Quick way to reach the edit form in a wiki: alternative to double-click?

Question

Many wikis offer a quick way to reach the edit form (either inline for a specific section, or on a separate page for the whole article): double-click on the page.

For me, this works really well.
When I read a wiki article and see something I like to fix, I just have to double-click at this very place to be able to edit it. If I would have to click at an Edit link, which might require scrolling first, I would skip many small edits I would have done otherwise. → Editing should be encouraged, so it should be as hassle-free as possible.

However, when I introduce other people to the wiki, I often observe that they have a problem: When they want to select some text on the page (e.g., for copy and paste), they accidentally reach the edit form because:

• they wanted to select a word by double-clicking.
• they wanted to select some text by single-clicking and dragging, but they were correcting the cursor position so fast that the wiki recognized it as double-click.

Apart from this, they all liked (and understood) the possibilty to double-click for editing, but it frustrates them when it happens accidentally. I’m sure regulars would get used to it (by changing their text selection habits for this wiki), but this is not ideal, of course.

What is a good way to quickly reach the edit form?

(The usual Edit link would stay, of course.)

(Note that this is intended for users with keyboard + mouse; solutions that also work for other users are very welcome, but not required.)

Answer 1

One of the problems with using a double click or triple click is that they already have functions tied to them. A double click for example on text will select the full word, whereas a triple click will usually select all text in a paragraph or the identifying block (< li> etc..).

The created dual interaction with the same input I think is very problematic, as you cannot effectively guess how the user is likely to interact with your page. And as you have experienced, users get frustrated as the system isn't functioning how they expect it to.

We haven't seen this as often in web UI's, but maps.google has implemented a custom right click menu with their recent UI update, so perhaps a model where a user performs a drag select on text, then right clicks to edit the 'selected text' is worth exploring.

Answer 2

A tripple click? It gets used somewhere (e.g. for selecting a whole line in Emacs), but the majority of users never heard of it. So it's free to use.

Or maybe Alt+click, I guess it's free, too.

they wanted to select some text by single-clicking and dragging, but they were correcting the cursor position so fast that the wiki recognized it as double-click.

IMHO this is a bug to be fixed. The speed mustn't matter if the cursor (really) moves.

Answer 3

From your description, it sounds like the double-click-to-edit functionality is geared towards the power user. You mention keyboard and mouse interaction, so perhaps you can consider implementing it in one or more of the following ways:

• A preference panel: Allow the user to customize their default double-click behavior in a preference panel. By default, double-clicking on a piece of text could simply select it.

• A short-cut key: Pressing a short-cut key can change the editor into "edit mode". The exact key-pair could also be customizable in a preference panel.

• A "hot margin": I'm not sure what to call this, but effectively double-clicking in the margin could enable edit mode. People are more likely to double click in a paragraph (on top of text), so would be less likely to accidentally double-click in the margin. The current browser behavior seem to "select all" when double-clicking in the margin, so you might want to test how many people actually performs "select all" this way. Again, this could be something that is enabled/disabled in a preference panel.

• A hovering edit icon: You could have an edit link/icon attach to (or hover near) the paragraph currently positioned under the mouse cursor (near a corner of the paragraph perhaps). This way, the user won't have to scroll to find the edit link (assuming the default edit link is positioned in a toolbar near the top/bottom of the page). This may not be the most unobtrusive solution.