[mobile ui] navigation rework

[Dirk Hohndel]

HI Marco,

I added you to the "approved sender" list for the mailing list so your
mails won't be held in the future. The mailing list is set up to only
accept email from list members - but I don't know if you are into dive log
software enough to want to join the mailing list (most of the time it's
not very high volume, though). Your call.

On Mon, Nov 30, 2015 at 03:52:51PM +0100, Marco Martin wrote:
> On Mon, Nov 30, 2015 at 5:57 AM, Dirk Hohndel <dirk at hohndel.org> wrote:
> > Sebastian and Marco (welcome to the team, btw):
> >
> > Awesome. The jump forward of the mobile UI is stunning. It's fun to read
> > through the commits and see the two of you work together.
> >
> > Thanks for the time and effort spent on Subsurface-mobile this weekend!
> 
> Hi Dirk, thank you!
> Just answering a couple of points.
> What we are trying is to do some components, together an user
> interface guideline that can be easily used by mobile QML
> applications, that are easily usable both on our platform and on
> Android, where it would look fairly consisten with the native material
> applications, but yet with its own personality. Subsurface was a great
> candidate as it was at the beginning of a QML based mobile version,
> and it has been pretty fun to work on :)

Can I nudge you to expand the vision here to include iOS as well? After
all, that's one of the big selling points of QML that you can write one
mobile app that can be compiled for both platforms. We aren't quite there
yet (Tomaz is still working on the infrastructure to do this), but I'm
optimistic we'll have that ready fairly soon.

> Since our components and user interface guidelines are still in the
> beginning, now
> we also have some designers/usability people working on the design
> side (will make them play with the application to see what suggestions
> they may come up with), so is important to see the eventual problems

AWESOME!!! That's what we need SO MUCH help with.

> that those components and paradigms of interaction can have on a real
> application, as now is the phase when there is still plenty of time to
> adapt and change things since we aren't fully committed to the API
> yet.

This is one of the things I noticed when I started playing with QML.
The use cases and applications and demos were already rather primitive.
I think having a full fledged end user application as your guinea pig will
be a huge help to get the components right and at the same time to have
something to point other developers to and say "here's an example of how
this can be used".

> > <Unknown File>: QML StateGroup: Can't apply a state change as part of a state definition.
> > qrc:////imports/org/kde/plasma/mobilecomponents/private/ActionButton.qml:52: TypeError: Cannot call method 'close' of null
> > <Unknown File>: QML StateGroup: Can't apply a state change as part of a state definition.
> > qrc:////imports/org/kde/plasma/mobilecomponents/private/ActionButton.qml:52: TypeError: Cannot call method 'close' of null
> >
> > Not sure what triggered those.
> 
> there are some coming from the components, some coming from the app,
> cleaning those that are component related now.

Thanks.

> > - dive list: the visual separation between the different dives is a bit
> >   subtle, I think. Yes, there is the very faint line but to me after a bit
> >   of scrolling it took my eyes a moment to settle and parse. Maybe we can
> >   have alternating background colors (light blue and the current light
> >   gray for example)?
> 
> or perhaps just a more visible separator. Not a big fan of the
> zebra-like alternating colors, but it could be tried

Given that I have won several coveted design awards for my work in user
interaction design and icon design, including the BLERCH, the YIKES, the
WTF? and most importantly the WDOTY (worst design of the year)... I'll
happily follow your ideas and stop making silly suggestions :-)

> > - opening the drawer: at least on the Nexus 6p with Android 6.0 it took
> >   quite a bit of trial and error until I was able to open the drawer just
> >   by swiping from the side. Could be a user issue. The button makes it
> 
> i seen that the edge seems to work better on some devices than the
> others, it may be an issue of the touchscreen sensitive area not
> stretching all the way trough the border, so maybe a bigger sensitive
> area is needed (in general at least with new devices this gesture
> should be usable, as material design has a similar drawer that can be
> pulled from the side as well)

So the Nexus 6p is Google's latest phone, the launch vehicle for
Marshmellow. I'll play with this some more, maybe I was just fat-fingering
it. I usually don't have problems with the drawer in other Android apps.

> > - dive view navigation: I can see the logic behind a swipe from the left
> >   bringing us back to the dive list, but the back button does that as
> >   well. I still would much rather see swipes to the left and right bring
> >   up the next and previous dive, respectively
> 
> this is one of the areas I want to get our interaction designers think
> about: on one hand getting back with that gesture is really convenient
> and is far easier for the "single hand" use case on a phone, but on
> the other hand is very restricting on what the application can do in
> its own screens, so yeah, interesting problems :)

Indeed an interesting problem. I don't really know how common this is in
mobile apps. To me it seems reasonably logical and consistent to have "up"
and "down" scroll the current item and "left" and "right" be next item and
previous item. And then use back key and item selection to navigate in the
stack. But see my comments above about my design skills, so I won't claim
any authority. It just seemed to me that if your data are an ordered list,
then being able to go to next and previous with gestures without having to
go back up a level in the stack had more merit than being able to go back
up in the stack using a gesture instead of the back key.

/D