[OSM-dev] Feedback for Vespucci-dev

[Jan Schejbal]

Am 2012-09-24 14:34, schrieb andrewg_oz:
> It's interesting. The one thing I couldn't stand about the original 
> EasyEdit was that it didn't have a context menu. I found EasyEdit unusable 
> and didn't use it until I enabled support.

For me, it is exactly the other way around... not getting the context
menu was a major plus of the EasyEdit mode. Is it possible that this
strongly depends not only on personal preference (e.g. the zoom level at
which one usually works), but maybe also on the device that is being
used? I have never had a problem to select exactly the object I wanted.
Sometimes, the context menu makes matters significantly worse - for
example, I have a "Seckbacher Landstraße" subway station (node) below a
road called "Seckbacher Landstraße". Almost as unhelpful is offering me
a choice between Node #4316872632 and Node #5691872334 (random numbers
here). I'd rather have to tap a second time to hit the correct node than
having this "choice".

I would at least like to have a regular preference in the preference
menu, if you think fast toggling of it is unnecessary. Please also
consider devices like the Galaxy Note, where a stylus can optionally be
used for input. That is pretty precise, I think. There are also
Android-based tablet/netbook combos that use trackpads in addition to a
touch interface.

We could also add an "Advanced options" button to the main pref editor
and hide everything behind that. Of course, I am willing to do the work
required for this, this is not a "I have an idea but you do the work"
kind of thing.

What about these options:
 - Always (default) - current behavior
 - Never - what was implemented before
 - Intelligent - only if nodes are extremely close (e.g. two nodes in
the exact same place) OR if no node is touched, but more than one way is.


> Regarding the undo colouring, the problem is that on some devices (eg my 
> Desire Z), the undo/redo list wasn't showing up different colours, but more 
> importantly, was showing up light grey text on a white background - almost 
> unreadable!

That could possibly be fixed by hardcoding both background and
foreground colors for both undo and redo items. However, this:


> is to use undo/redo icons next to each item. I thought about doing that, but haven't 
> quite gotten around to it just yet.

sounds like a good idea too. I would suggest a forward and backward
arrow with different colors to make it easy to see the difference at the
first glance.

You choose, I implement?


> Regarding autocomplete heights, yes that was me! :-) I guess I tend to 
> prefer default UI wherever possible, based on the assumption it was 
> designed that way for a reason. Consistency (with the OS, other apps) is 
> also good. Android probably defaults to relatively high lines to make 
> fingertip control easier.

I understand both things, however, seeing only four autosuggest entries
on my Galaxy Nexus with a pretty large 720p/XHDPI screen convinced me to
slightly reduce the height. The decision is yours, if you want I could
also make it configurable.


> Regarding tag ordering, I can see the value of "most important" tags first. 
> The question is how to define "most important". It sounds like it could be 
> a constant maintenance effort! 

The "most important" tag selection is based on the preset, i.e. does not
require any separate maintenance. If a preset has been selected in the
current tageditor instance, that one is used, otherwise the one that
best matches existing tags is used. Preset items can have "mandatory"
and "optional" tags. All mandatory tags are added to the tag editor, the
optional ones are not. Then, all tags (fixed, mandatory and optional)
are shown on top of the autosuggest list unless they are already used.
In practice, this means that (only) the optional tags show up at the top
of autosuggest after applying preset. Without this, the optional tags
are never shown/offered.

> In a way I prefer the certainty of a sorted list. That way I always
> know where to find a tag.

That is why I intentionally put the duplicates in - you can find the
tags from the preset on the top, or you may use the alphabetical list
below. This is great when you use the suggest menu while the tag field
is empty, but I understand it doesn't look well once a part of the tag
name is entered.

Again, we have three options:
 a) Original behavior (tags from preset on top, full alphabetical list
below)
 b) current behavior (only alphabetical list)
 c) Tags from Preset on top, duplicate-free alphabetical list below

If we keep the current behavior, the "autocompletePresetItem" member and
all related code should be removed, as the preset item doesn't have any
influence on anything.

Kind regards,
Jan