Oder möchtest du dich noch lange mit hässlichen, zerklütterten Editing Interfaces herumschlagen, Felder für andere Zwecke missbrauchen und dabei arme Kittens umbringen?

Anfänglich in den 90er Jahren gab es HTML. Content Management gab es eigentlich nicht und strukturierten Inhalt sowieso nicht. Es gab lediglich ein weisses Textfeld und dort konnte man in hübschen Tabellen Inhalt erstellen. Freiheit pur, aber lediglich für den Webmaster (irgendwann kamen dann die animierte GIFs was aber die Sache nicht wirklich besser machte).

(Den musste ich hier einfach reinmachen)

Dann irgendwann kam PHP, CSS und MySQL und die ersten System wurden gebaut. Allerdings bestanden die Systeme damals meistens aus einem Titel- und einen Bodyfeld. Nüchtern betrachtet also immer noch ein gähnend weisses Feld mit dem einzigen Unterschied, dass es in einer Datenbank und nicht in einem HTML File gespeichert wird.

Zum Glück sind wir da nicht stehen geblieben. Irgendwann kam Drupal und mit Drupal CCK und brachte uns Fields. Damit war es möglich, Inhaltstypen zu bauen mit 100 verschiedenen Feldern: Titel, Datum, Ort, Autor, Twittername, Webseite, Adresse, Preis und und und.

Jede Information wird in möglichst kleine Entitäten aufgeteilt, um höchst mögliche Flexibilität auch in Zukunft zu gewähren. Um den Namen abzubilden gibts nicht mehr nur ein Textfeld sondern gleich drei: Vorname, Mittelname und Nachname.

Mittlerweile ist es wohl bei jedem CMS in der einen oder anderen Form vorhanden (so übrigens auch in WordPress, aber nicht in Ghost).

Als Ex-Drupalianer ist ein Systemverliebter Entwickler unverkennbar.

Wenn man der Jen Simmons von The Web Ahead zuhört, ist ihre Liebe für Drupal unverkennbar. Klick, klick und schon ist ein Inhaltstyp erstellt, ein paar Felder hinzufügen und mit Views verbauen und hier und da wiederverwenden. Ein mächtiges Tool.

It’s true. We’ve both worked with Drupal. I know, for me, that’s shaped deeply my thinking around this stuff. Because it’s so easy to do this in Drupal. You just clickity-click and, «Look, I have another field! What kind of field do I want? Do I want a text, date, location, image, or file field?» There are flavors of fields. You can change the name, you can change the help text, you can rearrange the order, you can rearrange the order of the display. You can add filters and all sorts of fancy, complicated filers to make decisions about which content to display.

Resultat dieser Architektur: Ein sehr vielseitig einsetzbares und stabiles aber komplexes System, welches allerdings auf seine Art auch inflexibel ist. Zudem wirken die unzähligen, nicht geordneten Felder mit den unbrauchbaren standardisierten Hilfetexten abschreckend und verführen nicht zu kreativem Schreiben (kommt das jemandem bekannt vor?). Manche Backend Seiten gleichen manchmal einem Lückentext aus der ersten Klasse.

Dabei ist der Entwickler stolz auf seine Leistung, während der Schreiber vom System enttäuscht und verwirrt ist.

Weniger ist manchmal mehr

Ich behaupte, dass wir in Zukunft von solchen hochkomplexen und strukturierten Interfaces wegkommen hin zu schönen intuitiven für den User gebauten Interfaces. Diese Interfaces zeigen sich dadurch aus, dass sie nicht die Datenstruktur widerspiegeln, sondern die Benutzerlogik.

Bestes Beispiel dafür ist Medium. Viel Drag and Drop, sehr schönes Layout und sehr einfach zum Editieren. Es funktioniert einfach und ich war von Anfang an sehr begeistert. Schreiben wird hier nicht zur Qual sondern macht Spass.

Auch andere gehen diesen Weg: Für WordPress gibts ein Addons mit Namen «Aesop Story Engine«, welche noch mehr bietet als Medium, aber bei meinem letzten Versuch noch nicht ganz so flüssig läuft.

Auch hier: Einfache Interfaces, aber dennoch mächtige Features.

Interessanterweise entwickeln sich auch die Datenbanktechnologien in diese Richtung (oder ist es die Datenbanktechnologie, welche sich entwickelt und die Systeme, welche folgen?). Während in MySQL der Inhalt normalisiert und strukturiert wird, gibts bei den NoSQL Datenbanken lediglich ein Dokument (z.B. eine Seite), welche alle benötigten Informationen beinhaltet (unter umständen auch Redundanzen).

Kommt Zeit, kommt Rat

Blogs werden sicher am Schnellsten adaptieren, da es am Einfachsten ist, doch ich hoffe, dass auch komplexere Anwendungen folgen werden, so dass schlussendlich auch für komplexe Systeme keine Schulung und keine Techniker mehr notwendig ist, sondern der normale Marketeer die Texte schreiben kann.

Melde dich doch für den Newsletter an.