Kirigami design question (iOS users, please read)

Thomas Pfeiffer thomas.pfeiffer at kde.org
Fri Apr 1 14:00:28 PDT 2016


On Donnerstag, 31. März 2016 18:05:56 CEST Dirk Hohndel wrote:
> 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.

The idea has never been to have a drawer as the main way to go back. It just 
happens that "going back" in Subsurface-mobile usually means going back to the 
dive list, and the dive list (correctly) also being in the global drawer.

The drawers are not supposed to be used for very frequent functions, because 
of course they take longer to execute than buttons which are directly on the 
screen. The global drawer is similar to a main menu in a desktop application, 
whereas the context drawer is akin to a right-click menu. A good desktop 
application doesn't put the most common functions in either of those as the 
only way to access them, either.

The HIG for the Global Drawer [1] states "It contains an application's main 
menu, and any functions which are not part of the application's main usecases 
but are not specific to the current context either.".

The HIG for the Context Drawer [2] states "Use a Context Drawer if your 
application has any functions which are only relevant in specific contexts, and 
which are not central enough to the application's main purpose to put them in 
the main user interface or in a toolbar.",

Our idea for applications for which going back and forth between a list and 
specific elements of the list is the most common navigation pattern is to use 
column-based navigation (i.e. swiping to go back to the list). I was told that 
Subsurface-mobile doesn't use this because for your users, flicking through 
dives is more common than going back to the list.

The feedback from your iOS users sounds like going back to the list might be 
more common for them than anticipated, though. In cases where both flicking 
through items _and_ going back to the list are equally common, of course both 
need to be easily accessible (i.e, not just from a drawer).

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

The Kirigami and Apple Human Interface Guidelines have different underlying 
assumptions. The Apple HIG are about making all functions as easily available 
as possible, whereas two of the basic assumptions behind Kirigami [3] are 
"Phones are more for communication and content consumption than for content 
creation" and "Space is limited, and content is king."

These assumptions are obviously not 100% compatible with those behind the iOS 
HIG. Furthermore, given that Android is a more important ecosystem for KDE 
(since it's more "open source friendly", and far more Plasma users have 
Android then iOS devices), our design is closer to Android's than iOS' (which 
also lead to your Android testers being - after some initial getting used to 
the new things - much more positive about Kirigami in Subsurface-mobile than 
the iOS testers).

Being close to the iOS HIG was never the goal behind Kirigami, so we won't 
change things just in order to be closer to them. 
We do change things if they just don't work well in general, though, which is 
why I keep trying to find out whether your iOS testers dislike things because 
they're not used to them, or because they simply don't work well.

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

I know. If I had 50 iOS users happily using Kirigami Components, I'd probably 
simply ignore the feedback from your 15 users :P

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

I'm sorry but I _have_ to post this as a fake quote on Google+. Don't worry, I 
won't make it embarrassing for you.

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

Having redundant ways to access a function is always good, as long as they are 
not in conflict with anything else or clutter up the screen (neither of which 
is the case here).

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

I gave my request more weight by reminding Marco that he himself had the idea 
of a bottom toolbar with up to three buttons at some point ;)

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

Users complaining about something can, but not necessarily always does mean 
there is an underlying usability issue. Complaining about something can often 
be an initial gut reaction.
That's why observing users is much more valuable than just listening to them. 
I just wish I had more iOS users to watch while using Subsurface-mobile. The 
problem is just that I hardly know any. Everyone in my social circles just 
used Android. Therefore, feedback form iOS users is better than no data about 
iOS.

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

Yes, I understand that, which is why I'm willing to work with you to make iOS 
users at least okay with Subsurface-mobile, even if they might never be as 
happy with it as Android users.

> > I'd still love to hear additional feedback, also about _why_ swipe to go
> > back feels unintuitive.
> 
> I will keep asking :-)

Thank you!

[1] https://techbase.kde.org/Projects/Usability/HIG/GlobalDrawer
[2] https://techbase.kde.org/Projects/Usability/HIG/ContextDrawer
[3] https://sessellift.wordpress.com/2015/10/15/behind-the-scenes-of-the-kde-phone-hig-part-one-basic-assumptions/


More information about the subsurface mailing list