Re: [OSM-dev] Feedback for Vespucci-dev
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. Since then I've used nothing but EasyEdit! :-) Then there is Issue 113 which was filed just a few days after I merged the GSoC branch... The context menu adds at most only one click: 1=general object area, 2=context menu selection, 3=tag edit context menu button. Without the context menu I found myself tapping half a dozen times attempting to get the correct object selected. It's frequently possible to aim your tap so you don't need the context menu (avoiding tap #2). IMHO, the context menu shouldn't be a preference. The process is basically accepting that fingertips aren't a precision pointing instrument. The context menu helps to ensure the correct object is selected. I've often pondered reworking the map drawing code so that tiny drawings of the map highlighting the map object would show in the context menu against each item. I think they would be too small to be useful, though. 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! I spent a lot of time trying to improve the situation and couldn't quickly come up with a better solution than what I've done. What I think is needed is rather than a colour differentiation, 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. 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. 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! In a way I prefer the certainty of a sorted list. That way I always know where to find a tag. Regards, Andrew ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Feedback for Vespucci-dev
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 ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Feedback for Vespucci-dev
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
[josm-dev] JOSM webpage and SPAM
Hello, I finished the SPAM filter interface to the account manager of trac and now even user registrations are filtered for spam. It seems to work pretty good. To get a clean start, I removed all accounts which have never been used to modify at least one wiki or ticket. So if your account vanished, recreate it. Ciao -- http://www.dstoecker.eu/ (PGP key available) ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
