Wer als Webentwickler mit der API oder mit Apps von Facebook arbeitet, kennt es vielleicht. Plötzlich ist nicht mehr viel wie vorher. Funktionen sind nicht mehr da, wo sie einmal waren oder sie werden gänzlich abgeschaltet. Man muss Facebook aber ein Kränzchen binden, dies wird jeweils angekündet, respektive im Developer Blog dokumentiert.

Einer solchen Änderung sind auch die Facebook App Profile Pages zum Opfer gefallen.

Denn davor konnten Apps dank diesen Facebook App Profile Pages mit einer Leichtigkeit zu Fanseiten hinzugefügt werden. Mit dem neu beschriebenen Weg im Developer Blog muss man sich allerdings jedes Mal einen Link zusammenschustern. Dieser Weg ist aus meiner Sicht etwas kompliziert beschrieben, obwohl er relativ einfach wäre – wenn man es dann einmal begriffen hat.

Um die ganze Geschichte noch etwas zu erleichtern, habe ich einen kleinen Generator programmiert, welcher genau diesen Link erzeugen kann. Ganz simpel, ohne viel Nachleserei.

Er ist unter fb.claudioschwarz.com erreichbar und kann kostenlos benutzt werden.

Gastbeitrag von Martin Steiger, Rechtsanwalt

In der Schweiz gibt es bislang keine generelle Impressumspflicht für Websites, wie man sie beispielsweise in Deutschland als Anbieterkennzeichnung kennt. Lediglich für gedruckte Zeitungen und Zeitschriften gilt eine ausdrückliche Impressumspflicht. Andere Publikationen – auch Websites – unterliegen bloss einer Auskunftspflicht auf Anfrage hin.

Für Unternehmen und Unternehmer, die im Handelsregister eingetragen sind, besteht eine gesetzliche Firmen- und Namensgebrauchspflicht, nicht aber eine Impressumspflicht. Im Recht des unlauteren Wettbewerbs sind irreführende Angaben untersagt, doch besteht keine Verpflichtung zu Angaben über die eigene Identität.

Auch ohne Impressumspflicht ist ein Impressum mit Angaben zur eigenen Identität für Website-Anbieter empfehlenswert. Transparente Kontaktadressen erlauben in vielen Fällen, Probleme im direkten Kontakt zu lösen anstatt kostspielig und zeitraubend den Rechtsweg beschreiten zu müssen. Für Websites, die sich an Benutzer in der Europäischen Union richten, ist ein Impressum üblicherweise heute bereits notwendig.

Schweizerische Impressumspflicht ab 2012

Im Frühjahr 2012 wird auch in der Schweiz eine Impressumspflicht für Websites eingeführt. Hintergrund ist das revidierte Bundesgesetz über den unlauteren Wettbewerb (UWG), das per 1. April 2012 in Kraft tritt und unter anderem eine Impressumspflicht einführt. Die Schweiz orientiert sich dabei an den Informationspflichten in der europäischen E-Commerce-Richtlinie (2000/31/EG).

Gemäss dem revidierten UWG handelt in Zukunft insbesondere unlauter, «wer Waren, Werke oder Leistungen im elektronischen Geschäftsverkehr anbietet und es dabei unterlässt, klare und vollständige Angaben über seine Identität und seine Kontaktadresse einschliesslich derjenigen der elektronischen Post zu machen». Wer in der Schweiz Websites oder Apps anbietet, muss demnach künftig klare und vollständige Angaben über seine Identität und seine Kontaktadressen veröffentlichen, wozu ausdrücklich auch E-Mail-Adressen zählen.

Website-Anbieter, die heute noch kein Impressum veröffentlichen, sollten ihre Websites so bald wie möglich mit einem vollständigen Impressum ergänzen. Anbieter, die ab Anfang 2012 über kein Impressum auf ihrer Website verfügen, drohen zwar keine Abmahnungen wie sie in Deutschland berühmt-berüchtigt sind, doch finden die Strafbestimmungen des UWG Anwendung, die unter anderem die Möglichkeit von Geldstrafen vorsehen.

Zum Autor: Martin Steiger schloss ein Rechtsstudium an der Universität St.Gallen (HSG) ab und ist heute als Rechtsanwalt in Zürich tätig. Er berät kleine und mittlere Unternehmen, darunter auch Startups, in wirtschaftsrechtlichen Fragen. Seine Freizeit verbringt er insbesondere mit Motor- und Segelflug sowie als OK-Mitglied bei TEDxZurich.

Im Zweifelsfall, bei Unklarheiten und für Abklärungen im Einzelnen empfiehlt sich die Beratung durch eine Fachperson wie beispielsweise einen Rechtsanwalt.

Dieser Artikel erschien erstmals am 9. November 2011 auf startwerk.ch

Um es gleich vorwegzunehmen: Auch wenn wir bei Blogwerk am liebsten ohne Papier arbeiten, ganz ohne Briefmarken und Ordner kommen wir nicht aus, gerade in der Kommunikation nach aussen. Das meiste läuft bei uns aber – wie könnte es anders sein – über’s Bildschirmfenster.

Das ist auch nötig bei einer Redaktion, die sich über drei Länder verteilt und die mehrheitlich nicht in Zürich sitzt. Wir müssen die Zusammenarbeit mit freien Autoren koordinieren, brauchen Möglichkeiten zum gemeinsamen Bearbeiten von Texten und müssen aktuell Inforessourcen zur Verfügung stellen. Auch mit E-Mail kommt man da nicht weit.
Es geht also um Kommunikation, Koordination und Dokumentation. Welche Werkzeuge setzen wir ein? Hier unser Fuhrpark:

Die Allzweckwaffe: Google
Google Apps for Business bietet einen günstigen und umfangreichen Werkzeugkasten, um kollaborativ zu arbeiten. Mit «Text & Tabellen» lassen sich Office-Dokumente eben nicht nur verfassen, sondern auch verwalten. Arbeitet man zu mehreren an einer Datei, muss diese nicht per E-Mail hin und her geschickt werden, sondern lässt sich auf dem Server zur Bearbeitung freigeben. So kann gemeinsam an derselben Datei gearbeitet werden, zur Koordination stehen ein Chatfenster und Anmerkungen zur Verfügung.

Eine Erwähnung verdient auch Googles Kalenderapp. Die persönlichen Agenden, die alle Teammitglieder verwenden, lassen sich freigeben, so dass Blogwerker A vor seinem Terminvorschlag nachschauen kann, wann Blogwerkerin B Zeit hat. Gleichzeitig können beliebig viele Kalender angelegt und geteilt werden. Einzelne Teams oder das ganze Büro koordinieren hiermit Dienste, Ferienabwesenheiten, Piketts und Themenplanungen.

Der Aktenschrank: Dropbox
Was in Google-Docs entstanden ist und leicht wiederauffindbar abgelegt werden will, wandert in die gemeinsame Dropbox. Dieser Onlinespeicher sorgt für die ständige Verfügbarkeit der Dokumente für das ganze Team und ein kontinuierliches Backup in die Cloud. Die Software läuft auf jedem Rechner und synchronisiert im Hintergrund das Dateisystem im Netz mit dem lokalen System. Sehr angenehm: Auf die Dropbox kann auch ausser Haus ohne weiteres zugegriffen werden und per Browser oder App von anderen Geräten.

Das schwarze Brett: Yammer
Yammer dient einerseits als internes Kommunikationstool, und ersetzt einen internen Newsletter ebenso wie ein Diskussionsforum. Grundsätzlich funktioniert Yammer wie Twitter nach dem Follower-Prinzip: Nutzer können andere Nutzer abonnieren und erhalten deren Mitteilungen im einem Stream angezeigt, auf Wunsch auch gesammelt per E-Mail. Gruppen helfen dabei, die Kommunikation einzelner Projektteams zu bündeln, zum Beispiel der Redaktion eines bestimmten Blogs.

Yammer, das sowohl für kurze Nachrichten als auch für längere Beiträge geeignet ist, ist vielseitig einsetzbar. Auf der einen Seite lassen sich hier Links teilen, Mini-Umfragen erstellen oder kurze Status-Updates posten – beispielsweise kann die Technik die Redaktoren über das neueste Feature des Social Media Kits informieren. Gleichzeitig sind auch Anleitungen oder längere Diskussionen hier gut aufgehoben. Sie lassen sich verschlagworten und sind via Tags oder die Suchfunktion wieder auffindbar.

Sitzungstisch und Nachrichtenbuffer: Skype
Der Wert von Skype für ein verteiltes Team ist klar: Auf der einen Seite die Redaktionskonferenzen, wo man alle an einen virtuellen Tisch bekommt. Zum Zweiten für jeden schnellen Austausch zwischen Teammitgliedern, der via E-Mail umständlich würde.
Daneben erfüllt Skype aber auch innerhalb unseres Zürcher Büros eine wichtige Funktion – es dient als eine Art Nachrichten-Buffer: Rückmeldungen geben, Links teilen, kurze Fragen stellen. Das hat einen einfachen Grund, man will dem Kollegen ja nicht bei jeder kleinen Frage auf die Schulter tippen. Schliesslich weiss man nicht, ob er gerade «nur» eine E-Mail schreibt oder man ihn beim konzentrierten Arbeiten unterbricht. Ein Alternative zum Zuruf ist da die unaufdringliche Skypenachricht, die man zeitnah beantwortet, aber eben in den Moment, wo gerade Platz dafür ist.

Dieser Setup ist auf unsere Bedürfnisse zugeschnitten und hat sich aus der täglichen Praxis heraus entwickelt. Das bedeutet auch, dass wir laufend mehr darüber lernen, was sich für uns eignet und welche Werkzeuge wir wie einsetzen können. Unsere Erfahrung zeigt: Versuchen Sie Neues, es kann gut sein, dass Ihre Abläufe davon profitieren und dass Sie Ihre bevorzugte Arbeitsweise erst entdecken.

Im zweiten Teil des WordPress-Artikels geht es um den richtigen Einsatz von Plugins und den optimalen Einbau der Like-Box oder Tweet-Buttons.

Dieser Artikel ist in der Ausgabe 25 des t3n-Magazins vom 31. August 2011 erschienen. Wir veröffentlichen ihn hier mit freundlicher Genehmigung von t3n in zwei Teilen.

Langsame Plug-ins
Oft ist für ein lahmende WordPress-Installation ein Plug-in verantwortlich: Der Autor hat nicht über die Performanceimplikationen seines Codes nachgedacht, und auf seinem kleinen Blog fielen die Probleme nicht auf. Es gibt kein Patentrezept, um solche Plug-ins bereits vor der Installation zu erkennen; trotzdem lässt sich mit zwei Regeln ein bisschen Zeit sparen und mit gutem Codeverständnis schon manches Problem frühzeitig erkennen:

• Es sollten nicht bei jedem Aufruf des Plug-ins/der Webseite Schreiboperationen auf der Datenbank durchgeführt werden. Das ist oft der Fall bei schlecht geschriebenen Statistik-Plug-ins, die jeden Aufruf in der Datenbank mitschreiben. MySQL ist vor allem auf Leseoperationen optimiert. Schreibzugriffe sind vergleichsweise langsam, erzeugen viel Last, und wirken deswegen als Bremse, wenn sie bei jedem Seitenaufruf stattfinden.
• Der Code für die Administration des Plug-ins sollte in eine eigenen Datei ausgelagert werden. PHP ohne «Op-Code-Cache» liest bei jedem Aufruf alle PHP-Dateien neu ein und führt den Code sequentiell aus. Bei den meisten Aufrufen der Webseite wird der Code für die Administration nicht benötigt – warum sollte er also geladen werden?

Doppeltes Laden von jQuery
Durch unsachgemässen Gebrauch von WordPress-Funktionen kann es auch schnell passieren, dass das JavaScript-Framework jQuery zweimal geladen wird. Beispielsweise wird einmal die in WordPress integrierte Version geladen, und zum anderen eine ältere Version durch das verwendete Theme oder Googles CDN, dass auch eine jQuery zur Verfügung stellt. Durch das doppelte Laden entsteht kein JavaScript-Fehler, deswegen fällt die Verschwendung nicht von alleine auf.

Am einfachsten erkennt man den Fehler mit einem kurzen Blick in den ausgelieferten Quellcode, und mit der Suche nach «jquery»: Wird nur eine Stelle im Code gefunden, ist alles ok, gibt es zwei Referenzen, beginnt die Suche. Mögliche Stelle sind die Theme-Dateien header.php und footer.php oder installierte Plug-ins.

Browser Cache nutzen
Statische Dateien wie Bilder, CSS-Styles und JavaScript-Dateien in Themes, Plug-ins und dem Upload-Ordner von WordPress ändern sich nicht mehr. Deswegen können sie sehr aggressiv im Browser gecacht werden. Das Ziel ist, dass der Browser gar keinen HTTP-Request für diese Dateien absendet. Das kann beim Einsatz des Apache-Webservers mit einer .htaccess-Datei im wp-content forciert werden. Quellcode 1 zeigt den Inhalt dieser .htaccess-Datei.

<IfModule mod_expires.c>
  <FilesMatch "\.(gif|jpg|png|js|css)$">
    ExpiresDefault "access plus 10 years"
  </FilesMatch>
</IfModule>

Wenn ausnahmsweise doch eine Modifikation einer Datei nötig wird, muss die URL zu dieser Datei geändert werden, damit der Browser die Datei nicht aus dem Cache holt. Das geht am einfachsten, wenn hinter den Dateinamen ein Fragezeichen zusammen mit einer für jede Änderung hochzählenden Nummer angehängt wird. Beispiel: Aus dem folgenden img-Tag:

<img src=“http://testblog.de/wp-content/themes/theme1/gfx/logo.png“>

wird:

<img src=“http://testblog.de/wp-content/themes/theme1/gfx/logo.png?1“>

Der Dateiname der logo.png-Datei auf dem Server ändert sich nicht und bleibt gleich. Der Apache-Webserver wird beim Bestimmen, welche Datei er ausliefern muss, alles ab dem Fragezeichen im Dateinamen abschneiden.

Facebook, Twitter und andere Social Networks
Ein Blogbetreiber möchte, dass seine Artikel über Likes und ReTweets den Weg in alle gängigen Social Networks finden – deswegen ist so schön praktisch, wenn der Facebook-Like-Button, die Like-Box, der Tweet-Button und alle anderen integrierbaren Scripte eingebaut werden. Das Problem ist, dass jeder dieser Buttons die Ladezeit für den Besucher verlängert. Es gibt zwei verschiedene Technologien, wie solche Buttons eingebaut werden können:

1. Mit JavaScript (bei Facebook XFBML genannt)
2. Per Iframe

Wenn die Wahl besteht, wie z.B. bei Facebook, sollte zum unflexibleren iFrame gegriffen werden. Abgesehen von der modernsten Generation unterbrechen alle Browser den Aufbau der Seite, bis JavaScript-Dateien geladen wurden. Wenn der Server des Social Networks offline oder falsch konfiguriert ist, kann das eine signifikante Zeit dauern.

Auch beim Einsatz des Iframes ist aber mit einem Performancenachlass zu rechnen. Der HTML-Code dieser kleinen Buttons ist verhältnismässig komplex und erfordert Rechenleistung auf dem Computer des Besuchers.

Fazit
Unter Beachtung dieser einfachen Punkte wird die eigene WordPress-Site schon beträchtlich schneller; es gibt aber noch wesentlich mehr Möglichkeiten. Denn alle generellen Tipps zur Steigerung der Performance von Webseiten lassen sich auch auf WordPress übertragen. Hier seien beispielsweise das Vermeiden von HTTP-Requests durch zusammenlegen von Bildern in sogenannten Sprites oder der Einsatz eines Content Delivery Networks (wie Amazon S3) zum Speichern und Ausliefern der hochgeladenen Bilder erwähnt.

Bei allen Arbeiten an der Performance von Webseiten sollte man indessen nie das Ziel, den Besucher optimal zu bedienen, aus den Augen verlieren. Man kann sich leicht verzetteln: Hier noch 20 Millisekunden durch Optimieren von Einstellung X auf dem Server eingespart bringt wenig, wenn man gleichzeitig alle Share-Buttons noch als JavaScript eingebunden hat und damit den Seitenaufbau um mehrere Sekunden verlangsamt.

Die Performance beruht immer auf einer Kombination aus der Auslieferungsverzögerung des Webservers, der Verbindung zum Besucher und der Komplexität beim Rendern der Webseite. Das Firefox-Addon Firebug hilft dabei, die Gesamtsicht nicht zu verlieren.

Das CMS WordPress wird längst für weit mehr als nur Blogs verwendet. Allerdings ist es auf dem Server ressourcenhungrig – und eine schnelle Seitenauslieferung ist inzwischen sogar ein Kriterium für die Suchmaschinenplatzierung einer Website. Mit einigen WordPress-Expertentipps kann man das System optimieren und beschleunigen.

Dieser Artikel ist in der Ausgabe 25 des t3n-Magazins vom 31. August 2011 erschienen. Wir veröffentlichen ihn hier mit freundlicher Genehmigung von t3n in zwei Teilen.

Die Darstellungsgeschwindigkeit einer Webseite ist ein Erfolgsfaktor: Eine Grosszahl der Besucher gelangen via Suchmaschinen auf die Site – Google und co. berücksichtigen im Ranking-Algorithmus inzwischen aber auch die Auslieferungsgeschwindigkeit der Webseite. Ihr Argument: Langsame Websites sind schlecht gepflegt und bieten eine mangelhafte User-Experience.

WordPress ist bereits in der Grundeinstellung relativ langsam und generiert mit jedem Seitenaufruf viel Last auf dem Server. Allerdings bietet das Blog-CMS viele Optimierungsmöglichkeiten und lässt sich durch Plug-Ins leicht beschleunigen.
Ein Blick auf den Tacho:

Zunächst muss sich der Webmaster einer WordPress-Seite über die aktuelle Performance klar werden und Engpässe eruieren. Wenn das Blog in den «Google Webmaster Tools» registriert ist, sollte der erste Weg dorthin führen. Mit Hilfe der Browser-Erweiterung «Google Toolbar» bezieht Google die durchschnittliche Ladegeschwindigkeit von Webseiten bis zum «JavaScript-onload-Event», also bis der Besucher die Webseite nutzen kann. Die Informationen können unter «Google Labs» – «Website-Leistung» gefunden werden.

Genauere Daten, was den Performanceengpass verursacht, liefern die Firefox-Erweiterung «Firebug». Auf dem «Netzwerk»-Reiter wird detailliert darüber Auskunft gegeben, wie lange das Laden welcher Datei gebraucht hat. Automatisierte Analysen inklusive Verbesserungsvorschlage bieten die beiden Firebug-Addons «YSlow» und «Google PageSpeed». Sie sind über einen entsprechenden Reiter innerhalb Firebugs aufrufbar und analysieren die Webseite.

Beide Tools beziehen sich nicht auf WordPress im Speziellen. Sie geben generelle Empfehlungen, was vorgenommen werden soll. Die können teilweise schnell umgesetzt werden. Die Webmaster-Tools-Daten sind zu grob, um Rückschlüsse auf die Performance von der WordPress-Installation zu ziehen. Anders sieht es in Firebug aus. Der erste Eintrag mit der URL der Webseite gibt die Ladezeit der HTML-Daten an – und dafür ist die Performance von WordPress verantwortlich.

Der erste Eintrag auf dem Netwerk-Reiter in Firebug zeigt die Auslieferungsgeschwindigkeit der HTML-Daten und damit die Geschwindigkeit der WordPressInstallation.

Dynamisch bleiben, aber statisch ausliefern
Ohne spezielle Plug-ins werden bei jedem Aufruf einer von WordPress generierten Seite PHP und die WordPress-Dateien geladen. WordPress generiert den HTML-Code für die Seite, schickt ihn an den Webserver-Prozess, und dieser wiederum an den Browser des Besuchers. Beim nächsten Aufruf wird der Vorgang komplett wiederholt, als wäre vorher nichts gewesen. Und zwar auch dann, wenn sich and er Seite nichts verändert hat.

Der grösste Geschwindigkeitszuwachs auf der Serverseite lässt sich deswegen erzielen, wenn der Generierungsprozess z.B. durch zwischenspeichern des HTML-Ergebnisses abgekürzt werden kann. Dies kann entweder durch einen Caching-Server wie Varnish oder Squid geschehen, was aber Erfahrung im Konfigurieren von Linux erfordert und nicht auf günstigen Shared-Hosting-Angeboten möglich ist, oder durch WordPress-Plug-ins wie WP-Super-Cache oder W3-Total-Cache.

Die Plug-ins funktionieren so, dass sie den einmal generierten HTML-Code auf der Festplatte des Webservers abspeichern und beim nächsten Aufruf ausgeben lassen. Beide Plug-ins haben den Vorteil, dass sie durch die Integration in WordPress automatisch darüber informiert werden, wenn der Cache neuerstellt werden muss. Dies ist beispielsweise nötig, wenn ein neuer Artikel veröffentlicht wird oder ein Kommentar geschrieben wurde. Die Konfiguration und Benutzung ist sehr einfach und erfordert in der Regel keine manuellen Eingriffe. Im optimalen Fall wird durch diese Plug-ins für einen Grossteil der Anfragen gar kein PHP mehr auf dem Webserver gestartet, und die Ausgabe des HTML-Codes an den Client geschieht statisch durch den Webserver-Prozess, was enormen Tempogewinn zur Folge hat.

Für Profis: Der Object Cache
Wenn viele Plug-ins in einer WordPress-Installation aktiv sind oder WordPress für mehr als ein simples Blog verwendet wird, werden schnell viele Daten pro Aufruf aus der Datenbank abgefragt. Diese abgerufenen Daten werden vor dem Weiterverarbeiten innerhalb von WordPress aggregiert und in Objekten gespeichert. Da Datenbankanfragen relativ viel Zeit in Anspruch nehmen, bietet WordPress ein Interface an, den sogenannten «Object Cache», um diese Daten in einem flüchtigen, schnellen Cache zwischen zu speichern. Der Einsatz des Object Caches macht aber nur auf eigenen Servern Sinn und ist auf shared-Hosting-Systemen meist gar nicht möglich – er wäre mit grosser Wahrscheinlichkeit auch ein Sicherheitsrisiko, da alle gehosteten Websites den gleichen Cache auf dem Server verwenden könnten.

Der Object Cache erfordert ein sogenanntes Cache-Backend. Dazu wird eine Caching-Software auf dem Server verwendet. Es empfiehlt sich, memcached zu verwenden; aber auch andere Systeme, wie der User-Cache in APC, wären möglich. Nachdem die Software auf dem Server installiert ist, muss WordPress mitgeteilt werden, dass es den Cache nun verwenden soll. Dazu muss eine Datei namens object-cache.php in dem Verzeichnis wp-content angelegt werden. Diese Datei muss eine bestimmte Schnittstelle implementieren und die Daten an das Caching-Backend weiterreichen. Eine Implementierung für memcached kann von mohanjith.net heruntergeladen werden. Für alle anderen Backends bringt eine Google-Suche nach «wordpress object cache » das gewünschte Ergebnis.

Das im vorherigen Abschnitt vorgestellte Plug-in W3-Total-Cache beinhaltet verschiedene, einfach zu aktivierende Object-Cache-Implementierungen. Es kann auch verwendet werden, um die Cache-Backends anzusprechen. Neben den vorgestellten Backend bietet Total-Cache auch ein Backend, das die Daten als Dateien auf der Festplatte des Servers ablegt. Die Performance ist nicht so gut wie mit einem richtigen Cache-Backend, aber dafür auch für Shared-Hosting-Angebote geeignet.

Aktiviertes WP-Super-Cache-Plugin: Die Einstellung „Cache An (Empfohlen)“ reicht meistens schon

Morgen veröffentlichen wir hier den zweiten Teil mit weiteren Tipps.

HTML5 beinhaltet nicht nur das bekannte HTML zum Aufbau von Webseiten, sondern auch CSS, um die Seite schön zu gestalten, und Javascript, um der Webseite ein bisschen Interaktivität zu verleihen. Diese drei “Sprachen” bilden den Kern von HTML5 und werden von nun an gemeinsam und regelmässig weiterentwickelt. HTML5 soll alle bisherigen Standards, wie HTML4, XHTML 1.0 etc. ablösen.

Ich habe im ersten Beitrag erwähnt, dass man auch «Teile von HTML5» anwenden kann. Richtig, denn HTML5 sind nicht nur ein paar neue Tags/Attribute in der HTML-Syntax, sondern eben auch CSS3 und Javascript 1.8. Was das genau umfasst, wurde an der Präsentation am Internet Briefing vom 7. Juni 2011 kurz überflogen, würde aber den Rahmen dieses Blogeintrags sprengen. Viel interessanter ist, was man anwenden kann und welche Risiken man damit eingeht.

Semantische Tags und Formulare

Tags wie <header>, <nav> und <article> sollen Suchmaschinen oder Screenreadern helfen, die Inhalte einer Webseite besser zu finden. Das sollte man nutzen, auch wenn es noch keinen wesentlichen Vorteil bringt. www.jeriko.de ist eine Seite, die diese Tags bereits nutzt. Alte Browser wie der IE7 kennen zwar die Tags nicht, aber solange sie mit CSS gestylt sind, werden sie dargestellt. Bei anderen Elementen, wie dem Header mit Schatten und Fade-Effekt, ging man Kompromisse ein: Er erscheint im IE7 und 8 schlichtweg nicht. Übrigens: Das nächste WordPress Standard-Theme setzt diese Tags auch ein.

Ein anderes Beispiel sind die verbesserten Formulare. Die meisten kann man heute einsetzen. Alte Browser fallen auf normale Textfelder zurück und zeigen unter Umständen ein spezielles Feld für eine Datumseingabe nicht an. Das Problem: Man braucht für alte Browser trotzdem Kontrollmechanismen und damit bringt das ganze halt keinen Vorteil. Mobilgeräte hingegen bieten für die speziellen HTML5-Formulare entsprechende Tastaturen an oder im Falle eines Datumsfeldes die bekannten Drehrädchen.

Zugeschnittene Tastaturen für HTML5 Formulare

Stylen mit CSS3

Wir sehen: Wenn wir HTML5-Tags verwenden, müssen wir fast in jedem Fall einen Fallback programmieren. Etwas einfacher verhält es sich mit CSS3. Die bereits rege eingesetzten gerundeten Ecken sind ein gutes Beispiel. WordPress setzt sie bei Formularen und Buttons ein. Moderne Browser zeigen gerundete Ecken, ältere die herkömmlichen eckigen. Etwas mühsam ist, dass man runde Ecken derzeit dreimal definieren muss. IE9, Firefox und Chrome/Safari interpretieren je nach Version jeweils andere Anweisungen.

Ich persönlich bin der Meinung, dass man CSS3 ruhig einsetzen darf, da es hier in der Regel nicht um Funktionalität, sondern nur um Eyecandy geht. Das mindert zwar das Funkeln in den Augen derer, die noch auf einen alten Browser setzen, schränkt die Funktionen der Webseite aber nicht ein.

Im Vergleich fallen die kleinen Unterschiede schnell auf

Neues in Javascript

OK, jetzt machen wir ein grosses Fass auf. Die Neuerungen in Javascript eröffnen Webentwicklern sehr viele neue Wege und Möglichkeiten. Viele Techniken sind jedoch nicht abwärtskompatibel umsetzbar und können somit nur auf mobilen Webseiten oder etwa in einem Intranet mit vorgegebenem Browser umgesetzt werden. Mir fehlt leider der Platz und Jürg Stuker fehlte am Internet Briefing fehlte die Zeit um auf dieses sehr grosse Thema im Detail einzugehen.

Das am weitesten verbreitete «neue» Feature ist sicher die Geolocation API, die vor allem für mobile Webseiten interessant ist. Über den GPS-Sensor hat man Zugriff auf die aktuellen Koordinaten, sofern es der Benutzer zulässt. So funktioniert zum Beispiel die Umkreissuche auf der mobilen Webseite der Privera AG. Ein weiteres Beispiel lieferte ein Anwesender am Internet Briefing: Hier wurde eine Intranet-Applikation komplett auf HTML5 aufgebaut. Die genannte Applikation sei dank dem Einsatz von der WebStorage Technologie offline- und sync-fähig .

Die ganze Präsentation findet Ihr auf dem Slideshare Account von Namics.

Am Internet Briefing vom 07. Juni 2011 war das Thema HTML5. Reto Hartinger leitete den Event mit der Bemerkung ein, dass HTML5 jetzt und genau jetzt komme, merkte aber selbst an, wie oft er das schon gesagt habe. Aber ist es denn nun soweit, kann man HTML5 heute ohne Bedenken in jedem Projekt einsetzen? Und was genau ist eigentlich HTML5? Um diese Fragen zu beantworten, lassen wir die Präsentation von Jürg Stuker und Thomas Junghans von Namics und die interessante Diskussionsrunde kurz Revue passieren.

HTML5 – Jetzt ist es soweit

Könnte man zumindest meinen, wenn man die News der letzten Wochen sieht: Google stellt seine Apps per August auf HTML5 um und führt den Support älterer Browser wie IE6 und 7 sowie Firefox 3.5 nicht mehr fort. Wait what…? Das heisst, im Umkehrschluss wird IE8 noch unterstützt und dem sind keine HTML5-Techniken bekannt. OK, Google wird wohl auf den neuen Doctype umstellen und einige Funktionen von HTML5 nutzen. Das ist besser als gar nichts, aber in meinen Augen nicht die gefeierte Kehrtwende.

Ähnlich verhält es sich mit den News zu Windows 8. Apps für Windows 8 sollen mit HTML5 programmiert werden und Windows 8 selbst wird bei den eigenen Interfaces zum Teil auf diese Techniken setzen. Finde ich OK, man kann also HTML5 auf einem geschlossenen System nutzen, erreicht damit aber lediglich den Windows 8-Markt. Oder anders gesagt: Man kann HTML5 heute und in Zukunft anwenden, aber nicht da wo wir es wollen: Im Internet.

Alles in allem sind die Argumente, HTML5 einzusetzen noch nicht stark genug. Das zeigt die Tabelle aus der Präsentation von Jürg Stuker:

Und schnell wird klar: Wir sind noch nicht soweit

Man sieht: Für Mobile Apps kann man aus dem Vollen schöpfen, hier ist der Markt überschaubar. Behandelt man Android und iPhone, welche HTML5-kompatbile Browser einsetzen, erreicht man einen Markt mit nützlicher Grösse, zumindest in der Schweiz. An Blackberry braucht man meiner Meinung nach (auch in den USA) nicht zu denken: Die älteren Geräte haben so inkompatible Browser, da ist im Vergleich selbst der IE6 modern.

Doch was ist mit dem Internet? Ja, einzelne Teile vom HTML5 kann man einsetze, muss sich aber immer die Frage stellen, wie hoch der Aufwand ist, ein Ersatzfeature für ältere Browser zu bauen. Gerade als Dienstleister trifft man nicht selten Kunden, die auch die letzten 3% (IE6)-Marktanteil in der Schweiz erreichen wollen. Als Anbieter einer Web App ist man am längeren Hebel: Man kann selbst entscheiden was sinnvoll ist. Baut man eine App, die der Durchschnitts-Geek verwendet? Dann HTML5, volle Kanne – Geeks und Web-Enthusiasten surfen nicht mit alten Internet Explorer-Versionen.

Mobile First

Etwas Offtopic aber durchaus gut platziert war der 2009 von Googles Eric Schmidt propagierte Slogan «Mobile First». Es geht darum, bei der Umsetzung eines Projekts mit einer mobilen Website zu beginnen und sich und/oder den Kunden zu zwingen, sich auf die wichtigsten Features zu beschränken. Auf mobilen Endgeräten ist nun mal nicht derselbe Platz zur Verfügung wie auf modernen Computer-Bildschirmen. Das ist ein Ansatz, den man – unabhängig von HTML5 – in gewissen Fällen anwenden kann, heute im Jahr 2011 (dem Jahr des iPad 2, wie Reto so schön sagte) erst recht.

Und dann kam die Diskussionsrunde…

… in der es weniger um HTML5 ging, sondern vielmehr um das Thema «Wie kann ich den Kunden überzeugen, dass er keine IE6-Unterstützung mehr will?». Ganz unabhängig davon, dass auch IE7 und 8 kein HTML5 unterstützen. Wie immer kommt es auf das Projekt an. Jürg brachte ein gutes Beispiel mit dem Ticketshop der SBB: Auch wenn nur ein paar Prozent aller Besucher den IE6 nutzen, geht reales Geld verloren, wenn diese den Ticketshop nicht mehr verwenden. Auch wenn die entsprechenden Personen das Ticket am Schalter holen können, verärgert hat man sie, wenn man sie aussperrt. Auch wenn die Diskussion lange ging und hitzig mit Argumenten herumgeworfen wurde: Viel ist aus dieser Runde nicht hervorgegangen.

Nun wollen wir das ganze nicht weiter in die Länge ziehen. Ein weiterer Beitrag mit viel technischem Mambo Jambo wird in Kürze separat folgen. Die ganze Präsentation findet Ihr auf dem Slideshare Account von Namics.

Der Blogwerk Helpdesk steht von Montag bis Freitag von 09.00 Uhr bis 17.00 Uhr unter der E-Mail-Adresse support(at)blogwerk.com oder unter der Telefonnummer 044 533 30 20 zur Verfügung.

Wir wünschen geruhsame Festtage und einen guten Start ins 2011.

Ich blogge heute nur über eine Nebensächlichkeit, vom Hauptthema erzähle ich dann bei Gelegenheit.

Hinterher beim «Apéro riche» (für Zugereiste: es gibt neben Alkohol auch Kleinigkeiten zu essen, konkret u.a. exzellente Schinkengipfel) sprach mich jemand an und sagte, er sei Doktorand vom «XY Institute» (Namen bekannt) und habe heute unser Whitepaper Social Media Marketing runtergeladen, um es auf der Zugfahrt zu lesen. Ach ja, ich weiss, antwortete ich, Du hast beim Wort «Institute» einen Tippfehler gemacht.

Er sagte nichts, schaute aber sichtlich ungläubig. Also holte ich das iPhone raus und zeigte ihm in der Salesforce Mobile App seinen Eintrag (das geht recht schnell, weil die Daten synchronisiert werden und lokal gespeichert sind). Tatsächlich, er hatte «Insitute» geschrieben.

Aber richtig schockierend für ihn war wohl die Tatsache, dass direkt darunter steht: «Lead-Status: Unqualifiziert». Nicht qualifiziert zu sein entspricht natürlich nicht dem Weltbild eines Doktoranden. Ich konnte ihn beruhigen und sagen, dass das nur heisst, dass wir ihn nicht morgen anrufen, um ihm was zu verkaufen, und dass er für uns natürlich trotzdem ein wertvoller Kontakt sei, denn er könne ja in einigen Jahren irgendwo PR-Verantwortlicher mit Riesenbudget sein, und dann rufen wir ihn natürlich auch gern an. Das versöhnte ihn etwas.

Fazit: Es macht immer wieder Spass, einen organisierten Eindruck zu machen. Und Salesforce hilft mir in letzter Zeit sehr oft dabei. Teil II folgt. (Nein, ich habe nicht das Business gewechselt, wir machen immer noch Social Media und nicht CRM. Ich merke aber immer mehr, wie beide Bereiche zusammen spielen müssen, um etwas zu erreichen.)

Ein Klick, und schon bist Du bei Twitter oder Facebook und kannst einen Kommentar zum Link dieses Artikels hinzufügen: Wenn Du die Welt auf einen unserer Texte aufmerksam machen willst oder Deinen Followern zeigen, was sie verpassen, wenn sie uns nicht lesen …

Das geht inzwischen ganz einfach mit den beiden Knöpfen, die wir seit kurzem unter jedem Artikel einblenden: “Retweet” und “Share on Facebook”. Wer per Browser auf diesen Diensten sowieso gerade eingeloggt ist, kann mit nur zwei Klicks die Botschaft verbreiten. Das neue Feature schien uns angebracht, nachdem diese beiden Dienste derzeit den Trend zur Vernetzung anführen.

Grundsätzlich neu ist der Service übrigens nicht: Wir haben schon immer die Möglichkeit zum Verlinken/Anmelden/Versenden unserer Texte per simplem Mausklick angeboten – unter dem Text und nach der Werbung, mit dem Link “Merken/Email”, hinter dem sich rund 50 Social-Bookmarking- und andere Dienste verbergen, darunter die einfache E-Mail zum Weiterleiten unserer Texte. Einfach mal ausprobieren.