Kirigami design question (iOS users, please read)

[Dirk Hohndel]

On Thu, Mar 31, 2016 at 11:37:25PM +0200, Thomas Pfeiffer wrote:
> On Donnerstag, 31. März 2016 07:09:40 CEST you wrote:
> > 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?

The feedback was "menus are unusual" and "having the 'back' function in a
menu feels like being different just to be different". And in general most
iOS users asked for more buttons on the screen, several sending screen
shots with example apps (just like Robert did), showing how the top row
and bottom row are typicall used for actions.

So it's not that people "couldn't" use them, the perception I got was that
they felt that Subsurface-mobile was less usable because we went out of
our way not to have actions on the screen and instead made them 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.

You know what they say about a sample size of one... :-)

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

Can we summarize this as mine is bigger than yours?

Oh wow, where did that come from. I will claim that I am still narked. I
did two 22ft dives this afternoon...

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

Thank you - I think we can agree on that. And then we can add the pinch
zoom thing for Robert :-)

> I will ask Marco to implement the option for additional buttons next to the 
> action button.

AWESOME. Thank you.

I will try to do the port to the latest Kirigami tonight. Let's see how
far I get.

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

See above. The feedback is about usability. And while you are the expert
on usability, I think we can agree that if a statistically significant
number of your users tell you that you have usability issues, it's worth
listening to them.

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

Yes. I am all for change. I am all for good intentions and better
directions - but I want to balance this against not pissing off the user
base :-)

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

I will keep asking :-)

/D