Subsurface-mobile port to Kirigami 1.0

[Dirk Hohndel]

On Fri, Apr 01, 2016 at 09:57:49PM +0200, Thomas Pfeiffer wrote:
> > 
> > - dynamic title bar... cute, but too extreme - this needs to be
> >   configurable from the application; right now it seems that the three
> >   factors (0, 1.6, 3) are hard coded in the Kirigami sources (or I'm
> >   misunderstanding how this works)
> 
> What do you mean by "too extreme"? What values would make more sense to you?
> We don't have any evidence yet on which are optimal values, so these values 
> can still change. 

At factor three the title bar on my Nexus 6P looks comically huge. I'll
send a screen shot later if you need illustration.

> Having it configurable by the app sounds sensible, though.

Yes, please.

> > - bread crumbs... certainly useful for many other applications, for us I'm
> >   not so sure. I think I'd prefer what we had before in that tapping on
> >   the title bar gets you to the top of the dive list. Of course you could
> >   allow the application to intercept the tap on the title bar and have it
> >   decide whether it wants to accept the event or not - that would be the
> >   best of both worlds, I guess
> 
> The bread crumb is what comes closest in interaction to the iOS back button 
> which iOs users seem to like so much, so it may be useful for Subsurface, 
> after all. What makes you feel it isn't?

Because we don't have the typical "deep" structure. We never have more
than two layers (at least not that I could reproduce). It just doesn't
feel like this provides a ton of information (or value). I may need to
play with it some more, but I've now used it both on my iPhone and my
Nexus and on both it feels... artificial. I think this would be different
if we had a deeper structure where you could be several layers deep inside
the program.

> > - scrolling and flicking of pages... oh my.
> >   -- I sometimes get a huge empty space at the top of the dive list, not
> >      sure how to describe this, it's like a massive margin or something -
> >      I think this happens if I pull the list down; something similar
> >      happens with some other pages like the About page or developer log;
> >      pull down, you suddenly have the top third of the page as empty
> >      margin
> 
> This is actually intentional, for lists at least. The rationale is that the 
> first list entries are hard to reach at the top of the screen. Being able to 
> scroll further up (we call it "overscroll") allows you to bring them to an 
> area of the screen where they are easily reachable. The same goes for the 
> bottom entries.

By 50% (half the screen)? Err. OK.

> This makes it very valuable for one-handed usage, but we do get the feedback 
> that it still somehow feels "weird" to users, so it looks like the current 
> presentation doesn't convey what this white space is good for, but feels like 
> a bug instead.

If definitely looks like a bug to me.

> What we might to instead is stopping the original scrolling when the first list 
> item is reached, but allowing to overscroll if the list is pulled down again 
> (after lifting the finger) from there (assuming this is done because the user 
> cannot reach the first item(s) ). Also we should use a different visual 
> representation that just "white space", to indicate that "Yes, this is 
> actually intentional"

I like both of these ideas.

> The margin can actually be set by the application, though (or at least that's 
> what Marco told me), so until we get the interaction right, you might simple 
> set it to zero.
> 
> For the about page or developer log, overscroll doesn't make any sense, of 
> course, and I'm not sure why it happens there. May be a bug, let's see hwat 
> Marco says.

Yes, if the margin was configurable and I could just set it to zero for
the pages that are like the About page and to a much smaller value than it
is now for the lists type pages... and if the list only went there on
repeat "pulling down" gestures... that would be better.

> >   -- I still get the confused list at the bottom of the dive list with
> >      white areas and scrolling going all crazy on you
> 
> Okay, this seems to be an actual bug.

Oh most definitely that's a bug :-)

> >   -- The weirdest one is that I can flick away some pages. So for example
> >      I go to add dive or edit a dive. Then the add/edit dive page is like
> >      an overlay on top of the other pages. And I can literally flick it
> >      away. Subsurface-mobile still things it is in editing stage and
> >      things get royally confused. This bug I think is the biggest reason
> >      why I'm not pushing this to our unsuspecting testers.
> 
> This, too, is intentional. It gives you an easy way to cancel an operation 
> without having to look for a button. Flicking back in the other direction 
> should get you back to the dialog.

I'm not sure what "flicking back in the other direction" means.
If this is a way to cancel an operation, then do I get a signal in the app
that this has happened?

> However, this has to be communicated to the application, of course. If 
> Subsurface-mobile still thinks it's in editing mode, then of course we have a 
> broken situation. This has to be fixed on a technical level.

That's what we have right now.

> As for the interaction: Does it feel like flicking away by accident happens to 
> easily? If so, we have to increase the threshold before it's executed so it 
> happens only if done intentionally.

It happened to me twice by accident - maybe because I wondered why I was
able to "move" the page at all - not sure. I'll need to play with this
more before I claim one way or another.

> > This needs a lot more testing but it's late (yeah, only 11, but I have to
> > go diving tomorrow... oh how I suffer). So please take a look at the APK
> > or build from sources...
> > 
> > Not sure what the best path forward is. Any chance that you have some time
> > to address these concerns, either in Kirigami or (where necessary) in
> > Subsurface?
> 
> Again, this is for Marco to answer. He certainly can give you pointers to 
> things which can be fixed by setting different properties. As for the actual 
> bugs, those are of course not my area.

I have no problems creating patches to Kirigami as well to implement some
of the things that I'd lake changed. Frighteningly QML does appear to
become easier the more you desperately try to fix things. And given that
hardly anyone appears to use QML (based on the lack of any useful answers
that Google is able to produce whenever I'm stuck), that might mean that I
am quickly moving to the "I'm an expert" category. Which in itself is
frightening.

/D