Kirigami design question (iOS users, please read)

[Thomas Pfeiffer]

On Donnerstag, 31. März 2016 07:09:40 CEST you wrote:
> > In the current Kirigami version, the symbols for the global and context
> > drawer were changed to match those on Android, but that's just a detail.
> 
> Just a thought... please remember that one of the MAJOR draws of Kirigami
> is the fact that it can work on multiple mobile platforms. We already use
> it on Android and iOS, once someone ports Qt to Tizen or Windows Phone we
> can easily tap into the vast user bases of those two eco systems as well.
> (*oops*)
> 
> So while it makes sense on Android to use the Android symbols, on iOS
> that's more of a problem - in general it appears that the concepts of such
> menus is much more foreign to iOS users.

The burger symbol for "Menu" is pretty common across operating systems these 
days. The context menu is less common outside of Android, but it's not more 
ambiguous than an arrow.

Drawers may not be that common on iOS, but that doesn't mean that users don't 
understand how to use them. Did you get the feedback from iOS users that they 
couldn't use the drawers?
I admit I had only one iOS-only user in my first user tests, but she was 
actually the one who had the least problems with anything in Kirigami.

> > I'm still not ready to give up on "swipe to go back" yet, because it
> > should be easier to execute - especially when using with one hand - than
> > pressing a button at the bottom of the screen.
> 
> The problem is that every single iOS app has a back button. Every one. And
> that is the number one feedback that I'm getting from the testers. Of the
> 15 testers that are not both iOS and Android users, 12 have pointed out
> that they couldn't figure out how to get back and 7 have pointed out that
> they had problems figuring out how to start edit / cancel edit.

> That's a massive ratio.

Ok, your sample size is bigger than mine, you win ;)
Having swipe to go back as an alternative still makes sense for those users 
who don't want to move their thumb all the way to the bottom, but a back 
button as an obvious alternative does make sense.

I will ask Marco to implement the option for additional buttons next to the 
action button.
 
> > I know that it can conflict with "swipe to switch between dives" in
> > Subsurface's case. On the other hand, the only situation where it would
> > conflict is when going back to the dive list, and with the breadcrumb
> > header (available in the Kirigami version you are about to port to) and
> > the global drawer, users still have two ways to go back to the dive list.
> > Furthermore, the fact that you're using swipes to switch between dives
> > means you assume that just flicking through them is a much more common
> > action compared to going back and forth between dive list and individual
> > dives.
> 
> Correct.
> 
> BTW: I couldn't figure out last night where to find that next version of
> Kirigami which stopped me from porting to it (so I fixed other stuff
> instead). Can you point me to the git tree / branch to use?

I assume you've read my other email by now, but just in case:
git://anongit.kde.org/kirigami.git

> > Can you point out where else swipe to go back wouldn't work, or where
> > users
> > have reported problems with it (I may have missed that particular
> > feedback)?
> See above. The feedback comes a lot just to me, as I am listed as the
> contact for people to get added to the test... so they email just me.
> Whenever there's something new in the feedback I try to remember to
> forward it to the list, but if it's just the same three things I usually
> don't bother.
> 
> > As for the "positive action": That is what the Action Button usually does.
> > Can you point me to cases where the "positive action" would not be the
> > main action?
> 
> Not off the top of my head. I don't think I have a use case where I need
> all four buttons I suggested. I do have a use case for three:
> 
> Edit dive (positive) Delete dive (negative) Back to dive list (navigation)

> > The way I suggest thinking about action placement (I'll also put that into
> > official Human Interface Guidelines once it's proven to work) is:
> > 
> > - Main action / Confirm: Action Button
> > - Go back / Cancel: Swipe left
> > - Secondary actions which are almost as commonly executed as the main
> > action: Additional buttons at the bottom
> > - Every other contextual secondary action: Context drawer
> > - Every global action: Global drawer
> 
> I think this works. Caveat is that the drawers are a lot more alien to iOS
> users than to Android users. I wonder how many of the users that you did
> the tests with were 100% iOS users vs. Android users or people who use
> both.

I had just one iOS-only user.
Did your iOS-only testers report not knowing how to open the context drawer?

> If I can get a button instead of ONLY the swipe left to go back, I think
> I'm OK. And since you allow up to two more buttons, I guess I can do this
> in your design :-)
> 
> > > I think this would be more intuitive to iOS users (based on their
> > > feedback). I also think this is easier to use than having to open the
> > > context drawer. And at least in the case of Subsurface so far, this
> > > covers
> > > everything we ever need to do.
> > 
> > The context drawer should only be used for less common actions. I got the
> > impression that deleting a dive wasn't really a common action, so opening
> > the context drawer for it should not be much of a problem. I'd generally
> > not suggest to put it right next to the edit button, because even though
> > we have the undo action, it can still get annoying if users regularly
> > delete dives just because they missed the edit button.
> 
> Valid point.

You can of course play with deleting right from the "menu bar". Since we 
hadn't allowed more than one button in Kirigami before, I have no evidence yet 
on whether this would be an actual problem.

> > > Of course one could keep this extensible and allow to have the right
> > > most
> > > button instead be one that opens a context drawer after all.
> > > 
> > > What do you think? Too crazy? Too cluttered? Or maybe worth a try?
> > 
> > My main feedback is: Seriously give "swipe to go back" another try. It may
> > feel a bit strange at first, but it's a pattern which is adopted more and
> > more in Android applications and it works pretty smoothly actually.
> 
> It's not about me, Thomas. It's about the people who are hardcore iOS
> users. I talked to my wife. She just rolled her eyes. I talked to my
> daughters (who, yes, I know, this is parental abuse, are iOS and Tizen
> users). Neither of them thought this was intuitive or worked particularly
> well. They all looked for a button to get back. And the feedback from
> other iOS people seems to confirm that.

Sorry if I came across as thinking this was just your personal opinion. I know 
this is based on actual user feedback.
I also know that people are reluctant to change, even if a change may turn out 
to be beneficial after some getting used to, but I do see that this change-
aversion may turn into negative feelings towards your application, so I 
understand that it makes sense for an iOS app to have a back button so people 
don't have to learn new things if they don't like to.

> > I'm not completely against putting additional buttons at the bottom, but
> > given that they are less comfortable to reach than gestures, I'd only use
> > them if nothing else works.
> > 
> > Let's work together on this and see if we can find a better solution. If
> > we
> > can't putting a virtual back button at the bottom is still a last resort
> > option.
> :
> :-)
> 
> So on this list here I am pretty sure we have several people who don't own
> Android devices but are iDevice people all the way. Can I get a few of you
> to speak up and comment whether you think the typical iOS user would
> prefer a "swipe back" or a "back button" or "go back by opening a menu and
> tapping on an entry" (we need that when viewing a dive and wanting to go
> back to the dive list).

I'd still love to hear additional feedback, also about _why_ swipe to go back 
feels unintuitive.

Best,
Thomas