Hi Jan,
Apologies if the formatting messes up in this, I'm replying on my phone.
On Monday, September 24, 2012 11:51:21 PM UTC+8, Jan Schejbal wrote:
> 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
>
A preference would be ok by me. Either on or off (a checkbox).
> 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.
>
I have considered devices with precision pointers. Eg the emulator on my pc
with my mouse. In that situation the precision pointing makes unambiguous
object selection easy and the context menu is much less likely to be needed, no
preference required.
>
>
> 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.
That sounds good. I've been thinking the preferences could do with some
simplification. BTW, I really liked the way you combined the OSM username and
password into one dialog. I had been thinking such customization was possible
but hadn't got around to figuring it out. Now I have a nice example to refer
to! :-)
>
>
>
> 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.
I think on or off at this stage. Keep it simple.
>
>
>
>
>
> > 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.
>
>
I would say no to colours. Android UI design guidelines say monochrome images.
I know our main menu / mode selectors are colour, but I don't have the artistic
talent to make nice icons. Thankfully I consider your EasyEdit mode a wonderful
opportunity to get rid of them entirely, which is even better.
>
> 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.
>
Too many preferences! Make it smaller again (four isn't much, even my 480x800
desirez shows more then that.
>
>
>
>
> > 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 this is going to change I'd strongly suggest a duplicate-free list.
>
>
> 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.
>
If the code might be useful, leave it. I'm quite sure the compiler will
optimize it out. We've added so many preset bitmap, what is a little code?
>
>
> Kind regards,
>
> Jan
Regards,
Andrew
_______________________________________________
dev mailing list
dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev
