Bitte auch den Nachtrag am Ende des Artikels lesen. Einige meiner Kritikpunkte und Fragen klären sich dort auf.

Und wieder mal ist ein neues Baukastensystem entstanden. Es heißt rukzuk und ich habe 2014 zum ersten Mal davon gehört, weil Flyeralarm dafür Werbung macht. Aber es kann natürlich auch schon älter sein.

Wie alle solche Baukästen wird auch hier versprochen, dass man schnell und einigermaßen mühelos zur eigenen Website kommt. Man kann sich einen kostenlosen Testzugang geben lassen, was ich letztes Jahr auch aus Neugierde getan habe. Und heute habe ich mir das noch mal kurz angesehen, um mich auch gleich wieder davon abzuwenden: Ich persönlich kann mit solchen Baukästen überhaupt nichts anfangen. Viel zu umständlich und unflexibel. Sie sind in aller Regel wohl für Laien gedacht, die über keine HTML- und CSS-Kenntnisse verfügen, aber sich gern eine eigene Website basteln möchten, und das ist völlig in Ordnung.

Warum sich rukzuk dann aber offensichtlich an Profis richtet, die verschiedene Pakete für eine monatliche Gebühr mieten können, ist mir jetzt ein wenig schleierhaft. Das Freelancer-Paket zum Beispiel bietet für 19 Euro im Monat 10 Projekte und 3 Live-Websites. Nur: was ist denn das für ein Webdesign-Freelancer, der zum Erstellen von Webseiten einen Baukasten benötigt und von HTML und solchem lästigen Zeug verschont bleiben möchte? Und der mit Grafikprogramm und Webeditor nicht umzugehen weiß? Also doch ein Baukasten für Privatleute? Nein, denn für die dürfte rukzuk zu schwierig zu bedienen sein bzw. eine zu lange Einarbeitungszeit erfordern. Aber es ist ja auch nach eigenen Angaben sowohl Design-Tool als auch Content-Management-System.

Ich kann mir also nur folgende Zielgruppe vorstellen: Grafikdesigner aus dem Printbereich, die auch Webdesign in ihre Angebotspalette aufnehmen möchten. Schwierig dürfte es nur dann werden, wenn sie mal an einen Kunden geraten, der sehr spezielle Wünsche hat. Da steht man mit den meisten Baukastensystemen dann wohl ziemlich auf dem Schlauch.

Übrigens: Mein Konto wieder platt zu machen, dazu habe ich im Kundenmenü keine Möglichkeit gefunden. Auch eine Art, potenzielle Kunden zu binden.

Nachtrag:
Der Produkt-Manager von rukzuk, Jakob Schröter, hat mir eine sehr nette E-Mail geschrieben und einige meiner Kritikpunkte aufgeklärt. Demnach richtet sich rukzuk vor allem an

Freelancer und Agenturen die keine Coding-Kenntnisse haben und bisher ihre Photoshop-Layouts von externen Entwicklern umsetzen und dann ein CMS integrieren lassen. Dieser Workflow braucht oft viel Zeit für die Kommunikation und Feinabstimmung; mit rukzuk können die Designer selbstständig Websites umsetzen und auch betreiben. Grafikdesigner aus dem Printbereich sind auch viele dabei.
Ein paar Sätze zu unserer Idee finden sich auch hier im Artikel:
https://webmagazin.de/mobile/photoshop-lugt-gestalte-webseiten-direkt-im-browser-gastbeitrag-2958000
und auf unserer Seite: https://rukzuk.com/de/Service/About/

Über unsere Modulentwicklung (http://developers.rukzuk.com/) können übrigens auch individuelle Kundenwünsche umgesetzt werden.

Und zur Löschung des Kontos:

Wir sind gerade dabei eine Löschen-Funktion in den Kundenbereich zu integrieren, diese wird in den nächsten Wochen freigeschaltet.

Momentan bin ich damit beschäftigt, für eine Kundin die Website zu überarbeiten, die vor längerer Zeit eine Agentur für sie erstellt hatte. Das Design ist ausgesprochen hübsch, den Quelltext allerdings entschlacke ich und befreie ihn von einigen Fehlern. Doch was mir gerade noch aufgefallen ist: die Hauptnavigation auf der Startseite funktioniert nur mit im Browser eingeschalteten JavaScript. Schlimmer noch: ist es ausgeschaltet, sieht man weder das Hintergrundbild noch das eigentliche Navigationsmenü, sondern findet eine fragmentarische, fast leere Seite vor.

Nun kann man zwar sagen, dass ja heutzutage nur etwa – je nach Statistik – zwei Prozent aller Benutzer JavaScript deaktiviert haben. Aber wenn diese zwei von hundert Besuchern auf so eine Website stoßen, werden sie wohl ganz schnell wieder weg klicken. Im schlimmsten Fall hat man auf diese Weise zwei Interessenten verloren, die vielleicht Kunden geworden wären.

Eine Navigation zu bauen, die nicht wenigstens als Alternative eine reine HTML-/CSS-Lösung bietet, halte ich also auch in der heutigen Zeit für nicht sinnvoll.

Wenn man Bilder einbindet, kann man ja die Breite und Höhe angeben. Das hat den Sinn, dass der Browser diesen Platz beim Aufbau der Seite schon einmal reserviert. So kommt es bei der Anzeige während des Ladens nicht zu hässlichen Ruckeleffekten.

Nehmen wir mal folgenden Fall an: eine größere Anzahl von Bildern ist in einem Verzeichnis auf dem Webserver gespeichert, diese Bilder haben unterschiedliche Maße, eine Teilmenge wird durch ein PHP-Skript per Zufallsmodus geladen, und diese Bilder sollen zu guter Letzt – vielleicht aus ästhetischen Gründen – alle die gleiche Breite haben. Nun könnte man denken, etwa folgende Angabe im Image-Element sei die Lösung:

width="110" height=""

Die Breite soll also festgelegt werden und die Höhe sich proportional anpassen. Aber in manchen Browsern, zum Beispiel alten Internet-Explorern, funktioniert das nicht. Allerdings klappt es dann, wenn man die Höhenangabe ganz weglässt, also so:

width="110"

Prinzipiell wäre es eleganter, von Vornherein alle Bilder mit einem Bildbearbeitungsprogramm auf dieselben Abmessungen zu schneiden. Dann bräuchte auch der Webbrowser sich nicht die Mühe zu machen, sie zu skalieren. Das macht aber natürlich dann keinen Sinn, wenn die Bilder teils im Querformat, teils im Hochformat vorliegen.

Gerade habe ich einen Artikel über sieben Webdesign-Sünden gelesen. Nun, sieben, das klingt nicht gerade viel. Bestimmt gibt es noch einige Fehler mehr, welche man machen kann, aber die in dem Beitrag beschriebenen Entgleisungen sind besonders schlimme Sünden. Die meisten Webauftritte sind ja schön, informativ und übersichtlich. Aber manchmal stößt man eben auch auf Websites, wo man erst mal gar nicht so richtig weiß, worum es geht und was der Betreiber uns eigentlich sagen will. Dies ist ein Punkt, der in dem Artikel gleich zuallererst genannt wird.

Doch insbesondere Punkt 6 hat mich angesprochen. Es geht um die Lesefreundlichkeit von Webseiten. Ich prangere ja oft genug zu kleine Schriftgrößen oder zu geringe Kontraste zwischen Schrift und Hintergrund an und noch ein paar Dinge mehr. Doch ich habe bisweilen das Gefühl, mit dieser Meinung alleine dazustehen. Wunderbar, dass ich mich in diesem Punkt irre und es Menschen gibt, die meine Ansichten teilen.

Hier der Artikel: Die 7 Website-Sünden.

Und wieder einmal habe ich durch Zufall eine Website entdeckt, die eine so kleine Schriftgröße aufweist, dass das Lesen einfach keinen Spaß macht. Der Text ist gesetzt in Arial in der Größe 10 Pixel. Hier die Angaben in der CSS-Datei:

.schrift {
	font-family: Arial, Helvetica, sans-serif;
	font-size: 10px;
	font-style: normal;
	font-weight: lighter;
	text-transform: none;
	color: #333333;
	line-height: 13px;
}

Ganz ehrlich, was soll so was? Das ist so, als würde man Bücher und Zeitungen in so winziger Schrift drucken, dass man Papier sparen und die Blattgröße schön klein halten kann. Eine Tageszeitung in DIN A5 oder so. Der Leser soll sich doch gefälligst eine Lupe kaufen.

Standardeinstellung der Schriftgröße ist in allen Webbrowsern, die ich kenne, 16 Pixel, und das sicherlich aus gutem Grund. Dass sich diese voreingestellte Anzeigegröße durch CSS-Angaben verändern lässt, ist grundsätzlich eine sinnvolle Sache, gerade heutzutage. Denn die Menge der heute verfügbaren Webfonts ist gewaltig, und wie auch im Druck, fallen manche Schriftfamilien größer aus, manche kleiner. Die Lesbarkeit wird beeinflusst durch verschiedene Merkmale wie die Breite und Formgebung der einzelnen Buchstaben, die Höhe der Kleinbuchstaben im Verhältnis zu den Großbuchstaben oder die Abstände der Buchstaben zueinander, und da macht es Sinn, die Schriftgröße an die jeweilige Schriftfamilie anpassen zu können (andere Faktoren wie Bildschirmauflösung oder Art des Displays spielen weitere Rollen, aber das ist ein Thema für sich).

Wir Menschen möchten Informationen im WWW finden. Wir möchten sie schnell finden und einfach erfassen können. Also müssen Bilder aussagekräftig, Texte gut formuliert und Schriften auf Anhieb lesbar sein, ohne dass man die Nase an den Monitor drücken muss. Und insofern ist eine 10 Pixel kleine Arial ganz einfach ungeeignet.

Die Wetter-Plattform donnerwetter.de zeigt sich seit kurzem in einem neuen Outfit, das ich sehr gelungen finde. Die alte Website kam ein bisschen überladen, düster, unstrukturiert und altbacken daher, aber der neue Auftritt erscheint klar, freundlich-hell, aufgeräumt und zeitgemäß. Nur die lustigen Wetter-T-Shirts finde ich nicht mehr, schade. Irgendwann, so hatte ich mir vorgenommen, wollte ich mal eins bestellen.

Alte Hasen aus Zeiten von HTML 3.2 oder 4.01 werden sich erinnern, dass man fetten Text mit <b> auszeichnete, kursiven Text mit <i>. Unter XHTML kamen dann <strong> und <em> dazu. <b> hatte ein rein typografische Bedeutung, es sollte also Text visuell durch eine Fettung der Schrift hervorgehoben werden. <strong> hingegen sollte eingesetzt werden, wenn eine Textpassage inhaltlich stark hervorgehoben werden sollte, was in gesprochener Sprache einer starken Betonung entspricht. In fast allen Browsern wurde beides genau gleich dargestellt.

Mit <i> und <em> verhielt es sich ähnlich: visuelle Schrägstellung der Buchstaben einerseits, Betonung andererseits. Nur dass hier eine eher schwache oder normale Betonung symbolisiert werden solle, im ersten Fall eine starke Betonung. <strong> war also eine Steigerung von <em>.

Leider wurde das von Amateur-Webdesignern oft nicht verstanden, und so hieß es oft, <b> solle oder dürfe ja nicht mehr verwendet werden, und man zeichnete alles, was irgendwie fett aussehen oder bedeutungsschwanger sein sollte, kurzerhand mit <strong> aus. Dazu kamen dann noch die Verfechter der unsinnigen These, dass alle diese Text formatierenden HTML-Elemente eh nichts mehr im Quelltext zu suchen hätten. Und so wurde dann <span style="bold"> als reine CSS-Lösung verwendet. Dumm nur, dass man nicht berücksichtigte, dass dann auch die Screenreader, die ja CSS ignorieren und sich nach der rein semantischen HTML-Auszeichnung richten, den sehbehinderten Benutzern die hervorgehobenen Passagen nicht betont vorlasen.

Mit HTML5 wird alles noch schwieriger – vermeintlich. Ich hingegen bin der Ansicht, dass es einfacher, weil eindeutiger geworden ist. <b> und <i> dienen nach wie vor der rein typografisch-visuellen Hervorhebung. Mit <strong> zeichnet man eine besonders wichtige Textpassage aus, mit <em> dagegen eine sprachlich besonders betonte. <strong> ist also keine Steigerung von <em> mehr, sondern beide haben eine unterschiedliche Bedeutung bekommen.

Dies finde ich absolut verständlich und plausibel. Und die Darstellung, die man mit CSS festlegt, ist eine ganz andere Sache. Sie hat mit Design zu tun, nicht mit Semantik.

Quellen:
der-webdesigner.net
blog.antikoerperchen.de

Webseiten sollten benutzerfreundlich und intuitiv bedienbar sein, klar. Ich habe schon eine ganze Menge über gute Lesbarkeit, einfach zu verstehende Navigation und eine übersichtliche Strukturierung der Inhalte gelesen. Ein Blogartikel, den ich kürzlich gefunden habe, hat mir aber einige Punkte verdeutlicht, über die ich wohl nie so richtig nachgedacht hatte. Man lernt eben immer dazu.

Der Autor, Jakub Linowski aus Toronto, stellt zunächst fest, dass eine geschäftliche Website zwei Aufgaben zu erfüllen hat: sowohl dem geschäftlichen Aspekt als auch den Besuchern zu dienen. Kundenorientiertheit ist also oberstes Gebot. Wie kann man nun den Interessenten den Aufenthalt auf der Website so angenehm und einfach wie möglich machen? Jakub hat zwanzig Ideen aufgelistet.

Und da gab es Einiges, das mich doch nachdenklich gemacht hat. Fangen wir gleich bei Idee 1 an: Ist ein einspaltiges Layout nicht wesentlich einfacher zu erfassen, als wenn links und rechts noch Seitenleisten sind? Hm, da musste ich überlegen, ob ich nicht oft die Webseiten überlade, obwohl ich mich schon immer um Einfachheit und Übersichtlichkeit bemühe.

Idee 2: Warum nicht zunächst etwas verschenken, bevor man einen möglichen Kunden zum Kauf »drängt«? Na gut, es ist nicht gerade ein kaufmännisches Geheimnis, dass Geschenke ja eigentlich aus dem Grund gemacht werden, dass der Interessent sich anschließend zum Kauf verpflichtet fühlen soll. Insofern bin ich darüber geteilter Meinung. Ehrlicher ist es, einer Person, die bereits Kunde ist, gelegentlich etwas zu schenken oder billiger zu lassen, weil man diesen Kunden einfach als Menschen gern mag. Andererseits biete ich ja mein Blog auch nicht zuletzt deswegen an, weil es hilft, meine Website bekannter zu machen. Klar, das Bloggen macht mir Spaß. Und ich schreibe auch nur über Dinge, die mich tatsächlich interessieren. Da überschneiden sich die Zwecke also ein bisschen. Doch vielleicht ist das ja gerade der Optimalfall: dass man mit dem, was man gern tut, auch Geld verdient.

Bevor es hier zu philosophisch wird, kommen wir nun lieber zu Idee 3: Ähnliche Funktionen lieber verschmelzen anstatt sie an verschiedenen Stellen doppelt und dreifach auftauchen zu lassen. Noch schlimmer ist es, wenn gleiche Funktionen gar verschieden bezeichnet sind. Klar, so was verwirrt den Benutzer.

Es folgen noch viele weitere gute Ideen und Anregungen, die ich aber hier nicht alle aufzählen möchte. Wer der englischen Sprache mächtig ist, kann sich gern den Originalartikel durchlesen (gut bebildert). Hier ist er:

A Good User Interface

Ich habe im Netz einen intuitiven Farbwähler gefunden, der die hexadezimalen Farbcodes ausgibt. Das ist ideal für Webdesigner, die die HTML-Farbangaben benötigen und sich auf einfache Weise eine Farbpalette für ein Webprojekt zusammenstellen möchten.

Das gesamte Browserfenster dient als Farbwähler. Man fährt mit der Maus über die Fläche, um eine Farbe auszusuchen. Bewegt man die Maus von ganz links nach ganz rechts, erscheinen die Farben vom Orangerot-Bereich bis zum Violettrot-Bereich, natürlich mit allen Farben dazwischen, also Grün, Blau etc. Maus nach oben dunkelt Farben ab, Maus nach unten hellt sie auf. Ein linker Mausklick speichert die Farbe links im Browserfenster ab, und man kann die nächste Farbe wählen, bis man seine Palette zusammen hat. Die Farbangaben werden mitten auf jedem Farbbalken als Text angezeigt, und diesen kann man per Copy-and-paste in seinen HTML-Editor einfügen.

Ich finde, intuitiver und einfacher geht es schon fast nicht mehr. Vorausgesetzt natürlich, man hat keine Farb-Fehlsichtigkeit und ein gutes Gespür für passende Farben.

http://color.hailpixel.com/

Typografie war ja in der Vergangenheit ein Stiefkind des Webdesigns. Kein Wunder, denn man konnte nur Schriften verwenden, die auf dem Computer des Benutzers installiert waren. Standardmäßig sind das sehr wenige, und dann noch unterschiedliche unter Windows, Mac und Linux. Irgendwann kamen JavaScript-Lösungen in Mode, wie zum Beispiel Cúfon, mit denen der Webdesigner den Überschriften einen anderen Font zuwies. Oft sah man auch Überschriften, die als Bild eingebunden waren – nicht wirklich optimal im Hinblick auf Ladezeiten und Suchmaschinenfreundlichkeit.

Einfacher und eleganter ist da schon die Einbindung über das @font-face-Element in der CSS-Datei. Prinzipiell kann man zwar einen beliebigen True-Type-Font vom Computer auf den Webserver hochladen und dann einbinden. Doch erstens kann nicht jeder Browser mit diesem Format umgehen, zweitens ist es unkompriert, sodass die Ladezeiten beträchtlich erhöht werden, und drittens verstößt das in aller Regel gegen Lizenzrechte.

Doch seit 2009/2010 werden verstärkt spezielle Webfonts von verschiedenen Schriftherstellern und -vertrieben angeboten. Diese nun dürfen auf den Webserver hochgeladen und per @font-face eingebunden werden – vorausgesetzt natürlich, man hat eine Lizenz erworben. Einige sind auch Freeware. Man erhält die Webfonts in verschiedenen Formaten, sodass sie mit jedem Browser und auf jedem Desktop- und Mobil-Betriebsssystem korrekt angezeigt werden. Eine Anleitung wird meist mitgeliefert.

Noch einfacher geht es mit den Google Webfonts. Hier wird nur eine einzige Zeile Code im Header der HTML-Datei benötigt. Allerdings sind nur wenige der 616 Schriften (Stand: Januar 2013) für Mengentext tauglich. Viele eignen sich höchstens für Überschriften, manche sind schlecht lesbar und einige rendern sehr unsauber. Einige Perlen sind aber durchaus darunter zu finden.

Quellen und nähere Informationen:
CSS, HTML UND JAVASCRIPT MIT {STIL}
How to use CSS @font-face
Google web fonts
MyFonts: Webfonts & Desktop Fonts