spackblog

Ich bin begeisterter Qype-Nutzer und schätze Qype als fundierten Ratgeber für Lokalitäten und Einkaufsmöglichkeiten. In letzter Zeit ärgere ich mich aber immer wieder und zunehmend über Abstriche und schlechte Entwicklungen, die ich nun mal gebündelt niederschreiben möchte.

Punkt 1 und ganz wichtig: Die Suche bei Qype ist und war schon immer ein schlechter Witze. Wenn man einen Laden sucht, dessen Namen man nicht genau im Kopf hat, ist man total aufgeschmissen, weil die Suche schon bei kleinsten Abweichungen in der Schreibweise scheitert. Immerhin wird einem dann eine Google-Suche als Alternative geboten, die auch vorher schon die bessere Alternative für das Auffinden von Läden bei Qype war. Eine Autovervollständigung würde das Problem immerhin teilweise beheben, aber langsfristig muss eine unscharfe Suche her.

Bis zuletzt habe ich Läden, die ich ums Verrecken nicht über die Suche gefunden habe, immer über die allgemeine Kartenansicht der Stadt gesucht und so zuverlässig finden können. Dieser Workaround ist aus unerfindlichen Gründen nicht mehr auffindbar. Was soll das Qype? Wo ist die allgemeine Kartenansicht über alle Kategorien hin? Dienste wie MapTheQ sind zwar cool und hübsch, aber hier fehlen etliche Locations aus für mich nicht ersichtlichen Gründen. Ein hier naheliegendes Beispiel ist der fehlende REWE hier um die Ecke in dieser Kartenansicht. Zudem ist es schon irgendwie seltsam, dass man Qype verlassen muss, um eine gute allgemeine Kartenansicht zu bekommen.

Ein weiteres Problem in der Nähe der Suche und Positionierung sind die völlig falschen Stadtteilgrenzen. Zumindest in Düsseldorf stimmen die Stadtteilgrenzen vorne und hinten nicht, so dass ich mich hier mit allen Läden um mich herum laut Qype in Stadtmitte befinde und Flingern-Nord erst östlich der Dorotheenstraße anfängt (also an der PLZ-Grenze 40233/40235). Eller und Lierenfeld stimmen auch ganz und gar nicht. Diesen Fehler habe ich bereits mehrmals im letzten Jahr gemeldet, eine Antwort bekam ich nie und behoben wurde das auch nicht. Auch hier: Was soll das Qype? Die Statteile hatten ursprünglich ja mal gestimmt.

Die kaputten Stadtteilgrenzen sind deswegen besonders ärgerlich, weil Qype einem seit einiger Zeit ständig und überall die Stadtteile statt der Städte aufdrängelt. Beispielsweise kommt man im Breadcrumb innerhalb einer Kategorie nicht mehr zurück zur ganzen Stadt. Ist man also in Shopping->Mode in Flingern-Nord und möchte andere Modegeschäfte in Düsseldorf suchen, kann man nicht einfach im Breadcrumb klicken, weil man da nur zu Düsseldorf ohne Kategorie oder eben zur Kategorie Mode in Flingern-Nord gelangt. Will man Mode in ganz Düsseldorf shoppen, muss man zurück zur Stadt und sich wieder zur Kategorie durchklicken. Ohne die Stadtteilebene war das alles kein Problem. In Berlin mag das mit den Stadtteilen essentiell sein, aber in den meisten anderen Städten ist das eher lästig. Eine Entfernungssuche wäre die klar bessere Alternative.

Kein echtes Problem, aber schon oft zu Recht bemängelt: Das "neue" Design in Türkis und rot ist nach wie vor zum kotzen abstoßend und das für Mitglieder wählbare Classic-Theme ist nichts Halbes und nichts Ganzes. OK, die neue Optik ist inzwischen durchaus rund optimiert, aber immer noch nicht mal im Ansatz so angenehm, wie das angenehme orange-grüne alte Design. Seit diesem Relaunch geht es in meinen Augen bei Qype nur noch bergab. Auch die Zahl der Beiträge pro Tag scheint seitdem zu stagnieren. Keine Ahnung, ob das stimmt, aber ich werde das Gefühl nicht los, dass Qype seitdem nur noch abbaut.

Wenig hilfreich ist da, dass man keine negativen Bewertungen mehr für Beiträge vergeben kann. Immer wieder begegne ich schlechten Beiträgen, ob zu kurz oder einfach total dämlich, ich möchte gerne schlechtes Feedback geben. Ich kenne genug gute Beispiele, wo doofe Beiträge, die mehrheitlich von anderen Nutzern abgelehnt werden, ausgeblendet werden oder sonstwie in den Hintergrund gedrückt werden. Das sehe ich als guten Anreiz, qualitativ hochwertige Beiträge zu schreiben, denn niemand mag gerne negativ bewertet werden. Ein "Weniger lesenswert" oder "Nicht hilfreich", wie es das früher bei Qype gab, ist in meinen Augen immens wichtig für die Qualitätskontrolle durch andere User. Die gelegentlich angesprochene Gefahr des Vergraulens von Neuusern sehe ich weniger, denn viele Experten sind sehr nachsichtig bei schlechten Beiträgen von Anfängern und geben gute und konstruktive Kritik. Nur loben zu können oder sonst schweigen zu müssen, entwertet das Lob in meinen Augen immens. Klar kann man auch Kommentare schreiben, aber wie alle wissen, wie schnell bei negativen Kommentaren ein Flamewar auflodert. Gut ist allerdings, dass man inzwischen sehen kann, wer einen Beitrag lesenswert fand, das ist schon ein Schritt in die richtige Richtung, um diese Lobfunktion wieder aufzuwerten. Immerhin.

Ein Ärgernis ist in meinen Augen die fehlende Möglichkeit, ältere Beiträge zu editieren, ohne dass der Beitrag nach oben geschoben wird. Ich gebe zu, dass es durchaus meine Eitelkeit ist, aber wenn ich einen frühen oder ersten Beitrag zu einem Platz geschrieben habe, empfinde ich diesbezüglich gelegentlich einen gewissen Stolz. Das führt dazu, dass ich solche Beiträge regelmäßig nicht mehr um neue Informationen ergänze, um die Position nicht zu verlieren. Zudem kenne ich das Hochschieben von Threads durch kleinere Änderungen als ein eher negativ besetztes Verhalten und würde das im Falle von Schreibfehlern schon aus diesem Grunde gerne vermeiden. So oder so: Man sollte wählen können, ob ein Beitrag bei einer Änderung ein neues Hauptdatum bekommt oder nur einen Editierzeitstempel. Ach ja, der Thread-Zusammenhang wird durch das ungefragte Umsortieren ebenfalls auseinander gerissen, konkret meine ich die durchaus übliche Bezugnahme auf die Vorredner.

Einige der hier beschriebenen Kritikpunkte finden sich auch im Qype-Feedback-Forum (nur für Insider und Experten sichtbar). Trotzdem wollte ich mal eine eigene kommentierte Sammlung von Kritikpunkten hier veröffentlichen. Ich hoffe, es ist kontruktiv genug formuliert, damit das auch ankommt. Wie ich Qype kenne, wird das sogar durchaus wahrgenommen. Das muss ich mal loben: Communitymanagement funktioniert bei Qype recht gut. Trotzdem habe ich das Gefühl, dass es seit Monaten keine echte Weiterentwicklung mehr gibt. Vielleicht gab es einen signifikanten Personalabbau in der Entwicklung? Man weiß es nicht.

Stagnation ist Tod, Qype ist immerhin nicht alleine am Markt.

Wer ernsthaft beruflich oder auf hohem Niveau in seiner Freizeit mit PHP arbeitet und älter als 15 ist, dem stehen wahrscheinlich beim Blick in den Quellcode von Wordpress die Haare zu Berge. Code is art ist ein wunderschöner Wordpress-Slogan, der in dem Kontext aber wirklich mehr als unangebracht ist. Schlimmer als der zusammengezimmerte Kern von Wordpress, der aktuell mal wieder mit einem notdürftigen Flicken gegen den grassierenden Wordpress-Wurm repariert wurde, sind aber die meisten PlugIns. Viele sind offenbar von blutigsten PHP-Anfängern schnell und ergebnisorientiert runterprogrammiert worden, was von Wordpress ja geradezu provoziert wird und was auch großen Anteil an der Beliebtheit des Systems trägt. Jeder ahnungslose Anwender kann mit ein paar Zeilen PHP-Code schnell das erreichen, was er gerade braucht. Das erinnert mich an meine Anfänge mit PHP im Jahr 2001 mit dem damals herausragenden phpBB 1.4. Hier war im Grunde alles hartkodiert und wenn einem irgendwas nicht gefiel, hackte man irgendwie im Quellcode herum. Ein Templatesystem wurde erst mit Version 2 eingeführt und auch hier hackte man noch alle möglichen MODs in das System, was ein Update praktisch unmöglich machte. Folge waren haarsträubende Sicherheitslücken, die nicht gestopft wurden. Wordpress vermeidet dieses Modding immerhin mit einem sehr flexiblen PlugIn-System, der Zugang für Dilettanten und Anfänger wurde dadurch aber noch einfacher. Das Ergebnis sehen wir zur Zeit, Gerrit van Aaken hat das schon zusammengefasst: Bei Wordpress hilft nur ein schmerzhafter Neuanfang, so wie TYPO3 das momentan auch vollzieht und wie phpBB das auch schon zwei mal hinter sich hat.

Nun will ich nicht so viel auf Wordpress rumhacken, wenn ich es selber gar nicht benutze. Im Grunde ist das System großartig, wenn man die miese Codebasis ignoriert. Ich will auf etwas ganz anderes hinaus, nämlich die Codequalität von Serendipity-PlugIns. Wann immer ich ein Seitenleisten-PlugIn installiert habe, musste ich dessen Code bearbeiten, weil die HTML-Ausgabe standardmäßig schlimm aussah oder gar fehlerhaft war. Das PlugIn-System von S9Y ist auf den ersten Blick recht kompliziert, was totale Dilettanten vom PlugIn schreiben abhält; das ist schon mal gut. Trotzdem ist die Codequalität der PlugIns oft eher mäßig. Fast überall wird zum Beispiel der HTML-Code mit echo direkt da ausgegeben, wo er anfällt, natürlich mit irgendwelchem HTML-Code drumherum, den der Autor gerade für angemessen hielt. Kein Wunder also, dass der Output nicht immer angemessen ausfällt. Ich habe vor einiger Zeit ein eigenes Seitenleisten-PlugIn für Twitter geschrieben, weil das alte u.a. genau dieses Problem zeigte. Ein Kernfeature meines PlugIns war der Einsatz einer Templating-Engine. Die zu implementieren war PHP-seitig ein Kinderspiel für jeden halbwegs erfahrenen PHP-Programmierer. Die Frage ist nun, warum zur Hölle von den paar offiziell verfügbaren PlugIns noch fast keines so ein Templating-System mitbringt? Es täte S9Y wirklich immens gut, wenn sich mal jemand hinsetzen würde und ein paar der PlugIns auf den aktuellen Stand bringen würde. Also zumindest eine Templating-Engine einbauen und die Ausgabe entsprechend anpassen, aber auch manch andere Routine könnte mal überarbeitet werden. Gegenüber Wordpress ist das Jammern auf hohem Niveau, aber auch S9Y ist merklich in die Jahre gekommen, vor allem seine PlugIns.

Wenn ich sowas lese, pflege ich zu antworten, derjenige soll nicht jammern, sondern selber anpacken. Das gilt auch für mich, sicher. Allerdings habe ich immens schlechte Erfahrungen mit meinem Twitter-PlugIn gemacht. Das einzige konstruktive Feedback kam vom unglaublich engagierten Chefprogrammierer selber, der mir meinen ursprünglich geplanten Arbeitsaufwand mit Änderungswünschen um das Mehrfache aufgeblasen hat. Am Ende war das neue PlugIn wirklich großartig geworden, ich bin richtig stolz darauf. Die ganzen angeforderten Änderungen kreisten alle um funktionale Anpassungen an das alte PlugIn, so dass mein neues PlugIn alle Funktionen des alten hatte, nur eben diesmal in gut. Dann kam das Problem: Es gab kein Feedback von Dritten und stattdessen hat mir ein ätzender Troll auch noch ans Bein gepisst und einen extra Thread im Forum aufgemacht, um mich als Schnösel zu dissen (weil ich PHP4 Nutzer, die PHP4 Kompatibilität einfordern, als Ewiggestrige bezeichnet habe und er sich davon angesprochen fühlte). Ich habe mein Engagement für S9Y daraufhin nach ein paar Tagen Diskussion eingestellt, denn für kostenlose und gute Programmierarbeit möchte ich echt alles andere haben als von irgendwelchen undankbaren Typen beschimpft zu werden. Mein PlugIn ist übrigens nie im Repository erschienen und stattdessen gibt es ein funktional wirklich krasses anderes PlugIn; hoffentlich ist wenigstens meine Arbeit da eingeflossen und war nicht völlig umsonst. Wie auch immer: Ich werde keine Arbeit mehr zu S9Y beitragen; wenn ich etwas neu baue, reiche ich das im Forum ein und wenn sich niemand drum kümmert, soll mir das egal sein.

Gelegentlich möchte ein CSS Dowpdown-Menü um eine kleine Animation erweitert werden, die bei der Gelegenheit auch den Suckerfish für den IE6 übernimmt. Natürlich macht man sowas mit jQuery, wenn man das sowieso eingebunden hat, in etwa so (natürlich alles innerhalb von $(document).ready()):

$('#mainMenu>li').hover(
  function(){
    $(this).find('>ul').slideDown(150);
  },
  function(){
    $(this).find('>ul').slideUp(50);
  }
);

Nun kommt es dabei immer wieder zu den selben Problemen:

Fährt man mit der Maus schnell mehrmals über einen Punkt, werden alle nötigen Animationen in eine Warteschlange gepackt und nach und nach gemütlich abgearbeitet. Das lässt sich noch leicht und logisch beheben, indem man jeweils mit einem stop() vor slideDown() und SlideUp() die Animation erst einmal stoppt, bevor man das Gegenstück ausführt. Das gleiche passiert auch bei animate() und vergleichbaren Sachen und lässt sich da auf die gleiche Weise beheben. Soweit kein Problem und nach ein paar Sekunden Google-Recherche gefunden.

Ein weiteres Problem ist das Handling der Animation bei der ersten Berührung mit der Maus: Scheinbar wird das jQuery hover Event erst bei der zweiten Berührung genutzt, bei der ersten klappt das Menü ganz normal mit der im CSS definierten Methode aus. Auch hier hilft eine Google-Recherche schnell weiter und bringt die Lösung frisch auf den Tisch: Vor der ersten Berührung (also zweckmäßiger Weise in $(document).ready()) müssen die UL-Elemente der Untermenüs mit einem beherzten Aufruf von hide() versteckt werden, auch wenn sie durch das CSS eigentlich schon versteckt sind. OK, das muss man wissen und kommt nicht von alleine drauf.

Perfide ist das dritte Problem bei Animationen mit den Ausmaßen der Untermenüs, also slideDown()/slideUp() und animate() in Kombination mit height() oder width(): Nutzt man diese innerhalb der hover() Funktion und verlässt das Element noch während die Animation läuft, speichert jQuery den zu diesem Zeitpunkt aktuellen Wert der animierten Abmessungen zwischen und animiert fortan nur noch bis zu diesem Maximalwert. Verlässt man den Menüpunkt also sofort wieder, wird das Menü bis zum Seitenreload nie wieder erscheinen, denn es ist ja nur noch etwa einen Pixel hoch und wird entsprechend auch nur bis zu einem Pixel animiert. Hier habe ich keine Lösung bei Google gefunden, weil ich nicht wusste, wonach ich suchen sollte. Also habe ich mich mit dem Firebug auf die Lauer gelegt und das Problem in der beschriebenen Form analysieren können. Ich weiß nicht, ob das ein Bug ist oder volle Absicht, aber ich kann mir nicht wirklich eine Situation vorstellen, wo dieses Verhalten gewünscht wäre. Die Lösung dafür liegt aber auf der Hand: Ein unscheinbares height('auto') vor der ausklappenden Animation behebt das Problem sehr zuverlässig.

So sieht nun also das komplette Menüscript aus, das sich endlich so verhält, wie man es auch erwartet:

$('#mainMenu>li>ul').hide(); // needed to prevent CSS-only behaviour on first contact
$('#mainMenu>li').hover(
  function() {
    $(this).find('>ul').stop().height('auto').slideDown(150); // the height('auto') prevents the menu from memorizing an incorrect height-value forever when leaving the menu while the animation is running
  },
  function() {
    $(this).find('>ul').stop().slideUp(50);
  }
);

An anderer Stelle half mir height('auto') aber nicht weiter, was also tun? Die Lösung lag zunächst auch hier auf der Hand: Beim Laden der Seite müssen die initialen Werte des Elements in einer Variablen gespeichert werden, zu denen die Animation dann jeweils zurückkehren kann. Das schien mir immens unelegant, weil ich nicht den globalen Scope mit solcherlei Variablen vollmüllen wollte. Mein Bruder brachte dann den entscheidenden Tipp: Man kann die Werte prima als Attribute des Elements im DOM ablegen. Beliebige Attribute sind in HTML zwar nicht erlaubt, aber wenn das Dokument erst mal ins DOM eingelesen wurde, sind die Limitierungen von HTML völlig gleichgültig. Kurz gesagt: Ist das Ding im DOM, ist es kein HTML mehr. Die Denke muss man sich erst mal klar machen. Gut, also schreibe ich die Werte in $(document).ready() fix als Attribute ins DOM und alles wird gut. Doch da hatte ich nicht mit der strengen, aber korrekten Auslegung des ready()-Events in Opera gerechnet: Dort stehen zu diesem Zeitpunkt die gewünschten Werte nicht zur Verfügung, weil es sofort gefeuert wird, sobald das DOM fertig eingelesen wurde, aber eben noch bevor die Engine irgendetwas rendern konnte. Abmessungen sind also nicht bekannt. Die Lösung lautet hier $(window).load(). Dieses Event wird gefeuert, sobald die Seite gerendert wurde, mithin also auch alle Abmessungen bereit stehen. So sind die Events spezifiziert, aber Opera scheint der einzige Browser zu sein, der sie auch so handhabt. Die komplette Lösung für dieses Problem lautet also in etwa so:

$(window).load(function(){
  $("#elementId").attr('origHeight', $("#elementId").height());
});

Ausgelesen wird auf die gleiche Weise, also $("#elementId").attr('origHeight').

Nachtrag 05.07.2010: Wo ich den alten Beitrag gerade noch mal lese, fällt mir auf, dass Doku lesen oft hilft. Der letzte Punkt wird natürlich viel eleganter gelöst, wenn man einfach die data()-Methode von jQuery benutzt. Also wie immer: Augen auf und Hirn an.

Ich habe heute den ganzen Tag Vista plus etliche Programme auf einem iMac 24" installiert. Entgegen landläufiger Meinungen hatte ich nur bei einem Programm Probleme, die auf Vista zurückzuführen waren. Oder anders herum: Vista entlarvt die miese Programmierung dieses Programms derart schonungslos, dass sein Entwickler (der inzwischen aufgegeben hat) zum Start von Vista einen Jammerbrief über dieses böse Vista an seine Kunden mit Wartungsauftrag geschickt hat. Dieses Gejammer ist unfassbar peinlich, weil das Programm seit etlichen Jahren schon nicht sauber funktioniert. Unter anderem arbeitet es schon immer ohne sinnvollen Grund nur mit Administratorrechten. Ich kenne den genauen Grund zwar nicht, aber das ist auch völlig egal, denn offensichtlich bestünde dieses Problem bei halbwegs sauberer Programmierung nicht. Aber das ist nicht der einzige Fehler. Das Programm ist ein Musterbeispiel, wie man etwas nicht machen sollte; ergonomisch und programmiertechnisch einfach nur katastrophal.

Ich hätte glatt Lust, mal einen Screencast zu machen, wo ich dieses Stück Software-Dreck en Detail zeige. Was mein Kunde mir über die Jahre schon an Geld bezahlt hat, damit ich die Probleme so gut es geht behebe, ist wirklich immens. Übrigens habe ich auch für die mehrfache Neuinstallation eines HP-Druckertreibers schon so viel Geld in Rechnung gestellt, dass man gleich zwei der problemlosen Brother Geräte hätte kaufen können, mit dem wir diesen HP OfficeJet dann endlich ersetzt haben. Was soll ich sagen: Inzwischen gibt es dort neben dem uralten HP LaserJet 4L nur noch drei Brother-Geräte und keins davon hat jemals für unnötigen Supportaufwand gesorgt. Ein Traum, kann ich nur sagen: Drucker ans Netz, CD rein, ein paar Minuten lang den Installationsassistent laufen lassen (der fragt, ob man nur Drucker- und Scannertreiber oder die ganze Software haben will), fertig. Sogar der "Scannen an" Knopf am Gerät funktioniert sofort wie er soll und im Gegensatz zur Höllen HP-Software sogar dauerhaft. Danach kann man die Geräte schlicht vergessen, so wie es sein soll. Den kleinen Monochrom-Laserdrucker habe ich tatsächlich seit seiner Installation vor einigen Jahren nur zum woanders hinstellen mal anfassen müssen. Ich frag schon gelegentlich nach, ob der überhaupt noch benutzt wird, weil ich nichts davon höre. Ja wird er, täglich.

Puh. Heute war ein problematischer Tag: Es fing schon doof an, weil mir der Alex dankenswerterweise Starthilfe geben musste, weil ich gestern das Licht in meinem Auto angelassen habe. Das Warnpiepsen hatte ich wohl ignoriert, ärgerlich. Dann habe ich eine Stunde an einer Telefonanlage gebastelt, weil DSL und Telefon nicht mehr liefen, nachdem ich gestern die Verkabelung angefasst hatte. Das Telefon lief schnell wieder: Eine Lötstelle war gebrochen, das hatte der Betroffene nach kurzer telefonischer Instruktion sogar selbst beheben können. Ich war beeindruckt. Aber das DSL lief trotzdem nicht, also Außeneinsatz. Auch direkt am Hausanschluss im Keller und mit getauschtem Kabel und anderem Modem gab es keine Synchronisation. Irgendwann hatte ich alle Variablen durchprobiert und rief bei der Telekom an. Ich rufe ja nicht mehr beim Provider an, bevor ich alle Variablen durchprobiert habe, siehe hier. Aha, OK, ich resette mal eben Ihren Port… geht es jetzt wieder? Ja, läuft; na toll, hätte ich da mal früher angerufen. Aber ich hatte an dem Kabel ja rumgefummelt gestern und sowieso ist die Konstruktion da reichlich fragil, weil historisch gewachsen: Analoganschluss durch zwei Adern eines mehradrigen Kabels in einen anderen Raum in die Fritzbox, von da ISDN zurück durch ein anderes vieladriges Kabel zur Telefonanlage, die neben dem Hausanschluss hängt. Alles nur, weil der Hausherr vor vielen Jahren eben (für seine Zeit vorausschauend) nur vieladrige geschirmte Drähte gezogen hat und keine Ethernet-Verkabelung, so dass die Fritzbox in das Zimmer mit den Computern muss.

Danach gerade noch rechtzeitig zu meiner zweiten Verabredung geschafft, schon wieder DSL. Dieses mal gründlich verzögerter Wechsel von 1&1 zur Telekom mit neuem Router. Ein Speedport W 502V. Schnell angeschlossen, Zugangsdaten rein, die alten WLAN-Parameter wieder eingestellt und ab dafür. Hab ich gedacht, denn auf zwei von vier Testrechnern war der Netzzugang unfassbar zögerlich. Egal ob WLAN oder Kabel, egal ob Internet oder die Konfigurationsseite vom Router, Seitenaufrufe zögerten alle erst mal etliche Sekunden, bevor dann alles sofort da war. Keine Personal Firewall, nix. Was, außer einem Haufen Software ist auf diesen beiden Notebooks anders? Was ist ungewöhnlich? Zwei Stunden später bin dann ich auf des Rätsels Lösung gekommen: Auf beiden Rechnern war Microsoft IPv6 für Windows XP installiert. Ich weiß nicht wieso, aber es war da. Schnell mal deaktiviert und siehe da: Es fluppte wieder einwandfrei.

Mein technischer Erklärungsansatz: Der alte Router hatte mit IPv6 nichts am Hut, der neue schon und so verteilte er per DHCP auch fröhlich IPv6-Adressen und DNS-Einstellungen. An sich vorbildlich und fortschrittlich. Nur leider hat das wohl dazu geführt, dass die Browser jede DNS-Anfrage erst mal via IPv6 gestellt und erst nach einem Timeout auf IPv4 zurückgeschaltet haben. Eine recht plausible Erklärung in meinen Augen, oder bietet jemand einen besseren Ansatz?

So oder so, ich weiß schon, warum ich solche Sachen eigentlich nicht mehr anbiete und mich auf Web-Projektgeschäft und -Beratung konzentriere. Klar kitzelt es mich noch immer sehr, solche Probleme zu lösen, aber ich muss Geld verdienen. Und niemand bezahlt nach meiner Erfahrung gerne dreistellige Beträge für ein paar Stunden Knobelarbeit an kleinen Detailproblemen. Mein krassester Fall war mal ein nicht mehr startender Rechner, bei dem sich nach einem langwierigen Virenscan herausstellte, dass alle .exe-Dateien auf der Platte befallen waren. Allein diese Diagnose hat inklusive Abholen und allem drum und dran ein paar Stunden gedauert. Dann alle Daten retten, die nicht befallen waren (natürlich wie immer gaaaaaaaanz wichtige Daten und kein Backup) und das System sauber neu aufgesetzt mit möglichst allen alten Programmen und Daten. Natürlich war keine Windows XP Home OEM CD dabei (Keine Ahnung, find ich nicht, das hier ist alles, was ich hab), also musste die auch noch besorgt bzw. per kleinem Hex-Editor-Eingriff an einem Image erstellt werden. Schon ein komisches Gefühl, aus den einschlägigen Quellen eine zur vorliegenden Seriennummer passende Windows CD zu saugen und zu modifizieren, obwohl man genug Windows XP CDs da hat, nur eben nicht für die Home-OEM-Edition. Insgesamt habe ich also über einen Arbeitstag intensiv an dem Rechner gearbeitet, dessen Wert meinen normalen Tagessatz bei weitem unterschritt. Für das Geld hätte man sich einen schicken neuen Rechner anschaffen können, also habe ich nur zwei Arbeitsstunden berechnet. Im Nachhinein ärgere ich mich ein wenig darüber, aber das Problem ist ja, dass die Kosten hier in keinem Verhältnis zum Nutzen standen. Also kann ich entweder viel weniger Geld nehmen und trotzdem langen Gesichtern gegenüber stehen, was reichlich bescheuert ist, oder eben etwas machen, wo ich meine gewünschten und angesichts meiner Leistung und Expertise angemessen Stundensätze realisieren kann. Man bezahlt nun mal lieber für ein neues Bad als das gleiche Geld für die Behebung eines Rohrbruchs.

Warum ich trotzdem gelegentlich noch Computerservice für Privatleute mache, obwohl ich daran viel zu wenig oder oft auch gar nichts verdiene, bzw. sogar draufzahle, wenn man in Opportunitätskosten denkt? Weil ich ein paar alte Kontakte nicht einfach abbrechen möchte und die Leute haben ja sonst niemanden und ich hab so ein gutes Herz… Also letztlich fürs Karmakonto, denn Dankbarkeit ist eine echt schöne Währung. Und nebenbei reizen mich gelegentlich auch die kniffligen Probleme, vor allem, wenn ich sie dann gelöst bekomme und auch weil ich sie lösen kann. Come get some, bastard bugs!

Lightboxen, also diese Dinger, die Bilder und anderes schön anzeigen, ohne ein echtes Popup zu sein, sind ja eine feine Sache. Einige Lightboxen erkennen nämlich die Bildschirmauflösung des Benutzers und skalieren die Bilder entsprechend, so dass sie so breit wie möglich sind, aber noch in den Browser passen. Eine kluge Idee an sich, wenn sie nicht von Zeit zu Zeit etwas hirnlos implementiert wäre. Ich habe eine Auflösung von 1920x1200 auf meinem 24"-Bildschirm. Diese hohe Auflösung nutze ich dazu, neben normalbreiten Fenstern noch Chatfenster, Audioplayer und solchen Kram sichtbar zu halten. Vor allem aber sehen die meisten Websites in so breiten Browsern völlig dämlich aus, weil sie nicht mal die Hälfte der Bildschirmbreite füllen. Jetzt kommt das Problem mit den kurzsichtig programmierten Lightboxen ins Spiel: Besucht mal diese moderne Seite eines Wohnwagenherstellers (via Alex) und öffnet eines der Bilder. Surft ihr mit maximiertem Browserfenster ist alles OK, tut ihr das nicht, ist das Bild breiter als das Browserfenster und ist nicht mehr sinnvoll zu erkennen.

Das dort eingesetzte Lightbox-Script ist Lightview und das macht den kapitalen Fehler, hier die Bildschirmausflösung abzufragen und nicht die Größe des Viewports (der im Browser sichtbare Bereich). Update: Das Problem tritt nur in Opera auf. Warum? Denken die Entwickler, jeder surft immer maximiert? Was ist mit Leuten, die einen erweiterten Desktop haben (mehrere Bildschirme)? Und was ist mit Leuten, die ihre Websites gezoomt anschauen? Und wie dämlich ist der gesamte Ansatz, wenn nur die Breite beachtet wird und nicht die Höhe? Die Bilder auf der verlinkten Seite haben ein 4:3-Format, so dass es auf einem Widescreen-Monitor mit hoher Auflösung zwangsläufig oben und unten abgeschnitten wird. Scrollen ist aber nicht, weil das Bild leider mitscrollt. Nett gemeint, aber völlig unzureichend umgesetzt.

Lightview ist aber nicht das einzige Script, das diesen Fehler macht, der gleiche Effekt kommt mir immer wieder unter. Meistens fällt das nicht auf, weil die Bilder nicht größer als mein Viewport sind. Aber wenn das der Fall ist zeigt sich sehr imposant, dass der Entwickler des Scripts nicht zu ende gedacht hat und so die Usability am Ende sinkt statt steigt. Das Bild wird man übrigens mit einem beherzten Druck auf Esc wieder los, oder indem man die Seite weit genug heraus zoomt.

Nachtrag 16.09.2008: Wie ich gerade feststellen musste, tritt das Problem bei Lightview nur in Opera (getestet in 9.52) auf, im Firefox orientiert sich die Bildgröße in Höhe und Breite korrekt am Viewport. Nach etwas Recherche weiß ich jetzt auch, wieso: Die von Lightview eingesetzte JavaScript-Bibliothek Prototype hat ein Problem mit der von Opera seit Version 9.5 veränderten Handabung des Viewports. Klingt kompliziert? Ist es auch. Also kurz gesagt: Lightview arbeitet korrekt, nur gibt es eine Inkompatibilität der benutzen Prototype-Version mit Opera 9.5. Das Ergebnis ist das gleiche: Usability-mäßig gut gemeint, am Ende steht aber ein dickes Minus. Ein generelles Problem mit solchen JavaScript-Spielereien, mit denen man stets vorsichtig umgehen sollte.

Mein Bruder hat schon lange arge Probleme mit meinem RSS-Feed in Thunderbird. Diese äußern sich derart, dass immer wieder mal (mehrere) alte Beiträge als ungelesen markiert werden. Auch solche, die ich nicht editiert habe, dort ist das ja Absicht. Frage nun: Hat sonst noch jemand solche Probleme mit meinem Feed? Wenn ja, bitte mal eben einen Kommentar oder eine Mail schreiben und die Probleme spezifizieren, sowie den verwendeten Feedreader nennen.

Ich habe diese Probleme nicht, weder in Opera noch im momentan testweise von mir eingesetzten Gregarius, daher bin ich auf Eure Mithilfe angewiesen.

Ich mache intensiven Gebrauch der Tabs in Opera. Beispielsweise gehe ich Newsseiten immer in der chronologischen Übersicht durch und öffne interessante Artikel als Tabs im Hintergrund. Seit ich auf Opera 9.5 upgedatet habe kommt es nun immer mal wieder vor, dass ich Artikel vermisse, von denen ich eigentlich dachte, dass ich sie zuvor geöffnet hatte (Rechte Maustaste -> in neuem Tab öffnen). Bislang habe ich das immer auf meine Nachlässigkeit geschoben, hab ich wohl daneben geklickt. Heute an einem anderen Rechner habe ich aber definitiv auf den richtigen Menüpunkt geklickt und es hat sich kein Tab geöffnet. Ha, in flagranti erwischt Du schelmisches Stück Software. Offenbar handelt es sich hier um einen Bug. Lästig. Lästiger jedenfalls als der Bug, dass bei mir gelegentlich die Menüleiste durchsichtig wird und erst durch maximieren und wiederherstellen des ganzen Fensters wieder sichtbar gemacht werden kann. Bei beiden Fehlerbildern konnte ich bisher keine Regelmäßigkeit entdecken.