Schau dir doch mal viele Seiten an, dort ist “Typo im Web” ein Fremdwort, ebenso wie Artikelformatierungen. Es gibt mittlerweile doch mehr als genügend Lösungen solch einen Artikel-Gau zu verhindern. Jeder Editor lässt sich beschneiden, das ist nicht die Boshaftigkeit, wenn ich einem Kunden keine 35 verschiedenen Formatoptionen im TinyMCE zur Verfügung stelle, sondern Vorsorge.

Es gibt ja tolle Extensions, welche ganz einfach erlauben selbst BB-Code für die Editoren zu integrieren. Wo ist das Problem frage ich mich, dem Kunden ein PDF zur Verfügung zu stellen und zu sagen: “Passen Sie auf, das hier sind Ihre Formatierungsoptionen”. Neben Fettschrift, Italic und Underline - hat der Autor dann eben noch vorgefertigte Möglichkeiten. [hinweis]Dein Text[/hinweis] - könnte so eine sein. Das ganze wird dann flott im Dein Text ausgegeben.

Es gibt ja den schönen Spruch “simplify your Work” - warum das nicht auch auf Editoren anwenden ? Nur weil das Web inzwischen unzählige Optionen mittels Editoren ermöglicht, bedeuted das noch lange nicht das diese auch sinnvoll sind. Ich glaube nämlich das Web verlangt zuviel vom User, nicht wir. Meine Autoren haben einen minimalistischen Editor, der nur Dinge erlaubt, die eben keinen Artikel-Gau produzieren können. Die Grundformatierungen werden eh vom Artikeltemplate gehalten, alle weiteren sind durch speziell an die Bedürfnisse angepasste BB-Code-Optionen. Da hat der Autor ein PDF und kann, sofern er etwas besonders hervorheben möchte, sich den entsprechenden Tag raussuchen. Nach ein paar mal verstehen die meisten das auch ohne auf das Cheatsheet zu schauen.

Jemand der sich nicht einmal mit solchen Optionen zurecht findet, der sollte vielleicht hinterfragen ob es nicht vielleicht sinnvoller wäre, Inhalte vom Professionellen seines Vertrauens pflegen zu lassen. Wenn ich mir keinen Tisch bauen kann, dann geh ich zum Schreiner. Wenn mein Auto kaputt ist, dann fahre ich in die Werkstatt und wenn der Webdesigner es nicht fertig bringt, seinen Kunden in klarer Sprache zu erzählen auf was es ankommt und was der Kunde eventuell selbst machen kann und was wohl besser mit in die Seitenpflege integriert werden sollte, dann hat der oder die gute seinen/Ihren Beruf verfehlt.

Ich bin nach wie vor der Meinung, das jemand mit einer prof. Webseite, seine Inhalte auch professionell einstellen und pflegen lassen sollte. Nur weil es Editoren gibt und die Umwelt einem erzählen möchte das dank Joomla & Co. nun jedes Kind eine Webseite betreiben kann, ist es noch lange nicht wahr.

Aber da rutschen wir wieder in die Endstation: “Frank ist jetzt ein Webdesigner” ab.

Problem hierbei ist auch, das der TinyMCE und auch alle anderen Editoren mit dieser Funktionalität, Divs und Spans beim Backspace ganz gern mal löschen. Heißt ich habe beispielsweise ein für den Autorennamen, so löscht der Autor die Vorgabe “Max Mustermann”, logisch - wenn er allerdings einmal zuviel löscht, dann hat er diesen nicht mehr. Bei umfangreichen Artikeltemplates ist das natürlich problematisch. Angenommen das passiert beim vorletzten Imput-Element, da gehen die Jungs&Mädels an die Decke. Ein paar mal wenn das passiert und niemand möchte mehr mit “Artikeltemplates” arbeiten.

Sinnvoll wäre also auch hier eine Erweiterung der Editoren, die anhand eines Merkmals, welches man einem Element mit auf den Weg gibt, deklarieren, das der Editor selbiges nicht löschen darf.

Das ist ein Manko was wohl jedes Content Management System mit sich rumschleppt. Meiner Meinung nach nicht verständlich. Es wird sich überall beschwert, das Autoren und Webseitenbetreiber aus einer hübschen Seite, mit Ihren “eigenwilligen” Word-Schönheitsidealen, die komplette Website verhunzen.

Weshalb kam noch nie irgendjemand auf die Idee, das ganze endlich mit in ein CMS zu integrieren. TypoLight geht ja schon mal den ersten Schritt. Ich halte das “kopieren” allerdings nicht für sonderlich sinnvoll, denn hat man mehrere Artikelbereiche und entsprechend auch andere Artikelvorgaben, so müsste sich der Autor jedesmal durch die Liste wühlen und den letzen Artikel einer bestimmten Kategorie heraus suchen. Das ist keine zumutbare Alternative.

Zumal, es müssten einfach ganz klare Benennungen für die Inputs und Textfelder vorhanden sein. Habe ich beispielsweise eine Ausgabe, so wäre es unnötig einen Editor für dieses Feld zur Verfügung zu stellen, lediglich die Bezeichnung und eine Inputrow müssten zu sehen sein.
Schön strukturierte und etwas aufwändiger gestaltete Inhalte müssen also weiterhin auf “Inhaltstemplates”, die in die Editoren geladen werden, zurückgegriffen werden.

Wie blöd. Auch von Entwicklerseite.

Ist es denn so ungewöhnlich das man sich um Typo und Darstellung/Anordnung der Inhalte auch kümmern möchte ? Ich könnte mir das ganze im Typoschema schön vorstellen.

Input: Headline
Input: Autor
Input: Create_date
Input: Article_image ( Upload-Feld)
Textbox: Teaser
Textbox: Article Text
Textbox: Quellverweise / Links / etc.

Der Vorteil würde doch klar auf der Hand liegen. Man könnte den Autoren eine einheitliche Struktur vorgeben, die das einheitliche Aussehen der Webseite und deren Inhalte festlegt. Man hätte wesentlich mehr möglichkeiten, auch umfangreiche Archive Aufzubauen, die Daten nicht in Textform beinhalten. Man hätte verdammt viel mehr Möglichkeiten.

Ben