Kirigami 1.0 feedback

[Dirk Hohndel]

On Sat, Apr 02, 2016 at 04:38:43PM +0200, Thomas Pfeiffer wrote:
> even though you addresses Marco, let me comment on your suggestions so Marco 
> knows what's "Kirigami design approved":

Bad habit of mine to address one person instead of all of you...

> > 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 ;)

Affirmation sandwich? Absolutely. And the thing is... I really like the
progress. This is good. And it sucks when you get an email and it contains
nothing but "whine", "complain", "bicker"...

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

I still every once in a while - maybe one out of ten times I use this -
get the completely incorrectly placed bottomMargin. No idea why. Feels
like a Qt bug to me, frankly.

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

:-)
But then this of course leads to the next thing... this should work not
just on ListViews but on any page, right? So that you can get to the title
bar...

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

So with the values I picked for Subsurface-mobile, on a device, it seems
quite nice and natural to me. But that may be a matter of taste.

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

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.

Excellent. So we now have the user interaction design guru seal of
approval for the up to five buttons. AWESOME. I love it.

> > 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 :)

I'll admit that I tried to send patches for more of the desired features -
but I'm still in the "learning" stage of QML. I have all day today for
hacking, so maybe I'll get some more done. Right now I'm playing with UI
ideas in Subsurface-mobile for a long press since I realized that Kirigami
supports that (reading the sources when trying to create more of the
aforementioned patches...)

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

I'm very happy to hear that. The shared goals work out well here.

> > Thanks for all your hard work on this
> 
> ...and the sandwich is complete ;)

Of course! Emails that end on "... and now I need you to do X, Y, and Z
for me" rarely have the desired effect... especially if they come with 6
items and lots of potentially controversial topics. I am on the receiving
end of this all the time. And I think that most of the people sending
these emails don't mean them the way they come across. So when asking for
help or features or stuff, I try very hard to write emails that I myself
would actually enjoy receiving.

Have a good weekend everyone - I realize not everyone is crazy enough to
be on an island in Mexico with nothing else to do today and instead of
sitting at the beach decides to spend their time working on the
computer...

/D