praegnanz.de büro für intervernetzte medien

Unser Weblog

PlayCatan auf HTML5-Basis

Gerrit, 30.04.2014

Heute morgen ist ein Projekt gelauncht, an dem wir als Teil eines bunt gemischten Teams mitarbeiten durften. Die Rede ist vom Relaunch der PlayCatan-Plattform. Kurz gesagt kann man dort Siedler von Catan online spielen. Die Plattform enthält jedoch einiges mehr, unter anderem sämtliche Erweiterungen des Basisspiels, sowie einige Extras. Auch eine Art Meta-Spiel (Oberwelt), in der man seinen Avatar hochrüsten und mit anderen Mitgliedern chatten kann, ist mit von der Partie.

PlayCatan

Technisch ist PlayCatan insofern interessant, als dass es die Plattform bereits seit 2001 gibt – und zwar als Java-Client (oder wahlweise als Java-Applet im Browser). Die gesamte Flash-Ära wurde übersprungen. Nachdem Java aber inzwischen nicht mehr zu den populärsten Desktop-Technologien gehört, wird nun konsequenterweise direkt auf HTML5 gesetzt. Die neue Plattform besitzt ein HTML/CSS/JS-basiertes Layout-Gerüst aus dem Hause praegnanz.de (Design und Frontend), und wird größtenteils mittels des Google Web Toolkits zum Leben erweckt. Vereinfacht gesprochen konnte die Produktionsfirma Brettspielwelt die alte Java-Anwendung per GWT zu JavaScript konvertieren, und damit den von uns gebauten Rahmen dynamisieren. Selbstverständlich mussten dabei extrem viele manuelle Anpassungen vorgenommen werden, was auch den Monsteranteil der vergangenen Monate in Anspruch nahm.

Doch es kommt noch toller: Die eigentlichen Spiele (und die Spielevermittlung) werden nämlich per Canvas realisiert und basieren nicht nur auf den alten Java-Spielen, sondern sind sogar mit ihnen kompatibel. Sprich: Eine Partie Catan kann mit einer gemischten Teilnehmergruppe bestritten werden: Ob ein Spieler den alten Java-Client verwendet oder die neue HTML-Oberfläche, ist für die Partie unerheblich.

Die Herausforderung für praegnanz.de war es, eine recht komplexe Verzahnung aus

  • handgestrickten DOM-Objekten
  • GWT-generierten DOM-Objekten (a.k.a: DIV-Hölle)
  • GWT-generierten Canvas-Objekten

so unter einen Hut zu bekommen, dass die Übergänge kaum erkennbar sind. Im weiteren Verlauf des Projekts ist geplant, immer mehr Canvas-Elemente nach und nach in DOM-Konstrukte umzuwandeln. Wenn es also derzeit visuell noch ein wenig rumpelt, liegt das meist an einem Canvas-Frendkörper, der ein anderes Rendering besitzt und möglicherweise noch aus einer 10 Jahre alten Java-Anwendung stammt.

Zusätzlich war eine wichtige Anforderung, in Zukunft fit für Tablets zu sein. Noch ist das ganze etwas behäbig und performt nicht optimal auf allen mobilen Geräten. Das wird mit neuen, schnelleren Geräten sicher bald besser werden. Speziell für uns war in diesem Zusammenhang jedoch wichtig, dass sich das Spielfeld dynamisch anpasst: Responsive Techniken, sowie das optionale Wegklappen von Meta-Elementen machen die Oberfläche sehr flexibel, was die vorgefundene Bildschirmbreite und -höhe angeht.

Fast schon eine Nebensache ist der Einsatz von ProcessWire als CMS für alle „statischen“ Inhalte der Website, also die Spielregeln, zahlreiche Hilfetafeln und Preislisten, ein News-System und FAQ. Dabei finden diese Inhalte komplett in Lightbox-iFrames statt, die sich über die eigentliche Anwendung legen und somit ein laufendes Spiel nicht unterbrechen können. Und wir haben es sogar geschafft, dass diese CMS-Inhalte von Google gelesen und indexiert werden können, obwohl das konzeptionell gar nicht so einfach war.

Wir hoffen, ihr wagt ein Probespielchen! Einen Basis-Account kann man sich hier kostenlosen klicken!

Kommentare [2]

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

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