[Wikipedia-l] the tool bar : disable it in some browsers (or fix

Wed Jan 21 07:10:50 UTC 2004

Erik wrote:
>That's not possible. Your browser does not support it. It neither 
>supports  changing the selection *nor* retrieving it. So the best 
>we can do in these browsers is give the user a kind of help menu 
>to get sample text for easy copy and pasting (which is particularly 
>useful for stuff like the  signature tildes,

Then put it under a help menu! But the current implementation, even with the 
"Click a button to get an example text" is non-intuitive because it mimics 
the look of an edit tool bar in a word processor. If something looks familiar 
like that, the user is not going to read "Click a button to get an example 
text", they are going to just do what comes naturally to them and expect a 
result similar to what they get in their word processor (or at least it's 
mark-up equivalent). As a matter of fact, I didn't even notice the "Click a 
button to get an example text" wording until you pointed it out. 

Now that means I'm either stupid, blind, lazy, or it means that I quickly 
looked, saw something familiar, and expected it to work in a certain familiar 
way. When that did not happen, I repeated but got the same result. I then 
became frustrated and annoyed.

Better to have a link to a page that has a side-by-side comparison of wiki 
markup and the result. Oh wait! Such a link already exists on every edit 
window behind [Editting help]. Why is it necessary to duplicate that with 
something that confusingly looks like a real edit bar? The result, as has 
been already demonstrated, will be confusion and frustration. 

If it were just a clear edit window the newbie would have just wrote whatever 
text they thought would improve the article. But no. Instead they are 
fighting with a toolbar that does not work the way they expect. 

How is having a counter-intuitive feature helping newbies? How is putting an 
emphasis on markup going to help improve the content of articles? Putting all 
these markup options in front of newbies, especially when a toolbar 
confusinginly does not function as a toolbar, gets in the way of *content* 
creation. Newbies catch on to wiki syntax very fast. So in the absence of a 
functioning toolbar, a clean edit window will work fine. 

Much better, IMO, just to let the newbie enter in the unformatted text and 
*improve* the article quickly without having to worry about formatting. 
Somebody else will come along and add markup if needed and the newbie will 
discover our markup very naturally. It is quick and easy - it's wiki. 

IMO, the 2) toolbar is just a very poor surrogate for finding out how to add 
markup to articles by interacting with formatted wiki text and by watching 
other users who know the ropes. But what is worse is that it masquerades as a 
real toolbar that looks like it should be usable for adding markup to text 
directly - which it does not. If it really is a helpbar and not a toolbar, 
then it should be behind a help link. 

I'm an end-user using your feature for the first time Erik. I've found some 
big usability problems with the 2) toolbar. Yet when I report those problems 
you explain how I should use the feature and what I'm doing wrong! The point 
of usability testing is *not* to teach users how to use your feature, it is 
to get feedback on how to improve your feature so that users can use it 
intuitively and without getting frustrated. 

If that feature can't be improved for certain users, then instead of force 
feeding those users half the feature, it would be, IMO, much better that 
those users don't see the feature at all unless they specifically request to 
see it. So default on for browser/OS configs that are known to be able to 
display the 1) toolbar right, and default off for every other browser/OS 
config. 

If you have to explain how to use the 2) toolbar, then how does it help 
newbies? Wasn't the point to make things easier for them? 

-- Daniel Mayer (aka mav)