miradlo.com Auflösungen testen

In den letzten Wochen habe ich mich intensiver mit Responsive Webdesign befasst. Hierbei geht darum, die Inhalte einer Seite möglichst optimal für alle Geräte darzustellen. Egal ob mobiles Smartphone oder großer Monitor mit hoher Auflösung alle Nutzer sollen ein Layout finden, was zu ihrem gerade genutzten Gerät passt. Beim Barcamp Stuttgart habe ich am Samstag eine Session zu diesem Thema angeboten, dieser Beitrag enthält die Links und Infos hierzu.

Die Techniken im Hintergrund sind gar nicht so neu, vorgestellt wurde CSS 3 schon vor einigen Jahren. Sinnvoll einsetzbar wurde diese Möglichkeiten jedoch erst seit sie von den wichtigsten Browsern auch interpretiert wurden. Für mobile Geräte konnte man zunächst mittels media="handheld" ein anderes Layout festlegen, Geräte wie das iphone melden sich jedoch gar nicht als handheld und bekamen daher doch wieder dasselbe Design wie Nutzer mit großen Desktopmonitoren.

media queries je nach Auflösung

Mittels media queries aus CSS 3 wird ein Layout je nach Auflösung ausgegeben. Zunächst habe ich ein Layout erstellt wie es in meiner Arbeitsumgebung optimal passt. Mein erster Schritt war also das Layout für eine hohe Auflösung wie z.B. 1920 * 1080 Pixel anzulegen. Danach probierte ich immer kleiner werdende Auflösungen und sobald mir etwas nicht gefiel, passte ich es an. Das habe ich so lange gemacht bis ich eine weitere Verkleinerung nicht mehr für sinnvoll hielt, sprich bei weniger als 300 px Breite erzwinge ich einen Scrollbalken, Beispiel:

@media only screen and (max-width: 429px) {
#mainwrapper{
    min-width: 270px;
}
}

Genauer ansehen könnt ihr euch das CSS layout.css im unteren Teil von der Seite miradlo.com. Testen lassen sich Seiten:

• screenfly dort werden diverse Auflösungen je nach Gerät angezeigt, einfach die URL eingeben, z.B: miradlo.com
• Responsive Webdesign Testing zeigt direkt mehrere Auflösungen auf einen Blick, auch hier einfach die URL eingeben, z.B: miradlo.com

Responsive Webdesign vs. Apps

Ich halte diese Technik insbesondere für sehr sinnvoll. Damit werden weiterhin dieselben Inhalte auf allen Geräten ausgegeben und trotzdem wird das Design angepasst. Für große Seitenbetreiber, wie wikipedia können auch Apps für iphone, android usw. eingesetzt werden, um mobile Versionen zu nutzen. Bei der Mehrzahl aller Websites ist das jedoch nicht sinnvoll und meist auch finanziell nicht machbar. Plugins wie für WordPress die eine mobile Variante erstellen sind sicher oft besser als nichts, sie zeigen jedoch nicht mehr das Ursprungsdesign der jeweiligen Seite. Responsive Webdesign ist eine gute Lösung für viele Seiten und der Aufwand ist nicht so viel höher wie beim Erstellen einer App.

Je nach Design lässt sich das auch im Nachhinein noch relativ einfach anpassen, das klappt jedoch sicher nicht immer. Das gesamte Design muss mit flexiblen Breiten zurecht kommen. Die einzelnen div-Container müssen problemlos verschiebbar sein, sonst lohnt sich das nicht. Einige weitere Links zu diesem Thema:

• Responsive Webdesign – Verschiedene Devices simulieren und testen
• Responsive Webdesign: Umfangreiche Präsentation mit Tipps und Tricks
• Responsive Webdesign mit CSS3 Media Queries: So funktioniert’s

@font-face auf uteles Blog

So ganz allmählich lassen sich Schriftarten sinnvoll einsetzen, die nicht auf dem Rechner des jeweiligen Nutzers installiert sind.  Es gibt viele freie Schriften, die dafür genutzt werden können, jedoch für deutschsprachige Blogs eignen sich nicht alle.

uteles Blog als erste Testecke, siehe Screenshot.

Um einen Überblick über die Schriften zu haben und weil ich eine eigene Auswahl aus Schriften mit Umlauten wollte, habe ich mir eine eigene Seite für Schriften angelegt. Vorsicht, es dauert einen Moment bis die Seite vollständig geladen ist (eher nicht mobil geeignet): http://www.miradlo.info/schriften/

Es gibt Browser – insbesondere manche ältere Browser – die die Schriften nicht darstellen können. Für die Schriftenseite ist das natürlich ungeschickt, aber für den Alltagseinsatz ist es kein Problem, denn mit Angabe von Alternativschriften wird alles korrekt angezeigt, nur eben nicht so hübsch.

@font-face

Die Einbindung der Schriften, die dann vom jeweilien Browser runtergeladen und angezeigt werden, mache ich mit @font-face im CSS. Im Internet Explorer sollte es wohl bereits ab IE 6 klappen, zumindest bei meinen Tests. Aktuelle Browserversionen von Opera, Safari, Chrome usw. kommen gut damit zurecht, der Firefox kann es seit Version 3.5. Der Konqueror mag bei mir nicht, obwohl ich die Einbindung so mache wie auch empfohlen. Unterm Strich sind die Schriften für mich ein zusätzlicher Hingucker, schön wenn es angezeigt wird, aber wenn es halt mal nicht klappt ist es auch nicht schlimm.

Ladezeit für Schriften

Auf einem üblichen Rechner mit DSL fällt es kaum auf und durch Angabe etwaige bereits vorhandener Systemschriften muss auch nicht in jedem Fall die Schrift geholt werden. Der Browser speichert die Schriften, damit ist es schlimmstenfalls beim ersten Aufruf nötig die Schriften zu holen. Für den üblichen Webeinsatz spricht also nichts dagegen es zu nutzen.

Mobile Geräte

uteles Blog brauchte im explizit abgewählten mobile-Theme auf dem iphone im lokalen Netz rund 3 Sekunden, mit ein bissel weniger starkem Zugang ist das dann keine so gute Idee. Sprich beim Einsatz im Alltag wäre es sinnvoll mobile Themes anzubieten, die ohne die speziellen Schriften auskommen.

Freie Schriften und Umlaute

font-squirrel bietet eine große Auswahl und eine Schrift kann mit einem Kit runtergeladen werden, mit dem die Einbindung dann recht einfach klappt, siehe auch: @font-face-Tipp
Leider ist in der Übersicht nicht erkennbar, ob eine Schrift mit Umlauten zurecht kommt, das lässt sich mit dem Testdings probieren, da wird angezeigt, was man eingibt. Es gab einige Schriften, die mir gut gefallen haben, die jedoch deshalb nicht in Frage kommen, weil sie keine Umlaute darstellen. Die ein oder andere, die ich jetzt mit eingebunden habe, kommt mit dem “ß” nicht zurecht. Je nach Einsatzzweck, kann das für Überschriften jedoch trotzdem noch akzeptabel sein. Keine Umlaute sind dagegen ein klares no-go.

Effekte und Probleme

Einige Schriften sind sehr verspielt und damit schwer lesbar, aber für spezielle Überschrifteneffekte oder andere spezielle Ansichten ist das ja durchaus mal akzeptabel. Die ein oder andere Schrift bietet nicht alle Font-Formatierungen an, die CSS an sich kennt. Teils übernimmt dann der Browser die Darstellung, das klappt nicht überall so hübsch, wie bei Schriften, die selbst einen fetten oder kursiven Stil anbieten.

Alles wird gut

Noch ist nicht alles gut, ein Browser ist nach wie vor keine Textverarbeitung mit allen Möglichkeiten von Schriften. Aber aus meiner Sicht ist es ein großer Schritt weg von Webseiten, die nur mit den paar üblichen Schriften auskommen müssen, die bislang im Web einigermaßen übergreifend unterstützt wurden. Was mir gut gefällt ist das problemlose Fallback auf Alternativen und dass eine Schrift nicht jedesmal runtergeladen werden muss. Ein klarer Vorteil für Stammleser einer Seite. Wenn sich die Schriften verbreiten, wird es auch seltener, dass eine Schrift noch nicht installiert ist.

Es ist noch nicht alles gut, es braucht noch intensives Testen im Umgang damit, aber ich bin fürs Erste völlig zufrieden, dass es jetzt einen Weg gibt, der ohne Flash, Bilder oder sonstige Krücken auskommt um eine besondere Schrift anzubieten.

Unlesbare Navigation

Teaserinfos laufen in- und übereinander

Fast auf allen Seiten, auch auf ordentlich sauber mit HTML und CSS erstellten, passen die Formularelemente mit meinen Einstellungen nicht.

Ein Klick auf die Bilder führt zur vergrößerten Ansicht.

Benutzerdefinierte Mindestschriftgröße

Einerseits habe ich seit Jahren in dem Browser, den ich normalerweise nutze, eine Mindestschriftgröße eingestellt, weil ich sonst auf sehr vielen Seiten, schlicht nichts lesen kann. Hinzu kommt, dass selbst damit inzwischen viele Seiten eine derart schicke, Minischrift haben, dass ich erneut die Schrift vergrößern muss.

Einfach wäre die Mindestschriftgröße erneut höher zu setzen, doch das geht leider nicht, denn spätestens bei Seiten mit Formularen, sind damit nur noch sehr wenige überhaupt nutzbar. Oft komme ich nicht mal soweit, weil schon vorher die Benutzung nicht mehr klappt:

• Insbesondere horizontale Navigationen werden meist schlicht auf eine vordefinierte Schriftgröße festgezurrt und werden unlesbar, wenn die Schriftgröße erhöht wird, z.B. stern.de
• Zusammenstellungen wie in vielen Teasern und anderen Bereichen, die Aufmerksamkeit wecken sollen laufen völlig in- und übereinander z.B. auf suedkurier.de

• Beschriftung der Eingabefelder unlesbar
• Eingabefelder zu klein

Schriftgrößen insbesondere in Formularen und so

Häufig sind Formularelemente mit fixen Werten vordefiniert, wenn ich also die Schriftgröße so setze, wie ich es bequem lesen kann, dann kann ich wichtige zusätzliche Infos nicht mehr lesen:

• Eingabefelder sind zu klein um den gesamten geforderten Inhalt lesbar anzuzeigen (Deutsche Bank)
• Beschriftung der Eingabefelder unlesbar, bzw. kann sogar ganz verschwinden (suedkurier.de)

Die Konsequenz ist bei mir ein Mischsystem:

• eine Mindestschriftgröße die für manche Seiten passt
• erhöhen der Schriftgröße, wenn ich etwas lesen will
• verringern der Schriftgröße, um Bedienungselemente nutzen zu können

Überflüssig und ärgerlich

Schade, dass nur für schicke Optik so häufig auf zugängliche, nach Webstandards erstellte Seiten verzichtet wird. Das Web ist von seinen Grundlagen her optimal geeignet solche Probleme zu vermeiden und es den Nutzern zu überlassen, welche Einstellungen ihren Bedürfnissen entsprechen. Doch leider gibt es noch immer viel zu viele Designer, die Webseiten entwerfen, als sei es Papier.

Dazu passt die unsägliche Schriftgrößenumrechnung, die pixelgenau und berechenbar sein soll: den Mythos der 62,5% erklärt toscho in einfachen Worten.

Ich wünsche mir, wie viele andere, dass der Unsinn – Papierlayouts im Web 1:1 abzubilden – aufhört. Eine Initiative dazu ist der Blue Beanie Day, siehe: Blaue Mützen : Blue Beanie : 30.11.2010 Webstandards

PS: Falls jemand meint ich solle mal einen Optiker aufsuchen, ja das habe ich getan, ich habe eine Brille für die Ferne und eine Lesebrille, keine von beiden hilft mir am Bildschirm.

• Blue Beanie Tag

Am Dienstag den 30. November ist also wieder Zeit für die blauen Mützen… Worum es geht? Webstandards und Zugänglichkeit (Accessibility) sollen ins Bewußtsein gerückt werden.

Ebenso wie in den letzten Jahren las ich den Aufruf zum Blue Beanie Day zuerst bei Robert.

Was ich letztes Jahr Blaue Mützen : Blue Beanie : Webstandards : Adventskalender schon schrieb, gilt auch heute noch, meine Wunschliste zu Webstandards:

• Inhalte sind wichtig und sollten für alle zugänglich sein (kleines zartgrau auf weiß ist keine lesbare Schrift)
• Grafische Captchas behindern alle Nutzer
• Flash ist kein Designelement (als Navigation ist Flash immer falsch und auch sonst wird Flash oft überflüssigerweise eingesetzt)
• Formularelemente sollen mitwachsen je nach gewählter Schriftgröße (ich nutze eine Mindestschriftgröße und kann oft Formulare nicht nutzen, weil die Felder zu klein bemessen sind)
• valides HTML und CSS tun nicht weh und sind eine Grundlage für bessere Seiten für alle Nutzer

Blue Beanie Tag

Heute ist Blue Beanie Tag, zuerst las ich bei Robert davon, auch t3n berichtet darüber, es gibt eine facebook-Gruppe. Worum es geht?  Webstandards sollen ins Bewußtsein gerückt werden.

Eine weitere Idee ist: Fünf Sätze zu diesem Thema zu formulieren, die für einen selbst wichtig erscheinen um Webstandards voran zu bringen.

Meine Wunschliste zu Webstandards

• Inhalte sind wichtig und sollten für alle zugänglich sein (kleines zartgrau auf weiß ist keine lesbare Schrift)
• Flash ist kein Designelement (als Navigation ist Flash immer falsch und auch sonst wird Flash oft überflüssigerweise eingesetzt)
• Grafische Captchas behindern alle Nutzer
• Formularelemente sollen ebenfalls mitwachsen je nach gewählter Schriftgröße (ich nutze eine Mindestschriftgröße und kann oft Formulare nicht nutzen, weil die Felder zu klein bemessen sind)
• valides HTML und CSS tun nicht weh und sind eine Grundlage für bessere Seiten für alle Nutzer

Aprospos Webstandards

• Adventskalender Webkrauts

Inzwischen schon traditionell der Adventskalender der Webkrauts . Ab dem 1.12. gibt es wieder täglich einen Beitrag rundum Webstandards von wechselnden Autoren der Webkrauts. Ich bin sicher auch dieses Jahr wieder lesenswert.

Beim nächsten Mal installierte ich erstmals ernsthaft lokal, mit den Daten, die dann live auch genutzt werden sollen. Ich nahm die fortgeschrittene Installation, um auch gleich mal genauer zu sehen, was sich so einstellen lässt, da S9y für mich ja noch neu ist.

Schritt für Schritt änderte ich die Rechte, um auch da gleich zu testen, ob Serendipity da alle Probleme anzeigt. Bis zum Ende der Installation und dem Hinweis alles habe geklappt lief es problemlos.

• Adminbereich eines Redakteurs bei S9y

Doch dann…

Erster Aufruf des neuen Blogs

Ups, tja nur weil da keine Warnungen waren, war es wohl doch übertrieben direkt Umlaute zu nutzen. Ein abgeschnittener Blogtitel und ein ebenso beschnittener Untertitel sehen schon mal nicht so hübsch aus.

Auf der Seite gibt’s ein Login, nette Idee, mal sehen was sich da versteckt, denn das Forum empfiehlt bei Umlautproblemen den Titel erneut zu setzen.

Huch, “/serendipity/admin die Seite kann nicht gefunden werden“, hm, das ist ein bisschen unpraktisch, denn alle Tipps basieren darauf, erstmal im Admin irgendwas anzupassen. Ein bisschen recherchieren bringt wenig, denn der Admin-Benutzername war schon frei von Umlauten und auch bei erneutem Setzen mittels einer extra erstellten recover.php ändert sich nichts.

Also gut, dann nochmal in die Schritt-für-Schritt-Doku schauen und da mal genauer lesen und prüfen:

“…You can do that by calling your URL http://yourdomain.com/serendipity/serendipity_admin.php” Hm, wie jetzt serendipity_admin.php? Nun gut, die hätte den Vorzug, dass sie existiert, denn mir war schon klar, dass /admin nicht klappen konnte, weil es nicht vorhanden war, allerdings wusste ich ja nicht, ob da nicht beim Installieren versehentlich was nicht angelegt wurde.

Juhu, ein Erfolg: serendipity_admin.php lässt sich aufrufen und sieht aus wie eine Adminoberfläche, wenn auch ohne jedwedes Styling, das war beim ersten Testen noch anders… Na denn, weiter geht’s…

Admin ohne Styles

Keine Ahnung was ich falsch gemacht habe, aber mein Adminbereich lässt sich nicht nur nicht per Link aufrufen, er findet auch die CSS-Dateien nicht… Klar, gut ist, dass er trotzdem nutzbar ist, aber so ganz ohne Styles ist es schon sehr spartanisch.

Die nächste Installation

Bei einer weiteren Installation nahm ich nicht die fortgeschrittene, sondern die einfache Variante, da ich vermutete, dass irgendeine Einstellung schuld war, am Problem der fehlenden Styles. Stimmte auch, denn mit der einfachen Variante hatte der Admin Styles und auch das Login klappte wie gewünschte über die Blog-Oberfläche.

Allerdings auch hier gab’s wieder das Umlautproblem, trotz angegebener Sprache Deutsch fraß s9y alles ab einem Umlaut. In den Einstellungen läßt sich das zwar wieder ändern, aber es stört schon.

Einstellungen

Ich würde ja erwarten, dass ein bereits gespeichertes Passwort und eingeloggt sein ausreicht, aber das stimmt so nicht. Bei den eigenen Einstellungen läßt sich auch das Passwort ändern, falls man etwas anderes ändern will, muss trotzdem das Passwort zweimal angegeben werden, sonst beschließt Serendipity, dass das keine korrekte Eingabe war, löscht alles Eingegebene und beschwert sich übers fehlende Passwort.

Ignoriert wird zunächst alles ab einem Umlaut und auch die Sprachangabe deutsch führt nicht dazu, dass das bereits eingestellt ist, sondern muss in den persönlichen Einstellungen wiederholt werden.

Administration | Konfiguration | Generelle Einstellungen

Na bravo, hier wollte ich den – schon gewohnt gefressenen – Blogtitel mit Umlauten einstellen.

->  Seite wählen -> Blogtitel ändern -> Speichern -> alle Umlaute kaputt und Titel mit kaputten Umlauten

nächster Versuch:
->  Seite wählen -> Blogtitel ändern -> Zeichensatz ändern -> Speichern -> alle Umlaute doppelt kaputt und Titel ebenfalls mit kaputten Umlauten

ein weitererVersuch:
->  Seite wählen -> Blogtitel ändern -> Zeichensatz ändern wieder UTF8 -> Speichern -> alle Umlaute weiter kaputt und Titel wieder abgeschnitten

noch ein Versuch:
->  Seite wählen -> Blogtitel ändern -> Zeichensatz nicht ändern -> Speichern -> alle Umlaute weiter kaputt aber Titel stimmt

weiter geht’s:
-> Autorennamen wieder reparieren  -> Kategorien mit Umlauten wieder reparieren -> neuen Beitrag schreiben -> alte Beiträge reparieren

Taraa, tröööt, jubelnde Webentwicklerin und überhaupt…

Ja, dieses Mal klappt es und scheint jetzt ok. Nochmal testen, ob sich der Blogtitel jetzt nochmal ändern lässt und sich alles auflöst:

Nein, dieses Mal bleibt alles soweit ok.

Was lerne ich daraus?

Zunächst einmal, dass es wohl nur mit der einfachen Installation sinnvoll ist. Wie ich inzwischen weiß, wird bei der fortgeschrittenen Installation nichts angegeben, was sich nicht nachher noch ändern ließe. Nachträgliches Ändern hat den Vorzug, dass ich immerhin weiß an welcher Ecke ich was eingestellt habe, was S9y nicht mag.

Beim vierten oder fünften  Versuch stellte ich während des Testens dann auch fest, dass es einen Zusammenhang zwischen einem Adminbereich ohne Styles und einigen Themes besteht, die plötzlich auch keine Styles mehr hatten.

Admin ohne Design und manche Themes funktionieren nicht

Also ging ich mal an die Stellen, die mir verdächtig erschienen und verglich Einstellung für Einstellung der Installationen. Pfade und so waren in Ordnung, aber da gab’s einen Unterschied, der mir schon wahrscheinlich erschien und der auch reproduzierbar den Fehler zeigt:

• URL-Formung hat drei Alternativen
  • Disable URL Rewriting
  • Use Apache errorhandling
  • Use Apache mod_rewrite

Die Einstellung bei einfacher Installation ist Disable, ich hatte wegen etwaiger Pfade und hübscher URLs mod_rewrite eingestellt, vielleicht würde das auf dem Server sogar klappen, denn lokal gibt es meist Schwierigkeiten beim Umschreiben. Jedenfalls kann ich auch bei anderen Installationen den Fehler erzeugen, wenn ich auf mod_rewrite umschalte und das Problem ist weg, wenn ich es anlasse.

Benutzergruppen

Wenn solch eine harmlos aussehende Drop-Down-Box solche Auswirkungen hat, dann fällt mir direkt ein, dass es doch gut wäre die Benutzerrechte einzuschränken. Hier war ich dann sehr angetan, denn wie das Bild zeigt, es gibt eine Rolle, die wirklich nur anzeigt, was jemand zum Schreiben braucht und nicht mit unzähligen Konfigurationsmöglichkeiten überfordert. Einstellbar einfach beim Benutzer anlegen mittels zuweisen der Rolle Redakteur z.B.

Als nächstes gehe ich dann morgen mal suchen, wie ich dem WYSIWYG-Editor abgewöhne die Option der Schriftartänderung anzuzeigen…

Ich habe heute in der Linkliste auf zwei Beiträge zu flexiblen Layouts hingewiesen.

• Flexible Layouts haben ihre Vorzüge, trotz Seitenzoom der Browser
• Ein weiterer Artikel meint es wäre gut nicht über die flexiblen Layouts zu streiten, sondern sie schlicht als Variante zu sehen.
• In obigem Artikel wird auf mehrere Videos zu YAML verlinkt, die gibt es auch als eine Präsentation, direkt bei Galileo

onli kommentierte daraufhin recht ausführlich. Beim Schreiben meiner Antwort fiel mir auf, dass es ein bisschen lang wird, deshalb jetzt als eigenen Artikel. onli schrieb:

“Ich bin über die Diskussionen über flexible Layouts immer wieder überrascht. Denn eigentlich führt die Diskussion am Thema vorbei. Das eigentliche Problem dürfte sein, dass CSS in derzeitiger Form ungeeignet ist für das, was ein dynamisches Layout erfordert. Man kann viele Dinge einfach nicht zuverlässig erreichen, die nötig wären: Elementen eine dynamische Größe zuordnen, aber mehreren Elementen immer die gleiche. Nachbarbeziehungen, die über ein float hinausgehen usw usf. Sicher, ich bin kein Profi, aber es scheint mir so, als sei die Ursache der Diskussion dergestalt, dass einige notwendige Layoutanforderungen mit dynamischen Layouts nicht oder nur schwer umsetzbar sind. Die Antwort sind dann aber nicht pixelgenaue Layouts, sondern Verbesserungen am Handwerkszeug.

Ich werde mir bei Gelegenheit die verlinkten Videos anschauen, vielleicht beinhalten diese ja Konzepte, die meine obige Argumentation ad absurdum führt, weil damit dann alles so umsetzbar ist wie ich es mir vorstelle. “

Ich habe ja schon mal recht ausführlich über flexible Layouts geschrieben, ein paar Bildbeispiele wie sich flexible Layouts auswirken habe ich anlässlich eines Wechsels des Hintergrunds mal beschrieben.

Meines Erachtens sind flexible Layouts nicht schwierig, wenn man von vorne herein flexibel denkt. Das Hauptproblem ist, dass ein Design auf Papier in fester Größe entworfen wird und dann eben häufig auch nicht mehr so einfach flexibel umgesetzt werden kann.

Design bedeutet häufig, es ist ein Entwurf eines Designers, der gestern einen Flyer in A5 entwarf, morgen ein Plakat in A0 und deshalb heute beim Entwurf einer Webseite in 1024*768 denkt. Solche Entwürfe können sehr schwierig umzusetzen sein und sind oft auch nicht flexibel lösbar.

Für mich ist jedoch die Grundlage des Webs, dass ich eben nicht weiß, welches System, welche Auflösung mein Nutzer gerade verwendet, dass ich nicht weiß, ob er Schriftgrößen ändert und und und.

Ich versuche deshalb Layouts von vorne herein so zu erstellen, dass es nicht wichtig ist,welche Voraussetzungen gegeben sind. Leider ist die Tendenz jedoch nach wie vor, das Optimieren auf eine Auflösung und nicht das Erstellen eines anpassungsfähigen Layouts.

Yaml von Dirk Jesse auf das sich die Videos beziehen ist ein Framework, was den Webautoren schon vieles abnimmt. Enthalten sind in Yaml bereits Definitionen um Browserfehler zu umgehen. Es gibt z.B. auch WordPress-Yaml-Themes, die sich recht einfach anpassen lassen, weil vieles eben bereits berücksichtigt wurde. Der Nachteil ist offensichtlich, ein Framework muss alles berücksichtigen und ist deshalb schon ein dickeres Ding.

Ich selbst nutze natürlich auch Vorlagen und fange nicht bei jedem Layout bei 0 an, aber ich nutze kein Framework. Für meine eigen Layouts kenne ich mittlerweile den größten Teil der möglichen Probleme und ihre Lösung.

Im Gegensatz zu fast allen Designern entwerfe ich Layouts nicht auf Papier, auch nicht in einem Bildbearbeitungsprogramm, sondern wirklich live auf einer Testseite. Ich sehe so viel schneller, welche Idee problematisch werden könnte und überlege mir Alternativen, noch bevor das erste Layout fertig ist.

Ist CSS ungeeignet für Layouts?

onli überlegt, ob CSS nicht einfach ungeeignet ist und sich das Handwerkszeug verbessern müsste. Nein, das glaube ich nicht. Das Hauptproblem bei CSS-Layouts ohne Tabellen und in modernem Design ist nicht das CSS. Die Realisierung für standardkonforme Browser wie Firefox, Opera, Safari usw. die ist nicht so schwierig. Es kommt selten vor, dass es spezielle Anpassungen braucht, um ein Layout für diese Browser wie gewünscht zu realisieren. Das eigentliche Problem sind die alten Versionen der Internet Explorer und leider in manchen Fällen sogar der aktuelle IE8.

Manches ist irgendwann bekannt und lässt sich recht schnell auch für die IEs anpassen. Aber immer mal wieder passiert es, dass wegen eines IE-Fehlers Stunden drauf gehen, um eine Lösung zu finden. Microsoft möchte, dass jeder ihrer Browser auch die Seiten korrekt darstellt, die für eine fehlerhafte Vorgängerversion optimiert wurden. Dabei entstehen immer wieder Probleme und noch hat jede IE-Version teils haarsträubende Fehler. Das kommt zwar auch bei anderen Browsern mal vor, nur falls Firefox 2.14 etwas falsch darstellt, dann ist es das heute beim Stand von Firefox 3 nicht so schlimm, denn nur wenige nutzen aktuell diese eine Version, wenn ein Layout trotzdem lesbar bleibt, käme kaum ein Webautor auf die Idee, wegen dieser einen Version etwas zu ändern. Beim IE hält eine Version “ewig” der immer noch stark verbreitete IE6 ist aus dem Jahr 2001, da gab es noch gar keinen Firefox…

Was ist die Lösung für dynamische Layouts?

Die eine ultimative Lösung gibt es nicht. Denn ein modernes Layout mit dem Anspruch das zu zeigen, was heute Stand der Technik ist, das passt zu modernen Browsern. Der IE6 kommt aus einer Zeit als ganz andere Designs entworfen wurden, für die Layouts seiner Zeit war er auch kein Traum, aber noch akzeptabel. Für heutige Layouts ist er einfach ungeeignet und das führt dazu, dass es sehr aufwändig wird, wenn ein besonderes, aktuelles Design umgesetzt werden soll.

Meine Layouts, die nicht darauf aufbauen, dass sie pixelgenaue Linienführungen haben, lassen sich schon deshalb viel einfacher umsetzen. Außerdem habe ich nicht den Anspruch, dass ein Layout in jedem Browser absolut identisch aussieht. Für mich genügt es, wenn alles lesbar ist und die Optik nicht völlig verschoben. Wenn der IE6 das “miradlo bloggt”-Bildle nicht genauso darstellt wie alle anderen, dann ist mir das egal, es ist nicht so hübsch, aber auch nicht kaputt, ich höre an dieser Stelle auf und bastele dann nicht noch Stunden weiter, um mit Tricks und Schlichen eine identische Optik zu bekommen.

Wozu auch? Denn mein sich anpassendes Layout sieht je nach Auflösung sowieso immer ein bisschen anders aus. Für mich ist es wichtig, dass Besucher in etwa ein Design bekommen, was aktuell ist, dass alles lesbar und bedienbar ist und möglichst wenig Scrollbalken hat. Dieses Ziel lässt sich mit CSS und flexiblen Layouts recht gut erreichen.

Manches lässt sich nicht dynamisch und zuverlässig erreichen?

onli fragt sich, ob nicht einfach was fehlt um zuverlässig z.B. Elementen eine dynamische Größe zuzuordnen, aber mehreren Elementen dabei immer die gleiche.

Auch das fällt für mich unter Browserprobleme. Es ist mit standardkonformen Browsern durchaus möglich solche Anforderungen zu erfüllen. Die Grenze dessen ist vor allem der IE6. Für mich kein Grund das nicht zu nutzen, denn ich mag die speziellen Stylesheets die per Conditional Comments z.B. nur genau dem IE6 sagen, was er zu tun hat. Damit bekommt der IE6 dann eben etwas was nicht so flexibel ist, aber für einen Browser der so alt ist, kann ich damit leben.

Falsch finde ich etwas nicht zu nutzen, nur weil der IE6 es nicht kann. Ebenso überflüssig finde ich es Tage in eine Lösung für den IE6 zu investieren, nur um irgendwas auch da noch hinzubekommen. Allerdings halte ich auch nichts davon, “das Kind mit dem Bad auszuschütten” und dem IE6 einfach gar kein Layout und Warnhinweise zu geben. Die Nutzer eines IE6 nehmen ihn entweder, weil er ihnen am Arbeitsplatz vorgeschrieben wird oder weil sie nicht in der Lage oder bereit sind einen anderen Browser zu installieren.

Insgesamt meine ich geht es um genau zwei Punkte:

• Das Web ist nicht aus Papier, ein Layout sollte daher nicht für “welche Auflösung auch immer” optimiert werden
• Eine Webseite muss nicht in jeder Umgebung identisch aussehen

Berücksichtigt man das, dann gibt es kein Problem mit flexiblen Layouts, so einfach ist das.

RGB Cheat Sheet

Spickzettel haben ja zunächst einmal den Ruf ein Betrugsversuch zu sein, z.B. in der Schule. Doch es gibt ja verschiedene Formen etwas zu lernen, sich etwas zu merken oder sich in etwas einzuarbeiten. Ich hatte zu Schul- und Studienzeiten eine Vorliebe für Spickzettel.

Bei mir entstanden sie nach und nach. Zunächst hatte ich meine Aufschriebe zu einem Thema, meist aus recht vielen Seiten bestehend. Die erste Zusammenfassung bestand für eine Abschlussprüfung immernoch aus mehreren DIN-A4-Seiten. Bei jedem weiteren Durchgang wurde das weniger, am Ende gab es für jedes Prüfungsfach nur noch maximal eine Seite. Dort standen nur noch die wichtigsten Punkte des Themas und  in wenigen Stichwörtern, was ich mir ganz schwer merken konnte.

In den letzten Tagen vor einer Prüfung hingen diese Spickzettel entweder an Stellen, die ich mehrfach täglich sah, oder ich hatte sie im Hosensack. Jedenfalls sorgte ich dafür mir diesen einen Spickzettel immer wieder durchzulesen, irgendwann diesen nur noch im Kopf durchzugehen und nur nachzuschauen, wenn ich unsicher wurde. So gelang es mir auch auswendig zu Lernendes am Prüfungstag präsent zu haben, etwas was mir eher schwer fällt.

Bis heute finde ich Spickzettel praktisch, wenn ich mich in etwas neu einlerne. Je nach Thema gehe ich noch immer ähnlich vor. Allerdings schreibe ich nicht mehr alles selbst, denn beispielsweise die RGB-Farben im Bild sind sinnvoller, wenn auch die Farben dabei sind. Für vieles gibt es bereits Spickzettel, die je nach eigener Vorliebe ausgedruckt auf Papier oder elektronisch auf dem Rechner liegen können. Im Englischen heißen Spickzettel Cheat-Sheets. Die beste Auswahl quer durch einiges aus dem Webumfeld gibt es meines Erachtens bei Dave Child. Er bietet folgende Cheat-Sheets an:

• ASP / VBScript
• CSS (V1)
• CSS (V2)
• HTML Character Entities
• HTML
• JavaScript
• Microformats
• mod_rewrite (V1)
• mod_rewrite (V2)
• MySQL
• PHP (V1)
• PHP (V2)
• Python
• Regular Expressions (V1)
• Regular Expressions (V2)
• RGB Hex Colour Chart
• Ruby on Rails
• SQL Server
• Subversion

Für die meisten (ich habe nicht geprüft, ob für alle) dieser Spickzettel gibt es eine Version als Bild und eine als PDF. Zu jedem der Spickzettel gibt es eine eigene Seite, mit Hinweisen zu Versionen und ergänzenden Erklärungen. Ein, wie ich finde, prima Überblick in die Themengebiete.

t-online.de

Durch meinen Linktipp kam onli zu einer Seite, bei der er den empfohlenen Text auf seinem Röhrenmonitor nicht lesen konnte. In einem Kommentar zu seinem Beitrag stellte ich die Theorie auf, dass ein Teil schlecht lesbarer Farbwahl an den neuen Designs liegt, die nahezu ausschließlich aus Hintergrundbildern und nicht mehr wie früher aus angegebenen Farben bestehen.

Ich kannte und nutzte lange einige Webseiten und Add-Ons, die überprüften, ob die gewählten Farbkombinationen auch für Menschen mit eingeschränkter Sehfähigkeit noch nutzbar sind. Was ich immernoch bei jedem Layout mache sind zumindest zwei Tests:

Design auf Farbkontraste testen

In einem meiner Browser, die immer teste, habe ich ein recht ungewöhnliches apricot als Hintergrundfarbe eingestellt, damit fällt mir sofort auf, falls ich an einer Stelle vergessen habe, die Hintergrundfarbe zu deaktivieren. Ich nutze den Seamonkey für manches nebenbei, deshalb weiß ich, dass bei weitem nicht alle Webautoren das testen, sehr amüsant finde ich wie schlecht das z.B. bei t-online klappt.

Die Kontraste lassen sich z.B. mit dem Firefox Add-On Colour Contrast Analyser testen. Aber eben leider nur die Kontraste der Hintergrundfarben, das gilt nicht für Hintergrundbilder und ist daher kaum noch für ein Design passend.

Sinnvoll ist immer auch ein kurzer Test mit vischeck.com dort werden die häufigsten Formen von Farbblindheit simuliert, damit fallen ganz unglückliche Farbkombinationen auf. Sinnvoll ist selbst einen Screenshot zu machen, um zu testen, testet man eine Website direkt, fehlen die Hintergrundbilder und der Eindruck ist verfälscht.

Ebenfalls gut ist die Seite von Colorblind Filter dort kann auch noch einiges eingestellt werden.

Website auf Zugänglichkeit testen

Die Accessibility-Toolbar für den Firefox testet vieles, was automatisiert möglich ist, z.B. auch den Farbkontrast auf derselben Grundlage, wie das Farbkontrast-Add-On. Die Toolbar kann jedoch eben nur automatisiert testen, nicht alles was da an Fehlermeldungen oder eben nicht aufgeführt wird, ist tatsächlich relevant. Hier wird beispielsweise ein Fehler angezeigt, weil blogoscoop als Bild eingebunden ist, ohne dieses Bild können jedoch keine Zugriffe gezählt werden, hier nutze ich im Moment ein unsichtbares Bild.

Ich bin nicht so begeistert von der Erweiterung, weil sie zwar viele Tests bietet, aber halt nicht “mitdenken” kann. Ein weiterer gemeldeter Fehler für dieses Blog ist, die h1 auf der Startseite sei nicht identisch mit dem title-Attribut. Ja, stimmt und das wird auch so bleiben, denn dieses Blog hat einen title für die Startseite, der etwas ausführlicher ist, als das Logo, welches hier innerhalb der h1 liegt. Manche Erklärung für einen angegebenen Fehler sagt mir keineswegs in für mich verständlicher Form, was das Problem ist. Ich habe schon einiges Wissen zu diesem Thema, sicherlich mehr als viele Webautoren, aber für manchen Hinweis reicht das nicht aus. Aus meiner Sicht sollte eine solche Toolbar jedoch so klare Meldungen bringen, dass auch weniger versierte Webautoren zumindest verstehen was gemeint ist.

Layout ohne Grafiken testen

• miradlo bloggt ohne Grafiken

Mit der Webdeveloper-Toolbar, die ich in Firefox und Seamonkey installiert habe, lässt sich eine Website ohne Grafiken anzeigen (für den IE gibt was ähnliches). Das zweite Bild zeigt dieses Blog ohne Grafiken. An diesem Beispiel sieht man, worauf ich achte, wenn ich Bilder für ein Layout einsetze:

Die Hintergrundfarben aller Bereiche sind angelehnt an die Farbe der Layoutbilder, die Vorteile:

• die Optik nicht mehr ganz so schick, aber noch immer sehr ähnlich
• ganz schlecht lesbare Farbkombinationen fallen auf
• falls die Seite mal langsam lädt, fällt es kaum auf, weil die Farben eben sehr ähnlich sind
• wer ganz ohne Grafiken surft bekommt trotzdem noch ein lesbares Design

Fazit der Farbkombinationen

Auch nach nochmaliger Recherche konnte ich nichts finden, mit dem sich auch Farbkombinationen von Hintergrundbildern und Text testen lassen. Damit gibt es eben keine Alternative für aktuelle Designs, die auf Farbverlaufsbildern basieren, mit Transparenzen arbeiten oder ähnlichem.

Ich meine das Bewusstsein, dass Webseiten in erster Linie lesbar sein sollten, hat sich noch bei weitem nicht durchgesetzt. Außerdem wird von vielen Webautoren zuwenig getestet. Doch es fehlt auch an automatisierten Tests und die Werkzeuge die solche Tests erlauben sind häufig nicht verständlich.

Da wir überwiegend mit Webapplikationen arbeiten ist fast immer auch PHP beteiligt, deshalb nutzen wir meist Subclipse in Eclipse, für die svn-Befehle. Ab und zu lohnt es sich jedoch nicht, den Klotz (Eclipse ist dick und langsam) zu öffnen, wenn es grad nur ums einchecken, nach kleineren Änderungen im HTML oder CSS geht, die ich mit Quanta mache.

In solchen Fällen bevorzuge ich die Konsole (KDE auf Gentoo Linux, ob das auch mit Windows oder Mac so klappt weiß ich nicht) . Leider gibt es manchmal Versionsprobleme, deshalb kann es vorkommen, dass ein über die Konsole bearbeites Projekt in Eclipse nachher nicht mehr gelesen werden kann, weil die svn-Version älter ist. Andererseits gabs auch schon mal einen Rechner, auf dem Eclipse grad nicht auf Anhieb laufen wollte und sowieso nur fürs svn genutzt wurde. Dann lohnt es sich nicht lange zu suchen, der einfachere Weg ist hierbei die Konsole.

svn-Befehle auf Konsole

Vor Arbeitsbeginn, falls man nicht ganz sicher weiß, dass niemand sonst etwas eingecheckt hat, im eigenen Verzeichnis aufrufen:

• svn update
  Dabei werden alle aktualisierten Dateien geholt.
• Zwischendurch zeigt svn status (svn st genügt auch, für fast alles gibt es auch kürzere Varianten) den aktuellen Stand aller lokal geänderten Dateien an. So kann entschieden werden, welche Dateien geändert, gelöscht, hinzugefügt werden sollen.
• svn add Dateiname fügt eine Datei hinzu.
• svn delete Dateiname löscht eine Datei, die bereits im svn war.
• Einchecken mit: svn commit -m „das ist der Text der beschreibt, was ich tatsächlich getan habe, z.B. Datei xy erstellt, im Design der Navigation Fehler korrigiert, Funktion xy eingebaut”
  Im Kommentar sollte stehen, was getan wurde, damit jeder andere am Kommentar sehen kann, wann und was in einer Version geändert wurde.
• Bei weiteren Aktionen bietet sich meist eher Eclipse an, beispielsweise geht svnignore in Eclipse schneller und komfortabler.

• Die nächsten Barcamps in der Übersicht bei Jan.
• Geschichte von Linux und Unix via identi.ca
• Safari, Firefox und IE unterhalten sich… via twitter
• Selten genutzte CSS-Eigenschaften einsetzen, im Artikel werden teils noch Hinweise auf Situationen gegeben, in denen die ein oder andere Möglichkeit praktisch ist. Beschrieben werden text-transform, letter/word-spacing, text-indent, table-layout und white-space. via twitter
• Roland beschreibt wie man WordPress MU lokal installiert und wie sich etwaige Probleme damit umgehen lassen: Installation von WordPress MU auf Gentoo Linux

ohne CSS also nacktes HTML

Wie was kein Design? Warum, was ist los?

CSS Naked Day

Einen Tag lang sollen mit der Aktion keine Styles anzuzeigen, Webstandards gefördert werden. Denn ohne Styles, Bilder und Design sieht man den Seitenaufbau genauer. Manche Seiten nutzen den internationalen “ganzen Tag” das bedeutet das CSS bleibt für 48 Stunden aus, damit es weltweit alle sehen können, dann dauert der 9. April halt nicht nur 24 Stunden.

Wer sich an Webstandards hält nutzt valides und semantisches Markup in (X)HTML. Die Inhalte sind sinnvoll strukturiert, mit Überschriften, Absätzen, Listen usw. An diese Regeln sollte man sich natürlich immer halten, die Aktion ist nur ein Hinweis um darauf aufmerksam zu machen.

Wem helfen Webstandards?

Unterm Strich allen, denn eine sinnvolle Struktur und korrektes Markup sind ein grundsätzlicher Vorteil. Ansonsten nützen Webstandards:

• Suchmaschinen die sowieso kein Design sehen
• Tastaturnutzern siehe auch Navigieren mit der Tastatur
  • manche mögen keine Maus benutzen
  • manche können keine Maus benutzen
  • …
• es gibt Besucher mit sehr langsamer Internetverbindung, die schalten Styles und Bilder grundsätzlich ab
• Screenreader haben nichts von Styles (werden von Blinden genutzt)
• Menschen die schlecht sehen oder irgendeine Fehlsichtigkeit haben schauen sich Webseiten ohne oder mit speziell auf sie zugeschnittenen Stylesheets an
• Standards machen es leichter unabhängig von den genutzten Voraussetzungen gut funktionierende Webseiten zu erstellen
• überarbeitete oder neue öffentliche Seiten müssen sich an Webstandards und einen gewissen Stand der Barrierefreiheit halten
• Webstandards sind die Grundlage, um barrierefreie Seiten zu erstellen (nein, nicht jede standardkonforme Seite ist deshalb barrierefrei)
• für Stammleser die einen Feed ohne Design bevorzugen ist die Struktur einer gut aufgebauten Seite besser zu verstehen
• …

Es gibt viele Gründe, die dafür sprechen, es spricht nichts Nachvollziehbares dagegen (Webseitenerstellungsprogramm XY kann das nicht, ist für mich kein Argument). Trotzdem gibt es noch viel zuwenige Seiten, die sich an Webstandards halten.

Die meisten Redaktionssysteme, CMS (Content Management Systeme) und somit auch die bekannten Blogsysteme können mit Webstandards umgehen. Manche besser, manche schlechter, häufig entstehen die Probleme jedoch erst wenn die Autoren etwas eingeben oder bei Themes, die sich nicht daran halten.

Der CSS-Naked-Day ist eine gute Gelegenheit auch das eigene Blog, die eigenen Seiten mal kritisch zu betrachten. Wer das nicht gleich öffentlich tun möchte, dem kann ich für Firefox die Webdeveloper Toolbar empfehlen, da lassen sich alle Styles mal eben zum Nachsehen deaktivieren. Sowohl auf eigenen, wie auf fremden Seiten ab und zu mal ganz spannend… Für Seamonkey gibt es das auch, Opera bringt ähnliches grundsätzlich mit, für den IE (zumindest für Internet Explorer 7 und gibt es eine ähnliche Toolbar.

Wie lässt sich das für Besucher anzeigen?

Ich habe für CSS-Naked-Day das WP-Plugin genutzt, weil es einfach bequem ist und für einen Tag wollte ich jetzt nicht selbst basteln. Allerdings geht das Plugin soweit ich gesehen habe, dann eben nur von den 24 Stunden des 9. Aprils Ortszeit in Deutschland aus. Wer es lieber selbst ins Theme einbauen mag, findet die Anleitung dazu bei Frank. Eine Liste einiger teilnehmender Seiten gibts Dustin Diaz, in deutscher Version unter nakedcss.de. Auf diesen Seiten gibt es auch Hinweise, wie sich das automatisiert bei anderen Systemen realisieren lässt.

Ganz ohne Automatisierung bietet unser Styleswitcher ganzjährig auch eine Naked-Version. Viel Spaß beim Surfen heute, ich hoffe es wird auch hierzulande einige teilnehmende Seiten geben, schaut doch z.B. auch bei Dieter vorbei.

• Passend zu dem, was ich schon öfter gefragt wurde von Menschen, die nicht so oft im Netz sind gibt es bei akademie.de einen Artikel zum Reputationsmanagement. Was kann man wie tun, um auch im Netz den Ruf zu haben, den man haben möchte.
• Welch grauenerregend schlechte Formulare es noch im Web gibt, davon berichtet Trixy mit Beispielen und Bildern.
• Bei der Web 2.0 Konferenz in München diese Woche ging um Firmenblogs, angesprochen werden in dem Artikel von interworld.de das Saftblog und das Daimlerblog, die ich ja auch bei meinen Beispielen zu Unternehmensblogs genannt hatte.
• Dieter steigt mit in die aktuell laufende CSS-Framework-Diskussion ein: Pro und Contra YAML mit vielen Links zu den diversen Beiträgen für und gegen solche Frameworks.
• Ergänzend dazu schreibt auch Jens Meiert über CSS-Frameworks.
• Die erste Ausgabe des – auf Papier gedruckten – Webstandards-Magazins ist im Handel erhältlich; abonnieren kann man es auf der Website. Mein erster Eindruck: Einiges kannte ich schon, zumindest so in etwa in dieser Form, der ein oder andere Artikel ist jedoch lesenswert und auch für mich neu. Wäre das Pflichtlektüre für alle Webautoren, Webdesiner usw. dann gäbe es weiter weniger schlecht gemachte Seiten…