There has historically been an argument that works like so:
This page makes a specific argument against WYSIWYG.
The argument is essentially that WhatYouSeeIsWhatYouGet (WYSIWYG) implies a contract with the user: What You See, is What You Will Get.
This produces burdens on the WikiEngineDeveloper?.
Originally, the burden was:
But now, the burden is:
This is typically a much greater burden than the original non-WYSIWYG-based system.
The humble TEXTAREA + rendering pipeline is simplified by the following:
This means it’s harder to implement new ideas in the wiki.
On the balance, I would rather sacrifice people’s comfort around WikiMarkup, than sacrifice the capacity of the community to process text and adapt it to their various needs. If people don’t want to use markup, just let them not use markup – other people can format their text for them.
We talked about this and found some compromise points, to deal with the problem.
🦁 Timur, could you paste a screen shot of your slideshow generator here? 🍄 I don’t know what are you talking about. HalfVisualEditor?
Perhaps it doesn’t need to be WYSIWYG. Perhaps it would be perfectly fine to use only a limited subset of WYSIWYG capacities, making it a HalfVisualEditor.
A simple partial set might include only:
Linking would still be performed on the server side’s render. There is no implied contract; The user knows that only a core of functionality is implemented in the UserInterface.
(Tables would be particularly interesting, because they might form the basis for a large variety of enhanced wiki syntaxes.)
It is conceivable, with a new InteractivitySystem or UserInterface programming concept, a new ProgrammingLanguage or library or framework, that the burdens may be dramatically reduced – perhaps even making it cheaper to write a client highly interactive WikiEngine, than in any other way.
Perhaps a client-heavy library system, with transparent (“transparent,” spelled: “The developer doesn’t have to think about it,”) access to the server’s resources, and a clever user-interface builder system, and a clever smart-string system and visual editing environment, would work.
This post began as Lion's argument against WysiWyg for Wiki. It was further argued and some creative ideas developed in conversation between Lion and Timur in [[WikiMeet 2021-01-06]], though not everything has been fully captured here yet.
Alex Schroeder: Yeah, it depends on how the other format code is implemented. If care is taken, it works recursively, otherwise it does not. I’ve implemented
// both ways and I guess we’re using the less powerful version, here. 🥺