Montag20. Juli 2009

Frank Bültge, einer der bekanntesten Köpfe der deutschen Wordpress-Szene äußerte am Samstag in seinem Blogbeitrag "Unzufrieden als digitaler Freizeitkämpfer" seinen Umut über das geringe Feedback auf seine vielen GPL-Veröffentlichungen der letzten Jahre. Frank bezieht sich dabei einerseits auf die extrem geringe Spendenbereitschaft im deutschsprachigen Raum, aber auch auf sehr spartanisches oder gar ausbleibendes Nutzerfeedback, speziell aus dem Bereich der Businessanwender. Frank Bültge spricht damit ein Thema an, welches mir seit vielen Jahren nur zu gut vertraut ist – die Wertschätzung von Open Source in Deutschland.

Die Diskussion in den Kommentaren ließ nicht lange auf sich warten und ist ausgeprochen fasettenreich. Bemerkenswert und und leider kein Einzelfall sind Kommentare mit folgendem Tenor:

Wenn es kostenlos ist, ist es kostenlos! Ich zahle gern für gute Software und gute Plugins, auch gern mal etwas mehr. Aber irgendwie versteh ich Eure Sicht trotzdem nicht, denn im Grunde liest es sich ja schon so raus das ihr gönnerhaft GPL Plugins schreibt, dann aber trotzdem hofft eine Spende zu bekommen, letztlich ist GPL dann sinnfrei weil ihr für Eure Leistung einen finanziellen Gegenwert erhaltet, auch wenn der sicherlich nicht im Verhältnis zu Euer Arbeit steht.

Kommentar Nr. 48

Die GPL ist aus Anwendersicht eine tolle Sache, den diese Lizenz gibt dem Anwender sehr viele Freiheiten und die notwendige Rechtssicherheit, aber keine Arbeit – und schon gar nicht qualitativ hochwertige Arbeit – ist umsonst. Der Autor dieses Kommentars sieht das jedoch ganz anders.

Seit vielen Jahren existieren zahlreiche schillernde Perlen am Open-Source-Himmel, die da lauten: Mozilla Firefox & Thunderbird, Wordpress, MySQL, OpenOffice, Joomla, Ubuntu, jQuery, Eclipse u.v.a.m. All diese Dinge gibt es quasi gratis für den Anwender. Dieser Umstand lässt schnell vergessen, dass hinter diesen erfolgreichen Großprojekten finanzkräftige Firmen, Organisationen oder Sponsoren stecken, die solche langfristig angelegten Projekte mit einer Vielzahl exzellenter Entwickler überhaupt ermöglichen und die vom Nutzer letztlich als qualitativ hochwertige Produkte wahrgenommen werden. Doch die GPL vereint nicht nur Großprojekte. Eine riesige Menge an Erweiterungen für diese Projekte aber auch viele kleinere, eigenständige Entwicklungen werden unter GPL lizensiert, wobei hier viel öfter kleinere Entwicklerteams oder Einzelentwickler wie Frank Bültge stehen. Und für diese Entwicklungen gilt das oben gesagte leider nicht. Zwei, drei Schritte von den Top-100 der Open-Source-Projekte entfernt ist es mit dem externen Geldregen in der Regel vorbei. Und hierbei spreche nicht vom reich werden, sondern vom notwendigen Lebensunterhalt. Die Mozilla-Entwickler leben genauso wenig von Luft und der ewigen Liebe der Nutzercommunity.

Doch genau dieser Teil von Open Source scheint vielfach ignoriert oder nicht verstanden zu werden. Anders kann ich mir solche Kommentare nicht erklären. Oder nehmen wir folgenden Kommentar:

... So wie Autoren das erste Buch fast verschenken, wird die zweite Auflage teuer an den Mann gebracht.

Kommentar Nr. 45

Das mag ein undurchdachter Spruch eines ahnunglosen Bloggers sein, aber dieser Satz dürfte wirklich jedem Fachbuchautor unter die Haut gehen, denn gegensätzlicher könnten die Mutmaßungen des Kommentarautors und der Realität kaum sein. Frank Bültge hat hierzu übrigens bereits Stellung genommen, klingt dabei aber aus meiner Sicht relativ resignierend.

Doch wo ist der Ausweg? Viele Kommentatoren empfehlen Frank, sich besser zu vermarkten, sein Wissen nicht – für lau – preiszugeben. Und die meisten versichern ganz selbstverständlich, für gute Software auch zu zahlen. Doch geht das überhaupt? Vorrausgesetzt man ist freiberuflich dieser Branche unterwegs, können Veröffentlichungen unter GPL-Lizenz, wie auch Bücher, die perfekte Eigen-PR sein. In diesem Fall entsteht die Entlohnung nämlich nicht direkt über Lizenzeinnahmen sondern indirekt und langfristig über den wachsenen Bekanntheitsgrad und die Reputation in der Community, wodurch man Aufträge aquirieren kann - von deren Entlohnung der Entwickler letztlich seine Miete und die Brötchen bezahlt.

Doch dieser indirekte Weg – und dabei gleichen sich die Umstände bei Frank Bültge und mir – ist bei so manchem Entwickler nur in Ausnahmefällen bzw. gar nicht möglich. Sowohl Frank Bültge als auch ich dürfen uns als so genannte "Freizeitkämpfer" bezeichnen. Wir haben andere, zeitintensive Berufe und tummeln uns mehr oder weniger in unser Freizeit in dieser Branche. Das machen viele, klar, aber nur wenige mit jahrelanger Ausdauer und in der Qualität, wie sie Frank Bültge vorlebt.

Ich selbst stand mit YAML vor knapp 4 Jahren genau vor dieser Entscheidung. Nach ersten Nutzungsanfragen aus dem professionellen Bereich musste eine Entscheidung hinsichtlich einer sinnvollen Lizenz getroffen werden. Ich habe all diese Probleme bereits damals gewälzt und mich mit YAML bewusst gegen die GPL entschieden. Und diese Entscheidung war in den vergangen Jahren immer wieder Grund zahlreicher verbaler Tiefschläge von Leuten, die meine Arbeit nur allzu gern unter GPL (und wohl somit ohne jegliche Gegenleistung) gesehen hätten, die ich hier nicht wieder auffrischen will. Und erstaunlicherweise kamen diese Stimmen vorwiegend aus dem Agenturumfeld.

Ich kann aus heutiger Sicht sagen, dass ich damals richtig entschieden habe und dies auch immer wieder tun würde. Der Weg war nicht gerade frei von Steinen aber letztlich erfolgreich. Ich sehe YAML als Open Source Projekt, denn der bei weitem überwiegende Teil der Downloads geht auf Nutzer, welche das Framework unter der Creative Commons Lizenz einsetzen. Und in diesem Bereich sind durchaus Parallelen zu erkennen. Fachliches Feedback ist extrem selten und hätte ich nicht einige wenige treue Helfer, würde die Weiterentwicklung sehr viel schwieriger sein. Der Supportaufwand, gerade aus diesem Bereich heraus ist jedoch gewaltig. Und Support ist keineswegs ein optionales Gut. Er gehört dazu, ob man will oder nicht. Auch ich hatte über drei Jahre einen kleinen Paypal-Button auf meiner Seite, der in dieser Zeit gerade einmal 35 EUR eingebracht hat. Seit August letzten Jahres ist er deshalb einer Amazon-Wunschliste gewichen - welche sehr viel mehr Akzeptanz bei den Nutzern hat. An dieser Stelle möchte ich mich deshalb bei allen bedanken, die mir über die Wunschliste bereits Freude bereitet haben. Ich versuche auch stets, soweit es die beiliegende Amazon-Rechnung ermöglicht, mich bei den jeweiligen Absendern persönlich zu bedanken. Leider klappt das nicht immer. Deshalb an dieser Stelle stellvertretend mein nochmaliger Dank an alle Spender.

Ich kann und möchte aber nicht sagen, dass Frank mit seiner Entscheidung pro GPL etwas falsch gemacht hätte. Vielmehr gibt es offensichtlich zahlreiche Leute da draußen, die bis heute das Konzept "Open Source" nicht verstanden haben. Open Source war nie als Einbahnstraße gedacht und kann auch so nicht funktionieren und es täte mir leid wenn Leute wie Frank, denen im konkreten Fall die Wordpress-Community viel zu verdanken hat, sich resigniert vom Open Source Gedanken abwenden.


Freitag17. Juli 2009

Einen etwas ausführlicheren Beitrag zu effizientem Code (HTML & CSS) habe ich mir schon lange vorgenommen – dieser hier ist es noch nicht. Dennoch hat mich diese kürzlich erschienene Evaluation der vier bekanntesten CSS-Frameworks zu diesem Beitrag bewogen. YAML ist wohl mit Abstand das komplexeste Framework unter den genannten und bedingt aufgrund seiner Ausrichtung (flexible Layouts) sowie der Vielzahl an Möglichkeiten, Dateien und Beispiele auch eine steilere Lernkurve. Schnell kann dabei der Eindruck entstehen, dass die Komplexität (und die umfangreiche Browserunterstützung) zu einem überbordenden Umfang des Frameworks führen. Also gehe ich dieser These hier mit einem kleinen Vergleich mal auf den Grund und verleiche das CSS-Volumen der Framework-Cores.

Der Framework-Core

Beinahe jedes CSS-Frameworks definiert sich durch so genannte Kernbausteine. Diese stellen die grundlegende Funktionalität bereit und sorgen für deren browserübergreifende Kompatibilität. Neben diesen Kernbausteinen bieten die einzelnen Projekte mal mehr, mal weniger optionale Bausteine an (Navigationsbausteine, Textformatierung, Formulare ect.), um den Entwicklungsprozess über die grobe Layouterstellung hinaus zu erleichtern. Genau in diesem Punkt klafft die Schere zwischen den einzelnen Projekten sehr weit auseinander. Diese optionalen Bausteine erhöhen zwangsläufig für den Einsteiger beim Erstkontakt die Komplexität, berühren aber eigentlich die Kernaufgabe der CSS-Frameworks (die Layouterstellung) nicht wirklich und erschweren die Vergleichbarkeit. Ich konzentriere mich deshalb beim folgenden Vergleich jeweils auf diese Kernbausteine, den so genannten Framework-Core folgender Projekte:

Den gesamten Beitrag lesen


Mittwoch08. Juli 2009

Note: This experiment began with a big portion of irony in mind, regarding CSS frameworks. But then it developed into an interesting exercise on how to code with minimal markup.

Have you ever wanted to work with a streamlined CSS framework? Here it is ...

The source code

revision 1: 109 Bytes

<!DOCTYPE html><head><title></title><style type="text/css">*{color:#000;background:#fff}</style></head><body>

No need for a download link. It even fits in a tweet on Twitter.

Revision 2: 74 Bytes

<!DOCTYPE html><title></title><style>*{color:#000;background:#fff}</style>

This is still a valid HTML 5, crossbrowser compatible document and the framework is still ready to start adding content. With revision 2 we achieve amazing 32 percent saving of markup. The source code fits on a single typewriter line.

10 exciting killer-features

  1. It’s standard compliant and only uses valid code (valid HTML 5)
  2. Completely made without any CSS hacks
  3. It’s prepared for the future by using the latest web technologies (HTML 5)
  4. It has a streamlined source code, no DIV soups or bloated CSS, no optional end-tags.
  5. It has accessibility features (maximum contrast for all elements)
  6. Premium class browser compatibility (IE 3+)
  7. Performance optimized code - only a single HTTP request
  8. No limits for webpage design (allows fixed, elastic or fluid designs and even grids)
  9. Prepared for web 2.0: Just add rounded corners, drop shadows and reflections
  10. It’s free: licensed under Gnu Public License

Many thanks to co-author Tomas Caspers for his help, hard work and contribution to make this web developers dream come true.

UPDATE:  Revision 2 is out with huge markup savings. Thanks to all commenters who helped to fall below the 100 Byte limit.


Montag29. Juni 2009

Ich unterbreche die temporäre Funkstille in diesem Weblog für eine kleine Diskussion, die mir nun schon seit ein paar Wochen auf dem Magen liegt. Irgendwie wird man das Gefühl nicht los, bei HTML & CSS wäre entwicklungstechnisch die Luft raus. Seit Monaten überschlagen sich Online-Magazine für Webdesigner mit Toplisten, in denen bestehende Informationen aus dem Netz nach mehr oder minder sinnvollen Kriterien immer wieder neu zusammengestellt und wiedergekaut werden. Echte Fachartikel mit “a-ha” Effekt sind in diesen Tagen äußerst selten geworden.

Nachdem nun aber auch Toplisten kaum jemand mehr sehen und lesen mag, wird insbesondere bei den zahlreichen Online-Magazinen spürbar, dass es - bedingt durch den quälend langsamen Entwicklungsprozess bei HTML & CSS - ganz offensichtlich nicht mehr viel Neues und Spannendes zu entdecken gibt. Man sucht händeringend nach unverbrauchten Themen und neuen Autoren.

Als vor 14 Tagen bei Dr. Web der umstrittene Beitrag “Hintergrundbilder eindrucksvoll mit CSS skalieren” erschien und der Autor für seine (bzw. die auf der Webseite GOTO CHINA verwendeten Lösung) Viewport-füllende und horizontal + vertikal zentrierte Darstellung einer Hintergrundgrafik doch tatsächlich eine HTML-Tabelle als Grundlage vorsah, war ihm der Proteststurm der CSS-Community sicher. Fast niemand der Kommentatoren hat sich dabei die Mühe gemacht, die vorgestellte Technik vollständig zu verstehen bevor man sie in der Luft zerriss. Denn ganz so trivial wie viele vermuteten, ist sie dann eben doch nicht. Gleichermaßen hat es der Autor versäumt, seine Entscheidung pro Layouttabelle schlüssig zu begründen.

Nun finde ich Layouttabellen alles andere als charmant. Aber ich muss auch zugeben, dass ich eine optisch zu 100% gleichwertige und ebenso robuste Variante auf reiner CSS-Basis – zumindest innerhalb einiger Stunden – nicht präsentieren konnte. Auf der anderen Seite hatte ich jedoch sehr schnell eine alternative Lösung, die ohne Tabellen dem Vorbild sehr nahe kommt und lediglich die vertikale Zentrierung bei sehr kleinem Viewport vermissen lässt. Mein Testcase ist zunächst nur ein Schnellschuss, zeigt aber, dass es auch anders geht.

Nach vielen Jahren der Diskussion um Webstandards wundert es mich dann schon, dass der Autor Adrian Bechtold kein Wort darüber verliert und dadurch die massive Kommentarflut provoziert. Es ist nämlich die Frage, ob – wie im vorgestellten Beispiel – das Ergebnis die Mittel (Layouttabelle) wirklich rechtfertigt. Genau diese Folgediskussion wäre interessant gewesen, doch leider wollten sich hier weder der Autor noch die Kommentatoren darauf einlassen. Das Team von Dr. Web ist gerade dabei ist, dem eigenen Portal neues Leben einzuhauchen. Hier wäre eine Chance gewesen, doch ohne den Bezug zu aktuellen Layouttechniken wirkt der visuell beeindruckende Effekt in der Umsetzung verdammt altbacken.

Und damit kommen wir zum zweiten Fall. Auch das in die Jahre gekommene SelfHTML versucht mit neuen Fachartikeln den Anschluss zu halten. Doch dieser scheint sowohl beim Autor als auch bei der Redaktion bereits in weite Ferne gerückt zu sein. Stein des Anstoßes ist der Beitrag “Benutzerfreundliche Viewportweiche ohne JavaScript”.  Auf dem einstigen deutschsprachigen Aushängeschild, der langjährigen Lernplattform für unzählige angehende Webdesigner veröffentlicht man 2009 invaliden HTML-Code ohne Doctype (invalid selbst nach HTML 4.01 Transitional), mit Layouttabellen, Absatztrennung mit <br><br> und haufenweise Inline-Styles. Das ganze verpackt in einem Thema dessen Relevanz um den Nullpunkt schlingert und mit haarsträubenden Argumenten und Beispielen.

Und als ob das nicht bereits genug wäre, können weder die SelfHTML-Redaktion noch der Autor selbst mit der zwangsläufig aufkommenden Kritik sonderlich gut umgehen. Diese wird vom SelfHTML-Team als das Gemeckere eines “elitär kleinen Zirkel von Semantik-Fetischisten” und vom Autor Martin Suhr selbst als Quatsch eines nörgelnden Misanthropen gekontert. Inhaltlich geht man auf die Kritik natürlich nicht ein. Stattdessen rechtfertigt sich die Redaktion wir folgt:

Wenn ich an alle unsere Artikel, insbesondere an die, die noch zu schreiben sind, die höchsten Qualitätsansprüche stelle, nur um einen elitär kleinen Zirkel von Semantik-Fetischisten zufrieden zu stellen, habe ich keine Autoren mehr, die es überhaupt noch wagen werden, uns irgendwelche Inhalte zu liefern.

Liebes SelfHTML-Team, das ist ein peinliches Armutszeugnis und wenn Ihr das wirklich so seht, wenn euch die Qualität Eurer Artikel egal ist so lange Ihr nur etwas veröffentlichen könnt, dann SelfHTML: Ruhe in Frieden. Oder wie Jens Grochtdreis es in seinem Kommentar treffend formuliert:

Diese Qualitätskontrolle erwarte ich auch bei SELFHTML. Dann sollten keine Codebeispiele Marke “Scheiss egal, was da steht, es geht erstmal ums grobe Prinzip” veröffentlicht werden.

Der nächste Entwickler, dem ich dann versuche seinen Tabellenlayouts auszureden, erzählt mir dann, daß er das bei SELFHTML gelesen hat. Und das müsse ja dann wahr sein.

Und wenn Du keine Qualitätsansprüche an Deine Publikation stellen willst, dann tut es mir um das ehemals richtig gute SELFHTML sehr leid. Dann ist es wohl wirklich an der Zeit, von diesem netten und informativen Dino Abschied zu nehmen. Die Referenzen von Sitepoint sind auf dem neuesten Stand und kommen ohne Tabellenlayouts aus.

In diesem Sinne, das war’s, was ich kurz anmerken wollte. Was meint Ihr?


Donnerstag18. Juni 2009

Fast auf den Tag genau vor einem Jahr habe ich bei Dr. Web und im Smashing Magazine einen längeren Essay über “Flexible Layouts als die Herausforderung der Zukunft” veröffentlicht.

Schon damals – lange bevor mit dem IE8 und dem Safari 4 die letzten beiden Browsergrößen auf den Seitenzoom-Zug aufsprungen – war ich der Meinung, dass die von Opera 9 und Firefox 3 eingeführte Technik nicht das Allheilmittel für die zahlreichen Limitierungen pixelbasierter Layouts, bzw. der Sargnagel für flexible Layouts sein wird und hatte dies in den beiden Artikeln mit der immer weiter aufklaffenden Schere von Bildschirmauflösungen und der verstärkten Nutzung von Smartphones und Netbooks begründet. Seinerzeit entbrannte eine heiße Diskussion, danach war aber eigentlich die Luft raus und kaum jemand widmete sich mehr diesem Thema.

Umso erstaunter war ich heute über drei aktuelle, englischsprachige Beiträge (Danke Angar, für den Hinweis), die sich erneut dem Thema widmen und weitere gute Argumente für elastische und fluide (oder allg. flexible) Layouts liefern.

Der Beitrag auf 456bereastreet.com bringt ein sehr interessantes Argument: die Mehrsprachigkeit. Allein aufgrund der Sprache, in der Inhalte ausgegeben werden, verändert sich die Textmenge, bzw. deren Platzbedarf. Flexible Layouts können sich hier deutlich besser anpassen als fixe Konstrukte. Der Beitrag von Zoe Mickley Gillenwater geht noch deutlich tiefer ins Detail und bringt sechs weitere, gut durchdachte Argumente pro elastischem bzw. flexiblen Layout. Besonders interessant dabei ist der Punkt “Preserve design proportions”. Genau dies wird aktuell sehr gern als Grund angeführt, warum elastische Layouts in Zeiten eines funktionierenden Seitenzooms praktisch keine Relevanz mehr hätten (noch dazu, da sie sehr aufwändig in der Erstellung seien). Das überzeugende Argument pro elastischem Layout ist wieder einmal der User mit seiner Möglichkeit, die Standardschriftgröße seines Browsers/Betriebssystems beliebig nach oben oder unten anzupassen. Ein fixes Layout - Seitenzoom hin oder her - kann sich derartigen Gegebenheiten nicht anpassen, die Laufweiten der Texte ändern sich zwangsläufig und die schönste Typografie kann den Bach runter gehen.

Ich möchte hier nicht alle Punkte wiederholen. Die Beiträge sind hervorragend geschrieben, also lest selbst. Der sehr schön formulierten Zusammenfassung von Zoe Mickley Gillenwater schließe ich mich hiermit aus ganzem Herzen an.

Again, I have to stress that zooming is a great function for browsers to include. Also, fixed-width layouts are not evil—they are ideal in certain situations. But liquid and elastic layouts have a lot of benefits that fixed-width layouts in combination with browser zoom can’t necessarily match. ... Don’t use browser zooming as a reason to stop—or never start—making flexible layouts.

“Why browser zoom shouldn’t kill flexible layouts”, Zoe Mickley Gillenwater


Seite 11 von 44 Seiten

« Erste  <  9 10 11 12 13 >  Letzte »