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)