crossorigin="anonymous" referrerpolicy="no-referrer" /> Infos über Technik, Navigation dieser Website
WanderreiterWeb    Tec-Infos   
Auf dieser Seite habe ich die technischen Infos zur gesamten Website zusammengetragen. Die Infos sind neben Nutzern auch für technisch an Webprogrammierung interessierte Menschen gedacht, die eine eigene Website betreiben und evtl. für Optimierungsinformationen dankbar sind.

Vorgeschichte

Diese Website existiert seit ca. 2006. Da sich die Entwicklung des html-Systems (Internet) seitdem erheblich verändert und weiterentwickelt hat, musste ich die Seiten permanent anpassen. Insbesondere die Etablierung der mobilen Browser wie Smartphones/Tablets haben hier eine wesentliche Umprogrammierung der Seiten erfordert. Da die gesamte Webdomain mittlerweile aus über 1000 Einzelseiten, mehr als 12000 Links zu Ressourcen und Fremdseiten, mehr als. 10.000 Fotos und vielen anderen Elementen besteht kannst du dir leicht vorstellen wie aufwändig das ist und, dass ich kaum Lust dazu habe alles nach neuesten Richtlinien komplett zu erneuern (das wäre eigentlich das Optimum aber eben praktisch undurchführbar). Bisher ist es mir auch gut gelungen das bestehende System durch Anpassungen aktuell und anschaubar zu halten.

Ein riesiges Problem der Anpassung war, dass ich zu Beginn alle Inhalte wie Bilder, Texte, Links durch Tabellen in Form gebracht hatte. Damals, 2006, war das völlig normal, da gab es kaum css-Formatierung (cascading stylesheets). Aber als dann, durch die diversen mobilen Geräte, die Notwendigkeit der variablen Seitenbreiten aufkamen, musste ich feststellen, dass Tabellen dafür wirklich ungeeignet waren da sie sich nicht besonders gut den variablen Bildschirmbreiten anpassen können. Der Ausdruck "responsiv-Design" beschreibt die Tatsache, dass eine moderne Website den "viewport" des Anzeigegerätes ausliest und an Hand der darin mitgeteilten Seitenbreite den dargestellten Inhalt so formatiert, dass die Elemente in ausreichender Größe dargestellt werden, die Seitenbreite durch den Inhalt nicht überschritten wird und einiges mehr.

Viewport

Die Funktion "Viewport" ist notwendig denn es existieren gravierende Unterschiede in der Darstellungsgröße bei den diversen Displays von z.B. Full-HD, das ist 1920x1080 Pixeln, wenn diese beim Smartphone 5-7 Zoll, beim Tablet 8-12 Zoll und beim Desktopbildschirm 13-27 Zoll (und größer) betragen. Die Schriftgröße, Elementgröße von Links, Bildern etc.,  kann dabei eben nicht gleich behandelt werden sonst könnte man einen 5 Zoll-Bildschirm nicht lesen und nicht bedienen auch wenn er die gleiche Auflösung anzeigen kann wie ein 27 Zoll Desktop-Bildschirm. Diese Änderungen an einer vorhandenen alten Website kann nur durch manuelles Kopieren der Tabelleninhalte in neue Textblöcke geschehen, die dann eben responsive reagieren, Bilder sich evtl. verkleinern und Bilder/Texte zusammenfließen damit die Seitenbreite nicht den Inhalt verdeckt. Das Herauskopieren der Inhalte aus den Tabellen in ein Flex-Design mit css ist wirklich sehr viel Handarbeit. Manches habe ich genau so ausgeführt aber nicht bei allen Seiten und nicht in allen Tabellen-blöcken.

Manchmal ist Webdesign eher skurril als logisch - ich konnte einen Fehler beheben. Ein Fehler, der seit Jahren die Kartenanzeige, nur bei mobilen Geräten, nach dem Aufbau der Seite so verschoben hat (?), dass Tracks, Wegpunkte und Kartenposition nicht mehr übereinstimmte. Ich habe vieeeeele Stunden den Fehler im Programmcode gesucht und nur durch einen Zufall die externe Ursache gefunden....mehr/weniger lesen

Die Nutzer dieser Website nutzen mittlerweile mehr mobile Geräte als Desktob-PCs. Ich habe pro Jahr etwa 30.000, von der Statistiksoftware MATOMO gezählte, Besucher, davon 17.000 mit mobilen Geräten. Da die Software bei Weitem nicht alle Besucher erfasst (wir respektieren die Ablehnung des Trackings und andere Richtlinien), sind es vermutlich ❯ 30-??% mehr. Es gibt daneben die Facebookseite, in der eine Auswahl der Informationen und Bilder zu sehen sind. Der Nachteil dieser sozialen Medienseiten ist jedoch die Ex- und Hopp-Mentalität "einmal sehen und vergessen"! Nichts kann auf Grund der Massen an Posts irgendwie später wiedergefunden werden - intelligente Information und Wissensbildung geht anders. Es dreht sich heute alles nur noch um den "Kick" - daher kommt auch das populistische Gebahren mancher politisch oder marketingmäßig motivierten Subjekte so gut an.

Die nachfolgende Änderungen habe ich bis jetzt vorgenommen

dark mode

Die aktuellste Änderung bei der Mobiloptimierung ist der Dark-mode. Martin Smaxwil (s.u.) zitiert seinen Prof mit den sinngemäßen Worten: "Das Auge ist ein 'Lichtsucher' und 'Reizsucher'. Vor allem für elektronische (Lese-) Medien gilt: Bei dunkler Schrift auf hellem Grund wird zuvorderst die weiße Fläche (Lichtreiz) wahrgenommen und erst in einem zweiten Schritt der Buchstabe als 'Unterbrechung dieser leuchtenden Fläche'. Die kognitive Leistung der notwendigen Invertierung von 'Lücke in der Leuchtfläche' zu 'Buchstabe' kostet Energie und Zeit, die bei heller Schrift auf dunklem Grund recht einfach eingespart werden kann." - das leuchtet ein, auch wenn ein Buch nichts anderes macht als eine Seite im light-mode, das Auge dies also als gewohnt wahrnimmt!

Der Darkmode hat sich durch die vielen mobilen Geräte mittlerweile etabliert, was überwiegend am geringeren Akkuverbrauch und der bevorzugten Nutzung in dunkler Umgebung liegt. Da die meisten User mittlerweile mit Mobilgeräten auf die Seite zugreifen, habe ich hier eine Notwendigkeit gesehen und lange am Darkmode getüftelt. Nun habe ich diesen integriert - das aktuelle Script ist mein 2. Darkmode-Versuch. Der erste bestand nur aus dem Zustand light und dark und war mir zu einseitig, da das system in dark die User-Einstellung ersetzt hat. Der User wurde letztlich immer auf dark geleitet, hatte nicht wirklich die Wahl, die Systemvorgabe war nicht extra speicherbar. Dieses relativ simple Script kam von: Martin Smaxwil.

Nun habe ich ein 3-Phasen-Script integriert. In der Fußleiste befindet sich das Mode-Symbol zum Wechseln. Möglich sind die Einstellungen: light, dark und system. Das Symbol zeigt light und dark . Bist du das erste Mal auf Wanderreiterweb.de, dann erscheint nebem dem light/dark-Schalter in der Fußleiste "system". Das heißt, die Webseite folgt den Systemeinstellungen für das hell/dunkel-Thema. Dies kann vom Betriebssystem oder von der Einstellung des Browsers vorgegeben werden, es kann somit auch zeitabhängig sein, je nachdem was dein Gerät erlaubt. In light und dark bleibt das Layout-Thema genau dort. Bist du mit dem gleichen Gerät/Browser wiederholt auf der Seite und hattest vorher einen Modus (außer System) gewählt, dann stellt sich dieser nun ein. Die Speicherung erfolgt im lokalen Speicher der jeweiligen Browser-App und nicht als Cookie.

Bitte teste den Dark-Mode denn das ist eine logische, stromsparende und damit ökologische Maßnahme aber auch designtechnisch kommen Fotos auf dunklem Hintergrund viel besser zur Geltung. Alle Styles wurden so angepasst, dass sie auf dunklem Hintergund gut zu erkennen sind und, dass der Vordergrund nicht blendet. Wenn du längere Zeit im Darkmode liest/arbeitest wirst du ihn zu schätzen wissen. Der Status wird in deinem Browser abgespeichert, so dass beim nächsten Aufruf oder auf einer anderen Seite des WanderreiterWebs, die Seite im gleichen Modus ist wie zuvor von dir bestimmt. Das Script wurde von mir leicht verändert und an meine Seite angepasst. Quelle des Original-Scriptes und ein gutes Tutorium: DEV-community

white flash

Es ergab sich bei der Einrichtung des Darkmode-Scriptes jedoch ein Problem. Beim Seitenaufbau flasht, je nach Geschwindigkeit oder Rechenpower des Gerätes, mehr oder weniger kurz, ein weißer Hintergrund auf. Das ist ein viel erwähntes Thema im Netz - es gibt unzählige Lösungsvorschläge aber leider hat keiner so richtig Erfolg gezeigt. Ich bin zu der Überzeugung gekommen, dass vor allem reine html-Systeme von diesem Problem betroffen sind. Es liegt einmal (beim Erstaufruf der Website) an der Aufbaugeschwindigkeit der Seiten (Netztraffic, Internetgeschwindigkeit, Rechenpower des Gerätes) und an der Tatsache, dass eine leere Browserseite, standardmäßig einen weißen Hintergrund hat, selbst wenn der sich im Darkmode befindet. Diese weiße Seite erscheint bis die aktuelle html-Seite angezeigt wird.

Zum Anderen liegt es daran, dass der standardmäßig eingestellte Modus (normalerweise light) erst durch das Script auf dark umgestellt werden muss und dieses Script befindet sich aus Performancegründen am Ende der html-Seite. Bei php-Systemen ist es leichter diesen white Flash beim Seitenwechsel innerhalb einer Website zu verhindern, da nicht die gesamte Seite neu geladen werden muss. Auf einen Hintergrund, der im dark-Modus dunkel, im light-Modus hell ist und der beim "Seitenwechsel" erhalten bleibt, wird nur neuer Content in den Vordergrund geladen. Die Styles des Vordergrundes werden durch die dark/light css-styles entsprechend angepasst. Auch ist eine php-Seite wesentlich schneller und unabhängig von der Rechenpower des Anzeigegerätes da ein Teil des Renderings der Server übernimmt und nicht der Browser des Nutzers. Dies betrifft zumindest den Seitenwechsel innerhalb einer Website, nicht den Erstaufruf.

Das ist ein Vorteil von CMS (Content-Management-Systemen - es gibt aber auch Nachteile). So werden mit php die html-Seiten virtuell erstellt und dann an den Browser gesendet und angezeigt. Eigentlich gibt es diese nicht wirklich sondern nur EINE php-Seite, welche die html-Elemente variabel in den dafür vorgesehenen Positionen erstellt und dann anzeigt. Diese virtuelle html-Seite hat dann auch eine URL (https-Adresse), so dass der Aufruf dieser Adresse den Vorgang des Erstellens der virtuellen html-Seite provoziert.

In reinen html-Sytemen wird jedoch die "alte" Seite durch eine komplett neue ersetzt und der Standardhintergund des Browsers, der vor dem kompletten Aufbau der Gesamtseite erscheint, ist auch im Darkmode weiß. Je nachdem wie gut die Infrastruktur oder die Netzverbindung ist, flasht das kurz oder lang weiß auf. Im hellen Modus fällt das nicht auf da eh alles weiß ist, aber im dunklen Modus stört es doch sehr. Desweiteren ist jede Seite ja in einem festgelegten Grundmodus programmiert, in der Regel schwarz auf weiß. Nun benötigt die Umschaltung der Seite bei Aufruf einer neuen html-Seite, aus dem Darkmode heraus, geringfügig Zeit, damit das Script den Modus umschalten kann. Auch das kann zu kurzem "white flash" führen.

Grundsätzlich ist der Darkmode aber wichtiger als dieses kleine Flickern beim Seitenwechsel. Gerade die Smartphones laufen oft im darkmode, weil das im Dunkeln angenehmer für die Augen ist und auch erheblich stromsparender und weil die Displays in heller Umgebung (Sonneneinstrahlung) den Inhalt mit weißem Hintergrund grundsetzlich schlecht darstellen. Der Schalter für dark/light ist ein Javascript, das prüft in welchem Modus sich die Seite:

War die Seite im light-mode dann fiel das nicht auf und man benötigte auch kein Script um das umzuschalten. War die Seite im Darkmode erschien das helle Aufblitzen der Leerseite (1. kurze Verzögerung) und dann dann erschien die Light-Variante der Website und das Script schaltete die neue Seite auf dunkel (2. kurze Verzögerung).

Meine Lösung ist nun Folgende: Ich habe jede Seite als Standard (durch einen Trick) auf dunklen Hintergrund gesetzt und lasse die neue Seite mit einem Fade-In-Effekt einblenden (0,5 Sekunden lang). Durch diese Änderungen gibt es im Darkmodus, zumindest beim Seitenwechsel innerhalb der Website, kein Aufblitzen mehr, da die neue Seite ja auch mit dunklem Hintergrund startet, und das bevor der gesamte Inhalt geladen ist und angezeigt wird. Danach erfolgt die Prüfung auf den lokalen Speicher. Ergibt die Prüfung dunkel passiert mit dem Hintergrund nichts, die neue Seite wird eingeblendet. Ergibt sie hell, dann erscheint die neue Seite mit weißem Hintergrund. Manchmal ist die Netzverbindung sehr schlecht oder irgend ein Script hängt kurz, dann kann es auch jetzt kurz, aber deutlich weniger oft, flackern. Im hellen Modus gibt es dafür jetzt ein mehr oder weniger kurzes Erscheinen des dunklen Hintergrundes bis das Script greift und alles auf hell umschaltet. Das ist aber durch den Einblendeffekt etwas kaschiert und bei Weitem nicht so störend als der helle Flash in einer dunklen Umgebung - aber es ist auch nicht wirklich ein gelöstes Problem - aber mir scheint es auf einer "nur"-html-Website nicht komplett lösbar.

Displayfläche optimieren

Dann sind die Menuleisten als wichtige Neuerung zu sehen. Ursprünglich hatte ich diese auf allen Seiten oben fixiert, damit man von jedem Punkt der Seite darauf zugreifen kann. Ich wollte kein Akkordeon-Menu zum Ausklappen, da das entsetzlich umständlich ist, wenn es viele Seiten (in Folge) in einer Sektion gibt. Zu viele Klicks wären nötig um weiter oder zurück zu blättern und eine Übersichtlichkeit ist nicht vorhanden. Auf Mobilgeräten wurde dann sichtbar, dass eine fixierte Menuleiste nicht geht, denn die Menus überdecken dann einen Großteil der lesbaren Fläche. Also musste die Fixierung bei kleinen Displays aufgehoben werden, damit das Menu nach oben weg scrollt. Dann aber ist das Menu wiederum nicht schnell erreichbar! Nun habe ich, glaube ich, eine optimale Lösung gefunden.

Ich habe zwei Menuleisten programmiert: Die obere erscheint wenn der Cursor am Seitenanfang steht und verschwindet, wenn nach unten gescrollt wird. Die untere Leiste verschwindet wenn nach unten gescrollt wird und erscheint beim "nach-oben-scrollen". Auf breiten Displays bleibt sie immer sichtbar. Auf der unteren Menuleiste sind entweder aktuelle Links wie "Home", "Top", "Datenschutzerklärung", oder, auf Seiten wo das Sinn macht, kontextsensitive Links wie "zurück zur letzten Seite" (in logischer Reihenfolge), "Top" und "zur nächsten Seite". Außerdem befindet sich auf der Fußleiste links ein Link zur Facebook-Seite "Wanderreiterweb" und rechts der dark/light-Umschalter.

Dazu gibt es ein oben rechts fixiertes "Hamburger" Symbol "" zum manuellen Ausklappen beider Leisten von jeder Stelle der Seite aus. Nun kann man zur besseren Übersichtlichkeit und dem schnelleren Durchbättern, die Leiste ausklappen, und schnell mit den Buttons der Fußleiste blättern. So findet man beim Blättern innerhalb einer Sektion, eine gesuchte Seite schneller!

Grundsätzliche Darstellung

Die Lesbarkeit von langen Texten ist verbessert worden. Der Text wird beim Verkleinern des Screens größer und so ist eine gute Übersichtlichkeit über die vielen Inhalte gegeben und die Links sind besser aufrufbar. Dazu hätte ich eigentlich alle inline-Formatierungen der Schriftgröße, die früher in jedem Absatz und in unterschiedlichen Formen vorkamen, entfernen müssen und das wäre (wegen der diversen Formatierungsarten) nur von Hand möglich gewesen. Das wäre eine immense Aufgabe und ich habe lange damit gehadert, das zu tun. Jetzt ist mir die Lösung dazu eingefallen.

Ich habe einfach alle (font-size) Größenwerte in allen Seiten/Abschnitten und Texten mit einem "Suchen und Ersetzen Tool"auf "font-size:1rem" gesetzt (rem bezeichnet das Vielfache der als Standard festgesetzten Schriftgröße). So konnte ich, in einem Durchgang, die unterschiedlichen Größen an verschiedenen Stellen jeder Seite neutralisieren ohne den Wust an verschiedenen Formaten (12px, 12pt, 14px, 14pt, x-small, small, medium, usw.) in den diversen Formatierungs-Tags zu finden und zu löschen. Nun sind die Angaben noch da, beziehen sich aber auf die, in der externen Formatdatei vorgenommene Standardgröße und wirken sich somit nicht aus. Auch durch die mittlerweile vergebenen Klassen reagiert die Schriftgröße wieder auf Änderungen bei geänderter Displaybreite (durch media queries in der css-Datei) obwohl die inline-Formatierung "Schriftgröße" nicht komplett entfernt wurde!

Durch eine Einschränkung der Breite von Textblöcken konnte die Lesbarkeit weiter verbessert werden. Ein Text ist dann gut lesbar, wenn in einer Zeile etwa 8-12 Wörter stehen. Seit einiger Zeit habe ich mit Spaltensatz, experimentiert. Nun sind auf allen Seiten die Texte (ich weiß ja, dass ich gerne lange Texte schreibe) dahingehend geändert. Die Spalten haben den Vorteil gut lesbar zu sein und automatisch untereinander zu fließen wenn die Seitenbreite nicht mehr ausreicht.

preview-Bilder

Eine weitere "Optimierung der Website für kleine Displays! Ich bin schon längere Zeit dabei die vielen Texte der Rittbeschreibungen und auch der Wikiseiten anschaulicher zu machen. Neben der besseren Lesbarkeit durch kurze Spaltenzeilen und größere Schriftart je kleiner das Display, wollte ich kleine Bildchen in die Texte einbringen, die auf Klick in eine Lightbox vergrößert werden können. Was mich bisher davon abgehalten hat, war der Hinweistext bei jedem Preview-Bild. "Bitte Klicken zum Vergrößeren". Ohne diesen Hinweis, bemerkt ein Touchscreen-Nutzer nicht, dass hinter dem kleinem Preview-Bild eine Lightbox wartet. Nun habe ich eine CSS-Stylesheet-Anweisung erstellt die jedes, vergrößerbare, oder alternativ darstellbare, kleine preview-Bild mit einem Symbol kennzeichnet. Diese Lupe wird den Hinweis in Zukunft sicherstellen. Das sieht dann so aus:

print styles

Weiter habe ich durch einen Eintrag in der css-Formatdatei dafür gesorgt, dass in Zukunft Ausdrucke ohne lästige Menuleisten und schwebende Elemente gedruckt werden können. So verhindert zum Beispiel der css-Eintrag:

@media print {#facebook, #kopf-fixed, .nav-b, .button {display:none;}}

den Ausdruck der schwebenden/fixierten 4 Elemente mit der betreffenden ID/Class, die sonst auf jeder Druckseite erscheinen würden und auch Text überdecken könnten.

Grundsätzlich ist ein Ausdruck tricky, denn die A4-Seite entspricht in keiner Weise der Bildschirmformatierung und Browser-Programmierer legen keinen sonderlichen Wert auf den Ausdruck. Ich habe die meisten Texte für den Ausdruck optimiert, bei Links wird die Zieladresse in rot und in Klammern mit gedruckt (sehr sinnvoll). Die interaktive Karte auf den Trackseiten - hier wird der Track gerne abgeschnitten, da die Größenzuweisung unter Zwang geschieht und der Kartencontainer in der Druckvorschau nicht mehr reagieren kann. Also vorher gewünschten Kartenhintergrund wählen, eine Stufe verkleinern und Tooltip des Wegpunktes schließen. Die Kartenkontrollelemente und copyright-Texte werden nicht mitgedruckt. Ansonsten - Ausdruck mit der Option "an Seite anpassen" auf DIN A 4 ergibt ein einigermaßen gleichmäßiges Druckbild, ob Drucker oder pdf!

Responsive-design und touchscreens

Darstellung auf mobile devices: Um das WanderreiterWeb für Smartphones mit Ihren kleinen Bildschirmen optimal anzuzeigen habe ich auf den Hauptmenü Seiten einiges angepasst. Ich habe eine Funktion eingebaut, wodurch Textblöcke, die auf Touchscreeens nicht gut angezeigt werden oder sinnlos sind, ausgeblendet werden. Dieser Abschnitt verdeutlicht dies! Auf Desktop-Rechner mit Maus und Pointer wird der Block in der Farbe rot, bei Touchscreens ohne Pointer in gelb dargestellt. Du betrachtest die Seite auf einem Gerät mit Pointer (Mauszeiger)!

Darstellung auf mobile devices: Um das WanderreiterWeb für Smartphones mit Ihren kleinen Bildschirmen optimal anzuzeigen habe ich auf den Hauptmenü Seiten einiges angepasst. Ich habe eine Funktion eingebaut, wodurch Textblöcke, die auf Touchscreeens nicht gut angezeigt werden oder sinnlos sind, ausgeblendet werden. Dieser Abschnitt verdeutlicht dies! Auf Desktop-Rechner mit Maus und Pointer wird der Block in der Farbe rot, bei Touchscreens ohne Pointer in gelb dargestellt. Du betrachtest die Seite auf einem Gerät ohne Pointer (Mauszeiger)!

Ausnahmen: Bei manchen Geräten mit Stifteingabe wird dieser als Mausersatz erkannt (er hat evt. einen Pointer), manche Browser könnten die Anweisung ignorieren (getestet auf Firefox, Chrome, Opera, Edge)!

Diese Maßnahme ist notwendig, da auf Touchscreens manche Funktionen nicht vorhanden sind und die Anzeige dann sinnlos werden könnte. Sinnlos werden z.B. Menus, die auf kleinem Raum viele Menupunkte zeigen und durch Überfahren mit der Maus eine Kurzbeschreibung des Menupunktes anzeigen, denn ein Touchscreen ohne Pointer (Mauszeiger) und ohne Hover wird diese javascript-Menus nicht anzeigen. Weiter ist die zoom-Funktion auf allen Touchscreens jetzt wieder abgestellt. Ich hatte sie bisher zugelassen, damit man die oftmals sehr kleine Schrift lesen konnte. Nach der konsequenten Mobiloptimierung ist das jetzt nicht mehr so notwendig und die Nachteile des Zoomens sind auf mobile devices doch gravierend. Ein Zoomen auf den kleinen Bildschirmen bringt sehr viele Positionierungen von Blöcken, Menuleisten und Anderem durcheinander und diese funktionieren danach schlecht. Manche Browser/Geräte akzeptieren das Zoomverbot jedoch nicht da es ein Hindernis für barrierefreie Darstellung ist.

Barrierefreiheit im Web

Bei Sehbehinderungen könnte man ein Vergrößern des Textes als sinnvoll erachten aber es gibt vermutlich Zusatzprogramme und plugins die dies trotz Sperre ermöglichen. Ein Vergrößern auf Desktopbildschirmen ist auch jetzt jederzeit möglich. Für eine 100% barrierefreie Website müsste ich alt-Tags in den Bildern mit genauer Beschreibung der dargestellten Szene erstellt haben und andere sogenannte aria-labels platzieren - ich sehe mich zeitlich außerstande jedes der bisherigen, mehr als 21.000 Bilder und vieler anderer Teile der Website mit einem beschreibenden "alt-attribut" für Screenreader zu versehen. Ein Screenreader nimmt die alt-Tags und aria-labels von Steuerelementen, wie z.B. Menus, buttons und Links, und liest dem Nutzer diese dann vor.

Dieses hatte ich bisher leider aus Unkenntnis nicht gepflegt da es bei den Mengen an Fotos wirklich viel Mehrarbeit ist, für Menschen die das Bild nicht sehen können, eine genaue Beschreibung einzugeben. Ich bezweifele auch, ehrlich gesagt, dass es sinnvoll möglich ist und viel Nutzen bringen würde. Diese Beschreibung müsste sehr ausführlich sein um wirklich Nutzen zu bringen. Ich lege Wert darauf, dass nicht nur Infos gefühlsneutral übermittelt werden sondern mir ist das Design und die Wiedergabe der Stimmungen enorm wichtig. Was nutzt einem Menschen ohne Augenlicht die Aussage "Pferd mit Reiter vor schroffen Bergspitzen", ohne dass mehr Emotionen, die dieses Bild auslösen, vermittelt werden. Alleine die Farben können enorm emotional sein. Aber eine Farbkonstellation kann man nicht wirklich mit Worten beschreiben - leider. Und ich bezweifele auch, dass es viele Menschen mit Sehverlust gibt, die sich für Reiten und Wanderreiten interessieren und dies praktizieren (auch wenn das für diese Menschen wirklich ein Highlight an Lebensqualität wäre). Gäbe es ein nennenswertes Interesse daran, dann würde ich mir die Mühe machen und die Website nach diesen Richtlinien nochmals überarbeiten.

TV-Displays

Die Anzeige auf TV-Geräten, in Full-HD, ist jetzt so groß, dass Texte aus einer weiteren Entfernung lesbar sind. Dies funktioniert nur bei Vollbild denn sonst hätte man diese riesigen Buchstaben auch auf 14 Zoll Notebooks. Für 4K-TV-Geräte habe ich bisher keine Anpassung vorgenommen - mir fehlt das Testgerät bzw. ich habe den Verdacht, dass die Browserauflösung auf 4k-Geräten nur in Full-HD angezeigt wird, denn ich konnte keine Vergrößerung durch css erreichen. Sollte der Text auf 4k-Displays zu klein sein, dann musst du dich mit der Vergrößerungsfunktion (>100%) des Browsers behelfen - wenige Seiten im Web werden daraufhin angepasst sein.

Sektion Wanderritte

Die Content (Inhalts) -seiten sind bis etwa Mitte 2018 für Desktop-PCs geschrieben. Das Menu am Seitenkopf ist jetzt auch auf den älteren Seiten responsive (für Mobilgeräte optimiert), ebenfalls das Titelbild und die interaktive Karte mit Tracks und Wegpunkten und die Rittbeschreibung danach. Lediglich der danach folgende Bilderblock ist, bei Seiten bis etwa 2018, nur an mobile Darstellung angepasst. Die Technik und die Größe der Smartphones lässt nur eine eingeschränkte Darstellung dieser Bildersektion zu, sie sind jedoch gut anzusehen da man sie auch vergrößert im Landscape-Modus (quer) betrachten kann. Die Anpassung dieser, in Tabellen formatierten Bilder, war äußerst kompliziert, denn ein manuelles Übertragen in eine mobiloptimierte Flex-Struktur hätte das Kopieren von ca. 20-25.000 Zellinhalten bedeutet - das war mir deutlich zu viel. Vor Allem da ein automatisiertes Ersetzen hier nicht funktionieren konnte (zu viele verschiedene, Texte, Bilder, Größen und Formate). Dadurch wäre eine automatisch durchlaufende Ersetzenfunktion zu kompliziert und äußerst fehleranfällig gewesen.

Aber durch Nachdenken ist mir die Lösung erschienen (⁠⁠)  und ich habe durch ein "Suchen und Ersetzen-Tool" die internen Größenangaben aller Bilder in einem Durchgang entfernen können. Diese Größenangaben verhinderten nämlich, dass sich Tabellen dem Bildschirm anpassen. Jetzt werden die Tabellen auf Bidschirmweite skaliert. Es zeigt jetzt zwar 2 Bildern nebeneinander (auf Smartphones ist das sehr klein), aber dies ist deutlich besser als der, nach rechts über die Displayfläche hinausragende Bilderblock. Die nicht eindeutig definierte Seitenbreite hatte auch noch andere gravierende Nachteile beim Anschauen der Seiten auf dem Handy, wie zum Beispiel fehlerhafte Anzeige von fixierten Fußleisten und anderen Elementen. Bildbeschreibungstext war früher viel zu klein, weil er mit skaliert wurde, er verhält sich jetzt wie überall und skaliert größer, je kleiner das Handydisplay ist, bleibt also lesbar.

Ein Tipp: kleine Displays stellen die Bilder im Querformat in der Regel gut dar. Tablets zeigen die Seite, auf Grund der größeren Displayfläche, wesentlich besser an. Alle neueren Inhaltsseiten der Sektion Wanderritte, (ab Veröffentlichung Mitte 2018) sind nun vollständig responsive. Bilderblöcke verhalte sich auf den neueren Seiten wie Spaltentext und fließen aus zweispaltiger Anzeige, beim Schmäler werden, untereinander und zeigen so immer die optimale Größe.

Interaktive Karte

Einbindung von Topografischen Karten: Auf den Wanderrittseiten gibt es zu Beginn immer eine interaktive Karte auf der die Tracks und evtl. Marker für Wegpunkte auf einer OSM-Straßenkarte dargestellt sind. Über ein Ebenenmenu in der Karte kann man zur Wanderreitkarte, einer Open-Topo und einer Satellitenansicht wechseln. Auch diese Karte ist durchgängig auf smartphones darstellbar. 

Sektion Trailritte

Die Contentseiten der Trail-Sektion sind nur an mobile Geräte angepasst. Auf Grund der überbreiten Bilder (900/1200 pixel) der Fotobücher macht es aber keinen großen Sinn diese Seiten in Smartphones aufzurufen da die Bilder auf Bildschrirmbreite skaliert werden. Auf Tablets ist die Ansicht perfekt. Allerdings werden die Trailseiten seit einiger Zeit nicht mehr erweitert, ich habe zwar noch 1-2 Ritte nicht veröffentlicht - es ist mir aber zu viel Arbeit. Es ist leider inzwischen eine schiere Katastrophe mit Bildern von anderen Rittteilnehmern, da viel zu viele Smartphones viel zu besch***ene Bilder in viel zu vielen Formaten und Farbtönen fabrizieren. Ein Anpassen aller Bilder an ein durchgängiges Layout ist wohl möglich aber extrem aufwändig und unbefriedigend.

Videos

Ich habe, über die Website verteilt, einige Videos von Youtube eingebettet. Das Einbetten hat den Vorteil, dass mein Provider in der Regel keinen, für Videostreaming spezialisierten Server betreibt, bzw. dieser in einer anderen Preiskategorie liegt als ein Standardserver. Beim Einbetten von Videos gibt es aber auch Nachteile: Der Hoster (Youtube, Facebook oder wer auch immer) setzt jede Menge Cookies und versucht seine Werbung an den User zu bringen. Die Webseiten registrieren schon beim Laden eine unglaubliche Menge an Anfragen, zum Teil Fehlermeldungen, der Seitenaufbau wird dadurch verzögert und die DSGVO wird in der Regel nicht erfüllt. Klickt man dagegen auf einen Link-Button und öffnet die Youtube-Seite, wird die Einwilligung, Cookies zu akzeptieren, von Youtube abgefragt und erst danach werden diese gesetzt.

Hat man ein embedded-Video in einem InlineFrame (eingebettet) werden Cookies in der Regel schon beim Seitenaufbau ungefragt gespeichert und der Hoster beginnt mit dem Abgreifen von Informationen. Nun hat Google zwar einen "Dateschutz-Modus" zum Einbetten, der Zugriff erfolgt über "www.youtube-nocookie.com/embed/[Video-ID]", aber dennoch gibt es zahlreiche Zugriffe auf die Seite bevor überhaupt ein Video zum Abspielen angeklickt wurde. Mit der Seite PageSpeed Insights kann man sich die Ladegeschwindigkeit einer beliebigen Seite anzeigen lassen. Meine Seite "Videos" z.B. hatte eine Ladegeschwindigkeit von 31/100 Punkten mobil und 52/100 beim Desktop-PC. Das ist schlecht und behindert ein gutes Ranking, belastet den Browser und nervt. Wenn auf einer Seite viele Videos sind dauert die bloße Anzeige der Vorschaubilder aller Filme schon ein paar Sekunden, da zu jedem Video die URL abgefragt werden muss und der Download der ersten Daten abgewartet werden muss bis das nächste Video abgearbeitet wird, usw.

Ich habe lange gesucht, die meisten Skripte funktionierten nicht, da sie meist für CMS-Systeme/in php-Umgebungen geschrieben wurden und in einfacher html-Umgebung funktioniert das dann nicht. Jetzt habe ich ein Javascript gefunden, das verhindert, dass Verbindung zum Video-Server schon beim Seitenaufbau hergestellt wird. Das Script ist von einem "Bastler aus dem #TeamHalbwissen" und funktioniert einfach genial. Der iframe wird erst durch Klick auf einen Button freigegeben und baut die Verbindung nur für dieses Video auf. Ich habe das Originalscript stark verändert und an meine Bedürfnisse angepasst. Jetzt sind Vorschaubilder, als Hintergrund des iframes, lokal abgespeichert, denn sonst wären alle iframes leer, schwarz oder andersfarbig bis die Verbindung zum Server freigegeben ist - das ist designtechnisch ein "no go", es würde auch sehr abweisend auf den Nutzer wirken.

Du kannst es auf meiner Video-Seite testen. Damit erreiche ich bei PageSpeed jetzt für Mobil-Geräte 88% und für Desktop-PCs 97%, das war bei beiden Endgerätearten 54% Geschwindigkeitssteigerung! (die Ergebnisse bei PageSpeed sind variabel, mal mehr mal weniger) Ich habe es bei allen Seiten mit eingebetteten Videos eingebaut und habe dann endlich eine DSGVO-konforme, schöne und user-freundliche Einbindung der Videos. Die Einwilligung zu Cookies nach DSGVO werden zwar grundsätzlich durch das ccm-Banner abgefragt, jedoch ist die Verbindungsverhinderung mit einer Datenkrake sicherlich eine gute Sache. Übrigens verhindert eine Ablehnung der Youtube-cookies keine Wiedergabe eines Videos weil eben im erweiterten Datenschutzmodus keine Cookies gesetzt werden. Aber genug anderer Schrott prasselt auf den Rechner ein - wenn man sich mal den Verbindungsaufbau in den Entwicklertools des Browsers anschaut!

Navigation und Suche

Auf allen Hauptseiten findest du am Anfang das Main-Menu, von denen aus du fast alle Themenbereiche direkt erreichen kannst, und auf den meisten Hauptseiten eine Suchfunktion (Volltextsuche mit eigenem php-Script). Ich habe endlich ein einfaches Script gefunden und angepasst um die lästige Google-Suche rauszuschmeißen. Das Script setzt keine Cookies, ist schnell, umfangreich von mir konfigurierbar und viel gründlicher als die Google-Suche je war. Ich habe vorher auch andere Suchanbieter getestet, die waren nicht besser als Google. Allen ist es gemeinsam, dass sie nur deine Daten wollen, dafür die unvollkommene Suchfunktion anbieten. Jetzt gibt es keine Anzeigen mehr und keine Gefahr, dass Daten abgegriffen werden. Und die Ergebnisse liegen in Echtzeit vor. Quelle des Scriptes: Werner Zenk

Die Suche findet jedes Wort auf allen Seiten, ist jedoch aus Laufzeitgründen auf 50 Treffer begrenzt. Das dauert bei knapp 600 freigegebenen Seiten ca. 0,6 sec, da php direkt auf dem Server ausgeführt wird. Gratis angeboten wird es von einem Menschen der auch seine Arbeit für andere freigibt. Bei der Google-Suche musste man immer ein paar Monate warten bis alle neuen Seiten indiziert waren. Und auch dann fehlten teilweise wesentliche Treffer. Google ist eine tolle Suchmaschine über das gesamte Web hinweg, aber für das Durchsuchen einer einzigen Website nicht wirklich geeignet. Die Ergebnisse der Suche werden auf einer eigenen Seite "Volltextsuche" angezeigt, von der aus man dann das Ergebnis annklicken, oder wieder auf die Ausgangsseite der Suche, zurück kann.

DSGVO

DSGVO: Datenschutzgrundverordnung (allein der Name ist schon bescheuert). Auf Grund der DSGVO habe ich etliche Änderungen an der Website vorgenommen. Die Datenschutzerklärung aktualisiert, einen Link zu dieser auf viele Seiten gestellt und ein Cookie-Banner implementiert, das vor der Nutzung der Website die Erlaubnis oder Verweigerung von Cookies und/oder Datenweitergabe an Dritte abfragt, dies aber nur auf einigen wenigen Seiten, die Dienste von Drittseiten (Facebook, Google, Youtube) implementiert haben. Das Cookie-Banner funktioniert optimal, allerdings enthalten die meisten Seiten keine Abfrage da keine Cookies von Drittanbietern oder zu Werbezwecken gesendet werden. Nachträgliche Änderungen der DSGVO-Einstellungen sind hier möglich:

Einstellungs-Icon
im Impressum

Cookie-Genehmigung

Auch wenn WanderreiterWeb.de fast keine eigenen Cookies einsetzt (außer für das Cookie-Banner), habe ich dieses Tool auf allen Seiten eingesetzt die Fremddienste implementieren und damit fremde Skripte aufrufen. Es ist für mich nicht sicher, dass diese keine Cookies setzen auch wenn ich es bei der Installation der Dienste nach Möglichkeit ausgeschlossen und es zu Beginn getestet habe. Aber ich bin nicht in der Lage dies ständig zu überwachen. Die meisten Skripte, auch die welche zum Aufruf der Kartenimplementierung auf allen Wanderrittseiten dienen sind auf WanderreiterWeb.de gespeichert. Die Kartendaten kommen natürlich per ssl-Verschlüsselung von den entsprechenden Servern, aber eben keine Skripte! Auch ein Großteil anderer Fremdscripte rufe ich intern von der eigenen Seite ab. So kann eine nachträgliche Änderung vom Scriptersteller verhindert werden.

social media

Alle Facebook-plugins (like-buttons) habe ich aus Datenschutzgründen durch reine Bild-Links ersetzt, die keine Cookies speichern und keine Daten weitergeben, es sei denn man klickt sie an und verlässt damit WanderreiterWeb.de. Ausnahme: Home, Wanderreit-Startseite und Instagram-Seite, dort ist jeweils ein IFrame zur Facebookseite "WanderreiterWeb" platziert.

Moderne Browser sind durchaus in der Lage Cookies von Drittseiten zu blockieren, dies muss nur in den Einstellungen der Browser angeklickt werden. Wenn allerdings die Seite WanderreiterWeb über einen Link verlassen wird ist das nicht mehr gewährleistet, da es dann keine Drittseiten mehr sind.

Grundsätzliches dazu

Man sollte, bezüglich der Nutzung der Daten, die manche Seitenbetreiber wie Youtube oder Facebook erheben immer bedenken: Schließlich ist auch die bezogene Leistung, diese Inhalte, Videos, o.ä. bereitzustellen, mit Kosten verbunden und ich finde es nicht verwerflich, diese Kosten in Maßen durch Werbung zu erwirtschaften. Wer dies grundsätzlich ablehnt, darf solche Seiten im Internet, auch meine Seite WanderreiterWeb.de, eben nicht nutzen. Ich kann es mir leisten diese Dienste gratis anzubieten, es ist mir sogar ein Bedürfnis dies zu tun, aber die Kosten sind auch überschaubar, nicht zuletzt, aber auch, und gerade durch die "böse" Werbung/Datennutzung im Internet. Durch diese, oft kostenlose Leistung, fallen auch meine Kosten gering aus. Das ist meine persönliche Meinung dazu!

Die gegenwärtige Regelung nach dem DSGVO ist nahezu schwachsinnig, da sie nur dazu führt, dass sich jeder Nutzer auf jeder aufgerufenen Seite über die permanent aufpoppenden Cookie-Banner ärgert und fast ausschließlich auf "alle annehmen" klickt, was ja praktisch immer hervorgehoben dargestellt wird, um nicht noch mehr aufgehalten zu werden - also kontraproduktiv im Sinne des DSGVO. Gerade beim "sich informieren" über mehrere Seiten hinweg ist das eine schiere Katastrophe. Und das witzige, makabre Detail: Das Cookie-Banner, welches dem Nutzer die Entscheidung abverlangt, zu wählen ob und welche Cookies er speichern will, funktioniert nur durch ein Abspeichern eines weiteren oder mehrerer weiterer Cookies. Ohne diese würde der Aufruf JEDER Seite eines Webs wiederum das Banner erzeugen und das ist selbst den Datenschützern zu heftig. Löscht man konsequent und regelmäßig alle Cookies im Browser dann steht man bei jeder bekannten Seite wieder auf "noch nie dagewesen". Das einzige, auf WanderreiterWeb gespeicherte Cookie kommt von der Cookie-Abfrage-Software - ist das alles nicht irrsinnig?

Das ist ein Bürokratiemonster PUR, verordnet durch die EU - sorry da hat niemand mehr Verständnis zu und das kostet die Wirtschaft bald mehr als der Unterhalt der Onlinefunktionen.

Es gibt übrigens für praktisch alle Browser ein plugin, das sehr viele der automatisch aufpoppenden Cookie-Banner wegklickt. Suche nach: I don't care about cookies. Das funktioniert nicht bei allen Seiten/Bannern, aber ausreichend. Nichts ist nervender als beim Suchen über mehrere Webseiten hinweg ständig diese blöden Cookie-Banner zu sehen. Das zerstört sämtliche Vorteile die uns das Internet bietet, aber leider sind die Seitenbetreiber dazu verpflichtet diese Warnung anzeigen zu lassen. Andernfalls drohen horrende Strafsummen (bis zu 300.000€) sowie Abmahnkanzleien, die diese Abmahnungen zum Geschäftskonzept erhoben haben oder ähnliches.

Tools

Weiterhin gibt es Tools, die in der Lage sind Werbung und Datenübermittlung effektiv zu verhindern. Das mir bekannteste Tool ist das kostenpflichtige ADGUARD. Eine lebenslange Lizenz für 3 Geräte kostet zwar etwa 75,-€ (2022), das Tool blockt aber effektiv Werbung, selbst auf sozialen Medien, weil es systemweit (also nicht nur in einem Browser sondern im Betriebssystem) installiert werden kann. Dazu gibt es die Möglichkeit die Filterung kurzzeitig zu unterbrechen, da ja manchmal auch nützliche Einblendungen geblockt werden. Es kann nämlich sämtliche auf Drittseiten verweisende Links und somit auch den Datenverkehr blockieren. So wird z.B. das Anzeigen des  Facebook-Applets auf der Startseite blockiert, was in einem InlineFrame die Facebookseite WanderreiterWeb in Echtzeit darstellt, aber eben auch Informationen über dein Bewegungsprofil an Facebook übermittelt.

Sicherheit

SSL-Zugriff über "https://": Die Domain ist jetzt konsequent auf HTTPS umgestellt. Jeglicher Zugriff auf "WanderreiterWeb.de" erfolgt nur noch SSL-verschlüsselt. Nun ergaben sich bei etlichen externen Links Zugriffsfehler auf nicht verschlüsselte "http://"-Seiten die ich einfach umgangen habe. Und zwar über Kurzlinks der Domain "t1p.de". Diese überwacht die Zielseiten auch ohne, dass diese SSL-verschlüsselt aufgerufen werden auf Schadfaktoren und der erzeugte Kurzlink kann mit "https://" aufgerufen werden! Leider kann man jetzt den Link nicht mehr identifizieren denn er lautet in der Satusleiste des Browsers z.B.:" Bernina-Trail, er erscheint also als "https://t1p.de/zkug". Wer sich nicht sicher ist wohin der Link führt kann diesen testen. Mit der Eingabe von "https://t1p.de/zkug+" (+ am Ende), erscheint eine Erklärung wohin der Link tatsächlich führt!

Das ist ein wenig unschön, liegt aber daran, dass ganz viele Betreiber von "kleineren" Webseiten ihre Domains nicht vernünftig warten. Dazu müssen z.B. beim Provider neben der http://Domain.de auch die http://www.Domain.de in den DNS-Einstellungen eingetragen werden und es muss eine zwingende Umleitung des Seitenaufrufes vorgenommen werden.

Servertechnik

Automatische Umleitung der Websiteaufrufe

Es ist z.B. leicht möglich die Aufrufe der Domain auf nur eine Version zu beschränken und das sollte aus mehreren Gründen auch immer vorgenommen werden. Nicht

1. "http://www.domain.de"
2. "http://domain.de"
3. "https://www.domain.de" und
4."https://domain.de" (also 4 Versionen der gleichen Domain)

sondern eben nur eine dieser 4 Versionen. Diese 4 Versionen können von den Suchbots, die die Internet-Domains permanent durchsuchen, als Duplikate erkannt werden und Duplikate verschlechtern das Ranking der Domain, welches zwangsläufig seine Position in den Suchergebnissen nach hinten schieben würde. Außerdem wird die Trefferhäufigkeit für jede Version einzeln gezählt, die Website dadurch unscheinbarer erscheinen als sie tatsächlich ist.

Ein einfacher Eintrag in einer Textdatei im Root-Verzeichnis der Domain leitet dann alle Anfragen automatisch auf diese eine Version um. Die Datei heißt ".htaccess" und der Eintrag in dieser Textdatei, um nur noch "https://domain.de" zuzulassen lautet folgendermaßen.

Gibt es für die Internetdomain einen SSL-Zugang über https://:

Jede Tabellenzelle (linke Spalte) ist dabei in einer Zeile zu schreiben.

RewriteEngine on
startet das "Rewrite"
RewriteCond %{HTTP_HOST} ^www\.(.*)$ [NC] entfernt das www aus dem Seitenaufruf  und erzwingt https ohne www
RewriteRule ^(.*)$ https://%1/$1 [R=301,L]
RewriteCond %{HTTPS} !on erzwingt sicheren SSL-Aufruf
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]

Natürlich ist die Verknüpfung eines SSL-Zertifikates, welches vom Provider gestellt werden muss, Voraussetzung für diese Umleitung.

Ist kein SSL-Zertifikat vorhanden, könnte die Umleitung auf "http://www.domain.de" folgendermaßen aussehen:
Durch diese Zeilen (linke Spalte) würden Aufrufe von "https://domain.de" auf "http://www.domain.de" umgeleitet werden ohne einen Fehlercode zurückzugeben.

RewriteEngine On muss nur einmal in der .htaccess angegeben werden
RewriteCond %{HTTP_HOST} ^domain.de erzwingt Aufruf über http://www... 
RewriteRule (.*) http://www.
domain.de
/$1 [R=301,L]

(domain.de ist natürlich mit dem eigenen Domainnamen zu ersetzen. Die Option "R=301" erzeugt eine permanente Umleitung, so dass auch die Suchfunktionen von Google oder anderen Bots diese dauerhaft notieren und es keine scheinbaren Duplikatseiten gibt, die das Ranking der Domain in der Suche verschlechtern würden.)  In CMS-Seiten (Wordpress, Joomla u.a.) kann oftmals nicht auf die Datei ".htaccess" zugegriffen werden. Diese Systeme beherrschen jedoch andere Umstellungsmöglichkeiten über das Einstellungen-Menu. Diese Umleitung auf nur eine Version der Domain erzeugen automatisch eine Häufung der Zugriffe auf deine Domain, verbessern damit das Ranking.

Ich arbeite von Zeit zu Zeit weiterhin an der Umprogrammierung "alter" und "neuer" Seiten und der Implementierung moderner features um eine angenehme Nutzung zu ermöglichen. Technik ist für mich hochinteressant und mir fallen immer wieder Prozesse ein, die eine Änderung ohne viel Handarbeit ermöglichen - manchmal, nicht immer geht dies.