Schon eine alte Geschichte, aber immer wieder erweitert: Sitemaps.
Die Sitemap-Initiative stammt ursprünglich von Google ist aber herstellerneutral und wird auch von Yahoo! und Microsoft unterstützt. Dabei kann ein Informationsanbieter URLs von Seiten die er indexiert haben will, an die Suchmaschinen inkl. einem geschätzten Änderungsintervall etc. übermitteln.
Was damit passiert resp. Vorteil/Sinn aus Sicht der Suchmaschienenbetreiber haben Uri Schonfeld und Narayanan Shivakumar an der WWW2009 mit ihrer Präsentation “Sitemaps: Above and Beyond the Crawl of Duty” ausführlich gezeigt. Interessant finde ich insb. die Hinweise auf die genutzten Ansätze von Google um zu crawlende URLs über PageRank zu priorisieren (ist eigentlich logisch, macht die GSA/Mini aber nicht so). Und dann die Tatsache, dass auch Sitemaps häufig Fehler aller Art drin haben. Also “nur” eine weiter Quelle um die Crawl-List zu füttern und es werden weiterhin Heuristiken benötigt, um Abdeckung zu optimieren. Also versprechen die Suchmaschinen auch nicht, die übermittelten Seiten aufzunehmen. Interessant die die Aussage, dass in der Stichprobe (ca. 35 Mio. Sitemaps) fast 80% der URL zuerst über Sitemaps entdeckt wurde.
Zudem ist auch das Problem der Duplikate ist mit einer Sitemap nicht systematisch beseitigt… dafür hilft übrigens Canonical URLs. Aber ich sollte nicht alles verraten. Prädikat des Papers: lesenswert.
Was ich aber erzählen wollte ist, dass das Sitemap-Protkoll um Video-URLs erweitert wurde. Als Seitenbetreiber habe ich somit die Möglichkeit Video-Inhalte inkl. der Seite auf der diese eingebettet sind, dem Vorschaubild. einem Link auf den Player etc. übermitteln.
Gelegentlich diskutiere ich mit ausgewachsenen Marketiers und werde ertappt.
Irgendwann hat Jemand (?) behauptet, dass Public Relations (PR) und Corporate Communications ein Bestandteil des Marketings sind. Inzwischen sag ich es selbstbewusster: Diese Theorie ist mir egal. Marketing und PR führen eine moderne Beziehung. Jeder ist mündig und selbstbewusst mit gemeinsamen Ziel:
zufriedene Kunden.
In Social Media Zeiten wird der Unterschied der Beiden recht deutlich. Es wird diskutiert, ob Marketingkampagnen in Facebook funktionieren oder nicht? Nutzt dieses oder jenes Unternehmen Social Media richtig? Wie steuert man Public Relations in den Netzwerken? Gute und schlechte Beispiele entstehen.
Bild: tanzendes Paar. Quelle http://www.flickr.com/photos/admiral_von_schneyder/
Ich sehe die Unterschiede so:
Marketing:
Es stellt das Unternehmen/Produkte optimal dar, ist mal spielerisch mal strategisch, mehrstufig, investiert, lädt ein und fordert auf, immer mit dem Ziel, dem Kunden, im Visier. Inhalte dürfen hier werberisch sein. Es gibt schier unendlich viele Kanäle und Kombinationen.
Kommunikation:
Sie will sich austauschen. Den Dialog kann der Mitteilungs- und hoffentlich Zuhör-Bedürftige dank Social Media endlich direkt führen, anderen Gesprächen lauschen, ohne Umwege wie z.B. die Presse. Ein Unternehmen erfährt Neues mit unschätzbarem Wert über seine Kunden und andere Zielgruppenund und kann direkt informieren. Inhalte sind hier möglichst nutzbar, real und ungeschminkt, zeitabhängig, schnell. Dank Web 2.0 auch spontan, diskutierbar und persönlich.
Gehören die Beiden im Social Web zusammen?
Das kommt darauf an: Möchte man wissen, was Kunden, Aktionäre, potenzielle und Unbeteiligte zu sagen haben? Dient es dem Ziel, dann lohnt es sich, am sozialen Web teilzunehmen. Ob Marketing-Kampagnen im Facebook nerven oder nicht, liegt allein im Auge des Empfängers, und mit diesen Augen können wir jetzt öffentlich lernen zu sehen und verstehen, dass 1:1 Werbeaussagen beispeilsweise im Twitter nicht funktionieren.
Die beiden Verliebten müssen also ihre Stärken ausbauen und zusammen überlegen, kombinieren, sich ergänzen lernen und korrigieren. Hauptsache sie stehen zu ihrer grossen Liebe: dem Kunden (ups oder wars das Marketing)…
Vorgestern hielt ich beim IKT-Forum an der Johannes-Kepler-Universität in Linz einen Vortrag über ARIA und HTML 5 in freier Wildbahn. ARIA ist ein fast fertiger Webstandard des W3C, der bereits weite Unterstützung in Browsern und assistiven Technologien wie Screenreadern hat. Auch wenn der Standard noch nicht final verabschiedet ist, sollte man die Techniken einsetzen, da sie jetzt Menschen mit Behinderungen die Zugänglichkeit zu Websites ermöglichen.
Wie immer steht meine Präsentation bei Slideshare zur Verfügung, auch zum Download. Da es dort aber gerade technische Probleme mit den Vortragsnotizen gibt, die zum Verständnis wesentlich beitragen, gibt es die gesammelten Werke einfach hier:
Die Wahrnehmung von Barrierefreiheit und HTML5 ist oftmals, als wären sie natürliche Feinde.
… oder kann im Gegenteil Barrierefreiheit zusammen mit HTML5 Superkräfte entwickeln?
ARIA wird ungefähr seit 2006 von vielen Screenreadern und Browsern unterstützt, und es kommen immer mehr hinzu.
Im Folgenden möchte ich einige Beispiele aus der Praxis vorstellen, in denen wir ARIA eingesetzt haben.
Insbesondere auf der Startseite von bahn.de sind viele Elemente mit ARIA angereichert. Namics hat das Konzept, Design und die Frontend-Umsetzung realisiert, während die Bahn die Integration in das CMS, ins Buchungssystem und Backend vorgenommen hat (online seit Dezember 2008, weitere Entwicklungsphasen sind vorgesehen).
Die neu designten Seiten der Fraunhofer Gesellschaft sind im Juni 2009 online gegangen. Sie enthalten recht viel ARIA, was nicht weiter verwundert, denn Webstandards und Barrierefreiheit sind bei Fraunhofer nicht zuletzt durch die langjährige Leitung des deutschen W3C-Büros ein wichtiger Punkt.
Die neue Website der Schweizerischen Bibliothek für Blinde und Sehbehinderte wird voraussichtlich im August 2009 online gehen. Selbstverständlich ist ARIA integriert.
Zuerst sollten die niedrig hängenden Früchte geerntet werden. Einige Früchte bei ARIA hängen so niedrig, dass sie einem fast in den Mund fallen.
Mit
aria-required
werden Pflichtfelder ausgezeichnet. Ein Screenreader liest dann vor: „Eingabefeld, erforderlich“. Noch ein weiterer Pluspunkt: die Sprache passt sich automatisch an, ein englischer Screenreader würde also vorlesen: „input, required“. Somit sinken die Aufwände für eine Lokalisierung.
Video:
Ähnlich einfach zu integrieren ist
aria-invalid
. Ein Formular wird serverseitig validiert, und bei ungültigen Feldern wird das Attribut
aria-invalid="true"
eingefügt. Ein Screenreader liest vor: „Eingabefeld, ungültig“.
Video:
Aber selbst bei diesen einfachen Schritten können Fehler unterlaufen. ARIA ist für viele Entwickler, insbesondere im Backend, noch immer eine neue Technologie. Sie sind damit nicht vertraut und übersehen vielleicht relevante Anpassungen. Das sollte man nicht unterschätzen. Als Frontend-Entwickler haben wir also die Aufgabe, diese Techniken zu erklären.
Hier als Beispiel das Kontaktformular von Fraunhofer. Vorgesehen ist eigentlich, dass man per Tastatur auf den Absende-Button tabben kann, das Formular mit der Eingabetaste absendet und auf der neuen Seite Fehler unter anderem mit
aria-invalid
markiert werden. Umgesetzt ist aber ein Formular mit einem aus Usability-Sicht überflüssigen „Zurücksetzen“-Button, und der Absendebutton funktioniert ausschließlich mit dem JavaScript-Event
onclick
, woraufhin sich ein JavaScript-Alert öffnet. Damit wurde aber unwissentlich eine unüberwindbare Barriere für Menschen geschaffen, die keine Maus benutzen. Nur mit der Tastatur (oder ohne JavaScript) ist dieses Formular nicht mehr abzusenden. Um Spam zu vermeiden ist JavaScript eine ungeeignete Methode, weil sie Barrieren schafft und schlechte Usability für alle Nutzer bedeutet.
Sehr gut funktioniert hingegen die Navigation, in der sogar ARIA-Landmark-Rollen wie „Menü“ vorgelesen werden.
In der Navigation haben wir sowohl die ARIA-Rolle
navigation
angegeben als auch
GeSHi Error: GeSHi could not find the language en (using path /var/www/wordpress-3.3-beta3/wp-content/plugins/codecolorer/lib/geshi/) (code 2)
, das im XHTML Role-Modul spezifiziert wird.
Für das Aufklappmenü haben wir einen Link benutzt, weil diese im CSS bereits gestylt sind. Mit ARIA haben wir aber die Rolle
GeSHi Error: GeSHi could not find the language en (using path /var/www/wordpress-3.3-beta3/wp-content/plugins/codecolorer/lib/geshi/) (code 2)
zugewiesen, damit ein Screenreader ihn als „Schaltfläche“ erkennt. Zusätzlich wird ein
GeSHi Error: GeSHi could not find the language en (using path /var/www/wordpress-3.3-beta3/wp-content/plugins/codecolorer/lib/geshi/) (code 2)
benötigt, damit der Button per Tabulatortaste fokusierbar wird. Mit
GeSHi Error: GeSHi could not find the language en (using path /var/www/wordpress-3.3-beta3/wp-content/plugins/codecolorer/lib/geshi/) (code 2)
kann eine Beziehung zu einem anderen Element hergestellt werden, das von dem Button gesteuert wird. Allerdings wird diese Beziehung noch nicht von assistiven Techniken unterstützt. Macht aber nichts, in der Zukunft ist das vielleicht der Fall, und dann steht die Beziehung schon drin.
Nun kommen wir zu vermeintlichen Feinden von Barrierefreiheit, dem HTML 5-Element
GeSHi Error: GeSHi could not find the language en (using path /var/www/wordpress-3.3-beta3/wp-content/plugins/codecolorer/lib/geshi/) (code 2)
. Es ist richtig, dass derzeit Canvas von Screenreadern nicht erkannt wird und selbst Alternativtexte nicht vorgelesen werden. Bei Fraunhofer haben wir das Element aber als Verzierung eingesetzt, was unproblematisch ist.
Auf einigen Seiten von Fraunhofer.de gibt es zwischen der Navigation und dem Textinhalt Teaser-Elemente, die schräge Kanten oben und unten besitzen.
Es gibt sehr viele davon in unterschiedlichen Farben und Schattierungen. Entweder hätte man also zig Hintergrundbilder produzieren müssen …
… oder man verwendet Canvas. Wir haben hier zunächst in der Box ein
GeSHi Error: GeSHi could not find the language en (using path /var/www/wordpress-3.3-beta3/wp-content/plugins/codecolorer/lib/geshi/) (code 2)
-Element in den Hintergrund gelegt. Das hat per CSS eine Hintergrundfarbe, eine Transparenz (opacity) und ist rechteckig. Per JavaScript werden die Farben ausgelesen und das
GeSHi Error: GeSHi could not find the language en (using path /var/www/wordpress-3.3-beta3/wp-content/plugins/codecolorer/lib/geshi/) (code 2)
-Element durch ein
GeSHi Error: GeSHi could not find the language en (using path /var/www/wordpress-3.3-beta3/wp-content/plugins/codecolorer/lib/geshi/) (code 2)
-Element ersetzt, das schräge Ecken hat. Das wird in allen aktuellen Browsern unterstützt außer im Internet Explorer. Dazu gibt es eine Alternative, die wir gleich erfahren werden.
Bei der Website der Schweizerischen Blindenbibliothek gibt es einige Bedienelemente mit runden Ecken. Hier haben wir das CSS 3-Attribut
GeSHi Error: GeSHi could not find the language en (using path /var/www/wordpress-3.3-beta3/wp-content/plugins/codecolorer/lib/geshi/) (code 2)
verwendet. Das ist schnell und flexibel einzusetzen und wird in fast allen Browsern unterstützt.
Natürlich wird
GeSHi Error: GeSHi could not find the language en (using path /var/www/wordpress-3.3-beta3/wp-content/plugins/codecolorer/lib/geshi/) (code 2)
nicht vom Internet Explorer unterstützt. Hierzu erzeugen wir Hintergrundbilder mit runden Ecken mit dem proprietären Standard VML (Vector Markup Language), Microsoft’s Antwort auf SVG (Scalable Vector Graphics). Zunächst wird per Conditional Comment abgefragt, ob der Browser VML versteht. Wenn das der Fall ist, setzen wir eine Variable in JavaScript und erzeugen das VML-Element. Schließlich wird es per CSS gestylt.
Hierbei ist zu bemerken, dass im Internet Explorer 8 eine Breite oder Höhe von 100% für VML-Elemente nicht mehr funktioniert. Der Browser unterstützt nur noch Pixel- oder
GeSHi Error: GeSHi could not find the language en (using path /var/www/wordpress-3.3-beta3/wp-content/plugins/codecolorer/lib/geshi/) (code 2)
-Werte. Interessant, dass Microsoft selbst seine eigenen „Standards“ bricht. Leider ist es etwas mühselig, dann für jeden Button je nach Textlänge eine feste Breite anzugeben. Alternativ kann man den IE8 auch in den IE7-Kompatibilitätsmodus zwingen.
In Opera 10 sieht die Seite derzeit ungefähr so aus: mit eckigen Ecken statt runden, aber das stört auch nicht wirklich.
Seit wenigen Wochen unterstützen Firefox 3.5 und der Safari-Browser auf dem iPhone mit OS 3.0 einen fast finalen Standardentwurf des W3C, Geolocation.
Bei der Schweizerischen Blindenbibliothek haben wir Geolocation eingesetzt entsprechend den Prinzipien des Progressive Enhancements. Nutzer, deren Browser Geolocation unterstützt, bekommen die Option, ihren Standort auf der Karte anzeigen zu lassen. Gedacht ist das vor allem für Sehbehinderte oder Blinde, die ein iPhone 3G S nutzen und die damit ihren Standort erfahren können auf dem Weg zwischen S-Bahn-Haltestelle und Bibliothek.
Oft benötigt man über die ARIA-Attribute in HTML hinaus noch JavaScript, um die Tastatursteuerung zu unterstützen. Man kann dazu Widgets verwenden, z.B. von jQuery UI, dojo oder YUI, die oft bereits ARIA eingebaut haben. Oder man muss diese Schritte selbst programmieren.
Auf bahn.de werden Registerkarten zur Navigation verwendet. Mit der Tabulatortaste kommt man auf den aktuellen Reiter. Tabbt man weiter durch, gelangt man in den offenen Reiterinhalt. Auf dem Reiter liest ein Screenreader aber auch vor: „Bahn, Registerkarte, eins von vier“. Somit weiß ein Nutzer, dass es sich um eine Reiternavigation handelt, auf der man wie in den Tabs im Browser mit den Pfeiltasten (und anderen Tasten) auf den nächsten Reiter kann. Auf der aktuellen Bahn-Seite ist leider noch eine ältere Version, die weniger intuitiv funktioniert. Aber die Entwicklung der Website geht weiter. ;-)
Video:
Vereinfachter Code. Bei der Bahn haben wir noch Hintergrundbilder, die per
GeSHi Error: GeSHi could not find the language en (using path /var/www/wordpress-3.3-beta3/wp-content/plugins/codecolorer/lib/geshi/) (code 2)
eingefügt sind. Wenn zwischen dem Element mit der Rolle
GeSHi Error: GeSHi could not find the language en (using path /var/www/wordpress-3.3-beta3/wp-content/plugins/codecolorer/lib/geshi/) (code 2)
und dem Kinder-Element mit der Rolle
GeSHi Error: GeSHi could not find the language en (using path /var/www/wordpress-3.3-beta3/wp-content/plugins/codecolorer/lib/geshi/) (code 2)
andere Elemente liegen, können diese im Screenreader mit der Rolle
GeSHi Error: GeSHi could not find the language en (using path /var/www/wordpress-3.3-beta3/wp-content/plugins/codecolorer/lib/geshi/) (code 2)
ausgeblendet werden.
Damit die Reiternavigation per Tastatur funktioniert, muss per JavaScript ein
GeSHi Error: GeSHi could not find the language en (using path /var/www/wordpress-3.3-beta3/wp-content/plugins/codecolorer/lib/geshi/) (code 2)
gesetzt werden. Die entsprechenden Tastatur-Events werden abgefangen. Dabei muss man differenzieren, ob eine Taste nur alleine oder zusammen mit Shift, Alt oder Strg gedrückt wurde, das macht einen Unterschied. Der Reiterinhalt wird dann eingeblendet, am besten, indem man eine Klasse hinzufügt oder entfernt.
Dann muss noch das Event-Bubbling verhindert werden. DOM-Elemente sind sehr mitteilungsbedürftig und sagen sofort ihren Eltern, wenn etwas passiert ist, immer so weiter bis zum Document-Root. Wenn ich aber mit der Pfeiltaste den Reiter wechsele, möchte ich vermeiden, dass beim Drücken der Pfeiltaste die Seite nach unten scrollt.
Schließlich muss man für ältere Screenreader noch den virtuellen Buffer aktualisieren. Beim Laden der Seiten wird die Seite in einem Puffer abgelegt. Ändert man später ein Element von
GeSHi Error: GeSHi could not find the language en (using path /var/www/wordpress-3.3-beta3/wp-content/plugins/codecolorer/lib/geshi/) (code 2)
auf
GeSHi Error: GeSHi could not find the language en (using path /var/www/wordpress-3.3-beta3/wp-content/plugins/codecolorer/lib/geshi/) (code 2)
, bemerkt das der Screenreader nicht. Im Formularmodus ändert sich der Inhalt aber ständig, der Puffer wird aktualisiert. Also schreibt man einfach per JavaScript in ein hidden Input-Feld irgendwelche Zufallszahlen.
Auf der Seite der Blindenbibliothek haben wir eine Merkzettelfunktion eingebaut. Blinde können sich schlecht mal eben Notizen auf einem Zettel machen, weswegen wir auf jeder Seite einen Button haben „zum Merkzettel hinzufügen“. Die Seiten werden sich dann in einem Cookie gemerkt. Die Bestätigung wird mit AJAX und dynamischer Textersetzung eingefügt, was Nutzer von assistiven Technologien nicht bemerken würden. Mit einer ARIA-Liveregion liest der Screenreader aber Änderungen in einem Abschnitt vor. (Anmerkung: hier sieht man einen funktionalen Prototypen, zum Zeitpunkt des Vortrags war das noch nicht „hübsch“ final umgesetzt).
Video:
Fazit: Barrierefreiheit und Technik (oder ansprechendes Design wie in diesem Uhrenentwurf von David Chavez) können sich sehr gut ergänzen.
Ich ertappe mich oft, wie ich bei einer Website-Suche das Vorurteil hege, ohnehin nicht auf die gewünschten Informationen zu stossen – und daher die öffentliche Google Websuche verwende. Wahrscheinlich bin ich nicht der Einzige, der sich an Google gewöhnt hat und daher erwartet, dass jede Suche so zu funktionieren hat. Diese Annahme bestätigt sich denn auch in von uns durchgeführten Usability Tests und Analytics-Daten: Immer mehr User suchen bestimmte Inhalte auf einer Seite über die angebotene Suchfunktion. Häufig finden sie aber die gewünschten Inhalte nicht, da die eingesetzten Suchmaschinen schlicht und einfach entweder nichts taugen oder schlecht konfiguriert sind. Die Lösung? Google Mini ;)
Was kann denn eine Google Mini?
Die Google Mini ist ein 19 Zoll Hard- und Softwarebundle und bietet neben einer ausgereiften und vertrauten Volltextsuche einige weitere wirklich gute Funktionen:
Dank dem XML Suchinterface kann die Google Suche in beliebige bestehende Webseiten integriert werden, auch parallel in mehreren (beliebige Anzahl Kollektionen).
Mit Keymatches (eigenständig definierbare Treffer zu bestimmten Suchbegriffen) kann den Suchenden geholfen werden, die richtigen und wichtigen Informationen schnell zu finden. Beispiel: gibt jemand einen Produktenamen ein, erscheint der Keymatch dazu oberhalb der restlichen Treffer und ist optisch hervorgehoben.
Die Google Mini durchsucht mehr als 200 Dateiformate und bietet eine Textvariante des jeweiligen Inhalts an.
Eine Suchanwendung kann mittels Onebox Modulen ausgebaut werden. So können z.B. bei einem Treffer zu einer Produktseite detaillierte Informationen zu diesem Produkt bereits in der Resultatliste angezeigt werden. Beispiele zu Onebox Modulen auf der öffentlichen Google Suche: Lokale Wetterprognosen oder Treffer aus dem Branchenverzeichnis von Google.
Sofern notwendig kann die Google Mini in bestehende Sicherheitslösungen integriert werden.
Was kostet eine Google Mini?
Eine Google Mini gibt es ab circa CHF 4’000.- inklusive Lizenz und Wartung für 2 Jahre, also für CHF 2’000.- pro Jahr. Der Aufwand für eine Integration in eine Webseite beläuft sich auf circa CHF 15’000-30’000. Darin eingeschlossen sind Design von Suchmaske und Resultateliste, Implementierung, initiale Konfiguration sowie Inbetriebnahme der Google Mini.
Bei Interesse oder spezifischen Fragen einfach Kontakt aufnehmen, oder unten kommentieren. Gerne stelle ich die Google Mini (oder auch die grössere Google Search Appliance) auch im Live-Einsatz vor.
Übrigens, Namics ist bereits seit 2005 zertifizierte Google Enterprise Professional Partnerin und in der Schweiz damit bislang alleine. Und natürlich machen wir Google Mini / Google Search Appliance Projekte auch in Deutschland :)
Handytypen gibt es wie Sand am Meer. Entwickelt man einen mobilen Webauftritt, kann man diesen jedoch nicht für alle und jeden optimieren. Gruppieren und priorisieren ist also angesagt.
Bei der Entwicklung von Websites gilt es meistens, verschiedene Browser und Betriebssysteme zu berücksichtigen. So sollte eine Website (im Optimalfall) im Internet Explorer 6, 7 und 8 gleich aussehen wie im Firefox oder Safari und dies sowohl unter Windows als auch unter Mac OS. Im mobilen Web ist dies nochmals komplizierter (Applikationen schliesse ich mal aus): es existieren verschiedene Betriebssysteme und Browser, eine Vielzahl von Bildschirmauflösungen, unterschiedliche User Interfaces (Tastenblock, Tastatur oder Touchscreen) und und und… Doch wie soll man vorgehen, wenn man einen mobilen Webauftritt entwickelt? Schliesslich ist es nicht möglich, eine mobile Website für jeden Gerätetyp masszuschneidern, andererseits sollen aber dennoch soviele User wie möglich in den Genuss des mobilen Webauftritts kommen.
Eine Empfehlung, wie das Problem zu lösen ist, findet sich bei Usability-Guru Jakob Nielsen, welcher die Unmenge von Handytypen in drei Gruppen unterteilt:
und auch gleich Empfehlungen darüber abgibt, wie damit in der Entwicklungsphase umzugehen ist.
Full-Lösung
Im Optimalfall, so Nielsen, optimiert man die mobile Website für alle im Bild aufgeführten Typen (also mit unterschiedlicher Darstellung und angepasstem Funktionsumfang).
Medium-Lösung
Wünscht man weniger Aufwand, entwickelt man eine mobile Site für die Low End-Standardhandys und eine für Smartphones/Full Screen Handys.
Basic-Lösung
Will man jedoch bloss eine einzige Version entwickeln müssen, empfiehlt Nielsen, diese an die Bedürfnisse der Smartphone- und Full Screen Handy-User anzupassen, statt eine Minimallösung zu bauen, die zwar mit möglichst vielen Gerätetypen kompatibel ist, die jedoch niemand besuchen will, weil sie so schlecht ist.
Dieser Empfehlung kann ich jedoch nicht 100%-ig zustimmen – so gibt es durchaus Anwendungsfälle, bei welchen es sinnvoll sein kann, mit einer “Minimallösung” zu fahren. Es existieren viele Dienste, welche vor allem firmenintern von Bedeutung sind (beispielsweise ein mobil-optimiertes Firmentelefonbuch oder unser Raumreservierungssystem RoomNOW) und in einem solchen Kontext ist man darauf angewiesen, dass möglichst viele User diesen Dienst nutzen können. Doch auch bei klassischen “externen” Websites kann es sinnvoll sein, den mobilen Auftritt am kleinsten gemeinsamen Nenner zu orientieren, so dass beispielsweise wenigstens sichergestellt wird, dass ein User, welcher mit seinem Handy auf die Website surft, mindestens mobile-optimierten Inhalt vorfindet und sich in seinem Handy nicht mit der vollen Website abmühen muss.
Trotzdem – der Ansatz, dass man, wenn man einen mobilen Webauftritt baut, primär auf diejenigen User “Rücksicht” nimmt, die auch tatsächlich viel und oft mobil surfen (also iPhone-, Blackberry-User und Co.), ist sicherlich auch nicht falsch. Die Konsequenz daraus: Die Frage, wie man seine mobile Website für verschiedene Gerätetypen optimiert, kann nicht einfach mit drei Standardlösungen beantwortet werden. Dieser Prozess setzt vielmehr strategische Entscheidungen (Ziel- und Zielgruppendefinition, Kosten-/Nutzenanalyse, etc.) voraus, welche von Projekt zu Projekt grundverschieden sein können.
