Einige wenige meiner Kollegen lehnen Gmail ab. Ich muss das hässliche und unpraktische Outlook benutzen, wenn ich ihnen Mails schicke. Und sie verlangen sogar, dass ich Mails von ihnen oder an sie nicht in meinem Gmail-Account speichere. Sie befürchten, dass Google Profile von ihnen anlegt und diese Profile missbraucht.

Für mich ist Gmail — ich verwende es mit der GTDInbox — eines der wichtigsten Arbeitsinstrumente. Ich kann praktisch unbegrenzt viel speichern (die interne Mailbox bei meinem Arbeitgeber ist immer wieder überfüllt), finde die Informationen wieder und und kann sie leicht organisieren. Der Komfort ist so gross, dass ich darüber hinwegsehen kann, dass Anzeigen für Liebe ab 30 oder mit der Aufforderung Folgen Sie Ihrer Berufung….Werden Sie Schamane! eingeblendet werden. Außerdem unterrichte ich Web Publishing und muss brauchbare webbasierte Tools kennenlernen — das geht nicht, ohne sie selbst intensiv zu benutzen. Wer Gmail nicht verwendet, wird Google Wave kaum benutzen können, und wer nicht versteht, was Google Wave bedeuten könnte, sollte nicht zu angehenden Journalisten über das Web sprechen.

Handle ich unverantwortlich, wenn ich Gmail benutze? Liefere ich vertrauliche Informationen einer Datenkrake aus? Ich glaube: Nein! Ich bin mir aber nicht ganz sicher, und ich bitte um Diskussion und Kritik — nicht zuletzt übrigens Kollegen, die das hausinterne Exchange-System (von dessen Sicherheit wiederum auch nicht alle überzeugt sind) für vertrauenswürdiger halten.

Ein paar Überlegungen dazu:

  1. Viele mögen diese erste Überlegung für naiv halten: Google hat Datenschutzbestimmungen. Wer Dienste von Google benutzt, erkennt diese Bestimmungen an, und Google verpflichtet sich dazu, sie einzuhalten. Diese Bestimmungen lassen, wenn ich sie richtig verstehe, nicht zu, dass Google Profile von erwähnten Personen, z.B. Adressaten, anlegt, und sie schließen definitiv aus, dass diese Profile zu kommerziellen Zwecken weitergegeben werden. Sollte ein Missbrauch vorkommen, kann man dagegen klagen. (Mir sind solche Klagen nicht bekannt.) Warum sollte sich Google dem Risiko solcher Klagen — und dem PR-GAU, den Verstöße gegen diese Regeln bedeuten würden — aussetzen? Gibt es Gründe, die Seriosität des Unternehmens Google anzuzweifeln?

  2. Email-Daten sind prinzipiell nicht sicher; sie lassen sich an vielen Stellen scannen und werden gescannt, z.B. um Spam zu bekämpfen. Will man ausschließen, dass Emails von Dritten gelesen werden, muss man Programme wie Pretty Good Privacy zur Verschlüsselung verwenden. Die Verwendung solcher Verschlüsselungen ist zusammen mit Gmail möglich (ich habe sie noch nicht probiert). Anders gesagt: Wer vor Gmail Angst hat, sollte keine unverschlüsselten Emails versenden.

  3. Es besteht sicher ein nicht geringes Risiko, dass Google personenbezogenen Daten an Regierungsstellen und z.B. amerikanische Geheimdienste weitergibt. Googles Datenschutzbestimmungen schließen das nicht aus. Allerdings ist auch nicht auszuschließen, dass andere Emails von Geheimdiensten verwendet werden. Ich würde über Gmail nicht unverschlüsselt Informationen austauschen, die für Geheimdienste (und ihre Klienten, z.B. möglicherweise US-Unternehmen, die Wirtschaftsspionage betreiben) interessant sein könnten — wobei fraglich ist, ob Gmail dabei angesichts einer Vielzahl anderer Überwachungstechniken das oder auch nur ein Hauptrisiko darstellen würde. In meinem beruflichen Umfeld an einer steirischen Fachhochschule habe ich mit Geheimdienst-relevanten Informationen noch nicht zu tun geabt.

  4. Wer Gmail nicht toleriert, darf prinzipiell keine Speicherung von Daten außerhalb eines geschlossenen Systems zulassen, also z.B. auch nicht andere Webmail-Anbieter oder Amazon EC2. Das wäre weltfremd und reaktionär, es würde wohl bedeuten, auf moderne Web- und Internettechnologie überhaupt zu verzichten. Gmail im Arbeitsleben verlangt wie viele andere Technologien — vom Firmenlaptop, den man mit nach Hause nimmt, bis zum privaten Telefon, über das man dienstliche Gespräche führt — dass man es verantwortungsvoll benutzt. Davon muss eine Firma bei ihren Mitarbeitern ausgehen — und ganz sicher eine Hochschule bei ihren Lehrern.

Mein persönliches — sicher nicht ganz begründbares — Gefühl ist: Die Furcht vor Gmail ist wie andere Formen der Anti-Google-Hysterie Teil der amorphen Angst vor weiterer Modernisierung, dem Internet überhaupt und obskuren Kräften wie dem Neoliberalismus. Sie trägt zur Sicherheit der Benutzer nicht nachweisbar bei und erschwert es, über die wirklichen Risiken von Internettechnologien zu diskutieren. Ich lasse mich aber gern korrigieren.

Zwei neue Websites informieren über Werkzeuge für Onlinejournalisten: Tools for News und Journalists Toolkit. Beide füllen eine Lücke: Bisher ist es sehr schwierig, halbwegs darüber auf dem Laufenden zu bleiben, was im Onlinejournalismus technisch state of the art ist. Beide sind als work in progress angelegt: Das Journalists Toolkit liegt erst in einer frühen, noch nicht designten Beta-Version vor. Bei den Tools for News können sich alle Interessierten registrieren und die Seite ergänzen. Die Devise ist:

Don’t be a tool. Use one.

Die Tools for News sind ein Katalog von Werkzeugen für Onlinejournalisten, gegliedert nach Kategorien — von Audio bis Workflow. Das Journalists Toolkit ist eine Trainings-Site, die vor allem auf Tutorials hinweist. Es gibt weniger Kategorien als bei den Tools, die Gliederung ist aber ähnlich. Beide Sites ergänzen sich also: Die eine bietet Überblick und aktuelle Information, die andere Einführungen und hoffentlich bald auch Best Practice-Beispiele. Die Tools for News kann man als Feed abonnieren.

Hinter den Tools for News steht Chris Amico, der in seinem Blog beschreibt, wie er die Site entwickelt hat (mit dem Web-Framework Django, bei dem man Module sehr leicht wiederverwenden kann). Amico gehört zum Netzwerk Wired Journalists, das ich ebenfalls empfehlen möchte. Es entwickelt sich gerade zu einem der wichtigsten Diskussionsforen über Onlinejournalismus

Auf die Tools for News bin ich über Michael Thurms Bookmarks und Dirk von Gehlen. gestoßen. Leute wie Ryan Sholin und Matt Thompson sind von der Initiative begeistert.

Mindy McAdams betreibt das Journalists Toolkit. Sie lehrt seit 10 Jahren an der Universität von Florida Onlinejournalismus und teilt ihr Wissen in dem Blog Teaching Online Journalism, das nicht nur Lehrende dieses Faches lesen sollten.

Für deutschsprachige Journalisten und Studenten ist es leider noch nicht selbstverständlich, englische Websites zu verfolgen. Außerdem gibt es auch viele gute Tutorials und Einführungen für Onlinejournalisten in deutscher Sprache. Vielleicht lohnen sich deutsche Adaptionen?

In den letzten Wochen habe ich öfter über Linkjournalismus geschrieben. Der Ausdruck meint eine Methode — berichte, wo du dich auskennst, und linke auf den Rest! — und eine Haltung: verwende die Informationen, die du und deine Leser brauchen, und verweise auf ihre Urheber, auch wenn es deine Konkurrenten sind. Über Apture schreibe ich zugleich begeistert und skeptisch: Apture bietet enorme neue Möglichkeiten für den Linkjournalismus, kann aber auch benutzt werden, um die walled gardens der überkommenen Verlage vor den Stürmen des Webs und des Markts zu schützen.

Mit Apture kann eine Autorin einen Text einfach und wirkungsvoll mit Rich Media (Text, Bild, Audio, Video) ausstatten. Die Medien erscheinen in Popup-Fenstern, wenn der Benutzer mit ihnen verlinkte Textstellen überfährt. Sie stammen aus einem Pool aus frei zugänglichem Material, proprietäre Medien können hinzukommen.

Apture bei der BBC und der Washington Post

Die BBC hat Apture im Sommer auf ihrer News-Site getestet. Im Augenblick wird diskutiert, wie man weiter vorgehen will, und wie überhaupt auf den BBC-Seiten mit Links umgegangen werden soll. Am 8. Dezember gab die Washington Post bekannt, dass sie mit Apture zusammenarbeitet; sie will damit

offer readers a highly engaging way to view political data, congressional records, video, news and abstracts within a single washingtonpost.com browser experience. In addition, washingtonpost.com will make this data and content available to any blog or Web site that uses the Apture publishing platform [MarketWatch; dazu Only open news is good news – CNET News].

Andere Seiten, die Apture verwenden, können über die Washington Post auf dieselben Inhalte zugreifen.

Lawrence Lessig übernimmt in seinem Blog das Video, das zeigt, wir die Washington-Post mit Apture über den US-Kongress informiert. Es ist eine gute Einführung in die Technologie und ihre Möglichkeiten:

Ein Layer für Medien

Apture kommt den Bedürfnissen der Benutzerinnen wie der Autoren so sehr entgegen, dass man öfter leise wow sagt, wenn man es kennen lernt. Der Benutzer kann die Fenster vergrößern und verkleinern, er kann Serien von Medien durchblättern, zu bestimmten Stellen in Audios und Videos springen oder sich das Inhaltsverzeichnis eines Wikipedia-Artikels anzeigen lassen. Die Autorin installiert lediglich ein kleines JavaScript-Fragment — etwa als unsichtbares Widget in einem Weblog. Dann muss sie nur ein Wort markieren, und es erscheint ein Auswahlmenü für Medien. Apture durchsucht und verwendet Medien, die unter Creative Commons lizensiert sind. Eigene PDF-Dokumente kann man über Scribd hinzufügen. Man kann einen Text mit einer ausführlichen Dokumentation ausstatten, indem man auf mehrere Inhalte zugleich verweist. Bemerkenswert und so wohl einmalig: Apture-Authoring findet am fertigen Text außerhalb eines Content Management Systems statt. Da Apture ein eigenes Layer bildet, kann man seine Texte zur wikiartigen Bearbeitung durch andere Apture-Benutzer freigeben.

Die für mich beste Beschreibung der Möglichkeiten Aptures stammt von Ben Metcalfe, der zu Aptures board of advisors gehört. Wie Apture funktioniert, erfährt man im Apture Wiki. Allerdings gibt es dort nur wenig technische Informationen. Robin Good führt gründlich in Apture ein

Man kann Apture an- und abschalten, die Texte selbst werden durch Apture nicht verändert, sie erhalten lediglich ein zusätzliches Layer. Das erlaubt es, sie so anzulegen, dass sie auch ohne die Ergänzung durch Apture funktionieren — ein Muss unter Usability- und Accessibility-Gesichtspunkten. (Unter dieser Perspektive beschäftige ich mich hier nicht mit Apture, sie spielt wohl bei der Diskussion in der BBC eine wichtige Rolle.) Die Apture-Links können dynamisch sein und auf Material verweisen, das jeweils aktuell gesucht wird.

Hoffnung für Verleger?

Apture lässt sich mit jedem gängigen Blogging-Tool zusammen verwenden. Entworfen wurde es sowohl für Bloggerinnen wie für Verlage. Blogger müssen für Apture nichts bezahlen; Apture will Geld verdienen, indem es an den Werbeerlösen von Publikationen beteiligt wird, die Apture verwenden. Für Verlage ist an Apture attraktiv — und das ist eine seiner problematischen Seiten — dass die User auf den mit Medien ausgestatteten Seiten bleiben und nicht durch Links zu anderen Angeboten geschickt werden. Das Apture-Marketing nährt den Pfeifentraum der Medienhäuser, alle Inhalte aus einer Hand anzubieten. Die Praxis wird zeigen, ob Apture die Vernetzung und damit den Linkjournalismus unterstützen wird oder das Abschotten von Inhalten.

Ich habe noch nie etwas zu Twitter geschrieben, weil mir dazu nie etwas Interessantes eingefallen ist. Währenddessen häufen sich in meinen ungelesenen starred items und meiner Read It Later-Liste Texte über Twitter. Ein paar meiner Studis und Kollegen sind sehr erfolgreiche Twitterer, und viele sind von Twitter begeistert. Hier ein paar erste Bemerkungen zu Twitter bzw. zum Microblogging (ich verwende die Ausdrücke synonym). Sie gehören in eine Materialsammlung zu den Formen der Webkommunikation (und sind weder inhaltlich noch stilistisch ausgereift).
Ich finde, fast alle Texte über Twitter, die nicht einfach Tools beschreiben, haben etwas gemeinsam: Sie schreiben, wie man Twitter für das nutzt, was die Autorin auch schon am meisten interessiert hat, bevor es Twitter gab — dabei kann es sich um Marketing, Journalismus, PR, Wissensaustausch oder Celebrity Gossip handeln. Je mehr ich über Twitter nachdenke, desto mehr finde ich: Die Frage: Welchen Sinn hat Twitter? hat keinen Sinn. Twitter ist kein Werkzeug, sondern eine Kommunikationsform. Und wie Kommunikation selbst haben auch Kommunikationsformen wohl keinen höheren Zweck — oder sehr viele unterschiedliche Zwecke, die immer wieder neu besprochen, ausgehandelt und festgelegt werden, während man kommuniziert. Mit Twitter kann man twittern, so wie man mit einem Telefon telefonieren, oder mit einem Blog bloggen kann.

Punkte, die mir bei Twitter wichtig sind:

  1. Twittern/Microblogging ist ein eigenes Format der Webkommunikation, das nicht durch andere Formen (z.B. Blogs, Wikis) ersetzbar ist, aber mit ihnen verglichen werden kann.
  2. Twitter erlaubt es offenen Gruppen von Menschen (und auch Services) im Web, sich zu beobachten und zu kommunizieren, und erleichtert es ihnen damit, sich zu organisieren.
  3. Twitter ist ein Teil des Webs. Twitter kann damit die Möglichkeiten des Webs und der Webkommunikation nutzen und ist für andere Formen der Webkommunikation einschließlich aller technischen Erweiterungen direkt anschlussfähig.
  4. Man twittert in der Öffentlichkeit des Webs; Twittern ist eine Publikationsform und eine Option für jeden, der im Web publiziert.

Weblogs — Twitter — Wikis

Vom Bloggen unterscheidet sich Twittern u.a. dadurch,

  • dass es in Echtzeit beobachtet wird,
  • dass Twitterer ihre Follower kennen, und
  • dass man mehrere oder viele Twitterer gleichzeitig beobachtet.

Wie das Bloggen ist Twittern aber eine hypertextuelle Gattung. Es ist also auch asynchron beobachtbar, und jede Äußerung ist verlinkbar, so dass man immer wieder an sie anschließen kann. Der Übergang zwischen Twittern und Bloggen ist fließend — man kann ohne Follower twittern, und man kann Twitterer im Web beobachten, ohne sich bei dem Service anzumelden. Aber das Besondere an Twitter besteht darin, dass man anderen ohne einen zwischengeschalteten Service (wie einen Feedreader) in Echtzeit folgt, und dass man weiß, wer einem selbst folgt.
Mit dem Schreiben in Wikis hat Microblogging auf den ersten Blick wenig gemeinsam, aber auch bei Twitter arbeiten viele Autoren zusammen an Seiten, und wie in einem Wiki kann man sehr leicht zwischen den Seiten navigieren. Wie
Wikis macht es auch Twitter so leicht wie nur möglich mitzumachen. Es gibt (Hashtags, @-Syntax) sogar etwas wie ein spezielles Markup. Während bei einem Wiki Wissen zusammengestellt wird und damit etwas Dauerhaftes entsteht (das aber trotzdem von einer Community getragen und geschützt werden muss, wie es für die Wikipedia Clay Shirky beschreibt), erfährt man bei Twitter, was gerade los ist. Wikis wurden von vielen für etwas Absurdes gehalten, bis dann die Wikipedia gezeigt hat, was mit diesem Format möglich ist. Genauso hielten und halten viele Twitter für sinnlos. Möglicherweise werden sie erleben, dass Twitter alles, was mit Nachrichten zu tun hat, so revolutioniert wie es die Wikis mit dem Wissensaustausch getan haben und tun.

Many to many

Am interessantesten erscheint mir bei Twitter, dass damit viele mit vielen kommunizieren können. Das wird nicht durch das Subskribieren von Twitterern ermöglicht, sondern durch die Beschränkung der Länge der Tweets auf 140 Zeichen. Man twittert immer in eine Wolke von Menschen hinein. Ein Menge von Botschaften unterschiedlicher Sprecher tritt an die Stelle von Monologen oder Dialogen.
Mit Twitter wird eine andere Form von Community oder Gruppe möglich als durch Wikis (zielgerichtete Kollaboration) oder Blogs (Gedanken- und Erfahrungsaustausch). Durch Twitternachrichten lässt sich eine Webcommunity permanent beobachten. Vielleicht ist das der Kern des Phänomens: Twitter gibt Communities im Weg die Möglichkeit, sich in Echtzeit zu wahrzunehmen. Dabei ist der Austausch synchron und asynchron ohne Medienbruch für andere Webteilnehmer prinzipiell offen; das unterscheidet Twitter von Gruppenchats oder dem Austausch in social networks.

Anschlusskommunikation

Twitter erlaubt einen unmittelbaren, interaktiven Umgang mit Echtzeitkommunikation über die unmittelbare Kommunikationssituation hinaus. Es macht Echtzeitkommunikation im Web anschlussfähig, weil sie direkt im Web beobachtbar und adressierbar ist. Man kann auf Tweets verlinken, man kann Streams von Tweets in Widgets zeigen, und man kann sie mit den verschiedensten Tools auswerten bzw. für Mashups verwenden. Vielleicht kann man sagen: Twittern erschließt für das Web eine Kommunikationsform, die vorher zwar im Internet (seit dem IRC) aber nur außerhalb des Webs möglich war. Damit erschließt es umgekehrt für die Echtzeitkommunition die Vielfalt der Möglichkeiten des Webs.

Twittern als Publikationsform

Wenn man twittert, statt zu chatten, begibt man sich in die Öffentlichkeit des Webs (auch wenn sich diese Öffentlichkeit einschränken lässt, indem man seine Tweets nur Followern zugänglich macht, die man vorher akzeptiert). Noch mehr als andere Formen der Webkommunikation ist dabei Twittern writing as a performing art. Twittern hat nur da einen Sinn, wo man die Vorteile des Webs benötigt, z.B. Verlinkbarkeit von Informationen, Zugänglichkeit für eine große, potenziell unbeschränkte Öffentlichkeit und Kombinierbarkeit von verschiedenen Medien. Wenn Twittern nicht nur eine Kuriosität ist, sondern eine der wichtgen Kommunikationsformen im Web, ist es damit eine ständigen Option für alle, die im Web publizieren. Wo immer öffentliche Information in Echtzeit (und am besten durch mehrere Autoren) sinnvoll ist, stellt sich die Frage, warum man nicht einfach twittert.

In die rechte Kolumne von Lost and Found habe ich unter Tips ein Linkblog eingefügt. Gemacht ist das Linkblog mit Publish2 (Blog hier), einem Service für Journalisten zum Sammeln und Austauschen von Links. Ins Leben gerufen hat ihn Scott Karp, der in seinem Blog Publishing 2.0 den Link-Journalismus ausgerufen hat und promotet. Publish2 hat die meisten Funktionen von Delicious und erlaubt es, Links auch an Delicious zu posten. (Was ich tue, denn für mich bleibt Delicious das wichtigste Werkzeug, um Informationen zu sammeln.)

Publish2 enthält aber auch Funktionen, die delicious nicht bietet, und die die Recherche und das Publizieren erleichtern. So kann man bei demselben Link private und öffentliche Notizen machen. In eigenen Feldern können das Veröffentlichungsdatum und die Quelle festgehalten werden. Außerdem gibt es drei Kategorien von Bookmarks: außer denen für die Publikation von Links kann man welche für laufende Recherchen und für Hinweise auf eigene Publikationen anlegen. Außer an Delicious lassen sich Links auch an Twitter schicken, wahlweise mit eigenem Text oder dem öffentlichen Kommentar für die Linksammlung.

Wichtigstes Arbeitsmittel ist ein Bookmarklet. Wie es funktioniert, habe ich in einem Screencast festgehalten:

Link: Das publish2-Bookmarklet

Die Linksammlung jedes Benutzers ist auf einer Seite erreichbar; dort können die Links ausgetauscht und auch kommentiert werden. (Meine Publish2-Links sind außer in diesem Blog hier zu finden. Ein RSS-Feed kann hier über Feedburner abonniert werden.) Über diese Linksammlung kann man sich mit wenigen Klicks ein Widget erstellen, das man als Linkblog in sein Blog einbauen kann.

Publish2 integriert das Sammeln von Links in den journalistischen Workflow, und zwar in einer webgemäßen Weise, bei der Informationen auf allen Bearbeitungsstufen geteilt werden. Es gehört so in eine Reihe mit anderen Netzwerken für Journalisten, die verteiltes gemeinsames Arbeiten im Web erlauben, z.B. Wired Journalists.

Der Offenheit des Web 2.0 widerspricht, dass man zugelassen werden muss, wenn man Publish2 verwenden will. Es wird gecheckt, ob man entprechend professsionellen Standards arbeitet — für mich riecht das etwas nach Korporatismus. Ich fände es besser, wenn man sich innerhalb des Service ein Netzwerk von Vertrauenspersonen aufbauen könnte, statt gleich am Eingang geprüft zu werden. Allerdings hat die Bestätigung meines Accounts nur eine Stunde gedauert (als media outlet habe ich mein Blog angegeben) und ich freue mich, an dieser Initiative teilnehmen zu können.

Haben FriendFeed, Disqus und seesmic etwas gemeinsam? Mir kommen sie wie die nächste Generation von Social Media Tools vor. Auf verschiedene Art sind sie Plattformen für Kommentare und Dialoge — wobei FriendFeed zugleich als Aggregator und seesmic als Videopublikationsplattform funktioniert. Wie ältere Dienste sind sie Publikations- oder Aggregationswerkzeuge für Microcontent, aber weit besser zeigen und ermöglichen sie Beziehungen zwischen (Mikro-)Inhalten. Seesmic gehört vielleicht als Plattform für eine bestimmte Form von Inhalten, nämlich kurze Videos, nicht in dieselbe Kategorie wie die beiden anderen. Aber auch bei seesmic ist nicht das Format wichtig, sondern die Verbindung, der thread, und interessant ist seesmic vor allem als Instrument für Videokommentare. Alle drei sind so entworfen, dass sie so gut wie möglich mit anderen Plattformen und Services zusammenspielen.

Seit dem Schlüsselsatz des Cluetrain Manifests markets are conversations wird wahrscheinlich kein Wort so oft benutzt wie conversation, um auszudrücken, was Webkommunikation von den älteren Medien unterscheidet. Aber erst jetzt werden Tools entwickelt, die der Konversation im Web den Vorrang vor ihren Bestandteilen wie Blogeinträgen und Kommentaren geben.

Vor einer Stunde habe ich mich bei Utterz angemeldet (thx Boris!). Es ist, österreichisch gesagt, blunzen-einfach, damit Audios (und Videos) zu produzieren und im Web zu veröffentlichen. Für meine eigenen Utters habe ich im Sidebar von Lost and Found ein Widget eingebaut.

Utterz ist vor allem ein Tool für Mobiltelefone. In den USA und einer ganzen Reihe anderer Länder kann man Audios und Videos mit dem Mobiltelefon aufnehmen und über eine spezielle Nummer direkt an Utterz posten. Mit einem ganzen Arsenal von Widgets lassen sie sich dann weiter publizieren, zum Beispiel in Weblogs. Sie lassen sich taggen, und es gibt die üblichen Social-Network-Features. Podcasting als Convenience.

Genau so einfach ist es, Audios oder Videos mit einem Computer aufzunehmen oder auch upzuloaden. Das Interface ist Flash-basiert und selbsterklärend.

Ich habe es noch nicht ausprobiert, aber es scheint auch sehr leicht zu sein, Audios mit Bildern zu begleiten. Hier, wie auch bei den anderen Features von Utterz, merkt man, dass der Dienst tatsächlich durchdacht ist.

Zu publizieren kostet nichts. Als Benutzer gibt man Utterz the perpetual, irrevocable, non-exclusive, sublicensable right to display that content in any form on any Utterz Service (whether by phone or over the internet) or anywhere else, without limitation.. Das ist natürlich problematisch; man kann nur hoffen, oder besser: man sollte daran arbeiten, dass auch nichtkommerzielle Versionen solcher Dienste ins Leben gerufen werden.

Utterz finanziert zur Zeit offenbar durch Verträge mit Telefongesellschaften. Sie zahlen, damit ihre Netze noch intensiver genutzt werden. Wirklich kostenlos ist der Service also nicht.

Ich werde Utterz sicher weiter beobachten. Es ist gut vorstellbar, dass Google bald einen ähnlichen Service anbietet. Interessant finde ich, dass die technische Seite des Publizierens durch solche Dienste regelrecht trivialisiert wird. Für Blogger stellt sich damit die Frage, was man besser schreibt und was man besser sagt — bis Upperz & Co die Audio-Postings automatisch verschriftlichen.

Am Wochenende habe ich mich etwas mit Zotero beschäftigt, auf das mich Julian gebracht hat, der es für seine Diplomarbeit benutzt. Mit Zotero kann man Lesezeichen, Verweise und Notizen organisieren. Es läuft als Firefox-Addon und ist mit dem Browser sehr gut integriert. Man kann es ähnlich verwenden wie das Delicious Bookmarks Addon, man speichert aber nicht nur URLs, sondern komplette bibliographische Angaben. Die Verweise lassen sich hierarchisch ordnen, taggen, miteinander verknüpfen oder mit Anhängen versehen. Zotero verwaltet komplette Snapshots von Web-Dokumenten. Das alles geschieht lokal auf dem Rechner, auf dem Zotero installiert ist; dabei arbeitet Zotero übrigens mit einer SQLite-Datenbank.

Weiterlesen

Zum ersten Mal ein Buch in meine Bibliothek bei Google Books gestellt. Ich wusste nicht, dass es diese Funktion gibt. Wirkt sehr brauchbar — und macht Google wieder etwas mächtiger.

PS: Bei den meisten Büchern lassen sich nur Informationen über ein Buch speichern, einige kann man aber komplett lesen. Notiz an mich selbst: Gibt es ein Tutorial über das Bibliographieren mit Web-Tools? Lohnt es sich, eines zu schreiben? Kann man Google Books und BibSonomy zusammen benutzen?

Ich komme schon seit Wochen nicht mehr zum Bloggen, weil ich ein paar Projekte zuendebringen muss, bevor ich richtig ins neue Jahr starten kann. (Leider ist es nicht meine Stärke, Dinge abzuschließen.) Dabei arbeite ich mit Plone und mit Drupal. Ich frage mich manchmal, wie ein Vergleich dieser beiden Content Management Systeme aussehen würde.

Ich würde es — aus der Perspektive eines technisch interessierten Users, nicht eines Entwicklers — so sagen: Man kann mit Plone mehr anfangen, aber die Eintrittsschwelle liegt deutlich höher. Für Websites, bei denen man die Systeme einfach out-of-the-box verwenden kann, spielen die Unterschiede keine große Rolle. Wenn man aber eigene Inhaltstypen entwickeln und das Layout der Seiten kontrollieren möchte, unterscheiden sich die Systeme deutlich. Die Lernkurve bei Drupal ist viel flacher, führt aber wahrscheinlich auch nicht so hoch wie bei Plone.

Für mich ist vor allem interessant, wie schwierig es ist, neue Inhaltstypen zu entwickeln, und wie aufwändig es ist, Layouts anzupassen oder zu erstellen. Bei Drupal benutze ich dazu das Content Construction Kit. Damit ist es relativ einfach, Inhaltstypen zu erstellen, die aus verschiedenen Feldern bestehen. Man klickt sie sich im Grunde zusammen. Für Daten oder Feldtypen, die der Drupal-Kern nicht anbietet, z.B. für Bilder, kann man zusätzliche Module installieren. Um den Inhalt in Listen darzustellen, z.B. auf Überblicksseiten, benutzt man das Modul Views, bei dem man mit einer Art wizard Abfragen an die Datenbank erstellt, mit denen man die gewünschten Inhalte zusammenstellt. Für das Layout erstellt oder verändert man Templates; dabei präsentiert einem das Modul Contemplate die Variablen, über die man die Inhalte in das Template einfließen lässt. Für Leute die Angst vor Code haben, ist das zwar nicht geeignet, man braucht aber keine Kenntnisse in PHP (der Sprache, in der Drupal geschrieben) ist.

Ein Problem bei Drupal: Es gibt eine Vielzahl von Modulen, mit denen sich der bewusst schmal gehaltene Funktionsumfang des Drupal-Kerns erweitern lässt; und man braucht Zeit und vielleicht auch etwas Gespür um herauszubekommen, wie ausgereift die Module sind. Was die Module dabei in der Datenbank verändern, sieht man als Drupal-User nicht. Wahrscheinlich ist die beste Strategie, mit so wenig Modulen wie möglich auszukommen und bei denen, die man wirklich braucht, via Google herauszukriegen, welche Erfahrungen andere mit ihnen gemacht haben. Ich bin z.B. erst nach einiger Zeit darauf gekommen, dass man für Bilder in unterschiedlichen Größen wohl besser das Modul ImageCache als das gängigere Modul Image verwendet.

Bei Plone ist es nicht unbedingt schwieriger, neue Inhaltstypen zu erstellen, allerdings muss man entweder in den Python-Code eingreifen oder mit der Unified Modelling Language (UML) arbeiten — was sich anspruchsvoller anhört, als es nach meinen ersten Erfahrungen ist. Inhaltstypen bei Plone werden als so genannte Archetypes angelegt. Wenn man einen nicht bereits vorhandenen Inhaltstyp braucht — bei mir geht es um eine Datenbank mit Beschreibungen historischer Darstellungen des Fürstentums Anhalt — muss man entweder einen Archetype neu schreiben oder ihn mit einem UML-Tool entwickeln und den Code generieren lassen. Wenn ich es richtig sehe, ist der zweite Weg der übliche. Ich habe ArgoUML als UML-Software installiert; außerdem braucht man das Pytonmodul ArchGenXML, das aus einem als XML exportierten UML-Schema den Archetype bzw. mehrere aufeinander bezogene Archetypes produziert. Was einem UML und ArchGenXML leider nicht abnehmen, ist die Erstellung der Templates für die Oberfläche. Nach den Erfahrungen, die ich mit einem älteren Prototyp meines Projekts gemacht habe, muss man dazu die Zope-eigenen Template-Sprachen TAL und METAL verwenden. Was sich bei Plone 3, der neuesten Plone-Version verändert hat, kann ich noch nicht sagen.

Ich mache gerade zum ersten Mal Bekanntschaft mit einem UML-Tool und bin davon ziemlich fasziniert (wobei ich nur ein Minimum an UML verwende). Man kann mit UML — so weit bin ich allerdings noch nicht — auch ganze Workflows für Plone-Applikationen entwerfen und den Code automatisch erzeugen lassen. Ich vermute, dass dabei dann erst die eigentlichen Stärken von Plone zum Tragen kommen.

Was würde ich antworten, wenn mich jemand fragt, ob sie für ein Projekt Drupal oder Plone benutzen soll? Uns stellt sich das Problem gerade an der FH, wo eine neue Website für die Design-Studiengänge entwickelt wird (an die sich die in den Wirtschaftsfachbereich verbannten Journalisten hoffentlich anschließen dürfen). Ich würde — wie wahrscheinlich jeder andere auch — zuerst sagen, dass es auf das Projekt ankommt. Wenn die Sicherheitsarchitektur und Workflows eine grosse Rolle spielen, dürfte Zope/Plone das stärkere System sein. Wenn es allerdings um eine normale Content-Site geht, würde ich die Entscheidung vor allem davon abhängig machen, wer die Site entwickelt. Stehen wirklich Coder zur Verfügung, die sich außerdem etwas mit Python auskennen (der Programmiersprache, in der Plone geschrieben ist), dürfte es letztlich einfacher sein, mit Plone zu arbeiten. Wenn es darum geht, mit etwas Grundwissen eine dynamische Website auf die Beine zu stellen (vor allem eine Community-orientierte), dann ist wohl eher Drupal zu empfehlen. Außerdem hat Drupal den Vorteil, dass PHP- und MySQL-Knowhow relativ weit verbreitet ist, während Python leider immer noch zu unbekannt ist, obwohl es — finde ich — die Programmiersprache für Nichtprogrammierer sein könnte.

Da ich nicht Coder unterrichte, sondern Journalistinnen und PR-Leute, frage ich mich natürlich auch, ob ich mich gerade in Dinge versteige, die mit meinem Job nichts mehr zu tun haben. Es klingt vielleicht abstrus: Aber für den Unterricht kann ich möglicherweise am ehesten UML verwenden. Ich könnte mir vorstellen, dass man damit auch Nichttechniker sehr gut in die Entwicklug von Websites/Webapplikationen einführen kann — aber das ist ein anderes Thema.

(PS: Ich bin auf diesem Gebiet noch mehr Dilettant als auf einigen anderen. Ich bitte also um Korrekturen, wenn ich Unsinn geschrieben habe.)