Detect Three-Finger Swipe Gestures in Safari with the HTML5 History API

As I’m only using Mac computers at home, I’m used to the amazing and timesaving  multi-touch gestures on my Macbook and the Magic Mouse. Wouldn’t it be nice to use this type of user interaction as a web developer to make your web app more useful?

Today I’ve made an interesting discovery. Safari uses the three-finger swipe gesture for going back and forth in the browser history. That’s the only gesture in the browser, that affects the content of the displayed site directly. With the use of the HTML5 History API it is possible to manipulate the browser history although you aren’t actually leaving the visited site. So let’s say You’ve a gallery page with 5 different photos and You want to swipe through them like it’s possible in iPhoto or on the iPhone. If you’re on a Mac and using Safari, you can check it out here.

The best way to start is to open a new pop-up window, so it doesn’t contain any previous page in the browsing history. Then you have to create a history entry for all items in your gallery and jump back to the very first one right after the page is loaded. If  you’re now swiping with three fingers, you are going one page forward and it’s easy to catch this change with a simple event handler. The rest is just some fancy javascript trickery.

How to change the iPhone On-Screen-Keyboard in Web Apps

Nearly three years ago, when Apple introduced the iphone, so-called “Web Apps” were the only way to develop and publish self-made applications on Apple’s new and shiny gadget. With the announcement of the SDK and the launch of the App Store, developers started abandoning web applications and began flocking to native development. But this is not the end of web-based applications: Recently Google declared the end of mobile app stores and with Google Voice, Buzz and GMail, the company started to port their entire range of services to the mobile web. Besides that, HTML5 provides the much-needed technologies (offline access, storage, location awareness) to really make web-based applications great and useful.

On of the biggest problems developers are facing with mobile web applications is the user interface/experience. We have to reach the superior quality GUI of native applications together with all the conveniences they are offering to users. The majority of web sites for example are using the plain old on-screen-keyboard for every text input, no matter what characters will be entered. It isn’t really comfortable to enter an email-address when you have to change to the secondary keyboard to enter a “@”. Just the same as having to change it for entering numbers in an input element that is only ment to contain numbers anyway.

This is probably the most common user interface problem and it is also one of the easiest to fix. The HTML5 specification contains an extension to the type attribute of input elements that is perfectly recognized by Mobile Safari. With just a little change, you are able to make your web-based application more convenient to use. And by the way: Browsers that don’t understand the new type attributes will ignore it and keep displaying a normal input element.

It is as simple as the following code snippet:

Text: <input type="text" /> <!-- display a standard keyboard -->
Telephone: <input type="tel" /> <!-- display a telephone keypad -->
URL: <input type="url" /> <!-- display a URL keyboard -->
Email: <input type="email" /> <!-- display an email keyboard -->
Zip Code: <input type="text" pattern="[0-9]*" /> <!-- display a numeric keyboard -->

Just change to type attribute to either “tel”, “url” or “email”. Additionally you can alter use the new pattern attribute to only allow numbers. I’ve set up a demo page which can be accessed with every iPhone and iPod Touch. Please note, that this feature is only supported in iPhone OS 3.1 or newer.

Google Browser Size

Es ist noch gar nicht so lange her, da musste man beim Web-Design noch auf die kleineren Auflösungen der CRT-Monitore Rücksicht nehmen. 800*600 Pixel war vor ein paar Jahren noch die Bildschirmauflösung von einem nicht zu vernachlässigenden Teil der Website-Besucher, der dementsprechend berücksichtigt werden musste. Ähnliche Probleme entstehen auch jetzt wieder, wenn man mit Netbooks und anderen mobilen Geräten mit geringer Bildschirmgröße auf das Internet zugreift.

Google hat jetzt ein brauchbares Tool herausgebracht, dass einem Vieles erleichtern soll. Mit Browser Size spürt man gezielt Usability-Probleme im Zusammenhang mit zu kleinen Auflösungen auf und kann seine Internetseiten entsprechend verändern. Über die eigentliche Website wird ein halbtransparentes Overlay gelegt, anhand dessen man anschließend leicht den prozentuell sichtbaren Bereich erkennen kann.

Bei wem also wiedermal ein Website-Redesign ansteht, der sollte sich das kleine Helferlein im Hinterkopf behalten …

DiggBar: “Release early, release often and reiterate”

digg_logoObwohl ich die DiggBar anfangs als äußerst positiv und angenehm empfunden habe, gab es genügend Leute, meist Suchmaschinen-Optimierer, die diese Neuerung alles andere als einfach akzeptieren wollten. Das Problem an Diggs Short-URL-Service war schnell identifiziert: Anstatt wie üblich mit einem 301-Redirect die verkürzte Adresse sofort auf die Ursprungsquelle weiterzuleiten, liefert Digg den HTTP-Statuscode 200 aus und bindet die Quelle in einem Frame ein. Suchmaschinen erkennen dadurch den Zusammenhang zur eigentlichen Seite nicht und werden auch nicht auf diese weitergeleitet. Auf der anderen Seite ist dies die einzig praktikable Möglichkeit die DiggBar zu realisieren. Um eine größeren Aufstand der Webmaster zu vermeiden, hat sich Digg nun dazu entschlossen eine Kompromisslösung einzugehen:

bild-18

Nicht auf Digg angemeldete User bekommen nach der Änderung keine DiggBar mehr angezeigt und werden direkt (301-Redirect) durch die verkürzte URL weitergeleitet. Für alle Digg-User bleibt alles beim Alten. Sie bekommen weiterhin die DiggBar – immerhin war die DiggBar seit dem Launch für ca. 45 % der abgegebenen Diggs verantwortlich. Ganze 25 % haben neue Inhalte und Seiten entdeckt, die sie anderenfalls nicht bemerkt hätten – so Digg’s John Quinn in einem Beitrag auf dem Digg-Blog. Natürlich gibt es auch weiterhin die Möglichkeit für registrierte User, die DiggBar zu deaktivieren.

Mit diesem Schritt hat der Social-News-Gigant ein weiteres Mal bewiesen, dass User-Feedback auch wirklich bei den Entwickler ankommt. Es ist nahezu eine Win:Win:Win-Situation entstanden: Die Content Provider sollten durch die Änderungen weitgehend zufrieden sein, die User bekommen weiterhin die speziellen Funktionen der DiggBar und Digg profitiert von der gesteigerten User-Interaktivität. Diese Entwicklungs-Weise entspricht ganz klar der Unternehmenskultur des kalifornischen Unternehmens. Wie Kevin Rose, Mitbegründer von Digg, schon öfters durchklingen lassen hat, ist es für ihn persönlich wichtig, ein Produkt sowie die Änderungen in einer schnellen Taktfrequenz zu veröffentlichen, genau auf die Reaktionen bzw. das Feedback zu hören und dann prompt Anpassungen durchzuführen. “Release early, release often and reiterate”. Diese Praktik haben wir damals schon bei den Kommentaren gesehen und sie kommt auch heute wieder bei der DiggBar zum Einsatz. Vielleicht sollten mehr Web-Entwickler diesen Entwicklungsstil adaptieren, um nicht in der Konkurrenz unter zu gehen.

Was Nintendo vom AppStore lernen kann

wii-test_01Vor 12 Tagen war es Apple sichtlich eine Freude die Erfolgsmeldung schlechthin zu veröffentlichen: Über 500 Millionen Downloads wurden bisher über den AppStore verbucht, in dem mittlerweile über 15.000 verschiedene Programme zum Download bereit stehen. Apple hat es geschafft in weniger als einem Jahr ein funktionierendes und profitbringendes Ökosystem für die Erweiterung des iPhones und iPod Touchs zu schaffen. Angespornt durch diesen offensichtlichen Erfolg versuchen nun immer mehr Mobiltelefonhersteller auf den Zug aufzuspringen: Von Google über Palm bis hin zu Blackberry  hat jeder den Trend erkannt, sowohl Hobbyentwicklern als auch kommerziellen Softwareproduzenten einen einfachen und komfortablen Weg für die Entwicklung und Distribution zu bieten!

Wendet man jedoch den Blick von den Mobiltelefonherstellern ab und nimmt die Strategie der Konsolenhersteller unter die Lupe, kann man von dieser Trendwende noch nicht viel entdecken. Alle drei (Nintendo, Sony und Microsoft) haben zwar in dieser Generation erfolgreich ihre Online-Distributions-Plattformen aufgebaut, geben diese jedoch nur für kommerzielle Entwickler frei. Hobbyprogrammierern wird ein kompliziertes und teilweise kostenintensives Anmelde- beziehungsweise Bewerbungsverfahren in den Weg gelegt. Privatpersonen müssen schon bei diesem Schritt kapitulieren, da eine Bewerbung für eine Entwicklungslizenz nur von Unternehmen ausgeführt werden kann.

Ganz anders läuft dies bei Apple ab: Hier reicht eine Mitgliedschaft im iPhone Developer Program um 99 Dollar. Sowohl für Hobbyprogrammierer als auch professionelle Entwickler eine lohnende Investition, die sich später bezahlt macht. Zusätzlich zur Anmeldung benötigt man für die WiiWare-Entwicklung ein Wii-Development Kit um 2.000 bis 10.000 Dollar – Bei Apple genügt hier das kostenlose Software-Development-Kit und ein normaler iPod Touch oder ein iPhone. Ein weiterer Punkt in den Bedingungen von Nintendo ist, dass die Entwicklung nicht zu Hause statt finden darf, sondern nur in einem getrennten Gebäude – auch ein Home-Office ist nicht erlaubt! 

Sind diese Hürden überwunden, entdeckt man eine der wenigen Gemeinsamkeiten: Sowohl Apple als auch Nintendo behalten sich das Recht vor, Programme oder Spiele nicht für den Verkauf freizugeben. Jede Kleinigkeit, die nicht passt, kann zur Ablehnung des Produkts führen. Diese Praktik wurde bei Apple schon öfters angewendet, bei Nintendo wird dies offensichtlich von den Entwicklern nicht in der Öffentlichkeit publik gemacht.

Für Hobbyentwickler bleibt auf den Konsolen nur die Wahl unautorisierte Programme, auch Homebrew genannt, zu erstellen. Die Wii hat sich im letzten Jahr bereits eine aktive und sehr lebhafte Homebrew-Szene aufgebaut, die zeigt, wie viel Mühe und Arbeit auch ohne offizielle Tools in die Entwicklung von Programmen gesteckt wird. Die Homebrew-Spiele werden durch eine Sicherheitslücke der Konsole zum Laufen gebracht und sind deswegen von den Konsolenherstellern nicht gerne gesehen. Es gibt weder eine öffentliche Dokumentation der Softwareschnittstellen noch Entwicklungswerkzeuge für die Homebrew-Community – dementsprechend schwer ist die Entwicklung und das Veröffentlichen von vorzeigbaren Ergebnissen. Ähnlich wie Cydia auf dem iPhone, hat sich auch auf der Wii ein inoffizieller ”AppStore” breit gemacht. Der Homebrew Browser ermöglicht das Laden und Updaten neuer Applikationen für die Wii direkt über die Konsole. Auf diese Weise werden zahlreiche nützliche Programme, wie zum Beispiel ein DVD-Player, angeboten. Derzeit sind über 170 Programme im Katalog erfasst, die zusammen bereits über 1,4 Millionen mal heruntergeladen wurden. Solche Zahlen zeigen, dass es ohne Zweifel einen Markt für Hobbyentwickler auf den Konsolenplattformen gibt. Es liegt einzig und allein an den Herstellern, diese Lücke zu erkennen und mit einer praktikablen Lösung zu füllen. Die Basis für solch einen Erfolg hätten sie mit der überwältigenden Menge an verkauften Geräten bereits gelegt.