Wikitex usability review

From Wikisophia
Jump to: navigation, search

This review was written by a design university student wanting to support wikitex.


Main Issues

If there should ever be a Wikipedia: Usability guide for future developements the first rule should be:

Never mixup what's designed to be read by humans and what's designed to be read by computers

and the someone should add: No matter how easy to read your code is, it's still a code.

The importance in this rule is to always welcome new users, no matter who they are. Imagine an old but open-minded musician who spent twenty years studying Prussian baroque music, so today he feels uneasy with his computer and has to constantly call his grandson to ask, again, how we attach a file on an email. Now suppose this grandson decides to show him what is this Wikipedia thing. If when he first clicks 'edit this page' he see something as:

	\relative c' { 
		e16-.->a(b gis)a-.->c(d b)c-.->e(f dis)e-.->a(b a)
		gis(b e)e,(gis b)b,(e gis)gis,(b e)e,(gis? b e)

Even if this is the award-winner simpler code the programmer could get, He'll probably feel he's too old to learn this complicated thing and never come back.

So it would be smart to separate the wikitex source from the article's source. This way our old fellow there would be comfortable to contribute to the article, and would only stumble upon the music plugin after he had learned the basics of wiki.

Wikitex new toolbar.jpg

First of all a small change would be needed on Wikipedia's toolbar. The toolbar should be kept always the simpler possible and every addition to it should be thought carefully.

In this review only three wikitex are suggested for implementation: baktik, music and chemistry. Baktik, the SVG reader does not need an icon as it is suggested that he be called by the image tag. Then only two new buttons are needed.

But the button horizontal rule could be cleaned out. The button itself suggest it should be used sparingly and its tag ---- is easy enough to remember as to make the icon unnecessary.

If other wikitex diagrams shall be approved for implementation maybe it would be best to leave only one button, the most commonly used for the user. The other buttons would be accessed by either clicking on the lower right corner of the icon or by holding down the mouse button. Adobe has used this succesfully on its products for a long time.

Clicking on the button would put a tag like [[Music:Asa branca]], or [[Chemistry:Water]] . If there was no music with that name, an imaqe would indicate this and invite the user to edit that link. If the music existed, it would be shown.

Blank music sheet.jpg

Clicking on an existing music link takes you to a page identical to the existing image page, and clicking on edit takes you to the lilypond source code. This code should also accept other wiki tags, like redirect (so China's anthem redirects to People's Republic of china national anthem) or other templates like copyrights tag, votes for deletion, featured music etc...


The wikitex tag could also have some information on how the thing will be displayed. For example, an article on Beethoven might want to add just the overture of his songs, and maybe an article on musical ending might want to display only the end of the song. Something like

[[Music:Asa branca | 2 ]] would display only the second (verse? Compass?) of the music and [[Music:Asa branca | 9 to end ]] would display from the ninth till the end.

Music: Lilypond

Music sheet wikitex.jpg

One of Lilypond's most important features is the midi output. But Wikipedia is way more than a website. Although in a multimedia environment the possibility of hearing the music is always desirable, this makes no sense in a printed media and certainly should work differently when accessed in voice mediums, like some special softwares for the seeing impaired accessing wikipedia.

So musical output should be a flexible feature, changing according to the environment, cannot be a manual link saying click here to listen.

On a typical wikipedia paqe, Lilypond would show the song image in the bottom there shall be the song's title and to its right an icon like 'play'

A non-crucial improvement would be adding written lyrics. That's very important to anthems and some operatic pieces. Of course, this takes us to further complications with non-Latin alphabets, so this feature could be implemented later.


The SVG implementation should be completely invisible, along with the image tag, indistinguishable from uploading a GIF, PNG or JPG. The only difference would be a link on the image page for downloading the source code. (Because as in a bitmap what you see is already what you get, you do not need a link to download it)

Simply like: [[Image: Butterfly.svg]]


The chemistry engine is a tour-de-force in that it provides flexibility to generate organic chemistry structures that render nicely. However, the vast majority of chemists do not use TeX to generate structures. For better, or worse, a front-end is needed to allow chemists to "draw" structures as they would with any number of programs out there. Preserving a mark-up languange for the chemical structures seems reasonable since, then, the structure could be easily changed or used in other contexts (presumably still through the GUI interface).


Gnuplot itself does not include very good support for inline data. That is; any data that is not contained in an external file. Gnuplot does support interactive data entry using the special filename: '-', but when this command is used in WikiTex <plot />, the cryptic directive non gratum. is the only response. I imagine that becuase WikiText's gnuplot command is spawned in a shell that is not a tty, it is not supported without some special effort.

Gnuplot supports inline data. Please read the manual.


Adding special plugins for games have some political implications. Games are from local cultures, and wikipedia’s policy on internationality would mean that adding a chess or go engine should be along with another for xiang-qi (chinese chess) and etc. The danger is that there will be created many closed gardens inside wikipedia.

Wikipedia encourages everyone to set up your personal wiki for any game, like for example Sensei's Library, but should not be one itself.

A note: Go did not originate in the west.
I know. Chess neither.Internationality does not means anti-western. It means gmes from argentina, congo, korea, lichenstein. Not only big blockbusters from US, chinaa nd Japan.
The point of this feature is to document famous games. At the moment there is no way other than to construct the games in some external application and screendump. --Phil 09:07, 7 Jun 2005 (CDT)

Another Note:

The point of TeX is to provide a description of the printed (rastered?) page, not to provide a generic engine for playing board games. The board games so-far implemented in WikiTeX apear to be such to allow scholarly discussion or historical archiving of positions. I imagine that the card game Bridge would be of some interest to a large community if a nice <bridge> </bridge> notation could be developed. I don't play bridge so I can't suggest how one might go about it. Another game people might find interesting to document in TeX is Poker.

For info on existing non-TeX work in this area for bridge, see Thomas Andrews work on XML and bridge publishing. --Mabraham 06:54, 28 May 2007 (CDT)


A good rule of thumb for addinq a special enqine would be: how many articles need this? It is a universal subject or a too narrow one? Won't this feature be better implemented with svg images? [custom essay]