With “back button” I’m referring to the (physical or virtual) button mainly used in Android, that, as all Android users know, always cause a lot of confusion, in fact two events could happen pressing it:
it bring you back to the previous view of the same app (and it isn’t always clear which the previous view is);
it close the current app bringing you to the previous app or to the home screen.
This scare users from using the back button or anyway it make them dissatisfied. In some cases the back button is totally useless, a waste of space of the screen or of a physical button.
In fact it’s, for me, a totally no-sense thing, since it chains the app to a system-defined pattern, on devices where the touch screen give a lot of freedom to the apps, from a user interactions point of view. The back button has sense if drawn inside an app by the app itself at the right moments in a way that make clear what it does. A lot of app already drawn a back button by their selves: you can see it both in Android and Ubuntu Touch… in the top-left corner of the screen. Yes, exactly, the most difficult to achieve point of the screen, for right-handed people.
Discussing KDE mobile HIG, we decide to try to keep all the things more reachable as possible, so near the bottom, since devices with large screens are more and more widespread. So, a bottom bar with back button? No. On mobile the contents are the rulers, and we want all the screen for them, so avoiding tool-bars when it’s possible.
One of our solutions, for now, comes from our views-by-columns approach: the contents are organized by columns, each columns is a view of the screen; to come back to the previous view the user have to swipe horizontally (by default from left to right for right-handed people).
An advantage of this: the back button on Android is one, instead we can let apps to provide more than one “back” action; how? The keyword is “context” and an example here will make clear what I mean: if you open the global drawer, you can have menus and sub-menus, and to come back to the previous menu a back button could be drawn inside the drawer. So the user will use it to go to the previous menu and the swipe to close the drawer. No confusion, very intuitive. You can already see this example in the (already mentioned) preview of Subsurface Mobile app:
An other big advantage we (me, Thomas, Andrea, …) hope to see is the forward swipe: our idea consist into the chance for the user to re-open a view just left by a back-swipe, through an other swipe to the opposite direction. This should please the user that swipe back by mistake; also, you could switch between the view of an e-mail and the editor-view to reply to it without, obviously, losing the written text.
But the back button on Android close the app, too; so what about the swipe? The swipe shouldn’t close the app. Do you want to close the app? Reflect about what “close app” means: on Android, come back to home screen doesn’t mean close the app, that could continue to run in background. An other behavior that confuse the users: is the app running in background? Did the system stop it to free RAM? A behavior we don’t have on desktops, where we often have a task manager that indicates which apps are running (and eventually an icon in the system tray to indicate background services). To stress that a service is running in background, some Android apps use notifications: a needed trick caused by a poorly designed system…
So, my (just personal) idea is:
in Plasma Mobile, to don’t provide a system back button, but only a solution to switch running apps and go to the “home screen” (and for this we could have a lot of solutions, some more traditional and some more innovative, I will talk about them in a dedicated post);
in the global drawer of the apps, to provide a button to close the app, removing it from a task manager if there is one, and stop its processes (aka closing the app like on desktops). This doesn’t mean that the system should provide a way to close the apps 😉
On Android, to preserve the global user experience, I thought that the system provided back button should act like the back-swipe where this is provided, and should “hide” the app exactly how it happen for Android apps. This should make us able to care of our ecosystem (Plasma Mobile + KDE mobile apps) without big limits, to introduce our (innovative?) solutions and, at the same time, to preserve the consistency in Android for KDE mobile apps running there.
Please, notice that this post is about only a user experience point of view, I don’t know what this imply for a technical level, so don’t ask me about it, please base your criticism only on the UX 😉
Ciao, see you around!