Montag23. März 2009

CSS-Frameworks sind bei mir immer wieder Thema. Klar, ich entwickle ja auch ein eigenes. Dennoch – vergleichbar mit der Argumentation pro & contra CSS-Layouts, die David Maciejewski, Tomas Caspers und ich in der letzten Technikwürze diskutiert haben – mache ich mir bereits seit längerem Gedanken um eine gehaltvollere Argumentation in der öffentlichen Diskussion. Die Anzahl der Framework-Projekte wuchs im letzten Jahr fast wöchentlich und noch immer kommen regelmäßig neue Projekte hinzu. Gleichzeitig wird die Streubreite der Layoutansätze, Funktionsumfang und Intention der Projekte (Layout, Formulare, Menüs) immer größer, sodass ein Vergleich zwischen einzelnen Frameworks nicht gerade einfach ist, ganz zu schweigen von der nicht weniger weitgefächerten Erwartungshaltung von Webentwicklern an derartige Projekte. Zudem gibt es weder im deutschen noch im englischen Sprachraum nur sehr wenige Beiträge, die sich eingängig mit dem übergeordneten Konzeptes eines Frameworks im Beich HTML & CSS beschäftigen. Einer der wenigen Beiträge in dieser Richtung “Frameworks for Designers” wurde im Juli 2007 von Jeff Croft auf A List Apart veröffentlicht.

Fast in direkter Folge auf diesen Artikel erschien seinerzeit Blueprint CSS auf der Bildfläche und leitete einen weltweiten Hype ein, obgleich Projekte wie YAMLoder YUI Grids zu diesem Zeitpunkt bereits jeweils etwa 2 Jahre Entwicklungszeit hinter sich hatten. Keines der beiden Projekte vermochte aber die Aufwerksamkeit der Gemeinde der Webentwickler derart aufzurütteln.

Mit Blueprint CSS und seinem geradlinigen Grid-Ansatz kamen die Diskussionen um CSS-Frameworks in Schwung, wobei insbesondere im englischen Sprachraum aufgrund des Hypes die beiden Bezeichnungen “CSS-Frameworks” und “Blueprint CSS” sehr eng miteinander verbunden. Positive Stimmen heben den Gridansatz von Blueprint (und damit CSS-Frameworks) in den Himmel, kritische Stimmen bemängeln den tabellenähnlichen Aufbau des Markups, weiten ihre Kritik aber ebenso wie die Beführworter meist pauschal auf alle Framework-Projekte aus. Hinzu kommt die verbreitete Liebe zu Top-Listen-Blogbeiträgen (“Die 10 besten ...”, “Die 100 besten ...”), wobei das Hinterfragen der unterschiedlichen Projektansätze zugunsten der Masse auf der Strecke bleibt.

Bereits auf dem Webkongress 2008 in Erlangen habe ich deshalb in meinem Vortrag versucht, einen etwas differenzierteren Blick auf die Vielzahl der Frameworkprojekte zu werfen und dabei die individuellen Stärken und Grenzen der Projekte, wie auch die allgemeinen Vorteile der Arbeit mit CSS-Frameworks herauszuarbeiten. Der im Verlauf der letzten 3 Wochen in Zusammenarbeit mit Nils Pooker entstandene Essay “Was Sie über CSS-Frameworks wissen sollten!” ist eine Fortführung dieser Betrachtung, der parallel auch in englischer Sprache veröffentlicht wird.

Wir haben dabei bewusst die Länge des Essays in Kauf genommen, denn wir wollten alle in der öffentlichen Diskussion befindlichen Aspekte ansprechen und nicht in einer Serie Einzelartikeln in Details verlieren. Zu schnell ginge in der Hitze der Diskussion der Blick auf das übergeordnete Konzept verloren. Erwartungsgemäß steckt in diesem Essay unsere meine Meinung pro CSS-Frameworks, denn sonst würde ich mich wohl kaum um die Weiterentwicklung von YAML kümmern. Wir hoffen, mit diesem Essay die Diskussion anregen zu können und freuen uns auf hoffentlich zahlreiche Kommentare und Blogbeiträge, gern auch mit gegenteiligen Meinungen. Bei Interesse antworten wir auf interessante Diskussionspunkte auch gern mit einem Folgebeitrag.

In diesem Sinne, viel Spaß beim Lesen ...


Mittwoch18. März 2009

Vor etwas mehr als 8 Monaten hat dieses Webseite ein umfassendes Redesign erfahren. Damit einher ging ein Testballon, meine Eigenentwicklung einer dynamischen Kommentaransicht. Die Kommentare erscheinen jeweils rechts neben den Blogbeiträgen, ältere Kommentare werden dynamisch ausgeblendet, damit auch bei vielen Kommentaren kein Zaunlattenlayout (the long tail) entsteht, welches endloses Scrollen erfordert. Nach fast einem dreiviertel Jahre wird es Zeit, sich über die Zukunft dieses Features ein paar Gedanken zu machen.

Die dynamische Kommentaransicht wurde mit jQuery realisiert und blendet die jeweils neuesten 5 Kommentare ein. Ältere Kommentare werden dynamisch paginiert und können bei Interesse entweder in schrittweise (jeweils 5 Kommentare) oder vollständig aufgeklappt werden. Anfängliche Schwierigkeiten mit dem Anspringen der neuesten Kommentare von der Highresolution-Startseite waren schnell behoben. Ebenfalls bereits seit ein paar Monaten gibt es auch den von Alexander Farkas angeregten Yellow-Fade-Effekt, mit dem der angesprungene Kommentar kurzzeitig gelb hervorgehoben wird.

Im damaligen Relaunch-Artikel gab es insgesamt viel Lob aber auch einige kritische bzw. bedenkliche Stimmen, was die Position der Kommentare bzw. die ungewohnte Art der Präsentation angeht.

8 Monate später ist mein Resümee dieses Experimentes durchweg positiv. Ein Absinken des Kommentaraufkommens konnte ich nicht feststellen, das neue Bloglayout hat eher dafür gesorgt, dass viele neue Leser offensichtlich gern in diesem flexiblen Layout verweilen und durchaus auch gern und umfangreich kommentieren – obwohl ich durchschnittlich kaum mehr als 3 Beiträge pro Monat schreibe. Optisch hat die Lösung die gesetzten Ziele voll erfüllt, denn das Layout ist auf dein meisten Artikelseiten sehr gleichmäßig ausgelastet und die rechte Spalte läuft nicht mehr ins endlos nach unten. Meine Leser scheinen – zumindest ist das mein Eindruck – mit der Kommentaransicht gleichfalls gut zurecht zu kommen, denn Diskussionen innerhalb der Kommentare finden auch gelegentlich statt.

So gesehen, werde ich dieses Feature also beibehalten und möchte deshalb hier die Frage in den Raum stellen, ob grundsätzlich Interesse an einer Plugin-Lösung auf jQuery-Basis für die dynamische Kommentaransicht besteht? Der Quelltext befindet sich grundsätzlich in recht ordentlichem Zustand, sodass die Umwandlung in ein Plugin keinen zu großen Aufwand bedeuten würde. Allerdings stellt sich eben zuvor die Frage, ob überhaupt Interesse an dieser Darstellungsform besteht – nicht nur an einer exemplarischen Umsetzung sondern auch das Interesse, ein solches Plugin im eigenen Blog einzusetzen. Ich bin gespannt auf Eure Antworten.


Samstag07. März 2009

Im letzten Sommer habe ich in meinem Essay zu flexiblen Layouts (deutsch / englisch) ja für einigen Diskussionsstoff gesorgt. Im Rahmen dieses Beitrags hatte ich mir die Display-Statistiken von w3schools.com herangezogen, um darauf hinzuweisen, dass eine “Optimierung” von Webseiten auf eine feste Breite von 1024 Pixel Breite nicht wirklich Sinn macht, denn die absoluten Auflösungen und die damit verbundene Vielfalt steigen immer weiter an. Auf Basis der Statistik hatte ich damals eine Prognose für die Verteilung im Januar 2009 vorgestellt und diese gilt es nun, da die aktuellen Zahlen verfügbar sind, zu überprüfen.

Das Diagramm zeigt drei Graphen für Auflösungen von 800x600, 1024x768 Pixeln und alle darüberliegenden Auflösungen (Higher) als Volllinien. Die gestrichelten Linien entsprechen meiner Prognose für die Entwicklung bis Januar 2009 vom Juni letzten Jahres.

Wie man sieht, liege ich ganz schön daneben – im positiven Sinne. Denn der Anteil der höheren Auflösungen hat exponentiell zugelegt, während ich damals vorsichtig herangegangen war und damals nur eine lineare Zunahme angenommen habe. Dementsprechend ist auch der Anteil für die 1024x768 Auflösung kräftiger gefallen als vermutet. Während ich eine Abnahme auf ca. 42% geschätzt hatte, weist die Statistik aktuell nur noch 36% aus.

Das Gesamtbild verdeutlicht, wie vielfältig und nicht vorhersagbar die Randbedingungen sind, mit der Webseiten im Browser betrachtet werden. Zumal noch hinzukommt, dass der Browser selten im Vollbildmodus betrieben wird, sodass die noch ein weiterer Unsicherheitsfaktor (die Größe des Viewports) hinzu kommt. Ich selbst arbeite mittlerweile sowohl dienstlich als auch privat nur noch in Auflösungen von 1680x1080 oder darüber, der Brower lasse ich ausschließlich in einem Fenster laufen, ziehe jedoch das Fenster meist sehr weit auf, um beim Surfen nicht von anderen Applikationan abgelenkt zu werden. Die Viewportbreite meines Browserfensters liegt daher gewohnheitsmäßig (je nach dem, an welchem Rechner ich gerade sitze) zwischen 1400 und 1600 Pixeln. Das war auch der Grund, weshalb ich das Layout dieser Seite flexibel gestaltet und für große Auflösungen entwickelt habe.

In diesem Zusammenhang auch spannend, die aktuelle Display-Statisik von YAML.de, eine Seite mit recht ordentlichem internationalen Besucherverkehr. Wie man sieht, ist der Anteil der 1024er Auflösung mit 12% bereits deutlich niedriger. Den größten Einzelposten kann die 1280er Auflösung für sich beanspruchen mit 43%. Zusammen mit der 1024er sind das knapp über die Hälfte aller User. Das zeigt zum einen, dass der allgemeine Focus für die Breite einer Webseite sich in diesem Bereich bewegen sollte (alles andere hätte auch verwundert). Aber man sieht auch wie kräftig 1440, 1680 und die HD-Auflösung mit 1920 Pixeln Breite mittlerweile vertreten sind. Und für diese drei Auflösungen prognostiziere ich für Januar 2010 einen weiteren deutlichen Anstieg, während die kleineren Auflösungen, einschließlich der 1280er Breite stark federn lassen werden.

Egal, für welche Breite man letztlich sein Layout auslegt. In jedem Fall sollte die Zentrierung einer linksbündigen Anordnung vorgezogen werden. Denn bei einer fixen Breite von 760px bedeutet das schon bei der 1280er Auflösung, dass 40 Prozent der Viewportbreite ungenutzt bleiben. Steigt die Auflösung beim User - oder werden Inhalte innerhalb des Layout nicht über die volle Breite darsgestellt (typisch für Mehrspaltenlayouts), verschiebt sich das Verhältnis im Regelfall noch weiter in die Richtung, dass der ungenutzte Raum dominiert.
 


Montag02. März 2009

Bereits vor reichlich 3 Wochen hat Dirk Ginader in seinem Weblog ein jQuery-Plugin zur Erstellung barrierefreier Tabboxen veröffentlicht und in einem umfangreichen deutsch- wie englischsprachigen Releasebeitrag auch einen tiefen Einblick in die Hintergründe seiner Lösung gegeben. Offenbar lesen noch viel zu wenig Leute Dirks Blog, denn bei den üblichen Verdächtigen (zumindest denen, die ich über meinen Feedreader überwache) blieb es weitgehend still.

Vor ca. 1,5 Jahren, im Sommer 2007 sprach ich Dirk Ginader per Skype auf ein kleines Problem an. Damals machte ich gerade meine ersten Schritte mit jQuery und wollte für das Redesign von YAML.de ein Tabscript verwenden, um mehrfach hintereinander aufgelistete Quelltextabschnitte aufgeräumter präsentieren zu können. Zu diesem Zweck sah ich mir verschiedene Tab-Lösungen (mit und ohne jQuery) an, die jedoch alle am gleichen Problem krankten.

Die Tabs funktionieren generell nur in Verbindung mit JavaScript. Dennoch erwarteten sämtliche existierenden Scripte von mir, den für die Tabreiter notwendigen Markup (UL-Liste) fest im Layout zu integrieren. Ich hielt das für unsinnig, denn zum Wesen von unaufdringlichem bzw. zugänglichem JavaScript gehört, dass Bedienelemente, die nur in Verbindung mit der JavaScript-Applikation benötigt werden, auch per JavaScript erzeugt werden sollten.

Daraus entstand folgende Idee: Man definiert einen Bereich der Webseite, welcher die Tabinhalte beinhaltet und definiert ein HTML-Element, welches als Trenner zwischen den Tabinhalten fungiert und den Namen des Tabreiters beinhaltet. Im einfachsten Fall wäre das Bereich aus gleichrangigen Überschriften und Absatztexten. Per JavaScript könnten aus den Überschriften die Tabreiter generiert werden. Die dazwischen befindlichen Absatztexte (oder was auch immer sich zwischen den Trennelementen befindet) würden als Inhalte der Tabs interpretiert und entsprechend gestaltet. Das Schöne daran: Ist JavaScript deaktiviert, so stört kein unsinniger Listenmarkup und die Tabinhalte präsentieren sich im normalen Textfluss der Webseite.

Mit dieser Idee trat ich also im Sommer 2007 an Dirk heran und es dauerte nur wenige Tage bis die erste Version des Plugins Gestalt annahm, die im Übrigen bis heute auf YAML.de in der Dokumentation der Subtemplates ihren Dienst tut. Schon lange hatten wir vor, dieses Plugin zu verfeinern und zusammen mit YAML zu veröffentlichen. Dass es dennoch bis ins Jahr 2009 gedauert hat - naja, sei es drum. Ein großer Teil der Verzögerung floss nämlich eben in die Verfeinerung des Plugins, über die Dirk in seinem Blog auch ausführlich berichtet. So ist es gerade bei den so gern auf modernen Webseiten verwendeten Tabs alles andere als trivial, diese wirklich barrierfrei zu gestalten. Nun hat Dirk bei Yahoo in London den besonderen Vorteil, mit Artur Ortega einen blinden Kollegen neben sich sitzen zu haben, und beide gemeinsam konnten die sich langsam entwickelnde Lösung nicht nur theoretisch durchdenken, sondern auch unmittelbar im Praxistest auf Herz und Nieren testen. Vielen Dank Euch beiden, wirklich eine reife Leistung.

Momentan stehe ich mit Dirk in Kontakt, um noch weitere Verbesserungen an seinem Plugin vorzunehmen. So soll das Script in der nächsten Version unabhängig von animierten Übergängen eine vollständige Druckausgabe aller Tabinhalte unkompliziert ermöglichen und eine optionale Synchronisierung der Containerhöhen der Tabinhalte möglich sein. Eine Anreicherung mit ARIA ist ebenfalls denkbar.

Übrigens: Auf die gleiche Art und Weise ließen sich auch zugänglichere Accordion-Boxen erstellen. Die Probleme dürften sich gleichen, ebenso wie der aufgezeigte Lösungsweg.


Seit heute ist die 15. Ausgabe des T3N Magazins verfügbar und dieses Mal habe ich mal wieder einen Artikel beigesteuert. Auf dem Berliner Barcamp im Oktober letzten Jahres war ich mit den yeebase-Jungs ins Gespräch gekommen und habe Anfang Januar habe ich dann in die Tasten gehauen. Wenig verwunderlich dreht es sich um Layout-Frameworks.

  Seit langem schon ärgert es mich, dass in Berichten über CSS-Frameworks immer wieder die z.T. grundverschiedenen Ansätze der verschiedenen Projekte undifferenziert in einen Topf geworfen und miteinander verglichen werden. Deshalb fasse ich alle aktuell existierenden Projekte zunächst unter dem übergeordneten Begriff Layout-Frameworks zusammen. Ausgehend vom gewählten Layoutansatz es Frameworks folgt dann eine Unterscheidung in Grid- und CSS-Frameworks (eine Einstufung, die ich auch schon beim in Webkongress in Erlangen vorgestellt habe).

Grid-Frameworks
Sinn und Zweck eines Grid-Frameworks sind schnelle Ergebnisse in der Anwendung in den Grenzen des vorgegebenen Rasters.
CSS-Frameworks
Sinn und Zweck eines CSS-Frameworks ist die Bereitstellung einer möglichst leistungsfähigen Entwicklungsumgebung

Den roten Faden durch den Beitrag bildet die Betrachtung der Entwicklungszeit eines Layouts, wobei sich Layout-Frameworks in Abhänhigkeit des Layoutansatzes und der gewährten Freiheiten recht gut zwischen den beiden Extremen, dem Einsatz von Fertigtemplates (minimaler Aufwand, kein Einfluss auf Codequalität) oder der vollständigen Handkodierung des Layouts (volle Codekontrolle, maximaler zeitlicher Aufwand zur Layouterstellung) einordnen lassen. Unabhängig von persönlichen Vorlieben für den einen oder anderen technischen Weg lässt sich über die Zeitschiene sehr deutlich zeigen, wo die maßgeblichen Vorteile von Layout-Frameworks liegen - in der geringeren Entwicklungszeit.

Die gewonnene Zeit kann für Verbesserungen von Usability und Accessibility und/oder Performanceoptimierungen genutzt werden, denn diese Eigenschaften professioneller Webseiten sind in erster Linie contentabgängig. Das umschließende Layoutgerüst von Layout-Frameworks bietet zwar ebenfalls Potential, jedoch weit weniger als oft vermutet. Bei typischen Größen von 200 ... 300 kB komplexer Webseiten hat das Seitenlayout (HTML und CSS) im Durchschnitt einen Anteil von 5-10 Prozent (unabhängig von der Entstehung).

Im zweiten Teil des Artikel dreht sich dann auch alles um Performance. Frameworks bieten hier aufgrund ihres modularen Aufbaus des CSS naturgemäß Angriffsfläche für Kritik. Kommentare im CSS bedeuten verlängerte Ladezeiten, jeder einzelne CSS-Baustein muss vom Server angefordert werden (HTTP-Requests), was zwangsläufig mit Wartezeiten verbunden ist. Vergessen wird bei dieser Diskussion zumeist, dass auch bei der Handkodierung von Webseiten kaum ein Entwickler auf Zeilenumbrüche, Einrückungen und den einen oder anderen erläuternden Kommentar verzichten kann. Worauf ich hinaus will: Ob Framework-Einsatz oder Handkodierung - die Komprimierung von CSS-Dateien und die Reduzierung von HTTP-Requests sind generelle Optimierungszenarien, um die Performance einer Webseite zu steigern. Wer Performance-Optimierung ernsthaft betreibt, der kommt um eine komprimierte Live-Version des Entwickler-CSS nicht herum.

 


Seite 1 von 1 Seiten