Kirigami design question (iOS users, please read)

[Dirk Hohndel]

If you are primarily an iPhone / iPad user and don't use Android devices a
lot, please read and respond to the question on the bottom

On Thu, Mar 31, 2016 at 12:05:51PM +0200, Thomas Pfeiffer wrote:
> On Mittwoch, 30. März 2016 21:06:21 CEST Dirk Hohndel wrote:
> > Thomas,
> 
> > Based on some of the feedback we have been getting from testers on iOS
> > (I'm sure you have seen some of it here) I have been wondering if we
> > should consider a change to the Kirigami design...
> > 
> > Right now the bottom layout shows a right angle/arrow in the lower left
> > corner (main drawer), an action button in the center (optional) and a
> > left angle/arrow in the right corner (context drawer).
> 
> 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.

> > Would it be possible to have instead the angle for the global drawer plus
> > up to four action buttons? The center one could be bigger and be the
> > default action, to the right (where we have the context drawer handle) one
> > could have a virtual back button, then half left could be an auxiliary
> > "positive" action (so "add dive", "do something"), and half right could be
> > an auxiliary "negative" action ("delete", "cancel").
> 
> We are still considering allowing two more buttons at the bottom (smaller 
> buttons to the left and right of the main action button), but I would not 
> suggest using them for the purpose you suggest.
> 
> 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.

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

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

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.

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

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

/D