BLog

ImprintImpressum
PrivacyDatenschutz
DisclaimerHaftung
Downloads 

Die Suchmaschine deren Name nicht genannt werden darf

Da gibt es diese Suchmaschine, deren Name nicht genannt werden darf (She, who must not be named - Swmnbn), damit man nicht aus deren Index fliegt - ihr wisst schon welche. Die hat sich also in den Kopf gesetzt, ihre Indexierung auf Mobile First umzustellen. Damit nun Seiten wie diese hier auf Mobilgeräten überhaupt noch gefunden werden können, dürfen sie nicht nur den Suchmaschinennamen nicht nennen, sondern müssen zusätzlich noch eine Validierung auf Mobilgerätetauglichkeit bestanden haben.

Ich öffne also zunächst einmal meine Seiten auf meinem ollen iPhone 5s und halte sie wie schon seit Jahren für perfekt mobilgerätetauglich. Dann starte ich in der Swmnbn-Search-Console einen Validierungslauf meiner Web-Instanz mit deren Smartphone-Crawler, um dann nach im Schnitt 24 h gesagt zu bekommen, daß das alles keinen Mobile-Taug hat. Das Blöde ist nun, daß dieser Crawler offenbar von einem Praktikanten zusammengehackt wurde, und die Ausgabe der Crawler-Ergbnisse mehr vom Wetter in Mountain View denn von der Eingabe meiner Seiten abhängt. Keine Panik, Spock würde sagen, Wir müssen logisch vorgehen und uns auf das wesentliche konzentrieren.

Swmnbn Mobile Usability of obsigna.com

Nach 17 Iterationen durch den Smartphone-Crawler, habe ich immer noch 43 Seiten mit Mobile-Usability-Issues. Darunter Text too small to read, Clickable elements too close together und Content wider than screen. Von gestern auf heute habe ich im Stylesheet für alle Seiten die Schrift und den Zeilenabstand um knapp 10 % vergrößert, und prompt habe ich nun 4 Seiten mehr mit zu kleiner Schrift gemeldet bekommen. Ergibt das irgendeinen Sinn? Jetzt habe ich die Schrift und den Zeilenabstand nochmal um 12,5 % vergrößert und den 18ten Validierungslauf gestartet. Auf meinem iPhone 5s ist das alles mittlerweile nur noch grob unansehnlich, aber was will man machen, wenn ein zu 75 % sehbehinderter und manisch-depressiver Crawler mit dem virtuellen dicken Zeigefinger einer 250 kg Person die Regeln vorgibt. Achja, welche Regeln?.

Es gibt übrigens auch ein Swmnbn-Mobile-Usability-Live-Test-Tool, und bereits nach der zweiten Iteration bescheinigte das allen meinen Seiten, also auch jenen, die von dem behinderten Crawler beanstandet wurden: Page is mobile friendly. Und damit es auch die dümmeren von uns richtig verstehen, mit dem Nachsatz This page is easy to use on a mobile device.

Unter dem Gesichtspunkt ist es ja fast schon ein Wunder, daß ich überhaupt 107 von 150 Seiten validiert bekommen habe. Im Laufe der genannten 17 Durchläufe gab es noch eine weitere Auffälligkeit. Nämlich am 21.9. waren auf einmal 15 meiner Seiten, darunter einige populäre, aus unspezifischen Gründen aus dem Index geworfen worden. Nachdem ich dann am 24.9. mit dem Kommandozeilen-Tool sed(1) alle Vorkommnisse von $ihr_wisst_schon_wer auf meinen Seiten durch Swmnbn ersetzt hatte, waren die verschwundenen Seiten seit dem 25.9. alle wieder drin.

   sed -e "s/$ihr_wisst_schon_wer/Swmnbn/g" -i "" articles/*.html

Ich glaube dennoch an eine Koinzidenz. Mein Herz hängt aber nicht dran, ich muß ihr wisst schon wen hier nicht nennen, und jetzt bleibt das eben so.

Jedenfalls werde ich nicht in dasselbe Stockholm-Syndrom verfallen, wie viele Web-Designer, die sich offenbar ganz freiwillig und mit wehenden Fahnen in die Swmnbn-Mobile-Usability-Geiselhaft mit dem gestörten Crawler als Aufpasser begeben haben. Der 18te Durchlauf ist garantiert auch der letzte - hop oder top. Immerhin gab es eine Lernkurve, und über die werde ich ab sofort streng logisch und der Reihe nach berichten.
 

Der Viewport – über-, unter- oder unbestimmt?

Ich wollte meinem BLog die Anmutung von gedruckten Seiten im Hochformat geben, wenn auch ohne Seitenumbrüche. Also habe ich seinerzeit ein A4-Blatt an den damaligen Bildschirm gehalten und durch Ausprobieren die Breite der beschreibbaren BLog-Seite zu etwa 730 Pixeln bestimmt. Dazu kommt dann noch die Seitenleiste mit der Liste aller BLog-Artikel. Bei anderen Bildschirmen paßt das dann natürlich nicht so schön zusammen, aber wenn man mit dem Fahrrad daran vorbeifährt, merkt man den Unterschied kaum, und es kommt ja auch auf die Anmutung an. Jedenfalls gibt es bei allen meinen Seiten ein <DIV class="page">...</DIV> direkt unterhalb des <BODY>-Elements, durch das die Seitenbreite exakt festgelegt ist:

DIV.page { width:940px; min-height:1880px; margin:10px auto; padding:10px 5px 10px 35px; background-color:#FFF; box-shadow:0 3px 7px rgba(100, 100, 100, 0.25); }

Der Margin-Wert auto bewirkt, daß die Seite immer dieselbe Breite hat, egal wie groß das Browser-Fenster ist. Diese feste Seitenbreite haben die Browser von allen Mobile-Devices, die ich kenne (Safari, Chrome, Firefox und Opera) auf Androids, iPhones und iPads schon immer einfach so verstanden und die Seiten dann durch Skalierung automatisch an die jeweilig verfügbare Display-Breite angepaßt. Das sah perfekt aus und Normalsichtige konnten den Artikel-Text auch ohne heranzoomen lesen.

Die Farbe des Seitenhintergrundes ist hier übrigens als reines Weiß #FFF festgelegt. Die Darkmode-Liebhaber, das sind die, die sich die teuersten, größten, hellsten und kontrastreichsten Monitore zulegen, und dann alles auf Dunkel stellen, weil ihnen die Augen wehtun, kommen bei meinen Seiten zwar zu kurz, da kann man aber nichts machen, denn Wissenschaftler arbeiten nunmal schwarz auf weiß.

Wir haben also die Breite unserer Web-Seite, und es gibt die zur Verfügung stehende Breite auf dem Monitor bzw. Display. Apple hat dann dazwischen noch eine weitere Ebene eingezogen, nämlich den Viewport. Dafür gibt es in HTML5 eine META-Direktive. Damit kann der geneigte Web-Designer die Anzeigebreite auf dem Ausgabegerät in Pixeln, einen Skalierungsfaktor und neuerdings auch jede Menge andere Parameter festlegen.

Was soll man nun sinnvollerweise als Breite und Skalierungsfaktor angeben? Viele Seiten raten, das Gerät die Anzeigebreite setzen zu lassen (width=device-width), und den Skalierungsfaktor auf 1 zu setzen (initial-scale=1.0). Die Empfehlung ist aber nur sinnvoll, wenn die Web-Seitenbreite tatsächlich flexibel ist, andernfalls wird nämlich ein Großteil der Seite abgeschnitten, und der noch sichtbare Rest befindet sich dann im Lesen-für-Blinde-Modus.

Um das alles besser zu verstehen, gehen wir nochmal einen Schritt zurück, wir haben also die Seitenbreite (page width pw), die Viewport-Breite (viewport width vw), die Display-Breite des Gerätes (display width dw) und zwei Skalierungsfaktoren. Dabei vermittelt der erste Skalierungsfaktor (scale factor sfpv) zwischen der Seitenbreite und der Viewport-Breite und der zweite Skalierungsfaktor (scale factor sfvd) zwischen der Viewport-Breite und der tatsächlichen Display-Breite des Gerätes, und zwar nach den Gleichungen vw = sfpv·pw und dw = sfvd·vw.

Der zweite Skalierungsfaktor ergibt sich aus der Definition der Viewport-Breite, und wenn wir es hier einfach wie empfohlen bei (width=device-width) belassen, dann ist sfvd = 1, und wir haben es dann nur noch mit einem Skalierungsfaktor sf in einer Gleichung zu tun, nämlich dw = sf·pw.

Wir haben nun eine Gleichung und 3 Parameter. Wenn wir den Skalierungsfaktor zu 1 festlegen, dann kann die Gleichung nur aufgehen, wenn unsere Seitenbreite identisch mit der Display-Breite des Gerätes ist. In meinem Fall ist die Breite 980 Pixel (940 + 40 Pixel für's Padding). Wenn ich also in der Viewport-Direktive initial-scale=1.0 setze, dann zeigt mein iPhone 5s, das mit 320 Pixel Display-Breite arbeitet, eben nur ein knappes linkes Drittel der Seite an (s. Screenshot oben).

Mathematisch betrachtet ist diese Gleichung überbestimmt, d.h. wir haben mehr Gleichungen als Variablen, nämlich 1 Gleichung und 0 Variablen. Damit die Gleichung für verschiedene Anwendungsfälle aufgeht, müssen wir einen der drei Parameter variabel lassen, und in meinem Anwendungsfall mit von mir festgelegter Seitenbreite und von den jeweiligen Geräten vorgegebenen Display-Breiten kann das nur der Skalierungsfaktor sein. Deshalb lautet die Viewport-Direktive bei meinen Seiten:

   <META name="viewport" content="device-width">

In den Fällen, bei denen die Seitenbreite variabel ist, wäre damit allerdings die o.g. Gleichung unterbestimmt, d.h. mehr Variablen als Gleichungen, nämlich eine Gleichung und die 2 Variablen pw und sf. In dem Fall muß man tatsächlich den Skalierungsfaktor in der Viewport-Direktive vorgeben, also:

   <META name="viewport" content="device-width, initial-scale=1.0">

Das sind eigentlich die beiden einzigen vernünftigen Viewport-Direktiven, alles andere ist von Web-Adepten betriebenes Viewport-Vodoo.

Selbst wenn der Viewport unbestimmt bleibt, d.h. wenn man die ganze Viewport-Direktive einfach wegläßt, braucht man nur eine Seitenbreite festzulegen, und dann machen die Mobile-Devices einfach so alles richtig. Insofern ist der Viewport a complex non-solution for a simple non-problem.

Nun, der behinderte, gestörte und übergewichtige Swmnbn-Smartphone-Crawler ist aber wohl zu beschränkt, um ohne auszukommen und besteht auf einer Viewport-Direktive. Dann tun wir ihm eben den Gefallen.
 

Links zu den Pflichtinformationen – Sein oder Nichtsein?

Die Pflichtinformationen, wie Impressum, Datenschutzerklärung und Haftungsausschluß, dürfen nicht fehlen. Auf meinen Seiten habe ich dazu eine Link-Gruppe direkt neben das Obsigna-Logo oben rechts plaziert. Sind wir mal ehrlich, für diese Seiten interessiert sich ausser Abmahnanwälten und Datenschutzkleptokraten keine Sau. Die Positionierung ist also so gewählt, daß wer will einfach auf die genannten Informationen zugreifen kann, aber diese Links ansonsten nicht weiter auftragen und stören.

Unter dem Mobile-Usability-Gesichtspunkt haben wir damit aber die Rechnung ohne den Wirt gemacht, denn der behinderte, gestörte, übergewichtige und beschränkte Swmnbn-Smartphone-Crawler ist zu allem Überdruß auch noch ignorant. Ein Link ist ein Link ist ein Link ist ein anklickbares Element, reimt er sich zusammen, und diese Links müssen wie alle anderen anklickbaren Elemente auch, und zwar unterschiedslos, ob wichtig oder nicht, ob in der rechten oder linken Ecke oder mitten im Text (wie wir später noch sehen werden), von seinem fetten Zeigefinger bei 75%iger Sehbehinderung einfach angetoucht werden können, und zwar ohne die Stelle heranzoomen zu müssen.

Die Linkgruppe zu den Plichtinformationen kann auf Mobile-Devices als solche so nicht bleiben, denn die würde dann fast das gesamte Smartphone-Display einnehmen, um diesen ignoranten Crawler zufriedenzustellen. Nach einigem Ausprobieren habe ich mich dafür entschieden, für Mobilgeräte die Gruppe von einzelnen Links durch ein anklickbares Bild der Links zu ersetzen. Der geneigte Toucher wird dann auf eine Zwischenseite geführt, wo dann die Links zu den Pflichtinformationen in ausreichender Größe und ausreichendem Abstand aufgelistet sind. An dieser Seite hatte dieser beknackte Crawler auch zunächst noch rumgenörgelt, bis ich Schrift und Abstände so groß gemacht hatte, daß die Seite voll war – muß Sein!

Bei der Gelegenheit habe ich den Navigationsbereich auf der rechten Seite, in dem alle Artikel verlinkt sind, für Mobilgeräte ersatzlos entfernen müssen. Es ist ein Ding der Unmöglichkeit, eine solche Link-Liste dem behinderten, gestörten, übergewichtigen, beschränkten und ignoranten Swmnbn-Smartphone-Crawler auch nur annähernd schmackhaft zu machen. Schade eigentlich – Nichtsein mit Schaden!
 

Form und Inhalt – Einheit oder entzweit?

Für die alten Griechen war Form und Inhalt zweierlei, oder besser gesagt der Inhalt war immer derselbe, er erschien nur durch seine Form anders. Bei den alten Römer war das noch bekannt unter alter Wein in neuen Schläuchen. Spätestens seit Immanuel Kant wissen wir aber, daß Form und Inhalt eine Einheit bilden, denn wir nehmen das Wesen von allem erst durch ihre Form wahr. In diesem Geiste hatte Richard Wagner seine Gesamtkunstwerke geschaffen.

Auch mir ist es nicht egal in welche Form meine Inhalte gepresst werden müssen, damit der Swmnbn-Smartphone-Crawler glücklich ist. So müßte ich eigentlich alle Hyperlinks zu weiterführenden Informationen in meinen Texten entfernen, weil sie als anklickbare Elemente unter Umständen zeilenweise untereinander geraten können, und zwar unvorhersehbar je nach Laufweite der Schrift und den Zeilenumbrüchen, die sich daraus ergeben. Die Zeilenhöhe kann ich gar nicht so groß machen, damit der Crawler nicht meckert.

Überhaupt ist bei der Schriftgröße, die der Crawler fordert, für inhaltliche Auseinandersetzungen kein Platz, oder wieviele Kilometer will man denn nach unten scrollen, um lange Texte zu lesen.

Jedenfalls katapultiert uns dieser reaktionäre Crawler zurück zu den alten Griechen, bei denen es auf den Inhalt nicht ankam, weil der sowieso immer derselbe war. Nur die Form muß so sein, daß noch genügend Platz für die antouchbare Werbung (apropos alter Wein in neuen Schläuchen) vorhanden ist.

Von Kant kennen wir auch den Begriff Kategorischer Imperativ, wonach wir weitestgehend philosophisch begründet zwischen Gut und Böse unterscheiden können.

Als Kriterium, ob eine Handlung moralisch gut sei, wird hinterfragt, ob sie einer Maxime folgt, deren Gültigkeit für alle, jederzeit und ohne Ausnahme akzeptabel wäre, und ob alle betroffenen Personen nicht als bloßes Mittel zu einem anderen Zweck behandelt werden.

Demnach ist dieser Swmnbn-Smartphone-Crawler nicht nur behindert, gestört, übergewichtig, beschränkt, ignorant und reaktionär sondern tatsächlich auch bösartig.

Copyright © Dr. Rolf Jansen - 2021-09-25 22:24:20

Diskussion auf Twitter: 1444329361948168194