praegnanz.de büro für intervernetzte medien

Unser Weblog

Es spammt so schön zur SEO-Zeit

Gerrit, 21.02.2014

Wir erlauben uns gerne einen Scherz mit den Meta-Keywords. Diese werden bekanntlich von den Suchmaschinen seit vielen Jahren ignoriert, aber von Laien immer noch gerne mit viel Akribie gepflegt. Da stehen wir drüber. Auf der Website zum #webtypobuch lauten die Meta-Keywords von daher wie folgt:

deine, mudda, meine, mudda

Dieses scherzhafte Verhalten lässt die autark handelnden Mail-Bots der SEO-Abzockerfirmen völlig kalt. Heute ereilt uns eine wichtige Mail mit einem noch wichtigeren SEO-Angebot:

Sehr geehrte Damen und Herren,
wir haben bemerkt, dass sich Ihre Webseite beim Abrufversuch solcher Schlüsselwörter wie »deine, mudda, meine« auβerhalb von den ersten zehn Suchergebnissen bei Google befindet.

Dies bedeutet, dass der potentielle Kunde beim Eingeben der wichtigsten Schlüsselwörter bei Google auf die Webseiten Ihrer Konkurrenz stöβt, die in den Ergebnissen eine höhere Position haben.

Nach der Analyse Ihrer Konkurrenz sind wir in der Lage, die Position Ihrer Seite bis auf die ersten 10 Suchergebnisse bei Google zu erhöhen.

Wir garantieren keine versteckten Kosten, nur eine einmalige Gebühr.

Sonderangebot!
Bis zum 21.02.2014 erhalten Sie ein Optimierungspaket für Ihre Webseite für 149,- EUR (eine einmalige Gebühr, ohne Abonnement).

Kommentare [8]

Webfonts: Fette Fehlerquelle

Gerrit, 08.02.2014

Handwerkliche Fehler und Hässlichkeiten im Web zu entdecken, ist für den etablierten Webdesigner wahrlich nichts neues und Teil unseres Berufes. Unangenehm wird es vor allem dann, wenn wir Probleme entdecken, die sonst keinem auffallen, weil nicht jeder Kollege (und schon gar nicht jeder Kunde oder gar Besucher) den entsprechend geübten Blick hat. Zu starke JPG-Komprimierung ist so ein klassischer Fall, oder auch fehlerhafte Orthografie.

Typografisch interessierte Webdesigner erleben dabei noch viel schlimmere Qualen als die meisten anderen Mitglieder unserer Zunft. Heute will ich mich neben dem Dämonischen Trio (Blocksatz ohne Silbentrennung, falsche Kapitälchen, falsche Anführungszeichen) einem Phänomen widmen, welchem ich in den letzten zwei Jahren immer häufiger begegne: falsche Fetten.

Zur Erläuterung: Die meisten CSS-Autoren begnügen sich mit den einfachen Fetten-Angaben über normal oder bold. Dies ist einfach zu erklären, denn in der Prä-Webfonts-Ära konnte man ausschließlich Systemschriften auf Websites nutzen, die beinahe ausnahmslos in den vier Schnitten regular, italic, bold und bold-italic verfügbar waren.

Mit dem Einzug von Webfonts hat sich das verändert. Gut ausgebaute, beliebte Webfonts sind beispielsweise die Open Sans, die Source Sans Pro und die Myriad Pro. Alle besitzen weit mehr als vier Schnitte. Es gibt jeweils ganze 4 bis 6 Fetten mit je einer italic-Variante. Was uns vor ein Problem stellt. Ausgehend davon, wie viele Schnitte des Webfonts wir tatsächlich verwenden wollen, müssen wir unsere @font-face-Definition und die daraus resulierenden CSS-Regeln entsprechend anpassen.

Fall 1: Ich habe nur eine oder zwei Fetten einer Schrift im Einsatz

Hier muss genau darauf geachtet werden, dass die font-weight-Deklaration im @font-face-Abschnitt mit den verwendeten Werten bei den Element-Eigenschaften übereinstimmt, etwa so:

@font-face {
	font-family: "MegaFont";
	src: url('megafont.woff');
	font-weight: normal;
	font-style: normal;
}
@font-face {
	font-family: "MegaFont";
	src: url('megafont-bold.woff');
	font-weight: bold;
	font-style: normal;
}
p {
	font-family: "MegaFont";
}
strong {
	font-family: "MegaFont";
	font-weight: bold;
}

Man beachte insbesondere den gleichbleibenden Namen der Schriftfamilie. Wie der Begriff schon andeutet, bleibt die Familie gleich, lediglich der Einzelschnitt und damit die referenzierte Font-Datei ist eine andere, wenn es um den bold-Schnitt geht.

Fall 2: Ich habe mehr als zwei Fetten einer Schrift im Einsatz

Hier ist es sehr empfehlenswert, auf die zahlenmäßige Notation der Schriftfetten zu wechseln, welche in CSS schon sehr lange existiert, jedoch bisher niemals so richtig notwendig war.

@font-face {
	font-family: "MegaFont";
	src: url('megafont.woff');
	font-weight: 400;
	font-style: normal;
}
@font-face {
	font-family: "MegaFont";
	src: url('megafont-bold.woff');
	font-weight: 700;
	font-style: normal;
}
@font-face {
	font-family: "MegaFont";
	src: url('megafont-ultrathin.woff');
	font-weight: 100;
	font-style: normal;
}
p {
	font-family: "MegaFont";
	font-weight: 400;
}
strong {
	font-family: "MegaFont";
	font-weight: 700;
}
h1 {
	font-family: "MegaFont";
	font-size: 10em;
	font-weight: 100;
}

Es wäre unnötig kompliziert, den superdünnen Schnitt als eigene Schriftfamilie »MegaFontUltralight« zu deklarieren, und dann über normal anzusprechen. Es ist semantisch nicht richtig (es handelt sich ja um die gleiche Familie), und stellt uns vor Probleme, sobald uns dann doch mal ein bold aus dieser Schriftfamilie reinrutscht, wo gar kein bold eingebunden ist

Was kann man falsch machen?

Offenbar vieles! Es häufen sich Sichtungen von Websites – teils angesehener Kollegen –, bei denen beispielsweise Elemente mit bold gekenzeichnet werden, obwohl die Schrift mit 600er-Fette deklariert wurde. Was nun passiert, ist unschön: Für den Browser entspricht die »bold«-Deklaration einer 700er-Breite. Diese ist aber nicht vorhanden. Statt dessen wird die 600er-Version der Schriftfamilie verwendet und – ihr ahnt es – ordentlich improvisiert. Jede Browserengine macht hier ihr eigenes Ding. Im Mac-Chrome werden die Buchstaben seltsam unscharf und erhalten eine höhere Laufweite. Und genau an dieser Stelle beginnen die Bauchschmerzen, denn diese Art von Seltsamkeit sehen nur wenige Menschen. Die stört es jedoch umso mehr.

Bitte tut euch also den Gefallen, und achtet auf die korrekte Zuweisung der font-weight-Eigenschaft im Rahmen der @font-face-Deklaration, sowie die damit übereinstimmende font-weight bei den Elementen-Eigenschaften. Dann klappt’s auch mit dem netten Typografen von nebenan.

Achtung, Falle: Die Elemente b und strong, sowie alle Headlines sind vom Browserstylesheet standardmäßig mit einem beherzten bold versehen. Sollte eure fette Schriftdeklaration jedoch einen anderen Wert als 700 aufweisen, muss das im Rahmen eines CSS-Resets auch noch bedacht werden. (Das CSS-Äquivalent für normal beträgt übrigens 400 Fetteneinheiten.)

Achtung, Falle 2: Natürlich versuchen die modernen Browser inzwischen, Fehler und Ungenauigkeiten von CSS-Autoren durch Mitdenken zu korrigieren, so auch hier: Findet der Renderer nicht die passende Fette einer Schriftfamilie, nimmt er gerne auch eine oder zwei Stufen knapp daneben und tut, als sei nichts gewesen. Von daher Obacht: Diese Auswirkungen können sich bei jedem Browserupdate ändern.

Achtung, Falle 3: Historische Browser wie der IE 6–8 kommen mit mehr als 2 Fetten in einer deklarierten Schriftfamilie gar nicht klar. Hier muss man leider doch für die dritte und eventuell vierte Fetten-Stufe auf eine eigene font-family ausweichen. Siehe Details in diesem Typekit-Blogbeitrag.

(Danke auch an @maddesigns für seine Slides)

Kommentare [4]

Außer Haus im 1. Halbjahr 2014

Gerrit, 14.01.2014

Es wird auch in diesem Jahr einige Gelegenheiten geben, den Gesellschafter van Aaken (also mich) auf diversen öffentlichen und nichtöffentlichen Veranstaltungen zu treffen. Der Übersicht halber hier eine derzeit vollständige Auflistung:

28./29. März 2014
WordPress für Webdesigner
bei der Typografischen Gesellschaft München

28. April 2014
bookmarks 2014 – Tagung für Buchgestalter und Hersteller
auf dem Mediacampus Frankfurt

5./6. Mai 2014
Publisher’s Forum 2014
in Berlin (auf dem Podium)

10./11. Mai 2014
Responsive Weblayouts mit HTML und CSS
bei der Typografischen Gesellschaft München

19./20. Mai 2014
Beyond Tellerrand
in Düsseldorf (nur als Teilnehmer)

31. Mai 2014
Arbeitstagung der Herstellerleiter
Kloster Irsee

3.–6. Juni 2014
Seminar Web-Basics II
Zürcher Hochschule der Künste

Kommentare

Aspekte bei Wahl und Einrichtung von Content-Management-Systemen

Gerrit, 05.12.2013

Ein sperriger Titel, ein Dauerbrenner-Thema: Seit etwa zehn Jahren laufen beinahe alle Websites, die von Webdesign-Profis und Amateuren erstellt werden, auf Basis eines webbasierten Content-Management-Systems (CMS). Ich mag heute nicht zwingend bestimmte Systeme anpreisen oder verurteilen. Das habe ich vor einigen Jahren schon einmal getan, und werde es sicher in naher Zukunft wieder tun. Heute geht es mir um die Praxiserfahrungen und die Lehren, die ich aus acht Jahren aktiver CMS-Betreuung mit unterschiedlichsten Kunden sowie unterschiedlichsten CMSen gesammelt habe. Genauer gesagt eine Reihe unsortierter Aspekte, die ich hervorheben möchte. Und los:

Der Mythos vom eifrigen Kunden

Dass alle Kunden alle ihre Inhalte selber pflegen wollen, bedarf keiner Frage. Bis auf wenige Ausnahmen ist es das erklärte Ziel in allen Briefing-Gesprächen, die Dinge selber in die Hand nehmen zu wollen. Unsere Aufgabe als Webdesigner ist es, diese Absichten richtig einzuordnen. 80 bis 90 Prozent der Projekte, die ich in den letzten Jahren begleitet habe, werden de facto sehr wenig bis überhaupt nicht gepflegt, und das völlig unabhängig davon, wie aufwändig wir das Backend für den Kunden individualisiert und hübsch hergerichtet haben.

Die wenigen tatsächlich eifrigen Kunden melden sich zuverlässig und freundlich, wenn etwas nicht so klappt, wie sie es wollen. Und es herscht auch erstaunlich wenig Groll, wenn man dann erklärt, dass das eben nicht so geht. Die wenigsten Kunden haben die technischen Möglichkeiten und Paradigmen von einem halben Dutzend unterschiedlichen CMSen im Kopf und können sich fundiert beschweren, dass die artikelbasiert verknüpfbare, aber grundsätzlich globale Bildverwaltung von WordPress aber flexibler sei als die rein artikelbasierte Bildverwaltung von ProcessWire.

Was CMS-Schulungen angeht, so haben wir uns seit kurzem auf Anregung von Nils vorgenommen, nach Möglichkeit keine telefonischen oder vor-Ort-Schulungen mehr durchzuführen. Hier sind es nämlich gefühlte 93 Prozent der Teilnehmer, die sich das System nach der Schulung mindestens ein Vierteljahr nicht mehr angucken, und dann selbstredend alles wieder vergessen haben. Statt dessen: kleine Schulungsvideos per Screencast aufnehmen und per privatem YouTube-Link an den Kunden schicken. Dauert nur unwesentlich länger als die direkte Live-Schulung und kann jederzeit wieder angeguckt und nachvollzogen werden. Wir testen das in den nächsten Monaten und werden berichten, wie es damit läuft.

Anwender- oder entwicklerfreundlich?

Kann man beides haben? Es hängt davon ab. Manche Systeme sind von Haus aus ziemlich benutzerfreundlich, wenn es um Standardsituationen geht, kränkeln aber sehr schnell, sobald Spezialfälle auftreten. Andere Systeme müssen erst sehr mühsam benutzerfreundlich gemacht werden, können dafür aber extrem flexibel sein. Systeme mit schneller Entwicklungsgeschwindigkeit und flexiblen Möglichkeiten sind bisweilen Gift für nicht-technische Anwender. Und so weiter und so weiter.

Es gilt, mit ganz viel Menschenkenntnis herauszufinden, ob der Kunde tatsächlich zu den erlauchten 10 Prozent gehört, die tatsächlich mit ihrer Website arbeiten, und zwar mehrmals monatlich, ggf. sogar wöchtentlich oder gar – man mag es nicht zu hoffen wagen – täglich! Falls ja, kann man getrost ein größeres Budget einplanen und eventuell die CMS-Wahl noch einmal überdenken, denn nun müssen die ganzen fancy Speziallayoutmodule auch noch pflegbar gemacht werden!

Wer als Webdesigner gerne sein Ding macht und genug Selbstbewusstsein besitzt, kann aber auch immer das entwicklerfreundliche CMS nehmen, mit dem er selber am besten zurechtkommt, pfeilschnell und flexibel Seiten bauen kann. Das führt zu günstigen Preisen. Wenn der Kunde dann wider Erwarten doch dieses und jenes zweimal im Jahr geändert haben möchte, ist es eine Überlegung wert, ihm das als Service innerhalb einer kleinen Rahmenvereinbarung anzubieten. Oder die Pflegbarkeit on demand nachzurüsten. Tipp: Die zweite Lösung ist meist teurer und weniger zufriedenstellend.

Machen wir uns nichts vor: bestimmte Layout-Konstrukte sind einfach nicht dafür gemacht, vom Kunden gepflegt zu werden. Und entgegen der Beteuerungen wird das auch selten nötig sein. Mein Appell: mehr Mut zu »Geht erstmal nicht. Rufen Sie an, wenn Sie es tatsächlich ändern wollen!« Der Anruf wird vorerst nicht kommen. Und wenn doch, fällt einem sicher eine gemeinsame Lösung ein.

WYSIWYG wird besser

Manche mögen es nicht glauben, aber inzwischen ist es denkbar, den Kunden ihren geliebten TinyMCE zu geben. Schmeißt alles raus, begrenzt die erlaubten Elemente und Klassen, stutzt das Ding bis zur Unkenntlichkeit, aber sorgt in Gottes Namen für ein eigenes Stylesheet, dass dem CSS des Frontends einigermaßen entspricht. Eigene Klassen sind möglich, auch div-Bereiche lassen sich realisieren und beschriften. Gute CMSe kapern auch die Bildfunktion und integrieren die eigenen serverseite Bilderskalierung. Da geht einiges. Vor allem für kleinere Webprojekte.

Markdown und Shortcodes können auch rocken

Vor allem wenn man selber (oder der fleißige Praktikant) größere Mengen an Inhalten umpflegen muss, ist trotz aller WYSIWYG-Euphorie so eine schöne Plaintext-Welt die robustere und schnellere. Und bei tatsächlich großen Webprojekten, die von mehreren Redakteuren über Jahre hinweg kontinuierlich und einheitlich gepflegt werden, würde ich stets versuchen, die Professionalität, Verlässlichkeit und Unbestechlichkeit von Markdown in Kombination mit diversen eigenen Shortcode-Erweiterungen einzubringen. Natürlich muss man anfangs etwas Überredungskunst anwenden, da immerhin eine neue Syntax gelernt werden muss mit individuellen Spezialbefehlen. Aber bei Projekten wie Renovabis und Catan hat sich das (im Rahmen von Drupal) durchaus bewährt.

Rockstar oder Underdog?

Ganz klar: Mit bekannten Namen hat man es immer leichter. Fast jeder Kunde hat irgendwann einmal etwas von WordPress, Typo3 oder Joomla gehört. Völlig klar, dass dann eine Webdesignerin erst einmal in einer Defensivsituation ist, wenn sie ihr (für den vorliegenden Fall) klar überlegenes ProcessWire oder ExpressionEngine verargumentieren muss. Oftmals ist man ja auch dankbar, wenn der Kunde bereits einen CMS-Wunsch äußert, selbt wenn er nicht fundiert ist. Dann hat man später wenigstens nicht den Schwarzen Peter in der Hand, wenn es nur so mittelrund läuft mit dem Projekt.

Dennoch sollten wir hartnäckig bleiben. Falls wir der Meinung sind, dass für den gegebenen Fall die Vorteile eines »alternativen« CMS eindeutig erkennbar sind, sollten wir versuchen, es durchzudrücken! Und ganz ehrlich: So obskur kann ein CMS nicht sein, dass sich nicht mindestens ein halbes Dutzend fähiger Webdesigner in Deutschland finden lassen, die im Notfall das Projekt übernehmen könnten.

Vom agentureigenen CMS im Rahmen einer proprietäre Gesamtdienstleistung inklusive Hosting und monatlicher Strafmiete halte ich übrigens nicht viel. Ein Unternehmen sollte stets die Hoheit über seine eigene Website haben.

Der Mythos der schnellen, billigen Theme-Anpassung

Auch ich bin der Versuchung mehrfach erlegen, für ein kleines Budget einem sympatischen Kunden ein vorhandenes WordPress-Theme anzupassen und somit massig Zeit zu sparen. Es ist dann immer anders gekommen als geplant. Entweder der Quellcode des Themes ist einfach nur Schrott oder entspricht so gar nicht dem eigenen Stil. Das ist nicht gut für den Blutdruck. Oder der Kunde installiert sich eigenmächtig Plugins und wundert sich, dass die nicht automatisch zum Stil der Seite aussehen – immerhin ist es doch ein fertiges Theme! Oder geringfügige Anpassungen am Theme lassen die responsiven Layoutkonstrukte komplett durcheinanderpurzeln, weil man diese zunächst nicht bedacht hatte.

Am Ende wäre es fast immer genauso viel oder sogar weniger Arbeit gewesen, selber ein individuelles Theme aufsetzen, maximal mit einem neutralen Sandbox- oder Starter-Theme als Hilfestellung. Weil einfach jeder Extrawunsch sehr viel länger dauert als im eigenen Theme. Und Extrawünsche kommen garantiert – wenn nicht vom Kunden, dann von euch selber! Ein bisschen Stolz steckt nämlich in jedem von uns. Wer kennt das nicht? »Uh, so kann man das nicht lassen! Nur noch schnell diesen Abstand, dann hier noch das Fett rausnehmen, und hier … Moment, wie hat der denn die Navigation gelöst? Pfui Spinne! Das muss ich noch schnell ordentlich machen…« Und schon sind drei Stunden rum, bei responsiven Layouts auch gerne ein ganzer Tag!

Und sonst so?

Es gibt noch viele weitere Aspekte bei der praxisnahen CMS-Zähmung. Das soll jedoch erstmal genügen. Über eure Erfahrungen in den Kommentaren freue ich mich natürlich!

Kommentare [11]

Nexus 5 – Android, wie es sein soll

Gerrit, 06.11.2013

Von den vielen Problemen, die die Android-Plattform seit seiner Erstveröffentlichung hatte, war eines stets die starke Bande mit den Mobilfunkanbietern und den diversen Hardware-Herstellern. Wenn ein normaler Bürger ein Smartphone erwerben möchte, geht er am ehesten in einen der 277 Mobilfunkshops in seiner Stadt und lässt sich beraten bzw. schaut sich die Geräte an. Der vermeintlich einzige Point of Sale bestimmt den Großteil des Markts und damit auch zu weiten Teilen, wie die Geräte aufbereitet sind. Das Ergebnis kennen wir: kaputtkonfigurierte, vor Werbung und Crapware bis zur Unkenntlichkeit verstümmelte Smartphones in jeder Preisregion.

Mit der Nexus-Serie wollte Google diesen Wildwuchs eindämmen und zeigen, wie das mit diesem Betriebssystem eigentlich gedacht war. Nexus-Geräte sind Referenzimplementationen. Aber solche, die man tatsächlich benutzen und seine Freude dran haben kann. Schade, dass der Mobilfunk-Einzelhandel so wenig Interesse an der reinen Lehre besitzt, denn ich halte Nexus für den einzigen erträglichen Weg, sich der Android-Plattform zu nähern.

Zu Testzwecken kaufen wir uns für das Büro alle paar Monate ein aktuelles (oder weniger aktuelles) Nexus-Gerät, damit wir die zunehmende Anzahl an mobiloptimierten Websites aus unserem Hause gut testen können. Nebenbei spielen wir natürlich auch gerne mit den Geräten und vergleichen sie mit unseren täglich (auch privat) genutzten iOS-Geräten.

Was soll ich sagen?

Das Nexus 5, welches wir gestern früh mit der Post geliefert bekamen, lässt mich seitdem nicht mehr los. Es ist mit Abstand das gelungenste Android-Smartphone, das ich je in der Hand hatte. Woran liegt’s?

  • Es ist sehr gut verarbeitet, leicht, liegt gut in der Hand
  • Der Bildschirm ist sehr hoch aufgelöst, hell und groß
  • Android 4.4 hat sich deutlich gemacht, sieht schick aus, hat größtenteils butterweiche Animationen und trifft meist den richtigen Ton zwischen Sachlichkeit, Übersichtlichkeit und Verspieltheit

Gerade im Gegenzug zur extremen Typolastigkeit Helveticalastigkeit von iOS 7 ist das Nexus-Android wohltuend differenziert in seinem Grafikdesign. Auch wenn die verwendete Systemschrift Roboto nicht alle Designpreise der nächsten Jahre gewinnen wird, sie ist in Fließtexten deutlich angenehmer zu lesen als die Helvetica-Wüste. Hier ein Vergleich (Feedly-App vs. Reeder 2):

(Die Feedly-App gibt’s auch für iOS, aber sie verwendet nicht Helvetica. Gut gemacht!)

Ich habe mich erstaunlich schnell unter Android breitmachen können, da ich bei den meisten Sync-Diensten nicht auf Apple, sondern auf Google vertraue. Also waren meine Mailkonten, Kalender, Kontakte und ein paar Youtube-Kanäle direkt startklar. Andere Dienste, die ich häufig nutze, konnte ich ebenfalls nach wenigen Minuten starten: Spotify, Twitter, Facebook, Dropbox. Es ist erstaunlich, wie schnell man sich so einen Taschencomputer mittels Clouddiensten personalisieren kann.

Im Grunde sind es fast nur ein paar iOS-only-Spiele (Carcassonne, anyone?), die mich von einem Fulltime-Test des Nexus abhalten. Und natürlich die Tatsache, dass hier keine Nano-SIM, sondern eine gute alte Micro-SIM ihre Dienste verrichtet. Doch auch ausschließlich im WLAN bereitet mir das Gerät derzeit große Freude. Was ich ehrlich nicht gedacht hätte.

Und zu einem Preis von 349 Euro kann ich nur sagen: Wie kann man jetzt noch auf die Idee kommen, ein anderes Android-Smartphone zu kaufen? Es ergibt keinen Sinn, ein verstümmeltes TouchWiz-Samsung für den doppelten Preis bei Vodafone zu erwerben, wenn man ein cleanes Nexus 5 von LG/Google haben kann.

Ach ja. Am Telefonhörer-Symbol können sie noch arbeiten, die Android-»Grafiker«.

Kommentare [12]