It’s much easier to add new features to programming languages and command-line interfaces than it is to add new features to graphical user interfaces.
I think that is profound, but I’ll have to muse it over to be sure.
For example, to add a new editing command (say, superscript) to emacs, just choose a name or keyboard shortcut for the command. But to add it to a graphical text editor, you need a new button or menu item. It has to be worked into the layout of the graphical interface. Other interface components might have to get moved or kicked out. If you’re Microsoft, you just add it onto the end of a quickly growing toolbar or menu or preference window.
Maybe this helps to explain why wikis are still based on wiki-text rather than WYSIWYG editing. If you want to add a new feature to a wiki (say, superscript), just define some new language tag for the wiki-text, e.g.: ““. But if you want to add that to a WYSIWYG wiki (let’s call it a wizziwiki), you have to design. Put the button somewhere. Decide which features are most important. This is hard! And it is especially hard for open source communities where a vocal minority will get upset at the removal of a feature that they particularly like (or programmed). That’s probably part of why brand new open source projects have to continually get started.
Here’s one solution. A wiki which lets you do the most basic editing (bold, italic, lists, links) as WYSIWYG, but has an “advanced editing” mode which is text-based and allows all those other features. The problem with adding this to current wikis lies in getting a “handle” on the text entry point; that is, mapping back from the graphics into the source. Right now it’s a one-way street: wiki-text to html/DOM. It’s hard to go in the other direction. (The same is true for LaTex.) So maybe we need a completely html-based wiki. Is someone working on this?
