praegnanz.de büro für intervernetzte medien

Unser Weblog

Vorsicht mit »Add to Homescreen«

Gerrit, 17.03.2014

Aus aktuellem Anlass – mehrere unterschiedliche Canvas-basierte Spielentwicklungen hier in unserer Bürogemeinschaft – sei an dieser Stelle daran erinnert, dass es einen signifikanten Unterschied macht, ob man unter iOS 7(.1) eine Webapp im regulären MobileSafari laufen lässt, oder ob man sich dieselbe Webapp als selfcontained App auf dem Homescreen ablegt.

Nach wie vor zieht es Apple vor, die Performance von selfcontained Webapps zu drosseln. Insbesondere bei Canvas-basierten Spielen merkt man deutlich, dass es ruckelt, bis hin zur Unspielbarkeit.

Mein Rat: Trotzdem hübsche Icons erstellen und einbinden, trotzdem einen feinen Titel vergeben, aber die Capability auf »no« setzen:

<meta name="apple-mobile-web-app-title" content="MeinSpiel" />
<meta name="format-detection" content="telephone=no" />
<meta name="apple-mobile-web-app-capable" content="no" />
<link href="path/to/icon-152x152.png" sizes="152x152" rel="apple-touch-icon" />
<link href="path/to/icon-144x144.png" sizes="144x144" rel="apple-touch-icon" />
<link href="path/to/icon-120x120.png" sizes="120x120" rel="apple-touch-icon" />
<link href="path/to/icon-114x114.png" sizes="114x114" rel="apple-touch-icon" />
<link href="path/to/icon-76x76.png"   sizes="76x76"   rel="apple-touch-icon" />
<link href="path/to/icon-72x72.png"   sizes="72x72"   rel="apple-touch-icon" />
<link href="path/to/icon-60x60.png"   sizes="60x60"   rel="apple-touch-icon" />
<link href="path/to/icon-57x57.png"   sizes="57x57"   rel="apple-touch-icon" />

Somit öffnet sich einfach ein neuer Tab im normalen Mobile Safari, wenn man auf das Icon im Homescreen tippt. Hat außerdem den Vorteil, dass externe Links auf eine vernünftige Weise behandelt werden können (siehe hier). Happy HTML5-Game-Developing!

Kommentare [6]

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 [7]

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 [2]

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 [10]