Long pages and unintentional clicking of "edit(gui)" instead of "info"

Observation

I have run quite some times in this usability problem - however at the moment I cannot reproduce that..

1. Visit a big wiki page, which takes quite some time to load (via DSL), but which is not as big as e.g. MoinMoinScreenShots

2. After the page appears, click on "info" (page is still loading in the background) because you want to see some specific changes.
3. Gui Editor is enabled in wikiconfig.py
4. Shortly before clicking "info" javascript adds the "edit(gui)" link to the editbar
5. You do click (since you have'nt noticed the change). But now you click on "edit(gui)" instead of "info"
6. This is very annoying since loading a bigger page in gui also takes a lot of time. When it is loaded, you have to cancel edit(gui), reload the page a pay attention not to click on "info" in the wrong moment.

Task

Desire to view "info" on a bigger page which takes quite some time to load but not too long

Users

Dumb philosopher

Context

Happend to myself quite some times...

Discussion

I cannot reproduce this behaviour now intentionally, but it happend to me quite some times when not paying attention to it and when trying to work normally with Moin.

Reason for this: Some javascript adds the menu item "edit(gui)" afterwards to the editbar which has already been displayed

How to prevent? Don't change dynamically edit bar, but I don't know if there is another solution for this except using javascript.. Maybe add edit(gui) (according to the wikiconfig.py setting) by default to the editbar but gray the item out or disable it (Like e.g. "Immutable page") instead of adding and removing it... Maybe even better: add edit(gui) by default as disabled an inactivated menu item to the edit bar and activate it (replace it by a clickable link) when gui is available..

The Edit (GUI) is added in JavaScript because this is the only robust way to detect if the browser support it or not. If the browser does not support the GUI editor, the button is not added. The issue here is using separate button for the GUI editor, and providing 2 edit buttons. A sane design will display only one edit button, activating the user preferred editor, or the text editor if the current browser does not support the GUI one. To provide both options, a CSS popup menu can be used - see how its is done in JotSpot (soon Google Wiki).

Menu fields which are created by javascript are said to be a severe accessibility (and thus usability issue): There is no chance for screereader users to notice this pop-up thing let alone find it with their screenreader. MonthCalendar tooltip (which displays the wiki level one headings as some page summary) suffers of the same issue. But this needs some real testing with a screenreader user. -- OliverSiemoneit 2007-09-03 19:33:13

CategoryUsabilityObservation