> On Jul 19, 2017, at 6:30 AM, Davide DB <dbdav...@gmail.com> wrote:
>
> On 19 July 2017 at 15:03, Dirk Hohndel <d...@hohndel.org> wrote:
>
>>> 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?
>
> Unfortunately ATM I cannot be of great help on these use cases.
> Currently my main desktop subsurface is behind a proxy and git cloud
> connection doesn't work (I posted about it months ago but I understand
> that I'm a corner case) so currently I have mainly access only to
> Subsurface mobile and I'm afraid to delete my logbook so I'm always
> very cautious doing experiments. Occasionally I use another desktop
> connection just to save my new dives.
a) let's fix that proxy issue. I have used Subsurface behind a proxy for many
years, this is supposed to work, let's make it work for you.
b) if you ever delete a dive by mistake or make some other mistake, just
email me and I can revert those changes. Yes, it's possible to lose data
with cloud storage - but it takes effort or exceptional bad luck in hitting
corner cases of the merge algorithm.
>>> 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.
>
> I agree that a normal user gets confused on which side is updated
> while syncing to the cloud. While using GIT for cloud logbook is
> really a unique feature, we cannot pretend that the average joe
> understands it.
All I need is infinite time (or more people working on the UI) and we
can easily address that.
>> 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.
>
> Let me see if I find some doc specific to mobile apps...
Thanks
/D
_______________________________________________
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
