Monthly Archives: Juni 2009

Liegt wahrscheinlich an mir, aber bei dem Stichworten personas und customization kamen mir spontan zwei Dinge in den Sinn.

1. Profile gibts doch schon.
2. Moment — so richtig anpassen? Whoot!

Tja, leider sind Personas in Firefox 3.5 bloss so eine Art MySpace fürn Desktop. Schade. Aber auch cool. Nicht für mich, aber bestimmt für andere. Der IE kann sowas jedenfalls nicht. In diesem Sinne kann das doch nur ein Stunt sein, die Kids zu FF zu holen, die lange Jahre dem IE treu geblieben sind.

Jetzt haben sie endlich einen handfesten Grund, FF zu benutzen. Sauber :-)

Bei einem der letzten Mittwochstammtische erzählte Jörg von einem Jungdesigner in seinem Team, der ob des Auftrags, eine Website im IE6 zu checken und etwaige Probleme zu beheben, verzweifelte. Immerhin hatte er den IE6 nicht mehr so wirklich mitbekommen — seit 2006 gibts den IE7, da war der Knabe gerade 16.

Wollen wir hoffen, das der IE6 bald von der Bildfläche verschwindet. In fünf Jahren gibt eh niemanden mehr, der für dieses wunderbare Stück Software Website bauen kann ;)

Da fällt mir, ich sollte meine monatliche Erinnerungs-E-Mail an unsere Admins einrichten…

Meine Idee, die Blogroll durch meine Twitter-Freunde zu ersetzen, hat einen Haken. Bislang hat kein Feedreader, trotz htmlURL im OPML, ein auto discovery gemacht. Das generierte OPML ist in dieser Form also nicht nutzbar. Sch…ade auch.

Nun, Entwickler sind ja bekanntlich faul ;) Statt selbst das auto discovery zu implementieren (was, nebenbei bemerkt, eine echte pita sein kann, trotz HTTP HEAD und regexp magic), wandte ich mich meinem Kumpel Yahoo! Pipes zu.

Mit Fetch Data, einer Loop, Feed Auto Discovery und Filter ist das Problem, aus einer per OPML (oder beliebigem XML) gelieferten URL-Liste eine Blogroll zu machen, im Nu gelöst.

Im Moment sieht der Ablauf wie folgt aus:

1. Benutzer lässt die Applikation per OAuth auf sein Twitter-Profil. Das muss sein, weil die Liste der Freunde nur eingeloggt sichtbar ist.
2. Die App ruft den Feed mit den letzten Status der Freunde ab (Freunde, die nie getweetet haben, fallen also hinten runter). Dieser Feed beinhaltet für jeden Freund die im Profil angegebene URL.
   Alternativ könnte man auch eine Liste der Twitter-IDs der Freunde abrufen und dann für jeden einzeln das Profil. Pah.
3. Aus der Liste generiert die App OPML mit htmlURL-Angaben und speichert sie temporär auf meinem Webspace.
4. Die Pipe wird mit der URI auf diese Datei als Parameter angeworfen. Sie gibt einen RSS-Feed zurück (Yahoo Pipes! gibt immer RSS zurück, aber auch serialisierte PHP-Arrays oder JSON).
5. Dieser Feed wird von der App in OPML umgewandelt und das Ergebnis ausgegeben.

Problematisch dabei ist die Laufzeit von Yahoo! Pipes. Das Crunching der Liste meiner Freunde dauert um die 40 Sekunden — nicht wirklich praktikabel, wie ich finde. Für meine Zwecke reichts, aber um das ganze öffentlich anzubieten, doch etwas zu heftig. Die lange Laufzeit ist durch das auto discovery bedingt. Die Pipe fragt jede URL ab, und muss die Rückgabe parsen. Antwortet die Website langsam oder gar nicht, kanns bis zum Timeout (geschätzte 3 Sekunden) dauern, bis die Loop die nächste URL dem Feed Discovery-Modul übergibt.

Wenn die Feedreader das auto discovery selbst erledigen würden oder clever genug wären, die htmlURL im OPML mit bereits vorhandenen Feeds abzugleichen… eRONA konnte sowas ;)
Der Link führt zu allen eRONA-Artikeln hier — eRONA war ein Feed Aggregator Marke itst.

Morgen kommt Firefox 3.5.

Genau im richtigen Moment. Mein 3.0.11er schluckte gerade knapp über ein Gig RAM. Wenn dieser Benchmark auch nur ein halbwegs reales Bild zeichnet - holy moly.

Mein Test Case wird soup.io bzw. dessen Popup sein. Wenn man nach dem Klicken auf den “Zitieren”-Button bis drei zählen kann, eh etwas passiert: FF 3.5 #fail, u know?

What you see is what you get. Das mag für einfache Dinge gelten, für einen Stein oder eine Pflanze.

Nein, auch für einfache Dinge … Moment, was sind einfache Dinge?

Kommt wohl darauf an, wie man es benutzen will, das Ding. Ein Feuerzeug zum Beispiel ist einfach zu benutzen. Aber ist es deswegen einfach? Einfach herzustellen zum Beispiel?

Das Gleiche gilt für Texte im Browser. Steht der Text nicht gerade Blau auf Rot, kann man ihn meistens ganz gut benutzen, also lesen. Ob es auch einfach war, den Text herzustellen?

Egal wohin man schaut, überall findet man WYSIWYG-Editoren. Und die gaukeln dem Benutzer vor, dass der veröffentlichte Text am Ende genauso aussieht, wie der Text jetzt im Editor erscheint. Außerdem, und das ist viel schlimmer, weckt so ein WYSIWYG-Editor Erwartungen — immerhin hat er eine Toolbar fast wie Word. Die Erwartungshaltung lautet also: Word im Browser¹.

Jetzt nicht die Stirn runzlen. Geht mal bitte nicht von Euch aus — ich nehme an, die wenigen Leser meines Blogs sind ähnliche Techies wie ich und kämen nie auf diese Idee. Und bitte, “Ah. DAUs!” braucht an dieser Stelle keiner zu denken. Wir reden von Lieschen Otto-Müller, die prima mit Word klarkommt (und vielleicht sogar schon mal mehr als einen Brief damit geschrieben hat) und ausgeguckt wurde, Texte auf der Website zu veröffentlichen.

Der erste Stolperstein: Sieht der publizierte Text im Frontend wirklich so aus wie im Editor? Nö. Warum? Weil die CSS-Definitionen des Frontends es nicht bis zum Editor im Backend schaffen.

Und zweitens: Funktioniert der Editor wie Word? Nö. Man kann nicht mal Text aus Word einfach so in den Editor kopieren. Jaja, das liegt vor allem an Word. Vor allem. Aber nicht nur.

Ach so, warum ich hier auf Word rumreite. Weil es nun mal die Standardtextverarbeitungssoftware in Unternehmen ist.

Nun hat man zwei oder drei Alternativen. Entweder man nimmt beim Copy&Paste einen Umweg über Notepad, oder man schult seine Contentlieferanten im Umgang mit dem Editor, oder man lässt sie gleich in Dreamweaver schreiben.

Die Notepad-Misere: Sage und schreibe 9 (neun) Schritte sind nötig, um einen Text aus Word über Notepad in die textarea zu bekommen. Das ist … Schlecht.

All in one place geht leider nicht. Was ist mit Rechtschreibung- und Grammatikprüfung? Mit gelieferten Texten? Entweder hat man Glück und der Redakteur braucht keine Rechtschreibung- und Grammatikprüfung, weil er die zwölf Duden-Bände auswendig gelernt hat, dann kann er direkt lostippen. Bekommt seine Kollegin aber Texte geliefert (von Externen, aus der Presseabteilung, dem Vertrieb oder aus anderen undurchsichtigen Quellen), muss sie den Text im Editor nachbauen. Der Spaßfaktor dürfte entsprechend gering sein, von der Produktivität ganz zu schweigen.

Träume zerbrechen an der harten Realität. Dreamweaver ist eben keine Textverarbeitung, sondern ein Websitemanager mit XHTML-Fähigkeiten.

Letztlich sind alle drei Optionen nur workarounds, aber keine Lösung des Problems. Schade.

Bleibt der Weg über ein highly sophisticated Redaktionswerkzeug, das SGML ausspuckt, welches transformiert wird und automatisiert die Publikationskanäle füttert. Na klar, für eine Pressemitteilung oder eine Produktbeschreibung (die online bitte nicht der im gedruckten Katalog entspricht!).

Oh, und nicht zu vergessen die Contentmanager, Leute, die den lieben langen Tag Texte nachbauen. Und wenns mal eine Woche keine Änderungen zu machen gilt, drehen die Däumchen. Jetzt sagt nicht, dass man ja zwei Leute schulen kann und die das dann eben machen. Tagesgeschäft anyone? Urlaub? Krankheit? Dienstreise?

Was wir brauchen, ist ein WYSIWYG-Editor, der seinen Namen verdient. Und wenn Word eben Bockmist in die Zwischenablage packt, dann muss es eben der Editor richten. Was TinyMCE und FCKEditor da als Lösung präsentieren, ist Halbseidenes — nicht mehr.

Bis dahin bekomme ich (berechtigte) Meckeranrufe und muss die Texte im CMS selbst nachbauen. Nachbauen!

¹: Ribbons im CMS-Editor? OMG.

Wie HORIZONT berichtet, hat es die IVW endlich geschafft, die schon 2008 leise angekündigte Umstellung im Meßverfahren beschlussfertig zu machen.

So sollen PI nur noch bei Klicks auf werberelevante Links erfasst werden. Diese Umstellung bedeutet das Aus für Klickstrecken — worüber sich vor allem die kleinen unabhängigen Publisher unterhalb der 10 Mio. PI-Grenze freuen werden.

Wo bild.de & Co. täglich mehrere Klickstrecken mit dutzenden Seiten bauten, wird sich das ab 2010 nicht mehr lohnen, und die PI dieser Websites entsprechend nach unten korrigiert.

Durch den Einsatz von Klickstrecken werden aus einer Page Impression für den Aufruf eines Artikels plötzlich dutzende, wodurch die IVW-gemessenen PI verfälscht und unvergleichbar wurden.

Die durch die von der IVW geplanten Änderungen der Messregeln ab 2010 geringer ausfallenden PI-Zahlen haben durchaus Auswirkungen auf die Publisher. Sie erhalten dann nämlich weniger Werbebuchungen, bekommen einen geringeren TKP und haben am Ende des Jahres deutlich weniger Werbeeinnahmen.

Bereits 2008 hatte ein IVW-Mitarbeiter mir gegenüber gesagt, dass man daran arbeite, die Messregeln entsprechend anzupassen — scheinbar hatten sich eine Menge Publisher beschwert und immer wieder “Verstöße” gemeldet, die strenggenommen keine waren. Nach dem aktuellen Regelwerk (S. 4f) ist das Laden eines neuen Bilds innerhalb einer Bildergalerie eine wesentliche Änderung, die das Erhöhen des PI-Zähler rechtfertigt.

Und so entstanden an allen Ecken und Enden des Netzes die unrühmlichen Klickstrecken. Hat man Zugriff auf ein großes Bildarchiv, lassen sich im Handumdrehen oben erwähnte Durchklickgalerien erstellen. Auch Quizze und Umfragen sind zur Steigerung der PI-Zahlen sehr beliebt — und sind im Zweifel vom Praktikanten kostengünstig erstellt.

Zumal die meisten Klickstrecken journalistisch gesehen Müll sind. Soviel zum Thema Qualitätsjournalismus.

Andererseits, wie oben erwähnt, waren PI bislang DIE Währung der Online-Werbung (jedenfalls für die Verleger, Social Networks wie schuelerVZ haben arge Schwierigkeiten, ihre 5+ Mrd. PI zu Geld zu machen, vor allem jetzt in einem schrumpfenden Markt). Drastische Änderungen der Messung und Ausweisung haben gleichfalls drastische Änderungen der Verteilung der Werbeetats zur Folge.

In einer eilig nachgeschobenen Pressemitteilung läßt die IVW heute verlautbaren, dass auch in Zukunft die PI ein Faktor zur Darstellung der Werbeträgerleistung von Online-Medien bleiben sollen:

Darüber hinaus ist es unser gemeinsames Ziel, Leistungswerte wesentlich stärker in Zusammenhang mit Herkunft, Plattformen und Inhalten in Form eines multidimensionalen Kategoriensystems zu differenzieren.

Ich weiß nicht so recht, was ich davon halten soll. Handlete die IVW nach ihrer Ankündigung, verlieren die Publisher ordentlich Mana im Kampf um Werbekunden, was in deren Sinn ja nicht sein kann. Also vermute ich, dass wir gegen Ende des Jahres ein paar Detailänderungen bekommen, die zusammen genommen niemandem wehtun werden. Immerhin ist die IVW eine vom Zentralverband der deutschen Werbewirtschaft e.V. gesteuerte Veranstaltung. Dem ZAW wiederrum gehören überwiegend Werbende und Werbemittelhersteller an. Keiner von denen hat ein Interesse an drastischen Änderungen (=Kosten) oder geringeren Umsätzen.

Deloitte hat eine Studie über Zeitungs- und Zeitschriftenverlage in konvergierenden Medienmärkten veröffentlicht, die kostenlos verfügbar ist.

In der Studie werden sechs strategische Handlungsoptionen empfohlen:

• Aktive Konsolidierung – mit dem Ziel einer Markt- und Kostenführerschaft im Printgeschäft
• Diversifikation zu einem integrierten Medienkonzern – mit dem Ziel, digitale Wachstumsmärkte zu erschließen und Synergien zu schaffen
• Internationalisierung – mit dem Ziel, außerhalb des gesättigten deutschen Marktes zu wachsen
• Fokussierung auf Nischenmärkte – mit dem Ziel, spezielle Informations- und Unterhaltungsbedürfnisse abzudecken
• Geordneter Rückzug – mit dem Ziel, loyale und zahlungsbereite Leser zu halten, um den Free Cashflow zu optimieren
• Desinvestition – mit dem Ziel, über einen kurzfristigen Marktaustritt den maximalen Verkaufserlös zu erzielen

Buchverlage finden zwar keine Erwähnung, für sie gilt aber das Gleiche.

Sehr lesenswert auch die “Übersetzung” der sechs Empfehlungen von Ulrike Langer.

via @leanderwattig

Hab’ heute abend meine Elektroschrottkiste ausgeräumt. Neben 14.4er Modems, Diskettenlaufwerken und anderen historischen Gerätschaften — und zig dongly things — habe ich mein Zip-Laufwerk ausgegraben.

Angeschafft hatte ich das 2000 um größere Datenmengen von der Uni nach Hause zu transportieren, ähem. Und siehe da, es läuft auch nach Jahren der lieblosen Behandlung und Ignorierens noch wie am ersten Tag.

…

Und was mach’ ich jetzt damit?

In 20 Jahren werde ich mit großer Wahrscheinlichkeit Vater eines pubertierenden Kindes sein.

Werde ich alles verstehen, was es tut? Werde ich die gleichen Medien nutzen, auf die gleiche Weise? Musik? Kleidung? Sprache?

Nein, natürlich nicht. Aber Mühe sollte ich mir geben. Sollten wir uns geben.

Werden wir es schaffen? Wahrscheinlich nicht ;)

Zum Start von api.golem.de stehen Webservices für den Zugriff auf Artikel- und Kategorieinformationen bereit. Für die Zukunft sind weitere Webservices für den Zugriff auf Videos und Foren von Golem.de geplant. Die entsprechenden Daten stehen in XML und JSON zur Verfügung.

via Golem.de-API - Schnittstelle für Entwickler - Golem.de.

Holy moly. Nicht, weil die Golem so unglaublich super sind, sondern weil sie es tun.