Re: [OSM-dev] Feedback for Vespucci-dev
On Mon, Oct 1, 2012 at 7:56 AM, Jan Schejbal jan.mailinglis...@googlemail.com wrote: Hi, I have now made and committed the following changes. - Add Advanced Preferences (and move some stuff there) Less clutter. :) - Add pref to disable context menu in unnecessary cases (default: enabled = show always) - Add heuristics for context menu (to always show it when really necessary). If the above-mentioned pref is unset, it basically works like this: Get the list of touched objects. If there are OSMBugs, always show. If there are no nodes but multiple ways, always show. If there is at least one node, then the nearest node is considered to be clicked, UNLESS this node has another node *really* close to it (not to the click area). This ensures that exactly overlapping nodes and ways always bring up the context menu, while other cases can be handled quickly. (Way tolerance is low enough so it doesn't cause false hits.) - Sort context menu entries by distance to click (nodes by distance first, then ways by distance) Great idea! - Undo menu: Add background colors (black/white) and icons properly I now always set background and foreground color. The problem before was that I only set one of them and/or only in one case, I think. I also added custom-made greyscale icons. Feel free to remove the icons if they suck/eat too much space or remove the coloring if it causes problems (I think it shouldn't this time). Color has the big plus over icons that it a) doesn't need space and b) is easier to notice than small icons. - Tag editor: Changed X icon size to match editor rows, force minimum text field size The text fields were REALLY small on my device, and the X was too large. Indeed, the spacing between the fields was the X being larger than the text fields. I gave the text fields a minimum height and a bottom border to fix this, and shrunk the X so it is now aligned. - Tag editor: Set autosuggest dropdown spacing to minimum text field size - I chose to use 36dp as the height of one dropdown item (not counting the spacers). This is already more than the text field size on my device, which is 36dp *including* the spacers (and was even smaller before I introduced the minHeight). If the fields and X are big enough to hit, the autocomplete is too. If the autocomplete is too small, we need to also enlarge the fields (in my tests, I didn't have trouble hitting them correctly, though). Will have to try it out to be sure. Hitting a text field not precisely has less consequences then hitting the wrong autosuggest. ...just a thought. I suspect the field height could be device/style specific. It should be in device indipendent pixels based on the size of a finger. Not device specific. I did NOT make any changes to the content of the autosuggest (i.e. re-add the duplicates or move the corresponding entries to top), so we currently have a plain alphabetic list. I would like to hear some more opinions on this if possible. I guess an LRU schema would be way to complicated to implement and users would be surprised to find their tags at different positions in the list every time. Should we maybe remove the distinction between recommended and mandatory tags and add them all when applying a preset? Currently, recommended tags are more or less invisible to the user, so we should do *something*. The best way would probably to check for mandatory tags every time a tag was added or changed and just add them. I'm not sure how users would react to selecting the wrong tag and getting all these additional ones to delete before they can select the one they actually wanted. Oh, and I just noticed that I forgot to update the appname.xml, but I am not the first one. Should we maybe put a $Rev: $ SVN tag in there for now? The dollar signs look nasty but it makes sure it's always up to date. Good idea. It will always be forgotten once in a while. I returned last night and will sign the release this afternoon after work and after checking that there are no open translation tickets with texts we haven't applied yet. Weekend was too busy with a thousand other projects that can only be done on weekends. Marcus ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Feedback for Vespucci-dev
On Monday, October 1, 2012 2:28:40 PM UTC+8, Marcus Wolschon wrote: I think the icons for source=survey and for presets need to be replaced with something more intuitive at some point. Problem is, I don't know any symbol more intuitive for these myself. Agreed, but I couldn't think of anything better, either. I was thinking an eye icon for surveyed, like: http://www.darshancomputing.com/android/1.5-drawables/ic_menu_view.png i.e. you had seen whatever it is. Still thinking about presets. I chose the heart because the presets remind of favourites, which are often represented with a heart. Andrew ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Feedback for Vespucci-dev
On Mon, Oct 1, 2012 at 9:04 AM, andrewg_oz andrew.greg...@gmail.com wrote: On Monday, October 1, 2012 2:28:40 PM UTC+8, Marcus Wolschon wrote: I think the icons for source=survey and for presets need to be replaced with something more intuitive at some point. Problem is, I don't know any symbol more intuitive for these myself. Agreed, but I couldn't think of anything better, either. I was thinking an eye icon for surveyed, like: http://www.darshancomputing.com/android/1.5-drawables/ic_menu_view.png i.e. you had seen whatever it is. Still thinking about presets. I chose the heart because the presets remind of favourites, which are often represented with a heart. I was thinking favorites too when I first saw it. Then I wondered why you would mark an object as a favorite. ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Feedback for Vespucci-dev
Just as an FYI in relation to Galaxy Ace testing, I've checked Vespucci on a 320x480 emulator, and it looks OK. The real Galaxy Ace runs Froyo. Has anyone been able to run Vespucci on Froyo? When I try a Froyo emulator, Vespucci gets stuck starting up (black screen, ANR). Andrew ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Feedback for Vespucci-dev
On Mon, Oct 1, 2012 at 9:25 AM, andrewg_oz andrew.greg...@gmail.com wrote: Just as an FYI in relation to Galaxy Ace testing, I've checked Vespucci on a 320x480 emulator, and it looks OK. The real Galaxy Ace runs Froyo. Has anyone been able to run Vespucci on Froyo? When I try a Froyo emulator, Vespucci gets stuck starting up (black screen, ANR). Andrew I have a very old china-tablet at home but that't 600Km away at the moment. ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Feedback for Vespucci-dev
Is Froyo Android 2.1? I think I was having the same problem earlier in the year and I started to trace which commit did it Well, I have been through a few different SVN revisions - r215 runs ok for me. There seems to be something odd about checking out r216 and r217 using the eclipse SVN plugin - it shows as r215, but r218 fails. But I am afraid I did not work out what it was that caused the problem because my phone upgraded itself and Vespucci started working again and I forgot about it, sorry! It looks like something introduced between revision 215 and 218. Graham. On 1 October 2012 08:25, andrewg_oz andrew.greg...@gmail.com wrote: Just as an FYI in relation to Galaxy Ace testing, I've checked Vespucci on a 320x480 emulator, and it looks OK. The real Galaxy Ace runs Froyo. Has anyone been able to run Vespucci on Froyo? When I try a Froyo emulator, Vespucci gets stuck starting up (black screen, ANR). Andrew ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev -- Graham Jones Hartlepool, UK. ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Feedback for Vespucci-dev
On Mon, Oct 1, 2012 at 9:28 AM, andrewg_oz andrew.greg...@gmail.com wrote: Does anyone else think the OSM API URL should be moved to the new Advanced preferences? Andrew Indeed. It certainly is an advanced feature. Just like custom presets. Marcus ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Feedback for Vespucci-dev
I've just checked in quite a few changes. Didn't see your comment on presets until afterwards. I have reported the bug in ABS at: https://github.com/JakeWharton/ActionBarSherlock/issues/642 You will need to patch your ABS accordingly in order for the new long-click ActionMode to work correctly. I see Jake has already commited the change to ABS. See his commit for code. Andrew ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Feedback for Vespucci-dev
Am 2012-10-01 09:28, schrieb andrewg_oz: Does anyone else think the OSM API URL should be moved to the new Advanced preferences? In theory, yes. However, I think it is better to keep it easily available to quickly switch between the official OSM API and a custom one, so I intentionally kept it in the main menu. This makes it easier for users who use Vespucci to edit a custom map to quickly return to the OSM server to contribute a change to the official map. Kind regards, Jan ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Feedback for Vespucci-dev
Am 2012-10-01 09:04, schrieb andrewg_oz: Still thinking about presets. I chose the heart because the presets remind of favourites, which are often represented with a heart. The official favourites icon is a star on Android, but I wouldn't suggest that. What about the document icon (though that usually means new) or a stamp icon that would need to be created? Kind regards, Jan ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Feedback for Vespucci-dev
Am 2012-10-01 08:16, schrieb andrewg_oz: 2. I think I'd prefer the undo/redo icons looked the same as the undo icon we already use in the action bar. Keeps the UI consistent. Just mirror for redo (like you've done with the arrow). I tried that first, but changed it to the custom arrow once I noticed the original icon is too large, does not properly align with the text and enlarges the fields. With your cropped version, these problems are less strong, so I think its OK now. Kind regards, Jan ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Feedback for Vespucci-dev
Hi, I have now made and committed the following changes. - Add Advanced Preferences (and move some stuff there) - Add pref to disable context menu in unnecessary cases (default: enabled = show always) - Add heuristics for context menu (to always show it when really necessary). If the above-mentioned pref is unset, it basically works like this: Get the list of touched objects. If there are OSMBugs, always show. If there are no nodes but multiple ways, always show. If there is at least one node, then the nearest node is considered to be clicked, UNLESS this node has another node *really* close to it (not to the click area). This ensures that exactly overlapping nodes and ways always bring up the context menu, while other cases can be handled quickly. (Way tolerance is low enough so it doesn't cause false hits.) - Sort context menu entries by distance to click (nodes by distance first, then ways by distance) - Undo menu: Add background colors (black/white) and icons properly I now always set background and foreground color. The problem before was that I only set one of them and/or only in one case, I think. I also added custom-made greyscale icons. Feel free to remove the icons if they suck/eat too much space or remove the coloring if it causes problems (I think it shouldn't this time). Color has the big plus over icons that it a) doesn't need space and b) is easier to notice than small icons. - Tag editor: Changed X icon size to match editor rows, force minimum text field size The text fields were REALLY small on my device, and the X was too large. Indeed, the spacing between the fields was the X being larger than the text fields. I gave the text fields a minimum height and a bottom border to fix this, and shrunk the X so it is now aligned. - Tag editor: Set autosuggest dropdown spacing to minimum text field size - I chose to use 36dp as the height of one dropdown item (not counting the spacers). This is already more than the text field size on my device, which is 36dp *including* the spacers (and was even smaller before I introduced the minHeight). If the fields and X are big enough to hit, the autocomplete is too. If the autocomplete is too small, we need to also enlarge the fields (in my tests, I didn't have trouble hitting them correctly, though). I suspect the field height could be device/style specific. I will test the entire application on a Galaxy Ace (small low-res screen with Samsung UI) as soon as I can. If it looks and works OK there and on the Galaxy Nexus, it will probably be good for everything. We need to check the ActionBar in the action modes and the tag editor on such a device. Forcing menu items to appear using showAsAction=always might cause trouble if they don't fit, and if menu items with icons overflow, it could be possible that it will be white icon on white background again. (I fixed this for the main action bar by replacing the transparent white with a non-transparent gray that will look the same on the actionbar, but will be at least a bit visible on white backgrounds as offered by overflow menu of the Samsung UI). I did NOT make any changes to the content of the autosuggest (i.e. re-add the duplicates or move the corresponding entries to top), so we currently have a plain alphabetic list. I would like to hear some more opinions on this if possible. Should we maybe remove the distinction between recommended and mandatory tags and add them all when applying a preset? Currently, recommended tags are more or less invisible to the user, so we should do *something*. Oh, and I just noticed that I forgot to update the appname.xml, but I am not the first one. Should we maybe put a $Rev: $ SVN tag in there for now? The dollar signs look nasty but it makes sure it's always up to date. Kind regards, Jan ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
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
