Grafik von Mst/Wikimedia

Jahrelang konnte kein ernstzunehmendes Design im Web den Blocksatz benutzen. Kein Browser unterstützte die Silbentrennung und daher sah der Blocksatz einfach nur grässlich aus. Worte wurden ewig auseinander gezogen, es sah nicht schön aus. Als einzige Lösung praxistaugliche Lösung gab es ein Javascript-Tool namens Hyphenator, welches die Silbentrennung nachrüstete. Doch nun endlich seit Firefox 8 schon gibt es endlich auch für die deutsche Sprache Silbentrennung im Browser.

Bei der Einführung dieser Eigenschaft für die englische Sprache im Firefox 6, war das Ganze für den einen oder anderen noch eine Nachricht wert. Und obwohl nun die Silbentrennung endlich auch in deutsch funktioniert, wurde diese Eigenschaft mehr oder weniger unbeachtet von Mozilla nachgerüstet.

Die Details für den Firefox-Browser finden sich natürlich auf den Mozilla-Seiten. Die Spracheinstellung übernimmt Firefox aus dem lang-Attribut. Ist weder für das Dokument noch für den Absatz eine Sprache definiert, so trennt Firefox gar nicht.

 -moz-hyphens: auto;  
  hyphens: auto; 

Der Präfix -moz ist noch notwendig, da diese Eigenschaft noch experimentell ist und die Entwicklung in den Browsern noch am Anfang steht. Der Internet Explorer unterstützt die Silbentrennung mit dem Präfix -ms ab der kommen Version 10, Chrome und Opera unterstützen die Eigenschaft noch gar nicht und Safari (ab 5.1) unterstützt die Silbentrennung, benutzt aber eine völlig andere Syntax als Firefox. Im Gegensatz zum Firefox und dem IE 10 basiert die Trennung im Safari auch nicht auf den im Browser integrierten Trennungsdatenbanken, sondern auf den Datenbanken, die das Betriebssystem integriert hat (ähnlich wie bei der Rechtschreibprüfung unter Mac OS X). Unter Snow Leopard wird daher nur in Englisch getrennt. Erst ab Lion werden auch andere Sprachen (unter anderem Deutsch) unterstützt.

Die Informationen finden sich unter Lion in /System/Library/LinguisticData/ und bei Snow Leopard in /System/Library/Frameworks/AppKit.framework/Resources/English-Hyphenation.txt. Es wäre spannend auszuprobieren, ob sich die Informationen übertragen lassen. Hat das schon mal jemand getestet?

Die Syntax unter Safari sieht dann im Beispiel so aus:

p {
    -webkit-hyphens: auto;
    -webkit-hyphenate-character: '~';
  }

p[lang='en'] {
    -webkit-locale: 'en';
  }

p[lang='es'] {
   -webkit-locale: 'es';
  }

Mit webkit-hyphens definieren wir die Silbentrennung (manual, auto, none). -webkit-hyphenate-character wird leider nur von Webkit unterstützt. Damit wird das Zeichen definiert, welches für den Umbruch genutzt wird. Standard ist der normale Bindestrich „-“. In unserem Beispiel wird daraus die Tilde („~“). Die Sprache für die Trennung ist standardmäßig die Systemsprache, das lang-Attribut wird leider ignoriert. Möchte man die Sprache für Safari umstellen, so muss man dies per -webkit-locale tun.

Eine Sonderstellung hat der mobile Safari ab iOS 4.2. Dort lässt sich die Silbentrennung zwar auch mit -webkit-hyphens aktivieren, aber es wird jede Spracheinstellung in der CSS- oder HTML-Datei ignoriert und immer die Spracheinstellung des Gerätes verwendet. Daher ist von einer Nutzung eher abzuraten.

Quellen:

• http://code.google.com/p/hyphenator/wiki/en_CSS3Hyphenation
• https://developer.mozilla.org/en/CSS/hyphens

Ein Barcamp/WordCamp ist ein loses Zusammentreffen einer sehr heterogenen Gruppe. Hier treffen sich Core-Entwickler, Theme-Entwickler, Plugin-Entwickler, Designer, WordPress.com-User, Übersetzer, und viele Anwender mit mehr oder weniger Interesse an Community, kommerziellen Produkten, Internationalisierung, soweit es sie nicht direkt betrifft.

Das Problem ist also offensichtlich nicht zu lösen. Wie soll ich bei dieser schieren Masse an Nutzertypen das ideale Camp bauen? An was soll ich mich orientieren? Die Sessionbeschreibungen waren offensichtlich nicht ausreichend genug, um den einzelnen vor der Wahl einer falschen Session zu bewahren. Auch die Selbst-Einschätzung nach Anfänger, Fortgeschritten und Profi ist sehr heikel, wenn es keine klaren Maßstäbe gibt, wie diese Einschätzungen zustande kommen sollen. Während sich der eine schon „Profi“ nennt, traut sich der andere bei gleichem Kenntnisstand gerade mal „Forgeschritten“ zu. Die Kategorie wird damit so grob, dass sie kaum noch hilft. Zudem kommt hinzu, dass ich mich auf verschiedenen Bereichen unterschiedlich einschätzen könnte. Entwickler-Fortgeschritten, Design-Anfänger und SEO-Profi – und was nun? Was bin ich jetzt?

Foyer beim WordCamp

Selbst die geforderte Vorstellungsrunde hätte da meines Erachtens kaum etwas gebracht (was kein Grund wäre, es nicht nächstes Jahr trotzdem damit zu versuchen!). Denn bei über 250 Teilnehmern und zahlreichen Sessions wäre die Runde ewig lang geworden. Fraglich, ob die Erklärungen zu den Sessions hier länger und weniger missverständlich geworden wären. Einzig die ausgefallenen Sessions hätten an dieser Stelle schon einen Stellvertreter finden, oder für alle als „fällt aus“ markiert werden können. Ein absoluter Gewinn, da dies wohl für viel Frust gesorgt hat.

Vielleicht lässt man die Sessionleiter beim nächsten Mal diese Frage selbst beantworten:

• „Für wen ist deine Session gedacht?“
• „Was wird vorausgesetzt?“

Das wäre bei meiner Session zum Thema „WordPress.com-Blogs individualisieren“ dann so ausgefallen:

• Für alle die ein Blog bleim Bloghoster WordPress.com haben und dieses (mit z.T. wenig bekannten Features) voll ausreizen möchten.
• CSS-Grundlagen für einzelne Bereiche (Custom Design-Upgrade)

Aber auch so können natürlich immer noch Missverständnisse entstehen, aber vielleicht hilft es ein wenig.

Was die Enttäuschungen innerhalb der Session angeht, da ist jeder auch selbst gefordert auch den Mund aufzumachen. Wenn 20 Leute im Raum sind und 19 davon gerade nichts Neues erfahren, dann kann man das dem Sessionleiter ja kurz mitteilen. Vielleicht überspringt man dann bekannte Teile und diskutiert lieber mehr über Details auf einem nun höheren Niveau. Wenn niemand etwas sagt, dann orientiert man sich ggf. zu weit unten, weil man niemanden ausschließen möchte (siehe Anzahl unterschiedliche Nutzertypen!).

Ich gehe jetzt mal kurz die Sessions durch, die ich mir angehört habe:

Session 1 – eShops-Systeme

Die beiden Sessionleiter haben kurz alle wichtigen, kostenlosen Shopsysteme auf Pluginbasis für WordPress vorgestellt. Und zwar vor dem besonderen Hintergrund ob die Systeme eine Importfunktion haben. Das Ergebnis ist eine Fleißarbeit, die nett war, aber 1. sehr ernüchternd, was die Fakten angeht und 2. durch eine Recherche im Plugin-Repository auch jeder selber hätte machen können. Ich hatte für ein kommendes Projekt gerade Shopsysteme recherchiert und hörte hier leider kaum Neues. Testen muss man die Systeme ja trotzdem, ob sie für das aktuelle Projekt geeignet sind.

Kommerzielle Systeme, wie z.B. das für Deutschland hergestellte wpShop Germany wurden nicht erwähnt.

Das Fazit der Session war dann kurios: Die beste Lösung ist WordPress gar nicht für den Shop zu verwenden, sondern ein echtes Shopsystem (wie Oxid, Prestashop oder Magento), denn bei einem Shop sollte der Shop primär und das wichtigste Element sein. Ein Blog kann dann über ein gleich aussehendes Theme ergänzt werden.

Für meinen aktuellen Fall hat es sich trotzdem gelohnt, die Session anzuhören. Ich werde mir Quickshop und Jigoshop, letzteres trotz der WooCommerce/Fork-Geschichte, mal näher anschauen. Recherche-Bestätigung ist auch was Schönes!

Session 2 – WP.com Blogs individuell

Meine erste Session …

Die Bewertung müssen daher andere vornehmen. Sie war (vermutlich durch den Ausfall der Session von Vladimir Simovic) recht gut besucht. Erstaunlich war, dass viele Selbsthoster dabei waren, die WordPress.com dann benutzen, wenn sie schnell und unkompliziert mal ein Blog benötigen (oder natürlich wg. dem Stats-API-Key …)
Ich hatte am Ende doch zu wenig Zeit, bin kaum durchgekommen, daher konnten am Ende leider keine Fragen mehr gestellt werden und ich stelle mir selbst immer noch die Frage, ob die Hörer damit nun etwas anfangen konnten oder nicht. War ich zu sehr auf Anfänger eingestellt oder zu wenig? Ich freue mich auf Feedback!

Die Slides sind auch schon online.

Mein Einstieg war auf jeden Fall schon mal gut … ;-)

Schöner Beginn der Session zu wordpress.COM "Wer #WordPress selber hostet, ist hier eventuell falsch."
#wck11 http://img.ly/8Iq4—
Pottblog (@pottblog) September 24, 2011

Session 3 – Spaßbremse Recht

Für mich unverständlich warum hier viele Blogger von einer guten Session sprechen. Ja, der Vortrag war super, sehr unterhaltsam und sicher in seinem Wissen, aber ehrlich: Wer war von den Inhalten noch überrascht?

Wer ein Haustier hat, sollte wissen, wie man es füttert. Wer ein Blog hat, der sollte wissen, wie man es betreibt. Dazu gehört auch die Kenntnis der rechtlichen Seite. Ich habe jahrelang in der Jugendpresse geschrieben und Veranstaltungen organisiert, inzwischen habe ich ein paar Jahre nebenberuflich Webseiten gemacht. Ich also wahrlich kein Profi, aber Impressumspflicht, TMG, RDStV, das alles sollte einem nicht mehr neu sein – genauso wie die Tatsache, dass der Haftungsausschluss vom LG Hamburg, den alle so gerne zitieren, eigentlich genau den umgekehrten Fall beschreibt. Ich habe hier nichts Neues gehört, außer viel Naivität auf Seiten des Publikums. Ein bisschen erschreckend … ;-)

Session 4 – Podcasting auf WP.com

Meine zweite Session. Auch hier müssen andere die Bewertung vornehmen …

Wir waren nur eine Handvoll Personen und das Thema war nicht so komplex wie bei meiner ersten Session, so dass ich hier recht schnell durch war. Fortan entwickelte sich das Ganze eher zu einer WP.com-Session Nr. 2, was womöglich daran lag, dass einige meine erste Session nicht hören konnten, weil sie bei Teil 2 der Einsteiger-Session von Olaf Baumann waren. Leider keine sehr glückliche Session-Planung. Ist mir zu spät aufgefallen und vor Ort wurde aus Zeitgründen auf die Sessionvorstellung verzichtet, so dass sich hier leider nichts mehr ändern konnte.

Nochmal zur Sessionplanung generell:
Ich habe kein Problem mit einer festen Sessionplanung (was daran liegen mag, dass ich bisher auf keinem anderen Barcamp war), aber man sollte diese feste Planung auch entsprechend nutzen. Ich hatte Sessions bereits im System auf WordCamp.de markiert, also Interesse daran angemeldet. Meine eigenen Sessions waren dann genau parallel dazu geplant worden. Darauf wurde also anscheinend nicht geachtet. (Oder doch, aber es ging nicht anders?) WordPress.com-Sessions und eine WordPress-Einsteiger-Session sollte man nicht parallel legen, weil die Zielgruppe viel zu sehr übereinstimmt. Feste Sessions okay, aber mit mehr Sorgfalt bei der Planung!

Auch hier sind die Folien zu meinen Vortrag schon online.

Feedback ist willkommen!

Session 5 – XtremeOne

Noch bin ich kein Vollzeit-WordPress-Themebauer, daher war der Mehrwert für mich nicht ersichtlich. Eine Dauerwerbesendung mit rasend schneller Selbstbeweihräucherung inklusive unfreiwilliger Komik („bestes Widget-System der Welt [lachen] Nee, echt.“).

Vielleicht bin ich nicht kompetent genug, die Genialität des Werks zu würdigen, aber in der Geschwindigkeit und Art war das Ganze für mich völlig irrelevant. Dabei bin ich durchaus ein möglicher Kunde! Das Abspielen des Demovideos hätte denselben Effekt gehabt, dazu brauche ich aber kein WordCamp. Das kann ich auf der Homepage von zuhause haben.

Das soll überhaupt nichts Schlechtes über das Produkt aussagen, ich fand nur die Session nicht gut. Tut mir Leid.

Session 6 – Übersetzerrunde

Erschreckend: Wenn ich gewusst hätte, dass das WordPress Deutschland-Übersetzerteam *nur* aus Olaf Baumann besteht, dann hätte ich diese Sesssion nie eingereicht. Warum auch. Ich hätte meine Fragen einfach mit Olaf direkt geklärt. Dazu hätten wir keiner Session bedurft. So hatten wir ein sehr nettes, kleines Gespräch mit noch zwei Teilnehmern (unter anderem Bernhard Kau) über PoEdit, GlotPress und die Schwierigkeit beim Übersetzen generell und im Speziellen bei WordPress. Bernhard hat auch nochmal unsere spannendste Erkenntnis der Session im Codex herausgesucht. Nämlich wie man Übersetzungen mit einem Kontext versieht. Interessant ist auch, dass Automattic wohl überlegt die Sprachdatei direkt aus der Community-Lösung translate.wordpress.org zu beziehen. Damit würde WPD wohl oder übel die zentrale Lösung aufgeben müssen und mit dem GlotPress-System von WordPress.org arbeiten. Ungelöst ist dabei noch, wie dann neben der Du-Version noch die Sie-Version angeboten werden soll.

In diesem Zusammenhang mal wieder aufgefallen: Nach der Übernahme von de.wordpress.org durch WPD wurde ja alles soweit umgestellt, dass auf wordpress-deutschland.org verlinkt wird. Nur der direkte Link zum Forum ist immer noch möglich:

http://de.forums.wordpress.org/

Da schreiben auch immer wieder Leute, nur antwortet da niemand. Ist ja auch klar, da niemand dieses Forum betreut und der Großteil im Forum von WPD schreibt …

Session 7 – Jeopardy-Konfusion

Echt lustige, nerdige Idee. Aber die Regeln sollte man *vorher* abklären. Dazu gehört auch die Klärung wie Punkte vergeben werden und wer sie wie aufzeichnet … ;-)
Insgesamt schon irgendwie unterhaltend, aber manchmal auch eher unfreiwillig. Toscho als Joker, der darauf augenscheinlich überhaupt keinen Bock hat!? Für mich als Außenstehender witzig, aber nicht unbedingt hilfreich. Mit mehr Erklärungen, was die Lösungen angeht, ist das aber ein lustiges Spiel für den WordPress-Nerd. Ich bastle mir dann ein Jeopardy mit Videoformaten und spiele das bei uns im Büro … :-)

Foto: Alexander Frison

Nach dem WordCamp war ich dann endgültig todmüde. (Obwohl ich nicht derjenige auf dem Foto bin, der die Augen geschlossen hat, dass ist Thomas ‘Toscho’ Scholz.) Zwei Wochen habe ich das Finale vom Büro des Todes in Nachtschichten mit abgemischt und fertig gemacht, dann am Samstag Morgen drehte sich der Spieß um, statt um drei Uhr ins Bett zu gehen, bin ich um 3 Uhr aufgestanden, habe geduscht, bin ab zum Hauptbahnhof und dann nach Köln. Hier Mittags nur ein paar Brötchen … Als ich um 19 Uhr mit der Inpsyde-Crew Richtung Aachener Weiher ging, war ich so ungesprächig und müde, dass mir irgendwann schlagartig klar wurde, dass ich jetzt schnell etwas essen und ins Bett muss, bevor ich hier auf der Wiese einschlafe. Das ist echt schade, weil ich mich zu gerne noch näher mit den Inpsydes unterhalten hätte, aber die Lautstärke in dem Biergarten und die Tatsache, dass ich stumm war und kein Bier trank, mich in der Außenwahrnehmung wohl etwas langweilig erscheinen lassen mussten. Also zog ich die Reißleine und ging was Essen und ins Bett, was eine absolut richtige Entscheidung war. Wenn auch etwas bescheuert, wenn man zum Netzwerken hinkommt und dann alleine isst … Egal.

Es war ein schönes WordCamp, ich hatte viel Spaß, habe zwei Sessions gehalten und werde auch nächstes Jahr wieder dabei sein!

Ein riesengroßes Dankeschön an die Orga! Für das Bereitstellen einer großartigen Plattform für viele WordPressler. DANKE!

Bei konkreten Rückfragen, Lob und Kritik, könnt ihr gerne die Kommentarfunktion nutzen. Sollte die Frage jedoch zu allgemein werden oder euren Einzelfall betreffen, dann lasst uns lieber das Support-Forum nutzen. Danke!

Bei Fragen oder Anmerkungen zu den Folien könnt Ihr gerne hier die Kommentare nutzen, wenn es jedoch allgemeiner wird oder die Frage einen speziellen Einzelfall betrifft, dann lasst uns bitte das Support-Forum benutzen.

Die Session war recht gut besucht, auch wenn ich befürchte, dass dies nur deshalb der Fall war, weil der sehr geschätzte Kollege Vladimir Simovic leider krank war und deshalb seine parallel liegende Session ausfiel:

Mist! Augerechnet jetzt: Schnupfen, Husten & Kratzen im Hals. #WordCamp—
Vladimir Simovic (@vlad_perun) September 22, 2011

Ich hatte eigentlich schon damit gerechnet, dass die Session ausfällt, weil sich kaum jemand auf WordCamp.de dafür interessiert gezeigt hatte. Daher freut es mich um so mehr, dass ein niederländischer Core Contributer dabei war und auch sonst das Feedback durchaus positiv ausfällt.

„Da ich selber gelegentlich mal wordpress.com nutze, brachte mir die Session doch mehr als ich dachte.“ – Jens Matheuszik vom Pottblog

Foto: Jens Matheuszik

Entgegen meiner Einschätzung waren (durch die schon beschriebenen Gründe) vor allem WordPress-Nutzer in der Session, die sowohl selbst-hosten, als auch ein WordPress.com-Blog haben. Zum einen um den API-Key für die Stats zu bekommen, aber auch weil man auf WordPress.com eben sehr schnell ein funktionierendes Blog aufsetzen kann, mit etlichen Zusatzfunktionen.

Würde man versuchen einen Blog aufzusetzen, der die gleiche Funktionalität bietet, wie ein WP.com-Blog, dann ist es mit der 5-Minuten-Installation nicht mehr getan. Das Blog muss abgesichert sein, Updates und Backups müssen geplant werden und etliche Plugins müssen recherchiert, installiert und konfiguriert werden. Ein WP.com-Blog habe ich in 30 Sekunden am Start … ;-)

Soweit zur Session und den Gründen, warum man auch parallel noch einen WP.com-Blog haben kann. Nun freue ich mich über Feedback zu den Folien und zur Session.

Mein letztes WordPress-Projekt ist eine Vereinsseite für die RSG-Blankenese e.V. Es handelt sich dabei um eine einfache WordPress-Installation ohne viele Extras. Einfach eine Seite mit Infos zum Verein und die Blogfunktion für die News. Ich habe mich um die Installation, die Einrichtung des Themes und um ein paar Anpassungen gekümmert.

Da das gewünschte Theme RedBel jedoch keine deutsche Sprachversion hatte, habe ich die Übersetzung schnell mal selbst gemacht. Leider ist die Homepage des Theme-Erstellers tot, so dass ich ihm die deutsche Sprachfassung nicht anbieten konnte. Wer also eine WordPress-Seite auf Basis des RedBel-Themes hat, der kann die deutsche Sprachdatei nun hier bei mir herunterladen.

→ Deutsche Sprachdatei für das RedBel-Theme

Einfach das ZIP-File entpacken und die beiden Dateien (de_DE.mo/de_DE.po) in den folgenden Ordner auf dem Server legen:
/wp-content/themes/redbel/languages/

Wenn das Blog auf deutsch gestellt ist, dann wird automatisch auf die deutschen Sprachdateien zugegriffen, sofern sie vorhanden sind.

Einfach das neue Widget in die Seitenleiste ziehen …

… und konfigurieren.

Schon ist die Like-Box auf dem Blog!

Die englischen Texte in den Screenshots habe ich schon übersetzt. Die müssten also in den nächsten Tagen auch auf deutsch erscheinen.

via one cool site

Wenn Ihr Interesse habt, mehr über WordPress (bzw. WordPress.com) zu erfahren, andere Blogger treffen möchtet und vielleicht selbst von euren Erfahrungen mit WordPress berichten wollt, dann meldet euch an und seid dabei beim WordCamp 2011. Noch sind freie Plätze vorhanden!

Das Camp findet statt am Samstag, den 24. September 2011 in den Räumen der Humanwissenschaftlichen Fakultät der Universität zu Köln.

→ Zur Anmeldung

Bei Fragen oder Anmerkungen nutzt gerne die Kommentarfunktion hier!

Einfach in den Typekit-Account einloggen und den Kit Editor öffnen mit einen Klick auf „Launch Kit Editor“:

Kit Editor öffnen

Dann im Kit Editor ohne etwas zu Ändern einfach nur nochmal auf Publish klicken.

Publish klicken - und fertig!

Voilá, die Fonts werden wieder dargestellt!

Moderne Webseiten benutzen heutzutage eine semantische Auszeichnung, die möglichst einfach und effizient die Struktur baut, welche dann über Stylesheets designt werden. Zusätzliche Skripte haben entweder einen Fallback (Graceful Degradation) oder sind als Zusatznutzen konzipiert, der nur zum Tragen kommt, wenn das Skript unterstützt wird (Progressive Enhancement). Alte Webseiten erkennt man an groß-geschriebenen HTML-Tags, Tabellenlayout und/oder DIV-Suppe. Und in vielen Fällen werden Layout-Informationen direkt im HTML-Text geschrieben. Das würde man heute nicht mehr machen, aber zu der Zeit als diese Webseiten gebaut wurden, war die Entwicklung noch nicht so weit.

Aber dann gibt es noch Webseiten, bei denen man sieht, dass der Ersteller ein paar moderne Ideen hat, aber leider die ganze Idee dahinter nicht so recht begriffen hat. Ein Beispiel dafür ist die neue Webseite der Filmtournee unterwegs.

Der erste optische Eindruck ist wunderbar. Die frischen Farben gefallen und die Elemente (Navigation, Header, Footer, Inhalt) sind gut aufgeteilt. Der zweite Blick ist dagegen schon kritischer: Die Linkfarben sind nicht konsequent umgesetzt. Der User wird unnötigerweise verwirrt, wenn das helle grün als Linkfarbe genutzt wird, sowie als Farbe für Überschriften (ohne Link). Vor allem, wenn es dann noch Links gibt, die nicht in grüner Farbe sind. Mehr noch: Sie sind z.T. gar nicht ausgezeichnet, so dass man z.B. auf der Kontaktseite oder der Impressum-Seite gelegentlich einen Link findet, den man gar nicht erwartet hat.

Wohin der Link führt, wird uns aber auch nur selten verraten, denn -aus welchen Gründen auch immer- man hat sich entschlossen folgende geheimnisvolle Konstruktion für einen Link zu verwenden:

<span onclick="javascript:window.open('http://www.infomedia-sh.de/medien/filmwerkstatt-sh.html','','');" class="blank_link">Filmwerkstatt Kiel der Filmförderung<br>Hamburg Schleswig-Holstein GmbH FFHSH</span>

Warum hier nicht einfach ein ganz normaler Link benutzt wird, ist mir ein Rätsel. Stellt man in seinem Browser Javascript ab, so werden alle Links, die in dieser Art gebaut wurden plötzlich unbenutzbar.

Aber es geht noch schlimmer: Die gesamte Navigation läuft per iFrame ab. Klickt man auf einen „Link“ in der Navigation, so wird der iFrame mit einer anderen Seite versehen. Das heißt die gesamte Navigation ist tot, wenn man Javascript deaktiviert. Kein Fallback. Auch die Statuszeile gibt keine Infos über das Linkziel, wenn er auf diese merkwürdige Art gebaut wird. Und die schlimmste Sache: Durch die iFrame-Lösung gibt es nur eine Seite: die index.php. Ein Lesezeichen für einzelne Seiten zu setzen ist so nicht möglich. Das war vor 10 Jahren bei den Frames auch schon so. Inzwischen weiß aber man aber, wie wichtig es ist, dass Direktlinks auf Unterseiten möglich sind. Nicht nur für Suchmaschinen, sondern auch für den User sind „sprechende URLs“ und klar strukturierte Adressen hilfreich.

Neben solchen Problemen wirken Nervigkeiten, wie das animierte GIF, das als Favicon benutzt wird oder die Navigationsbuttons, die nicht über die gesamte Fläche anklickbar sind geradezu harmlos. Warum ein Scrollbalken erscheint, wenn ich mich mit der Maus rechts unten auf der Homepage befinde, habe ich noch gar nicht herausgefunden. Wahrscheinlich will ich es auch lieber gar nicht wissen.

Die weniger offensichtlichen Fehler offenbart ein weiterer Blick in den Quelltext. Die Meta Tags sind konsequent gar nicht gesetzt. Suchmaschinen erfahren hier also keine weiteren Informationen über den Ersteller oder den Inhalt der Webseite. Auch über eine XML-Sitemap erfahren die Suchmaschinen hier nichts.

Obwohl als Sprache XHTML benutzt wird, fehlen diverse „trailing slashes“ bei Befehlen ohne schließenden HTML-Tag und es werden schon lange als „deprecated“ (wird in Zukunft abgeschafft) eingestufte Elemente genutzt, wie der „Center“-Tag oder die Attribute „language“ beim Script-Tag und „border“ beim IMG-Tag. Im Formular wird beim action-Attribut „POST“ groß geschrieben obwohl es bei XHTML klein geschrieben werden müsste. Statt strong und em wird dementsprechend auch b und i benutzt. Daran, dass im Header „Englisch“ als Sprache definiert ist, merkt man, dass hier wohl generell wenig Sorgfalt stattfand und garantiert keine Endkontrolle. Auch die Skripte sind z.T. fehlerhaft eingebaut. Zwischen schließendem Body und schließendem html-Tag gehört kein Skript. Bei keinem einzigen Skript ist ein Fallback (z.B. per NoScript-Befehl) eingebaut.

Die Tatsache, dass es sich um ein Tabellenlayout handelt und eine Tastaturnavigation nicht möglich ist, da nicht alle Elemente mit der Tastatur erreicht werden ist da nur konsequent. Eine semantische Struktur über Headlines (h1-h6) wird nicht gebaut. Ein Druck-Stylesheet für die optimierte Druckausgabe der Webseite fehlt. Eine individuelle Fehlerseite ist auch nicht zu finden.

Aus welcher Zeit das Wissen des Ersteller stammt erkennt man an den Netscape-Farbangaben „darkorange“ und „papayawhip“, die anstatt der Hex-Werte als Namen notiert sind.

Die hohe Kunst der Performance-Optimierung hat hier natürlich auch nicht stattgefunden, so dass alle Seiten, Skripte und Stylesheets unkomprimiert ausgeliefert werden. Kein GZip.

Einfache MouseOver-Effekte werden per Javascript gebaut, obwohl sie per CSS einfacher, barrierefreier und browserübergreifender hätten realisiert werden können.

Es finden sich Layout-Angaben im HTML-Code und machen so die Wartung und den Code unnötig kompliziert (Spaghetti-Code).

Da die Webseite sowohl mit www als auch ohne aufgerufen werden kann und keine Umleitung stattfindet, besteht zudem noch das Duplicate Content-Problem. Eine gute Position bei Google ist nur aufgrund des wenig benutzten Namens denkbar, wenn man bedenkt wie viele Fehler hier gemacht wurden.

Fazit: Außen hui, innen pfui! Eine schöne Optik macht noch keine gute Webseite. Hier müsste definitiv nachgebessert werden.

Eine schöne Verbindung von Indie-Rock mit Indie-Kurzfilm …

Die Single erscheint übrigens am 3. Dezember.

[via NOISEAUX]