Subsurface-mobile port to Kirigami 1.0

[Thomas Pfeiffer]

On Donnerstag, 31. März 2016 23:05:04 CEST you wrote:
> Marco, Thomas,
> 
> I merged the port to Kirigamit 1.0 on top of latest master, but I'm
> hesitant to push out test binaries for iOS or Android as this brings a lot
> of regressions right now. I'm not quite sure how to handle this given that
> I'm on an island with rotten internet connection and you guys are rather
> busy with other things...

Great that you did that!

> For now I have pushed things into the mergeKirigamiPort branch of
> git://subsurface-divelog.org/subsurface
> 
> I also made an Android apk available at
> 
> http://subsurface-divelog.org/downloads/daily/Subsurface-mobile-4.5.2.1148-a
> rm.apk
> 
> but I have NOT pushed this to Google Play (nor do I have an iOS version
> for people to play with right now).
> 
> Here's my quick feedback with some of my concerns:
> 
> - 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. 
Having it configurable by the app sounds sensible, though.

> - 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?

> - 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.
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.

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"

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.

>   -- 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.

>   -- 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.
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.

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.

> 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.
 
> Thanks
> 
> /D
> 
> PS: as usual... while this may sound very critical, please don't take it
> this way. I enjoy the cooperation between the teams and my focus is to
> make both Kirigami and Subsurface better in the process.

Yes, and it is very valuable for us, too!