Wir bedanken uns bei allen Testern für das hilfreiche Feedback in der Beta-Phase und wünschen euch mit der App viel Spaß!

Kürzlich im abiapp.net-Changelog:

• Fundamentale Überarbeitungen an unserer Technik, die dafür sorgen, dass noch mehr Dinge auf abiapp.net sich jetzt live ändern, ohne dass ihr die Seite neu laden müsst

Dahinter versteckt sich nicht weniger als die komplette Umstrukturierung und Neuimplementierung des beinahe kompletten JavaScript-Quelltextes von abiapp.net – ein Vorgang, der sich über einige Monate gestreckt hat. In diesem Beitrag wollen wir etwas mehr dazu erzählen und auch für die Technikinteressierten unter euch zeigen, wie man mit den neuen Techniken herumspielen kann. :)

Neben einigen typischen abiapp.net-UI-Werkzeugen wie den „fliegenden Namen“ im Adminbereich, editierbaren Feldern (die gelb hinterlegten) und dem automatischen Umleiten von Formularsendungen als AJAX-Request besteht der JavaScript-Code von abiapp.net hauptsächlich aus Zeilen, die unser Haupt-UI-Feature verantworten: Die Live-Änderungen. Jede veränderte Eigenschaft, jeder neue Kommentar, fast alles was bei abiapp.net passieren kann wird live bei allen Usern die online sind, angezeigt, ohne dass die Seite neu geladen werden muss.

Aktuell läuft diese Technik über sekündliche AJAX-Requests (auf mobilen Clients seltener; in Zukunft ist eine Implementierung per Websockets geplant). Bisher war das so implementiert, dass es für jede Seite, auf der sich etwas ändern konnte, eigenen Code gab. Die AJAX-Requests enthielten eine Beschreibung der Seite und der Server antwortete mit Änderungen, die seit der letzten Anfrage geschehen sind. Was zunächst am einfachsten war, entwickelte sich schnell zu einer gigantischen Menge an Fallunterscheidungen. Schnell war klar, dass dieses System eines der ersten war, dass einer gründlichen Überarbeitung unterzogen werden sollte. „js-models“ hieß unser git-Branch – und der Name ist Programm: Auf Serverseite setzen wir Django ein, das wie die meisten Datenbankabstraktionen mit sogenannten Models (abstrakten Beschreibungen der Datenstrukturen) gearbeitet wird – so gibt es bei uns beispielsweise Models für Personen, Kommentare, Umfragen, Umfrageoptionen und vieles mehr. Äquivalente zu diesen Models sind nun auch JavaScript-seitig im Einsatz.

Was heißt das? Der Einfachste Weg für dich, hier unter die Haube zu gucken, ist, in der Javascript-Konsole einfach mal objects einzugeben. Schon siehst du alle Objekte, die aktuell auf dieser Seite existieren – geordnet nach Model. Clientseitig sind hier alle bekannten Eigenschaften über auf der Seite vorhandene Objekte gespeichert. Diese Daten werden automatisch aus dem DOM der Seite beim Seitenaufbau generiert. Alle Objekte enthalten in einem data-object-HTML-Attribut ihr Model und in einem data-id-Attribut ihre ID. Die Javascript-Models sind in der Lage, aus den gerenderten Objekten ihre Eigenschaften aufzulesen und zu speichern. Das tolle: Das geht auch umgekehrt – jede Änderung an einer Eigenschaft wird sofort überall im DOM ebenfalls geändert. Mehr dazu gleich.

Zusätzlich zu Javascript-Models existieren nun auch Listen. Diese sind via lists (bzw lists_by_type) einsehbar. Auch sie werden anhand von Attributen wie data-list und data-filter beim Seitenaufbau initialisiert. Listen haben die Aufgabe, verschiedene Objekte eines Models aufzulisten. Dabei kann es Kriterien geben, nach denen die Objekte, die in dieser Liste aufgeführt werden, ausgewählt werden (bei Kommentaren auf einer Personenseite sollen zum Beispiel nur Kommentare zu dieser Person geführt werden). Auch die Anzeige der Elemente in einer bestimmten Reihenfolge ist möglich. Listen halten sich automatisch aktuell, neue oder geänderte Objekte, die in die Liste passen, werde der Liste hinzugefügt (wir nutzen dafür EJS als Implementierung für Javascript-Templates – die Javascript-Templates findest Du in <script type="text/template">-Tags im HTML-Quelltext). Gelöschte Objekte oder Objekte, die durch eine Änderung nicht mehr in die Liste gehören, werden aus der Liste entfernt. Auch die Sortierung wird immer aktuell gehalten. Selbstverständlich werden alle diese Änderungen automatisch einheitlich animiert.

Was bringen uns die ganzen Models nun? Zum ersten eine Vereinheitlichung und eine deutliche verbesserte Übersichtlichkeit der Codes. Aber vor allem bedeutet es für uns, dass wir jetzt viel einfacher und an viel mehr stellen simpel Dinge live aktualisieren können. Und das geht nun teilweise bis in die kleinsten Details: Ändert sich der Name einer Person, ändert sich die Beschriftung aller Links auf dieser Person bei allen Benutzern! Zudem ist es jetzt möglich, dem Server sehr einfach mitzuteilen, welche Informationen benötigt werden – auch das Senden von nur einzelnen geänderten Eigenschaften ist möglich und für die Zukunft vorgesehen – so spart man noch mehr Bandbreite.

Aber genug der Theorie – wie kannst Du nun damit herumspielen? Ganz einfach, wir erklären dir wie du lokal mit der Javascript-Konsole Daten verändern kannst. Keine Bange, beim Ausprobieren kannst du nichts kaputt machen – lokale Änderungen werden nicht zum Server gesendet. Zwei Funktionen regeln alles:

update_object(type, id, data, user)
Ändere Daten eines Objekts, das durch sein Model (type, z.B. 'comment') und id definiert wird. Wenn das Objekt aktuell nicht bekannt ist, wird es angelegt. type und id kannst du aus der oben genannten Variable objects herausfinden. data sollte ein Javascript-Objekt mit neuen Werten für Eigenschaften sein, die geändert werden sollen. user kannst du weglassen, du kannst aber auch ein Object im Format {'name':'Frank Nord'} angeben – an allen Stellen auf der Seite, an denen dieses Objekt nun erscheint oder verändert wird oder verschwindet (gefilterte Listen) wird erscheint nun kurz dieser Name.

remove_object(type, id, user)
Entferne ein Objekt komplett. Die Parameter sind die selben wie bei update_object, nur dass hier keine Daten übergeben werden. Das Objekt verschwindet hiermit an allen Stellen der Seite, an denen es Dargestellt wird sowie ebenfalls aus allen Listen.

Beispiele:
Gehe auf eine Personenseite, auf der Kommentare angezeigt werden. Such dir einen Kommentar heraus, sodass du seine id weißt. Jetzt stehen dir folgende Möglichkeiten offen (id jeweils ersetzen):

// Verändert den Text dieses Kommentars
update_object('comment', id, {'text': 'lalala'})

// Erstellt einen neuen Kommentar zu der Person des gewählten
update_object('comment', 42, {'text': 'Neuer Kommentar', 'person': objects.comment[id].person})

// Ändert die Person, auf den sich der Kommentar bezieht (verschwindet aus der Liste)
update_object('comment', id, {'person': {'id':0}})

// Entfernt diesen Kommentar und Zeigt an dass eine Person namens „Ich“ das war.
remove_object('comment', id, {'name': 'Ich'})


Fragen? Immer her damit! Viel Spaß beim Erkunden! :)

Neue Stufe anmelden

Wir möchten uns an dieser Stelle bei den Abizeitungs-Komitees und den gesamten Abiturstufen 2014 des Geschwister-Scholl-Gymnasiums Mannheim, des Feudenheim-Gymnasiums Mannheim, des Ursulingen-Gymnasiums Mannheim, des Lieselotte-Gymnasiums Mannheim und des Uhland-Gymnasiums Tübingen für die konstruktive Mitarbeit bei den Tests und das vorgeschossene Vertrauen bedanken. Herzlichen Glückwunsch zum bestandenen Abitur euch allen!

Spannender als die Umfragen sind in dieser Hinsicht die Kommentare. Auf Wunsch einiger Schulen kann der Administrator inzwischen einstellen, wer sehen kann, wer einen Kommentar geschrieben hat. Um eure Privatsphäre jedoch nicht zu verletzten, wirkt sich diese Einstellung nur auf zukünftige Kommentare aus. Unter dem Kommentarfeld wird angezeigt, wer sehen kann, wer diesen Kommentar geschrieben hat. Wenn der Administrator diese Einstellung nachträglich ändert, gilt für vor dieser Änderung geschriebene Kommentare weiterhin das, was zum Zeitpunkt ihrer Erstellung galt.

Standardmäßig werden Kommentare anonym verfasst. Auch hier wissen die Server hinter abiapp.net natürlich, wer welchen Kommentar geschrieben hat (zum Beispiel damit nur derjenige den Kommentar zurückziehen kann, wenn das aktiviert ist). Es hat jedoch niemand aus eurer Stufe Zugriff auf diese Informationen, auch der Administrator nicht. Bereits kurz nach dem Start von abiapp.net mit unseren ersten Testschulen kamen jedoch die ersten Anfragen nach den Identitäten von Kommentarautoren um beleidigende Kommentare aufzuklären. Wir haben jedoch beschlossen, solche Anfragen grundsätzlich nicht zu beantworten und unser Anonymitätsversprechen zu halten, sondern einen anderen Weg zu wählen.

abiapp.net enthält bereits eine „Streichen“-Funktion für Kommentare, die es (je nach Einstellung) der Redaktion, dem Administrator oder jedem Schüler auf seiner eigenen Seite erlaubt, einzelne Kommentare vom Druck auszuschließen. Trotzdem kann es sehr nervig sein, wenn einzelne einen beleidigenden Kommentar nach dem anderen hinterlassen. Deswegen haben wir eine Funktion eingebaut, die wir „Anonymes Blockieren“ nennen. (Damit ihr sie nutzen könnt, muss euer Admin sie aktivieren.) Die Idee dahinter ist folgende:

Wenn jemand einen verletzenden Kommentar erhält, kann er den Kommentar streichen und zusätzlich den Autor des Kommentars blockieren. Der Autor des Kommentares kann dann zu diesem einen Schüler keine weiteren Kommentare schreiben, bis die Blockierung aufgehoben wird. Auf diese Weise kann Missbrauch der Kommentarfunktion eingeschränkt werden, ohne die Anonymität zu durchbrechen, denn es wird nicht verraten, wer der Autor ist.

Dadurch kann natürlich auch nicht verraten werden, welche Kommentare vom gleichen Autor stammen. Wenn also Felix fünf beleidigende Kommentare auf seiner Seite vorfindet, weiß er nicht nur nicht, von wem sie stammen, sondern auch nicht, von wie vielen Personen sie stammen. Er muss also alle fünf einzeln blockieren, auch wenn sie alle nur von einem Autor stammen, wenn er sicher gehen möchte, dass er keine weiteren Kommentare dieser Art erhält. Der Autor sieht dann statt des Kommentarfeldes nur noch die Meldung:

Du wurdest für diese Seite gesperrt.
Du hast dieser Person Kommentare hinterlassen, die unangemessen oder verletzend waren und darfst hier deswegen keine weiteren Kommentare schreiben. Bitte nimm mit Felix oder eurer Administratorin (Petra A.) Kontakt auf, um das Problem zu lösen.

Wir halten das für die eleganteste Lösung, mit Missbrauch bei anonymen Kommentaren umzugehen. Trotzdem bitten wir euch sehr, einfach gleich fair und freundlich zu sein und keine verletzenden Kommentare zu schreiben. Es macht niemandem Spaß, so etwas zu lesen.

Obwohl die mobile Website gut funktioniert und alle Features der Computer-Variante enthält, gab es noch ein paar Punkte, die den Spaß einschränken: Man muss sich ein Lesezeichen anlegen oder ständig die Adresse eintippen; dann muss man sich regelmäßig neu einloggen, was insbesondere nervig ist, wenn man sich über Facebook einloggt und auf dem Handy nicht auf der Facebook-Website eingeloggt ist; und außerdem ist die Navigation sperrig zu bedienen. Um diese Probleme zu lösen haben wir uns jetzt, obwohl wir das ursprünglich nicht wollten, entschieden, eine Android-App zu veröffentlichen.

Die App entspricht im Groben der mobilen Website, enthält allerdings einige Vorteile und Verbesserungen. Man muss sich nur einmalig einloggen, dann bleibt man auf dem Gerät eingeloggt. Wenn man sich über Facebook einloggen möchte, kann man das unter Verwendung der Facebook-App tun. Ist die Facebook-App nicht installiert, ist das auch kein Problem.

Die Navigation integriert sich ins Android-System. Statt als lange Liste oben auf der Seite Platz zu klauen, steht sie immer links als „Schublade“ bereit, wie man es aus zahlreichen anderen Apps von YouTube bis Google Mail kennt.

Die App hilft außerdem dabei, Akku und Datenverkehr zu sparen. Um immer alle Daten live anzuzeigen, müssen App und Website regelmäßig mit dem abiapp.net-Server kommunizieren. Im Gegensatz zur Website weiß die App aber um den Status des Gerätes und reduziert die Häufigkeit dieser Abfragen abhängig davon, ob gerade WLAN oder Mobilfunk zur Kommunikation verwendet wird.

Die App ist ab sofort im Google Play Store verfügbar:

Auf die naheliegende Frage, ob es auch eine App für iOS geben wird, können wir nur vorläufig antworten: Wir haben derzeit nicht die zeitlichen, personellen und finanzellen Ressourcen um eine iOS-App zu entwickeln. Die Kosten sind hier deutlich höher als bei Android und unser Team verfügt hier über deutlich weniger Erfahrung. Wenn abiapp.net erfolgreich wird, werden wir aber sicherlich die Entwicklung einer iOS-App verfolgen. Solange müssen sich iPhone-Besitzer mit der mobilen Website zufrieden geben – sorry! Für Verbesserungsvorschläge zur mobilen Website sind wir natürlich immer offen, wenn wir euch damit das Leben erleichtern können. Unter hallo@abiapp.net stehen wir euch zur Verfügung.

Fakt ist, dass einige Kosten entstehen. Selbst wenn man von den unzähligen Stunden, die wir in dieses Projekt stecken, absieht, zahlen wir für den reibungslosen Betrieb jeden Monat Servermiete und weil wir uns wünschen, dass das Projekt ein Erfolg wird, geben wir eine für uns Studenten recht große Menge Geld für Werbung aus, denn von ganz allein wird man dann doch nicht bekannt. Wir mussten also irgendeinen Weg finden, zumindest die laufenden Kosten zu decken. Wir glauben aus folgenden Gründen, dass eine kleine Gebühr nicht nur für uns, sondern auch für euch die beste Lösung ist.

Natürlich hätten wir die laufenden Kosten aus unserer eigenen Tasche bezahlen und abiapp.net völlig frei anbieten können. Dann müssten wir auf Werbung verzichten, aber könnten das Projekt auf Sparflamme durchaus betreiben. Das Problem ist nur: Auch wir müssen unsere Miete bezahlen und ein Projekt, das Geld kostet statt einzubringen, läuft in die Gefahr, langfristig vernachlässigt und nicht weiter gepflegt zu werden. Anderen Projekten ist das passiert. Das Internet ist voll von nett gemeinten Projekten, die irgendwann der Stillstand befallen hat. Das wollen wir nicht, dafür ist uns abiapp.net zu schade. Wir wollen euch auch in Jahren noch nicht nur eine moderne, erstklassige Plattform bieten, sondern vor allem auch einen Support, der euch auf alle eure E-Mails freundlich und kompetent antwortet, Fehler schnell behebt und stetig neue Funktionen hinzufügt.

Die offensichtliche Möglichkeit, mit einer Internetseite Geld zu verdienen, ist natürlich Werbung. Wir hätten abiapp.net mit Werbung versehen können. Oben eine Linkzeile, unten ein blinkendes Banner, rechts eine bunte Anzeige und bei jedem zehnten Seitenaufruf ein Fenster, das sich quer über den Inhalt schiebt. Im Ernst, das will niemand. Wir glauben nicht, dass ihr die Seite gerne benutzen wollen würdet, wenn sie mit Werbung vollgestopft wäre. Und wir wünschen uns, dass ihr sie gerne benutzt. Jeden Tag, ein ganzes Jahr lang. Das macht keinen Spaß mit Werbung.

Wer das ernsthaft benutzen wollte, würde einen AdBlocker verwenden und das Projekt würde wieder nichts abwerfen. Außerdem sind wir zu klein, um ein eigenes Werbenetzwerk aufzubauen und hätten Werbung über ein Netzwerk wie Google einbinden müssen, dabei halten wir es für ethisch verwerflich, die Daten unserer Nutzer einem anderen Anbieter auf dem Silbertablett zu präsentieren. Fazit: Wir wären unglücklich, ihr wärt unglücklich.

Die andere Möglichkeit wäre ein Sponsor gewesen, zum Beispiel eine große Abizeitungs-Druckerei, die uns finanziert und an die wir uns anhängen. Das wäre für euch auf den ersten Blick bequem, es gäbe nur ein wenig erträgliche Werbung und die Benutzung würde euch nichts kosten. Auch für uns wäre es bequem, wir hätten ein sichereres Einkommen mit dem Projekt und müssten weniger stark dafür kämpfen, mehr Schulen von uns zu überzeugen. Wir sind Sponsoring nach wie vor nicht vollständig abgeneigt, aber es gibt auf den zweiten Blick einen ganz gewichtigen Grund, warum wir uns nicht komplett über Sponsoring finanzieren wollen. Der Grund klingt erst einmal sehr offensichtlich, hat aber große Auswirkungen: Ihr wärt nicht unsere Kunden. Unser Kunde wäre der Sponsor, ihr wärt eher Ware, die wir dem Sponsor anbieten.

Bekanntlich ist der Kunde König, und das bedeutet, dass wir in allen unseren Entscheidungen über beispielsweise die Entwicklung von neuen Funktionen nicht darüber nachdenken müssten, was euch am besten gefällt, sondern was unserem Sponsor am besten gefällt oder am meisten nützt. Uns ist es deutlich lieber wenn ihr unsere Kunden seid und wir damit euren Interessen verpflichtet, und euch wahrscheinlich auch.

All diese Gründe legen nahe, statt uns abhängig zu machen oder euch mit Werbung zukleistern, klar und ehrlich eine einmalige Zahlung von euch zu verlangen – ohne versteckte Kosten, ohne Datenverkauf, ohne fremde Interessen. Damit lösen sich all die oben genannten Interessenkonflikte in Luft auf. Und wir glauben wirklich, dass wir einen Preis festgelegt haben, den jede Stufe zahlen kann. Der Druck von Raphaels Abizeitung (es war eine kleinere Schule) hat etwa 1.300 € gekostet – unsere Gebühr von 60 € bzw. 35 € ist dagegen wirklich verschwindend. Und wir geben uns alle Mühe, dass wir das Geld wert sind.

Ein paar Worte vorweg. Grundsätzlich gibt es zwei Möglichkeiten: Ihr könnt zu einer der mittlerweile zahlreichen Internetdruckereien gehen, die sich auf den Druck von Abizeitungen spezialisiert haben. Auf Grund der Größe und Spezialisierung können diese Anbieter euch meist einen besseren Preis machen. Die andere Möglichkeiten sind lokale Druckereien bei euch in der Nähe. Die sind meist etwas teurer, aber können oft kurzfristiger liefern und es ist manchmal leichter, wenn man jemanden hat, mit dem man direkt reden kann. Am Besten holt ihr euch von beiden Arten von Druckereien Angebote ein und entscheidend dann nach Preis und Sympathie.

Druckmuster. Insbesondere die auf Abizeitungen spezialisierten Anbieter bieten meist an, euch kostenlose Muster zuzuschicken: Entweder eine andere in dieser Druckerei gedruckte Zeitung oder einen „Musterkatalog“, der dann meist die verschiedenen angebotenen Papier- und Druckarten enthält. Wenn ihr mit der Suche nicht allzu knapp dran seid, macht davon Gebrauch!

Flexibilität. Wenn ihr dann Angebote eingeholt habt, achtet darauf bzw. fragt nach, ob ihr euer Angebot ohne böse Überraschungen im Preis noch abändern könnt, zum Beispiel, wenn ihr plötzlich doch 20 Seiten mehr oder weniger braucht oder doch mehr Exemplare drucken wollt. Eine seriöse Druckerei wird euch grob sagen können, auf welche Art sich das im Preis bemerkbar macht.

Abgabe- und Liefertermin. Wenn ihr ein Angebot akzeptiert, achtet darauf, dass der Liefertermin und der Termin, zu dem ihr die Daten abgegeben haben müsst, fest im Angebot oder der Auftragsbestätigung stehen, damit es hinterher keine Missverständnisse gibt und die Zeitung erst nach eurem Abi kommt. Manche Druckereien bieten kostenlos an, dass ein Grafiker der Druckerei nochmal vor Druck über die Zeitung schaut, ob technisch alles in Ordnung ist. Viele Druckereien liefern euch einen Vorabdruck zur Kontrolle. Nutzt das und plant ein bisschen Zeitpuffer ein, falls ihr noch Dinge ändern müsst.

Auflagengröße. Bei der Entscheidung, wie oft ihr eure Abizeitung drucken sollt, können wir euch keinen wirklich guten Tipp geben. Wir selbst sind bei unserer Abizeitung mit dem zwei- bis dreifachen der Schülerzahl recht gut gefahren, aber das ist von Schule zu Schule stark unterschiedlich und ihr solltet natürlich immer auch das finanzelle Risiko im Blick behalten, das ihr nicht alle los werdet. Am besten ist, ihr fragt mal beim letzten Jahrgang eurer Schule nach, vielleicht haben die Erfahrungswerte für euch.

Farbe oder schwarz-weiß. Das ist eine grundlegende Entscheidung, die ihr treffen müsst. Schwarz-Weiß-Druck ist deutlich günstiger, aber eine Abizeitung mit Farbfotos hat unabstreitbar ihren Wert. Viele Druckereien bieten es an, manche Seiten schwarz-weiß und manche farbig zu drucken. Das kann ein guter Kompromiss sein, wenn ihr knapp im Budget seid.

Grammatur/Papierstärke. Die Stärke von Papier wird in Gramm pro Quadratmeter gemessen. „Normales“ Druckerpapier hat üblicherweise 80g/m², College-Blöcke manchmal nur 70g/m². Für die Innenseiten einer Abizeitung sind, insbesondere wenn ihr Fotos druckt (die ja nicht durchscheinen soll), durchaus Stärken von 135g/m² angemessen. Ein bisschen weniger ist nicht schlimm (ab 100g/m² ist wohl in Ordnung), mehr als 135g/m² ist eher unnötig und unhandlich. Häufig liest man den Werbebegriff „Bilderdruckpapier“. Das ist meist durchaus eine gute Wahl.

Bindung und Umschlag. Auch wenn die Druckereien oft teure Hardcover-Bindung anbieten, haben die meisten Abizeitungen eine Softcover-Bindung (auch „Taschenbuch-Bindung“ genannt). Wenn eure Abizeitung sehr sehr dick wird, kann man Ringbuchbindung überlegen, aber wir würden es vermeiden. Der Umschlag ist dabei auch aus Papier, das aber deutlich dicker seien sollte als die Innenseiten. Das absolute Minimum ist in unseren Augen 300g/m², wenn die Druckerei mehr anbietet, nehmt mehr, der preisliche Unterschied ist meist gering. Während wir bei den Innenseiten eine „Veredelung“ oder „Kaschierung“ für unnötig halten, ist sie hier sinnvoll. Ob glänzend oder matt, solltet ihr anhand eures Motivs entscheiden, was besser passt. Prägungen und Sonderfarben könnt ihr machen, wenn das absolut perfekt zu eurem Design passt, ansonsten lohnt es das Geld nicht.

Alle Angaben und Tipps in diesem Artikel haben reinen Empfehlungscharakter, basieren auf unseren Erfahrungen und wir können keine Garantie für Richtigkeit übernehmen.

Wenn ihr Adobe InDesign benutzt, empfehlen wir den Export nach XML, zu dem es demnächst ein gesondertes Tutorial geben wird, wie ihr die Daten automatisch in InDesign einfügen könnt. Wenn ihr jemanden habt, der gerne selbst ein bisschen programmieren kann und mit den Daten arbeiten möchte, bieten wir mit XML und JSON gute Möglichkeiten. In allen anderen Fällen bist du in diesem Tutorial richtig: Hier empfehlen wir den Export nach HTML. Auch wenn der Auspackvorgang der Datei etwas gewöhnungsbedürftig ist, glauben wir, dass es für den eigentlichen Layoutprozess die praktischste Möglichkeit ist. Diese Anleitung erklärt, wie ihr mit den HTML-Dateien umgehen müsst.

Schritt 1. Zuallererst musst du den Exportvorgang starten. HTML ist dort bereits standardmäßig ausgewählt.

Wenn der Exportvorgang fertig ist, was durchaus einmal einige Minuten dauern kann, wird dir eine .zip-Datei zum Download angeboten. Eine .zip-Datei ist eine Art „Paketdatei“, die andere Dateien und ganze Ordner enthalten kann. Wenn ihr Fotos hochgeladen habt und beim Export ausgewählt habt, kann die Datei durchaus groß werden. Wir empfehlen, zum Testen der Dateiformate erst einmal ohne Fotos zu exportieren und dann noch einmal mit Fotos oder die Fotos einzeln.

Schritt 2. Auch wenn Windows es anbietet, du solltest die Dateien in dem .zip-Paket nicht direkt öffnen sondern musst erst das Paket entpacken. Dazu wählst du oben in der Werkzeugleiste „Extrahieren“. Daraufhin öffnet sich eine Ortsauswahl. Wichtig ist, dass du nicht auf einen der Orte sondern rechts auf „Alle Extrahieren“ klickst. Daraufhin kannst du trotzdem noch auswählen, wohin extrahiert werden soll. Am besten legst du einen neuen Ordner an.

Der Ordner, in den du exportiert hast, wird automatisch in einem neuen Fenster geöffnet.

Schritt 3. Öffne die Datei „index.html“ (evtl. wird nur „index“ angezeigt) mit einem Browser. Wenn neben der Datei bereits wie unten im Screenshot z.B. ein Chrome- oder Firefox-Symbol angezeigt wird, kannst du sie einfach per Doppelklick öffnen, ansonsten musst du per Rechtsklick → „Öffnen mit“ erst einen Browser (Chrome, Firefox, Opera, Safari, Internet Explorer, …) auswählen.

Schritt 4. Voìla! Es sollte sich jetzt ein Browserfenster mit den Exportdaten geöffnet haben. Du hast links eine Navigation, in der du zwischen den verschiedenen Bereichen hin- und herwechseln kannst, und rechts die jeweils ausgewählten Daten.

Du steckst fest oder hast noch Fragen? Unter hallo@abiapp.net erreichst du uns, wir helfen dir gerne weiter. Wir freuen uns auch immer über Feedback und neue Vorschläge zum Export.