When common desktop-PC users first approach the Android OS, they need to perform an important open-mindedness exercise which will be surely harder for those who are long time PC users: get used at the idea that you don’t have to close apps.

Please note: there’s also a short version of this article, that avoids theoretical and historical considerations.

Paradigm shift

This is a paradigm shift in the way our infodomestics work. Once upon a time, as those who used DOS know, it was impossible to have more than a program “open”, or better running, at once. It was the single-tasking era, with its command line paradigm. Later, with multitasking, there was the need of a good way to manage multiple running applications, and with graphic interfaces technology it came into being the desktop and “windows” paradigm, made famous by Windows, ho copied it from Apple, who copied it from the early 80′s Xerox Star (this system was way over its times, look for it with Google Images to understand what I mean).

After 20 years of windows (or better panels – what do they have in common with real windows??) opening and closing, it’s clear that learning to get on with a new system is not a straightforward process, yet I’m sure an explanation will help.

Why changing?

The User Centered Design discipline teaches us that a user performing some task needs to think to that task and to choices strictly regarding it, because only one thing at a time can be put in the attention focus. The risk is that if tools are hard to use or need attention in any way, one would end up neglecting the main task and making errors or forgetting something. This could be harmless, but anyway slows down the work.

Experience got us, heavy users, used at coping with all those surrounding details, making it almost automatic and, in the best case, not needing attention. But this doesn’t mean that the task has become easy, and we must not forget about all those people that actually have no idea of how to use a computer, and are scared away by those procedures. I’m talking about the notion of file (who has never seen somebody copying a document by opening it and saving it with another name? It’s not his/her problem: it’s the file concept that is artificial), the need to look for an application, opening them, configuring them, search in their own menus for functions and cope with their bugs…

We’re used to this stuff, to our technology slavery, but it’s been about a decade now that we’re studying to improve the situation, and it’s time to give the solution we’ve found a trustful chance.

The “apps” concept

Part of the solution to the aforementioned problems is given by the “apps” paradigm, introduced to the market by Apple and anticipated by User Center Design gurus (see at the bottom). Partly, this new system was born to cope with mobile phones displays, and partly they took the chance to introduce something new: no more “open a program to do something”, but simply “do something”. Not only: apps are always smaller than a desktop pc program could be – not just on the screen, but also in features! This revolution aims to reduce the attention we need to give to how to perform a task, so that we can give more to the task itself.

Another difference from desktop applications is how we deal with them. No more “windows”, but tasks and activities (Android developers know how important these terms are). While we’re carrying out some task, only the current task’s activity is shown on the display, nothing else distracting us. If the interaction must proceed, it’s the app itself that takes us to the next activity. And if we don’t need anymore some activity, we just press “back” to get to the previous one, possibly reaching the Home.

What if we need to pause our task to perform temporarily (or forever!) another one? We press Home button, start our second task, and when it’s over, or want to get back to our old one, we can press and hold Home button to see a list of the latest tasks and choose ours.

On Android, an open and modular system, the apps paradigm was implemented so that they (and their components) can interact and mix, without the user even knowing about it. Imagine: you’re reading the news and you want to tell a friend about one of them. You touch “share”, the email activity pops up (it’s another program indeed, but we don’t care: we have to report the news), then the Contact List activity, and when we’re done we’re back to the news, where we left, without opening menus, looking for applications, and having to find again News program window when we’re done.

No task bar, no windows, and you didn’t close anything.

The ever-open apps

We finally get to the core of the topic. It’s exactly this last feature that bothers us, good old technology slaves, use at always keeping it under control to maximize efficiency: keep memory free, close unused programs.

It’s just this kind of people that, looking at which processes are running on their phones, find out that there’s always an absurd amount of them, they might find things they haven’t used in hours, other never used! They think: “What a waste of resources!”. And so they invented the infamous Task Killer, a software idler/waster-killer. Right, don’t forget it’s a well designed, strict operating system.

In fact, the processes we see aren’t actually doing anything. They just fill the amount of memory needed to let us restart the activity from where we left. It’s Android that cares of freeing those resources, and only if necessary. Obviously it will begin by freeing those least used. Not only: if we left a task some time ago, we might have just forgotten all about it, and seeing it again would just make no sense. Solution: Android “resets” tasks that have been inactive for some time.

Poorly designed apps

Not everything is going rosy however: as everything, apps need to be well designed. There’s an application component called service and it’s used for those tasks that don’t need to interact with the user (if needed, they send a notification). Services, by their nature, might be running even if the task regarding them is not in our attention focus, for example a file transfer (unless we like to watch progress bars) or a service that checks for new mail every 5 minutes.

While in the first case the service will very likely be killed when it’s done, the second one will probably stay active “forever”. Android can still terminate it if it needs resources (it will also restart the service in better times), but if too many services behave like that the whole system suffers, especially if each of them does something every 5 minutes.

There is also a limit case where some services require the processor never to go to sleep: nothing worse for the battery.

It’s good practice, then, to let the user choose the execution frequency of such services and possibly deactivate them.

As I’ve already said in another article, it’s up to you to require apps that work. If you’re not comfortable with some technology thing, it’s not you not being able, it’s the developer that doesn’t understand and doesn’t communicate with his/her users.

For more

A wonderful article on why task killers are bad:

Historical article on why and how avoiding eternal services are to avoid:

Three books from two authors that showed the way to follow to free us from technology slavery:

  • The Psychology of Everyday Things and The Invisible Computer by Donald Norman
  • The Human Interface by Jef Raskin