Inconsistent user interface

[john_percy]

I think it is time for some consistency in the user interface, particularly with regard to accepting or cancelling settings screens. I illustrate three different screens in particular.

1. Changing info text for a track.

Do I tap the back arrow, or the SAVE text? Answer, no. Hide the keyboard and there's a SAVE button underneath.

2. Choosing available maps.

Does the X on the top right corner cancel? No, it accepts the settings in the check boxes.

3. Accepting terms of use for a map

No, the orange box is not a confirmation button. That's up in the top corner, where it says CONFIRM. And the X means cancel this time.

Oh Menion, let's get this right!

[michaelbechtold]

SO spot on, John !

#1 illustrates the issue around keyboards and different ways to hide them. All action elements (save, cancel, ...) should be on the top to end such device dependent behavious once and forever.

"X" (pure close of popup) should be avoided or ALWAYS mean "cancel". And "cancel" PLUS  "confirm" or "save" (that may depend on the context) should be explicitly presented as text. So there is zero ambiguity.

Just my 2c.

Cheers
Michael

[Menion]

Thanks John,
absolutely agree that over years, some screens are really old and inconsistent compare to some new UI parts. As I'm not "guys from UI/UX bussiness", maybe you and others may help me with some tips & tricks here.

Mainly Locus unique "X" in corner of dialogs. It always works same > close dialog. And only depends if dialog has "set" button (then X close it without saving) or hasn't (then "X" also logically save changes). it is not possible to get rid of "set" button on all places, because dialogs like setup of notifications, needs test, if changed values are correct.

So options?

• get rid of "X" : unfortunately, back button works exactly same = same problem
• add "set" button into all dialogs: quite a lot of work and will slow down work in many places, but doable and brings united system
• get rid of "set": when validation is needed, keep visible only "cancel" button and validate data everytime, user will try to close dialog (by "X" or back button). Do not allow to close it untill all is valid or "cancel" is pressed
• any other ideas?

[john_percy]

Having X mean both "close and save" and "close without saving" is far from intuitive. At the very least, can we not differentiate and have a tick in the top bar for "close and save" and an X for "close without saving"?
I agree the back arrow has the same problem, not only in Locus.
As for my 1. not only is the SAVE button hidden (in my case) but the text in the top bar (<- Save) misled me into pressing the back arrow on more than one occasion.

[Andrew Heard]

Thanks John for opening this important discussion. As often, as Menion describes, the devil is in the detail. I guess experienced users subconsciously know which button to tap, where & when, but very confusing and frustrating for new users.

[Menion]

New Beta version 3.30.4.1 version just published.
Changes that may help to solve these UI/UX problems (feedback is welcome of course):

• removed "X" button in dialog corners ... uff, after all these years, really?
• updated screen with confirmation of online maps terms of use. Confirmation in top toolbar should be step-by-step removed from all remaining screens (POI alert, Altitude manager, ...)
• small UI improvements in selections of values in settings dialogs

[michaelbechtold]

Good start, Menion, but do not sto´p here, please :-)

Adding a POI: SAVE is in the right place (upper bar), but discard is hidden in a sub-menu - put one left, the other right, so people don't mess by error

Editing track infos: still the SAVE is on the bottom - wrong place for reasons explained - incl., but not limited to consistency.

TXs and cheers
Michael

[Menion]

Hmm I wrote already many times that I'm really not a big fan of confirm/cancel buttons in top toolbar. To be true, I really wants to get rid of them all. Problem is with keyboard and sometimes with full-screen mode, I know. Hard task ....

[JohnCNA]

I have another example of an inconsistency. Tap Add Waypoint. Tap the phone back button. It creates and saves the waypoint. The only way to not save is tap 3 dots and select Discard.

Exiting via the back button should abort and not save. Or maybe even ask Save or Discard before going back to previous screen.

[Andrew Heard]

I'd beg to differ @JohnCNA. In lots (most?) settings Locus saves with the back button, so in this case it would be consistent. Because mostly the settings will be correct it is probably a reasonable optimization for speed of operation, with the less likely use-case related to the slower Discard menu item.

[Menion]

Unfortunately, there does not exist general rule how to work with this "up button" (top left in the toolbar).
I'm searching and it is nicely written here https://commonsware.com/blog/2011/02/15/principle-least-profanity.html .... simply, not specified, so it's up to developers.

Uff, complicated task for me to be true . Have to think about it a little more. I absolutely agree that because app is quite old and content is added one by one, it is now quite a mess in the behaviour of old screens and new screens.