[idea] Mobile UI #12: Auto-save pattern

[Bocio]

Previous idea here:
Mobile UI #1: general layout
Mobile UI #2: default action for main screen button
Mobile UI #3: Dive list item layout
Mobile UI #4: Dive list different layouts and menu option
Mobile UI #5: Sidebar
Mobile UI #6: Dive detail title
Mobile UI #7: Dive list EOL and Swipe To Refresh
Mobile UI #8: Sidebar Header
Mobile UI #9: Settings page
Mobile UI #10: Title Bar
Mobile UI #11: Edit Dive / New Dive layout

All original mockups made with moqups and are online at: (https://app.moqups.com/Bocio/3SSyFCoEwP)

Currently Subsurface mobile app has an explicit "save button" on the edit/new dive panel.
This poses two problems:

Screen space

Limited screen space while editing giving a really bad user experience. When keyboard slide in, the large save button occupies most of the visual space. See this screenshot:

Wrong gestures

If the user doesn't press "save" button explicitly he can easily loses all entered data just pressing back button (we have about 15 fields). Moreover the "dive edit" panel floats: swiping the panel upward or downward too far, actually delete it loosing all the data.
See this screencast: https://www.youtube.com/watch?v=qXcIIhQlzBQ

• On the first attempt I press the back button
• On the second attempt I slide the panel downward

Proposed solutions

Regardless of chosen solution, edit/new dive panel must be fixed, not a floating panel.

• Silent auto-save function. Each time a field is completed via the keyboard "done" button, data are saved locally. Local storage is then synced explicitly by the user via the "sync to cloud" action.

• Validation and save/dismiss invoked when the user leave the edit/new dive panel. User can leave the panel via the Android navigation bar back button or via the back icon on the title bar.
  Whatever back button is pressed a dialog tells the user that the form must be saved or discarded. This solution offer us a way to validate user input before actually saving them. The form could contains invalid values or the user quit before bare minimum dive data are entered.
  Again, like the first scenario, Local storage is then synced explicitly by the user via the "sync to cloud" action.

Some notes:

Hereafter some QA on this topic from UX Stack Exchange. Some of them are old (2012). Now both Android and IOS have mostly implemented background auto-save.
Some of the most used apps:

• Messaging (whatsapp, Hangout, Messenger)
• Email (Gmail, Yahoo)
• Social network (Facebook, Twitter, Google+)
• Productivity (Calendar, Any.do, Wunderlist)

provide auto-sync feature, which are seamless to the users.
Most of users also are using these apps, and their mental model is already set with an expectation of a hassle free, almost invisible auto-sync feature.

What is the best user experience in our use case?

https://ux.stackexchange.com/questions/106671/best-practice-when-saving-settings-to-backend-on-android

https://ux.stackexchange.com/questions/79558/manual-saving-loading-from-dropbox-in-mobile-app

https://ux.stackexchange.com/questions/88541/is-the-following-approach-better-for-mobiles-missing-save-option-in-google-ke/88551#88551

https://ux.stackexchange.com/questions/17538/android-explicit-save-or-background-save

[willemferguson]

Davide, Good point, above.

1. We need to have absolutely smooth operation when the user is at a remote dive site with no wifi or other Internet access.
2. Because the mobile input is awkward and one cannot see all the information for the whole dive on one screen, one probably needs a larger degree of user confirmation that the dive data are indeed to be saved, when compared to the desktop Subsurface.

[Bocio]

We need to have absolutely smooth operation when the user is at a remote dive site with no wifi or other Internet access.

Well, we cannot keep the user from using Subsurface if there is no connection. We have to make sure data is correctly saved locally and then sync to cloud when connection is available. Maybe we should find a simple way to indicate that you have some data locally stored but not synced on cloud.

Because the mobile input is awkward and one cannot see all the information for the whole dive on one screen, one probably needs a larger degree of user confirmation that the dive data are indeed to be saved, when compared to the desktop Subsurface.

Another reason to use background auto-save each time a field is entered. Then we can activate only form validation on edit/new dive panel exit.

[jimbodude]

Maybe we should find a simple way to indicate that you have some data locally stored but not synced on cloud.

It would be nice to be able to quickly see that things haven't been synced. I have 3 ideas. They could be combined or used separately. This discussion might be out of scope for this issue - we can move it to a separate one if you think it's worth it.

• When any local changes exist that are have not been synced
  • A button appears on the "dive list" screen on the left side of the "Add dive" buttons with a "cloud sync" icon
    • Pressing this button synchronizes changes.
• If there are no local changes, the button does not appear

This makes the hint "you should do a sync" more obvious and easy to access.

• When local changes exist that have not been synced
  • On the dive list
    • Each dive that has changes carries a "cloud sync" icon
  • On the dive view page
    • Each dive that has changes carries a "cloud sync" icon

I think this option might cause a lot of clutter, but it might be nice to know "what changed", not just "something changed".

• When local changes exist that are have not been synced
  • A "cloud sync" icon appears at the right side the title bar

This makes the hint "you should do a sync" more obvious, but leaves the sync action initiation alone.

[dirkhh]

On Thu, Jul 20, 2017 at 11:25:54AM +0000, willemferguson wrote: Davide, Good point, above. 1) We need to have absolutely smooth operation when the user is at a remote dive site with no wifi or other Internet access. 2) Because the mobile input is awkward and one cannot see all the information for the whole dive on one screen, one probably needs a larger degree of user confirmation that the dive data are indeed to be saved, when compared to the desktop Subsurface.

Or we need to ask ourselves why we are spending so much time on something that I doubt a lot of people will use. Seriously, who'd enter all that data on a mobile phone. Oh, right I forget. I'm old and cranky, some people think that's a reasonable way to interact with a device. Personally, I still am not convinced that having manual edit is actually desirable. We implemented this mainly because we didn't support download, but... meh. To get this right and to work smoothly on nine thousand different phones with 20 different Android flavors (and of course iOS) and 20 languages. Yeah, I know, I'm focusing on the negative...

[willemferguson]

I like the trend as little as you do, but this is undoubtedly where things are going. So many people I know have switched over to tablet (ipad or Android) and do not have a "formal" computer any more because a tablet enables browsing, facebook, email and a fair word processing and spreadsheet functionality, and that is all they feel they need.

1. My suggestion is that one aims to have Subsurface-mobile suitable for recreational divers who would not use the Desktop version; a full-on app but with reduced capability. I think we are just about there. As far as DC download is concerned we are not primary looking at Bluetooth-geared equipment such as Shearwater or G2, used by advanced/tec divers. We are primarily looking at FTDI transfer for the single-cylinder diver with a DC such as a Zoop who does 5-15 dives a year: frequently enough to want to log dives in a simple way.

2. The elephant in the room is what the future is for iPad or Android devices with a 10" screen that have enough resolution to, in principle, run desktop Subsurface efficiently. Desktop Subsurface can indeed currently be launched on an Android device. Should one see Android as just another target OS next to OS/X and Microsoft? What about iOS on iPad? The strategic approach would not necessary be to launch a big initiative for desktop Subsurface on "large-screen" equipment with a "mobile" OS. But it would include managing the software development in a way that does not preclude these transitions.

Kind regards,
willem

[dirkhh]

Please keep in mind that
a) there will be no FDDI download or BT download on iOS. So that's BLE only; right now Scubapro G2, EON Steel, new Petrel 2, Perdix and all Perdix AI. And a small number of other computers that we could support, but don't (including the newest OSTC, the Aeris 300CS and it's successors). So VERY limited download ability.
b) unless @glance- comes up with a different way to work around the SELinux issues, most newer Android phones and tablets (including every single one that I own) won't support FDDI, either.

So the target market that you are aiming for, is by definition very small.

I will not reject code to fix some of the remaining functionality gaps (stars/viz are missing). I'm less enthusiastic about the more complex ones (e.g. tanks - but maybe we can offer tanks that have previously been used in the same file?)

And also, please look at the problems on many phones were the keyboard covers a SIGNIFICANT part of the screen - yes, what we do right now makes things worse (we might have to disable the ActionButton when the keyboard is shown or something), but even without that the screenshot above should make it clear that this is not really a viable platform.

[dirkhh]

Separate comment to actually address the idea here...

(1) screen space: couldn't agree more. Terrible. I'm ok with going away from the floating window as that will help a little, and as I just said, maybe turn off the ActionButton (maybe depending on screen size? I don't know).
(2) the autosave one is tricky. Quite a few times you have told me "don't do pop-ups, don't do positive confirmation dialogs". Yet that's exactly what you are asking for here. Why is this OK here, but not ok for delete? Or for saving settings?

[willemferguson]

On 22/07/2017 07:36, Dirk Hohndel wrote: Separate comment to actually address the idea here... (1) screen space: couldn't agree more. Terrible. I'm ok with going away from the floating window as that will help a little, and as I just said, maybe turn off the ActionButton (maybe depending on screen size? I don't know). (2) the autosave one is tricky. Quite a few times you have told me "don't do pop-ups, don't do positive confirmation dialogs". Yet that's exactly what you are asking for here. Why is this OK here, but not ok for delete? Or for saving settings?

Look at attached image. If the grey banner area above the input (image on left) is removed and the keyboard is adjusted for efficient screen use, then the situation improves quite a bit (image on right). Kind regards, willem

[Bocio]

Ok let's see this as several separate activities that all together improve usability a lot.

• Arranging text field labels on top of the input area and using all the horizontal space available will improve it a lot. I don't know if Joakim is already work on it. It's really a small mod. Basically only layout arrangement.

• action button should be removed only if we implement auto save that nowadays is implemented on most app. We are so used it it that we didn't notice it. I don't remember I yelled against popup :) anyway I proposed to add just one popup IF the user exit the edit panel with inconsistent data.

• I'm fifty (OMG) and I usually I hate writing on the phone. With newer large screens (6" is becoming quite usual) and good UI design it's becoming a less miserable experience.

[dirkhh]

(1) YES - totally. Agreed.
(2) I really worry about getting this one right. The action button is obnoxious (especially on some phones where it seems crazy large compared to the rest of the layout - on my phones it isn't that huge), but it has a very clear semantic. With no action button, it may be entirely non-obvious how to exit the screen. And especially a first time user won't know how to actually save changes and how to abort the edit. I'm not disagreeing that another semantic could be much better than what we have, but we want to make sure that the new semantic is discoverable. "Save when I tap 'save', abort when I tap 'back'" is reasonably intuitive and discoverable...
(3) I will be fifty in a couple of months... wait, what?
Yikes.
Anyway. The challenge is the onscreen keyboard, autocorrect, and the fact that on the 9475 phone models that Android currently supports the range of usability is so insanely wide. On some of the larger ones I agree, there is enough screen real estate that (ignoring the input issue) the experience is ok-ish. But some of the smaller ones. Terrible, regardless what we do.
Once again, I may sound like I'm arguing against you. I am not. What I'm trying to do is to make sure we keep some of the constraints in mind that I have run into over the last couple of years of working on this UI.

[willemferguson]

Look at attached image. If the grey banner area above the input (image on left) is removed and the keyboard is adjusted for efficient screen use, then the situation improves quite a bit (image on right).

The images somehow didn't make it into the issue, but I saw them in email. Yes, you can improve the space-usage above the keyboard. But remember that on most phones we have no (or very little) control over how the keyboard is rendered. And I've now seen enough screenshots from phones where the keyboard covers a full 60% of the screen to know that this is a major issue. Nothing we can fix, just something we should keep in mind. /D

[Bocio]

And I've now seen enough screenshots from phones where the keyboard covers a full 60% of the screen to know that this is a major issue. Nothing we can fix, just something we should keep in mind.

AFAIK Unfortunately on all Android flavors, keyboard height is user configurable.

The action button is obnoxious (especially on some phones where it seems crazy large compared to the rest of the layout - on my phones it isn't that huge), but it has a very clear semantic.

On mine (1280x720) too. At first I thought it was just a resolution or screen density matter because on other 1080 phones I tested with the same screen it was smaller. Actually other apps on my phone have a smaller button, not an eyesore like mine :) Maybe there's something we missed into Kirigami parameters? The same problem happens on the title bar font. Completely different sizes on different phones while the current dive-list it's the same.

Generally speaking:

1. I completely agree that you cannot port on mobile app the entire desktop experience nor features of desktop Subsurface. It's plenty of famous apps that are streamlined/simplified on their mobile version (i.e. Gmail).
2. Once you give users a new feature/functionality you have to implement it right. Better not having at all than having a half-backed functionality. Of course I understand the reasons behind the first version of Subsurface.
3. For the above reason, you see that I'm not proposing new implementations but I'm suggesting improvements on what we already have.
4. The star of the upcoming version will be DC download. Yes there are caveats but AFAIK it will cover new BLE devices that are what the people likes more now. I made for fun that video with my old Viper but really I don't believe that kind of users will tear their dry-suits up if they cannot download dives on their phones. BT/BLE DC is a completely different story. here in Italy it's very common see guys with Shearwater app downloading dives on daily trip boats (out of the water, they grab the phone to say their wives "hey I'm alive" and since they were there... download!). IOS problem is different.
5. In the end, I really think that with the DC download subsurface user base will spread and even loyal users will start using it directly on the phone. We can stop them from trying only giving them a bad experience. I'm amazed to read how people is disposed to accept to transfer their data to different services/software to bring them in Subsurface...

Coming back to our headache...

With no action button, it may be entirely non-obvious how to exit the screen. And especially a first time user won't know how to actually save changes and how to abort the edit. I'm not disagreeing that another semantic could be much better than what we have, but we want to make sure that the new semantic is discoverable. "Save when I tap 'save', abort when I tap 'back'" is reasonably intuitive and discoverable...

Good point
On a lighter note. You better grab your light saber because I'm going to cite the beloved Axxxxn bar...
Reading this: https://goo.gl/HzavC7 Look at this comment: https://ux.stackexchange.com/a/88555
Other apps followed the same approach. Hereafter Trello. You have to press the keyboard "done" button or the check on the Axxxxn bar.

The problem with our huge button is psychological because it's there but it let me see part of the info behind giving me a bad feeling. Like having a dirty windscreen. Probably if I had the entire horizontal space covered by something else I wouldn't have the same feeling.

During the last week I was thinking to something more extreme (not for this version). I remember Thomas wrote that Kirigami supports up to three action button on the bottom drawer... Hence: download - edit/new - search :) but right now a bottom screen component doesn't help us.
Maybe with the work of @jbygdell on edit page the action button will be less intrusive but still we could lose all data if we don't press save.

Could we use a solution like Trello or Google (tick at upper right corner) just on edit panel?

Better sleep on it now.