Help button looks like a map function

[1ec5]

The help button should be moved to the top or bottom bar, alongside other controls that affect or pertain to the entire interface. It’s currently located on the right side of the map, alongside other controls that affect only the map. A user looking for help about the feature editor may not easily find the help button in its current location. Even if we change it to a question mark (#4650), the user might still mistake it for a query features function (but see openstreetmap/openstreetmap-website#1712).

The button’s current position enables it to open a flyout panel containing the help manual. The idea might’ve been that the user could see an interface element alongside its description in the manual. A modal dialog similar to the keyboard shortcuts dialog (and the help dialog in Potlatch 2) would cover up more of the interface being described, but since the flyout closes as soon as the user clicks outside it, the number of elements that can be viewed this way is limited.

[manfredbrandl]

I suggest that - as a smaller first step - to seperate the "Help" function and use the '?' as a cursor, similar to the current OSM-Website:

On the OSM-Website the '?' should be changed, discussion in the closed issue openstreetmap/openstreetmap-website#1712

[bhousel]

For reference, here's what iD looks like today (RTL looks the same, but on the other side):

The help button should be moved to the top or bottom bar, alongside other controls that affect or pertain to the entire interface. It’s currently located on the right side of the map, alongside other controls that affect only the map.

Hmm, I kind of like these icons where it are - All of those icons open panes from the side. I've never thought of those side icons as "affecting the map".

A user looking for help about the feature editor may not easily find the help button in its current location.

I dunno - The last step of the walkthrough tells users that this is where the help is, and it's not like there are a lot of places to look.

Even if we change it to a question mark (#4650), the user might still mistake it for a query features function

Oh yeah, I agree we should change the icon to make it look more like "help" - I definitely wouldn't change the icon to something that looks like "query features".

The button’s current position enables it to open a flyout panel containing the help manual. The idea might’ve been that the user could see an interface element alongside its description in the manual. A modal dialog similar to the keyboard shortcuts dialog (and the help dialog in Potlatch 2) would cover up more of the interface being described, but since the flyout closes as soon as the user clicks outside it, the number of elements that can be viewed this way is limited.

It doesn't auto-close any more 😄 Try it out on http://preview.ideditor.com/master

I saw a bunch of new users at a recent mapathon get frustrated with this auto-closing behavior. They would open the help, read about a thing, and try to do the thing, and the help would close. So now those panes stay open as long as the user wants them to. This is also nice because (aside from wanting to read the Help) sometimes users might want to pan or do things to the map while adjusting Background, or Map Data filters.

[1ec5]

A user looking for help about the feature editor may not easily find the help button in its current location.

I dunno - The last step of the walkthrough tells users that this is where the help is, and it's not like there are a lot of places to look.

This is just anecdotal, but I’ve spoken with a number of people at mapathons who wanted to run through the walkthrough again but couldn’t find it. That might be due to several factors, such as the help button’s appearance and the walkthrough button’s location within the help flyout, but I suspect information architecture also plays a role.

Desktop applications generally place help entry points near the top-right corner of the window (or at a bottom corner in dialogs). The top bar isn’t the exclusive domain of interface-wide operations, either, but help would be similar in scope to saving and undo/redo.

I saw a bunch of new users at a recent mapathon get frustrated with this auto-closing behavior. They would open the help, read about a thing, and try to do the thing, and the help would close. So now those panes stay open as long as the user wants them to. This is also nice because (aside from wanting to read the Help) sometimes users might want to pan or do things to the map while adjusting Background, or Map Data filters.

Yes, as long as the flyout leaves space for things on the side without dimming those things, the user would expect to be able to interact with them without the flyout closing. A popup window would accomplish that too. 😛

This might be off-topic for this issue, but another downside of the flyout design is that it doesn’t provide a lot of horizontal screen real estate for comfortable reading. The Spanish localization at 1,024×768 is like reading a newspaper column, except without hyphenation and justification:

I don’t know how much of an issue that is in practice, though it’s even felt claustrophobic to me in Vietnamese, which has much shorter words (maximum length of seven characters).

[bhousel]

I don’t know how much of an issue that is in practice, though it’s even felt claustrophobic to me in Vietnamese,

I made the pane a little bit bigger (50% or 600px vs 41% or 500px) in 44234ed

[althio]

this was not the topic of this issue, don't you think?

[bhousel]

this was not the topic of this issue, don't you think?

Yes, you are right ..
I still want to close it though, and leave #4650 open.
I just don't think "People can't find Help" is a real problem - and if it is, we can address that by making the icon better.