Killing the back button

killing-back-button

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:

  1. it bring you back to the previous view of the same app (and it isn’t always clear which the previous view is);

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

Subsurface's submenu
Subsurface’s submenu

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:

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

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

Just an idea for close-app button
Just an example for close-app button

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!

Comments (Markdown supported):

  1. Eugene

    https://www.fastcodesign.com/3053406/how-apple-is-giving-design-a-bad-name
    > Touch-sensitive screens, especially on relatively small devices, offer multiple opportunities for things to go wrong when an active link or button is accidentally touched. These accidental touches move the user to a new destination. The standard, simple way of correcting for these occasional mis-touches is to have a Back control: Android phones have Back built into the phone as a universal control that is always available. Apple does not. Why? We don’t know. Were they trying to avoid having a button or a menu? The result does provide for a clean, elegant visual appearance, but the simple-appearance mask is deceptive, for it increases the difficulty of usage.

    The whole article is a great read BTW.
    I like your idea about forward swipe to provide the redo ability, but lets not forget that the swipes do not have great discoverability. And how they should work in a browser for example? I think that some form of a toolbar with undo/redo buttons must be provided and enabled by default with ability to disable it and use just the swipes for people who already know how to use them. After all its the KDE, where configurability is the top feature.

    1. admin

      Browser: you mention an other area that benefit of my idea; now the mobile web is divided into traditional sites and web apps; for the first ones the system-provided back button has sense; for the second ones not, because web apps can’t manage a back button and if the system provide one that do unexpected events like closing the web app, it break the integration of the web app into the system. Instead the web app should provide a back button if it need it, because the traditional “come back to the previous page” of the browser shouldn’t be confused with the back action of a web app. This is because I suggest to put the back and forward button into the global drawer of the browser, where there are also the current tabs, exactly how Lighting browser already does on Android, this suggest that button is related to the browser, not to the current web app that remains in its tab and there it provide all the buttons it needs 😉

  2. SarcasmBoy

    Yeah, why bother with an almost-standard in a billion android devices, if you can have it your way. This will dramatically improve the user acceptance…

    I love my back button. It is there, in a fixed place. Always. And if the app developer is not retarded, it will somehow make sense. I can reach it with my thumb and i don’t need to worry where it could be positioned now. Swiping is for me a gesture to scroll through application data in the current view. Horizontal swipe for going forward and backward through the views is in my opinion rather stupid. Putting a back button at the end of variable list of menu entries is even worse, especially if I have to scroll to get there.

    The usual default I have observer is: default gets you one view back, until you reach the start view. If you use it there, the application closes (process ends – or asks for more information). Almost all of my apps in use follow this logic.

    1. admin

      In this case it will be my challenge to provide a “task manager” that don’t make you miss the back button 😉
      (P.S. the idea of swipes is already well applied in Telegram for Android, please try it and let me know how it feels for you 🙂 )

    2. dfens

      this exactly sums up my thoughts on this subject; no need for software back buttons but rather having the hardware back button doing consistant actions like back one screen until quitting.

  3. Kjetil

    Nice work, It would also be interesting to think a bit on how to integrate this with Android apps running under Plasma Active. Could it function sensibly?

    1. admin

      Android apps need a system provided back button, so I think that we will be forced to provide a virtual one in a bottom toolbar that appear only under Android apps. This is the main reason the system provided back button is stupid: it chains apps to the system and the system to the apps.

  4. Matthew

    Again, this is looking awesome. One thing I find interesting is the idea we have to “quit” apps. While I understand after having to deal with this on more traditional systems, I do think it would be good for everything to move more towards the Android/iOS/Mac OSX system of not actually “quitting” the actual process. People don’t really care about whether applications are actually running, they just want everything to work. It be cool if Plasma Mobile could also move in this direction, while pulling the desktop along with it.

    To look at your example, having a way to remove windows from the task switcher is great to make it easily to choose quickly between them. But I don’t think just because you do that an application should be killed. Some applications may wish to keep running in the background to finish some tasks (upload/download data to internet). Forcing applications to not run in the background would just force us back to the old iOS days.

    Otherwise, this all looks exciting. It’s great that you guys are thinking about making a unique brand while still allowing it to integrate with other systems to make it feel comfortable everywhere.

    1. admin

      “People don’t really care about whether applications are actually running, they just want everything to work.” this is what Microsoft, Apple, Google and a lot of others think and for me is like saying “the user is stupid”. This kind of UX really make the user stupid. On GNU/Linux world I didn’t find anything like this: the UX let me learn more and more because ” what happen under the hood” isn’t masked how do instead the mentioned corporations 😉
      This is my personal vision: the devices are tools in our hands, not tools in the hands of producers to make us do what they expect we want or what they want we do 😉
      Obviously you can agree or not, and I respect also the opposite opinion about this.

  5. rmx

    >This scare users from using the back button or anyway it make them dissatisfied

    Ans your source for this stament is?

  6. Lionel Chauvin

    Personally I prefer use the swipe to switch between applications (like on the Nokia N9 or Jolla phone). I feel more free and not locked in apps. Sadly this design is not compatible with android design and introduces some problems. It needs a ‘lock’ mecanism to prevent switch application by mistake (It happens usualy when you are playing a game)

    1. admin

      Oh so the next updates could please you, stay tuned 😉

  7. serafean

    hi, having tried quite a few smartphones, the only one i really enjoyed using was the hp pre3. all based on gestures… may i suggest you take inspiration there?
    https://www.youtube.com/watch?v=OWVo_OjYq8w

      1. admin

        Oh, thanks for the suggestion 🙂

  8. Johan Ouwerkerk

    Well, to me it looks like the “column” navigation thingy is really cribbed from the Meego (N9)/Sailfish (Jolla) school of UX thought. And it actually works, really, really well to do things this way.

    What doesn’t always work so well on the Jolla (speaking from experience) is knowing *when* there is ‘deeper’ level so you can swipe forwards to drill down to a sub menu/page; and the tension between the swiping and cancel/ok type menus: you could accidentally navigate ‘away’ instead of confirming/rejecting an action.

    Finally, if you go with swiping then it’s worth pointing out there is a certain awkwardness/tension between having global gestures from the edge of the screen and in-app gestures/navigation. You have to design for the butter fingered as well as the deft.

    That’s where these fixed buttons could provide a welcome relief as a standard means to switch between modes of navigation. For example the back button could be mapped to task-app overview (i.e. Alt+Tab) and the search button could be mapped to krunner/launcher (Alt+F2).

    Or perhaps if the KDE activities concept is going to be used, that is also something to think about.


    Tangent about KDE activities:

    I’d like my phone to be able to separate into approximately 3 different types of activities:

    * Archetypes. This is things like “work” and “play” to be used to separate data/apps/priveleges and help me keep those separate. This could be really useful also in the context of MDM. It’s not just to separate privs, though, it’s also to provide context.

    * Activities, proper. This is to switch between “modes” of using the phone depending on the physical activity I’m doing. E.g. when I’m driving the phone should probably be operated in some kind of handsfree way and the maps/navigation app should probably be given a certain prominence and the webbrowser probably should not.

    * Projects. This is to group related apps/documents and so on, so that when I switch between projects all the relevant stuff is opened/closed and easily and prominently accessible automatically.

    So putting it together:
    My phone could know based on the fact that I plug it into a carkit and the current ‘archetype’ is work that I’m going to be driving to client John D. because of my work calendar and so open all my notes/prep work on the meeting with John D. (Project) and also switch to the ‘driving’ activity and fire up the navigation app and input the agreed upon time and venue for me.

    That sort of through-and-through navigation is what KDE technically could offer right now, has been thinking/designing for for years (see previous Plasma tablet & vivaldi efforts), nobody else really tackles as yet, and would make a real impact — in the spirit of “Simple by default, powerful when needed.

    1. I really agree with you about activities, I hope to see them improved also on mobile 🙂

  9. There is already a navigation bar exactly like Android’s on Plamsa Mobile. How are you saving any space by removing a back button? Navigation bar basically blocks the bottom space.

    You should also realize devs will write crappy apps. You have no control over how devs write apps. When you don’t provide a consistent way to navigate and only rely on developer providing a contextual back button you are setting yourself for people having no idea how to navigate back when devs fail to provide a back button.

    1. Is there already a bottom bar? 🙂 Actually Plasma Mobile is a prototype, and the Plasma it self is an highly configurable DE, so why we should force our selves to a pattern used by default by Android and configurable in Android it self, as many custom ROM already does? 😉 Probably Plasma Mobile 1.0 by default will have the current bottom bar, but we should let users to use different component exactly how they can choose different task-manager plasmoids in Plasma Desktop 😀

  10. I like the idea of rethinking user interfaces and interactions, especially as there is some room for improvement. Android certainly isn’t perfect, and neither is iOS, but there might be some things they do right.

    1. Back Button

    I agree that the behavior of the back button in Android is not that consistent and can be downright confusing, but there is one particular use case that IMO it works perfectly and isn’t covered by your proposal. When you’re in an e-mail app, for example, and click on a link that opens in a browser or in another app, the back button provides both navigation and context. It takes you back where you came from, without having to mentally “bookmark” which app/context launched the current app. On a desktop, that might not be too much of a problem as you have the visual space to see all running windows. On a mobile, not so much.

    On iOS 8 and earlier, that behavior was absent. It required users to manually switch back to the previous app that launched the new context. On iOS 9, Apple added a “Back to …” button at the top left of the screen in instances like those. Interestingly, that Back button disappears once you manually switch to or launch another app, which breaks the context and flow anyway.

    2. Closing apps

    In my observation of smartphone users, esp. family and friends, I’ve noticed that they can be grouped into two as far as task management is concerned. On the one hand, you’ve got those who don’t really care or don’t want to care about it, not bothering to manually close apps because they just presume the apps won’t run or consume battery/data when they’re not using it. Note that they don’t actually know or even presume that the system actually kills idle apps. They just presume that, since they’re not using it, it’s not running.

    On the other hand, you’ve got a group that is somewhat obsessed by apps running in the background and more often than not try to kill apps manually even when they don’t have to (or really can’t). These people usually have been burned by misbehaving apps that run in the background and no longer trust the system to do housekeeping for them.

    It will be interesting to see and hear how Plasma Mobile will address these two cases.

    1. My idea for task manager should resolve all of these issues, I designed it without a back button just since the beginning. Stay tuned, I will explain my idea here as soon as possible. At the moment I can say that some VDG members really like it, and it’s the main reason I started this blog site. I wanted to avoid “where is the back button?” questions so I made this post and the real one will follow 😉

  11. Pingback: Task managers on mobile: daydreaming about new possible approaches – Dissentio ergo sum

  12. Pingback: Mobile-oriented HIG, the first prototypes and the mock-up kit – Dissentio ergo sum

Leave a Reply