Als Projektleiter e-Publishing arbeiten Sie an der Schnittstelle zwischen Technologie und Redaktion – sowohl in Kundenprojekten als auch bei der Weiterentwicklung der e-Publishing Suite.

Gegenüber unseren Kunden (beispielsweise Tageszeitungen, Magazinen oder Unternehmen) agieren Sie als zentraler Ansprechpartner in allen Projektphasen. Sie unterstützen und beraten Kunden hinsichtlich inhaltlicher und technischer Fragen. Im Rahmen der Umsetzung steuern Sie Projekte organisatorisch und inhaltlich und koordinieren dabei alle beteiligten Parteien. Im täglichen Betrieb bewerten, kanalisieren und beantworten Sie Kundenanfragen aller Art. Technische Probleme lösen Sie selbst oder in Kooperation mit der Entwicklung. Darüber hinaus wirken Sie an der übergreifenden Produktentwicklung mit und vertreten hierbei insbesondere die Perspektive unserer Kunden.

Sie sind idealerweise Informatiker (o.ä.) und haben schon einige Jahre bei einem Medienunternehmen im Bereich Web-Entwicklung gearbeitet und gemeinsame Projekte mit der Redaktion geleitet. Die sichere Beherrschung moderner Web-Frameworks (Django, RoR, jQuery, node, … ) ist für Sie genauso selbstverständlich wie das Interesse daran, sich fortlaufend in diesem Bereich weiterzubilden. Auch XML und XSLT sind ihnen vertraut, und Sie schrecken auch nicht davor zurück, sich in die native Entwicklung von Apps für iOS und Android einzuarbeiten.

Alternativ haben Sie längere Zeit als (Entwicklungs-)Redakteur bei der Konzeption und Realisierung neuer digitaler Angebote mitgearbeitet. Um Prototypen zu realisieren greifen Sie ggf. zum Text-Editor, schreiben fließend HTML5 und checken das Ergebnis in ein Repository ein. Sie können sich gut vorstellen, noch tiefer in den “Maschinenraum” der Technik zu gehen, um zu verstehen was dort passiert. Evtl. haben Sie dabei schon eigene Programmiererfahrungen (z.B. im Bereich Datenjournalismus) gesammelt, oder sind daran interessiert sich in diesem Bereich weiterzubilden.

Bei Interesse schicken Sie bitte Ihre aussagekräftigen Bewerbungsunterlagen mit Angabe Ihres Gehaltswunsches und des frühestmöglichen Eintrittstermins richten Sie bitte an:

gerd.kamp (at) dpa-info.com

Stellenanzeige Projektleiter (PDF)

The original plan was to publish some  background information on our e-Publishing approach along with the launch of the App. Well that didn’t happen, we were just too busy. But now we’ve finally found some time and this post is the start to a little series.

iWimpff: The comic

Obviously the client component (code named iWimpff) is an essential part of the suite. And the most visible one.

In order to explain the  motivation and rationale  behind the client framework to a broader audience we decided to take advantage of the fact that Benjamin Rabe, the teams graphic designer, is also an avid fingerpainter.

So we had a little bit of fun and produced an introductory comic (already back in January /February):

[Show as slideshow]

(There are also PDFs of the whole comic available for download in english and german)

For those more interested in the hard facts, these are elaborated in upcoming blog posts. For now: iWimpff is based on the idea / goal of a zig-zag inspired generic content rendering framework. Basically it is a two-dimensional browser that implements four additional implicit links (prev-x, next-x, prev-y, next-y) and uses web-technology (HTML5, CSS3, Javascript) whenever feasible  and or technically possible and resorts to native implementations only when necessary (e.g. because of processor speed and memory constraints)

It is supposed to enable more print-centric content renditions (e.g. multiple columns, paging) as well as more online-centric renditions (e.g. single column and scrolling).

Right now there are two apps based on the iWimpff in production: “Schwäbische Zeitung”  is the app of a german regional newspaper in south west germany.  It is using a print-centrix approach and even includes a viewer for the PDFs  of the print.

The other, an app for the executives of Daimler AG is a pure B2B app and hence not available in the AppStore.

Your feedback please

I was able to show off  various prototypes and release candidates to (IMHO very knowledgeable) people of both sides of the pond. Generally the feedback was very positive and the even the prototypes were graded as one of the best solutions seen so far.  So go and download “Schwäbische Zeitung” (iTunes Link) grab a couple of free editions (or buy some) , have a closer look and tell us what you think.

We are in general very interested to present and  discuss our ideas with as many people as possible. Feel free to comment, to send an email to newslab@dpa-info.com or a DM @dpa_newslab.  And if you think that a presentation of our approach would fit into the schedule of a certain conference, please tell us and we’ll see if we can make it happen.

Es geht um den Mindener Handball-Zweitligisten Grün-Weiß Dankersen. Neben aktuellen Vereinsnachrichten aus der Zeitung enthält die App Spielberichte, Telegramme, umfangreiche Statistikdaten, Kurzvorstellungen aller Spieler und Ligagegner sowie einen Liveticker: also alles, was ein Fan braucht. Die App kostet einmalig 3,99 EUR und gilt für die gesamte, am Wochenende startende Saison.

Was ist an dem Projekt spannend? Wir freuen uns, mit einem Verlag ein gemeinsames Projekt umzusetzen, bei dem es einmal nicht um die Zeitung als ganzes, sondern um ein für die Region interessantes Thema geht: Der GWD Minden verfügt über eine große und treue Fangemeinde.

Die größte Herausforderung war im Projekt nicht die Darstellung in der App selbst, sondern die Zusammenführung der Daten aus sehr unterschiedlichen Quellen. Ein Teil der Daten stammt aus dem Print-Redaktionssystem der Mindener (alfa). Spielplan und Tabellen stammen aus dpa-SportsData, dem dpa-Angebot für Sportdaten. Der Liveticker wird wiederum als XML-Feed von der Handball-Bundesliga  bereit gestellt. Und schließlich musste ein pragmatischer Weg gefunden werden, aktuelle Vereinsstatistiken, die für das in Quark-produzierte Hallenheft erfasst werden, am Redaktionssystem vorbei in die App zu bringen.

Bereitgestellt werden all diese Daten dann als ATOM-Feeds, die dann in der App, einem von uns entwickelten leicht konfigurier- und anpassbarem Feedreader dargestellt werden.

Zur GWD-App im App Store: http://bit.ly/nEJkWZ

That means that posts that might be of relevance outside germany  will from now on be written in english and tagged with an additional tag  ”english”. Posts mainly targeting a german audience will still be written in german.

Leider können weder Oliver Reichenstein noch Aron Pilhofer an dem  Hackathon teilnehmen. Aron muss am 30. morgens zurück nach New York um die “Midterm Elections” weiter vorzubereiten, Oliver muss sogar schon am 29. Abends weiter. Aber auch ohne die beiden wird es sicher wieder ein spannender Tag.

Nachdem letztes Jahr Mindmatters freundlicherweise seine Büros für den Hackathon zur Verfügung gestellt hatte, wird er dieses Jahr in den Räumen des  neugegründeteten (und sehr ansehnlichen) Betahaus Hamburg stattfinden.

Wir beginnen gegen 10Uhr . Da nur um die 40 Plätze zur Verfügung stehen, müssen wir wissen wer alles kommen will. Daher kann man sich hier kostenlos anmelden.

Themen

Nachdem wir letztes Jahr  quasi bei Null angefangen hatten und  mit einer komplett offenen Vorschlagsrunde für Themen angefangen haben, starten wir dieses Jahr ein klein wenig  anders. Wir haben jetzt schon ein paar Themenvorschläge vorbereitet, die wir am Anfang vorstellen wollen. Für jedes dieser Themen wird es einen Experten/Paten geben, der das Thema über den Tag hinweg betreut (sofern es denn geügend Leute interessant finden). Natürlich können weitere Themen vorgeschlagen werden, umso früher umso besser.

Folgende Themen sind es bisher:

1. NewsAktuell wird Ihre Presseportal API vorstellen und dabei helfen diese zu benutzen und in Projekte zu integrieren.
2. Georgi Kobilarov von Uberblic Labs (uberblic.com) und Organisator des grandiosen Web Of Data Berlin Meetups am Mittwoch (an dem ich auch einen Vortrag halten durfte) wird das Thema Linked Open Data und die Uberblic Plattform vorstellen und hat als Idee die Aggregation und Analyse von öffentlichen Daten zu Personen und Firmen, die in einen Skandal verwickelt sind / waren, mitgebracht. Ziel ist es herauszufinden, ob man den Skandal anhand dieser Daten hätte vorhersehen können. Bin mal gespannt ob er einen bestimmten Skandal vor Augen hat.
3. Moritz Stefaner der sich für / mit dem newslab  mit dem Thema Visualierung der Daten unseres experimentellen GeoBackends beschäftigt hat ist auch da. Er stellt das Thema FacetBrowsing/Faceted Search vor und hilft gerne insbesondere bei der Verwendung der von ihm entwickelten ElasticLists, die seit einiger Zeit auch open-sourced sind. Aber auch generelle Fragen / Ideen zum Thema Infoviz allgemein und/oder Processing und Protovis sind bei ihm gut aufgehoben.
4. Um  die Umsetzung der Infovis Ideen zu erleichtern aber auch um generell damit experimentieren zu können, werden wir die Geobackend API für den Zeitraum des Hackathon aufmachen.  Gerne diskutieren wir auch das API Design  und mögliche resp. notwendige neue Features und Erweiterungen.
5. Nicht zuletzt wollen wir die Überlegungen zur Informationsarchitektur und dem Design unserer in Entwicklung befindlichen iPad-App (sowie den aktuellen Entwicklungsstand) vorstellen und mit euch darüber diskutieren wie sinnig oder unsinnig  manche Enscheidungen waren  oder sind).
6. Wie einfach es ist, das sich von uns ausgedachte,  HTML5-basierte, Eingangsformat aus existierenden Inhalten und Systemen heraus zu erzeugen. Und was sollte man daran evtl. ändern um es einfacher zu machen?

Auf dem Web of  Data Meetup wurde als Antwort auf die Frage: “Warum Denn in  Deutschland der Datenjournalismus so weit  hinter den USA und UK zurückhängt” der Vorschlag gemacht  doch  mit  Hacks & Hackers Meetings zu beginnen. Letztes Jahr war der Hackathon eher mit 80% Hackers und 20% Hacks besetzt.

Die Themen 2,3, und 5 sind bewusst so angelegt, dass sie auch für Journalisten / Hacks interessant sein sollten und von deren aktiver Beteiligung enorm profitieren können:

• Wie sehen die Recherchestrategien bei 2 aus,
• Welche Visualiserungen sind denn aus sicht der Recherche / Analyse und aus Sicht der Darstellung für den Leser besonders interessant,
• Wieviel Print- und Online sollen in den Inhalten und im Interaktionsdesign einer iPad App für eine (regionale) Zeitung stecken? Wie unterscheidet sich das für die verschiedenen (möglichen) Zielgruppen?

Also: Kein Grund für Hacks und Hackettes dem Hackathon fernzubleiben.

In diesem Post geht es darum, earum ich die beiden diesjährigen Keynotespeaker ganz besonders spannend finde. In einem weiteren Blogpost gibt es dann Details zum Scoopcamp Hackathon, den ich (@gkamp) wieder zusammen mit Wolfgang Wopperer ( @wowo101 ) und neu: Klaus-Peter Frahm (@menotti) organisiere. Für diejenigen, die auch ohen Details wissen, dass der Hackathon sich lohnt: Hier könnt ihr euch für den Hackathon anmelden.

Doch jetzt zu den Keynote Speakern und ihren Vorträgen:

Aron Pilhofer: Beautiful data – state of the art approaches to journalistic research and interactive storytelling

Nachdem es mir letzten Jahr gelungen war Adrian Holovaty als Keynotespeaker zu gewinnen, freue ich mich dieses Jahr darüber, dass Aron Pilhofer von der New York Times kommen kann. Am liebsten hätte ich schon letztes Jahr gerne beide gehabt, aber a) konnte Aron nicht und b) hätte es das Bidget vielleicht auch nicht hergegeben. Um so schöner, dass es dieses Jahr klappt.

Ich hatte die Gelegenheit Aron im letzten Jahr in Verbindung mit einem Konferenzbesuch in New York zu treffen und finde er hat einen der spannendsten Jobs den man sich in unserer Branche vorstellen kann: Er ist Editor Interactive Newsroom Technologies für nytimes.com. Das heisst, dass er und sein Team als Teil der Redaktion im Newsroom angesiedelt sind und von dort aus die ganzen interaktiven Elemente und Sonderprojekte auf nytimes.com realisieren.

Das Team  von Aron ( @pilhofer ) besteht  aus Webentwicklern,  Information Architects,  Graphikern etc., die ihre Lösungen im grossen und ganzen unabhängig von der “Standard-IT” von Grund auf selbst entwickeln. Meistens auf Basis “neuer” Webtechnologien und OpenSource Software, also RoR, MySQL und  NoSQL-DBs etc. Gehostet wird das ganze unter Ubuntu  in der Cloud.  Für ihre interaktiven Graphiken und Karten setzen sie (zur Zeit noch) auf Flash, wobei sie hier auch ihre eigenen Frameworks einsetzen. Insbesondere im Bereich Karten haben sie mit Matthew Bloch einen der Besten seiner Zunft.

Einen Eindruck von der Arbeit des Teams kann man sich zum Beispiel anhand der im November stattfindenden Mid-term Elections machen, die schon jetzt sehr intensiv mit den Ergebnissen der Vorwahlen,Vorhersagen etc. begleitet werden. Aber auch die letze Präsidentschaftswahl,  die letzte Sommerolympiade oder die letzte Winterolympiade sind gute Beispiele.

Ein nicht mehr ganz taufrisches, aber immer noch sehr gutes Interview mit Aron findet man hier. Auf seinem Vortrag mit dem Titel: “Beautiful data – state of the art approaches to journalistic research and interactive storytelling” wird er das ganze bestimmt noch an viel mehr Beispielen erläutern.

Document Cloud

Neben seiner Arbeit bei der NYTimes ist Aron auch in einem der spannendsten, von der Knight Foundation geförderten Projekte involviert, das die NYTimes zusammen mit ProPublica realisiert: DocumentCloud.

DocumentCloud is an index of primary source documents and a tool for annotating, organizing and publishing them on the web.

Aron wird in seinem Vortrag wohl eher nicht auf Document Cloud, das zur Zeit von ca zwei Dutzend amerikanischen Nachrichtenorganisationen getestet wird, eingehen können. Ich empfehle aber jedem das Projekt nicht aus den Augen zu verlieren. Kleiner Wermutstropfen: Leider ist es aus rechtlichen Gründen noch nicht möglich, Organisationen ausserhalb der USA einen Betatest-Zugang zu geben. Der newslab-Antrag hängt deswegen seit einigen Monaten. Vielleicht bringt Aron ja gute Nachrichten mit.

Oliver Reichenstein – Duplo statt Lego: iPad-Design in Theorie und Praxis

Mindestens genau so spannend wird der Vortrag von Oliver Reichenstein ( @ia ) von den Information Architects. Oliver konnten wir auf meinen Vorschlag über die Vermittlung des Scoopcamp Partners Zeit Online (Vielen Dank Oliver und Sven) für das Scoopcamp gewinnen. Leider kenne ich Oliver noch nicht persönlich und freue mich darauf, dass sich das ändern wird.

Netzweit am bekanntesten sind die Information Architects wohl für ihre immer wieder mit Spannung erwarteten Poster: den Web Trend Maps (1, 2,3 und 4) und in diesem Jahr dem Cosmic 140 Poster.

Mindestens genauso spanned ist aber die Firmenkonstruktion selbst. Eine relativ kleine Firma mit zwei Standorten: Zürich und Tokio. Hoffentlich erzählt Oliver Reichenstein auch etwas darüber.

Die Allgemeinheit kennt die Arbeit von Oliver Reichenstein und seinen Kollegen aber eher indirekt. Über die von Ihnen (mit-)gestalteten Webauftritte von Zeitungen wie etwa Zeit Online, des Tagesanzeigers, der Basler und der Berner Zeitung etc. Für mich haben alle diese Auftritte eines gemeinsam: Sie liegen über dem Durchschnitt.

Am spannendsten – zumindest für mich – sind aber die erfrischend klaren (und deutlichen) Aussagen von Oliver Reichenstein zum Thema Design für das iPad und Tablets allgemein, die sich in diesem fulminanten und unbedingt lesenswerten  Artikel manifestieren.

So sehr ich die dort vertretene Linie verstehe und unterstütze, so sehr kann ich aber auch die Probleme verstehen, die ggf. Printredaktionen und die bisherigen Leser der Printprodukte evtl. mit dieser Linie haben.

Als Konsequenz dieses Dilemmas haben z.B. die Default -Artikeltemplates (HTML5) unserer in Entwicklung befindlichen iPad  App  ein einspaltiges Artikeldesign ohne Paging,  das nur mit CSS von hoch auf quer umgestellt wird. Wir bauen aber auch Optionen für mehrspaltiges Layout und Paging der Artikel ein (wie wir es z.B. in dem Prototypen für die Frankfurter Rundschau realisiert hatten),  und erklären den Kunden dann welche Probleme und Mehraufwände sie sich damit ggf. einhandeln.

Nicht zu vernachlässigen ist auch das Interesse der Verlage, die iPad-User in die Print-Auflage mit einberechnen zu können. Dies bedeutet aber auch, dass die Applikation ein Faksimile der Print-Ausgabe enthalten muss, Wie das am Besten geschehen kann, sehen wir uns im Moment gerade etwas genauer an. Auf keinenFall würde wir aber das Interesse an einer Zählbarkeit für IVW über das Interesse eines Nutzers an einer guten und dem Medium / Gerät angemessenen Applikation stellen. Dann würde man unserer Meinung nach nämlich eine Milchmädchenrechnung aufmachen.

Auf  jeden Fall freue ich mich deshalb schon sehr auf seinen Vortrag zum Thema: “Duplo statt Lego: iPad-Design in Theorie und Praxis”. Und auf die sich anschliessende Diskussion, die es sicher geben wird

Mein Problem am Nachmittag: In welchen der beiden Workshops gehe ich. Oder doch in einen ganz anderen?

Zur Erinnerung: Unsere Prämissen lauten wie folgt

• Unterstützung von Tablets und E-Readern
• Konsequenter Einsatz von Webtechnologien und -standards zur Bereitstellung und Darstellung der Inhalte.
• Darstellung der Inhalte mit nativen Technologien nur dann, wenn diese einen funktionalen Mehrwert bieten oder die Einschränkungen der mobilen Geräte dies notwendig macht
• E inbeziehung von “Digital Replica” und “Digital Magazine” Ansätzen
• Integration von Print- und Online-Inhalten
• Konzentration auf die effiziente und effektive Produktion auf Basis existierender Inhalte und Systeme (Print und Online)
• Sowohl Full Service als auch Arbeit in Kooperationen und Netzwerken

Gerd hat bereits über die ersten vier Punkte geschrieben und damit vor allem den technologischen Ansatz umrissen. Ich werde mir heute die weiteren Essentials unserer Postionierung vornehmen, die viel mit Prozessen zu tun haben.

Integration

Als Unternehmen im dpa-Verbund sind wir ein “Gemeinschaftsunternehmen” der deutschen Medienhäuser. Somit kennen wir die Gegebenheiten der Branche und können uns auf die Systemlandschaft der Verlage einstellen; inklusive getrennter Systeme für Print und Online, merkwürdiger XML-Outputs und überschaubarer Metadaten. Wir docken uns an die Redaktionssysteme der Verlage an (und schauen, ob noch das eine oder andere Metadaten-Feld mit-exportiert werden kann, aber dazu mehr im nächsten Punkt).

Wir glauben, allein mit einem Subset der Inhalte eines Verlages auf einem multimedialen, vernetzten Gerät wenig gewinnen zu können (erst recht nicht, wenn es um “Paid Content” gehen soll). Es wird nicht reichen, einfach die Inhalte aus der Zeitung weitgehend 1:1 auf das iPad zu transportieren. Es kommt wohl eher darauf an, zum Einen alle verfügbaren Typen von Inhalten zu integrieren und so die Basis für sinnvolle multimediale Angebote zu legen. Zum Anderen darauf, sich bei der Produktentwicklung Gedanken darüber zu machen, worum es in dem E-Publishing-Produkt geht – und was dafür auch nicht gebraucht wird. Ein großer Content-Berg ist wenig profiliert und dürfte an den Zielgruppen vorbei gehen, die Interesse für Inhalte eines Zeitungsverlages auf Tablets hegen.

Aus diesen Gedanken folgt die nächste Herausforderung: wie wir dies erreichen wollen.

effektive & effiziente Produktion

Wer sich die Realität in vielen Verlagen ansieht, wird schnell merken: der Personalbestand ist dünn (oder zumindest dünner als in der Vergangenheit), und es ist nicht zu erwarten, dass dies sich in nächster Zeit ändern wird. Häufig hören wir aus Verlagen, man brauche eine Lösung für die “vollautomatische Produktion”. Das ist zwar richtig, auf der anderen Seite trotzdem problematisch.

Warum?

Richtig ist, dass Automatik eine wichtige Rolle spielen muss, insbesondere beim Layout von Inhalten. Solch “algorithmisches Layout” ist mehr als nur die optische Gestaltung; es betrifft auch Selektion, Gewichtung, Reihenfolge und Aggregation von Inhalten. Wir glauben, dass im E-Publishing-Umfeld die Prinzipen der Zeitungsproduktion schlicht nicht funktionieren. Das betrifft die Produkte und die Ausgabegeräte. Es wird nicht mehr “den einen Monolith”, sondern mittelfristig eine Vielzahl von Produkten für unterschiedliche Zielgruppen geben. Diese Vielfalt komplett manuell zu zu gestalten, wird kaum leistbar sein. Endgültig unmöglich wird es durch die Gerätevielfalt, die auf uns zukommt. Schon jetzt braucht man fürs iPad zwei Layouts: horizontal und vertikal. Das WeTab beispielsweise wird ein anderes Bildschirmformat haben – schon muss das ganze manuell komponierte Layout angepasst werden.

Es ist also in aller Regel ökonomischer Irrsinn, neue Producer einzustellen, um jede Seite für jedes Gerät manuell zu optimieren. Wer aber erkennt, dass attraktive Produkte auf einem “revolutionären” Device nicht vom Himmel fallen, muss sich Gedanken machen, wie die Inhalte effektiv und effizient auf das iPad & Konsorten gelangen. Sich bei digitalen Produkten sinnvoller Algorithmen zu bedienen, ist daher sehr vernünftig.

Natürlich sind wir uns dessen bewusst, dass es Grenzen für automatisierte Prozesse gibt. Insbesondere solange wir mit Editionen, also abgeschlossenen Ausgaben zu tun haben. Hier geht es auch um eine innere Stringenz, einen “runden Eindruck”, den auch ein gutes Metadaten-Set nicht immer gewährleistet. Algorithmisches Layout stellt für uns daher keinen Selbstzweck dar, sondern vielmehr ein Werkzeug für Verlags-Mitarbeiter, das in die Lage versetzt, attraktive Produkte zu gestalten.

Problematisch ist die Idee der “vollautomatischen Produktion”, weil in den meisten Verlagen (noch) nicht die Voraussetzungen existieren, sinnvoll mit algorithmischem Layout zu arbeiten. Es fehlen schlicht die notwendigen Metadaten. Diese sind aber notwendig, um ein visuell anspruchsvolles automatisiertes Layout zu erzeugen. Beispiele: Fotos lassen sich ins jeweils optimale Bildformat tranformieren, wenn Schneidmarken oder Bildschwerpunkte übermittelt werden. Die Darstellung von Artikeln und Übersichten gelingt umso besser und variantenreicher, je mehr kontextrelevante Information, beispielsweise Prioritäten für Stories, Tags für die Themenpaketierung, Links auf verwandte Inhalte und Kennzeichnung von Artikeltypen, verfügbar sind. Verlage, die in letzter Zeit ihre Abläufe auf crossmediales Publizieren umgestellt haben, genießen hier einen Vorteil; viele der nötigen Metadaten sind bereits in den Systemen vorgesehen und werden für die Website teilweise auch bereits erfasst.

Das alles geht natürlich sehr weit und wird wohl erst einmal Idealvorstellung bleiben. Tatsächlich müssen wir einen gangbaren Kompromiss finden, um auch bei den gegenwärtigen eingesetzten Redaktionssystemen einen funktionierenden Ansatz bereit zu halten. Da kann man zum Einen über Bande spielen. Manchmal enthalten Print-Outputs interessante Informationen zu Artikeln, aus denen man einige relevante Metadaten ableiten kann. Diese Analyse ist ein obligatorischer Teil unserer Arbeit. Doch grundsätzlich halten wir uns an folgende Gleichung: Je weniger Ressourcen und je weniger technische Intelligenz als Input geliefert werden kann, desto höher der Grad an Standardisierung bei der Ausgaben-Erstellung. Dies ist der zwingende Trade-Off, solange die das einwandfreie Funktionieren sichergestellt sein soll.

Ein pragmatisches Vorgehen bedeutet auch, dass wir einige Elemente aus der Print-Welt, die häufig aufs iPad transferiert werden sollen, in unserem Ansatz berücksichtigen: die aufwändige Infografik, die besonders magazinig gestaltete Seite oder PDFs der gesamten Print-Ausgabe als E-Paper-Ersatz. “Digital Replica” wie Seiten-PDFs, das scheint erst einmal weit weg von einem Ansatz, der Web-Technologien ins Zentrum stellt. Andererseits: So wie jedes Foto als Grafikdatei in ein HTML-Framework eingebunden ist, so kann grundsätzlich auch mit PDF-Dateien oder SVG-Grafiken verfahren werden. Die Herausforderung liegt eher darin, den komplett unterschiedlichen Produktionsprozess (siehe oben) reibungslos zu integrieren. Insofernaber passen sich diese “Digital Replica”-Elemente (siehe Blogpost von Gerd) durchaus in unser grundlegendes Konzept ein.

Kooperationsfähigkeit

Jetzt haben wir eine Fülle von Aspekten vorgestellt, über die wir uns Gedanken machen. Ein sinnvolles Technologiekonzept, geräteaäquates Design. Ein stimmiges User-Interface, ein nachvollziehbarer Aufbau. Inhaltliche Fragestellungen und Ansätze zur generelle Positionierung. Saubere Implementierung, effiziente Prozesse, Anbindung an bestehende Systemen. Wir glauben, das richtige Maß an Querschnitts- und Spezialwissen zu besitzen, um Verlage in allen Fragen des E-Publishings zur Seite zu stehen. Auch wenn wir noch so viele Ideen haben, die zu implementieren wir noch keine Zeit hatten, so sehen wir uns doch auf dem richtigen Weg und sind gespannt, unsere Arbeitsergebnisse möglichst schnell in Projekten mit Verlagen auszurollen.

Die Rolle der dpa-infocom als Gemeinschaftsunternehmen der Verlage bringt dabei unterschiedliche Konstellationen mit sich. Häufig, und nicht nur für kleinere Häuser, agieren wir als Full-Service-Anbieter. Andere Verlage wiederum sehen uns eher als Mitglied in einem Konsortium, welches gemeinsam an Setup und Betrieb arbeitet.

In beiden Rollen fühlen wir uns wohl. Wir sind immer daran interessiert, schon aus intellektueller Neugier, mit weiteren Partnern in Projekte einzutreten. Bei einem solchen kooperativen Ansatz, wenn es zum Wohle aller Beteiligten aufgesetzt ist, bereichern sich die Projektpartner wechselseitig. Und das ist letzten Endes gut für alle: Uns, einen weiteren Partner und den Verlag.

PS: Join the Team!

Klingt das spannend? Wir suchen einen Projektmanager (m/w), der unser Team verstärkt.

Wir suchen einen Kollegen, der uns bei der Betreuung von Verlagsprojekten unterstützt, als Schnittstelle zum operativen Betrieb agiert und sich auch bei Fragen der konzeptionellen Weiterentwicklung einbringt. Unverzichtbar ist dafür eine ausgeprägte “Mediendenke” – jemand, der sich insbesondere auf dem Zeitungsmarkt auskennt, eine Vorstellung davon hat, wie ein Verlag “tickt” und der sich für Themen zwischen “alter” und “neuer” Medienwelt begeistert. Wichtig ist auch ein gutes Technikverständnis – es geht nicht darum, jedes Details zu verstehen, aber auf Augabenhöhe zu diskutieren. Außerdem wir Wert auf das richtige “Mindset”: Wir suchen einen Kollegen, der wissbegierig und kommunkationsbegabt ist, und der Lust hat, sich in unserem kleinen Team einzubringen. Ideal wären erste Erfahrungen in einem Verlag, einer Agentur oder bei einem Mediendienstleister – aber Talent geht vor Erfahrung.

Wir sitzen in Hamburg am Mittelweg (nahe der Alster), der Job ist zunächst auf ein Jahr befristet.

Interesse? Dann gleich Kontakt aufnehmen mit Gerd Kamp,  E-Mail: gerd.kamp@dpa-info.com

Bei “Zeitung Online” Anfang Juni in Düsseldorf haben wir nun einen Prototypen der “Frankfurter Rundschau” auf dem iPad vorgestellt.

Damit ist auch schon das Spektrum der Lösungen gut umrissen, die im Schwerpunkt E-Publishing des newslab entwickelt werden.

In diesem Blogpost versuche ich, die Eckpunkte unseres grundsätzlichen  Ansatzes zu beschreiben – und sie damit auch zur Diskussion zu stellen.

Die Eckpunkte

Die Eckpunkte unseres Ansatzes lassen sich kurz und knapp wie folgt beschreiben:

• Unterstützung von Tablets und E-Readern
• Konsequenter Einsatz von Webtechnologien und -standards zur Bereitstellung und Darstellung der Inhalte.
• Darstellung der Inhalte mit nativen Technologien nur dann, wenn diese einen funktionalen Mehrwert bieten oder die Einschränkungen der mobilen Geräte dies notwendig macht
• Einbeziehung  von “Digital Replica” und “Digital Magazine” Ansätzen
• Integration von Print- und Online-Inhalten
• Konzentration auf die effiziente und effektive Produktion auf Basis existierender Inhalte und Systeme (Print und Online)
• Sowohl Full Service als auch Arbeit in Kooperationen und Netzwerken

Und damit zu den einzelnen Eckpunkten. Wobei ich mich in diesem Post auf die ersten drei Eckpunkte beschränke. Zu den letzten vier Eckpunkten schreiben Martin Kohls oder ich in Bälde einen weiteren Blogpost.

Tablets und E-Reader

Viele werden sich beim Lesen der Eckpunkte gefragt haben: “Warum Unterstützung von Tablets und E-Readern? Sind E-Reader nicht tot?”

Genauso wie wir schon seid langem daran glauben, dass Tablets als multifunktionale Geräte eine größere Verbreitung im Markt finden werden als E-Reader, sind wir auch davon überzeugt, dass E-Reader als Gerätekategorie nicht so schnell vom Markt verschwinden werden und insbesondere das EPUB-Format für bestimmte Arten von Inhalten noch eine lange Halbwertszeit hat.

So ist EPUB der De-facto-Standard für elektronische Bücher nicht nur auf E-Readern, sondern auch im iBookstore von Apple. Darüber hinaus gibt es auf praktisch allen anderen mobilen Plattformen (z.B. Android) ausgereifte Software zum Erwerben und Lesen von EPUB-Publikationen. Einzige Ausnahme bildet Amazon, die ein eigenes Format einsetzen, das allerdings weitaus weniger kann als EPUB. Aufgrund der Marktverschiebungen erwarte / hoffe ich aber auch, dass Amazon dem wachsenden Druck der Verlage nachgeben wird und auch auf EPUB umstellen wird.

Wenn man sich dann noch EPUB etwas genauer ansieht und feststellt, dass EPUB zu mindestens 80% aus Webtechnologie besteht, dann ergibt es Sinn, auch EPUB zu unterstützen; insbesondere dann, wenn der auch Ansatz für Tablets auf Webtechnologien fußt.

Exkurs: Eine EPUB Datei ist im wesentlichen  ein ZIP-Bundle von XHTML und CSS2 Dateien, die durch eine Manifest-Datei zusammengehalten werden. Von der Art und Weise, wie ansonsten Mengen von HTML-Seiten oder anderen Inhalten zusammengehalten werden, ist das ganze also recht ähnlich. Dazu kommt noch eine zweite Struktur für eine inhaltsverzeichnis-basierte Navigation, die EPUB aus früheren E-Book-Standards mehr oder weniger geerbt hat, die aber relativ leicht generiert werden kann und auf die man leicht auch verzichten kann, wenn man im Inhalt selbst Links erlaubt.

Im Wesentlichen wurde im EPUB-Standard, der ja etwas älter ist, auf frühere Versionen von HTML und CSS standardisiert und das ganze um einige buchspezifische Funktionalitäten ergänzt. Hat man die schwachbrüstigen Prozessoren, die in E-Readern damals (und in dedizierten Geräten auch heute)  verbaut wurden vor Augen, so wundert es nicht, dass Javascript vom EPUB-Standard nicht unterstützt wird. Allerdings schert sich Apples iBooks nicht darum, wie die Experimente von Liza Daly und Keith Fahlgren  zeigen

Aktuell kümmert sich eine Arbeitsgruppe um die Weiterentwicklung des EPUB-Standards, insbesondere in die Richtung Unterstütung von unterschiedlichen Screengrößen und Periodicals. Wir werden sehen, was dabei herauskommt. Meine Empfehlung/Hoffnung: ein sinnvolles Subset von HTML5, Javascript und CSS3. Dabei stellt Javascript die größte Herausforderung dar, da ein vernünftigen Sandbox-Modell gefunden werden muss, damit nicht das Javascript eines “malicious books” die anderen gekauften Bücher zerstört.

Konsequenter Einsatz von Webtechnologien für Bereitstellung und Darstellung der Inhalte, native Darstellung der Inhalte , dann wenn Mehrwert gegeben  oder durch Einschränkungen notwendig

Vorbemerkung

Vereinfacht dargestellt, hat man zurzeit die folgenden Möglichkeiten zur Darstellung gestalteter Seiten von Inhalten auf dem iPad:

1. Nutzung der eingebauten PDF-Engine zur Anzeige der (in einem anderen Programm gestalteten) Seiten
2. Nutzung der Bilderanzeige zur Anzeige der (in einem anderen Programm gestalteten) Seiten. Eigene Implementierung von interaktiven Bereichen.
3. Nutzung von CoreText unter Verwendung einer eigenen Textlayout-Engine.
4. Verwendung der HTML-Layout & und Rendering-Engine des UIWebView

Die erste Variante wird mittlerweile gern unter dem Begriff “Digital Replicas” zusammengefasst, die zweite Variante ist die zurzeit meistgenutzte in der Kategorie der “Digital Magazine Viewer“, wie sie zum Beispiel von Herstellern wie Woodwing und Adobe zur Zeit angeboten werden.

Insbesondere von Adobe ist zu erwarten, dass sie in ihrer Roadmap irgendwann auch einen Port ihrer InDesign Text Layout Engine oder – noch wahrscheinlicher – einen Port des Flash Text Layout Frameworks   (TLF) vornimmt. Da letzeres OpenSource ist, können auch andere Anbieter auf diese Idee kommen. Auf jeden Fall ist die Implementierung einer Text Layout Engine in Objective-C nicht “einfach mal schnell gemacht”. Ich vermute sehr stark, dass die iPad-Apps der New York Times und von USA Today auf dieser Basis gebaut wurden, da sie beide den gleichen Fehler zeigen (einen größeren Durchschuss zwischen vorletzter und letzter Zeile eines Absatzes).

Warum moderne Webstandards als Basis?

Nach dem Vorwort in Richtung EPUB und den obigen Ausführungen ist es nicht mehr verwunderlich, dass wir für unseren eigenen Ansatz zur Realisierung von Applikationen auf dem iPad und weiteren zukünftigen Tablets  für die vierte Variante entschieden haben.  Wir setzen auf moderne Webtechnologien (insbesondere HTML5, CSS3 und Javascript).  Eine ähnliche Ansicht, wenn auch etwas radikaler formuliert vertritt übrigens auch interfacelab.

Dabei ist es unser Ziel und Anspruch, webbasierte Lösungen zu entwickeln, die sich auf Augenhöhe mit der auf der Google I/O vorgestellten HTML5-Version von Sports Illustrated befinden.

Ein einfacher Grund ist, dass praktisch alle angekündigten Tablets auf Webkit als Browsertechnologie / Rendering Engine zurückgreifen und damit eine einheitliche Plattform entsteht, für die entwickelt werden kann. Insbesondere setzen sowohl Android / Chrome  als auch Adobe AIR (der HTML Rendering Teil) auf der Webkit Rendering Engine auf, genauso wie u.a. WebOS , Symbian oder der neue Blackberry Browser.

Im Idealfall erhält man also für Tablets eine einheitliche Browserplattform zur Darstellung der Inhalte auf den verschiedensten Endgeräten: eine Browserplattform, die  moderne Webtechnologien unterstützt. Klar ist aber auch, dass sich die Browser, auch wenn sie alle auf Webkit basiseren,  in der Umsetzung der verschiedenen Aspekte von HTML5 unterscheiden. Aber auch der kleinste gemeinsame Nenner unterscheidet sich fundamental von dem kleinsten gemeinsamen Nenner  für Desktop-Browser: leider immer noch IE6.

Aus über 10 Jahren Erfahrung in der Entwicklung für das mobile Internet wissen wir, dass mobile Browser im Vergleich zum Desktop immer noch großen Einschränkungen unterliegen (die im Wesentlichen der deutlich schächeren Hardwareausstattung  der mobilen Geräte geschuldet sind). Daher funktionieren viele Dinge, die in einem Desktopbrowser super aussehen, auf einem Tablet nur schlecht oder gar nicht.

Inhalt und Repräsentation

Deswegen  unterscheiden wir auch sehr bewusst zwischen der Bereitstellung und Präsentation / Darstellung der Inhalte.

Wir sind gern bereit, aus Gründen eines funktionalen Mehrwertes (und sei es “nur” die bessere Performance, die in unseren Erfahrungen aber oftmals den Unterschied zwischen unbenutzbar und benutzbar ausmacht!) oder einer Browsereinschränkung bestimmte Komponenten zur Präsentation der Inhalte nativ zu implementieren. Dagegen bedarf es deutlich größerer Anstrengungen, uns davon zu überzeugen,  warum es sinnvoll sein soll, die Inhalte nicht in einem Webformat bereitzustellen.

Ein gutes Beispiel für die native Präsentation der Inhalte sind die Slideshows  in unserem FR-Prototypen. Sie waren zunächst nur mit  Webtechnologie implementiert, aber die Kombination aus Performance und Browsereinschränkungen führten dazu, dass wir eine native Slideshowkomponente implementiert haben.  Welche Bilder mit welchen Bildunterschriften etc. angezeigt werden sollen, wird aber weiterhin in einem HTML-Dokument bereit gestellt.

HTML5 oder XML

Hier sind wir der Überzeugung, dass HTML5 (insbesondere unter Zuhilfenahme der neuen semantischen Tags, zusammen mit semantischen CSS-Klassen) gut geeignet ist, um (Zeitungs-) Inhalte für die Darstellung auf Tablets bereitzustellen. Sollte uns das aber an einigen Stellen zu konstruiert erscheinen, würden wir zu einer Erweiterung via Namespace greifen.

Andere Ansätze (inbesondere die Digital Magazine Viewer) verwenden zur Übermittlung der Inhalte XML + Bilder. Oder es wird geplant, XML zu übermitteln und dann mit der eigenen Layoutengine zu rendern. Hier erschließt sich für uns nicht der Mehrwert, ein eigenes XML zu definieren und übermitteln. Verwendet man die XML-Serialisierung von HTML5, ist das ganze valides XML. Man verliert nichts in Hinblick auf die Verarbeitbarkeit des XML.

Dafür bekommt man eine Layout und Rendering Engine “for free”. Sie ist vielleicht aus typografischer Sicht nicht optimal, aber im Zweifelsfall ist die Entwicklergemeinde, die diese Layoutengines weiterentwickelt, die größte der Welt.

Textlayout und HTML

Das beste Beispiel  für die noch nicht erreichte optimale Darstellung von Text in HTML ist der im Vergleich zu TeX/LateX oder InDesign doch  eher rudimentäre  Blocksatz von engen Spalten. Ob der Blocksatz von schmalen Spalten generell eine gute Idee für Geräte wie das iPad ist, lassen wir mal außen vor. Oliver Reichenstein von informationArchitects hat da ja eine sehr dedizierte Ansicht, die wir im Prinzip teilen. Für jeden, den es interessiert, kann ich nur die sich anschließende Diskussion empfehlen (die sich interessanterweise auf Flickr entfachte).

Will man die Skalierbarkeit der Schrift nicht verlieren – eine Funktionalität, die insbesondere für die aus unserer Sicht gerade für Zeitungen interessante Verwendung des iPads als “intelligente Leselupe” wichtig ist – muss der Zeilenumbruch  auf dem Gerät stattfinden. Für JavaScript-basierte Implementierungen des  objektiv besten Zeilenumbruchalgorithmus, der Knuth-Plass Algorithmus ist die JavaScript Engine des Mobile Safari aber (noch) zu langsam, und durch die Verwendung eines Canvas verliert man Copy & Paste. Daher erscheint uns die in dem Artikel vorgestellte CSS Word Spacing Variante interessanter, auch wenn die CSS Property noch nicht unterstützt wird.

Völlig unverständlich für mich ist allerdings, warum – zumindest nach meiner Kenntnis – bislang kein Browser Knuth-Plass nativ implementiert. Kennt einer die Gründe? Für die Silbentrennung gilt im übrigen das gleiche Hier gibt es Javascript-Implementierungen der TeX/LaTeX Algorithmen, aber keine native Unterstützung.

Links, Links, Links

Zu guter Letzt ist  für uns das alles überragende Argument für eine HTML5-basierte Lösung, dass wir fest daran glauben, dass für ein “connected, interactive device” wie das iPad  (und Tablets im allgemeinen) es nicht die einzige bzw. die beste Lösung sein kann, die Darstellungsform eines gedruckten Produktes mehr oder weniger  1-zu-1 zu übernehmen, wie es die momentan am häufigsten für iPad-Apps genutzten “Digital Replica” oder “Digital Magazine Viewer”  Ansätze tun.

Dies hat zur Folge, dass ich in meinem initialen Review von Nachrichtenapplikationen auf dem iPad die Überschrift: “Welcome to the link free zone” gewählt habe. In allen Ansätzen außer einem HTML-basierten Ansatz muss die Funktionalität eines Links implementiert werden. Bei Variante 1 und 2 ist das unmögliche resp. schwierig (der eingebaute PDF-Viewer versteht keine Links in PDF-Dateien, wir haben es ausprobiert), in Variante 3 ist es möglich, muss aber nach meinem Kenntnisstand selbst implementiert werden. In Variante 4 muss man diese Funktionalität selbst deaktivieren

Eine Publikation die keine Links enthält ist aber nach unserem Verständnis noch nicht auf dem iPad angekommen. Selbst die Printausgaben der Zeitungen enthalten mittlerweile mehr oder weniger oft Verweise auf das eigene Online-Angebot und in das allgemeine Web. Wie will ich den Lesern erklären, dass diese Links in einer iPad-App nicht funktionieren?

Der Kern

So besteht der Kern des newslab zur Zeit aus vier Mitarbeitern:

Ich kümmere mich neben dem Organisatorischen um das Technologiescouting  und die prinizipielle  thematische und technologische Ausrichtung. In den Projekten diskutiere ich gern bei der prinzipiellen Architektur mit, und zwar sowohl der technischen als auch der Informationsarchitektur. Ich komme außerdem andauernd mit neuen Systemen, Tools und Ideen, die man mal testen könnte. Aber genauso setze ich schon mal einen neuen Server auf – z.B. um zu verstehen, wie man möglichst automatisch applikationsspezifische Amazon EC2 Instanzen von scratch baut. Viel zu selten komme ich dazu, selbst ein paar Zeilen Code für einen Prototypen zu schreiben (mittlerweile vorzugsweise in Python/Django oder Rails, mein Javascript/jQuery ist noch zu schlecht, keine Zeit ). Wenn es in einem Projekt mal eng wird, dann helfe ich gern auch mit Hilfsttätigkeiten aller Art  aus oder halte den Projektmitgliedern den Rücken frei.

Martin Kohls betreut schwerpunktmäßig das Thema eReading. Er sorgt dafür, dass wir das notwendige Branchen-Know-How besitzen und gut vernetzt sind (z.B. als nachgefragter Sprecher zum Thema beim BDZV, VDZ und anderen Verbänden). Als gelernter Medienwissenschaftler ist er neben den inhaltlichen Konzepten natürlich auch an Geschäftsmodellen für bezahlte und unbezahlte Inhalte interessiert. Martin organisiert und betreut solch komplexe Projekte wie den eReading-Feldtest, den wir im Herbst letzten Jahres mit insgesamt sieben Partnern durchgeführt haben. Er schreckt aber auch nicht davor zurück, erste eReading-Prototypen in HTML zu bauen oder während eines Feldtests die generierten Ausgaben layoutoutmäßig und inhaltlich zu optimieren.

Frank Buhr, Diplom-Informatiker, kümmert sich als Architekt und Entwickler darum, dass unsere webbasierten  Lösungen State-Of-The-Art sind. Neben der reinen Entwicklung ist er einerseits mein Sparringspartner, wenn es um Diskussionen zu Themen wie Feedformaten, JSON und ReST-basierte APIs geht. Andererseits sorgt er als Experte für User Experience / Interaction Design dafür, dass das, was wir bauen, auch benutzbar ist. Als LISP und Smalltalk-Veteran findet er dynamische Sprachen wie  Python, Javascript, Groovy etc. gut, als ehemaliger Besitzer nicht nur eines NeXT-Rechners kommen uns fürs iPad seine ObjectiveC Kenntnisse zugute. Kein Wunder, dass ein Mann mit so vielen Talenten begehrt ist. Als Systemarchitekt in einem anderen großen Projekt der dpa-infocom ist er noch bis Ende Juli eingeplant, so dass er erst danach mit voller Kraft für das newslab arbeiten kann.

Sebastian Mondial personifiziert das newslab-Motto “Brücke zwischen Redaktion und Technologie”. Die Hälfte seiner Zeit verbringt er in der Redaktion als Mitglied des RegioData-Teams der dpa, die andere Hälfte als Mitarbeiter im newslab. Dort helfen uns seine Kenntnisse im Bereich Computer-Aided Reporting und Datenjournalismus ebenso wie seine Erfahrungen, die er als Mitarbeiter von Start-Ups und Onlinemedienhäusern gesammelt hat. Sebastian bearbeitet im Wesentlichen Projekte im Bereich Redaktionstools und ist dpa-intern immer dann zur Stelle, wenn es um die  Konzeption der Schnittstelle zwischen Redaktion und Technologie geht. So war zum Beispiel auch mit in der Arbeitsgruppe zum dpa-Notizblock. Darüber hinaus unterstützt er newslab-Kollegen in den anderen Bereichen: wenn z.B. mal schnell ein Scraper gebraucht wird, Server- oder Clientseitig  bestimmte Tools gefunden, kompiliert und installiert werden müssen oder Inhalte für einen Prototypen zu recherchieren sind.

Das Netzwerk

Neben diesem kleinen Kern fester Mitarbeiter ist es das Prinzip des newslab, sich gezielt mit einem Netz  freier Mitarbeitern zu verstärken, die themen- und projektbezogen ihre spezielle Expertise einbringen. Wir glauben fest daran, auf die Anforderungen der heutigen Zeit nur mit einem solchen Netzwerk flexibel genug reagieren zu können.  Dabei  ist mir wichtig, dass die freien Mitarbeiter die Inhalte und Aufgaben im newslab spannend finden und ihre eigene Ideen einbringen. Es gibt bestimmt andere Jobs bei denen sie mehr Geld verdienen können vielleicht aber weniger interessante Sachen machen können.

Zu unserem Netzwerk gehören ein Spezialist für eReading und EPUB-Generierung  aus den verschiedensten Redaktionssystem / CMS / Feedquellen heraus, ein Experte der ein Geobackend auf Basis Postgres/PostGIS baut sowie ein Grafiker/Designer, der seine Entwürfe in HTML/CSS3 abliefert und  begeisterter Fingerpainter auf dem iPhone (und jetzt dem iPad) ist. Außerdem verstärken rivva Macher Frank Westphal und Moritz Stefaner das newslab-Netzwerk.

Frank hat unter anderem den dpa-eigenen URL-Shortener dpaq geschrieben, über den ich schon an anderer Stelle im newslab-Blog berichtet hatte. Er ist aber natürlich insbesondere wegen seiner Arbeit rund um Social-Media Monitoring bei rivva.de eine große Bereicherung für das newslab.

Moritz stand als einer der besten deutschen infovis-Experten schon lange auf der Liste der Leute, mit denen ich etwas zusammen machen wollte. Jetzt endlich hat es geklappt. Im newslab kümmert er sich unter anderem darum, wie man Elastic Lists und Facet Browsing für Recherche-Frontends, z.B. einer Oberfläche für das GeoBackend  einsetzen kann. Moritz wird sich aber  auch darüber Gedanken machen, wie man infovis-Ansätze für coole iPad Nachrichtenapplikationen  einsetzen kann. Bin schon gespannt was dabei herauskommt.

Vielleicht entsteht als interessanter Seiteneffekt ja auch etwas an der Schnittstelle rivva.de – revisit…

Spannend? Das newslab ist immer auf der Suche nach neuen Knoten im Netzwerk.

Apropos Netzwerk. Wer jetzt zu dem Schluss gekommen sein sollte, “was im newslab passiert, hört sich spannend an, und ich passe da gut rein”, der möge sich doch gern bei mir melden. Am besten mit einer Begründung, was er/sie besonders interessant findet und was er/sie in das Netzwerk einbringen kann. Keine Zeit, Full-Time im Projekt zu arbeiten? Kein Problem, das ist eher die Regel als die Ausnahme -  obwohl es schon gut wäre, im  Falle der Fälle auch mal richtig ranklotzen zu können.

Besonders dringend gesucht sind zur Zeit Leute, die sowohl ObjectiveC als auch Javascript/HTML5/CSS3 KnowHow besitzen und idealerweise auch Erfahrungen mit Redaktions- und Content-Management-Systemen mitbringen. Einen davon haben wir bereits gefunden; er fängt noch im Juni an und unterstützt uns in unseren iPad-Projekten. Aber auch Menschen, die Backends im Medienumfeld auf Basis von RoR, Python/Django, Java/Groovy/Scala/Clojure entwickeln und vielleicht sogar noch Know-How im Betrieb ebendieser in der Cloud (z.B Amazon, Eucalyptus, GAE) haben, sind leicht im Vorteil.

Wir suchen ebenfalls Menschen, die sich dafür interessieren, Medienformate inhaltlich und konzeptionell zu entwickeln und die sich für Projekte an der Schnittstelle von “alter” und “neuer” Medienwelt begeistern. Projektmanagement-Erfahrung und das Wissen, wie ein Verlag “tickt”, wären hier hilfreich.

Wir lassen uns aber auch von jeder guten Idee die zum newslab passt begeistern. Wenn Ihr jemanden kennt, der eine Mitarbeit im newslab spannend finden könnte, dann leitet doch den Link zu diesem Post weiter.

Master-, Bachelor-  & Studienarbeiten

Schon immer mal Lust gehabt, Deine Ideen/Algorithmen mit Hundertausenden von Nachrichten oder  zigtausenden von Bildern auzuprobieren? Erfahrungen mit node.js, MapReduce und/oder Hadoop? Linked-Open-Data, Named Entity Recogniniton / TextMining, FaceRecognition, allg. Bildverarbeitungs/ Bilderkennungs Know-How? OpenGL ES Experte? … Im newslab gibt es Ideen zu Master- , Bachelor- und Studienarbeiten in all diesen Themen.

Interesse? Auch in diesem Fall am besten bei mir melden – es wäre nicht die erste studentische Arbeit, die ich betreue.

Wer schon mal mit einem Wiki-System wie Wikipedia zu tun hatte, kennt höchstwahrscheinlich schon die Möglichkeit den Artikeltext inklusive Überschriften, Tabellen, Links etc. in einem reinen Textformat einzugeben. Dieses Textformat wird dann von der Wiki-Engine in HTML-Markup, also eine Webseite, übersetzt.

Reine Textformate zur Beschreibung von strukturiertem Text (insbesondere HTML) entstanden auch außerhalb des Wiki-Bereiches. Zwei bekannte Vertreter dieser “Leichtgewichtigen Markupsprachen” sind Textile und Markdown. Während Textile im Bereich der Blogs entstand und auch schwerpunktmäßig dort eingesetzt wurde, entstand Markdown aus der Verallgemeinerung von Textformatierungen die sich im Laufe der Zeit in textbasierten E-Mails herauskristallisiert hatten.

Im Rahmen der OpenNotebook-AG entstand daher bei mir die Idee, für die Auszeichnung der zusätzlichen Informationen eine dieser leichtgewichtigen Markupsprachen zu verwenden. Dies bietet den Vorteil, dass der reine Text weiterhin über den herkömmlichen dpa-Textfunk (IPTC7901) verteilt werden kann, ohne dass Änderungen vorgenommen werden müssen. Außerdem kann ein Text in diesem Format auch von einem Menschen gelesen und verstanden werden.

Gleichzeitig ist es möglich, mit Hilfe entsprechender Programmbibliotheken den Text praktisch ohne Aufwand in HTML zu wandeln und damit auf Webseiten einfach darzustellen. Außerdem wird die Weiterverarbeitung erleichtert, zum Beispiel im CoreMedia-System der dpa- infocom oder auch bei Kunden, die so leichter die verschiedenen Teile des Notizbuches identifizieren und in ihre Systeme übernehmen können.

Nach der Analyse etlicher Dokumente und der Möglichkeiten wie die aussehen könnten, fiel dann die Entscheidung für Markdown als Auszeichnungssprache. Sie bot die beste Lesbarkeit bei den geringsten Überlappungen mit der bisherigen Praxis und den Einschränkungen die IPTC7901 mit sich bringt. Aus den vielen alternativen Möglichkeiten, die Markdown zur Auszeichnung bietet, wurde in einem nächsten Schritt dann die zu verwendende Schreibweise ermittelt.

Diese versucht die Anzahl der zu verwendenden Elemente zu minimieren und beschränkt sich auf Zwischenüberschriften, unnummerierte Listen und Links sowie einer horizontalen Linie (* * * *), die als Abrisskante zwischen dem öffentlichen und dem nichtöffentlichen Teil des Notizblockes fungiert.

Aber am besten erklärt sich das ganze am Beispiel eines Textes, der quasi künstlich mit allen möglichen Arten an zusätzlichen Informationen angereichert wurde.
Zunächst der Text in Markdown:

Wohnungsbau/
Experten fordern mehr Wohnungen
(Berichtigung: Vier-Raum-Wohnung in der 4. Zeile))
(Mit Bildern und Grafik 3354) =

 Hamburg (dpa) – Die Bäume im Hamburger Stadtteil Eimsbüttel tragen
rund ums Jahr besondere Blätter: Zettel mit Wohnungsgesuchen. «Biete
Belohnung», steht darauf, oder «Paar, beide festangestellt, sucht
Vier-Raum-Wohung.» Der seltsame Blattbewuchs wird bislang vor allem
in großen Städten mit umkämpftem Wohnungsmarkt gesichtet, könnte aber
in den nächsten Jahren flächendeckend um sich greifen. Wie aus einer
Studie des Eduard Pestel Instituts für Systemforschung in Hannover
hervorgeht, müsste der aktuelle Wohnungsbestand in manchen Regionen
bis 2025 um mehr als ein Drittel aufgestockt werden, um den
prognostizierten Bedarf zu decken.

Autor: Andreas Meyer

# dpa-Notizblock
## Berichtigung
- Im Zeile 4 wurde geändert: Vier-Raum-Wohnung (statt: Drei-Raum)

## Achtung
- Zusammenfassung folgt - 20 Zl bis 1400

## Internet
- [Studie zum Wohnungsmangel in Deutschland](http://dpaq.de/VZRVW)
- [Daten zum Wohnen](http://dpaq.de/dgheZh)

## Orte
- [SP Eduard Pestel Institut für Systemforschung](Königstr. 50a, 30175 Hannover)

## Service
- [Studie zum Wohnungsmangel](Meier-Verlag 2009. 300 S. Euro 35,00, ISBN:300356756)

## Hinweise
- RegioData: Angebot von Regiodata zum Wohnungsmarkt in Deutschland

* * * *
Die folgenden Informationen sind nicht zur Veröffentlichung bestimmt
## Ansprechpartner
- x. xxxxxx, im Eduard Pestel Institut für Systemforschung, 0511/xxxxx-xx
  <x.xxxxx@pestel-institut.de>

## Autoren/Kontakt
- Andreas Meyer <meyer.andreas@dpa.com> und Klaus Müller, <mueller.klaus@dpa.com>
- Bearbeiter: Hans-Jürgen Ehlers Tel. 040/4113-xxxxx, <hamburg@dpa.com>

dpa am/km yyzz eh

• Der dpa-Notizblock beginnt mit der Zeile # dpa-Notizblock und kann dadurch leicht erkannt werden.
• Zeilen die mit einem # oder mehreren # Zeichen beginnen sind in Markdown Zwischenüberschriften
• Die Anzahl der # -Zeichen gibt die Gliederungstiefe an.
  
• # dpa Notizblock sagt also aus, das “dpa Notizblock” eine Zwischenüberschrift auf der ersten Gliederungsebene ist, während ## Berichtigung eine Zwischenüberschrift der zweiten Gliederungsebene darstellt.
• Zeilen die mit einem – Zeichen gefolgt von einem Leerzeichen beginnen bilden eine unnumerierte Aufzählung,
  • Nach einer Aufzählung steht eine Leerzeile um die Auzzählung abzuschliessen
• Links werden durch das Muster [Linktext](URL)beschrieben
  • Zwischen ] und ( darf kein Leerzeichen stehen

- [Studie zum Wohnungsmangel in Deutschland](http://dpaq.de/VZRVW)
- [Daten zum Wohnen](http://dpaq.de/dgheZh)

ist also eine unnumerierte Liste zweier Links

• Das Muster * * * * wird in eine horizontale Linie übersetzt
  • Dieses Muster, das sonst in der dpa-Berichterstattung nicht verwendet, wird zur Kennzeichnungder Abrisslinie zwischen dem öffentlichen und dem nichtöffentlichen Teil der dpa-Notizblockes verwendet.
  • Der nichtöffentliche Teil des dpa-Notizblockes wird bei einigen Belieferungswegen, z.B. bei der Versendung an Nicht-Medienkunden über dpa-select autmatisiert abgeschnitten.
• <mailadresse> ist eine Kurzform für einen Link zu einer Mailaddresse. Dabei achtet Markdown bei der Übersetzung in HTML darauf, dass die Mailaddresse nicht im Klartext im HTML-Quelltext steht, sondern so verschleiert wird, dass jeder Mailaddressenextraktor der halbwegs nach den Spielregeln der netiquette spielt die Finger davon lässt.

Aus diesem Text entsteht dann über die Programmbibliotheken ein HTML, das wiederum in diesem Blog z.B. so wie unten dargestellt aussehen kann. (Leider verhindern die zusätzlichen Angaben unter der Überschrift, dass diese als solche von Markdown ohne Nachbearbeitung als solche erkannt und dargestellt werden kann.

Hamburg (dpa) – Die Bäume im Hamburger Stadtteil Eimsbüttel tragen
rund ums Jahr besondere Blätter: Zettel mit Wohnungsgesuchen. «Biete
Belohnung», steht darauf, oder «Paar, beide festangestellt, sucht
Vier-Raum-Wohung.» Der seltsame Blattbewuchs wird bislang vor allem
in großen Städten mit umkämpftem Wohnungsmarkt gesichtet, könnte aber
in den nächsten Jahren flächendeckend um sich greifen. Wie aus einer
Studie des Eduard Pestel Instituts für Systemforschung in Hannover
hervorgeht, müsste der aktuelle Wohnungsbestand in manchen Regionen
bis 2025 um mehr als ein Drittel aufgestockt werden, um den
prognostizierten Bedarf zu decken.

Autor: Andreas Meyer

dpa Notizblock

Berichtigung

• Im Zeile 4 wurde geändert: Vier-Raum-Wohnung (statt: Drei-Raum)

Achtung

• Zusammenfassung folgt – 20 Zl bis 1400

Internet

• Studie zum Wohnungsmangel in Deutschland
• Daten zum Wohnen

Orte

• SP Eduard Pestel Institut für Systemforschung

Service

• Studie zum Wohnungsmangel

Hinweise

• RegioData: Angebot von Regiodata zum Wohnungsmarkt in Deutschland

Ansprechpartner

• x. xxxxx, im Eduard Pestel Institut für Systemforschung, 0511/xxxxx-xx
  x.xxxxx@pestel-institut.de

Autoren/Kontakt

• Andreas Meyer meyer.andreas@dpa.com und Klaus Müller, mueller.klaus@dpa.com
• Bearbeiter: Hans-Jürgen Ehlers Tel. 040/4113-xxxxx, hamburg@dpa.com

Berichtigungen

Bei Berichtigungen innerhalb des dpa-Notizblockes wird der zu berichtigende Abschnitt zusammen mit dem prinzipiellen Ansprechpartner gesendet, bei Änderungen im nichtöffentlichen Teil wird unmittelbar nach der Überschrift # dpa-Notizblock die Abrisskante gesendet.

dpa 1234 br 0456

Wohnungsbau/
(Berichtigung dpa-Notizblock)

   Bitte beachten Sie in der dpa 2346 (Experten fordern mehr Wohnungen - Hamburg/1234)
im Abschnitt Service die Änderung de ISBN-Nummer =

# dpa-Notizblock
## Service
- [Studie zum Wohnungsmangel](Meier-Verlag 2009. 300 S. Euro 35,00,
ISBN 300356345)

* * * *
Die folgenden Informationen sind nicht zur Veröffentlichung bestimmt

## dpa-Kontakte
- Redaktion: Maria Beispiel, Tel. +49 30 3456780, ‹Politik@dpa.com›

dpa abc yyzz n1 def

resp. bei Änderungen im nichtöffentlichen Teil.

dpa 1234 br 0456

Wohnungsbau/
(Berichtigung dpa-Notizblock)

   Bitte beachten Sie in der dpa 2346 (Experten fordern mehr Wohnungen - Hamburg/1234)
im Abschnitt Ansprechpartner die Änderung der Telefonnummer =

# dpa-Notizblock

* * * *
Die folgenden Informationen sind nicht zur Veröffentlichung bestimmt

## Ansprechpartner
- Max Mustermann, Eduard Pestel Institut für Systemforschung,
+49 511 xxxxxx, ‹m.mustermannr@pestel-institut.de›

## dpa-Kontakte
- Redaktion: Maria Beispiel, Tel. +49 30 3456780, ‹Politik@dpa.com›

dpa abc yyzz n1 def

Ich hoffe damit ist die Grundidee halbwegs verständlich erklärt, wer sich für Details interessiert kann sich gerne mit mir in Verbindung setzen oder hier kommentieren. Wer gerne selbst mit Markdown herumexperimentieren möchte, dem sein der Markdown Dingus ans Herz gelegt, in dem man interaktiv in einem Webfrontend herumexperimentieren kann, wie Markdown in HTML übersetzt wird.

[Update: ) Ganz vergessen: Hier ist ein (englischer) Text auf meinem privaten Blog in dem ich die ursprüngliche Idee festgehalten hatte. Der liefert noch ein paar zusätzliche Infos.