Die optimale Lösung hängt in der Praxis davon ab, welche Anforderungen Sie an Ihre mobile Webseite stellen – und wie viel Zeit und Budget für das Projekt zur Verfügung stehen. Wie so oft gilt auch hier: je mehr Aufwand, desto größer (in der Regel) der Nutzen. So existieren Lösungen, um ohne große Vorkenntnisse und teilweise sogar kostenlos innerhalb von fünf Minuten mit einer simplen mobilen Website online gehen zu können. Andere Lösungen erfordern grundlegende Erfahrungen im Bereich der Web-Programmierung und können Wochen oder sogar Monate an Entwicklungszeit dauern, um sich angemessen zu präsentieren.

Vier grundsätzliche Möglichkeiten stellt Ihnen dieser Artikels vor: die Nutzung von WYSIWYG-ähnlichen Editoren; clientseitige Lösungen, die auf JavaScript basieren; serverseitige Lösungen, die eine Gerätedatenbank als Basis nutzen; sowie der Mix aus den beiden letztgenannten. Teilweise können Sie dabei Inhalte aus bereits bestehenden Seiten übernehmen, in einigen Fällen müssen Sie die mobile Webseite von Grund auf neu aufbauen.

Wie von Zauberhand

Wenn Sie weder viel Zeit noch Geld in eine mobile Seite investieren möchten, eignen sich die zahlreichen „Wizard“-Anbieter, mit deren Service Sie ganz im Stile von WYSIWYG eine simple mobile Webseite „zusammenklicken“ können. In der Regel läuft es dabei so, dass Sie einen Link zu einem RSS-Feed, einer Facebook-Fanpage, einem Twitter-Profil oder ähnliche Dienste in einer Eingabemaske eintragen. Der Wizard holt sich die entsprechenden Informationen von der angegebenen Datenquelle, bietet anschließend die Möglichkeit, z.B. den Seitentitel, Beschriftung von Menüpunkten oder die Farben zu ändern, und speichert anschließend die gewählten Einstellungen in der Datenbank des Anbieters. Einige Wizards erlauben Ihnen auch, eigene Seiten und Inhalte anzulegen, meist ist diese Möglichkeit allerdings auf wenige Seiten und Inhalte beschränkt. Wer eine komplexe Lösung erstellen möchte, sucht hier also vergeblich.

Geringer Aufwand, geringer Nutzen

Die Einfachheit solcher Dienste ist auch gleichzeitig ihre Schwäche: sollen erweiterte Funktionen wie ein Kontaktformular eingebunden werden, stoßen viele dieser Dienste bereits an ihre Grenzen. Auch was die Kompatibilität mit verschiedenen Endgeräten angeht, sind die Möglichkeiten eher beschränkt. Oft wird nur eine iPhone- oder eine Webkit-Version aus den Daten erzeugt. Einfachere Geräte, die etwa keine Unterstützung für JavaScript bieten, bleiben dabei schnell außen vor. Auf der Kostenseite bieten alle Anbieter eine kostenlose Basisversion ihres Dienstes an. Wenn Sie etwa die Zahl der Unterseiten erweitern oder die möglichen Zugriffe pro Monat steigern möchten, sind Sie mit einer günstigen Monatspauschale ab ca. 5 Euro dabei.

Wirenode

http://www.wirenode.com/

„The mobile website creator“ heißt es, loggt sich ein Benutzer in seinen Wirenode-Account ein. Wirenode bietet ein simples Interface, mit dem Sie sich eine mobile Seite zurechtklicken können. Sie wählen aus verschiedenen Seitentemplates aus und erstellen anschließend über einen Richtext-Editor Seiteninhalte. Auch verschiedene Widgets wie z.B. die Einbindung der eigenen Twitter-Timeline werden angeboten. In der Basisversion ist Wirenode kostenlos und erlaubt es Ihnen, eine Site zu erstellen. Diese ist unter http://benutzername.wirenode.mobi erreichbar. Bei den vier kostenpflichtigen Versionen (zwischen 4,90 Euro und 190 Euro) können Sie mehrere Sites pro Account angelegen und eine eigene Domain verwenden.

Google Sites

http://www.google.com/sites/help/intl/en/mobile-landing-pages/mlpb.html

Auch Google bietet mit Google Sites seit kurzem die Möglichkeit, mobil optimierte Websites zu erstellen. „Mobilize your business“ heißt es auf der entsprechenden Produktseite. Entwickler können dabei aus einer Reihe von mobilen Templates für verschiedene Anlässe wählen (etwa „Restaurant“ oder „Local Businesses“) und über ein intuitives WYSIWYG-Interface Seiten erstellen, Inhalte anlegen und über einen Richtext-Editor formatieren. Über sogenannte „Gadgets“ bietet auch Google Sites die Möglichkeit, einen Twitter-Stream, das aktuelle Wetter oder eine Google Map in die Seite zu integrieren. Dabei ist jedoch Vorsicht geboten, denn auf Grund fehlender Geräteadaption bekommen auch alte Geräte ohne JavaScript-Unterstützung die Gadgets ausgeliefert, wodurch es zu Fehlern in der Darstellung kommen kann.

Onbile

http://www.onbile.com/

Ein sehr aufgeräumtes Interface, im positiven wie im negativen Sinne, bietet onbile seinen Nutzern. Positiv, da wirklich jeder, der einen Browser bedienen kann, ohne Probleme innerhalb von nur fünf Minuten mit einer mobilen Website an den Start gehen kann. Negativ, da die Möglichkeiten für Benutzer hier am restriktivsten sind. Die Anzahl der Unterseiten (vier inkl. Startseite) ist vorgegeben und kann derzeit weder erweitert werden, noch können Seiten entfernt werden. Als Benutzer dürfen Sie eines der rund 15 vorgegebenen Templates wählen, anschließend noch farbliche Anpassungen vornehmen und ein Logo hochladen. Alles in allem eine nette Spielerei, aber selbst für sehr kleine Unternehmen kaum eine ernsthafte Alternative, auch wenn die optische Gestaltung der Bedienoberfläche bei Onbile wohl für den Testsieg reichen würde. Auch die Tatsache, dass der Dienst vollständig kostenlos ist, ändert nichts mehr daran, dass Onbile höchstens dazu dient, um das Auge mit einem hübschen Interface zu erfreuen, als ernsthaft mobile Websites zu erstellen.

Clientseitige JavaScript Frameworks

In der Entwickler-Community stoßen sie auf ein großes Interesse und genießen einen hohen Stellenwert: mobile JavaScript Frameworks wie jQuery Mobile, SenchaTouch oder zepto.js. Spätestens seit dem Release des iPhones, das erstmals verdeutlichte, was auf mobilen Geräten im Browser möglich sein kann, gibt es eine ganze Reihe an Entwicklern, die sich auf die neue Touch-Geräte Generation spezialisiert haben und entsprechende Frameworks bereitstellen. Diesen Frameworks kommt zu Gute, dass sie auf HTML5 aufbauen und damit für die Zukunft gerüstet sind.

Diese Zukunftsfähigkeit hat wiederum zur Folge, dass deren „Vergangenheitstauglichkeit“ leidet, also dass hier Geräte, denen es an Unterstützung der recht neuen Standards mangelt, nicht ausreichend berücksichtigt werden. Vor allem ältere Geräte ohne JavaScript-Unterstützung, die gerade in so wichtigen Entwicklungsländern wie Indien, Brasilien oder der Türkei noch die überwiegende Mehrheit darstellen, können von den JavaScript-lastigen Frameworks nicht hinreichend bedient werden. Zwar ist es mit jQuery Mobile oder zepto.js noch möglich, durch „progressive Enhancement“, intelligentes Markup und klugen Einsatz von Stylesheets (bspw. durch Media Queries) zumindest eine mobile Seite mit Grundfunktionalitäten abzubilden, das ansonsten sehr ausgereifte SenchaTouch versagt hier jedoch auf ganzer Linie.

Gut, für gewisse Zielgruppen

So schön, einfach und crossbrowser-kompatibel derartige Frameworks auch angepriesen werden, so sind sie im Hinblick auf mögliche Zielgruppen durchaus kritisch zu betrachten und sollten nicht zu vorschnell eingesetzt werden. In Indien beträgt der Marktanteil des iPhones bspw. gerade einmal ca. 5% und auch Android-Geräte sind dort mit einem Marktanteil von unter 15% nicht wirklich breit vertreten. Wer also für einen Kunden aus Indien, dem nahen Osten oder Südamerika arbeitet, der sollte sich gut überlegen, ob er mit SenchaTouch nicht vielleicht an der Zielgruppe des Kunden vorbei entwickelt.

Doch genug zu den Nachteilen, selbstverständlich bieten diese Frameworks Entwicklern von mobilen Websites eine ganze Reihe echter Vorteile, die den Einsatz wirklich reizvoll und lohnenswert machen. Ein eben schon erwähnter Vorteil ist die Zukunftstauglichkeit: HTML5 eignet sich auf Grund seiner Eigenschaften als generische Markup-Sprache hervorragend für die Entwicklung mobiler Websites. Hinzu kommt, dass Entwicklern ein ganzes Arsenal an Tools zur Verfügung steht, die bereits auf den allermeisten Geräten der aktuellen und kommenden Generationen funktionieren. Ob Buttons, die in ihrem Verhalten an die Buttons des Geräte-Betriebssystems angelehnt sind, oder stilvolle Slide-Effekte beim Aufruf einer neuen Unterseite. Um all diese visuellen Schmankerl muss sich der Entwickler keine Gedanken mehr machen. Zusammenfassend kann festgehalten werden, dass JavaScript-Frameworks eine einfache und gute Möglichkeit sind, um schnell Ergebnisse zu erzielen. Ohne auf eine serverseitige Sprache zurückzugreifen, ist es dabei jedoch nicht ohne weiteres möglich, die Inhalte einer bereits bestehenden Seite im Nachhinein zu übernehmen.

jQuery Mobile

http://www.jquerymobile.com/

jQuery Mobile basiert vollständig auf dem verbreiteten JavaScript-Framework jQuery, nutzt also dessen bewährten Funktionsumfang und gibt Entwicklern somit ein Tool an die Hand, um innerhalb kurzer Zeit ansehnliche, bedienbare mobile Websites zu erstellen. Ausgangspunkt für jQuery Mobile ist sauberes HTML5 Markup, das über vordefinierte data-role-Attribute semantisch erweitert wird. So können Sie einen Seitenbereich über

einfach zu einem feststehenden Seitenheader deklarieren. jQuery Mobile bietet eine Reihe solcher Zusatzfunktionen, die über unaufdringliches JavaScript realisiert werden Wie der große Bruder jQuery steht jQuery Mobile unter GPL 2.0 und MIT zur freien Verfügung.

Sencha Touch

http://www.sencha.com/

Der Name impliziert es bereits: die Ausrichtung von Sencha Touch liegt ganz klar auf Geräten mit Touch-Bedienung. Da dies in der Hauptsache neuere Geräte sind, ist es auch nur wenig verwunderlich, dass das komplette Framework auf JavaScript aufbaut und für die Erstellung einer mobilen Website mit Sencha Touch nicht eine einzige Zeile HTML5-Markup benötigt wird. Obgleich Sencha von sich behauptet, das erste „HTML5 Mobile Web App Framework“ zu sein. Die gesamte Entwicklung einer mobilen Website bzw. Web App basiert auf JavaScript, für die visuelle Gestaltung kommt CSS zum Einsatz. Kompatibel ist Sencha zudem nur mit Webkit-Browsern (Safari, Chrome, …), Firefox und Opera Nutzer bleiben außen vor. Trotz des kommerziellen Backgrounds, Sencha Touch wird von der Sencha Inc. entwickelt, steht die Library aktuell noch unter der GPL 3.0 zur freien Verfügung. Dies gilt sogar für kommerzielle Projekte.

zepto.js

http://www.zeptojs.com/

„The aerogel-weight mobile javascript framework“. Das ausgesprochene Ziel von zepto.js ist es, eine JavaScript Library anzubieten, die nur 2-5 Kilobyte an Größe mitbringt und dem Entwickler dennoch alle Aufgaben abnimmt, für die sonst mühsame Fleißarbeit fällig würde. Die Syntax von Zepto.js ist stark an jQuery angelehnt. Entwickler, die bereits Erfahrungen mit jQuery oder anderen Frameworks gesammelt haben, werden sich schnell damit zurecht finden. Das Ziel, die Größe von 5 KB nicht zu überschreiten, erreicht zepto.js dadurch, dass mobile Randgruppenbrowser wie der Internet Explorer aber auch Opera Mobile derzeit außen vor gelassen werden. So funktioniert zepto.js, was sich zum aktuellen Zeitpunkt, ähnlich wie auch jQuery Mobile, noch in der Beta befindet, am besten auf Webkit-Browsern (iPhone, iPad, Android, …), aber auch im Firefox Mobile.

Serverseitige Verarbeitung von Anfragen

Eine weitere Möglichkeit, um Websites für mobile Geräte zu optimieren, ist die serverseitige Erzeugung von mobil optimierten Seiten. Dies passiert in der Regel durch die Ermittlung des aktuellen Client-Geräts durch den vom Browser gesendeten User Agent Header. Um auf ein Endgerät angemessen reagieren und eine tatsächlich optimierte Seite ausgeben zu können, sind bei dieser Methode Kenntnisse über die verwendete Kombination aus Gerät, Betriebssystem und Browser notwendig. Zu diesem Zweck gibt es Datenbanken mit ausführlichen Informationen über diverse am Markt erhältliche Geräte, die Angaben über die Bildschirmgröße, unterstützte HTML-Formate oder den Gerätetyp (z.B. Desktop, Mobile, Tablet, …) enthalten.

Diese Methode hat jedoch zwei Nachteile: zum einen prüft sie nur auf theoretische, nicht auf tatsächliche Geräte-Features. Sie kann also ermitteln, dass ein Gerät JavaScript-Unterstützung bietet, nicht jedoch, ob der Benutzer JavaScript-Unterstützung vielleicht clientseitig deaktiviert hat. Zum anderen ist das Verfahren insofern unzuverlässig, als dass der User Agent in den Browser-Einstellungen verschleiert oder geändert werden kann. Außerdem kann es zu Problemen kommen, wenn der User Agent noch zu neu ist, um von der Datenbank erkannt zu werden. Zumindest das erste Problem können Sie durch cleveres Markup umgehen, indem Sie z.B. gleichzeitig eine JavaScript- und eine Non-JavaScript-Version der Website ausliefern. Beim zweiten Problem können Sie lediglich auf schnelle Updates der Anbieter der entsprechenden Datenbank hoffen.

Der große Vorteil bei der serverseitigen Erzeugung einer Seite ist, dass Sie ein Dokument schon vor der Auslieferung auf das Endgerät auf die möglicherweise beste Darstellung hin optimieren können. Große JavaScripts, die viel Ladezeit benötigen, müssen so bspw. gar nicht erst an den Browser ausgeliefert werden. Bilder können Sie bereits auf dem Server auf die maximale Höhe und Breite des Displays skalieren. Das spart Akkuleistung, Übertragungskosten und lädt zudem die Seite schneller.

WURFL

http://wurfl.sf.net/

Pionier auf dem Gebiet der Gerätedatenbanken ist das Wireless Universal Resource File, kurz WURFL. Es enthält viele nützliche Geräteinformationen, die von der Open Source Community bis heute intensiv gepflegt werden. Im Kern besteht WURFL aus einem unheimlich großen XML-File mit Angaben über die Geräte. Mittlerweile gibt es aber Implementierungen in sämtlichen relevanten Sprachen wie PHP, Java, .NET, Python oder Perl. Durch die freiwillige Pflege der Open Source Community ist WURFL nicht immer auf dem neusten Stand und enthält zudem zu einigen Geräten fehlerhafte Angaben, die erst spät behoben werden. Ein kleines Manko, dafür erhalten Sie mit WURFL eine ansonsten solide Datenbasis, die für kommerzielle Projekte einmalig mit 1500 Dollar zu Buche schlägt.

DeviceAtlas

http://www.deviceatlas.com/

Genau wie auch WURFL besteht der DeviceAtlas aus einer Datenbank mit unzähligen Informationen über diverse Endgeräte. Anders als WURFL wird der DeviceAtlas jedoch kommerziell vertrieben. Eine Lizenz mit 1 Mio Datenbankabfragen ist für 399 Dollar im Jahr erhältlich. Für diesen stolzen Preis erfährt der DeviceAtlas jedoch Unterstützung von großen Unternehmen aus dem mobilen Geschäft: Nokia, Sony Ericsson oder auch Vodafone werden als Partner aufgeführt. Entwickler, die in ihren Projekten gern kommerzielle Unterstützung erhalten möchten, dürften sich beim DeviceAtlas gut aufgehoben fühlen.

Das Beste aus beiden Welten

Für eine gute User Experience im Bereich der mobilen Webseitenerstellung hat sich in vielen Fällen ein Mittelweg aus den beiden letztgenannten Technologien bewährt. Eine serverseitige Erkennung des Zielgeräts und anschließend eine clientseitige progressive Erweiterung der ausgelieferten Seite, je nachdem, welche Features ein Gerät tatsächlich unterstützt. Ältere Geräte erhalten dabei eine uneingeschränkt bedienbare mobile Seite, mit allen Inhalten, serverseitig skalierten Bildern und ohne JavaScript. Neue Geräte mit JavaScript-Unterstützung und hoch aufgelöstem Touch-Display erhalten eine aufgehübschte Nutzerführung mit Bildern in hoher Auflösung, Effekten wie CSS3 Transformationen und jQuery-Mobile-Erweiterungen.

fitml.com

http://www.fitml.com/

Diesen Weg verfolgt Sevenval mit seinem Cloud-Service fitml.com. Mit einer eigenen, FITML genannten Markup-Sprache können Entwickler XML-Dokumente erstellen, die je nach Gerät zum Teil völlig unterschiedlich dargestellt werden. So bekommen technisch ausgereifte Geräte ansprechende und hochwertige HTML5-Seiten ausgeliefert, die mit JavaScript und CSS3 angereichert werden, ohne dabei jedoch alte Geräte ohne HTML5 Support auszuschließen. Der Vorteil dieser Lösung ist die Markup-Abstraktion, so dass Sie nur FITML verwenden müssen, die Cloud-Plattform kümmert sich anschließend um die optimale Ausgabe auf allen Geräten. Dabei werden sowohl serverseitige Parameter als Ausgangsbasis, als auch zusätzliche clientseitige Abfragen zur weiteren Fein-Optimierung verwendet. Kleinere Seiten können dort kostenlos entwickelt werden. Für größere Auftritte bietet die Plattform abhängig von der Anzahl der monatlichen Page Impressions unterschiedliche Preismodelle.

Why create a mobile website instead of an application? Using the web has a number of advantages, websites can be browsed on most devices, the technology is flexible, and it is easy to update sites so all users get the latest version. You only need to modify a single codebase if you want to add or change content or even features, rather than updating each application.

Context Is King

When you create a website for desktop browsers you typically design and develop for a context in which a user has a large display, enough time, power and also a fast persistent internet connection. None of these are guaranteed when using the internet on mobile devices.

Although most new devices have much larger screens than devices a few years before, they are mostly still small compared to desktop devices. Beyond that users often access a mobile website when they are on the go and they may be focusing on other things in addition to the web site they are using because they have to look at the traffic for example.

Other problems to consider are the effects of a weak signal and a slow mobile internet connection. Since the average internet user is impatient, you can easily lose a user who has to wait too long for pages to load – they may obtain the information elsewhere. Therefore you should try to keep content such as external scripts and images as small as practical.

You should consider these factors when you are about to design a website for mobile devices. Focus your mobile web strategy on what content a user is probably looking for when they visit your website. They are unlikely to be interested in your awesome company intro page animation made in Flash. Beyond you should also think about the contexts in which your mobile site will be used before you begin to design a mobile website.

It could be in a train with a weak signal, in a village with poor connection speed, outside in a sunny environment on a top-notch smartphone with touchscreen display as well as on an older feature phone with an even older browser and keypad operation. You cannot influence the context a user is in but you can design your site to be useable under all these circumstances.

Usability Aspects

After thinking about content and context it is equally important to consider usability. It is not only a matter of what content is interesting for a user and the contexts in it will be consumed but also a matter of how your target audience will use your site. Navigating your site is less fun when doing it using the device’s keyboard instead of just using your finger on a large screen but it can be easier if the links within your page are so damn small that it is almost impossible to hit them without causing unwanted behavior (like tapping other links as you actually wanted to). There are some basic hints to make sure your content is adapted in the best possible and usable way for mobile users:

1. Make it “mobile” not only “small”: Create a concept that utilizes the possibilities of the technology. You won’t satisfy many people by simply offering a smaller version of your classic website. Mobilize, don’t miniaturize!
2. Keep all paths open: Leave it up to the user to access either the mobile or desktop version of your website.
3. Keep it simple: Avoid complex navigation structures, users will not dig that deep anyway while they are on the go.
4. Avoid text input wherever possible: Text input on mobiles sucks. If you really need the users to enter text, use wide input boxes so that they see what they are typing. Buttons to clear an input field on click/touch are also helpful very often.
5. Adapt the media: Adapt all pictures, videos and alike to be displayed properly on the handset (check the corresponding chapter in this guide: “Implementing Rich Media” for more information). Try to avoid formats such as .doc and pdf if possible.
6. The user is a creature of habit: respect that: Adapt usage patterns from classic websites such as linking logos to the homepage or offering corrections to mistyped search requests.
7. Think of stubby fingers: When optimizing your content for touch screen phones do not use clickable areas smaller than ~50x50px.
8. Use sharp contrasts: Fonts and background colors that guarantee legibility in any surrounding, including bright sunlight.
9. Reflect continuously: Ask yourself if you would use the implemented features yourself. Ask your friends and colleagues as well before realizing your ideas.
10. Do not require the user to think. Try to implement intuitive navigation, do not force users to make decisions more often than necessary.

Technical Limits of Web Technologies

When it comes to the decision whether to create an app or a mobile website for a specific project many mobile developers tend to say “app” first because you seem to have more possibilities and better performance. This answer is seldom wrong but it is only half the truth. Let’s have a detailed view on the advantages and disadvantages of mobile websites or web apps compared with native mobile apps.

If you are coming from the “desktop world” and you have never created a website for mobile devices before (or if the last time you did is already a long time ago) you will be surprised about the capabilities of modern mobile phone’s web browsers. Assuming that you intend to optimize your mobile website mainly for modern platforms you would also create apps for (iOS, Android, BlackBerry OS, WebOS, bada, Windows Phone) we will primarily focus on modern browsers running on the mentioned platforms in this chapter.

The current generation browsers on major platforms support a variety of modern HTML5, CSS and JavaScript features like Geolocation, WebGL (interesting for mobile game development), hardware acceleration, offline storage and many more. You can easily find out if a user is online or offline, you can synchronize online data on a device for later offline use (e.g. if the signal is lost) and you can make whole web applications available even when a user has no active internet connection.

You can ask for permission to query the current position of a user just like you can do in a native app and you can also access the gyroscope of an iPhone using pure JavaScript directly in the browser. In addition mobile browser vendors are also working on making it possible to access the phone’s camera, network status or address book data.

Sounds pretty app like, doesn’t it? JavaScript is still often underestimated but if you know how you can rapidly create high class web apps which make extensive use of a device’s capabilities (almost) without the need to create proprietary versions for each platform.

And that’s not all: almost all recent mobile browsers support a lot of the current CSS3 standard and so you can create nice and shiny things like transitions, custom web fonts, drop shadows or rounded corners with only little effort which makes it very easy to let your web applications look and feel like native apps.

Pitfalls? Issues? Of course there are some. Although modern browsers already have a wide range of device API support there are still things you cannot yet do inside a browser. Accessing the camera as already mentioned is one thing. You cannot prevent the device from going to standby mode on a website which can sometimes be a problem. And sure: you will need to implement your own user interface in HTML, CSS and JavaScript instead of just using the native GUI functionality which is a bit faster in most cases. But if your code is clean and effects are used wisely the performance difference to native apps is so small that a user probably will not even realise he is just using a web app instead of a native app.

Fragmentation

“In mobile, fragmentation is forever”. Unfortunately it is not always as easy to create a cross-device cross-platform crossbrowser cross-markup “cross-blahblah” mobile website as you might think. Dealing with many different devices also results in an annoying fragmentation jungle. Some devices use their own implementation of device APIs (i.e. Geolocation on Blackberry OS 4.6) or even have absolutely no support for certain features (i.e. filesystem access on iOS).

This means you have to write workarounds of your code for different platforms and even for the same browser running on different platform versions. But the web wouldn’t be the web if there wasn’t already a solution for almost all of these problems. And so there are sites, libraries and services like caniuse.com, Modernizr or fitml.com where you can build quick and clean workarounds to handle fragmentation issues with only a minimum of effort. You still only need to write most parts of your web app once.

Server-Side vs. Client-Side Adaption

Basically there are two different approaches to professional mobile web development if you aim to deliver a great user experience. Either way you will have to determine which (type of) device is sending a request to your website and then you need to “guess” (server-side) or test (client-side) what features are supported by the according device.

Server-Side Detection and User Agent Sniffing

The first possible way is to do so using the so called “user agent sniffing” on the server-side and then let your server create and deliver an optimized version of your site to the client. Serverside detection is usually based on large databases containing the user agents of thousands of devices and their capabilities. The most common use of server side adaption is image scaling on the server to save some bytes when delivering a big image to a mobile device. In most cases it is not necessary to deliver a 800×600 JPG with a file size of 120K to a device whose display resolution is only 320×480. So you typically resize the image to the display size of the mobile device and then serve a much smaller version to the client.

Service-side detection can be a good choice for other reasons. You can also decide which markup to deliver based on the user agent of the accessing device. If you have a visitor with an iPhone or an Android phone you can serve a nice HTML5 document while users with old Nokia devices will receive an old fashioned XHTML 1.1 document.

The advantage of server-side adaption is that you optimize all the content to serve only what a client probably really needs. And “probably” is also the problem here. New devices are released so often it is hard to keep a device database entirely upto- date. There are some commercial providers for device databases (WURFL, DeviceAtlas, fitml.com for example) if you want to realize mobile web projects with server-side user agent detection I strongly recommend you consider one of these as they have full time employees actively maintaining their databases and do a lot of work that would be impractical for you to do yourself.

Pitfall here: user agents can be “wrong”, manipulated or unknown. You should therefore always provide a fallback in case your user agent detection fails. Such a fallback could be a document in a format (i.e. HTML4) that almost every mobile browser released in the past 5 years can understand.

Client-Side Adaption and Feature Detection

Client-side feature detection is the second approach to create a great user experience on mobile websites. Feature detection in general means that you use JavaScript to look if a certain capability is supported on the accessing device. To give you a first impression: you can use if(navigator.geolocation) to check if a device supports acquiring of the user’s current position.

Feature detection also means that you will have to deliver the complete document with all possible features of the website in it and then gracefully degrade it by removing features which are not supported on the device. That means you are sending a lot of content to all devices regardless of whether a certain feature is supported on a device or not.

One big advantage compared to server-side adaption: when a feature test passes you can (under normal conditions) be sure that your desired feature or behavior will work as expected even if a user agent was modified and therefore was not recognized properly by a device capability database.

The Modernizr JavaScript library is probably the first place to go when it comes to client-side feature detection. Modernizr covers a lot of possible browser capabilities and provides a simple API to check for support of a certain feature. If you need to know whether a browser supports Drag and Drop or not, just use the Modernizr library this way:

if(Modernizr.draganddrop) {
	// browser supports native drag and drop
} else {
	// fallback
}

Another part that belongs to the client-side is the adaption of layout. On modern mobile browsers you can use media queries which let you apply CSS rules only if a client or browser matches certain conditions. You can easily show a two column layout when a device exceeds a display width of 800px (on tablets for example) and fall back to a linear one column layout when a device’s display has a resolution of less than 800px.

Issues concerning client-side approach: first there are some things, especially browser bugs, which may be hard to detect on client side. Another big problem is that you always have to serve the whole document with large scaled images and a bunch of JavaScript to the client since you do not know if your visitor is using a bleeding-edge hipster browser from Cupertino or an oldschool “I don’t know what JavaScript is” browser from 2003.

Why not just use the best of both worlds?

Excellent idea! There is of course no rule that forbids to combine both server-side and client-side technology to create an even better user experience. So you can try to determine the basics (“which markup should be used?”, “what is the correct size for images?”, “JavaScript support, yes or no?”) on the server and let the client handle the rest. You can provide server-side fallbacks for JavaScript enhancement to make a site accessible and so you can create mobile websites which even work fine on old devices.

A commercial platform working according to this principle is fitml.com where you describe your content in an abstract XML markup called FITML, the platform then converts your markup to the best suitable output format and optimizes both on serverside and on client-side.

Hybrid Apps

If you necessarily want (or need) to publish your mobile app on Android Market, Apple Appstore, etc. you can also create a “hybrid app”. Create your app completely by using common web technologies (HTML, CSS, JavaScript) and then compile it as app. Sounds easy? It is. There are several hybrid app frameworks which let you create native apps with only a single HTML5 web app as shared base. There is PhoneGap2, Appcelerator3 or Apparat. io4 and probably many more you can use to achieve this.

How does it work exactly? Write your complete application in HTML5 just as you were about to publish it to the web. Then you use one of the frameworks to compile your web app as native app. The framework creates some sort of “wrapper app” which embeds your web app in a “web view” and it can then be installed as regular application on several different platforms. The big plus of doing it this way is that you only have one web app as the base and thus you can reduce your costs for development and maintaining but the result is still a “real” native app.

Small downer: although frameworks let you use features in your web app which you usually cannot use in a browser hybrid apps are not a complete substitute for native apps. They offer some nice advanced functions like vibration, access to camera or address book but in its core it still is a web app. That means you will have to create your own user interface which might be slower and you also cannot use really everything as you can when creating an app using the native SDK.

Lessons learned

The gap between native apps and web apps is rapidly decreasing. Browser vendors did a lot of good work in the past few years and implemented many features which were only available in native apps. There are different approaches to create great mobile websites which can look and even feel a lot like a native app and new devices will be released that have even better support for HTML5 and its device specific enhancements.

Creating mobile websites or mobile web apps makes your content accessible over the web on almost every platform with only little work compared to native development for several platforms. It can thus save you a lot of costs for development and maintenance. Due to the existence of hybrid app frameworks you can even publish your apps in app stores.

If you have never developed a mobile website or web app before or if you were not convinced because of the poor browsers in the early days of the mobile web you should give it another try. Consistent support of the many different features is still far from perfect but it has been improved by at least 1000% since the rise and success of Android and iOS.

When you became curious and want to create a mobile website always have one thing in mind: make your mobile website mobile, not just smaller!

This article was published in the Mobile Developer’s Guide To The Galaxy #9 in October 2011. You can download it for free.

A short test on performance when using IDs in CSS selectors:
– http://oli.jp/2011/ids/

Nice trick: Fixing the JavaScript typeof operator
– http://javascriptweblog.wordpress.com/2011/08/08/fixing-the-javascript-typeof-operator/

Understanding prototypes in JavaScript
– http://yehudakatz.com/2011/08/12/understanding-prototypes-in-javascript/

How LinkedIn used Node.js and HTML5 to build a better, faster app
– http://venturebeat.com/2011/08/16/linkedin-node/

Advantages of Most Perpetual Web Development Technologies – PHP, ASP.NET, Java, Ruby on Rails
– http://phpwebdevelopmentservices.blogspot.com/2011/05/advantages-of-most-perpetual-web.html

10 Excellent HTML5 coding Tools Many Users Don’t Know About
– http://smashinghub.com/excellent-html5-coding-tools.htm

I created a small JavaScript library to provide some basic geo functions like distance calculation, conversion of decimal coordinates to sexagesimal and vice versa, etc.

Usage:

To calculate distance between two geo coordinates
geolib.getDistance({"latitude": 51.511928, "longitude": 7.463536}, {"latitude": 51.510318, "longitude": 7.524133}, 10); // -> 4200 (Accuracy 10m)

Takes 2 or 3. First 2 arguments must be an object with a latitude and a longitude property (e.g. {latitude: 52.518611, longitude: 13.408056}). Coordinates can be in sexagesimal or decimal format. 3rd argument is accuracy (in meters). So a calculated distance of 1248 meters with an accuracy of 100 is returned as 1200.

Return value is always an integer and represents the distance in meters.

To convert it into miles use:
geolib.convertUnit('mi', value)

Convert sexagesimal to decimal
geolib.sexagesimal2decimal("51° 29' 46\" N"); // -> 51.49611111

Convert decimal to sexagesimal
geolib.decimal2sexagesimal(51.49611111); // -> 51° 29' 46.00

Download:
https://github.com/manuelbieh/geolib

Demo:
http://www.manuel-bieh.de/publikationen/scripts/geolib/demo.html

18 mistakes that kill startups
– http://www.paulgraham.com/startupmistakes.html

7 lovely things about HTML5
– http://www.elated.com/articles/7-lovely-things-about-html5-markup/

Lists are cool. So here is another one: 15 HTML5 Canvas Applications Developers Should Know About
– http://smashinghub.com/15-html5-canvas-applications-developers-should-know-about.htm

CSS3 @font-face design guide
– http://webdesignerwall.com/tutorials/css3-font-face-design-guide

Published more than a year ago but still worth reading: Signs of a poorly written jQuery plugin:
– http://remysharp.com/2010/06/03/signs-of-a-poorly-written-jquery-plugin/

Many of you have probably used or at least heard of the famfamfam silk iconset in the past. 1000 free 16×16px icons for every purpose you can think of. Many websites or software packages are using it.

But 1000 icons means (in case you really use all of them) 1000 HTTP requests which is really a lot. And even if you’re using only ~100 icons, that’s still a lot of HTTP requesting.

For this reason I created a small CSS sprite version of the popular iconset including all 1000 icons in one single 299K png file + 1 stylesheet (56 KiB). (Filesize was reduced almost by half! (355K instead of 646K, that’s a reduction by 46%)).

Usage

Very simple. Just add a span to your markup, then add the class „icon“ and „iconname„.

Example:
<span class="icon attach"></span>

Download

Grab the file here:
http://www.manuel-bieh.de/publications/download/fff-sprites.zip

License

As the original iconset, the sprite is filed under Creative Commons Attributions 2.5

Adobe tries to bring the functionality of print publishing programs like InDesign to CSS. They called it „CSS regions“ and built a prototype that looks really interesting and promising:
– http://www.adobe.com/devnet/html5/articles/css3-regions.html
And there’s already a jQuery plugin as polyfill to play around with all these cool features:
– https://github.com/ricardrobin/Regions.js

A problem that doesn’t really bother you a lot when developing for mobile but css-tricks.com published some numbers about the fact that screen resolution is ≠ browser window size:
– http://css-tricks.com/9778-screen-resolution-notequalto-browser-window/

If you want to enrich your website’s data with some very useful HTML5 microdata and you’re looking for the right schema. Maybe we’ve got the right website for you:
– http://schema.org/docs/gs.html

Input “Type=Image” Considered Harmful (and how to fix)
– http://blog.vurve.com/2011/06/18/input-typeimage-considered-harmful/

This one is so cool: pdf.js is a javascript library to display PDF’s in your browser using the canvas element:
– https://github.com/andreasgal/pdf.js

Let’s Make a Framework is an ongoing series about building a JavaScript framework from the ground up:
– http://dailyjs.com/2011/06/02/framework-65/

An article about the new CSS calc() function. A feature we all have been waiting for a long time and yes: it already works in Firefox 4 and even in IE9(!):
– http://webdesignernotebook.com/css/the-wonderful-calc-function/

Jeremy Keith has created a list of collected design principles, divided into five categories: people, organisations, formats, software, hardware. Definately worth reading:
– http://principles.adactio.com/

30 Creative Examples of Responsive Web Design
– http://webdesignledger.com/inspiration/30-creative-examples-of-responsive-web-design

A web-based DJ prototype plus a really comprehensive post about how it was created:
– http://wheelsofsteel.net/
– http://www.schillmania.com/content/entries/2011/wheels-of-steel/

If you want to develop websites or web apps for mobile using several different content sources like Twitter API, RSS feeds or your existing desktop website, you should consider to have a look at fitml.com which was released as public beta at the beginning of this week (disclosure: I work for Sevenval, the company behind fitml.com)
– http://fitml.com

Nice demonstrations of what you can do with webfonts in combination with CSS3
– http://webfontgallery.com/

An overview of new features coming in iOS 5
– http://davidbcalhoun.com/2011/new-mobile-safari-stuff-in-ios5-position-fixed-overflow-scroll-new-input-type-support-web-workers-ecmascript-5

If you have to re-style large data tables for mobile and you have no idea how, this article on responsive data tables might help:
– http://css-tricks.com/responsive-data-tables

You have recently made any award-worthy CSS3 animations and now you wanna win your deserved prize for it? Submit it to the Mozilla DevDerby:
– https://developer.mozilla.org/en-US/demos/devderby

A browser tictactoe game including a computer opponent with only HTML and CSS – completely without JavaScript. You think that’s impossible? No it’s obviously not:
– http://jsdo.it/usualoma/qzfr

fitml.com 1.0 beta is now online. The awesome mobile development platform I’ve been working on in the past 8 months is now online. Sign up and give it a try!
– http://fitml.com

Another private showcase I’ve been working on went online yesterday. It was created during my daily trainride from Dortmund to Cologne and back. Check out my (yet little) HTML5 and CSS3 showcase
– http://doctypehtml.net/

I created a small jQuery plugin which acts as a simplification of the Geolocation API.

Instead of using navigator.geolocation.getCurrentPosition you can now just use the jQuery methods $.geolocation.get() or $.geolocation.watch().

Contrary to the standard API the only parameter the functions expect is a JSON object with three properties in no particular order: success, error, options. For success and error you can also use their alias properties „win“ and „fail“:
$.geolocation.get({win: function() {}, fail: function() {}, options);

You can also use $.geolocation.getCurrentPosition(success, error, options) to get native API feeling if this makes you happier. In conjunction with my Geolocation API polyfill script this also works with some non-standard Geolocation APIs like Google Gears or Blackberry Location.

Usage

$.geolocation.clearWatch(watchID)

Stops tracking of the user for the according watchID.

watchID (Integer)

$.geolocation.get(options)

Get the current position of the user

options (Object)

• error
  Function to call if geolocation request failed
• fail
  Alias for error
• options
  Options for the geolocation request
  • enableHighAccuracy
  • maximumAge
  • timeout
• success
  Function to call if geolocation request was successful
• win
  Alias for success

$.geolocation.getCurrentPosition(success, error, options)

Get the current position of the user (API standard behavior)

success Function to call if geolocation request was successful

error Function to call if geolocation request failed

options Options for the geolocation request

• enableHighAccuracy
• maximumAge
• timeout

$.geolocation.stop(watchID)

Stops tracking of the user for the according watchID.

watchID (Integer)

$.geolocation.stopAll()

Stops all watchPosition callbacks.

$.geolocation.watch(options)

Track the movement of the user

Returns: watchID (Integer)

options (Object)

• error
  Function to call if geolocation request failed
• fail
  Alias for error
• options
  Options for the geolocation request
  • enableHighAccuracy
  • maximumAge
  • timeout
• success
  Function to call if geolocation request was successful
• win
  Alias for success

$.geolocation.watchPosition(success, error, options)

Track the movement of the user (API standard behavior)

Returns: watchID (Integer)

success Function to call if geolocation request was successful

error Function to call if geolocation request failed

options Options for the geolocation request

• enableHighAccuracy
• maximumAge
• timeout

Examples

Demo

http://manuel-bieh.de/publikationen/scripts/jquery/geolocation/

Download

https://github.com/manuelbieh/jQuery-Geolocation

Mit diesem Plugin ist es möglich Checkboxen und Radiobuttons zu stylen.

Anwendung:

Einfach jedem Form-Element dessen Checkboxen und Radiobuttons gestyled werden sollen die Klasse „styleform“ anhängen. Alternativ kann das Styling auf alle oder nur ausgewählte Formulare angewandt werden:
$('form').styleForm();
$('#myForm').styleForm();

Styling:

Es kann entweder ein eigenes Stylesheet erstellt werden mit eigenen Eigenschaften für die klassen .styleRadio und .styleCheckbox was allerdings recht kompliziert ist, da es kein sauberes Standard-Stylesheet ist das angewandt werden kann. Daher empfiehlt es sich, einfach die mitgelieferten Bilder im images-Ordner so zu bearbeiten wie man es wünscht.

Bonus!

Ein iPhone Theme wird in drei größen mitgeliefert.

Bekannte Probleme:

• Opera ignoriert die disabled Eigenschaft komplett

Wünsche:

• Styling von select Elementen ermöglichen

Demo

http://www.manuel-bieh.de/publikationen/scripts/jquery/styleform
http://www.manuel-bieh.de/publikationen/scripts/jquery/styleform/iphone.html

Download

http://plugins.jquery.com/project/Styleform

English description

You can use this plugin if you want to change the default look of checkboxes and radiobuttons.

Usage:

Just add the class „styleform“ (all lowercase) to any form you want to be styled. Or you can alternatively use:
$('form').styleForm();
to apply the styling of checkboxes and radiobuttons in all forms inside a document.

Styling:

You can either create a new stylesheet with your own properties styling the .styleRadio and .styleCheckbox classes which is however quite complicated since there is no default stylesheet that can be applied yet. Or you can (the easy way) use the provided themes and edit the files inside the images folder the way you want it.

Bonus:

iPhone theme included in three different sizes (small, normal, big)!

Known issues:

• Opera ignores the disabled state completely

Wishes:

• Add styling of select elements

Demo

http://www.manuel-bieh.de/publikationen/scripts/jquery/styleform
http://www.manuel-bieh.de/publikationen/scripts/jquery/styleform/iphone.html

Download

http://plugins.jquery.com/project/Styleform

Mobiles Webdesign bedeutet in der Praxis, dass man eine für Desktop-PCs gestaltete Webseite für die kleinen Screens der Smartphones oder Tablets umgestaltet. Oder nicht?
Mobiles Webdesign bedeutet in der Praxis im Grunde genommen mehr, als der Begriff Webdesign vermuten lassen würde. Bei einer mobilen Website stehen neben dem eigentlichen Design an sich bei der Adaption einer bestehenden Website vor allem wohl konzeptionelle Gedanken an erster Stelle.

Mit welchen Konsequenzen?
Wie auch bei einer gewöhnlichen Website für Desktop-PCs werden eine ganze Reihe Vorüberlegungen notwendig. Welche Inhalte werden von der bestehenden Website übernommen? Gibt es mobil spezifische Inhalte, die sich auf dem Handy aufgrund der gegebenen Umstände besonders anbieten? In der Hauptsache dürften das wohl standortbezogene Dienste sein wie z. B. der klassische Tankstellen- oder Restaurantfinder. Grob lässt sich der Prozess des mobilen Webdesigns aber tatsächlich so wie von Ihnen genannt beschreiben: nämlich die Adaption der für Desktop-PCs gestalteten Website für kleinere Screens.

Gilt heute nicht eher Handys und Smartphones zuerst, wenn es um das Design einer Seite geht?
Das kann so sein, muss aber nicht unbedingt. Zwar gibt es diverse Studien und Hochrechnungen von Expertengruppen, die besagen, dass in einigen Jahren bis zu 90 Prozent des Internettraffics über Handys und Smartphones abgewickelt werden wird. Doch davon sind wir immer noch ziemlich weit entfernt. Im Grunde genommen kann man sagen, dass in der heutigen Zeit sowohl die Desktop-Version als auch die mobile Version einer Website allmählich eine ähnlich hohe Priorität genießen sollten.

Für welche mobilen Plattformen (OS) muss das mobile Design angeboten werden?
Die Fragmentierung der Plattformen erstreckt sich hier nicht, wie am Desktop, über 3 bis 4 große Browser, sondern über diverse Geräte mit diversen Betriebssystem-Versionen und entsprechend unterschiedlichen Browsern, die alle ihre Eigenarten haben. Ein aktuelles Must-have in Sachen mobile Plattformabdeckung sind, und das wird sich wohl auch in der nächsten Zeit erst einmal nicht ändern, natürlich die Platzhirsche Apples iOS und Android. Aber auch neue Systeme wie das Palm WebOS oder das neue BlackBerry OS 6 sollte man unbedingt im Auge behalten.

Welche Schriftarten können mobile Geräte darstellen?
Neuere Browsergenerationen auf Smartphones unterstützen die Schrifteinbettung von CSS3 und könnten somit theoretisch jede beliebige Schrift darstellen. Bei älteren Geräten hatte man oft nur die Wahl zwischen serif und non-serif. Bei noch älteren gab es oft sogar nichtproportionale Monospace-Schriften. Die Zeiten haben wir inzwischen längst hinter uns gelassen. Mittlerweile sollte man ganz gut fahren, indem man auf die bekannten Desktop-Fonts setzt und als Fallback im CSS eben „serif“ oder „non-serif“ angibt. Das Thema Schrift ist dank CSS3 ein sehr komplexes.

Mobil sein, heißt auch oft, auf das heimische schnelle WLAN verzichten zu müssen. Was sollte man weglassen an Ballast für mobile Seiten?
Der hier wohl sinnvollste Tipp ist, dass man große Bilder möglichst bereits serverseitig auf die Displaygröße des Geräts kleinskalieren sollte. Dabei helfen Dienste wie die eben bereits angesprochenen oder auch TinySrc (www.tinysrc.net). Wer dann noch auf einen sauberen und validen XHTML- oder HTML5-Quelltext achtet, der sollte mit einer langsamen Verbindung keine Probleme bekommen.

Ist es überhaupt nötig, Websites an die Darstellung auf dem Smartphone anzupassen?
Ja. Auch wenn bspw. Apple damit wirbt, auch herkömmliche Websites komfortabel auf dem iPhone benutzen zu können, ist die Auslegung dieser Website doch immer eine andere. Nicht nur das Display ist kleiner, sondern auch die Bedienung und dadurch die komplette Usability. Das größte Problem beim Betrachten einer herkömmlichen Desktop-Website auf dem Handy ist gar nicht mal die Auflösung der Seite, sondern vielmehr die mangelhafte Bedienung. Es muss umständlich in die verschiedenen Seitenbereiche gezoomt werden, um den Text vernünftig lesen zu können, verlinkte Inhalte sind oft von der Klickfläche her zu klein, als dass man die Seite komfortabel bedienen kann.

Bitte geben Sie unseren Lesern eine Checkliste, was sie unbedingt bei mobilen Seiten
beachten sollten. Gerne auch technische Dinge.
Bei der Konzeption und Erstellung einer Seite für mobile Geräte sollte man sich einige Fragen
stellen die hilfreich für den Erfolg der Seite sind:

1. Wer wird wann, wo und aus welchem Grund meine Seite besuchen?
2. Welche Inhalte wird sich mein Besucher auf seinem kleinen Handydisplay tatsächlich
   anschauen oder durchlesen wollen?
3. Welchen Mehrwert kann ich meinem mobilen Besucher bieten? (Standortbezogene
   Zusatzdienste, automatisch verlinkte Telefonnummern, …).
4. Welche Geräte nutzt meine Zielgruppe überwiegend? (Im Nachgang hilfreich ist hier z.B.
   das Tracking von mobilen Besuchern in den ersten Wochen und Monaten nach dem
   Launch).

Darüber hinaus sollte man darauf achten, dass man dem mobilen Benutzer immer die
Möglichkeit bietet von einer mobilen Version auf die herkömmliche Desktop-Version navigieren
zu können und von dieser auch immer wieder zurück auf die mobile Seite gelangt.

„Xify“ erzeugt einen X-Button zu einem Textfeld wie man ihn aus der Adressleiste des iPhone-Safari kennt. Ein Klick auf das Symbol löscht den kompletten Text des dazugehörigen Textfelds. Benötigt jQuery ab Version 1.2.3.

Die Anwendung

$('input:text').xify();
$('input:password').xify({color: "red"});

Parameter

color

Hintergrundfarbe des Buttons

Typ: CSS Farbangabe

Standardwert: #bbb

size

Größe des Buttons

Typ: integer

Standardwert: 12

left

Angabe um wieviel Pixel der Button im Eingabefeld nach links gerückt werden soll

Typ: integer

Standardwert: 4

callback

Callbackfunktion die aufgerufen wird, wenn das X geklickt wird. Muss true oder false zurückgeben.

Typ: function

Demo

http://www.manuel-bieh.de/publikationen/scripts/jquery/xify/

Download

http://plugins.jquery.com/project/xify

English description

You can use this plugin to automatically add a small „X“ to each input field to remove the current value by clicking or touching the X. You may know this function from the iPhone Safari URL bar. Requires jQuery 1.2.3+

Usage

$('input:text').xify();
$('input:password').xify({color: "red"});

Parameters

color

Backgroundcolor of the button.

Type: CSS color value

Default: #bbb

size

Size of the button.

Type: integer

Default: 12

left

Amount of pixels the button is moved to the left within the input field.

Type: integer

Default: 4

callback

Callback which is executed when the X is clicked. Must return true or false.

Type: function

Demo

http://www.manuel-bieh.de/publikationen/scripts/jquery/xify/

Download

http://plugins.jquery.com/project/xify

Damit wird es einem Seitenbetreiber nun ermöglicht – vorheriges Einverständnis des Besuchers vorausgesetzt – dessen aktuelle Position (Längengrad, Breitengrad, Höhenlage), die Reisegeschwindigkeit, sowie die Himmelsrichtung zu ermitteln und daran angelehnt entsprechend geolokalisierte Inhalte auszuliefern. Für einen Tankstellenbetreiber wäre es damit z.B. möglich, einen Tankstellenfinder zu realisieren, der dem Besucher die umliegenden Tankstellen inklusive Entfernung oder sogar eine genaue Wegbeschreibung auf dem Handy präsentiert. Auch eine Tracking-Anwendung, die bspw. die zurückgelegte Wegstrecke beim Joggen für die spätere Analyse am PC aufzeichnet, könnte so – ohne eine App zu installieren – mit dem Browser realisiert werden.

Anders als bei bisherigen Methoden wird dabei nicht ausschließlich auf die IP des anfragenden Clients geachtet, sondern es werden darüber hinaus Parameter wie umliegende öffentliche W-LAN SSIDs (inkl. Stärke des Empfangs) oder ein möglicherweise vorhandenes GPS-Modul abgefragt. Um datenschutzrechtliche Bedenken aus der Welt zu schaffen, wird der Benutzer beim Versuch einer Ortung jedoch vorab um Erlaubnis gefragt. Sollte dieser die Anfrage verneinen, ist der Zugriff auf den Standort über die API nicht möglich.

Wie bei den meisten Technologien, die sich gerade in den Kinderschuhen befinden, gibt es aber auch bei der Implementierung der Geolocation API leider noch einige Tücken. So unterstützen nicht alle Browser mit grundsätzlicher Unterstützung der Geolocation API auch alle Funktionen, die in der Spezifikation vorgesehen sind, und auch die Methoden, mit der die Daten abgefragt werden können, unterscheiden sich teilweise erheblich. Darüber hinaus nagt häufiges Orten bei mobilen Geräten, also Geräten ohne permanenten Strom-Anschluss, stark am jeweiligen Akku. Die Lokalisierung sollte also nicht unnötig oft oder mit einem übertrieben kurzen Intervall durchgeführt werden.

Zumindest um das Problem mit dem nicht einheitlichen Interface zu umgehen, gibt es einige frei nutzbare Open Source JavaScript Libraries, die ein vereinheitlichtes Interface zur Verfügung stellen, wie beispielsweise Geo-location-javascript oder Better Geolocation API.

Eine generelle Unterstützung des Standards, ob vollständig oder nicht, gibt es im Wesentlichen bisher in den folgenden Browsern bzw. Geräten:

• Android Webkit und Dolphin HD
• Apple iPhone/iPod Safari iOS 3.0+
• Blackberry OS 4.1+
• Firefox 3.5+ (< 3.5 mit installiertem Geode Addon)
• Google Chrome
• Opera 10.6+
• Alle Browser mit installiertem Google Gears

Um eine Ortung in einem Browser durchzuführen, der den Standard korrekt implementiert, kann der folgende exemplarische Code verwendet werden:

Zur Erklärung: Mittels typeof(navigator.geolocation) != 'undefined' wird abgefragt, ob der Browser des Benutzers die Geolokalisierung unterstützt. Daraufhin wird die Methode getCurrentPosition() aufgerufen, welche versucht, die aktuelle Position des Benutzers zu ermitteln. Gelingt dies, wird die als successCallback angegebene Funktion aufgerufen und ein Objekt position übergeben. Dieses erhält dann in position.coords.longitude bspw. den ermittelten Längengrad in Dezimalform (z.B. 7.45333164).

Schlägt eine Ortung hingegen fehl, wird die als errorCallback angegebene Callback-Funktion aufgerufen. Als Übergabe gibt es hier das PositionError-Objekt, das gemäß Spezifikation die Zahlenwerte 0 (Unbekannter Fehler), 1 (Ortung nicht erlaubt), 2 (Position konnte nicht ermittelt werden) oder 3 (Timeout) enthalten kann.

Als dritter, zusätzlicher und zugleich optionaler Parameter kann noch ein Objekt in JSON-Notation angegeben werden, um die Eigenschaften der Abfrage genauer zu spezifizieren. Gültige Eigenschaften des Objekts sind:

• enableHighAccuracy
• maximumAge
• timeout

Die Eigenschaft enableHighAccuracy soll sicherstellen, dass ein besonders genaues Ortungsergebnis erzielt wird. Dies geht allerdings, wie eingangs angesprochen, einerseits auf Kosten des Akkus, andererseits verzögert es die Ortung unter Umständen massiv. Im Gegenzug wird dafür die Fehleranfälligkeit sowie die Möglichkeit der Fehlortun verringert.

Über die Eigenschaft maximumAge kann festgelegt werden, wie alt das Ergebnis der letzten Ortung maximal sein darf (in Millisekunden), bevor eine erneute Ortung durchgeführt wird. Setzt man den Wert sehr hoch, ist das Ergebnis, sollte man sich in der Zeit seit der letzten Ortung bereits weit vom Ursprungsort weg bewegt haben, sehr ungenau. Setzt man es hingegen sehr niedrig an, geht das auch hier zu Lasten des Akkus. Einen empfehlenswerten Erfahrungswert gibt es hier nicht, da kommt es sehr auf den jeweiligen Anwendungsfall und etwas Fingerspitzengefühl an.
Mittels der dritten Eigenschaft, timeout, kann angegeben werden wie lange das Gerät bzw. der Browser probiert, die Position herauszufinden, bevor die errorCallback-Funktion mit dem Vermerk Timeout aufgerufen wird.

Neben der getCurrentPosition()-Methode, gibt es auch noch eine zweite Methode watchPosition(). Mit dieser Methode, die die gleichen Parameter erwartet wie auch getCurrentPosition(), ist es möglich, die Bewegung eines Benutzers zu verfolgen und die als successCallback definierte Funktion bei jeder Positionsänderung erneut aufzurufen. Um dieses Verhalten zu stoppen, muss die dritte und letzte Methode der API, clearWatch(), mit der Rückgabe-ID des watchPosition() Aufrufs aufgerufen werden.

Am konkreten Beispiel:

Die Geolocation API bietet eine sehr interessante Möglichkeit für Seitenbetreiber, die ihre Seite mit standortspezifischen Daten anreichern möchten. Man kann davon ausgehen, dass in Zukunft mehr mobile Geräte und mehr Browser den Standard korrekt unterstützen werden. Wenn die Hürden der Vereinheitlichung des Interfaces erst einmal genommen sind oder man sich mit den genannten Möglichkeiten weiterhilft, entstehen so viele neue Möglichkeiten, um das Web mit sinnvollen zusätzlichen Funktionen anreichern zu können. Der Kreativität des Web-Entwicklers sind dabei (fast) keine Grenzen gesetzt.

Dieser Artikel entstand im Rahmen des Webkrauts Adventskalenders und wurde dort am 3. Dezember 2010 erstveröffentlicht.

Einfach, logisch, funktioniert. Sollte man denken. Funktioniert am Desktop und am iPhone auch fantastisch, das iPad schmeißt mir hingegen den Fehler NO_MODIFICATION_ALLOWED_ERR DOM Exception 7 und fügt keinen neuen style-Knoten in mein Dokument ein. Des Rätsels Lösung ist hier einfach und liegt am innerHTML. Diese Anweisung scheint das iPad bei Styles nicht zu interpretieren. Nutzen sollte man hier stattdessen:

Dann fügt auch das iPad ohne zu murren den Style ins Dokument.

FITML ist eine eigens auf mobile Aspekte optimierte Markup-Sprache mit der einfach und komfortabel eine mobile Multi-Channel Website erstellt werden kann. Anders als bei den oben genannten Frameworks wird dabei nicht ausschließlich auf JavaScript gesetzt und ältere Geräte und Nicht-Smartphones somit oftmals ausgeschlossen, sondern es wird für jedes Gerät die jeweils bestmögliche Variante ausgeliefert und das in der Regel – mit nur sehr wenig Mehraufwand (größtenteils sogar völlig ohne!) – vollautomatisch.

So kann man als Entwickler, um mal ein kleines Beispiel zu nennen, auf einfache Art und Weise ein JavaScript-Carousel in die Website integrieren bei dem auf Touch-Geräten per Wischgeste ein Element weiter geblättert werden kann, während alte Nokia-Geräte mit nur begrenzter JavaScript-Funktionalität eine statische Version mit serverseitigem Fallback und dem klassischen „Weiter“-Button ausgeliefert bekommen. Dafür, dass auch stets die richtige Variante der Website ausgeliefert wird, sorgt eine eigene Geräte-Datenbank die OpenSource-Alternativen wie WURFL aber auch kommerzielle Kollegen wie z.B. DeviceAtlas in Sachen Zuverlässigkeit teilweise deutlich aussticht und auch wesentlich detailliertere Auswahlmöglichkeiten bietet.

Die FITML-Markup selbst ist eine im Microformat-Stil angereicherte, gewöhnliche HTML-Syntax in die ein gewöhnlicher HTML-Frontend-Entwickler sich rasch eingearbeitet haben sollte, auch wenn die vielen div-Elemente im ersten Moment sicher gewöhnungsbedürftig anmuten. Ich selbst musste jedenfalls, als ich hier im Oktober 2010 meinen Dienst antrat erstmal durchatmen. Davon sollte man sich im ersten Moment aber nicht abschrecken lassen, die Ergebnisse die man mit FITML binnen kürzester Zeit bekommen kann entschädigen für alles. Ich denke, wer tatsächlich auf kommerzieller Ebene mobile High-Performance Websites entwickeln möchte sollte tatsächlich mal, vielleicht auch in der Mittagspause, länger als nur 5 Minuten probieren sich in FITML einzuarbeiten, und das sage ich nicht aus dem Grund, weil ich selbst bei Sevenval beschäftigt bin sondern weil ich die Fallbackfähigkeit bei den ansonsten wirklich geilen Frameworks doch schon des Öfteren schmerzlich vermisst habe.

Warum ich überhaupt probiere euch das schmackhaft zu machen? Aktuell befindet sich FITML in der Version 4 noch in der Private Beta Phase. Wer möchte kann schon mal einen exklusiven Blick auf FITML4 werfen und auch eigene Websites erstellen und für die Zeit der Beta-Phase auch kostenfrei betreiben. Wenn ihr also tatsächlich Interesse haben solltet, in nächster Zeit mobile Projekte ins Haus stehen oder ihr einfach nur neugierig sein solltet, dann könnt ihr einfach hier nachlesen, was ihr dazu tun müsst um am Beta-Programm teilnehmen zu können: http://www.sevenval.com/de/news/FITML4_Private-Beta_FIT-Platform.html. Wer nicht bei Twitter ist, für den kann ich sicherlich auch anders einen Beta-Zugang besorgen. Ein Exklusiv-Service für Blogleser, sozusagen ;-). Hinterlasst einfach euren Namen und eure E-Mail-Adresse hier in den Kommentaren. Update: Die Beta-Zugänge werden ausschließlich über Twitter vergeben! Wer teilnehmen möchte der loggt sich bei seinem Twitter Account ein und schickt eine kurze Reply an @fitml!

Da die Entwicklung von FITML4 sehr Entwickler- und Community forciert ist werde ich (u.A.) hier in nächster Zeit wohl immer mal wieder den einen oder anderen nützlichen Tipp zu FITML geben.

Und nun wünsch ich euch viel Spaß beim Ausprobieren! ;-)

Das Jahr neigt sich dem Ende zu und so liest man, wie jedes Jahr aufs Neue, zahlreiche Expertenmeinungen was 2011 im Web angesagt sein wird. Da ich letztes Jahr eine solche Vorschau für 2010 bereits angefangen, dann aber leider nie fertiggestellt hatte, ich mit meinen Gedanken aber sogar ziemlich richtig lag, wage ich für 2011 einen neuen Versuch.

Was wird uns 2011 nicht bieten?

Eins vorab, da ich da schon 2010 drüber schmunzeln musste: auch 2011 wird nicht das Jahr des Mega-Durchbruchs von Augmented Reality, so cool die Technologie auch letztendlich ist. Noch immer ist die Anwendung Nerds und Early Adopters vorbehalten. Wer glaubt, mit einer Augmented Reality App die breite Masse erreichen und den großen Reibach machen zu können, der muss schon extrem harte Geschütze auffahren und ein Konzept umsetzen, das alles bisher da gewesene in den Schatten stellt. Glaubt ihr dran? Ich nicht.

… und was wird 2011 uns bieten?

HTML5 wird definitiv kommen und wir werden eine ganze Menge Demos erleben was in der neuen Version an Interaktivität alles denkbar und möglich ist, so wie wir es auch schon 2009 und vor allem 2010 erlebt haben. 2011 wird das noch mal etwas weiter treiben und ich bin mir sicher wir sehen auch in diesem Jahr eine ganze Menge coole Showcases die uns die Kinnlade zu Boden fallen lassen. Hinzu kommt, dass die Browser-Unterstützung bei den neuen Technologien immer besser wird, so dass wir auch immer mehr und mehr Praxisbeispiele finden werden. Und wenn ich von HTML5 rede, dann sollte ich im gleichen Atemzug natürlich auch CSS3 nicht vergessen. Mit dem Internet Explorer 9 gibt es nun erstmals einen Browser aus dem Hause Microsoft, der alle CSS3 Selektoren und auch viele coole Eigenschaften unterstützt. Längst nicht alle, so müssen wir auf border-radius im IE auch weiterhin noch warten, eine erhebliche Steigerung zum Betriebsunfall IE8 ist es alle mal.

Die logische Konsequenz aus der Entwicklung im Bereich HTML5/CSS3 sind mobile Anwendungen im Browser. Für gefühlte 90% aller Apps (Spiele mal außen vor) in den Appstores der großen Handset-Hersteller würde dank Webkit-Implementierung in den aktuellen Geräten im Grunde genommen schon heute der Browser reichen. Ich denke, dass viele Unternehmen das erkennen und neue Wege gehen werden. Vielleicht auch noch nicht 2011, dazu ist es einfach zu lukrativ und verlockend den Appstore-Hype noch mitzunehmen, der selbst gute 3 Jahre nach der Veröffentlichung des ersten iPhones noch nicht ganz abgeflacht ist. Um jedoch schon mal ein Beispiel zu nennen wie man es machen kann, „Die Zeit“ erweist ihrem Namen alle Ehre und geht mit selbiger: nach der Umstellung auf HTML5 gibt es nun auch eine iPad-Version die bei gleichem Markup eine massiv verbesserte User-Experience an den Tag legt. Ich denke auch andere werden diesem Beispiel folgen.

Big in 2011

Mobile Marketing und mobile Advertising (und irgendwie auch mobile Commerce). Irgendwelchen Super-Experten zufolge sollen in den kommenden Jahren Milliarden über Milliarden von Euros über das Handy umgesetzt werden. Ich gebe für gewöhnlich nicht allzu viel auf solche Prognosen, unbestritten dürfte aber eins sein: im mobilen Markt ist Geld zu machen und zwar eine ganze Menge. Sei es mit mobiler Bannervermarktung, mobilen Points of Sale oder auf Agenturseite durch mobile Kampagnen oder die Mobilisierung der bisherigen Websites großer bis mittelgroßer Unternehmen. Klar, was gibt es auch großartigeres für ein Unternehmen als ständig für den Kunden erreichbar zu sein. Am simpelsten ist das wohl über eine mobil optimierte Version der eigenen Unternehmenswebsite möglich.

Mobile, mobile, mobile und es nimmt kein Ende: Location Based Services. Bereits seit Jahren wünsche ich mir auch hier im Blog die Möglichkeit auf die Standortdaten eines Benutzers am Mobiltelefon zugreifen zu können. Dank inzwischen weitläufiger Browser-Implementierung der W3C Geolocation API (die übrigens entgegen der weit verbreiteter Meinung NICHT zu HTML5 gehört sondern ein vollständig eigenständiger Standard ist) ist das nun ohne größere Probleme möglich. Checkin-Dienste wie Foursquare, GoWalla, Latitude, Loca.li oder Places sind nur ein ganz kleiner Teil von dem, was möglich ist. In mittelfristiger Zukunft werden Location Based Services das Web maßgeblich beeinflussen. Ob es regionale eBay-Kleinanzeigen sind, Wohnungssuche mit Standortbezug oder Navigations-Szenarien wie Google Maps. „Location is everywhere!“ – und das einzige was noch im Weg steht ist die Akku-Laufzeit. Wenn ich von „Mobile“ rede, zähle ich Tablets übrigens dazu.

Facebook und das Wachstum

Gerade sprach ich kurz Places an: Facebook wird weiter wachsen und weiter wachsen. Mitte des Jahres gab es 500 Mio Nutzer bei der Plattform, die man mittlerweile als größten Google Konkurrenten sehen kann. Ich denke die 600 Mio Marke werden wir 2011 noch locker erleben, doch irgendwann nimmt auch das Wachstum beim populärsten Service ein Ende. Je mehr Nutzer angemeldet sind, desto weniger gibt es schließlich die sich noch anmelden könnten, Wachstum ist endlich, logisch. Vermutlich werden wir trotzdem noch die 650 Mio Marke knacken. Dann ist aber mal langsam irgendwann gut. Geplant hat Facebook den Gerüchten zufolge einen eigenen Zahlungsdienst. Das könnte der Killer werden aber ebenso auch floppen. Wenn man sich anschaut mit welch rasantem Tempo sich die Leute die Like-Buttons auf ihre Website gepackt haben, kann man wohl eher von ersterem ausgehen. Da liegt es ganz einfach an Facebook und der Komplexität der Lösung. Das ganze muss noch einfacher sein als Paypal und sollte auch für Micropayments lukrativ sein. Dann steht dem nächsten großen Coup von Facebook nichts mehr im Wege. Als heimlicher Fan des Dienstes vertraue ich den Jungs einfach mal dass sie wissen was sie da tun.

What about Google?

Um Google erschien es in den letzten Wochen und Monaten, abgesehen von einigen angeblichen Datenschutzskandalen durch Streetview (Hey, meine Hausfassade ist schließlich meine intimer Lebensbereich) im Prinzip ziemlich ruhig. Nun gibt es Streetview schon eine ganze Weile in anderen Ländern und sprengt daher nicht wirklich die Innovationsskala. Das gehypte Google Wave, auf das wir nach den ersten Previews alle gespannt gewartet haben, wurde eingestellt noch bevor es aus der Beta-Phase herauskam. Das Projekt lebt weiter unter dem Dach von Apache, wo es nun als Apache Wave weiterentwickelt wird. Das mobile Betriebssystem Android gewinnt mehr und mehr Marktanteile, der (wirklich coole!) Chrome-Browser gewinnt langsam Marktanteile und 2011 wird das Chrome OS auf den Markt kommen. Der Gedanke eines webbasierten Betriebssystems ist in der Tat cool und in meinen Augen auch zukunftstauglich und auch die ersten Eindrücke sind durchaus positiv, da wir aber immer noch lange nicht über ein voll ausgebautes 4G/LTE-Netz mit erschwinglichen Tarifen verfügen wird auch das in 2011 nicht durchstarten. Bin dennoch gespannt womit Google uns 2011 vom Hocker hauen wird. An der Zeit für einen Hammer wie seinerzeit Maps, Streetview oder Googlemail wäre es nach dem Flop von Wave eigentlich mal wieder.

Die Startup-Szene

Seit Jahren verfolge ich gebannt die Entwicklung in der deutschen Startup-Szene – zwischen 2008 und 2010 versuchte ich mich vergeblich selbst daran ein Imperium im mobilen Internet zu errichten – und ich denke wir konnten auch in 2010 wieder eine ganze Menge interessanter Neugründungen verfolgen. Rein Subjektiv scheint aber sowohl die Menge als auch die Qualität der erfolgversprechenden Startups abgenommen zu haben. So nehme ich es jedenfalls wahr, denn außer dem Groupon Ableger Citydeal, der mittlerweile von seinem großen Bruder Groupon aus den USA übernommen wurde, gab es kaum spektakuläre Gründungen in der deutschen Internet-Szene. Kein zweites Xing, kein zweites Spreadshirt, kein weiterer ernstzunehmender Konkurrent für die VZ-Netzwerke und auch kein großer deutscher Twitter-Klon. Am interessantesten ist es wohl, hier einmal zu beobachten wo sich im neuen Jahr Team Europe, European Founders und vor allem Hackfwd so alles beteiligen werden und auf diese Beteiligungen mal ein Auge zu werfen. Persönlich klingt loved.by so, als könnte das am ehesten überzeugen. Man wird sehen.

2011 – das Jahr der Browsergames?

Schon Ewig gibt es Browsergames, schon ewig ist da auch die ein oder andere echte Perle dabei. Irgendwie habe ich aber das Gefühl dass Browsergames, gerade wenn ich mir Farm-, Frontier- und Cityville, Brainbuddies oder sonst was bei Facebook anschaue in 2011 richtig durchstarten werden. Sehr gespannt bin ich auf Fliplife und auch im Hackfwd-Portfolio sind Browser-Games vertreten. Wenn man sich überlegt, dass auch der Browsergame-Hersteller Zynga nach eigenen Angaben eine halbe Milliarde Dollar Umsatz machen wird ist der Social Gaming-Markt wohl neben dem Mobile-Markt einer der Wachstumsmärkte mit dem meisten Potential.

Fazit

Wir werden in 2011 wieder einige interessante Startups erleben. Ob eins davon vom Kaliber Twitter oder Facebook sein wird würde ich noch bezweifeln. Vielleicht werden wir ja überrascht. Bekannte Stars im Web-Business werden interessante Projekte rausbringen und es wird viel im mobilen Internet passieren, Geräte-Fortschritt sei Dank. Ich wage keine Prognose welches Projekt definitiv rocken wird aber ich rechne Fliplife, loved.by und auch Foursquare, welches nach Deutschland expandieren will gute Chancen ein. Wir werden Technologiesprünge erleben und Showcases die uns begeistern werden. Interessant wird sein, ob und wann Apple ein neues iPhone herausbringt und ob dieses vielleicht sogar einen NFC-Chip integriert hat. In dem Fall könnte die Entwicklung auf dem Gebiet ungewöhnlich schnell voran gehen. Trotzdem sind das alles nur Spekulationen und Mutmaßungen. Man wird sehen was es am Ende wird, dürfen gespannt sein und uns auf interessante Services und Projekte in 2011 freuen – ich tu es auf jeden Fall und freue mich über jede echte Überraschung und Innovation!

• Webkrauts – deutsche Artikel zum Thema Internet. Schwerpunkt dieses Jahr: Kunden
• Maddesigns.de + Webstandardsblog – zwei Seiten, eine Kooperation: ein deutscher Kalender mit vielen Praxisbeispielen was heute schon mit CSS3 möglich ist oder bald sein wird
• 24 ways to impress your friends – englisch, in den letzten Jahren oftmals mit innovativen und sehr sehenswerten Praxisbeispielen
• PHP Advent – englisch, wie der Name vermuten lässt mit dem Schwerpunkt PHP-Entwicklung
• HTML5Adventure Calendar 2010 – ebenfalls englisch, jeden Tag ein beeindruckendes Beispiel was mit HTML5 möglich ist

Bei den Webkrauts sei noch darauf hingewiesen, dass sich hinter dem dritten Törchen ein Artikel von mir zum Thema „Geolocation API“ befindet. Wünsche euch viel Spaß an den kommenden 11 Tagen an denen ein „Törchen“ geöffnet wird. Solltet ihr noch themenrelevante Kalender kennen die hier nicht gelistet sind: ich freue mich über einen Hinweis als Kommentar!

• Android Webkit
• Android Dolphin HD
• Apple iPhone/iPod Safari iOS 3.0+
• Blackberry OS 4.1+
• Firefox 3.5+
• Firefox < 3.5 mit Geode Addon
• Google Chrome
• Opera 10.6+
• Alle Browsers mit installiertem Google Gears

Andere Browser bieten zur Zeit keine Unterstützung für Geolocation (korrigiert mich bitte wenn ich einem Browser Unrecht tue).

Wie wird das Script verwendet?

Das Script muss einfach vor dem ersten Geolocation Request eines Dokuments mittels <script src="geolocation.js"></script> eingebunden werden. Danach kann einheitlich durch navigator.geolocation.* auf die Methoden aus dem W3C Standard zugegriffen werden. Namentlich sind das getCurrentPosition(), watchPosition() und clearWatch().

Das Script mappt dann die proprietären Abfragemethoden (Blackberry Location, Google Gears) auf das navigator.geolocation Objekt und stellt eine einheitliche API zur Abfrage bereit.

Demo

http://www.manuel-bieh.de/publikationen/scripts/geolocation/demo.html

Download

Das Script gibt es bei Github und auf Google Code. Zieht es euch dort, wo es euch lieber ist. Ich halte für gewöhnlich beide Versionen auf dem aktuellen Stand
Google Code: http://code.google.com/p/better-geolocation-api/
Github: https://github.com/manuelbieh/Geolocation-API-Polyfill

Nun funktioniert, nach Monaten(!) in denen ich nicht die Zeit hatte oder die Lust fand mein System upzugraden, auch das Backend wieder fehlerfrei, so dass ich in Zukunft hier auch mal wieder etwas veröffentlichen kann. Zwar hab ich dazu wegen Studium und Arbeit nur sehr wenig Zeit dafür, 10 Minuten für kleinere Beiträge kann man aber ja eigentlich immer irgendwo abzwacken.

Ist jedenfalls ein schönes Gefühl endlich wieder bloggen zu können. Solltet ihr irgendwo noch einen Fehler finden der möglicherweise im Update seine Ursache findet, so gebt mir doch bitte kurz Bescheid.

Abschließend möchte ich noch darauf hinweisen, dass ich (mit einigen sehr wenigen Modifikationen) vom Code her noch immer das gleiche Template benutze wie bei der ersten Version dieses Blogs vor ziemlich genau 5 Jahren, als hier noch WordPress 1.2 Verwendung fand. Und es funktioniert tatsächlich immer noch. Das fasziniert mich ein wenig.