Das neue Design von SourceForge.net

Der große “Open-Source-Hoster” SourceForge.net hat ein neues Design. Die Optik wurde deutlich modernisiert und wirkt etwas zeitgemäßer. Auffällig ist, dass die Designer mit sehr vielen Farbverläufen gearbeitet haben um die Seite etwas geschmeidiger und “glatter” wirken zu lassen (hier darf geraten werden, was ich meine ;-)). Allerdings sind bei dem Redesign meiner Meinung nach einige Dinge deutlich schief gegangen.

Standardkonformität

• Im Großen und Ganzen ist die Seite recht valide. Es ist halt einfach schwer bis unmöglich, eine so große Seite die Code-Schnipsel von allen möglichen Seiten bekommt, komplett valide zu gestalten. Die einzigen Fehler die mir aufgefallen sind, waren & in URLs die nicht nach & kodiert waren und einige Tags die groß geschrieben waren. Die kommen vermutlich von irgendwelchen Anzeigenpartnern auf die SourceForge.net nicht so viel Einfluss hat - darüber lässt sich meiner Meinung nach hinwegsehen. Und zumindest ist ein deutlicher Ansatz erkennbar.
• Unschön ist allerdings, dass “presentational markup” benutzt wird. Das heißt konkret, dass viele Elemente mit <b>-Tags ausgezeichnet wurde. Das entspricht dem Grundsatz “Trennung von Design und Semantik” nicht so ganz, da das b-Element konkret fette Formatierung bedeutet. Sinnvoller wäre aber, nicht zu sagen “das soll Fett sein” sondern “das soll hervorgehoben werden”, also strong zu verwenden. Wie strong dann ausschauen soll, kann ja in den Stylesheets festgelegt werden.
• Ein grober Schnitzer ist meines Erachtens auch die Verwendung von b-Tags als Hilfselemente für die Gestaltung der Kästen. Konstrukte wie </b><b class="ttopw"></b><b class="t1w"></b><b class="t2w"></b> finden sich recht häufig im Quelltext. Semantisch hat das natürlich keinen Sinn, eine Verwendung von spans oder divs wäre sinnvoller bzw. semantisch weniger fragwürdig.

Usability

• Aus welchem Grund kann ich nicht auf das ganze SourceForge-Logo klicken um auf die Startseite zu kommen? Wieso ist das “.net” nicht anklickbar? Irgendwie irritiert mich das weil nichts passiert wenn ich auf die untere Hälfte des Logos klicke.
• Und aus welchem Grund gibt es gleich unter dem Logo einen “SF.net”-Link der zum selben Ziel, nämlich zur Startseite, führt?
• Weniger gelungen ist auch die Platzierung der Listen mit den Top-Projekten. Die sind auf der Startseite fast ganz unten eingequetscht zwischen den Site-News und Anzeigen.
• Fünfspaltiges Layout ist nicht so wirklich übersichtlich. Außerdem wird ständig zwischen 1-, 2,-, 3-, 4-, und 5-spaltigem Layout hin- und hergewechselt was die Situation noch verschlimmert.
• Und wieso werden die Beschriftungen der kleinen Icons über dem weißen Hauptkasten einer Projektseite (Beispiel), also der Schlüssel auf orangefarbenem Grund, das Werkzeug (?) auf blauem und der gelbe Kreis, nicht permanent angezeigt? Ich erkenne nicht sofort, was mit diesen Icons gemeint ist. Außerdem gerät es zum Geduldsspiel bis man es schafft, die Beschreibung per Mouseover einzublenden. Schonmal probiert erst auf das gelbe Symbol und dann auf das blaue zu zeigen? Ja, geht nicht da zwischen den Icons Zwischenräume sind.
• Ein Log-In ist jetzt erst nach einem Klick auf “Log-In” und anschließendem laden der Seite möglich. Früher war das ganz bequem auf jeder Seite möglich, ohne zusätzliche Zwischenseite.
• Die Leisten am oberen Bildschirmrand sind ja wirklich eine Zumutung. Ganze fünf Leisten werden standardmäßig eingeblendet. Das ließe sich deutlich reduzieren. Wozu ist die rotbrauen Leiste überhaupt nötig? Auf die Startseite komme ich auch mit einem Klick auf das Logo, das ich auf einer Projektseite bin, erkenne ich auch an der Breadcrumb-Navigation zwei Zeilen darunter, “My Page” lässt sich genau so gut neben den Benutzernamen in der Zeile darüber setzen und für “Help” würde sich sicher auch ein genau so guter Platz finden.
• Auf einer Projektseite verschlimmert sich der “Leistenwahn” noch. Dort kommen nämlich noch zwei zusätzliche Leisten hinzu: Die Titelzeile mit “Donate”, “Stats” und RSS-Link und die Projektnavigationsleiste. Die deckt sich ja eigentlich mit der Breadcrumb-Navigation da auch hier angezeigt wird auf welcher Projektunterseite der Benutzer sich befindet. Im Prinzip ist die Breadcrumb-Navigation dadurch ziemlich überflüssig - dass ich bei SourceForge.net bin erkenne ich am Logo, das ich ein Projekt ansehe daran, dass ich auf der entsprechenden Projektseite bin, welches Projekt ich ansehe erkenne ich an dem groß abgebildeten Namen der gleich darunter steht und auf welcher Projektunterseite wie gesagt an der Projektnavigation.
• Die einzige Verbesserung in Hinsicht auf Benutzbarkeit sind die Download-Seiten. hier kommt man deutlich schneller zum Ziel da zum einen unübersichtlich lange Listen durch JavaScript verkürzt werden und die jeweils neuesten Versionen ganz oben auf der Seite gelistet werden. Außerdem erkennt man in der “großen” Liste besser wo ein Release-Block aufhört und wo der nächste anfängt.

1. getElementsBySelector(selector): Wie viel einfacher wäre es doch, wenn es eine solche Funktion geben würde. Einfach den CSS-Selektor angeben und eine HTMLCollection mit allen zutreffenden Elementen zurückbekommen. Allerdings gibt es von Dean Edwards eine Funktion, die sie größtenteils simuliert: cssQuery. Der Nachteil dieses Workarounds ist die Größe: 16 KB unkomprimiert und 6 KB komprimiert - gerade noch vertretbar.

2. firstElement, nextElement, usw.: Ein gewisser Vorteil einerseits aber oft ein gewaltiger Nachteil ist, dass das DOM alles als Knoten betrachtet. Auch ein Leerzeichen zwischen zwei Elementen generiert einen neuen Knoten, genauso wie ein Kommentar. Wenn man nun das erste Element/Tag innerhalb eines anderen Elements zu bekommen, stößt man auf ein Problem: firstChild liefert möglicherweise einen Textknoten (mit Leerzeichen) und nicht das erste Element zurück.

3. Die Möglichkeit mit einer for...in-Schleife die Elemente einer HTMLCollection zu durchlaufen: Wenn man das probiert, erhält man nicht jedes Element sondern die Indizes des HTMLCollection-Objekts. Das lässt sich teilweise durch Wrapper-Funktionen, die das ganze in ein Array umpackt, ersetzen.

4. Ein Klassenmanagement-System: Man muss sich immer erst selbst Funktionen schreiben, die solche grundlegenden Abfragen ermöglichen. Wäre es nicht viel eleganter einfach auf element.hasClass('klasse') zu prüfen? Mit Prototypen kann man so etwas aber recht einfach realisieren. Notwendige Funktionen wären mindestens hasClass (zum Überprüfen ob das Element die Klasse besitzt), addClass (um eine Klasse hinzuzufügen) und removeClass (um eine Klasse zu entfernen). Zusätzlich wäre noch toggleClass (wenn das Element die Klasse hat, wird sie entfernt, ansonsten hinzugefügt).

Es gibt Sachen, die sind begrenzt. Zum Beispiel die Buchstaben des Alphabets. Das hat 26 Stück, wenn man Buchstaben, die mit Diäresen, Striche, Tilden, Accents und sontige Verzierungen und Ligaturen weglässt. Und wenn man zwei Buchstaben hintereinander stellt, bekommt man schon 676 Möglichkeiten, bei drei werden es schon 17576. Eigentlich logisch, dass es da irgendwann zu Kollisionen kommt. Natürlich sind nicht alle Kombinationen mit drei Buchstaben belegt (Vermutung von mir, wenn das Gegenteil bewiesen wird, soll’s mir auch recht sein). Zeichenfolgen mit komischen Kombinationen will natürlich niemand haben, deswegen bleiben die frei.

Und dann gibt es auch noch die Zeichenfolgen, die jeder haben will. “CSS” ist so ein Beispiel. Das Lexikon für überflüssiges Wissen, nutzlose Fakten und Besserwisser, in der Fachsprache auch als Wikipedia bezeichnet, kennt für diese Buchstabenkombination gleich 9 verschiedene Bedeutungen. “Na gut, dann gibt’s halt 9 verschiedene Bedeutungen, aber was interessiert mich das?” Der geneigte Leser erkennt jetzt sofort, dass massive Probleme auf uns zukommen. Wenn nämlich Scripte eingesetzt werden, die automatisch Abkürzungen mit solchen lustigen kleinen Pünktchen versehen, kann es zu Kollisionen kommen.

In manchen Bereichen ist es ja noch relativ einfach. In einem Forum für Webdesigner meint “CSS” in den seltensten Fällen “Content Scrambling System” oder gar “CounterStrike: Source”. Aber wenn man andere Bereiche hernimmt, kann es hier schon zu Problemen kommen: Im Heise-Forum gibt es sowohl Trolle, die “CSS” schreiben und “Cross-Site-Scripting” meinen als auch solche, die damit “Cascading Stylesheets” meinen.

Was tun? Eine Lösung muss natürlich her. Man kann Benutzer nicht dazu zwingen, zu jeder Abkürzung, die sie benutzen, die ausgeschriebene Variante dazu anzugeben - oft wissen die Nutzer selbst nicht genau, was damit gemeint ist. Ganz auf solche Abkürzungen verzichten? Das wäre eine Möglichkeit. Dem Nutzer lieber keine Information als eine möglicherweise falsche Information geben.

Eine andere Lösung wäre aber auch, eine große Akronymdatenbank anzulegen, in die alle Informationen eingetragen werden, eventuell auch mit einer kurzen Erklärung. Wenn der Benutzer jetzt ein Akronym eingibt, erscheint eine Auswahlliste, ähnlich wie bei “Google Suggest” oder in vielen anderen Eingabefeldern aus Desktopapplikationen, in der alle Möglichen Erklärungen enthalten sind. Das Problem hierbei: Normalerweise tippt der Benutzer in eine textarea und nicht in ein normales Eingabefeld. Meines Wissens ist es nicht möglich, per JavaScript zu erkennen, wo sich genau der Cursor befindet so dass eine Liste eingeblendet werden kann, falls das Akronym mehrdeutig ist.

Wer schon einmal längere Zeit mit einem (W)CMS gearbeitet hat, wird sich bald wünschen, sie wäre ein normales Programm für sein Betriebssystem und keine Webanwendung. Die meisten Webanwendungen die ich kenne haben äußerst wenig Komfort. Meistens beschränken sie sich auf das Bereitstellen von Eingabefeldern und die Auswertung nach dem Absenden des Formulars. Wenns ganz schlimm kommt, ist das Formular auch noch in alle möglichen Tabellen eingepackt, enthält Inline-Bilder usw.

Einen sehr interessanten Beitrag über das link-Element hat Tom Stich zusammengestellt. Überhaupt finde ich dieses Element (das übrigens auch auf normalen Links mittels des Attributes rel oder rev funktioniert) sehr sinnvoll - so macht semantisches Webdesign richtig Spaß (hier ist nicht das semantische Web von Tom-Berners Lee gemeint). Aber das Beste ist, dass man die Standardfeatures ziemlich leicht ergänzen kann und es gibt auch schon alle möglichen sogenannten “Profile” für das link-Tag, z.B: XFN.

Wer sich jetzt frägt was um Himmels willen man mit diesen Tags bewirken kann, tut das sicher nicht zu unrecht. Normalerweise verwendete man das link-Tag ja nur zum Einbinden von Stylesheets. Es kann aber viel mehr, z.B. große Dokumente gliedern, und überhaupt die Navigation vereinfachen. Aber es gibt einen Nachteil: Der Browser muss das Ganze unterstützen. Der Internet Explorer tut das natürlich nicht, aber auch Mozilla Firefox kennt dieses nützliche Feature nicht - dazu braucht es schon einer Erweiterung: die LinkToolbar. Einzig die Mozilla Suite und Opera (bei Safari, Konqueror etc. bin ich mir nicht sicher) unterstützen dieses Tag bzw. die dazugehörigen Attribute (rel und rev) von Haus aus. Von Hand aktivieren muss man sie aber trotzdem.

Aber es gibt durchaus schon große Webseiten die diese Funktion, die es schon in den Anfangstagen von HTML gab (!), unterstützen - prominentestes Beispiel ist hier sicherlich das Nachrichtenmagazin stern.

Auch wenn diese Tags noch nicht so weit verbreitet sind kann man mit der Erweiterung schon etwas anfangen. Sie durchsucht die gerade geladene Webseite nämlich auf so Wörtchen wie “next”, “previous” oder Zeichen wie > oder < die auf seitenweise Navigation hindeuten. Das funktioniert erstaunlich gut - durch Google-Suchergebnisse kommt man so blitzschnell.

Was Anne noch sucht, hab ich (für mich) gefunden: Das perfekte Weblog-/Webpublishingsystem. Sein Name ist Drupal

Drupal bietet so ziemlich alles was man braucht, angefangen von Blog-Features, einer API für Weblogs, vollständige UTF-8-Unterstützung(!), Moderation, Anti-Spam-Plugin, ausgefeiltes Rechtemanagement, XHTML-Kompatibilität (out of the box), schöne URLs, extrem erweiterbar durch Module (von denen es einige auf der Drupal-Website gibt).

Schon in dem Standardinstallationsarchiv sind Module für ein Forum, ein Blog, statische Seiten, ein Buch (Wiki-ähnlich), Umfragen und noch einige andere enthalten. Zusätzlich gibt es online einen Event-Kalender, Umfragebögen, einen Online-Shop, ein Banner-Modul, Bildergalerien, ein PayPal-Framework und noch einige mehr. Wer nicht findet, was er braucht, kann sich auch (ziemlich einfach) selber ein Modul basteln.

Drupal ist komplett themebar - jedes (X)HTML-Tag ist veränderbar. URLs kann man auch selber basteln, z.B. für wichtige Seiten. Und vor allem: Drupal ist internationalisierbar - es gibt Sprachpakete für einige Sprachen (das Deutsche ist noch nicht ganz komplett, aber ich arbeite dran ;-)) und man kann so wirklich alles in eine andere Sprache übersetzen.

Wer jetzt vermutet, so ein CMS hat mindestens 20 MB, liegt absolut falsch. Der Tarball mit der Grundausstattung wiegt läppische 460 kB - und bringt schon einige Themes mit. Drupal setzt nur einen Apache, PHP 4 und MySql oder PostgreSQL vorraus, lässt sich also auch auf einem Shared-Hosting-Account problemlos betreiben.

Das ganze mag vielleicht etwas euphorisch klingen, jeder der Drupal ausprobiert und sich wirklich damit auseinandersetzt (Handbuch lesen!) wird aber schnell merken wie mächtig das System ist. Drupal ist auf jeden Fall eine Alternative zu Konsorten wie Typo3 (naja, vielleicht nicht ganz ;-)) oder Contenido.