Heute aber habe ich, nachdem ich einen längeren Zeitraum lediglich marginale und gelegentliche Änderungen am Theme-Layout vorgenommen habe, diese Sache in Angriff genommen und meine Seitenleiste sozusagen ›widgetisiert‹. Ich hatte einfach Lust dazu, und warum sollte ich nicht mein betagtes Theme auf diese Weise zumindest im Unterbau etwas modernisieren?

Tatsächlich im Unterbau, denn an der Oberfläche sieht man natürlich überhaupt keinen Unterschied zum vorigen statischen Zustand. Der Effekt der Widgets besteht ja darin, Kerndateien des Themes von statischem Inhalt zu befreien zugunsten von Inhalts-Komponenten, die nach Bedarf einfach über das Adminpanel eingebunden (oder abgeschaltet) werden können.

Hierzu verlagert man die entsprechenden Code-Bestandteile als Widget-Blöcke in eine Theme-eigene functions.php und bindet in die sidebar.php statt derer den Aufruf-Code der Widget-Maschinerie ein.

Dadurch erhält man neben den mit WordPress mitgelieferten Widgets über das Adminpanel auch Zugriff auf die eigenen Komponenten und kann diese schließlich einfach per Drag&Drop in den entsprechenden Bereich der Seitenleiste befördern. Oder man kann auf Wunsch schnell einmal die Reihenfolge der Seitenleisten-Bestandteile ändern und und und …

Das ist mir ein Update der Theme-Versionsnummer wert: auf 2.03

Und jetzt schaue ich mal, ob ich eine kleine, reduzierte Tag-Wolke in die Seitenleiste einbaue, da eine solche als Standard-Widget mitgeliefert wird. Die große Tag-Wolke gibt es ja schon.

© Boris Stumpf - dyingeyes weblog 2004ff
Dieser Feed ist nur für die persönliche, nicht gewerbliche Nutzung bestimmt. Die Verwendung dieses Feeds auf kommerziellen Webseiten und/oder ohne Quellenangabe verstößt gegen die Lizenzbedingungen der Creative Commons License.
(Digitaler Fingerabdruck: 60c77d9e74d57f2299f42475f0e24778)

Tipps and Tricks and Rock and Roll …

© Boris Stumpf - dyingeyes weblog 2004ff
Dieser Feed ist nur für die persönliche, nicht gewerbliche Nutzung bestimmt. Die Verwendung dieses Feeds auf kommerziellen Webseiten und/oder ohne Quellenangabe verstößt gegen die Lizenzbedingungen der Creative Commons License.
(Digitaler Fingerabdruck: 60c77d9e74d57f2299f42475f0e24778)

Der Mietserver war die paar Jahre lang schon schön, zuletzt aber auch alt, schwerfällig und der Anbieter nicht bereit, mal ein Hardware­upgrade zu gepflegten Konditionen anzubieten. Und für die Zwecke, für die ein Freund und ich ihn gemeinsam betrieben haben, war er letzten Endes einfach zu teuer. Im Grunde überflüssiger Luxus.

Im Laufe der nächsten Tage werde ich also meine Domains umziehen und die Daten­pakete meiner beiden Blögchen dazu. Aber auch in diesem Punkt werde ich ein paar Anpassungen an meine heutigen Ansprüche vornehmen:

Beim Fotoblog augenstille.de wird alles bleiben wie gehabt, es gibt lediglich den Umzug der WordPress-Installation auf den neuen Datenplatz. Ich hoffe, der Daten­bank­aufbau dort gelingt problemlos.

Für dieses Blögchen hier gilt – vorerst – dasselbe. Ich überlege aber, es anschließend, nach einer gewissen Vorlaufzeit, umzulegen auf meine persönliche Domain borisstumpf.de, die zur Zeit lediglich als Verteiler zu meinen Websites und als private E-Mail-Domain dient. Das Blögchen läuft ja seit geraumer Zeit schon design- bzw. theme­mäßig eher unter meinem Namen und führt das ›dyingeyes weblog‹ nur noch im Untertitel.

Meine älteste Website xpw18.de mit Webdesign-Tutorials (die z.T. nicht mehr ganz up-to-date sind) wird samt Domain verschwinden und gelöscht; die Tutorials, die noch einiger­maßen zeitgemäß sind, hoffe ich im Laufe der Zeit als statische Seiten in diesem dyingeyes-Blögchen unterzubringen.

Langfristig will ich also meine Webaktivitäten unter zwei Domains konzentrieren: borisstumpf.de für das normale Blog einschließlich aller statischen Web-Aktivitäten, augenstille.de als Fotoblog. Dadurch werde ich auch mehr Übersicht­lichkeit bei meinem ganzen Wust an E-Mailadressen erzielen.

Wenn der Umzug richtig losgeht, sage ich das noch kurz an dieser Stelle an …

Sooo, hatte ich sonst noch Vorsätze für’s neue Jahr?

Kommentare von:

• Jared am 28.12.2008
• Boris (Autor) am 28.12.2008
• Alle Blögge sind schon da … » dyingeyes weblog am 30.12.2008

© Boris Stumpf - dyingeyes weblog 2004ff
Dieser Feed ist nur für die persönliche, nicht gewerbliche Nutzung bestimmt. Die Verwendung dieses Feeds auf kommerziellen Webseiten und/oder ohne Quellenangabe verstößt gegen die Lizenzbedingungen der Creative Commons License.
(Digitaler Fingerabdruck: 60c77d9e74d57f2299f42475f0e24778)

Wie dem auch immer sei. So lange die Software nicht für Linux (aus­schließ­lich nativ bitte, nicht als Wine-Konstrukt) erhältlich ist, ist sie für mich im Grunde ohne Interesse, was eine Nutzung angeht. In Sachen standard­konformer Darstellung von Webinhalten (HTML/CSS) halte ich mich an dieser Stelle auch deswegen vornehm zurück und überlasse es eifrigeren Webkrauts-Kollegen, sich hierzu zu äußern. Nach meinen Informationen soll das in Kürze passieren. Bitte dort gelegentlich reinschauen.

Was habe ich alles über den neuen Browser gehört? Ein paar wenige Links zum Stöbern seien herausgegriffen:

Ziemlich schnell soll er sein. Oder auch nicht.

Ein ganz schlichtes GUI soll er haben. Was man auch durchaus als hässlich bezeichnen könnte.

Und dann nochmals die Sache mit dem Datenschutz und den Nutzungsbedingungen.

Wie dem auch immer sein. (Ich wiederhole mich)

Kurztest des Ressourcenverbrauchs

Ich habe den Browser heruntergeladen, unter Windows XP installiert und mich eine kleine, kontrollierte Surfrunde lang mit der Entwicklung des Ressourcen­verbrauchs und der Performance beschäftigt. Meine Erkenntnisse:

Festplatten-Verbrauch

Installiert belegt Google Chrome (1) vom Fleck weg ca. 46 MB. Nach der ersten Surfsitzung hat er sich noch 2,2 MB Updatedaten geholt. Firefox 3 begnügt sich installiert auf meinem System mit 19,5 MB.

Das Profil-/Userverzeichnis schlägt nach dieser ersten Surfsitzung mit rund 23 MB (Cache abgezogen) zu Buche. Mein Firefox-Profil ist inzwischen zahlreiche Monate alt und eine nahtlose Fortsetzung des alten Profils meines Firefox 2 samt einer ansehn­lichen Reihe von Plugins. Insofern ist der Vergleich zu dessen rund 45 MB vielleicht nicht ganz astrein.

Zusammenfassend: Beide Browser nehmen sich nicht viel, was den frequentierten Festplattenplatz angeht.

(1) Google Chrome installiert sich in:
C:\Dokumente und Einstellungen\[username]\Lokale Einstellungen\Anwendungsdaten\Google\Chrome

Laufender Speicherverbrauch

Firefox 3 und Google Chrome standen neben­einander auf dem Bildschirm. Ich rief die verschiedenen Webseiten jeweils auf dieselbe Weise auf. Die Prüfung der Speicher­entwicklung unternahm ich schrittweise mit Hilfe des Windows-Prozess­monitors (im Taskmanager).

Ich öffnete thematisch zusammen­hängende Seiten aus verschiedenen Quellen und solche Seiten, die demselben inhaltlichen Gebiet zugehörten, manuell oder per Klick auf Links in neuen Tabs. Seiten innerhalb derselben Domain surfte ich im selben Tab an. So hatte ich im Verlauf meines Kurztests von rund dreißig Minuten bis zu fünf Tabs geöffnet, wobei ich gelegentlich einzelne Tabs schloss und neue öffnete. Insgesamt entstand auf diese Weise eine Surf­geschichte von etwa drei bis sieben aufgerufenen Seiten pro Tab einschließlich der Betrachtung eines Videostreams.

Google Chrome beginnt beim Programmstart und einer Leerlaufzeit von rund einer Minute mit 33 MB Arbeits­speicher­belegung. Firefox startet deutlich langsamer und breitet sich anfangs mit knapp 50 MB im Speicher aus.

In der Folge vergrößert sich die Speicherbelegung des Firefox kontinuierlich bis auf einen Wert von ca. 80 MB bei vier bis fünf geöffneten Tabs einschließlich einiger durchgeführter Seitenwechsel. Zu diesem Zeitpunkt hat Chrome den Rückstand aufgeholt und überholt sogar leicht mit ca. 90 MB belegtem Speicher.

Behält man dieses Surfverhalten bei – vier bis fünf Tabs und gelegentliche Seiten­wechsel darin –, so flacht die Kurve der Speicher­zunahme des Firefox langsam ab, er pendelt sich auf meinem System länger­fristig bei knapp oberhalb 90 MB ein.

Aus meiner Erfahrung unter Linux, aber inzwischen auch unter Windows XP, kann ich hierzu ergänzend Folgendes sagen: Bei zunehmend längerer Surfzeit und häufiger Tab-Bewegung – häufiges Schließen und Öffnen von Tabs und gelegentlich bis zu zehn, zwölf gleichzeitig offener Tabs – genehmigt sich Firefox 3 maximal etwa 130 bis 140 MB Arbeits­speicher, die er zuverlässig nicht überschreitet. Nach Reduktion offener Tabs auf zwei bis drei reagiert Firefox etwas zeitversetzt mit einem Rückgang der Speicher­belegung auf o.a. rund 90 MB.

Google Chrome reagiert offenkundig stärker und unmittel­barer auf die Anzahl der geöffneten Tabs, was auf den Umstand zurück­zuführen sein dürfte, dass er jeden Tab in einem eigen­ständigen Prozess laufen lässt. In wie weit diese Prozess­trennung tatsächlich zur aus­drücklichen Unab­hängigkeit der Tabs voneinander (Abstürze!) führt und keine zentrale Software­instanz involviert ist, kann ich nicht sagen.

Mein Fazit zum laufenden Speicher­verbrauch lautet auch hier: Beide Browser nehmen und geben sich nicht wirklich viel. Sie verhalten sich lediglich etwas unterschiedlich. Speicher­belegungen von rund 80 MB bis 140 MB halte ich bei Systemen mit einem Gigabyte Arbeits­speicher oder mehr für nicht weiter problematisch.

Performance-Eindrücke

Meine Ermittlungen betrafen besonders den Ressourcen­verbrauch, so dass ich lediglich einen groben Eindruck der Arbeits­geschwindigkeit über die vergleichende Surfsitzung schildern kann:

Beide Browser erscheinen mir praktisch unterschiedslos schnell im Aufbau von Webseiten. Es mag sein, dass Unterschiede zugunsten von Google Chrome messbar sind, aber diese scheinen mir so gering zu sein, dass sie im täglichen Gebrauch keine Rolle spielen sollten. Das Verhalten beim Seitenaufbau erscheint mir übrigens gleich, denn beide berechnen offenbar Seiten größten­teils im Hintergrund und bringen das Ergebnis dann quasi schlag­artig auf den Bildschirm, was vor allem im Vergleich zum eher kontinuierlichen Rendering früherer Firefox-Versionen den Eindruck höherer Performance hervorruft. Die Seitenaufbau-Geschwindigkeit des Opera erreichen beide Kontrahenten ganz klar nicht.

Zur Performance bei hochgradig Javascript-gestützten Seiten und damit der eingebauten neuen Javascript-Engine kann ich an dieser Stelle nichts sagen.

Was bleibt?

Ein neuer Browser, der nach meinen geschilderten Ermittlungen absolut in keinem bedeutenden Umfang gegenüber Firefox 3 punkten kann. Die Optik der Software mag einerseits Geschmacks­sache sein, andererseits kritisiere ich nach wie vor Software, die Standard­komponenten des System-GUIs ignoriert. Google Chrome hat keine Menüleiste, die wenigen Menüpunkte verbergen sich in einem Button am rechten Rand der Symbol­leiste. Der obere Fenster­rand beherbergt bloß die Tab-Reiter und die Funktionalität der (nicht klar differenzierten) Windows-Titelleiste. Das Ganze scheint mir wie das nur halbwegs gelungene Ergebnis des Versuchs, Windows-Systemoptik mit MacOS-Visualität zu kombinieren.

Das Fehlen jeglicher Steuerung von Skript-Funktionalität auf Webseiten und das bestenfalls rudimentäre Cookie-Management sind für mich absolute Ausschluss­kriterien für die Nutzung von Web­browsern. Dies und die möglicher­weise gegebene Daten­schutz­problematik, die ich zur Zeit mangels eigener Beschäftigung damit nicht weiter kommentieren kann, bedeuten mir, dass ich diesen Browser nicht verwenden und auch – bei Nachfrage – anderen Nutzern eindeutig nicht zu einer Nutzung raten werde.

Dies ganz abseits des Umstands, ob und wann Google eine bisher fehlende Plugin-Schnittstelle nachrüsten sowie eine native Version für Linux ausliefern wird.

Abschließend nochmal der Hinweis:

Möglicherweise wird in nicht allzu ferner Zeit ein Artikel bei den Webkrauts zu Fragen rund um die Standard-Konformität und andere für Webworker wichtige Aspekte für des neuen Browsers erscheinen. Die Diskussion hierzu ist im Gange. Einige Krauts haben sich jedoch unabhängig davon inzwischen in ihren Blogs geäußert.

Kommentare von:

• banane am 6.9.2008
• bembelkandidat am 9.9.2008
• Boris (Autor) am 9.9.2008
• Peter Schmidt am 11.10.2008
• Boris (Autor) am 11.10.2008

© Boris Stumpf - dyingeyes weblog 2004ff
Dieser Feed ist nur für die persönliche, nicht gewerbliche Nutzung bestimmt. Die Verwendung dieses Feeds auf kommerziellen Webseiten und/oder ohne Quellenangabe verstößt gegen die Lizenzbedingungen der Creative Commons License.
(Digitaler Fingerabdruck: 60c77d9e74d57f2299f42475f0e24778)

Webautoren und -designer, die auf Barrierearmut (Barrierefreiheit) und gegebenen­falls auch Rechts­sicherheit vor unliebsamen Abmahnungen achten wollen, haben das Problem, dass es gar nicht so einfach ist, eine E-Mailadresse vor dem Auslesen durch einen E-Mail-Harvester (Skript­software, die automatisiert Adressen auf Webseiten aufstöbert und zu Spam­zwecken abgrast) zu schützen.

Lösungen, die Adresse mit Unterstützung von Javascript (clientseitig) anzeigen zu lassen und ansonsten zu verbergen, sind zum einen nicht barrierearm und könnten scharf schießende Zeit­genossen abmahnend auftreten lassen mit dem Argument, dass sie mit ihrem Browser leider keine E-Mailadresse finden konnten – was aber ohne zusätzliche Hilfs­techno­logien (wie Javascript) möglich sein muss. Ich glaube mich zu erinnern, dass es (leider) sogar ein einschlägiges Gerichts­urteil hierzu gibt.

Versuche, die Adresse mit Hilfe von CSS-Formatierung mit oder ohne hierzu »störend« eingeschobenen HTML-Passagen zeitigt mindestens das Problem der fehlenden Barriere­armut: Was zeigt in diesem Fall ein Browser an, der nicht via media=all bzw. media=screen Webseiten darstellt, z.B. ein akustischer Screenreader?

Serverseitige Problemlösung

Ich bin seit einiger Zeit am Nachdenken, ob es nicht möglich ist, eine server­seitig generierte Lösung auf Basis von PHP auszutüfteln, die einem Harvester-Skript verborgen oder unzu­gänglich bleibt, einem menschlichen Leser aber die E-Mailadresse ohne größere Hürden bei vertretbarer Eigen­aktivität zugänglich macht.

Meine Versuche einer PHP-Lösung mit Hilfe eines skript­gesteuerten automatischen Reloads über URL-Weiterleitung plus über­gebenem Parameter sind vorerst gescheitert und ich bin nicht mehr sicher, ob das überhaupt geht. (Deswegen lasse ich mich darüber an dieser Stelle darüber auch nicht weiter aus …)

Ähnlich einem Rechen-Captcha?

Viele Blogger blockieren Kommentarspam mit Hilfe sogenannter Rechen-Captchas: Der Besucher wird aufgefordert, das Ergebnis einer einfachen Rechen­aufgabe in ein Feld einzugeben, worauf erst der Kommentar abgeschickt wird.

Meine Idee ist nun die Folgende:

Beim Aufruf der Kontaktseite erscheint die Postadresse, die E-Mailadresse aber bleibt verborgen. An ihrer Stelle steht eine Aufforderung, eine kurze Zeichen­kette in ein Feld einzugeben und einen Submit-Knopf zu drücken, worauf die Seite neu geladen und diesmal die E-Mailadresse (an Stelle der Aufforderung) angezeigt wird. Es wird also einfach per Formular-Übermittlung eine Variable ($_POST['Variablen-ID']) mit bestimmtem Wert übermittelt und vom Skript entsprechend verarbeitet.

Meine Hintergrundüberlegung dazu ist, dass ein Harvester-Skript nicht in der Lage sein dürfte, zu erkennen, welche Bedeutung eine Formular­komponente auf einer solchen Seite hat. Harvester scannen HTML-Code nach unver­schleierten E-Mailadressen, manche mögen hierzu ›intelligent‹ genug sein, auch Verschleierungen per CSS und Zeichen-Umkodierung zu durchschauen. (Siehe dazu auch den o.a. Dr. Web-Artikel).

Der menschliche Faktor

Darüber hinaus kann man den erläuternden Text für den menschlichen Leser so informell und gleichzeitig verständlich halten, dass auch dieser für ein auswertendes Skript keine verwertbaren, auffälligen Ansätze bietet:

Geben Sie zur Anzeige der E-Mailadresse die Summe aus 2 und 5 in das folgende Feld [Inputfeld] ein und drücken Sie danach [diesen Knopf]

Diese Lösung sollte in dem Sinne barrierearm und rechtssicher sein, dass sie weitest­gehend unabhängig (?) von der darstellenden Software ist und dem Besucher keine schwierig zu überwindende Hürde in den Weg stellt.

Zur Demonstration

Um das Ganze verständlicher zu machen, biete ich allen interessierten Lesern an, sich als Demo eine beispielhafte Ausführung dieser Idee anzu­schauen und zu testen. Dafür muss der interessierte Leser lediglich den Begriff schutz als Usernamen und no_spam als Passwort eingeben, um diese Demo zu erreichen. (Zur Sicherheit, dass mir keine marodierenden Bots auf dieser Demo herumtrampeln.)

Was meint ihr zu dieser Idee?
Ist sie aus der Sicht der Barrierearmut vertretbar?
Denkt ihr, dass sie im Zweifelsfall auch rechtlich vertretbar ist?

Kommentare von:

• Ute am 5.8.2008
• fwolf am 5.8.2008
• alp am 17.8.2008
• Boris (Autor) am 17.8.2008

© Boris Stumpf - dyingeyes weblog 2004ff
Dieser Feed ist nur für die persönliche, nicht gewerbliche Nutzung bestimmt. Die Verwendung dieses Feeds auf kommerziellen Webseiten und/oder ohne Quellenangabe verstößt gegen die Lizenzbedingungen der Creative Commons License.
(Digitaler Fingerabdruck: 60c77d9e74d57f2299f42475f0e24778)

Das wäre nicht nur zeitgemäß, sondern auch nützlich, denn man könnte auf diese Weise Veranstaltungstermine völlig unkompliziert in seinen (geeigneten) Terminplaner übernehmen.

Ein kurzer Blick vor meine Haustüre zeigte mir, dass auch das Frankfurter Webangebot in dieser Sache nichts zu bieten hat.

Es mag also tatsächlich so sein, dass derartig große Webangebote, mit derartig großen CMS von derartig großen Agenturen produziert, noch am Beginn des gewaltigen Sprunges von Broschüren-Holz zu WorldWideWeb sind und wir Nutzer da einfach geduldig sein müssen. Mit Inline-Links zu Fremd-Quellen in Informationstexten innerhalb dieser Webangebote hat man ja auch noch so seine Schwierigkeiten. Man kennt das übrigens auch von großen Zeitungen und Wochenmagazinen, die sich gerade vorsichtig im Web versuchen. Aber ich schweife ab …

Firefox, Operator und Mikroformate

Nils erwähnt die Firefox-Erweiterung »Operator«, die auf Webseiten oberflächlich verborgene mikroformatierte Daten ausfindig und bequem zugänglich macht. Das kann über eine zusätzliche Symbolleiste und/oder Hinweissymbole in der Firefox-Adresszeile bzw. der Statuszeile geschehen.

Nach der Installation der Erweiterung stellte ich sogleich höchst erfreut fest, dass sie auch vergebene Kategorien und Tags erkennt und hierzu jeweils weiterführende Links (zu Technorati, Amazon, Flickr, Upcoming, YouTube u.a.m.) anbietet. Ich kann aber im Moment noch nicht sagen, ob sich dieser Erkennungsvorgang auf WordPress-Blogs und womöglich das Plugin »Simple Tags« beschränkt, weil die Elemente dadurch entsprechend gekennzeichnet werden. Kurze Stichproben bei ein paar Nicht-Wordpress-Blogs zeigten jedenfalls, dass deren Kategorien und Tags nicht erkannt werden.

Hier sollte ich also noch etwas weiter forschen. Weitere Erkenntnisse teile ich bei Gelegenheit an dieser Stelle mit …

Update um 20:40 Uhr:

Das Mitteilen weiterer Erkenntnisse kann ich mir sparen, denn meine schlauen Leser wussten es schneller und besser als ich und ergänzten meine Ausführungen mit ihren Kommentaren …

Kommentare von:

• Eric Eggert am 4.8.2008
• Frank am 4.8.2008
• Sascha am 4.8.2008
• Nils am 4.8.2008
• Eric Eggert am 4.8.2008
• Boris (Autor) am 4.8.2008

© Boris Stumpf - dyingeyes weblog 2004ff
Dieser Feed ist nur für die persönliche, nicht gewerbliche Nutzung bestimmt. Die Verwendung dieses Feeds auf kommerziellen Webseiten und/oder ohne Quellenangabe verstößt gegen die Lizenzbedingungen der Creative Commons License.
(Digitaler Fingerabdruck: 60c77d9e74d57f2299f42475f0e24778)

In genau diesem Sinne folgen ab sofort in einer Webkrauts-Sommer­aktion viele gute Beispiele – Sonnenseiten!

Nicolai Schwarz beginnt mit der Begrüßung …

© Boris Stumpf - dyingeyes weblog 2004ff
Dieser Feed ist nur für die persönliche, nicht gewerbliche Nutzung bestimmt. Die Verwendung dieses Feeds auf kommerziellen Webseiten und/oder ohne Quellenangabe verstößt gegen die Lizenzbedingungen der Creative Commons License.
(Digitaler Fingerabdruck: 60c77d9e74d57f2299f42475f0e24778)