Overthinking on Subsurface mobile app UX

Anton Lundin glance at acc.umu.se
Thu Jun 22 07:08:50 PDT 2017


On 22 June, 2017 - Joakim Bygdell wrote:

> On 22 June 2017 at 13:26, Dirk Hohndel <dirk at hohndel.org> wrote:
> 
> >
> > > On Jun 22, 2017, at 2:42 AM, Dirk Hohndel <dirk at hohndel.org> wrote:
> > >> 1) Any possibility to allow for multi-line dive trip titles? This would
> > improve functionality of the app.
> > >
> > > Yes, that's a possibility. I'll see if I can implement that.
> >
> > Thanks to jet lag induced insomnia (dive vacations... the gift that keeps
> > on giving) this has been implemented.
> >
> > As has a fix to no longer show "(dive(s))" in en_UK and(!!!!) en_US.
> >
> > It would be great if the translators could add the singular / plural
> > translations
> > for this string on Transifex. Search for that source text, and note that
> > you
> > need to switch between "1" and "other" on the translation side (and for
> > some
> > language even three or four different options, e.g. in Polish 1, few,
> > many, other)
> >
> > >> 2) The refresh/sync option. I think what you mean is that autosync
> > happens when one pulls down the dive list beyond the topmost dive trip?
> > >
> > > Actually, I call the equivalent of the menu item "Manual sync with cloud"
> > >
> > >> But what if one accidentally pulls down the list without intending a
> > sync? I did just that and autosync happened, even though I have autosync
> > turned off. It is like some of the Microsoft applications that are trying
> > to be too clever, doing something that the user did not intend. In general
> > I have a strongly negative sentiment with respect to autosync. The reason
> > is that I have on several occasions accidentally deleted a dive on the
> > mobile application. It was then necessary to edit the lost dive on the
> > desktop (so that git sees the dive again) and then to re-save the dive log
> > from the desktop to the cloud in order to reinstate the deleted dive on the
> > mobile app. Highly irritating. While I think that some users prefer auto
> > sync, it is important to be able to have full control over the process of
> > cloud backup from the mobile app. A solution could be:
> > >> a) If autosync is turned off, NO autosync should take place anywhere.
> > >> b) It would be incredibly helpful if there are options similar to the
> > desktop version: Upload to cloud and download from cloud. These are
> > unambiguous and give full control to the user so that unintended changes to
> > dives are not saved to the cloud, messing up the backup of the dive log on
> > cloud. This would improve the functionality of the app.
> > >
> > > That is an interesting point. One way around this would be to finally
> > > implement a UI to walk back the git history explicitly. Because nothing
> > > is truly ever LOST.
> > >
> > > In the meantime, an option in the menu to
> > > a) turn of the pull down refresh for people who dislike it and
> > > b) add an option "abandon local changes, re-open from server"
> >
> > This I haven't done, yet. Instead I'll try to get another hour or two of
> > sleep.
> >
> > Everything is pushed to master, a new APK is app as well
> >
> > http://subsurface-divelog.org/downloads/test/Subsurface-
> > mobile-4.6.4.257-arm.apk
> >
> > This one (thanks to Jan) also tries to show only supported dive computers
> > in the Download from DC section. Anton, can you help by adding the FTDI
> > devices for Android (even though that still doesn't work on Pixel and other
> > strictly enforcing 7.x devices)?
> 
> This restriction also removed all DCs that we can download from via USB.
> 

That's all the serial devices. All of them can be used with a ftdi
cable.

One thing we rather should do is try to be a bit more intelegent about
which usb vid/pid's and name we see.

If we see a usb product "HeinrichsWeikamp OSTC3" or "HeinrichsWeikamp
OSTC 2N" we should propose the right things, but if we just see a
generic ftdi device, we should show all of them, and let the user tell
us what they have plugged in.


//Anton


-- 
Anton Lundin	+46702-161604


More information about the subsurface mailing list