einen editor zu bauen, der keinen spaghetti-code produziert, sollte doch aber eine herausforderung sein, die jeder programmierer gerne nachvollzieht. oder ist das eine geheime rache der programmierer an den nutzern, die auf wysiwyg stehen? fragt sich poupou
Von: elisabeth bauer eflebeth@googlemail.com An: Mailingliste des Wikimedia Deutschland e. V. / mailing list of Wikimedia Deutschland e. V. vereinde-l@lists.wikimedia.org Gesendet: 15:58 Donnerstag, 31.März 2011 Betreff: Re: [VereinDE-l] Autoren werden weniger
Am 31. März 2011 15:29 schrieb Sebastian Wallroth sebastian.wallroth@wikimedia.de:
Das schöne ist ja, dass jeder Benutzer auswählen kann, welchen Editor er benutzt.
Schön, wenn dem so wäre. Aber die Erfahrung mit WYSIWYG-HTML-Editoren lässt anderes befürchten. Diese Editoren erzeugen üblicherweise einen furchtbaren Spagetti-Code, wo derjenige, der sein HTML im Quelltext schreibt, erstmal ein paar Stunden aufräumen darf, bevor er damit überhaupt sinnvoll weiterarbeiten kann. Komplett neuschreiben ist oft einfacher.
viele Grüße, Elian
_______________________________________________ VereinDE-l mailing list VereinDE-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/vereinde-l
On 31.03.2011 18:14, poupou wrote:
einen editor zu bauen, der keinen spaghetti-code produziert, sollte doch aber eine herausforderung sein, die jeder programmierer gerne nachvollzieht. oder ist das eine geheime rache der programmierer an den nutzern, die auf wysiwyg stehen?
es ist leider schlicht unmöglich, einen wysiwyg-Editor zu bauen, der auch in komplizierten fällen nichts kaputt macht(*). Es ist ebenso unmöglich, automatisch zu erkennen, in welchen Fällen das passieren würde.
Man kann Editoren bauen, die "meistens" das richtige tun. Der von Wikia ist wohl der beste, den es gibt. Aber auch der macht manchmal was kaputt, und kann nicht alles. Es bleibt immer Flickwerk.
Die einzige *wirkliche* Lösung wäre, die Wiki-Syntax so weit zu verbessern, dass man sie ordentlich formal beschreiben und parsen kann. Dann kann man auch einen vernünftigen Editor dazu bauen (und auch vernünftige Exporter für PDF, TeX, etc). Aber es werden einige Seiten und vor allem auch Vorlagen dabei kaputt gehen, die müssen dann von Hand repariert werden.
Letztlich ist das der einzige weg, und ich weiß, dass bei der Foundation mittlerweile zumindest ernsthaft darüber nachgedacht wird. Das ist Teil des "wiki.next" Programms, für das die Foundation gerade Brion Vibber wieder eingestellt hat. Auch Trevor Parscal, einer der Chefentwickler, sagte mir, dass ihm das Thema unter den Nägeln brennt.
Nicht umsonst ist "fix the parser" eines der Hauptthemen beim Hackathon, den wir im Mai in Berlin veranstalten. Ich bin schon sehr gespannt, was dabei heraus kommt.
Kurz: das Problem treibt uns schon seit 2004 um, aber die Aussicht, möglicherweise Millionen von Seiten von Hand reparieren zu müssen, hat immer abgeschreckt. Aber es wird nur schlimmer, je länger wir warten. Und Wikimedia hat mittlerweile genügend Geld, das Problem mit etwas Wums anzugehen. Es scheint mir, als wäre jetzt der richtige Zeitpunkt, das endlich zu erledigen.
-- daniel
(*) Erstens folgt die Syntax keine kontextfreien Grammatik, damit scheiden die meisten formalen Beschreibungsmittel (EBNF, etc) und Parsergeneratoren aus. Es ist soweit ich weiß nicht einmal sicher, ob die Sprache überhaupt entscheidbar ist (D.h. ob der MediaWiki-Parser in allen Fällen terminiert). Zweitens ist es notwenid, *vor* dem Parsen alle Templates, Parser-Functions, etc auszuwerten. Das geht im Browser nicht, das kann nur der Server.
Hi allerseits,
einen editor zu bauen, der keinen spaghetti-code produziert, sollte doch aber eine herausforderung sein, die jeder programmierer gerne nachvollzieht. oder ist das eine geheime rache der programmierer an den nutzern, die auf wysiwyg stehen?
es ist leider schlicht unmöglich, einen wysiwyg-Editor zu bauen, der auch in komplizierten fällen nichts kaputt macht(*). Es ist ebenso unmöglich, automatisch zu erkennen, in welchen Fällen das passieren würde.
imho fällt es den WYSIWIGern aber auch schwer Textlogik zu verstehen. Eine Überschrift ist in deren Wahrnehmung halt auch nur "groß, fett und unterstrichen". Das merkt man viel öfters Worddokumenten als in Wikiquelltext.
Für Wikitextschreiber ist '''fett''' und eine == Überschrift == ein himmelweiter Unterschied, für WYSIWIGer oft nicht. Und der Parser müsste schon erkennen das eine komplett '''fette''' Zeile, nach einer Leerzeile und vor einem Absatz mit mindestens 200 Zeichen eben eine Überschrift sein soll.
Die einzige *wirkliche* Lösung wäre, die Wiki-Syntax so weit zu verbessern, dass man sie ordentlich formal beschreiben und parsen kann.
wenn man schon den Syntax (für den Parser) ändert, gibt es da auch Überlegung logische Teile zu ändern?
Es gibt ja viele vereinfachte Auszeichnungssprachen mit jeweils unterschiedlichen Vor und Nachteile (z.B. Markdown schreibt hyperlinks logischer erst den Linktext dann die Referenz, nicht andersrum wie wikitext )
greetz klml
On Fri, 01 Apr 2011 01:36:35 +0200 Klaus Mueller wrote:
(z.B. Markdown schreibt hyperlinks logischer erst den Linktext dann die Referenz, nicht andersrum wie wikitext )
Als ich die Wikisyntax kennenlernte, war ich positiv überrascht, dass zuerst das Linkziel und dann der Linktext kommt. Denn beim Setzen eines Links denke ich zuerst an das Ziel und erst danach an den Text des Links.
Hi allerseits,
Als ich die Wikisyntax kennenlernte, war ich positiv überrascht, dass zuerst das Linkziel und dann der Linktext kommt. Denn beim Setzen eines Links denke ich zuerst an das Ziel und erst danach an den Text des Links.
ich auch, ich kannte vorher ein wenig html, da erschliesst sich die Logik schnell.
Aber ein normaler User (tm) schreibt eher: "eine andere Auszeichnungssprache (http://de.wikipedia.org/wiki/Markdown) ist ..." Das würde in Markdown nicht viel anders ausschauen: "eine andere [Auszeichnungssprache](http://de.wikipedia.org/wiki/Markdown) ist ..."
Allerdings finde ich auch bei Markdown einigs diskutabel.
greetz klml
On 01.04.2011 01:36, Klaus Mueller wrote:
imho fällt es den WYSIWIGern aber auch schwer Textlogik zu verstehen. Eine Überschrift ist in deren Wahrnehmung halt auch nur "groß, fett und unterstrichen". Das merkt man viel öfters Worddokumenten als in Wikiquelltext.
Für Wikitextschreiber ist '''fett''' und eine == Überschrift == ein himmelweiter Unterschied, für WYSIWIGer oft nicht. Und der Parser müsste schon erkennen das eine komplett '''fette''' Zeile, nach einer Leerzeile und vor einem Absatz mit mindestens 200 Zeichen eben eine Überschrift sein soll.
Wer sagt denn, dass der Editor überhaupt so sachen wie "unterschrichen", "groß" oder "rot" anbieten muss?
Ich finde, ein Wiki-Editor sollte nur "semantische" Optionen anbieten: Überschrift (3 Ebenen), Lemma (wird fett). Kursiv braucht's vermutlich trotzdem. Listen und Tabellen auch. Aber das direkte setzen von Schriftgröße, Schriftart, Farbe, etc sollte schlicht nicht möglich sein. Sowas braucht man nur beim bauen von Vorlagen. Und das macht man von Hand.
Die einzige *wirkliche* Lösung wäre, die Wiki-Syntax so weit zu verbessern, dass man sie ordentlich formal beschreiben und parsen kann.
wenn man schon den Syntax (für den Parser) ändert, gibt es da auch Überlegung logische Teile zu ändern?
Es gibt ja viele vereinfachte Auszeichnungssprachen mit jeweils unterschiedlichen Vor und Nachteile (z.B. Markdown schreibt hyperlinks logischer erst den Linktext dann die Referenz, nicht andersrum wie wikitext )
Ich finde es müßig, sich über die Syntax zu streiten (auf wikitech-l - oder war es wikitext-l? - gab es neulich einen langen thread dazu).
Sinnvoll ist es, zunächst das *Datenmodell* (DOM = Document Object Model) festzuschreiben: welche Elemente gibt es, welche Eigenschaften haben die, wie können sie kombiniert werden. Für die beschreibung so eines Schemas könnte man z.B. den XML-Schema-Standard verwenden. Brion und Trevor sehen das übrigens auch so.
Dass soll aber nicht heißen, dass man dann von Hand XML schreiben muss. Bloß nicht! Wenn es ein DOM-Schema gibt, kann man Grammatiken für unterschiedliche Syntaxen (oder wie ist der Plural von Syntax?) definieren und Parser bauen. Jeder kann dann so schreiben wie er/sie/es will, die interne Repräsentation (eben als DOM) wäre immer gleich. Autoren könnten wahlweise erweitertes Markdown verwenden, oder Wiki Creol, oder etwas, was zu 98% mit der jetzigen Syntax überein stimmt. Und als Austauschformat für Programme, die PDF oder ODT oder so erzeugen, könnte man leicht XML verwenden.
Kurz: mit einem DOM-Schema und formal festgelegten Grammatiken kann man das Dokument beliebig zwischen unterschiedlichen Darstellungen konvertieren. Jeder bekommt die Syntax, die er/sie/es mag. Und wenn sie nicht gestorben sind, dann schreiben sie noch heute...
-- daniel
Der Editor von Twoonix ist so gut wie fertig und er unterstützt vor allem die bescheidene Tabellensyntax (hin-und-her). Sowas hilft wirklich, auch wenn man es gewohnt ist, im Quelltext herumzupinseln. Direkte Textformatierung hat da drin natürlich nichts verloren.
Am 1. April 2011 12:46 schrieb Daniel Kinzler daniel@brightbyte.de:
On 01.04.2011 01:36, Klaus Mueller wrote:
imho fällt es den WYSIWIGern aber auch schwer Textlogik zu verstehen. Eine Überschrift ist in deren Wahrnehmung halt auch nur "groß, fett und unterstrichen". Das merkt man viel öfters Worddokumenten als in Wikiquelltext.
Für Wikitextschreiber ist '''fett''' und eine == Überschrift == ein himmelweiter Unterschied, für WYSIWIGer oft nicht. Und der Parser müsste schon erkennen das eine komplett '''fette''' Zeile, nach einer Leerzeile und vor einem Absatz mit mindestens 200 Zeichen eben eine Überschrift sein soll.
Wer sagt denn, dass der Editor überhaupt so sachen wie "unterschrichen", "groß" oder "rot" anbieten muss?
Ich finde, ein Wiki-Editor sollte nur "semantische" Optionen anbieten: Überschrift (3 Ebenen), Lemma (wird fett). Kursiv braucht's vermutlich trotzdem. Listen und Tabellen auch. Aber das direkte setzen von Schriftgröße, Schriftart, Farbe, etc sollte schlicht nicht möglich sein. Sowas braucht man nur beim bauen von Vorlagen. Und das macht man von Hand.
Die einzige *wirkliche* Lösung wäre, die Wiki-Syntax so weit zu
verbessern, dass
man sie ordentlich formal beschreiben und parsen kann.
wenn man schon den Syntax (für den Parser) ändert, gibt es da auch Überlegung logische Teile zu ändern?
Es gibt ja viele vereinfachte Auszeichnungssprachen mit jeweils unterschiedlichen Vor und Nachteile (z.B. Markdown schreibt hyperlinks logischer erst den Linktext dann die Referenz, nicht andersrum wie wikitext )
Ich finde es müßig, sich über die Syntax zu streiten (auf wikitech-l - oder war es wikitext-l? - gab es neulich einen langen thread dazu).
Sinnvoll ist es, zunächst das *Datenmodell* (DOM = Document Object Model) festzuschreiben: welche Elemente gibt es, welche Eigenschaften haben die, wie können sie kombiniert werden. Für die beschreibung so eines Schemas könnte man z.B. den XML-Schema-Standard verwenden. Brion und Trevor sehen das übrigens auch so.
Dass soll aber nicht heißen, dass man dann von Hand XML schreiben muss. Bloß nicht! Wenn es ein DOM-Schema gibt, kann man Grammatiken für unterschiedliche Syntaxen (oder wie ist der Plural von Syntax?) definieren und Parser bauen. Jeder kann dann so schreiben wie er/sie/es will, die interne Repräsentation (eben als DOM) wäre immer gleich. Autoren könnten wahlweise erweitertes Markdown verwenden, oder Wiki Creol, oder etwas, was zu 98% mit der jetzigen Syntax überein stimmt. Und als Austauschformat für Programme, die PDF oder ODT oder so erzeugen, könnte man leicht XML verwenden.
Kurz: mit einem DOM-Schema und formal festgelegten Grammatiken kann man das Dokument beliebig zwischen unterschiedlichen Darstellungen konvertieren. Jeder bekommt die Syntax, die er/sie/es mag. Und wenn sie nicht gestorben sind, dann schreiben sie noch heute...
-- daniel
VereinDE-l mailing list VereinDE-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/vereinde-l
Am 31.03.11 21:07 schrieb Daniel Kinzler:
es ist leider schlicht unmöglich, einen wysiwyg-Editor zu bauen, der auch in komplizierten fällen nichts kaputt macht(*). Es ist ebenso unmöglich, automatisch zu erkennen, in welchen Fällen das passieren würde.
Das heißt, die Folge wird sein, daß wir praktisch nur noch sinnvoll mit WYSIWYG in Wikipedia arbeiten können, wenn der WYSIWYG-Editor erst einmal eingeführt sein wird.
Jürgen.
2011/4/5 Juergen Fenn juergen.fenn@gmx.de:
Das heißt, die Folge wird sein, daß wir praktisch nur noch sinnvoll mit WYSIWYG in Wikipedia arbeiten können, wenn der WYSIWYG-Editor erst einmal eingeführt sein wird.
Nö.
Der freie WYSIWYG-Editor von Wikia (der eine ganze Reihe der angesprochenen Punkte - mit Ausnahme des "grafischen Zusammenklickens" von Formeln - ziemlich gut kann und den man sich ggf. mal anschauen sollte, wenn man in diese Richtung interessiert ist), respektiert beispielsweise die Anweisung "__NOWYSIWYG__" in einer Seite und lädt in dem Fall dann halt nur den Standard-MediaWiki-Editor. Das könnte man natürlich auch genauso auf einzelne Abschnitte runterbrechen.
Tschüss, Tim.
Am 05.04.11 10:24 schrieb Tim 'avatar' Bartel:
Das heißt, die Folge wird sein, daß wir praktisch nur noch sinnvoll mit WYSIWYG in Wikipedia arbeiten können, wenn der WYSIWYG-Editor erst einmal eingeführt sein wird.
Nö.
Der freie WYSIWYG-Editor von Wikia (der eine ganze Reihe der angesprochenen Punkte - mit Ausnahme des "grafischen Zusammenklickens" von Formeln - ziemlich gut kann und den man sich ggf. mal anschauen sollte, wenn man in diese Richtung interessiert ist), respektiert beispielsweise die Anweisung "__NOWYSIWYG__" in einer Seite und lädt in dem Fall dann halt nur den Standard-MediaWiki-Editor. Das könnte man natürlich auch genauso auf einzelne Abschnitte runterbrechen.
Okay, man kann es im Einzelfall ausschalten. Aber wenn WYSIWYG den Quelltext so verhackstückt, daß ich das in einem reinen Texteditor nur noch mühsam bearbeiten kann, wird es eine faktische Vorentscheidung für WYSIWYG für alle sein. Es empfiehlt sich dann, grundsätzlich die WYSIWYG-Oberfläche zu benutzen.
Man kennt sowas derzeit beispielsweise von Wordpress, wo ich ja auch die Wahl habe zwischen reinem Text (vereinfachtes HTML) und einem grafischen Editor. Bei MediaWiki wäre der Quelltext, der zu erzeugen wäre, wesentlich komplexer als dort.
Jürgen.
2011/4/5 Juergen Fenn juergen.fenn@gmx.de:
Am 05.04.11 10:24 schrieb Tim 'avatar' Bartel:
Das heißt, die Folge wird sein, daß wir praktisch nur noch sinnvoll mit WYSIWYG in Wikipedia arbeiten können, wenn der WYSIWYG-Editor erst einmal eingeführt sein wird.
Nö.
Der freie WYSIWYG-Editor von Wikia (der eine ganze Reihe der angesprochenen Punkte - mit Ausnahme des "grafischen Zusammenklickens" von Formeln - ziemlich gut kann und den man sich ggf. mal anschauen sollte, wenn man in diese Richtung interessiert ist), respektiert beispielsweise die Anweisung "__NOWYSIWYG__" in einer Seite und lädt in dem Fall dann halt nur den Standard-MediaWiki-Editor. Das könnte man natürlich auch genauso auf einzelne Abschnitte runterbrechen.
Okay, man kann es im Einzelfall ausschalten. Aber wenn WYSIWYG den Quelltext so verhackstückt, daß ich das in einem reinen Texteditor nur noch mühsam bearbeiten kann, wird es eine faktische Vorentscheidung für WYSIWYG für alle sein. Es empfiehlt sich dann, grundsätzlich die WYSIWYG-Oberfläche zu benutzen.
Man kennt sowas derzeit beispielsweise von Wordpress, wo ich ja auch die Wahl habe zwischen reinem Text (vereinfachtes HTML) und einem grafischen Editor. Bei MediaWiki wäre der Quelltext, der zu erzeugen wäre, wesentlich komplexer als dort.
Ohne jetzt noch mal Werbung für WYSIFTW machen zu wollen: Die "Abwärtskompatiblität" zum Original-Text kann beim Editor-Design eine zentrale Rolle spielen. Mein Skript lässt alles, was es nicht eindeutig in HTML rendern und wieder genau so in Wiki-Markup zurücktransformieren kann, in Ruhe. Falls sich trotzdem allein durch die Benutzung von WYSIFTW auch nur ein Zeichen (incl. Leerzeichen) im Wikitext ändern sollte, gib't eine Warnmeldung; das kommt aber inzwischen nur sehr selten vor.
Auch kann man bei WYSIFTW einfach Wikitext schreiben (z.B. einen [[Verweis]]); der wird dann genau so übernommen. Oder man kann Links über den entsprechenden Button einfügen, die dann auch direkt wie Links aussehen. Vorlagen (meist automatisch "weggeklappt", ausser bei Infoboxen etc.) können als normaler Wikitext oder als "key-value"-Tabelle dargestellt werden; die Darstellung kann jederzeit umgeschaltet werden.
Einziges "Sorgenkind" sind im Moment die Tabellen, deren Text man zwar bearbeiten kann, die aber für Formatierung und strukturelle Änderungen (neue Tabellenzeile einfügen etc.) nicht zugänglich sind. Das ist in Arbeit...
Ein WYSIWYG-Editor kann also nicht-destruktiv sein, wenn das von Anfang an mit eingeplant wird.
Grüße, Magnus
On 05.04.2011 10:14, Juergen Fenn wrote:
Am 31.03.11 21:07 schrieb Daniel Kinzler:
es ist leider schlicht unmöglich, einen wysiwyg-Editor zu bauen, der auch in komplizierten fällen nichts kaputt macht(*). Es ist ebenso unmöglich, automatisch zu erkennen, in welchen Fällen das passieren würde.
Das heißt, die Folge wird sein, daß wir praktisch nur noch sinnvoll mit WYSIWYG in Wikipedia arbeiten können, wenn der WYSIWYG-Editor erst einmal eingeführt sein wird.
Nein. Das bedeutet, WYSIWYG für bestimmte Fälle einfach nicht eingesetzt werden kann, solange wir die aktuelle Wikisyntax haben.
Letztlich bedeutet es, dass wir eine saubere interne Repräsentation der Inhalte brauchen. Die kann man dann so bearbeiten, wie's einem passt: per WYSIWYG, per Markup, oder was auch immer. Denn über eine solche gemeinsame interne Repräsentation werden verschedeene Darstellungsarten der Inhalte, z.B. unterschiedliche Variante der Wikitext-Syntax, kompatibel und austauschbar.
gruß daniel
vereinde-l@lists.wikimedia.org