TheWysiwygContractProblem

Context

new: 2021-01-29 07:30 UTCLionKimbro:

There has historically been an argument that works like so:

  • “We should keep WikiSyntax. It’s faster for people who know what they’re doing, and it’s the tradition.”
  • “No, we should use WysiWyg. It’s much more user-friendly for new people, and we want to drive use of wiki by the public.”

This page makes a specific argument against WYSIWYG.

the Argument

The argument is essentially that WhatYouSeeIsWhatYouGet (WYSIWYG) implies a contract with the user: What You See, is What You Will Get.

  • “What I see in the editor, I see in the web page.”
  • “What I see in the web page, I see in the editor.”

This produces burdens on the WikiEngineDeveloper?.

Originally, the burden was:

  • Come up with WikiSyntax implications for the feature.
  • Manipulate code so that the WikiSyntax change creates a new kind of HTML output.

But now, the burden is:

  • Come up with how the user’s UserInterface will work.
  • Program the buttons, hot keys, menus, of the UI, to support the interactions required to implement the feature.
  • Program the data structure model and visualization within the UI.
  • Program the HTML rendering of the page.
  • Program access to the server’s database’s contents into the client, so that it has the intelligence it needs to output the same things that the server would output.

This is typically a much greater burden than the original non-WYSIWYG-based system.

The humble TEXTAREA + rendering pipeline is simplified by the following:

  • The text area is already written. The programmer does not need to write anything, other than a specification that readers can follow, on how to arrange characters within a window to write notes in the required format.
  • The transfer of the contents of the text area to the server was already solved in 1995. (TheEvolutionOfForms?.) The programmer does not need to write anything.
  • The WikiEngine has immediate access to everything that it knows, so it doesn’t need to pipe information about the ecology to the client.
  • Then the WikiEngineDeveloper? writes the code that presents a different output.

This means it’s harder to implement new ideas in the wiki.

We are far off the track of SimpleSystems and CommunityOwnedTechnology?, which are key attractions to WikiTechnology in the first place.

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.

Work-Arounds

We talked about this and found some compromise points, to deal with the problem.

Assisted Generators

TimurIsmagilov noted, and demonstrated, during WikiMeet 2021-01-06:

You create a JavaScript button, or a JavaScript interface of some type, that creates a simple problem-specific menu, or some problem-specific UserInterface, which itself generates the WikiSyntax and sends it to the engine.

๐Ÿฆ Timur, could you paste a screen shot of your slideshow generator here? ๐Ÿ„ I don’t know what are you talking about. HalfVisualEditor?

Partial WYSIWYG

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:

  • Headings
  • Bullet Lists
  • Tables
  • Basic Text Formatting (bold, italic, strikethrough, underline)

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.)

Advanced UserInterface Programming Concepts

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.

History of This Page

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.

See Also

CategoryWikiTechnology

Discussion

new: 2021-01-29 07:30 UTCLionKimbro:

That’s odd – WikiMeet 2021-01-06 links, but [[WikiMeet 2021-01-06]] does not.

new: 2021-01-29 11:06 UTCAlex 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. ๐Ÿฅบ

new: 2021-01-29 07:30 UTCLionKimbro: Ha! I was just thinking about, “I don’t really know how to write a good WikiSyntax interpreter,” over on the IdeaReuse page.

new: 2021-01-29 17:07 UTCTimurIsmagilov: Is the text before the Discussion heading ThreadMode or DocumentMode. I assume it’s a document, therefore I embed my thoughts.

new: 2021-01-29 07:30 UTCLionKimbro: ๐Ÿ‘

(CommunityWikiFooter)

Define external redirect: WikiEngineDeveloper CommunityOwnedTechnology TheEvolutionOfForms

EditNearLinks: DocumentMode JavaScript WysiWyg WikiEngine WikiMarkup ProgrammingLanguage WikiTechnology WhatYouSeeIsWhatYouGet UserInterface

Languages: