Subsurface-mobile for Android -845

[Rick Walsh]

On 14 February 2016 at 15:24, Dirk Hohndel <dirk at hohndel.org> wrote:

> On Sun, Feb 14, 2016 at 03:12:11PM +1100, Rick Walsh wrote:
> > I just tested 849.  I think the use of the action button is very good.
> It
> > doesn't waste space, it's transparent enough not to be invasive, it's
> easy
> > to reach, and most importantly, the icons give good clues what the button
> > does (unlike the original action button, which was powerful, efficient
> use
> > of space, but confusing to many the first time they saw it).  I also like
> > that I can still/again swipe the central action button instead of using
> the
> > arrows - as I said before, when holding my phone in my not-dainty left
> > hand, reaching the very left bottom of the screen with my thumb can be
> > awkward.
>
> Thanks for the feedback. Very helpful.
>
> > > > > Just a couple of things: The title bar is too cramped now.  Other
> apps
> > > use
> > > > > that to display info on the current context.  We could display
> "Dive
> > > list"
> > > > > or "Dive #643" or "Edit dive #242" or "About" there in the future.
> > > >
> > > > That's a good idea... but I think I like the idea of it simply fading
> > > away
> > > > even better.
> > >
> > > +1 for fading away.
> > >
> >
> > I agree with both points.  Screen real estate is scarce, so if/when the
> > title bar is shown, I think it should be more informative than
> > Subsurface-mobile (I know what app I'm using).
> >
> > Going through the various apps on my phone, many have "title" bars
> showing
> > what page is active on the app (e.g. "Inbox" in gmail), or toolbars, some
> > including the app logo (e.g. Twitter), but very few have a title bar with
> > the app name displayed.  A few have a search bar that mentions the app
> name
> > (e.g. "Search Google Maps").
>
> I think I'm sold on dropping the name from the title bar. But I'm not 100%
> sure what I want instead. No title bar at all? A title bar that fades?
> What is it showing until it disappears? Contextual info (which dive is
> shown or something like that)?
>
> > In my opinion, the ideal title bar would have the Subsurface-mobile logo
> at
> > left (like now, but moved down a tiny bit - right now its vertical
> > alignment is hard against the top of the screen), with the page name next
> > to it (e.g. Dive #643 as suggested by Henrik).  And ideally it would fade
> > away when you scroll down the page, and probably reappear when you scroll
> > back up to the top.
>
> Yeah, so that's kinda what I was contemplating.
>
> > > Google's apps for Android (those which do not auto-save) do use such a
> > > dialog.
> > > They all use a Discard/Cancel approach (though with completely
> different
> > > wording and even inconsistent button position between the apps, which
> is
> > > really bad design).
> > > We haven't written about it in the HIG yet (we'll still add one
> guideline
> > > for
> > > that), but here's what I'd suggest:
> > > "Discard your changes?" [Discard] [Keep Editing]". This makes saving
> take
> > > one
> > > more step, but we want to train users to just hit "Save" anyway, and it
> > > makes
> > > the decision in the dialog easier.
> > > There is already a component for a slide-in dialog available (don't
> know
> > > its
> > > name, though, tbh. If you can't find it, ask Marco).
> >
> > I find confirmation dialogs clumsy and don't like them if they can be
> > avoided, especially on a mobile app.  If we were talking about
> > writing/editing a thesis, I'd be more inclined towards a confirmation
> > dialog, but if the the user accidentally close the dive edit page without
> > saving, and lost their logging notes, they should be able to cope.
> >
> > I'd rather have the action button action be 'save changes and close', and
> > the Android back button would be 'discard changes and close'.  If that's
> > too out the for new users, there could also be a discard button next to
> the
> > current save (and close) ordinary button at the bottom of the page.
>
> So I tried to implement something that I find reasonable and intuitive.
>
> - there's still the save button
> - the action button is cancel and there is NO CONFIRMATION - you hit that
>   button, you get what you asked for
> - the back button asks the user if they really wanted to discard the
>   changes, and if they don't confirm within 3 seconds it simply hides the
>   confirmation dialog and pretends nothing happens
>
> Please play with it, the description sounds a lot more awkward that it
> felt to me to use...
>

The logic is good, and the description makes sense.  The reasons I'd rather
the action button be 'save' are:
(1) I'm lazy and if all I want to do is enter/alter a couple of details
(e.g. dive site and buddy), then I don't want to have to scroll down to the
bottom of the page to find the save button
(2) we effectively have two quick-access buttons: the action button and the
back button.  Having both do the same thing (with or without confirmation)
is a bit of a waste.  We have two actions that should be accessed rapidly:
save and discard.  The back button can be used to discard changes, so it
makes sense to me that the action button would be save.
(3) let's trust the user knows what she's doing - more often than not, when
the user wants to leave the page, she wants to save changes.  We should
make that as easy as possible.

>
> > Similarly, I think we should use the action button on the cloud
> > credentials.  The action button action would be "save", and the back
> button
> > would be "discard" (and return to dive list).  This could replace the
> > existing ordinary buttons.
>
> That I think is a good idea. I'll need to find the time to implement this.
>
> > Another thing - In the dive list, there's a blank row above the trip
> > separator line.  I'm not sure if that's deliberate, but it looks like a
> > waste of space to me.
>
> Do you have a screen shot?
>
> See attached


> Thanks for all the feedback!
>

No worries,

Rick
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.subsurface-divelog.org/pipermail/subsurface/attachments/20160214/cf23d43d/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screenshot_2016-02-14-15-33-05.png
Type: image/png
Size: 203087 bytes
Desc: not available
URL: <http://lists.subsurface-divelog.org/pipermail/subsurface/attachments/20160214/cf23d43d/attachment-0001.png>