praegnanz.de büro für intervernetzte medien

Gerrit, 01.10.2008

WYSIWYG in CMS – gut oder schlecht?

Da die Diskussion bei den CMSen ein wenig abschweift, aber hochinteressant bleibt, ziehe ich einige der dortigen Kommentare zu diesem Beitrag rüber. Angefangen hat Johann:

Das wollte ich schon immer mal diskutieren:
Was ich bis heute nicht verstehe ist, was ein WYSIWYG-Editor in einem CMS zu suchen hat wo es doch heißt »Trennung von Inhalt und Layout«. Durch so einen Editor suggeriert man dem Redakteur doch, dass er hier die Inhalte gestallten soll, anstatt semantisch zu gliedern. Es sollte doch eher ein Semantik-Editor entwickelt werden der dem Redakteur hilft, sein ohnehin gegliedertes Manuskript schnell eingeben zu können. Selbst Bildgrößen bestimmt noch immer der Designer und nicht der Redakteur oder? Bei herkömmlichen CMS geht mir da munter einiges durcheinander. Warum?
Ich behaupte, dass hier die Ursache liegt, warum CMS so starr sind. Solange ein CMS keine Ahnung von der Semantik der Inhalte hat, kann es keine Möglichkeiten für effiziente und intelligente Nutzung der Inhalte anbieten.

Ich schalte mich auch bald ein ;-)

47 Kommentare

  1. Gregor Nathanael Meyer am 1. Oktober 2008 #

    @Johann Heyne: Da stimme ich Dir voll zu. TYPO3 und TYPOlight sehen hierfür Möglichkeiten vor. Eine krasse Stilblüte leistet sich hier TYPOlight: Es zwingt einem die Aufteilung in Artikel (in den Seiten) auf, die wiederum verschiedenste Inhaltselemente enthalten müssen (Überschriften, Texte, Bilder, Listen, Widgets etc.). Soweit so gut. Aber jedes Textelement lädt wiederum einen voll ausgestatteten WYSIWYG-Editor, wo dem Redakteur doch wieder Tabellen, Listen und Bilder zur Verfügung stehen. Zusätzlich gibt es unter dem WYSIWYG-Feld der Textelemente noch mal die Möglichkeit, ein Bild anzuhängen, dessen Position vom Template bestimmt wird.

    Also erst mal umständlich (und zwangsweise) nach semantischem Inhalt trennen und dann doch wieder alles per WYSIWYG erlauben kann ich kleinen Kunden nicht verkaufen. Da gefallen mir Silverstripe und ModX besser: Da ist der Einsatz von WYSIWYG wenigstens stringent.

  2. Anne-Kathrin am 1. Oktober 2008 #

    @GN Meyer:

    Jein…. Man kann in TYPOlight – und das sehe ich als ehemaliger Joomla User nun wirklich als Errungenschaft an-, sehr granular die Rechte vergeben. Auf jedes einzelne Element, als0 auch auf Inhaltselemente.
    Es mag lieber in Frage gestellt werden, ob dieses Inhaltselemente wie Tabelle wirklich sinnvoll sind. Aber abschalten kann man das alles.

    Und dann sollte vielleicht noch erwähnt werden, dass man den Tiny MCE wirklich easy going abspecken kann. Und so sollte man das auch machen: Farbpalette & Co. rausschmeißen, ein paar aussagekräftige Styles anbieten und schon hat sich das Problem des Wildwuchses, der mitunter zu Katastrophen führen kann, erledigt.

    Interessant finde ich die Sache mit dem semantischen, etwas intelligenteren Editor. Mit einer DTD ist das natürlich alles kein Problem, siehe XML Editoren.

    Erstmal muss man vor allem eines: dem Benutzer das Copy und Pasten aus Word abgewöhnen, ich kenne kaum einen Fall, in dem da nicht doch irgendwelche Altlasten geblieben wären…

  3. Christian am 1. Oktober 2008 #

    Ich löse das bei MODx, indem ich dem User entweder den WSYIWYG-Editor stark einschränke (auf Einzel-Artikelseiten zB) oder sogar ganz wegnehme und statt dessen nur TemplateVariablen (für nicht MODxler: Quasi frei definierbare Textfelder, Bilder, Dateien, …) anbiete.
    Damit kann er verschiedene Inhaltsbereiche der Seite füllen wie er mag und um das Aussehen kümmere ich mich vorher.
    Und der Autor füllt Felder namens »Überschrift«, »Teaser«, »Intro« usw aus und macht sich so automatisch mehr Gedanken um Inhalte als um Formatierung, weil er auf die ja eh keinen Einfluss hat.

  4. Christian am 1. Oktober 2008 #

    Ach ja:
    : Erstmal muss man vor allem eines: dem Benutzer
    : das Copy und Pasten aus Word abgewöhnen, ich
    : kenne kaum einen Fall, in dem da nicht doch
    : irgendwelche Altlasten geblieben wären

    Dafür nutze ich (ich nutze TinyMCE) das PlugIn Paste, das auch die Funktion »Paste from Word« beinhaltet. geht recht gut. Den »normalen« Paste-Button blende ich aus.
    http://wiki.moxiecode.com/index.php/TinyMCE:Plugins/paste

  5. Gerrit am 1. Oktober 2008 #

    Bisher haben wir bei Kunden keine üblen Erfahrungen mit Markdown gemacht, wobei wir immer eine Reihe von proprietären Syntax-Erweiterungen hinzugefügt haben, um zum Beispiel interne Seiten per ID zu verlinken oder Bilder ohne Pfadangabe einzufügen. Wichtig dabei: Der Kunde darf kein HTML sehen, sonst fürchtet er sich.

    Inzwischen denke ich, dass ein stark abgespeckter Editor, bei dem man beispielsweise lediglich Formatvorlagen für Headings, Zitate und Listen benutzen kann, auch nicht komplett zu verdammen sind. Vor allem die Platzierung von Bildern im laufenden Text ist schon intuitiver, wenn man sie auch gleich sieht. Und das leistet eine simple Textarea mit plain text nun mal nicht…

  6. Pepino am 1. Oktober 2008 #

    Textile und gut is‹ :-)

  7. Alexander Langer am 1. Oktober 2008 #

    Und wie unterbindet man das kundenseitige Strg-V / Cmd-V? So ganz idiotensicher bekommt man es nicht hin. Bei reiner Texteingabe bleiben zusätzliche Möglichkeiten auf der Strecke, oder aber müssen mit anderen Krücken abgebildet werden.

    Letzten Endes kann man sich einem Ideal wohl stets nur annähern, ohne es jemals zu erreichen.

  8. Achim Musall am 1. Oktober 2008 #

    Für mich liegt hier durchaus auch ein Vorteil von Typo3. Typo3 hat wie alle CMS einen üppigen WYSIWYG-Editor, den man nach Bedarf abspecken kann. Traditionell werden aber z.B. Bilder nicht über den WYSIWYG-Editor eingepflegt, sondern haben eine eigene Maske (die Möglichkeit Bilder über den WYSIWYG-Editor einzupflegen, deaktiviere ich bei fast jedem Kunden).

    Darin lassen sich dann Bildunterschriften, Alt-Tags, Title-Tags, Aufteilung der Bilder (z.B. übereinander oder nebeneinander), Anordnung der Bilder zum Text (über dem Text, vom Text umflossen links etc.), Bildgröße, Verlinkung festlegen.

    Im Ergebnis habe ich dann keinen Spaghetti-Code in dem Redakteur seinen Unwesen treiben kann, sondern einen sehr robusten validen Quellcode.

    Der größte Vorteil ergibt sich vor allem bei Änderungen. Ob es besser aussieht, die Bilder in zwei Spalten nebeneinander links vom Text zu platzieren oder lieber in einer Reihe oberhalb des Textes, kann man mal eben interaktiv mit zwei Klicks ausprobieren. Bei einem WYSIWYG-Editor kriegt man das eigentlich kaum hin, denn da ist einfach Strg-V / Cmd-V angesagt.

  9. Steffen am 1. Oktober 2008 #

    Sowas sehe ich nicht als so grosses Problem an, zumindest nicht bei den meisten CMS. Die mitgelieferten WYSIWYG-Editoren lassen sich meist anpassen, und dann darf der Redakteur eben nur Text dick/kursiv machen und zwischen Blocksatz und linksbuendig waehlen. Weniger ist hierbei definitv mehr.
    Und bei dem von mir am haeufigsten eingesetzten CMS Typo3 habe ich mit der Extension TemplaVoila eine wunderbare Moeglichkeit, dem Benutzer Inhaltselemente vorzugeben, und zwar so wie ich das haben will. Da freut sich auch die Semantik.

  10. Gregor Nathanael Meyer am 1. Oktober 2008 #

    Abspecken des benutzten Editors ist sowieso Pflicht, das ist klar. Oder handhabt das hier jemand anders? Abgespeckt auf strong, em und die Absatztypen plus ggf. Snippets für Bilder mit Bildunterschriften und so kann man schon arbeiten. Trotzdem schaffen es Kunden nach meiner Erfahrung immer wieder, fragwürdigen Code zu produzieren. Angefangen bei gnadenlosem Strg-V aus Word über Bugs/Unfälle des Editors bis hin zu mutwilligen Änderungen direkt in der Codeeingabe (die IMHO nicht abgeschaltet werden kann/darf/sollte) habe ich alles regelmäßig am Bein.

    TYPO3 hat da einen recht spannenden Ansatz: Man definiert nicht nur die sichtbaren Buttons im RTE, sondern auch die vom Backend erlaubten Tags. Alle anderen Tags werden schlicht escaped. Lästige Fehlerquelle, wenn man nicht damit rechnet, aber eigentlich eine interessante Idee. Auch TemplaVoilà bietet richtungsweisenden Umgang mit Templating.

  11. Harald am 1. Oktober 2008 #

    Ich bin kein Fan von WYSIWYG-Editoren, aber erst recht kein Fan von alternativen Auszeichnungssynstax wie Textile, BbCode, WikiCode oder wie sie alle heißen.

    In Eingaben, die Formatierungen erlauben, sollte ein Subset von HTML zur Verfügung stehen, das im leider oft unumgänglichen WYSIWYG-Editor clientseitig und sonst serverseitig geprüft wird. Dann kann der User noch so viele Javaapplets, Imagemaps oder Tabellen einbauen – wenn die Tags dafür nicht erlaubt sind, hat er keine Chance. Und damit ist auch das leidige Word-Copy&Paste-Thema weitgehend gegessen.

    Richtexteditoren mag ich nicht, weil sie wichtige Auszeichnungen fast nie unterstützen wie z. B. Sprache oder Abkürzungen. Das gleiche Problem haben die Alternativformate. Es gibt fast keine Richtexteditoren, die das vorgegebene Layout unterstützen. Nach umfangreicher Bearbeitung darf man nicht mehr in den Quelltext gucken. Der ist dann vielleicht nocht valide – soweit aufwändige Parser eingesetzt werden – aber grauenhaft chaotisch. Und bloß um ab und zu mal ein Wort fett zu stellen braucht man sowas nicht.

    Und ganz schlimm finde ich es, wenn kein adäquater Quelltexteditor angeboten wird, der aufbereiteten Code liefert.

  12. Harald am 1. Oktober 2008 #

    Achso, und nicht nur Subsets von HTML-Tags, sondern auch von Attributen, Attributwerten sowie Validierung.

  13. Bernhard Vogler am 1. Oktober 2008 #

    Also was Johann fordert und u.a. Gerrit und Gregor beschreiben, habe ich vor kurzem für mich entdeckt – und zwar in Form des widgEditor
    (Ist natürlich vor allem bei individuellen CMS-Lösungen interessant, aber kann wohl auch relativ leicht in Fertiglösungen „reingehackt“ werden)
    Wenn man dann noch bei Bildern statt URL-Eingabe ein besseres Interfaces schafft, ist es doch ziemlich brauchbar.
    Und wenn man den dazugehörigen Stylesheet dann so ausstattet, dass u.a. Schriftart und Zeilenhöhe wie in der Ausgabe definiert sind, hat man einen Basis-Editor (em, strong, ul, ol, img, a, p, h1-h6), der echtes (wenn auch bewusst eingeschränktes) WYSIWYG bietet und somit auch technikscheue Kunden nicht abschreckt, schlechten eigenmächtigen Formatierungen vorbeugt und zugleich die Semantik wahrt.
    Natürlich wären eventuell noch Erweiterungen für acrynom, abbr wünschenswert, aber wenn wirklich Bedarf herrscht, sollte das auch gut zu schaffen sein.

  14. Tobi am 1. Oktober 2008 #

    Bei mir ist es genau anders rum. Ich verstehe nicht, wieso man heutzutage Markdown oder Textile verwenden muss, wo es doch so schön konfigurierbare Wysiwyg-Editoren gibt.

  15. Gregor Nathanael Meyer am 1. Oktober 2008 #

    An Markdown und Textile und Co. mag ich gar nicht, dass sie nicht explizit arbeiten. Sprich: Bestimmte Bedeutungen ergeben sich aus impliziten Zusammenhängen, die im Zweifel auch etwas anderes bedeuten können und die außerdem noch extra gelernt werden müssen. Mein Lieblingsbeispiel für Textile ist sowas:

    Kaufmann und frau ist was anderes als [beliebig viel Text hier einfügen] Groß und Einzelhandelskauffrau.

    Das kann keine allgemeingültige Lösung sein.

  16. Gero am 1. Oktober 2008 #

    Ich halte es da mit kopozky.net – The Life and Death of Design::

    Week 4: The designer has just finished a new website. Isn’t it neat?

    Week 7: The developer has customised and implemented the CMS. Still looking great … sort of.

    Week 13: The website is online. Editors have been busy adding content. Apparently they loved using the rich text editor.

    Dem ist in der Realität leider wenig bis nichts hinzuzufügen.

  17. Johann Heyne am 1. Oktober 2008 #

    Für einen Redakteur ist es nicht unbedingt einleuchtend, dass der Unterschied zwischen einer Headline1 und Headline2 nicht nur optischer Natur ist. Wenn ihm Headline1 zu groß ist, nimmt er eben Headline2. Sieht doch gleich viel besser aus nicht war? Für den Redakteur sind Headline1 und 2 nur Stile ohne strukturelle Bedeutung.

    WYSIWYG-Editoren sollten daher Semantik erzwingen können. Eine zweite Headline1 sollte Beispielsweise definitiv nicht möglich sein. Probierts mal aus.

    Kann man Semantik aber vollständig erzwingen? Vielleicht in dem man die Inhalte wie in einer Liste mit untergeordneten Punkten in ihrer Abhängigkeit zueinander sortieren/verschachteln lässt. In wieweit daraus schon eine Sematik abgeleitet werden kann und ob Lücken über Regeln bzw. auch manuelle Zuweisungen sicher geschlossen werden können, wäre mal zu erforschen.

    WYSIWYG-Editoren sollten auch für CMS eine Schnittstelle bieten, um die Inhalte strukturiert übergeben zu können (Array->Ajax), damit das CMS diese verwalten und übergreifend einsetzen kann. In den meisten CMS werden leider die eigentlichen Inhalte als reiner HTML-Code, so wie es der Editor ausspuckt, gespeichert. Damit ist der Inhalt unzugänglich für übergreifende Nutzung im CMS was keinen Sinn macht. Das ist der Punkt an dem fast jedes CMS schlapp macht, der eigentliche Sinn aber erst beginnt.

  18. Gregor Nathanael Meyer am 1. Oktober 2008 #

    Ein Bisschen kann man aber auch von den Redakteuren erwarten. Dass die H1 und H2 nur optisch unterscheiden ist eine traurige Denke, der man aber durch entsprechende Arbeitsrichtlinien und eine kurze Schulung durchaus begegnen kann. Viele Redakteure sind meiner Erfahrung nach sogar durchaus dankbar für klare Regeln, die ihnen überflüssige Entscheidungen abnehmen. Und wenn es dann doch an kompliziertere Vorgaben (Tabellen etwa) geht, sind viele auch froh, deren Finish von einem »Layouter« gemacht zu bekommen.

    Wer sich gar nicht an semantische Regeln halten möchte, hat meiner Meinung nach (im professionellen Kontext) in einer Webredaktion nichts zu suchen. Dass die Realität oft anders aussieht ist schlimm, aber irgendwann auch nicht mehr das Problem des Entwicklers/Integrators. Zu einer Übergabe gehört eben auch eine verbindliche Einweisung. Oder anders gesagt: Mitarbeiter ohne Führerschein fahren ja auch nicht die Lieferwagen einer Firma.

  19. Johann Heyne am 1. Oktober 2008 #

    Ein Bisschen kann man aber auch von den Redakteuren erwarten. …. Mitarbeiter ohne Führerschein fahren ja auch nicht die Lieferwagen einer Firma.

    @Gregor: gut, aber ein Automatikgetriebe ist auf jedenfall nicht zu verachten wegen der Usability ;-)

  20. Anne-Kathrin am 2. Oktober 2008 #

    Mein erster, ganz spontaner Eindruck:

    Editor abspecken ja, Fehler vermeiden ja, auch Tabellenvorgaben sind allein des Layouts wegen (auch wenn ihr mich mit diesem Hinweis für einen Banausen haltet) eine Überlegung wert, aber die Geschichte mit der Semantik ist dem ganz normalen (!) Kunden nicht zu verkaufen.
    In Redaktionen (was ist das überhaupt in der Praxis?), außer wir sind bei einer Zeitung, sitzen doch keine Journalisten oder Germanisten.
    Oder reden wir hier – mal ganz provokant gesagt- nur über die Crème de la Crème?

    Mir wird nun auch langsam klar, warum der Kostenaspekt bei der Schulung bei einigen eine so große Rolle spielt.
    Aber ich denke noch…

    Viele Grüße
    Anne

  21. René am 2. Oktober 2008 #

    Die Frage ist für mich nicht, ob ein Wysiwyg Editor verwendet wird oder nicht. Vielmehr ist entscheidend, wie die Inhalte gespeichert werden. Spätestens wenn die Inhalte in alternativen Ausgabeformaten zur Verfügung stehen müssen, wird man sich über eine saubere Trennung freuen.

  22. Dominik am 2. Oktober 2008 #

    Wir haben hier in der Agentur mittlerweile den 4. WYSIWYG-Editor in unser hauseigenes CMS implementiert. Einer ist schlimmer als der andere. Der produzierte Code wird von Bearbeitung zu Bearbeitung schlechter und 90 % der Benutzer haben dadurch mehr Probleme als Nutzen.

    Warum? Weil sie ihre in Word formatierten Texte übernehmen wollen – das ist eine Sache, die IMHO vorne und hinten nicht funktioniert. Copy & Paste in WYSIWYG-Editoren ist der Anfang vom Ende. Da wird sich dann beispielsweise gewundert, warum der Abstand unter dem zweiten Absatz größer ist als der unter dem ersten: der Editor hat aus unerklärlichen Gründen den einen Absatz in ein p-Element und den anderen in ein div-Element eingeschlossen. In solchen Fällen darf ich mich dann immer an die Datenbank setzen und den von Word produzierten (aber im Editor nicht sichtbaren) HTML-Müll zu entfernen bzw. korrigieren.

    Leute, die einen RTE-Editor fordern, sind meist auch diejenigen, die mit Word nicht umgehen können. Schliesslich kann Word Dokumente auch inhaltlich strukturieren. Sollte man sich automatisch ein Inhaltsverzeichnis generieren lassen wollen, kommt man da auch nicht drumherum (ist ja auch logisch ;-). Wenn den Leuten erstmal diese Möglichkeit (in Word) aufgezeigt wird und sie merken, wieviel effizienter (entspannter) sie durch eine vernünftige Struktur arbeiten könnten, tut der Schritt zu einem WYSIWYM (What-You-See-Is-What-You-Mean) Editor wie markItUp! nicht mehr weh.

  23. Stefan am 2. Oktober 2008 #

    Texte werden doch durch ihre Aussage interessant, und nicht dadurch, wie viel man rot oder grün färbt, rechts oder linksbündig setzt. Stilfragen gehören global geregelt und werden dann im CSS eingestellt.

    Markdown ist dafür die optimale Auszeichnungssprache, gelernt in 5 Minuten, hat nur die Elemente, die man zur semantischen Auszeichnung braucht und rendert schnell. Textile ersetzt doch nur HTML und ist viel zu langsam. ReST ist auch ein interessanter Kandidat.

    Das Problem ist, dass der Durchschnittsbenutzer Mausgesteuert ist, und Knöppe braucht, sonst ist er nicht glücklich. Daher werden solche Editoren wohl nie aussterben. Und er will ja kreativ sein, ich erinnere sich nur an die unglücklichen Augen, als die Texterin bemerkte, dass wir beim Wisiwig-Dings die Farben entfernt hatten.

  24. Thomas Schürmann am 2. Oktober 2008 #

    Ist das nicht eine uralte Dsikussion? Wenn der Kunde in ein WCMS in eine Seite 6 Bilder einbinden möchte, muß ich ihm in sein Template 6 Eingabemöglichkeiten einbauen. Dann kommt schnell die Rückfrage, können sie nicht noch ein Template bauen, in das man nur ein Bild einfügen kann. Meistens brauchen wir das nicht.
    Ich bin froh, dass es TinyMCE und Konsorten gibt.
    Viele verschiedene Templates zu erstellen, die dann doch nur Derivate eines Masters sind erscheint mir nicht sinnvoll. Da überlasse ich, mit gewissen Regeln, gerne die Einstellung von Bildern dem TinyMCE – und sehr eingeschränkt die Formatierung von Text.
    Wobei ich es a) lästig finde, dass der Tiny in der Grundausstattung immer noch mit B und I daherkommt – immer wieder aber auch beim Kunden auf staunende Gesichter blicke, wenn ich erläutere, warum es jetzt strong und em sein sollte.
    Im Extremfall sind einzelne Eingabefelder für alles nicht eine sehr sichere Möglichkeit alles genau zu kontrollieren.
    Für den Benutzer des WCMS ergibt sich aber ein sehr sehr schlechtes Mapping zwischem dem, was er tut und dem was er nachher sieht. Bei manchen Projekten mag das egal sein – bei anderen nicht.

  25. Sebastian am 2. Oktober 2008 #

    Sehr interessanter Thread!
    Der widgEditor sieht aus meiner Sicht der Dinge sehr spannend aus! Werd ich im Auge behalten.

    Ich setze in meinem eigenen kleinen CMS auch Markdown ein. Mir persönlich gefällt es sehr gut. Aber ich muss feststellen dass der Laie an der Basis (und das sind nun mal meine Kunden), damit nicht klar kommt. Trotz Assistent für Links/Bilder/Galierien. Anders sieht es vielleicht bei jemand aus, der jeden zweiten Tag an seiner Website bastelt. Aber der Kunde, der alle 1-2 Monate aktualisiert, kommt nicht klar. Soweit meine Erfahrung.

  26. Johann Heyne am 2. Oktober 2008 #

    Mir kam gerade der Gedanke, warum man RTE im Browser braucht, wenn der Kunde es schon in Word oder anderen Programmen auf sein Manuskript anwendet. Wie die Praxis zeigt, versucht der Anwender intuitiv per Copy und Paste sein Werk zu transportiern. Wenn der Kunde in Word/Pages etc. alles richtig macht und geschult ist, braucht ein CMS doch nur das Dokument laden, rein semantisch analysieren und verarbeiten. Die Stile, welche in Word verwendet wurden, spielen dann keine Rolle mehr. Noch ein paar Textile vereinbart für Bildplatzhalter und schon kann der Kunde sein Word als Editor nutzen. Technisch ist das Analysieren von Worddokumenten sicher nicht trivial. Aber das mit dem Copy und Paste hätte sich erledigt und das Eingeben der Inhalte wäre beschleunigt. Eine Schulung in Word müsste man auch nicht selber durchführen. Das kann der Kunde selber veranlassen.

    So etwas in einem CMS wäre eine feine Sache. Aber wenn nicht einmal RTE im Web korrekt funktioniert, kann man technisch sicher auch diese Idee knicken.

  27. Ingo Schommer am 2. Oktober 2008 #

    Als CMS-Hersteller sollte man WYSIWYG unterstützen, aber nicht als einzige Option. Und vor allem mit sinnvollen Defaults, zu denen keine Farbauszeichnungen gehören. Ich sollte mich als Enwickler z.B. nicht ewig mit Typo3/Typoscript Configs rumschlagen müssen, um einen TinyMCE auf die semantischen Basiselemente zurückzutrimmen.

    WYSIWIG ist ja im Prinzip nur eine Hilfestellung für den Redakteur, um den semantischen Sinn eines Inhaltes zu definieren – und zwar im Kontext der Seite. Das heisst, ein CMS sollte es einfach machen, Überschriften, Listen etc. im gleichen Design zu präsentieren wie im finalen Layout.
    (Vorsicht, Werbung: In SilverStripe ist das einfach über die ».typgraphy« CSS Klasse gelöst)

    Aber natürlich auch, um kompliziertere Elemente wie Youtube-Videos zu platzieren – hier wäre ein Redakteur ohne RTE-UI vermutlich aufgeschmissen.

    Andererseits bevorzugen Redakteure je nach Erfahrungsgrad und Device auch zu Recht Plaintext-Markups wie Textile oder Markdown. Passt z.B. auf einem iPhone viel besser als ein voller RTE bei dem ich umständlich Textfragmente selektieren müsste.

  28. stk am 2. Oktober 2008 #

    Mir wuerde es gefallen, wenn es eine Loesung gaebe, die:

    * annaehernd WYSIWYG aussieht

    * dem Benutzer nur semantisch korrekte Auswahlmoeglichkeiten gibt (strong, em, blockquote, etc)

    * diverse textile-artige Ersetzungen durchfuehrt (aus zwei Divis wird ein Gedankenstrich, drei Punkte eine Ellipse,…)

    * fuer knifflige Aktionen (und nur fuer dann!) auch im Quelltext fischen laesst.

    Bislang habe ich leider nichts vernuenftiges gefunden…

  29. Bastian Fenske am 2. Oktober 2008 #

    Wir haben vor kurzen auch in unserem CMS einen WYSIWYG-Editor eingefügt. Unsere Kunden sind hauptsächlich Institutionen, Verbände und Netzwerke mit vielen oft wechselnden Autoren, die vermutlich selbst ihre Mails in MS Word verfassen und dort dann Überschriften durch eine Änderung der Schriftgröße und Klicken auf „Fettdruck“ erzeugen.

    Ich habe mich für den WYMeditor als Basis entschieden, da er genau den Anspruch hat, die Struktur abzubilden und diese nicht über die Gestaltungsschiene ausschließlich optisch zu erzeugen.

    Mein Ansatz ist, Sektionentypen zu definieren, in denen bestimmte Komponenten (konfigurierte Module wie Text, Bild, Video-Player etc.) erlaubt sind. Das heißt, Bilder werden nicht über den Editor eingepflanzt, sondern sind eigenständige Komponenten. Momentan bin ich noch auf dem Stand, dass diese Komponenten noch fest definiert werden müssen (wurde oben mit den Templates so angesprochen, also 1. Text, 1. Bild, 2. Text., 2. Bild und mehr geht halt nicht), es ist aber bereits so angelegt und in Arbeit, dass der Benutzer frei (bzw. nach den Vorgaben des Seiten- bzw. Sektionentyps) Komponenten hinzufügen, verschieben und entfernen kann.

    Da hakt es im Moment noch an der Umsetzung, denn ein „Hochschieben“ eines Bildes in einen Text müsste den Text vor dem letzten Block-Element aufspalten und aus dieser einen Komponente zwei machen. Schick wäre natürlich auch, das direkt clientseitig umzusetzen. Hier überlege ich, ob es möglich wäre, in den Editor Frames einzusetzen, die die Komponenten enthalten und die dann eben nicht im Design-Mode laufen. Hab ich aber noch nicht getestet, ob es da weiter gehen könnte.

    Meine Erfahrungen bis jetzt mit dem Editor sind einmal dicke Probleme beim Einfügen aus anderen Websites oder MS Word und zum anderen, dass mit der Einführung des Editors die Erwartungen der Benutzer plötzlich genau die sind, dass sie da am liebsten alles beliebig einstellen (bzw. verhunzen) können. Bisher fanden sie es zwar doof, dass das nicht geht, inzwischen aber betrachten sie es nicht mehr als einen anderen Weg, sondern als ganz klaren Mangel, dass dort nicht das volle Programm an „ich gestalte meine Texte selbst“ geht.

    Den Ansatz, die Kunden bzw. Benutzer darin ernst zu nehmen, dass sie nun mal so arbeiten (Copy and Paste aus MS Word) finde ich genau richtig, weiß aber nicht, ob man damit wirklich weit kommt, das technisch umzusetzen.

    Mein Anspruch ist, dass unser CMS ohne Schulungen verständlich ist und das klappt bisher ganz gut.

    Was die Speicherung der Daten angeht, so spricht nichts dagegen, die in einer Untermenge von XHTML abzulegen. Alles andere wäre nur unsinnige Ressourcenverschwendung und ein unnötiger Verzicht auf die Vorteile von XML als Standard sowie die unzähligen Werkzeuge, die es in dem Bereich gibt.

    Ich nehme aus der Diskussion hier die Idee mit, die Überschriften nur in der sinnigen Reihenfolge zu erlauben. Bisher wird das gewünschte Block-Element (Absatz, Überschrift 2-6, etc.) aus einem Drop-Down-Menü ausgewählt. Ich denke, ich werde die paar Optionen als eigenständige Buttons in die Werkzeugliste schreiben und die jeweils nicht möglichen Optionen ausgrauen und dahinter (falls der Benutzer dennoch drauf klickt) einen entsprechenden Hinweis setzen.

    Vielen Dank für die Inspiration.

    Wer Lust hat, mit mir zusammen hier etwas sinnvolles zu entwickeln, ist eingeladen, sich mit mir in Verbindung zu setzen. Das Thema hat für meine Arbeit einen hohen Stellenwert und unser CMS wird (nach bisher über zweijähriger Entwicklungszeit direkt an den Kunden) voraussichtlich in wenigen Monaten unter einer Public License veröffentlicht werden. Aber auch CMS-unabhängig könnte eine Zusammenarbeit fruchtbar sein.

    Bastian Fenske

  30. Flüge am 2. Oktober 2008 #

    Ich finde typo3 auch einfach nur genial, da man im prinzip alles so gestaltet wie man haben will, bzw. wie man es anderen zutraut damit umzugehen. Somit kann man eigentlich jeden Anfänger im Backend rumfummeln lassen ohne großartige Schäden befürchten zu müssen. Das kann eine sehr gute Arbeitsteilung bewirken und somit zu effizienterem Arbeiten führen.

  31. Lukas am 2. Oktober 2008 #

    Nein, ein WYSIWYG-Editoren haben im Web nichts verloren. Auch in CMS nicht.

    Mein Prinzip (und dass vieler anderer Menschen): As simple as possible.

    WYSIWYG: nett, aber nicht notwendig.

  32. Dan Arkway am 2. Oktober 2008 #

    Abspecken so weit es gerade geht oder Wiki-Code. Den Rest macht der Browser und das, sehr langsam aber stetig, immer besser.

    Mein Traum wäre ein überarbeiteter LaTeX-paser der den raw-output von mediawiki versteht. Damit bekäme man aus umfangreichen Artikeln schnell schöne PDFs zum on- und offline lesen. Klingt zwar traurig, aber meist lese ich komplizierte Sachen im Netz in der Druckansicht.

    Wenn das nicht geht, abspecken, Smilies, Fontgrößen und bold einschränken. Wichtig sind nur Aufzählungen und Links. Spaß bei Seite, wenn man wirklich viel Kram braucht, ist ein Wiki oder Typo3 nicht schlecht. Besser als Roxen – duck.

  33. Harald am 2. Oktober 2008 #

    Optimal wäre, wenn der Anwender direkt im Layout arbeiten könnte – in definierten Bereichen, mit definierten Vorgaben.

    Ich denke aber, dass sowas eher was für clientseitige Programme ist, die mit einer Serveranwendung kommunizieren. Eine automatische Spracherkennung und Acronymerkennung und die Sicherung, dass der Code beim einfügen bereits korrekt formatiert ist (z.B. aus Word-Copy&Paste nur die erlaubten Formatierungen und semantisch, die gewünschte CSS-Klasse für umflossene Bilder oder Tabellen …) ist vermutlich mit Richtexteditor vom Browser, AJAX und 3 MB Javascript machbar, aber es macht halt keiner.

    Und ja, der Bedarf für Acronym- und Sprachauszeichnungen ist immer da. Da denkt bloß kaum jemand dran.

  34. Claude am 2. Oktober 2008 #

    Gerade wenn mehrere AutorInnen in einem CMS Inhalte eingeben können, habe ich bisher bessere Erfahrungen ohne Wysiwyg-Formatierungen gemacht, da auch bei gegenteiligem Hinweis immer irgendeiner der Autoren Inhalte aus Word kopiert oder dies als Umweg nutzt um nicht vorgegebene Formatierungen zu verwenden – Menschen sind zum Glück kreativ.

    Zur Zeit verwende ich daher für solche Systeme keinen Wysiwyg-Editor, sondern Text-Eingabe-Felder mit der Möglichkeit, Worte per Javascript-Button z.B. fett oder kursiv zu gestalten. Zusätzlich bekommen bestimmte Admin-Gruppen die Option, Html ohne Wysiwyg einzugeben. So werden Anwender, die wissen was sie tun, nicht eingeschränkt.

  35. Nicolai Schwarz am 3. Oktober 2008 #

    Ich finde Textile auch super, weil es den User zwingt, sich über die Semantik der Elemente klar zu werden.

    Mittlerweile nutze ich in Drupal auch häufig den FCKEditor. Den stelle ich für undarfte User so ein, dass sie nur Absätze, ein, zwei Headlines, Listen, Links und Bilder einsetzen dürfen, neben em und strong. Das reicht und freut die Nutzer, weil sie die Symbole von Word kennen. Und der Editor sorgt im Zusammenspiel mit Drupal dafür, dass valider Code bei rum kommt.

    WYSIWYGs sind ja nicht prinzipiell schlecht. Es muss nur die Möglichkeit geben, sie zu konfigurieren. Und dann muss man sie eben auch richtig einstellen.

    Insofern sehe ich den WYSIWYG-Editor tatsächlich als Semantik-Editor vor.

  36. stk am 3. Oktober 2008 #

    Der WYSIWYM-Ansatz von diesem WYM-Editor gefaellt mir sehr gut…

  37. Thomas Schürmann am 3. Oktober 2008 #

    @stk
    Ja, dieser WYM-Editor sieht wirklich nicht schlecht aus. Wenn die blockartige Darstellung der Blockelemente noch etwas reduzierter ausfallen würde und die Blockelemente über dem Editor platziert würden – sehr sehr schönes Tool. Ich nehme an, dass man im Detail solche Sachen schnell mit dem CSS anpassen könnte. Mit allem, was ein Redakteur zum Arbeiten braucht – meine ich.
    Auch ich nutze Drupal und die Möglichkeiten Editoren exakt auf Benutzer abgestimmt einzuschränken. Das sind dann meist die beim WYM-Editor aufgezeigten Buttons + Absatzformate.

    Was ich in der Tat auch interessant fände, wäre es Text- und Bild / Videobereiche zu mischen. Es wäre sehr schön, wenn eine gewisse Klasse von Redakteuren ein strickbares Template hätten. Es gibt in Drupal ja die Möglichkeit beliebig viele Eingabefelder zu mischen – aber nur von der Adminseite aus – und dann für den Redakteur sehr statisch. Das heißt er wählt für die Erstellung eines Artikels ein voreingestelltes Template aus – das ist es dann.

    Man müßte im Template die Möglichkeit haben neue Elemente einzubinden – bzw. vorhandene Elemente zu sortieren.

    Hört sich interessant an – aber für mich als entwickelnden Designer zu kompliziert. Da muß ein Experte ran.

  38. Thomas Schürmann am 3. Oktober 2008 #

    Ergänzung: Man kann nicht alles wissen – bzw. lesen hilft. Den WYM gibts auch für Drupal. Siehe Liste auf der WYM Seite.

  39. Fotograf am 3. Oktober 2008 #

    Was hat ein wysisyg Editor dort zu suchen hat? Garnix! Nur verkauft sich das ganze so einfach besser. Mehr muss man dazu eigentlich nicht sagen.

  40. Thomas Schürmann am 3. Oktober 2008 #

    Nun. Da sind wohl einige anderer Ansicht. Nicht ganz zu unrecht. Die Frage ist doch nur, wie weit man damit gehen möchte. Insofern gibt es imho sehr wohl eine Existenzberechtigung für wysiwig-Editoren.

    Eine reine XML-basierte Eingabe von Inhalten in ein CMS ist vielen Mitarbeitern von Firmenwebsites einfach zu abstrakt.

  41. Adrian am 4. Oktober 2008 #

    Ich beantworte deine Überschrift mal ganz kurz: Schlecht! Zumindest denke ich das jedes Mal, wenn ich das Standard-Unwerk bei Wordpress sehe…

  42. Sören am 5. Oktober 2008 #

    Zum Einstieg ist es aber sicherlich bequemer.

  43. Frank am 8. Oktober 2008 #

    Finde die Diskussion sehr interessant. Schließe mich den »Textilelern« an.

    @Gerrit: Das ist eine Sache, die ich an Redaxo gut finde. Inhalstblöcke und man kann sich aussuchen, wie und was geht, je nach installierten Plugins. Die Seite und Doku ist aber echt nicht der Hit. Wenn Du noch ein Windows rumfliegen hast ist’s auch schnell ausprobiert. http://redaxowinstaller.de

  44. GE am 9. Oktober 2008 #

    Bei Deinen vielen Kommentaren, wie wäre es denn mal mit einem »nach oben« Link, nach jedem Kommentar oder wenigstens ganz unten ;-) ?

  45. Baum am 10. Oktober 2008 #

    Interessante Diskussion. Ich suche schon seit längerem einen WYSIWYG Editor, mit dem ich XML erzeugen kann, welches per XSL-Transformiert wird. Somit hätte ich mehre Fliegen mit einer Klappe erschlagen: – Ergebnis ist XML – Man hat WYSWIG Funktionalität – Man könnte relativ einfach den Editor konfigurieren (z.B. mit dem Schema)

    Kennt jemand so einen Editor?

  46. felix niessen am 16. Oktober 2008 #

    Wäre interessant hier auch mal die Meinungen von RTE CMS Nutzern zu hören.
    Ich arbeite zur zeit an einem kleinem CMS das soviel wie möglich WYSIWYG haben soll. Indem der Admin bereich wegfällt und durch eine toolbar ersetzt wird.
    Ich kenne mich mit den aneren »großen« CMS nicht gut aus, denke aber das die Word programme einfach einen Textbearbeitungs-Standart gesetzt haben. Und das die leute darauf nur ungern verzichten. Grade wen es immer heist das der RTE das möglich macht.

  47. Herr Voß am 21. Oktober 2008 #

    Ich war auch kein Fan von WYSIWYG-Editoren, mittlerweile haben ich aber weitestgehend meinen Frieden damit geschlossen – richtig konfiguriert, können die echt gut sein.

    Beispiel Xinha, das ich zusammen mit dem CMS Zikula benutze:
    1. Alle Buttons raus, bis auf ul, ol und strong
    2. Im Dropdown fliegen alle stlye raus. Es bleiben nur h3 für Zwischenüberschriften (h1=Site, h2=Artikel), Blockquote und Normal
    3. Die Funktion zum Einfügen eines Bildes habe ich so umgebaut, dass nicht ein loses img eingefügt wird, sondern eine dl mit Bild und Bildunterschrift.
    4. Mit dem Stylist-Plugin kann man dieser dl jetzt Klassen zuweisen: rechts, links, s, m, l, xl – so kann man die Größe und die Anordnung des Bildes einstellen. Beispiel: http://foerdefluesterer.de/Artikel/News/Konzerthighlights-im-September.408.html

    Den so erzeugten HTML-Code lass ich dann noch einmal durch ein Plugin laufen, dass dafür sorgt, dass alle Absätze in korrekten p-tags usw. sind.

    In 90% der Fälle kommt dabei valider, teilweise sogar semantischer Code raus. Die letzten 10% hängen an den Macken der Browser-API. Die Editoren können leider nicht besser sein, als es der Browser erlaubt.

    Die Leute, die mit diesem System arbeiten können ihre Artikel optisch gliedern und Bilder einfügen. Mehr brauche sollten sie nicht dürfen. Das Problem bei den meisten Editoren ist, dass sie von Haus aus die gesamte Bandbreite von HTML und CSS unterstützen und so selbst schon teilweise ein Content Management System sind. Wenn man das in ein CMS einbaut, hat man vieles doppelt.

Kommentar schreiben

Nutzt Textile zum Strukturieren eures Textes.
SEO-Beiträge werden gelöscht, auch bei thematisch passendem Spam.