User:Gżdacz/Essay on wikitext
 | This is an essay. It contains the advice or opinions of one or more Wikipedia contributors. This page is not an encyclopedia article, nor is it one of Wikipedia's policies or guidelines, as it has not been thoroughly vetted by the community. Some essays represent widespread norms; others only represent minority viewpoints. |
To avoid ambiguity, editor below means a program to compose texts, while a Wikipedian will be called author.
On the relationships between articles, authors, readers and WMF
The content of articles (and many other texts) in Wikipedia is stored as wikitext.
Wikitext presentation
On the one hand, wikitext should be presented to the audience in the following ways:
- On a full-featured PCs with large screens, keyboards and pointing devices
- On mobile devices with small screens, no keyboard and with multi-touch in place of a pointing device
- Printed on paper
- Read by screen readers for sight-impaired users
- As a ready-to-edit wikitext
- … (all other present and future options I don't know about)
Presentation is important for readers who make up a significant majority of the audience. They are very different, but without them Wikipedia makes no sense. In this case, the presentation should be universally good, i.e. the same wikitext should be displayed to convey the full range of knowledge available in the article by all these methods. Note that the above distinctions can be continued: users of computers and mobiles might use strong contrast mode, be colorblind; in addition, printing can be done in color or in greyscale.
The penultimate point in the list is very important, too: it is the perspective of someone who is author himself/herself and wants edit the article manually or automatically. We are not a wiki-immortal and will leave someday. Caring for our articles will be taken over by the next generations (I hope!), so we should think about them too.
Creating wikitext
Wikitext is written by authors who may use several different methods for this purpose:
- In the wikitext editor, where everything is allowed, but may produce miserable results in some presentation formats
- In the visual editor, which makes editing more difficult, but gives a reasonably good chance that what it allows will display reasonably well
- In a syntax-checking editor (not yet in existence), in which at first glance everything is allowed, but when you try to save you might get a message I will not accept this because (and here some automatically generated explanation)
- … (all other present and future options I don't know about)
The way of writing is important for the authors, without whom Wikipedia will be unable to fulfill its mission.
Conflict and WMF
There is a fundamental conflict of interests between authors and readers: ensuring universal good presentation quality requires more work from authors and imposes restrictions on wikitext, which is inconvenient.
One can sometimes note another conflict, when the recipient is himself/herself an author. Frictions typically emerge when an article is edited by two authors of strongly opposing preferences.
WMF in this picture is an intermediary between authors and the readers: authors write articles using infrastructure and software provided by WMF; readers read articles also using infrastructure and software provided by WMF.
This role is extremely difficult because WMF gets blamed by the readers when the display quality of articles is insufficient, and by the authors when creating articles is too time-consuming and / or inconvenient. Any concession to one party causes potentially increased dissatisfaction with the other.
How did others overcome it?
Similar situations have occurred in other areas.
- In the early days of computers, programmers had had the ability to produce an arbitrary machine code and run it, getting a program that worked well, worked poorly or hung the machine. Years later, when programs were expected to run on many different machines and be created by teams of programmers, that freedom got very limited. Today programming is done predominantly in high-level languages, which very much limit the possible machine instruction sequences. However they guarantee faster, more modular programming and very much increased error control. The price is that after writing the program the compiler can say I will not accept this because (and here some automatically generated explanation). Visual programming goes beyond that and offers the possibility to develop a program by composing it from predefined modules, without ever seeing its code. Such programming style is yet more restrictive, but produces programs which are executable on almost any equipment (spreadsheets being an example). On top of that, there are standards regarding the form of programs imposed by custom, social pressure, codes of good practice, design patterns, etc.
- One of the first programs for composing scientific texts was TeX, created by Donald Knuth. It could do almost anything, including writing a Basic interpreter in it and creating custom fonts with Metafont. Today, perhaps, no scientific journal in the world would accept an article submitted in plain TeX. Most of them require the use of LaTeX, which sits on top of TeX and greatly limits the freedom of the author, but on the other hand offers standard, ready-to-use elements: section headings, font manipulation, various types of mathematical formulas, bibliography, cover sheet, etc. All of that can be brought to conformance with the typographic style of the journal by a single style declaration. Visual editors allow one to edit LaTeX code in WYSIWYG mode; there are tools to create it semi-automatically from Word documents.
Where is Wikipedia?
If we compare Wikipedia with the examples from the previous section, we're still in the assembler or plain TeX stage. We mostly write wikitext, using a certain number of templates, which, however, are not mandatory and, in principle, everyone can ignore them. Typically only the visual effect on a PC is ever verified, if at all.
Meanwhile, readers' problems call for methods to present articles correctly in a variety of forms in a fully automatic way. At the same time, we are increasingly feeling the burden of caring for articles by authors who have already left, and we are beginning to understand how good it is to standardize the form of the wikitext.
I think that these needs will eventually cause us to follow the pattern seen in the history of programming and of TeX/LaTeX text composition systems. As a result, we will have to limit the freedom of authors, which is usually achieved either through a visual editor, or a syntax-checking editor.
Because of this, I support reasonable standardization, automated code improvements, templates, etc., and last but not least, work on new tools for editing and discussing.
What does not follow from the above
While I think we will need to limit the existing freedom of editing (on the wikitext level) and accept some form of visual editor or syntax-checking editor, I do not mean that the current forms of VE and Flow are exactly what we need. I my opinion they both fall short of the requirements in terms of convenience of use, reliability, and intuitiveness.