Subsurface mobile: delete and sync operations.

[Joakim Bygdell]

On 19 July 2017 at 15:03, Dirk Hohndel <dirk at hohndel.org> wrote:

>
> > On Jul 19, 2017, at 4:11 AM, Willem Ferguson <
> willemferguson at zoology.up.ac.za> wrote:
> >
> > I must preface this expressing my pleasure in seeing what is happening
> with Subsurface-mobile version 2. The enormous effort that is going into
> this and the incredible difference that it makes to the usability of the
> program. I am privileged to be associated with this team that is creating a
> remarkable piece of software.
> >
> > I experience that there are fundamental problems with manipulating dive
> lists on the mobile platform.
> >
> > 1) See screencast at
> >
> > https://www.dropbox.com/s/47m9ujbzancuxen/2017_06_24_11_28_30.mp4?dl=0
> >
> > using 4.6.4.443. This playback speed is at a THIRD of the live speed.
> >
> > View dive list.
> >
> > Delete a dive
> >
> > Go back to dive list
> >
> > Select another dive and hit delete button at bottom.
> >
> > Display goes to *previous deleted* dive and the second dive is not
> deleted at all. Looks like delete sequence is not even started.
> >
> > Hitting the Android Back button (to get back to the dive list) crashes
> the program.
> >
> > Fortunately, upon restart of the program, no dives are deleted.
> >
> > I can supply adb logcat if required.
>
> I have now been able to reproduce one of these "delete - divelist goes
> weird" bugs. I still don't understand why the model gets confused, but at
> least now I can work on it.
>
> > 2) When deleting a dive/profile from the button at the screen bottom,
> the undo option only shows up for about 1 second. This is way too short for
> an unprepared user to respond appropriately. And then the dive is
> (theoretically) permanently deleted. Extremely user-unfriendly. The
> interface would be much more safe if the 1-second button rather said:
> "Confirm delete". Noticed the steps in Github that are required to delete a
> repo? You must really be convinced to do this in order to delete a repo, no
> way of doing that accidentally. I am pretty conversant with the mobile UI
> and on a few occasions my finger has managed to accidentally stray to the
> dustbin under a dive profile. And then the "Undo" button comes up, out of
> the blue, and I am so startled that I do not respond in time. Dive gone.
>
> The pattern of confirming an action is something that is not well liked in
> mobile apps. I am pretty sure we had this discussion here a while ago. I
> agree that it's way too easy to delete a dive. Of course, that dive isn't
> really gone (thanks to our git storage), but that's no consolation for a
> regular user.
>
> I'm not sure what to do about this. Davide, you are our resident UI
> guru... what do you think?
>
> > 3) I intentionally deleted four dives from my dive log (using dive list
> and red button) in order to test the delete option. Then I tried to regain
> them by doing a "Save to cloud" from my desktop. Nice, divelog saved. Then
> I do a "Sync with cloud" on the mobile but the four dives do not come back.
> No way of get them back, except by uninstalling Subsurface-mobile on
> Android and doing a complete reinstallation, re-initialising the cloud
> credentials and reloading the divelog from scratch. My four dives are back.
>
> You'd think that would work, but it doesn't because of the way git merges
> the operations. We need a UI to bring back deleted dives. It's not really
> hard to do, it's just something someone needs to implement.
>
> > I am just thinking how an unfamiliar user will struggle with this
> interface. My firm suggestions are:
> >
> > a) On Android, the "Sync with cloud" tries to be too clever and as far
> as I can see does not succeed. As user I would be much more happy if I had
> complete control with two more options: "Save to cloud" and "Load from
> cloud". These are unambiguous with clearly predictable results.
>
> The way git works it's not that easy. Yes, it's easy to implement "forget
> everything I've done and go back to what's on the server". I actually
> started working on that and then got side tracked. I should have a branch
> that has the beginnings of that somewhere. But "save to cloud" and ignore
> changes from the other side is not something that I'm keen to implement.
> That's basically a force push and that will make any other Subsurface
> instance that is connected to the cloud storage decidedly unhappy. So this
> needs a bit more thought.
>
> > b) Make the delete dive action more safe. Dive data are valuable, often
> with significant time spent in writing notes, specifying cylinder pressures
> (that are lost upon delete) and the like. One does not want to lose a dive
> accidentally.
>
> Agreed. I'm just not sure what the best user interaction for that would be.
>

Simple fix, remove the delete button in the dive details view, in order to
delete a dive from the dive list
the user must pres and hold for a few seconds until the trashcan appears
then click it to delete the dive.
A bit cumbersome yes, but not very accident prone.

If we are to keep the delete function in the details view we should add a
"Are you sure?" popup.


> /D
> _______________________________________________
> subsurface mailing list
> subsurface at subsurface-divelog.org
> http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
>



-- 
Jocke
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.subsurface-divelog.org/pipermail/subsurface/attachments/20170719/2b90a510/attachment.html>