Kirigami 1.0 feedback

[Thomas Pfeiffer]

On Freitag, 1. April 2016 22:44:03 CEST Dirk Hohndel wrote:
> Hi Marco,

Hi Dirk,
even though you addresses Marco, let me comment on your suggestions so Marco 
knows what's "Kirigami design approved":

> I have spent quite a few hours on porting Subsurface-mobile to Kirigami
> 1.0 and playing with the new features and options. I think this is coming
> along nicely. Many of the new things I like, the new naming feels natural,
> this is really a huge step forward.

You're good at the whole "sandwiched feedback" thing, too ;)

> But of course, if I'm writing an email like this, there are still a few
> things that I think could be improved.
> 
> I have two patches that make a big difference in usability for
> Subsurface-mobile and a few bug reports and requsts for features...
> 
> 1. handling the keyboard on iOS and Android - with Qt5.6 it's possible to
> do a better job at handling the bottom margin when the virtual keyboard
> opens and closes. I was able to still get this to go wrong occasionally,
> but I can't reproduce the error case, so my guess is that this is at least
> a massive improvement if not a fix. This is the first attached patch.

I can't say anything about the code, of course, but what you describe sounds 
very useful for us!

> 2. connected to this, if the keyboard opens, now the bottom of the page is
> the upper edge of the keyboard and the action button is shown at the right
> spot, but the drawer(s) and the drawer handle(s) are not moved up as well
> and as a result the drawer handles are hidden behind the keyboard.
> I looked at the code but didn't feel comfortable that I understood things
> in enough detail to try to fix this.

The drawers themselves should still go over the whole height (since one cannot 
really use the keyboard while the drawer is open, anyway), but the handles 
should indeed be moved upwards so they are still accessible.

> 3. it seems that the titlebar is drawn on top of the page in some
> situations. I hacked around this in Subsurface-mobile by adding extra top
> margin to pages where I noticed it (DiveDetailsView.qml), but this does
> seem like a bug to me.

Seems so. The titlebar covering page content definitely does not make sense.

> 4. the OverlaySheet is nice. I like the functionality and the intuitive
> way to get rid of it. And I figured out that I can already tell when it
> gets flicked off-screen so that I can exit edit mode, so this is mostly
> good. But there are two issues:
> a) it would be really nice if it "snapped" to its natural position. So
> when you move it up and down (maybe to look at what all is there) and if
> you let go, it should jump back to a reasonable position, so if you pulled
> down but not far enough to flick if off the screen and then let go, the
> top of the sheet should snap back to the top (or just below the top) of
> the current page. And similarly if you push the sheet up and let go, have
> the bottom snap back into place.

Agreed, this would be better,

> b) in order to be able to have the animations run when opening or closing
> the sheet one needs to call the open() and close() functions (makes sense).
> But if you want to open an OverlaySheet in a state transition all you can
> do is change properties, not call functions. Maybe there's a better way to
> do this, but I attached a patch that allows property changes to trigger
> the open() and close() functions.

> 5. the margin at the top when pulling down a list (e.g., our dive list)
> seems HUGE and unintuitive. It really looks like a bug to the user. But
> then Thomas explained what this was intended to do and it suddenly made
> sense. This exists in iOS as well; but there when you trigger it (not by
> pulling down but by a soft double tap on the magic button / finger print
> sensor) then the whole app jumps about as far down as you do (so my
> comment about HUGE may be wrong), but it shows the background behind the
> app and seriously blurs it to indicate that this is more than just white
> space, this is moving part of the screen closer to your thumb. Maybe you
> could do something similar?  Change the background for the margin that you
> create there? Or move the title bar down as well with the upper end of the
> page and have something blurred out above?

[pasting in your addendum mail here]

> I think this is our consolidated feedback:
> 
> - make it an intentional action; stop at the top when scrolling, but when
> 
>   the user stops and scrolls down again, then do the overscroll
> 
> - have the title bar stay attached to the top of the list and create some
> 
>   blurry background above, to make it visually more obvious that you are
>   pulling down the top of the application
> 
> - if the user lets go of the screen and takes no action for 3 seconds,
> 
>   have it snap back up to the top again
> 
> I hope this helps and makes sense
 
Yes, this does help and makes a lot of sense!
Pulling down the titlebar together with the list would also fix the problem 
that the breadcrumb is otherwise hard to reach. I always felt bad about that 
(given that we otherwise so strongly advise against putting anything 
interactive at the top), but this would solve it very elegantly!

> 6. the title bar is really cool - and thanks for providing the properties
> to control the min/preferred/max sizes. It would be neat if the
> application could get a tap event if the user taps on the title bar, If it
> handles it, then don't interpret this as navigation on the bread crumbs.
> But if the application doesn't handle it, then do. I guess this could be
> similar to the way you handle the back button? So a signal "titleTapped"
> or something like that?

Also, the more I play around with it, the more I see that we still need to 
tweak the default values. For example, enlarging the title bar (which is 
intended to make it easer to tap the breadcrumb) feels like it happens too 
soon. Maybe we should enlarge it only when doing the overscroll?

> 7. as discussed at great length on the Subsurface list, I'd really want a
> couple more buttons :-)
> My preference would be to have five button positions. (hey, one can dream)
> 
> left    halfleft    center    halfright    right
> 
> The left and right buttons are each mutually exclusive with having a
> globalDrawer or a contextDrawer (respectively). So if the page defines
> both a right button and a contextDrawer, that's an error (and I guess the
> drawer simply gets preference). But even with both drawers available, that
> would give us three action buttons. Maybe there could be the option to
> have the center button be a little bigger - if it is the obvious, natural
> default action, but I'm not sure how that would look. Same size or
> LARGE small LARGE small LARGE might make sense...

Yes, I agree with that, All of the buttons would be optional, of course. If an 
application has only one button (besides the drawers), it should be in the 
center (like the Action Button we currently have), the secondary two buttons 
should be smaller.

> Ok, long email, lots of content, many ideas, many requests. At least I am
> bringing along two patches and I hope the issues that I report make sense
> and help to make Kirigami better!

Thank you a lot for your feedback! It is indeed very constructive. Especially 
the feedback from using Kirigami in an iOS context is very helpful for us, 
because we lack experience in that field.
And thank you for the patches, of course, we all know that's always what an 
open-source project likes best :)

You also found nice solutions for problems I had already noticed, but hadn't 
come up with solutions for yet.

> Thanks for all your hard work on this

...and the sandwich is complete ;)

Thanks,
Thomas