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)