[josm-dev] JOSM Fail

[Frederik Ramm]

Russ,

Russell Nelson wrote:
> Executive summary: Do people know that JOSM has these newbie usability
> problems, and if I put resources into fixing them (without removing
> functionality or impeding experienced users), would those fixes make
> it back into the source tree?

Sure. We're always happy about improvements. JOSM is not primarily 
geared at newbies or casual users and some things that new users find 
annoying may actually help an advanced user to be productive, so *if* a 
decision has to be made we might be biased towards catering for the 
advanced user. However, the examples you mentioned seem entirely fixable 
without impeding experienced mappers. Most of what you mention has 
probably annoyed a lot of people but rather than fix them, people just 
find their way around it.

> 1) First (and I realize this is probably a Java / Mac thing), we
> couldn't paste a URL into the URL window.  Fortunately, the
> drag-n-drop code worked (massive hoorays to whomever added that).

I think there's a bug/feature that selects the contents of the text box 
when it gets the focus, which is desirable when moving there by keyboard 
but undesirable when focusing it by mouse.

> 2) JOSM has the usual GIS problem that it will happily render
> off-screen with no indication that anything is wrong.

There's a "zoom to data" function that helps. If you have NOT done 
anything else before, it will automatically zoom to your downloaded data.

> Perhaps if JOSM noticed that nothing got drawn within the clipping
> frame, and drew an arrow in the middle saying "Your data is thataway",
> it wouldn't be a "big black box of fail".

What if you're zoomed in rather far and your data is "everywhere but here"?

> 3) She may have used an older version (but definitely has used
> potlatch), but the first thing she did was select a box to try to zoom
> in.

I don't know how we could make it clearer than having the 
well-established magnifying glass symbol in the task bar on the left 
(AND the mousewheel AND ctrl +/-) to zoom but if you have an idea let's 
hear it.

> She successfully zommed in with "Zoom to Select", but then tried
> to zoom in again, and succeeded in grabbing and moving all those
> points.  That *would* have been massive fail if she found the upload
> button, even if she did manage to move them back to very nearly the
> right location.  I helped her find Undo.

The upload button would have told her that she is about to modify a 
gazillion objects (also, the command stack in the right-hand side window 
should have said something like "move 384 objects" or so). I firmly 
believe in users who read what the software tells them and I refuse to 
write software for users who cannot (or refuse to) read; but again, if 
you have a better idea to avoid doom when people use JOSM in this way, 
it can't hurt to be on the safe side.

> 4) She selected a way, and then tried to move the node because the
> road had been extended.  Of course, she moved the entire way.  (This
> mnay not be easy to fix).

Maybe the moving of entire ways should be removed completely or at least 
moved out of the standard editing mode; in my time as a mapper the only 
use I ever had for it was nudging buildings.

> 5) She went into insert node/way mode with the way still selected, in
> order to extend it.  It ignored her clicks.  This is a usability
> fail.  Never ignore a user's input.  If it can't be used in this
> context, then say why.

I think it would be sensible to try and extend the way from the "near 
end" in this scenario. You are right, JOSM currently just ignores clicks 
if it finds it cannot extend the way for some reason.

> 5) It *really* bothered her that in insert node/way mode, she had a
> red line from the tail node.  She is resourceful and figured out that
> ESC would terminate the adding.  But that de-selected the way, so she
> had to go into select mode, go back and select it again in order to
> tag it.

This is a problem for many. The best solution probably is switching off 
the helper line if people press ESC, but not deselecting the object.

> 6) "You geeks must really like tedium, because it's wicked boring to
> have to select/delete, select/delete, select/delete, select/delete all
> these inapplicable tags".  I reassured her that we don't like it
> either, but that didn't serve to explain why she couldn't select a
> range of tags to delete them.

Deleting tags is a relatively uncommon operation for us so maybe we just 
haven't noticed. It should be easy to allow ranges of tags to be 
removed. Is this a special TIGER use case?

> I've been hired this week as a Community Ambassador by Cloudmade.
> It's my job to help people map.  If I have to fix JOSM to get them to
> map, then that's what I have to do.

You're welcome to help with JOSM development. You might want to discuss 
your planned changes on the list before you start working on them, just 
in case some other developer is working on the same issue. But if you're 
not really interested and just view JOSM development as "clearing 
obstacles for your real work", then you could also give Merkaartor a 
try. It doesn't have as many features as JOSM but those who use it say 
the user interface is cleaner.

Bye
Frederik

-- 
Frederik Ramm  ##  eMail frederik at remote.org  ##  N49°00'09" E008°23'33"