Zeitbombe Delicious.

Den Linksammeldienst Delicious hatte ich fast zehn Jahre im Einsatz, bevor ich heute meinen Account dort endgültig in die Wüste geschickt habe. Mehr oder weniger engagiert habe ich da Links gesammelt, an die ich mich für gewöhnlich von allein nicht mehr erinnere, aber dennoch immer wieder staune, wenn ich mir die Links anschaue. Geht vermutlich vielen Delicious-Nutzern so.

Was mich an Delicious stört, ist die fast schon zelebrierte Hoffnungslosigkeit über die Zukunft des Dienstes. Seit dem Delicious aus Yahoo herausgekauft wurde (und zwar von den Erfindern von YouTube), bewegte sich bei Delicious quasi gar nichts mehr. Schon recht bald wurde Werbung eingeblendet, inzwischen aus mehr als vier AdSense-Werbeflächen. Delicious verkam zu einer reinen Klickhölle, die vornehmlich von Nerds noch verwendet wird, die selten einmal auf die Website von Delicious schauen.

Dass es allerdings irgendwann brenzlig wurde, merkte man daran, dass Delicious plötzlich einen „Shop“ hat. Mit Links hat der Shop herzlich wenig zu tun und erinnert am ehesten dem bösen Ende des Linksammel-Konkurrenten Mr. Wong, der plötzlich ebenfalls ein Shop wurde. So gibt es bei Delicious nun also Tech-Gadgets und vor allem viel Plastikmüll.

Was am Linksammeldienst allerdings nun richtig zeitbombig wird, ist die für notleidende Social-Media-Dienste übliche Abkanzelung. Die Export-Funktion für Links funktioniert seit einer Weile nicht mehr. Die Programmier-API wurde um wichtige Funktionen (eben zum Beispiel der Möglichkeit zum Export von Links) gekürzt. Der RSS-Feed zeigt nur noch die letzten 100 Links eines Benutzers an. Und wer sich zum Exportieren seiner mühsam aufgebauten Links ein Screenscraper-Script bastelt, bekommt es kurz darauf mit dem Webserver von Delicious zu tun, der „übermäßige“ Seitenzugriffe abblockt.

Hier bereitet sich ein Dienst auf seinen Exit vor. Deshalb meine Empfehlung: Finger weg von Delicious und retten, was zu retten ist.

Mit Chrome und Firefox bieten zwei große Webbrowser das Synchronisieren von Bookmarks über mehrere Browser. Zwar fehlt hier die „Socializing-Komponente“, aber mein Empfinden trügt nicht: Mit Linksammeln ist kein Geld zu verdienen und die Gefahr, dass irgendwann einmal so ein Dienst die Stromversorgung kappt, ist hoch. Bei jahrelang gesammelten Links, die mitunter zu echtem Wissen gehören, ist das mehr als ärgerlich, wenn man die verliert, nur weil da jemand keine Lust mehr hat.

R.I.P. RSS Graffiti.

Kleine und sehr wichtige Information an alle, die automatisiert von Blogs bzw. RSS-Feeds aus Inhalte auf Facebook(-Seiten) teilen und dazu bisher das Quasi-Standardwerkzeug „RSS Graffiti“ genutzt haben: RSS Graffiti ist seit 30. April 2015 nicht mehr. Der Dienst wurde abgeschaltet. Es wird hierüber nichts mehr auf Facebook geteilt.

Mir fiel das auch erst heute morgen auf, als ich mich wunderte, warum auf der Facebook-Seite eines Kunden-Weblogs keine Sharings mehr ankommen. Eine kurze Recherche nach der RSS-Graffiti-App auf Facebook ergab dann folgendes Bild:

Das Ende von RSS Graffiti auf Facebook

Auf der Website von RSS Graffiti bedauern die Macher die Einstellung und begründen dies mit dem Scheitern des Businessmodells. RSS Graffiti gehört zu den ältesten Facebook-Apps überhaupt und jeder, der ein Blog dazu bringen wollte, auf Facebook automatisch geshared zu werden, hatte wohl mal Kontakt mit RSS Graffiti. Vor einigen Jahren versuchten die Macher die einst völlig kostenlose App sehr moderat zu monetarisieren, was aber, wie nun offensichtlich ist, gescheitert ist.

So nützlich RSS und Feed-Syndication auch immer ist: Es ist immens schwer, in diesem Umfeld ein tragfähiges Verdienstkonzept unterzubringen. RSS Graffiti ist hier nur ein Opfer von vielen.

Alternativen.

Alternativen gibt es einige. Sowohl innerhalb Facebooks als Facebook-App, als auch als externe Dienste. Darunter dann auch einige kostenlose und einige richtig teure, die sich vornehmlich an professionelle Social-Media-Redakteure richten.

Ein kostenloser, externer Dienst ist IFTTT, der die Einrichtung relativ einfach hält, allerdings das zentrale Problem hat, dass immer nur eine Facebook-Seite pro IFTTT-Account als Ziel angelegt werden kann. Das ist für den professionellen Einsatz mit dem Sharen von Inhalten auf getrennte Facebook-Seiten relativ umständlich, weil man dann mit einer Vielzahl von IFTTT-Accounts hantieren muss. Einigermaßen absehbar ist, dass IFTTT – so wie viele andere Dienste auch – irgendwann einmal Geld kosten dürfte.

Eine weitere Alternative empfiehlt sich für WordPress, nämlich mit dem Plugin „Jetpack“ von Automattic, den Machern von WordPress. Hier gibt es in der riesigen Sammlung von integrierten Tools eine Rubrik namens „Sharing“, die genau das tut: Sharing auf Social Networks. Neben Facebook und Twitter unter anderem auch zu Tumblr und vor allem – zu Google+. Interessant dabei ist, dass dies mit WordPress- bzw. Automattic-Mitteln funktioniert und damit wohl auch ein längerfristiger Erhalt gewährleistet sein dürfte.

Was man alles aus Google Tasks machen könnte.

Google Keep und Google Tasks sind bei mir die beide am häufigsten genutzten Google-Dienste, die ich in der Kombination PC, Notebook, Smartphone und Tablet einsetze. Viele Inputs, die ich irgendwann einmal vor allem in Blog-Artikel oder anderweitige Texte verarbeite, entstehen bei mir an den unmöglichsten Orten: Im Auto, in der Küche, beim Essen, beim Laufen, auf der Toilette und überall dort, wo ich nun mal bin. Ein Gedankenblitz und der muss sofort irgendwo festgehalten werden.

Google Keep ist das, was man in der echten Welt als Notizzettelsammlung (oder Papierwirtschaft) bezeichnen würde. In so einen Notizzettel lässt sich Text unterbringen, aber auch ein Bild oder auch eine Audiodatei. Letzteres ist besonders praktisch während der Autofahrt. Zwar versucht Google danach eine OCR-Texterkennung, die jedoch bei meinem stichwortartigen Diktat und nebenan laufendem Radio sehr obskure Ergebnisse liefert, aber immerhin.

Wenn es strukturiert laufen muss, ist Google Tasks mein Werkzeug der Wahl. Im Gegensatz zu so vielen ToDo-Werkzeugen ist Google Tasks brutalstmöglich einfach: Aufgabe und gut. Keine Möglichkeit zur Priorisierung, keine bunten Farben, Reiter oder Möglichkeiten zum Einbinden von Bildern. Nichts. Nur ein Datum lässt sich hinterlegen, wann die Aufgabe kritisch wird. Und das lässt sich dann netterweise im Google Kalender einblenden.

Und noch etwas kann Google Tasks hervorragend: Aufgaben verschachteln und gruppieren. Es lassen sich Aufgabengruppen anlegen, so zum Beispiel für alle meine Blog-Projekte. Einzelne Aufgaben können dann innerhalb einer Gruppe angelegt werden und praktischerweise weitere Aufgaben dann auch unterhalb einer übergeordneten Aufgabe. Eine Aufgabe lässt sich sehr leicht von A nach B schieben, hoch und runter, ähnlich wie ein Fluglotse an- und abfliegende Flugzeuge sehr einfach gruppieren kann. Und für Google Tasks gibt es für iOS und Android auch genügend nette Apps, wie zum Beispiel „GoTasks“, das es auf beiden Plattformen gibt, aber witzigerweise von zwei unterschiedlichen Programmierern, die jedoch beide in Sibirien leben.

Das Problem: Google Tasks wird von Google stiefmütterlich behandelt. Es ist nämlich kein eigenständiger Dienst, sondern ist in Google Mail integriert. Deshalb gibt es nur mit Tricks auch ein eigenständiges Web-Interface und Google Tasks kann so viele Dinge nicht, die es eigentlich können könnte, wenn man denn wollte. Zum Beispiel:

  • Multiuserfähigkeit
    Wie schön wäre es, wenn man Aufgaben an andere Google-Accounts, zum Beispiel innerhalb eines Unternehmens, delegieren könnte oder Aufgaben mit anderen Benutzern teilen könnte. Aufgabe XY braucht einen Input von Kollege A, also Delegation zu ihm mit Datum. Er macht das Ding fertig, erledigt die Aufgabe und sie kommt wieder zurück. Danach geht die Aufgabe zu Kollege B, der dann Abrechnung macht. Wie auch immer. Multiuserfähigkeit wäre superschön (um wahr zu sein, leider).
  • Verheiraten mit Google Keep
    Was ich immer noch nicht verstehe: Google Tasks ist nicht verheiratbar mit Google Keep oder wenigstens mit Google Drive. Und genau das wäre einfach nur schön, denn aus einem Notizzettel eine Google-Tasks-Aufgabe machen, eine Aufgabe erledigen und dann in Google Drive zur Entsorgung verklappen und archivieren … ein Traum wäre das. Ärgerlicherweise hat Google Keep für Notizen eine eigene Möglichkeit zur Anlage von ToDo-Listen, die leider komplett inkompatibel zu Google Tasks ist. Verstehe das mal einer.
  • Eine Schnittstelle zu ggf. IFTTT.com
    Einen Aufgaben-Workflow, der nach der Aufgabenanlage und beim Vorhandensein bestimmter Kriterien bestimmte Wege geht – das ist das Killerkriterium einer großen und teuren Groupware und das wäre mit Google Tasks doch auch so hübsch und schön. Immerhin: Dieser Mangel ließe ein Stückweit kompensieren mit der Teilen-Funktion von Android. Hier könnte man, wenn eine Aufgaben-App das unterstützen würde, einen Text per Teilen-Funktion auch zu einer Aufgaben-App übertragen, die dann daraus eine Aufgabe erstellt. Leider habe ich eine entsprechende App noch nicht gefunden.
  • (Passwort- und SSL-gesicherter) RSS-Feed
    Ein RSS-Feed der Aufgabenverwaltung und einzelner Aufgabengruppen wäre der Gipfel des Perfekten, zum Beispiel zum Einbinden eines Aufgabenstranges in das WordPress-Dashboard. Alle Aufgaben schön im Dashboard und vielleicht dann mit einem Klick zu einem Artikelentwurf.

Okay, suchen wir weiter.

TiddlyWiki 2.6.0.

Fast genau ein Jahr nach der Veröffentlichung der Version 2.5.0 hat das Entwicklungsteam um das „Hosentaschen-Wiki“ TiddlyWiki nun heute die Version 2.6.0 veröffentlicht.

Gegenüber der letzten Version 2.5.3 gibt es allerdings nur kleinere Änderungen:

  • Mit einem Tiddler namens WindowTitle kann nun der Seitentitel direkt beeinflusst werden. Ist kein solcher Tiddler vorhanden, wird der Titel automatisch aus der Überschrift („SiteTitle“) und der Subüberschrift („SiteSubtitle“) gebildet.
  • Für Tiddler gibt es nun das zusätzliche Feld namens „creator“, mit dem bei der Anlage des Tiddlers der Benutzername des Benutzers eingetragen wird. Bisher war es so, dass sich dieser Benutzername immer änderte, wenn ein anderer Benutzer den Tiddler bearbeitete. Mit diesem neuen Feld bleibt der ursprüngliche Benutzername also auch nach einer späteren Bearbeitung des Tiddlers fest hinterlegt.
  • Die integrierte jQuery-Bibliothek ist auf die 1.4.2 aktualisiert.

Die deutsche Übersetzung ist natürlich schon während der stetigen Entwicklung der Version 2.6 nachgezogen worden und deshalb schon bereit. Findet sich alles, wie immer, bei TiddlyWikiDeutsch unter karadeniz.de.

SelfHTML goes Wiki.

SelfHTML, die deutschsprachige Referenz für HTML und Webdevelopment, bricht heute auf zu neuen Ufern im Web-2.0-Land, nämlich als Wiki. Das ist bemerkenswert, wenn auch kein Paradigmenwechsel im kollaborativen Sinne, denn das hat Stefan Münz, der Erfinder von SelfHTML, schon vor einigen Jahren vollzogen, in dem er nicht mehr der alleinige Redakteur ist, sondern sich durch das damals eingerichtete Forum im Laufe der Zeit ein Redaktionsteam gebildet hat, dass die Weiterentwicklung übernommen hatte. Kollaboration ist also bei SelfHTML nichts neues und wurde schon praktiziert, als es denn Begriff "Web 2.0" noch gar nicht gab. Ab diesem Zeitpunkt entstanden dann zahlreiche weitere Dokumentationsfeatures, die Stefan Münz als alleiniger Redakteur hätte gar nicht alle selbst betreuen können.

Im Januar dieses Jahres gab es dann eine bemerkenswerte Diskussion darüber, wie es mit SelfHTML weitergehen sollte. Auch das Redaktionsteam kam an seine Grenzen, was sich vor allem darin zeigte, dass es mit neueren Versionen immer komplizierter wurde. Für eine neue Version im Sinne eines Buches braucht es einen Artikelbaum, geschriebene Artikel, Lektorat und vor allem einen festen Zeitrahmen, den man nur mit einem festen Team halbwegs sinnvoll eingehalten bekommt. Aber kann es das sein? Ist das Web nicht gerade deshalb das Web, weil man hier schreiben und veröffentlichen kann, ohne auf die Version zu schauen. Muss man tatsächlich immer hin zu einem fertigen See schreiben oder kann man es nicht auch mit dem Paradigma eines ständig fließenden Flusses tun? Den inzwischen gewaltigen Diskussionsbaum zum Thema "Ist SelfHTML tot?" kann ich nur empfehlen, hier steckt viel darüber drin, wie Altes und Neues im Web funktioniert.

Ein Ergebnis dieser Diskussion war der erste Wiki-Anlauf von Stefan Münz, sozusagen als “Einfach-Machen-Versuch”. Typisch Stefan Münz, könnte man sagen, denn mit der Einfach-mal-Machen-Mentalität ist SelfHTML einst selbst erst entstanden. Nach nun gut sieben Wochen ist dieser Wiki-Versuch zwar bei weitem nicht mit dem Umfang des “Mutter-Projekts” zu vergleichen, allerdings hat es gezeigt, dass es geht – wenn man will.

Und nun geht es eben richtig los: Say hello to the SelfHTML Wiki.

Der Weg ist das Ziel. Aus diesem Grund machen es die Macher nun auch “ganz von vorn”, denn viele Seiten sind leer. Leer, um sie zu befüllen und SelfHTML so neu zu gebähren.

Erste 3D-Modelle in Google Earth aus der Region.

Es hat schon eine Weile gedauert, bis aus Pforzheim und dem Enzkreis die ersten 3D-Modelle in Google Earth auftauchen. Und dann sind es auch gleich ein paar sehr hübsche Modelle, die sich wirklich sehen lassen können, in Google Earth zu finden bei einem Besuch von „Birkenfeld/Württemberg“. (ein Klick für eine Großansicht):

Erstellt wurden die Modelle von Ulrich Stieler, einem Diplomingenieur der Geodäsie und Inhaber eines Vermessungsbüros in Birkenfeld, sozusagen also jemand, dem man am ehesten solche Modelle zutraut. In seiner Galerieseite bei Google finden sich noch einige weitere Modelle.

TiddlyWiki mit Safari und Opera.

Wer den RSS-Feed zu TiddlyWikiDeutsch, meinem Übersetzungsprojekt für die deutsche Übersetzung von Tiddlywiki, liest, wird heute einige Änderungen lesen, die ausnahmsweise nichts mit der Übersetzung selbst zu tun haben, sondern mit einem Problem, das auftritt, wenn jemand TiddlyWiki zum Sammeln von Informationen nutzen will und dazu die Webbrowser Apple Safari oder Opera einsetzt. Beide Webbrowser lassen es nämlich nicht zu, dass sich eine lokal abgespeicherte HTML-Datei selbst überschreiben darf. Genau das tut aber TiddlyWiki bzw. der darin liegende JavaScript-Code, wenn der Benutzer Inhalte in einem lokal abgespeicherten TiddlyWiki ändern und speichern möchte.

Die Lösung dazu ist klein, fein und sauber und nennt sich “TiddlySaver”. Der TiddlySaver ist ein kleines, knapp 3 Kilobyte großes Java-Programm und wird einfach in das gleiche Verzeichnis gelegt, in dem sich die TiddlyWiki-Datei befindet, die man bearbeiten möchte. Wird nun das betreffende TiddlyWiki im Safari oder Opera geöffnet, prüft es zunächst, ob im gleichen Verzeichnis die TiddlySaver-Datei liegt, fragt gegebenenfalls aus anwendungsspezifischen Gründen beim Benutzer um Zulassung der Ausführung und danach läuft das TiddlyWiki so, wie im Firefox oder Internet Explorer auch. Vor allem: Wenn das TiddlyWiki gespeichert werden soll, lässt es sich nun auch abspeichern, auch wenn das im Safari oder Opera getan werden möchte. Einzige Grundbedingung: Die Datei “TiddlySaver.jar” muss schon vor dem Aufruf des TiddlyWiki im gleichen Verzeichnis wie die TiddlyWiki-Datei liegen, weil schon beim Start der Datei der TiddlySaver aufgerufen werden muss.

Wo es das Ding gibt? Hier, unter http://www.tiddlywiki.com/TiddlySaver.jar. Nicht im Webbrowser ausführen, sondern einfach herunterladen und in das gleiche Verzeichnis legen, in dem sich deine TiddlyWiki-Datei(en) befindet/befinden.

Die Wikipedia im Wandel der Zeit.

Über die erschreckenden Diskussionen in der deutschsprachigen Wikipedia-Community über die so genannten “Relevanzkriterien” gibt es eigentlich nicht viel zu sagen. Man kann da auch nicht viel dazu sagen, man kann eigentlich nur den ganzen Tag den Kopf darüber schütteln und sich fragen, was sich da einige Leute eigentlich denken, wenn sie tagtäglich an der Wikipedia arbeiten. Ich habe da so meine eigene Theorie im Laufe der Jahre entwickelt, erstaunlicherweise zu einem Großteil aus meiner Parteiarbeit.

Collaboration ist eine unglaublich komplexe Angelegenheit mit viel Potential für nachhaltigen Ärger. Jeder, der in einer Firma mit anderen Menschen zusammenarbeiten muss, kennt die Thematik und die wird immer komplexer, je komplizierter das Themengebiet ist. Zu dieser Tatsache kommt dann noch das Engagement der Benutzer, das zunächst meist gekrönt ist vom Enthusiasmus über die unglaubliche Erfahrung, als Einzelperson an einem Lexikon mitzuarbeiten, ohne vorher ein Bewerbungsverfahren durchlaufen zu haben. Und so weiter. Diesen Enthusiasmus muss ich, denke ich, nicht wirklich beschreiben, dieses Gefühl hat jeder gemacht, der irgendwann mal in der Wikipedia irgendetwas geändert hat und seien es Korrekturen von Rechtschreibfehlern.

Und da kommen wir auch schon zu einem solchen Thema: Rechtschreibfehler. Diese nämlich “on the fly” beim Besuchen einer Wikipedia-Seite zu korrigieren, habe ich eine Zeitlang sehr gern gemacht. Wenn man schon keine Zeit oder Muße hat, einen Artikel zu ergänzen, kann man doch wenigstens so zur Qualität der Wikipedia beitragen. Es war für mich auch dahinsichtlich nie ein Problem, einen Wikipedia-Account dazu zu haben. Die mittelgroßen Dramen, die bei den Diskussionen, ob man das anonyme Schreiben weiterhin zulassen will oder nicht, habe ich nie verstanden.

Was ich irgendwann verstanden habe, war, dass man solche vermeintlichen Pupsarbeiten eigentlich gar nicht will. Das begann, als irgendwann die Reglementierungen durch die “Sichtung” von Änderungen eingeführt wurden. Das führte dazu, dass ich zwar munter rechtschreibkorrigieren konnte, aber diese Änderungen gerade in den wenig frequentierten Artikel mangels Sichtungen quasi niemals freigeschaltet wurden. Und gerade diese fehlenden Sichtungen führten dann paradoxerweise auch noch dazu, dass ich auch nicht im entferntesten in die Situation kam, irgendwann selbst sichten zu dürfen, weil ich meine Mindestanforderungen von 100 Seitenänderungen nicht zusammenbekam.

An solchen Metadiskussionen krankt die Wikipedia von Anfang an und es erstaunt mich zutiefst, wie man sich über Jahre hinweg mit solchen Diskussionen beschäftigen kann und megabyteweise Diskussionsseiten volltextet, anstatt diese Schreibenergie in vernünftige Dinge zu kanalisieren. Workflows, die keiner versteht, eine immer noch katastrophale Eingabesyntax, die keiner blickt und ein Ton von “Chefautoren”, den keiner nachvollziehen kann. Das Kleinbürgertum ist nicht frisch in die Wikipedia eingezogen, es war von Anfang an dort.

Das Fatale dabei ist, dass man zwei Dinge machen kann, wenn man mit Kleinbürgertum und Scheuklappendenken zu tun hat: Man kann es bekämpfen oder man kann versuchen, damit klarzukommen. Erstaunlicherweise versuchen sich viele mit ersterem, was in meinen Augen völlig hoffnungslos ist. Salopp gesagt scheitert es daran, dass man einen Dummen nur dann klug bekommt, wenn er denn das auch wirklich wollte. Oder man schaut lieber zu, mit dem Dummen soweit klarzukommen, dass er seinen Beitrag auf der niedersten Ebene so tut, dass andere damit aufbauen können. Das ist das Geheimnis der Collaboration.

Im Parteien- und Vereinsleben hat man es mit vielerlei Menschen zu tun und zwar gleich mit allen Kategorien. Dumme, Intelligente, Gesunde, Kranke, Gestörte, Gelenkte, Freidenkende, Chaoten. Alles in allem vereint eine Aktion alle diese Menschen: Sie kleben die gleiche Beitragsmarke in ihr Partei- oder Vereinsbuch ein. Und bei allen anderen Themen ist Toleranz gefragt. Selbstverständlich kann ich mit einem vermeintlich dummen Menschen tagelang darüber diskutieren, warum er an einem Infostand nur dazu taugt, Luftballons aufzublasen. Nur: Was bringt uns das? Ich kann weder den vermeintlich dummen Menschen rauswerfen, noch wird sich signifikant etwas an der intellektuellen Basis ändern. Also muss ich eher zuschauen, genügend Luftballons dabeizuhaben, damit dieser vermeintlich dumme Mensch sein Scherflein dazu beitragen kann. Und erstaunlicherweise funktioniert das, denn nach wie vor sind Luftballons unverzichtbar auf Infoständen von Parteien.

Zugegeben, diese einfachsten Grundregeln der Collaboration zu verstehen und auch ein Stückweit danach zu leben – das hat mich jahrelanges Lernen gekostet und das kostet mich auch jetzt noch immer wieder Nachsitzen. Sicherlich kann man auch darüber diskutieren, ob mein Parteiaustritt im Sommer nicht auch mit einer gewissen Portion Toleranz hätte vermieden werden können. Toleranz, die ich als Funktionär aufzubringen habe, denn auch dazu hat man mich ursprünglich einmal gewählt.

Nun ist das zusammenarbeitende Milieu in der Wikipedia weder eine Partei, noch ein klassischer Verein, sondern besteht aus einem unsortierten Haufen von Individuen, die aus haarsträubend Dummen und auch haarsträubend Klugen besteht. Begreift das doch als Chance, selbst wenn die Chance bedeuten würde dass die so genannten Relevanzkriterien aufgeweicht werden. Die Wikipedia ist an keine maximale Seitenzahl gebunden und lesen muss niemand alles. Der Rest regelt sich.

TiddlyWiki 2.5.3.

Auch bei TiddlyWiki gibt es ein Sommer-Update, allerdings hier nur ein kleines, das sich weitgehend auf Bugfixes beschränkt. Änderungen an der deutschen Übersetzung gibt es erfreulicherweise wiederum keine, so dass ein reines Update einer bestehenden TiddlyWiki-Datei genügt, wenn schon die Version 2.5.1 oder 2.5.2 eingesetzt wird.

Deutsche Übersetzung und Hinweise zur Installation wie immer nebenan.

TiddlyWiki 2.5.0.

Die Mini-Wiki-Software TiddlyWiki ist heute in der Version 2.5.0 erschienen. Die größte (und weitgehend einzige) Neuerung ist die Implementierung der JavaScript-Bibliothek jQuery, mit der die TiddlyWiki-Entwickler nun einen größeren Meilenstein für zukünftige Entwicklungen legen, vor allem im Bereich der Interoperabilität von TiddlyWiki in unterschiedlichen Browsern.

Dazu muss gesagt werden, dass JavaScript zwar eine weitgehend einheitliche Sprache ist, es aber bei der Interaktion zwischen JavaScript und Webbrowsern teilweise grundlegende Unterschiede gibt. JavaScript-Bibliotheken wie jQuery versuchen diese unterschiedlichen Ansätze mit einem eigenen Befehlssatz zu vereinen. Der Ansatz von TiddlyWiki war bisher so, dass die Entwickler weitgehend auf eigene Faust versucht haben, diese Unterschiede auszumerzen, was in den meisten Fällen auch eindrucksvoll funktioniert – noch immer staunen selbst gestandene Fachleute über den Funktionsumfang von TiddlyWiki und über das Phänomen, dass es immer noch ein Wiki ohne Server ist. Dazu kommt, dass die meisten der heutigen JavaScript-Bibliotheken noch gar nicht so alt sind und zu Beginn der ersten TiddlyWiki-Versionen diese noch nicht so hochentwickelt waren, wie sie es heute sind.

Wie dem auch sei – die Version 2.5.0 ist ein heller Meilenstein und ein deutliches Zeichen, dass trotz der inzwischen konservativ wirkenden Update-Zyklen TiddlyWiki noch lange nicht zum Alteisen gehört – ganz im Gegenteil.

Und wie immer ist auch schon meine deutsche Übersetzung bereit. Das vor allem auch deshalb, weil die bisherige Übersetzung für die vorherige Version 2.4.3 komplett unverändert übernommen werden kann.