Feature Requests /
Direct technical problems:
- Java Applets tend to become large, therefore they need a long time to load
Arguments for WYSIWYG:
Arguments against WYSIWYG:
- the large implementation effort slows other developments
- layout extensions become much 10x more expensive, when they are to be supported by the WYSIWYG interface.
- users that really work with wiki can cope with the markup easily
- WYSIWYG is bug-ridden, slow and clumpsy, usually not worth the effort, power users tend to turn it OFF.
ThomasKalka: Having both would be a interesting solution.
For the me as heavy wiki worker I did not find a way, which works better than to edit plain text.
Mass-editing is like programming, so something which helps, but dont get into my way, would be supportive. The problem with all "hidden information editors" is, that you dont have direct access to every information, which is stored, if the raw code is not accessible to you. Having raw-code of html available in the editor does not help much, since html is not human friendly.
The best solution would be: to have the rich text editor available simultaniously togehter with a raw editor for the wiki text.
I would love to see pointers to such efforts.
But maybee this is not the right place to discuss wiki feature evolution. Should at least be interlinked to an appropriate place in the english speaking wiki-community.
HelmutLeitner: Thomas, by side-by-side you mean that one can switch between classical wiki markup text editing and WYSIWYG-editing? I think that most sites must do it that way, if only to have a fall-back to something that is really working on all browsers (or to not frustrate power-users). -- HelmutLeitner July 11, 2006 10:20 CET