Cgeo: Proposal to access certain map settings

[moving-bits]

Taken from https://github.com/cgeo/cgeo/issues/8112#issuecomment-590012624 by @MagpieFourtyTwo:

Just an idea: What would you think about a (maybe semi transparent) icon list, where one can see the enabled resp disabled (e. g. crossed out) waypoint types?

Moreover I would prefer if the hide menu would not disappear on the very first tap, so one can enable/disable more than just one type in one go? Same applies to the Map Settings menu ... so one can set more than one option at a time - and a tap on the map, resp outside of the menu's area closes it ...?

[moving-bits]

Just an idea: What would you think about a (maybe semi transparent) icon list, where one can see the enabled resp disabled (e. g. crossed out) waypoint types?

Interesting idea. This could also be used for quick enabling / disabling.
OTOH map space is very precious. IMHO we should wait a bit for some feedback how frequently those features are used and then decide, whether to sacrifice some space for those toggles. Map bottom, in the center, might be a feasable place.

Moreover I would prefer if the hide menu would not disappear on the very first tap, so one can enable/disable more than just one type in one go? Same applies to the Map Settings menu ... so one can set more than one option at a time - and a tap on the map, resp outside of the menu's area closes it ...?

Understood, and sounds reasonable to me. As this behavior would be distinct from the way menu handling works today, those "hide settings window" could be a separate popup dialog which opens after tapping the "hide" menu entry. (Only needed if we decide not to implement toggle buttons as described above.) Similar for the "Map settings".

[fm-sys]

I decided continue this discussion rather here instead of #9281

@MagpieFourtyTwo had mentioned the idea of customisable action overlays like it is done in Locus. I really appreciate this idea and would like to add my two (OK, they have become three after all ;-) ) cents:

1. This action bar should be placed to the left and/or right of the screen as all other places are already used for displaying other information.

2. As a first step we can can just fill it with the most useful features and leave out the customization part and add it in a second later on IMHO.

3. Activating this overlay bar should be possible via the three dot menu, so it can be easily hidden if it's not needed right now and it takes too much screen space.

Ok, and for the hiding menu I agree that this should be a dialog rather a submenu...

[moving-bits]

I've played around a bit to find a way for displaying a popup for the hide settings. This is one possible solution, using a PopupMenu:

This menu is opened by tapping on the small "settings" icon at the map's bottom center.
Several settings can be changed without having to reopen the dialog.

Would this be a way to go?

[MagpieFourtyTwo]

Yes, definitely. Way better than the current menu solution.

Perhaps even a "reset automatic route to individual route" option can be added there?
And, yes, I'm aware that it may not perfectly fit in the context of this menu (in the eyes of a developer, i. e. with regard to the individual route context), but seen from the point of view of a not knowing user, it will probably make sense, to look right there ... and in fact disabling the route can be seen as a kind of hiding, too ... ;)

Ah, routing strategy - as one of the most often changed settings, at least over here - would also have deserved a place there ... IMHO.

[fm-sys]

IMHO the "settings" icon looks a bit lost there but I have no idea how to make it look better...

[MagpieFourtyTwo]

Perhaps it should just be a little bit bigger?

[geocachermgo]

I agree: My usecase: I want to check a certain area and use "All Caches". An easy way to switch "hide own/found" would be nice.

[eddiemuc]

IMHO the "settings" icon looks a bit lost there but I have no idea how to make it look better...

Could it be put in the header (like the "go to current position" and the "select map source" icon)?

[moving-bits]

I've implemented both ideas, for comparison purposes:

• enlarge icon in map bottom area from 24dp to 36dp
• set a fixed icon in action bar (ignore icon colors for now)

Icon in map bottom area is horizontally centered, a position which seems to work fine for both Google Maps and OSM.

Regarding the action bar: Right now we have only the "my position" icon as fixed icon in the action bar, and several others marked as "if room". On my mobile and the emulated devices I use, there will be the map selection icon visible as well. Only on tablets I get more icons (but not many).
To get the same view + additionally the "hide" settings popup button, I need to mark three entries as fixed. I'm a bit reluctant about that, as I fear that this might lead to problems on devices with smaller screens, cutting off more and more of the map title (eg: Cache name etc.).

What do you think?

[fm-sys]

I still like the idea of adding it to the action bar. But I would use a different icon and swap it with "select map source", which I would expect at the second right position out of habit...

[MagpieFourtyTwo]

I would have considered the icons for "My Position", and "Map View" as fixed (left to right) anyway ... never ever had a different subset. Apart from landscape view, where BTW (@fm-sys) "Map View" even goes to third (from right), as at the very right "Enable Live" and (in single cache context) "Hint" appear.

Anyway - to avoid icon confusions, and to save space for the cache name, I would suggest to use the icon at the lower end of the map. Down there is plenty of room, so why not use it. Moreover this can perhaps even be a come-on drug for the setting panes ... ;)

And perhaps it can still go some pixels downwards, so it's aligned with the scale?

[moving-bits]

Thanks for your feedback. I opened PR #9455 with a first working implementation to get some more hands-on experience. Icon is at the map bottom in this case, let's see how this works.

[geocachermgo]

Is there an APK available?

[moving-bits]

Is there an APK available?

It's not yet included in the nightlies, but you can use the build from the PR: On the PR page open the link "Show all checks" in the "2 successful checks" section, and follow the "Details" link beside the "default - build finished" entry. On the upcoming page you find the "cgeo-debug.apk" you are looking for.

[geocachermgo]

Sorry, but I'm still not able to find it. Is the PR 9455? On https://github.com/cgeo/cgeo/pull/9455 the is no Show all" link. On the tab "checks" there is only one check. I also search on codacy: https://app.codacy.com/gh/cgeo/cgeo/commit?bid=17246552&cid=513392291 but without success.

[moving-bits]

I've merged this PR today - seems like the "show all checks" links is removed then.

Can you see the direct links to our CI?

• Build: https://ci.cgeo.org/job/cgeo%20pull%20request/4078/
• APK: https://ci.cgeo.org/job/cgeo%20pull%20request/4078/artifact/main/build/outputs/apk/basic/debug/cgeo-debug.apk

If not, you'll have to wait for today's nightly, it will be included then.

[geocachermgo]

Ok, now I see it in the CI list #3151

[MagpieFourtyTwo]

I've merged this PR today - seems like the "show all checks" links is removed then.

apk is still there, I think:

1. PR9455
2. scroll down to "merged commit" ... => click View details
3. at the end of the line build finished line click on Details
4. Build page with .apk is shown.

Or am I wrong?

[geocachermgo]

You are right, its there. But I was strictly following moving-bits instruction. Since in a few minutes the new nighley will be there, I'll check with this.

[geocachermgo]

My remarks:

• Wouldnt be "Filter" instead of "Verbergen" a better wording and funnel instead of gearwheel a better icon?
• With displaying "all", the filter "surpress found" is not working. (I think that was mentioned before?)
• Could this also support #5599 ?

[moving-bits]

apk is still there, I think:

1. PR9455
2. scroll down to "merged commit" ... => click View details
3. at the end of the line build finished line click on Details
4. Build page with .apk is shown.

Yes, you're right - hadn't recognized that yet. Thanks!

[moving-bits]

Thanks for your feedback.

Wouldnt be "Filter" instead of "Verbergen" a better wording

You're talking about the menu entry, yes? This is called "Hide" since quite some time.
But anyway - "filter" could have two different meanings:

• "Filter to see only xxx" (which is the more common meaning for "filter", the same we use in our cache lists, but not the meaning we have here), and
• "Filter to see everything but xxx" (which is what we are doing here)

Using the word (and symbol) for "filter" in this use case would be a bit confusing, IMHO.

and funnel instead of gearwheel a better icon?

Besides the reason given above, I've chosen a gearwheel as it is a common symbol used for a more generalized "settings" meaning. For now, it's only the former "hide" options, but it's not limited to and we have a discussion on what else to put into that popup for a quick access.

With displaying "all", the filter "surpress found" is not working. (I think that was mentioned before?)

You mean, coming from a cache list, and select "show on map"? This is intentionally, IIRC.

Could this also support #5599 ?

Yes, if someone is willing/intersted in implementing that feature, the new popup might be a good place to access that switch.

[MagpieFourtyTwo]

Checked the new Settings icon in map. In short: Like it very much! ;)

Just two things (for now ;) ) which "surprised" me:

• I would have expected to see the changes immediately, i. e. as soon as I remove/set a check.
  If I additionally have to click [Ok] to see the effect, there is not that much difference to the menu behavior (IMO)
• I would have expected that after setting a check and then touching the map, the change just made is active, but it isn't.
  Following this, I would suggest to omit the [Ok] button completely, esp, if the immediate change is implemented

[moving-bits]

Possible answer to both points:

One of the original intens to implement such a popup was to be able to change multiple settings in one step, without having to re-enter the three-dot-menu, finding the submenu etc. That's why the popup does not close automatically after enabling / disabling a setting, but waits for your ok instead.

Given the size of the popup you don't see that much of the map, so there's no need (IMHO) to immediately update the map after changing a single setting, especially with the tile cache being cleared and redraw started after each setting.

So if you only change a single settings, it's the same effort as before (three taps for opening the popup, changing the setting, confirmation - in contrast to open three-dot-menu, open submenu, change setting) and the same responsiveness, but as soon as you change multiple settings in one step, you are much faster.

[MagpieFourtyTwo]

A pic tells more than 1000 words ... ;)

[MagpieFourtyTwo]

That's why the popup does not close automatically after enabling / disabling a setting, but waits for your ok instead.

That it does not close is - of course - perfectly fine. ;)
Nevertheless the changes should happen immediately, IMO.
And should stay, if the popup is closed by e. g. clicking in the map.

[MagpieFourtyTwo]

My expected workflow would be:

• click the settings icon => popup opens
• checking/unchecking => map updates immediately, popup remains open
• clicking the map (or [Ok], if it's decided to keep it for more clearness) => close popup
  (with changes remaining in effect, no matter how the popup has been closed)

[MagpieFourtyTwo]

Just realized that the screen shot you posted the other day had a similar display resolution.
So how come you're saying "don't see that much of the map"?
There is about 70 % visible, which I would not consider "not that much". ;)

[moving-bits]

Just realized that the screen shot you posted the other day had a similar display resolution.
So how come you're saying "don't see that much of the map"?
There is about 70 % visible, which I would not consider "not that much". ;)

That's so yesterday's nightly... :-)

Due to some limitations with the PopupMenu I had prepared a switch to a "regular" dialog, see #9461, which is not yet in the nightlies. There's much less visible of the map here, though. (That's what I was referring to.)

If we would stay with the popup, then we could implement it the way you've described, meaning:

• changes can take place immediately (at the cost of clearing the tile cache and redrawing map multiple times, if several settings are changed)
• popup closes by tapping anywhere else on the map
• but also no icons, as PopupMenu does not support it (and I couldn't make it to support them in any of the unofficial ways I've found so far)

[fm-sys]

I had prepared a switch to a "regular" dialog, see #9461, which is not yet in the nightlies. There's much less visible of the map here, though.

+1 for using an alert dialog

but it should only have a OK button (not OK / Cancel) and the change should also be done when canceling the dialog via clicking outside. With such a dialog, changes can be applied when closing - a direct redraw is not necessary IMHO

[MagpieFourtyTwo]

Ah, ok, wasn't aware of #9461 - looks nice, indeed. So, please forget the above. ;)

Question: Which one is this individual track you want to hide?
AFAIK we have these:

• "routing" route (the standard one)
• history track
• GPX track/route (loaded)
• individual route (clicked or loaded)

To avoid confusions I would either remove this one completely or ...
a) add all of them
b) keep terminology as is right now
c) keep order as is in current map menu (1. Routing, 2. History, 3. GPX, 4. Individual)

Moreover I would add an entry for the pretty dangerous Automatically route to target option.

[Lineflyer]

If we would stay with the popup, then we could implement it the way you've described, meaning:

I did not participate the discussion earlier but just saw the result and still want to give my few cents to it:

Reading the limitations of the popup I would prefer to stay with the "regular" dialog. There are several advantages and only the drawback, that changes are not immediately visible. IMHO the "regular" dialog (as seen in PR #9461) looks much more clean and self explanatory.

[moving-bits]

Question: Which one is this individual track you want to hide?

It's the GPX track/route. This had started as "Load individual track" and "hide individual track" menu entries. The feature got renamed when I extended "GPX track loading" by "GPX route loading" - and obviously I forgot to rename the "hide" menu entry back then...

[moving-bits]

IMHO the "settings" icon looks a bit lost there but I have no idea how to make it look better...

We could also apply a background to the icon to make it more prominent. Maybe the same semi-transparent background we use for the distance & target infos?

Icon could be this size or a bit smaller:

What do you think?

[Lineflyer]

The smaller the better to avoid accidental touch and semi-transparent is good in order not to completely obstruct the map below.
Like it.

[MagpieFourtyTwo]

I like the fully transparent one better. Looks more harmonic, IMO, and does not disturb the map picture.
And the icon looks sharper. But this is personal taste, I would say.

[MagpieFourtyTwo]

Just tested the new version - and like it. Well done! 👍

As there is still plenty of room, I would add Show circles, as it is a map setting, too (which the icon "promises" to be found there ;) ). Maybe some would like to see Show direction in there, too, as it is also a map setting, but I would consider it a "set & forget" option, which is rareley changed (I did not change it a single time), so IMO no need to add a shortcut for it.

What gets changed a lot. too, is the routing strategy ... perhaps you have an idea for a shortcut to this, too ...?

[eddiemuc]

I noticed that the icons seems to got lost in the new dialog. On my phone (current release) it looks like this:

[fm-sys]

Current master looks like this for me:

BTW the German translation is inconsistent. Should we use "ausblenden" or "verbergen" for all of them?

[eddiemuc]

Sorry my master was outdated

[moving-bits]

As there is still plenty of room,

I'll look into it.

Some suggestions:

• add "hide circles"
• add "compact symbols" (with three buttons)
• add "routing mode" (with four buttons)
• remove "show direct line" (this is a one-time setting, IMHO, should be fine to have this in general settings only)

This could completely replace three submenu in the three-dot menu (map settings, hide, routing).

We would then have the following entries left in the three-dot menu, which can be clearly assigned to three groups:

• three/four entries regarding caches:
  
  
  
  • enable live
  
  
  • save new
  
  
  • save all
  
  
  • show as list
  
  
• three entries regarding map internal settings:
  
  
  
  • select theme
  
  
  • theme options
  
  
  • select map language
  
  
• three entries regardings tracks/routes:
  
  
  
  • position history
  
  
  • GPX track/route
  
  
  • individual route
  
  

[fm-sys]

BTW the German translation is inconsistent. Should we use "ausblenden" or "verbergen" for all of them?

Some thoughts about the German language:

• "verbergen" should be used, if it is visible by default ( -> hiding is an additional feature)
• "ausblenden" should be used, if it was explicitly "eingeblendet" by the user before that ( -> come back to the default setting)

I have adapted the translations accordingly...

[MagpieFourtyTwo]

add "hide circles"
add "compact symbols" (with three buttons)
add "routing mode" (with four buttons)

To be honest: Had all of them in mind, too, in a first rush, but was afraid, the menu will perhaps get a bit overloaded ...?
Moreover meanwhile I would consider "hide circles" (as well as "compact symbols") as one time settings, anyway,
esp. with the new possibility to set the circles near to transparent, so one can see them without cluttering the map.

As for routing mode: This is fact a single click setting, i. e. in contradiction to e. g. the "Hide" stuff, where multiple changes in one go are more common, with routing you just want to select one and go ...

Hence a menu, where you can change routing mode, may close as soon as the selection has been made.
So perhaps there may be a second "Routing" icon between scale and current gearwheel for such a thing ...?

[moving-bits]

So perhaps there may be a second "Routing" icon between scale and current gearwheel for such a thing ...?

I fear that we don't have enough space reliably - from the left "Google Maps scale bar" is coming (depending on zoom level), and from the right "OSM zoom":

So I investigated further along the buttons alternative in the same dialog. A possible result looks like this:

[moving-bits]

Regarding the menu entries:

Where shall we put the following entries?

• show/hide circles (currently map only, but could be moved to preferences or shown in both places)
• show direction line (currently map + preferences)
• compact icon mode (currently map + preferences)

Don't know how frequently (and therefore easily) people like to switch those settings.

[Narrat]

Regarding the circles: I personally don't use them, but I know people which do use them fairly often. For them it would be a bother if it weren't easily switchable.

[MagpieFourtyTwo]

Buttons for routing strategy ... great idea! Like it. :)
What if the buttons (which IMO are a "solo setting", i. e. the only change in this dialog, if clicked) immediately close the box?
Or would two different closing strategies in one dialog be too confusing ...?

As for the others - what about s/th like this:

[bekuno]

I like the compact variant of @MagpieFourtyTwo
I would use a header "Show at map" (like "Use compact icons") for the checkbutton section and omit all "Show" texts on the check buttons.

[MagpieFourtyTwo]

Had the same idea in the beginning, but discarded it, as the "Show at map" needs an own row, thus "wasting" space.
And I did not want to drop the "Quick settings" line, as there is not only "Show/hide" stuff.
But ... if it's in the same small font like the "Use compact icon" ... may work.
But then the "Always route to ... " check would not fit perfectly ... if this would be ok ...

[MagpieFourtyTwo]

Ok, another go - it's even clearer, I would say:

[moving-bits]

Really like the compact version, especially the second proposal is quite clean. But we need to test with different translations, whether texts stay short enough to be presented in two colums + icons and checkbox, also with different font settings and screen sizes. We need to avoid horizontal scrolling.

Or we could use buttons instead of checkbox + icon, with today's icon being the symbol for the button.
(And maybe signalling the "activated" state with our accent color instead of a thin white line.)

An alternative could be to use mostly buttons, and text for labels only, eg.:

| Label | (button 1) | (button 2) | (button 3) | (button 4)
| ----- | ----- | ----- | ----- | ----- |
| Caches | (button own) | (button disabled) | (button archived) |
| Waypoints |(button original)|(button parking)|(button visited)|
| Other | (button circles) | (button direction line) |
| Tracks | (button position history) | (button gpx track/route) |
| Compact | (button on) | (button auto) | (button off) |
| Routing | (button straight) | (button walk) | (button bike) | (button car) |

(with "label" in the same line with the buttons)

Buttons for routing strategy ... great idea! Like it. :)
What if the buttons (which IMO are a "solo setting", i. e. the only change in this dialog, if clicked) immediately close the box?
Or would two different closing strategies in one dialog be too confusing ...?

I would stay with one paradigm per dialog.
But we could leave out the "OK" button, IMHO, as it suggests that you can also "Cancel" the dialog, without settings being applied - which is not the case here. Leaving the "OK" button out would be consistent with the other (map) settings dialogs as well.

[MagpieFourtyTwo]

Hmm, to use buttons for hide/show, too, would of course save the room for check mark and symbol (while the symbols are no must anyway, esp. if horizontal room becomes an issue), but IMO there will be no advantage at all, if there are three buttons per row plus a leading label - which makes four phrases per row to be translated (thus potentially long), compared to the "check mark version", where there are just two of these, thus the risk of running out of space is doubled with the button proposal:

Waypoints - original - parking - visited
Waypoints - Original - Parking - Visitados
Wegpunkte - Original - Parkplatz - Besucht
Waypoints - Oryginalne - Parking - Zwiedzane
ウェイポイント - オリジナル - 駐車場 - 訪問済み
Путевые точки - Оригинал - Парковка - Посетили

Pretty long ... and probably buttons are not as intuitive as check marks, esp, if all buttons are in the same state. Then it's hard to tell (at a glance) which state they are currently in ... hmmm ... I'm in fact kind of undecided ...

[MagpieFourtyTwo]

Forget about the "hard to tell" part - when using the accent color, it should be unambiguous. ;)

[moving-bits]

Hmm, to use buttons for hide/show, too, would of course save the room for check mark and symbol (while the symbols are no must anyway, esp. if horizontal room becomes an issue), but IMO there will be no advantage at all, if there are three buttons per row plus a leading label - which makes four phrases per row to be translated (thus potentially long),

Nah, beside the labels there would be no phrases to translate - the buttons would be the made of the icons only.

[fm-sys]

the buttons would be the made of the icons only.

The icons are hard to understand without a description besides them. So I would leave it checkbox based, as I don't see a benefit of using buttons. This would also be consistent to our settings...

[MagpieFourtyTwo]

the buttons would be the made of the icons only

I go with @fm-sys: Even if the icons would match the ones shown in the map, i. e. the users are used to, they are not mnemonic nor unique enough. While it would work fine with "found" caches, as the smiley is well known, already "disabled" vs. "archived" will be hard to either explain or distinguish (as they seem to use the same icon in map anyway, so there must be a new icon, which nobody knows). Moreover the "point" icon for "Original waypoints" is used in c:geo for "Reference Points", too ...

IMNSHO a user interface should always target at users below average. And should be as intuitive as possible ... thus symbols, that must be explained, should be avoided, IMO. What is in fact s/th I already don't like with the IMO not really self-explaining symbols for storing/deleting waypoints to PN ... would have stayed with the text buttons over there, too. Yes, the icons look cool, and fit perfectly fine the other two, but a non-experienced user has de facto no chance to get what they do. Not that hard, over there, as this is a kind of special function anyway, but please, don't let's do the same thing in a dialog with basic functions.

[geocachermgo]

Since the long click on the icons shows the text I doubt "de facto no chance".

[MagpieFourtyTwo]

Yep - I am making the same mistake, too, way too often: We are over-estimating the knowledge of average users.
Reality is: Most of them do not even know that the possibility of a long-click-hover-help-message exists.

Although the long-click-help-text is of course a nice feature, it's not evident to the user and most regretfully not consistently implemented, which makes it even harder to learn, use (and rely on) it. In fact you first have to know that it exists at all, secondly that it exists for this button, and even if you now these two (which is already knowledge "above average"), in case of these two buttons you just get two words, which do not really explain what will happen, as they do not even mention the phrase "Personal Note". As for me, this hover text should be written on a button, and the hover text itself should be expanded and explain in prosa what will happen when pressing the button.

I'll stay with it: IMNSHO a help text, that needs an additional help text, is no help at all. And a button, that has a help text, which needs additional explanation ... hope it's understandable what I'm thinking of ... ;)

[fm-sys]

Although I don't think this is the right place to discuss the PN buttons, I would like to make a small comment. Synchronizing the waypoints to PN is a function that will probably never be used by >95% of the users. Therefore we should move it into the overflow menu. Otherwise they would take up too much space when using text buttons, which is in no way in relation to the benefit for standard users...