On Dienstag, 5. Januar 2016 08:16:38 CET Dirk Hohndel wrote: > Hi there,
Hi Dirk, as the person in charge of the KDE Mobile HIG (and therefore also responsible for the usability of the Plasma Components), I'm very happy to get feedback from users of an actual working application using our components! Since I am not a developer, I can only discuss our design choices, our developers are better suited to discuss the technical problems you encountered. So here goes my comment on the user feedback. Please bear with me, as I'll have to expand a bit on the reasoning behind the interaction with the action button: > c) the user feedback (about 25 alpha testers on about 30 Android devices, > we haven't gotten the iOS build to work, yet, as some of our dependency > libraries are causing us trouble) is very negative on the action button. > People find it very unintuitive and a solution looking for a problem. > In my latest builds I have hacked our copy of the MobileComponents to > simply disable the action button and instead added traditional three > bar / three dot menus to the top bar - this was very well received with > the testers. The context menu button (three vertical dots in the top > right corner) only shows up when there is a contextDrawer. Tapping on > either of the buttons opens the coresponding drawer. > The Subsurface team would love to see an option to cleanly disable the > action button in the MobileComponents. First of all: It's fully understandable that Android testers like UIs the way that stock Android UIs are. That's what they're used to, that's what their muscle memory has learned. Let me explain to you, then, why we diverged from the default Android behavior. As a start, here are the relevant section from my blog post laying out the basic assumptions behind our design choices [1]: --- Users prefer to interact with the center of the screen As research [2] shows, smartphones are predominantly held upright (portrait mode) and in one hand, simply because that is the most convenient way to use it and it leaves one hand free e.g. to hold onto something while standing in a bus. If we want an application to be used conveniently with one hand, we have to make sure that everything that is needed often can be reached with that hand’s thumb without having to reposition the hand (although the aforementioned research also shows that people do switch how they hold their phone whenever needed). Regardless of the way users hold their phone, research [3] shows they generally are more precise in interacting with – and prefer to interact with – the center of the screen. Based on these findings, the HIG recommends interaction patterns which do not require users to reach for the far ends of the screen (mostly the top), but give them on-demand controls near the center of the screen. --- Given that, the context menu button in the top-right corner is almost in the worst possible place to reach (for left-handed people, it is literally in the worst possible place). Try reaching that button with your thumb when holding a 5"+ phone with one hand, without changing the position of the device in your hand. Really, it's no fun. What makes it even worse is that this button is the _only_ way to open the context menu on Android. Therefore, the first and very obvious idea was to allow users to open the context drawer by swiping in from the right edge of the screen (since they do not have to reach to a corner for that). However, we also know that not all users are comfortable with edge-swiping, which is why we looked for an alternative means to open the drawers (the primary way is still edge-swiping) for those people which are not. That's where the Action Button comes into play. With Material Design, the "Floating Action Button" (FAB) has become an integral part of most stock Android applications (Mail, Hangouts, G+, Calendar, Maps, Photos, the thing is pretty much everywhere). There, it's used to execute a "main action" within an application (often creating a new object, but in Maps it's navigation and in Photos it's searching). And, interestingly enough, the Material Design guidelines place that FAB in a position where it's easy to reach. So we thought "Hey, why not re-use the FAB as an alternative to edge-swipes for opening the drawers?". And this is how this idea was born: We have a button in an easy-to-reach position which doubles as a main action button and an alternative to open drawers, mostly for those who can't use edge-swipe well. So, dragging the Action Button is not "a solution looking for a problem", but in fact it is the answer to the problem that screen corners are hard to reach when you hold a bigger phone (which are becoming more and more common) in one hand. I do agree with you, however - and this is also what I suggested within our team before - that on Android, people are not used to being able to drag the FAB, as it's inconsistent with what they expect from other Android applications. What they _are_ used to, on the other hand, is those buttons in the top bar. Therefore what I'd like to see is that when our components are used within Android, they draw the buttons in the top bar (where they are - and that is a research-supported fact - hard to reach, but consistent with other Android applications) but leave edge-swiping as an easier-to-reach alternative for _both_ drawers (stock Android apps do it only for the left drawer, which is really nonsensical if you think about it). When the same application is run on Plasma Mobile, where people have learned how to use the Action Button-dragging from other applications, it should use that one. The Action Button, then, should on Android not always be drawn, but only when it is actually used for an action, like in the stock Android apps. I'm currently conducting usability tests with the components, and that's not "We ask people what they like", but I observe people to see what actually works well. The difference is that when asked what they like, people will almost always prefer what they're used to, even if it's inferior to a new solution. Another thing I want to see changed in our components, though is the actual dragging interaction with the FAB. Currently one has to drag it pretty far to open a drawer, which defeats the whole "Not having to stretch your thumb to a corner" advantage and currently indeed makes it rather clunky to use. I hope I was able to explain the reasoning behind our solution a bit better, while at the same time expressing that I support our components working in a manner that is similar to - but still better than - other Android applications. So, what do you think? Best, Thomas [1]: https://sessellift.wordpress.com/2015/10/15/behind-the-scenes-of-the-kde-phone-hig-part-one-basic-assumptions/ [2] http://www.uxmatters.com/mt/archives/2013/02/how-do-users-really-hold-mobile-devices.php [3] http://www.uxmatters.com/mt/archives/2014/09/insights-on-switching-centering-and-gestures-for-touchscreens.php _______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
