This text was originally written in 2012. By 2024, there have been many changes, including that smartphone hardware is on a completely different level, that the many specific comments on user interfaces need no longer apply, and that the degree of e.g. manufacturer customization makes it harder to make general statements.
Nevertheless, there are many lessons that can be drawn, as it matters more what approaches work well or poorly in general than how Android looked in the days of yore. Moreover, chances are that the more general problems still apply, including the poor attitude of e.g. Google. It is certainly still true that life is made unnecessarily hard for users.
Even today, I only make minimal use of smartphones, except for the purpose of tethering my computer for Internet access—and a regular computer is still a far superior alternative outside situations where bringing or using a computer would be cumbersome.
To make a more direct comparison between my current Smartphone and/or “user experience” with their respective 2012 counterparts is hard, as my memory of 2012 is vague and as I have worked so little with the current version. However, I see enabling the developer options, installing F-Droid and using this as the main source of apps, and learning the basics of the ADB-command (to access the smartphone from a computer) as near-mandatory today (I am uncertain what the availability was in 2012). I also strongly suspect that installing some Bash-like command line and/or similar tools would be a very good idea for less casual users with a background in the Unix-verse, but have not explored this area beyond learning that some apps exist.
Hardware-wise, my current Smartphone is far more powerful and has a far larger screen than the device discussed below, but it lacks a keyboard, which hampers input and would make e.g. the use of Bash much more cumbersome. (External keyboards are almost certainly available, but I have not looked into this and they would reduce portability.)
In terms of changes to the below, I have written a 2024 addendum here and there (and made some minor language changes), but not all are from 2024 (or later). Newer will (I hope, consistently) contain the year of writing; older do not. The latter should be seen as “2012 or thereabouts”.
In mid-2012, I had decided to try a smartphone based on Android—my first cell-phone since around 2007 (and the telephone features, unlike e.g. the Internet access, do not really interest me even now). The choice fell on an xPeria mini pro, which seemed to be a good beginners model. Below I will discuss some of my impressions during the first two weeks of use, with some amendments based on later experiences.
Bottom-line: To root and install better (non-standard) apps, possibly even an alternate image, is a necessity for anyone who wishes to be a serious user. The default setup is so user-hostile, bloatware infested, and limiting that it could easily have come from Microsoft—despite being derived from Linux...
It might be that some of the below problems are solvable through tricks that I have not yet learned; however, if so, these tricks are highly non-obvious and the user does not get any help in learning to do better. Further, the overall sum is too depressingly large for this to be a likely explanation for more than a minority.
To my 2024 recollection, I never did learn such tricks, but this might be because I did not truly push forward and soon re-focused on regular computer use. Similar remarks can apply elsewhere without explicit mention.
I am not at this stage always able to tell what problems pertain to Android, what to the phone used, and what to the service provider (O2). For simplicity, I will rarely attempt to differentiate below and will use “Android” as catch-all; however, the reader should keep in mind that statements made might vary depending on these factors—and that not all problems will be Android’s fault.
All statements refer to the phone in its original installation state, unless otherwise stated. Many problems can be solved by installing better software, rooting, switching to an independent image, whatnot—this, however, is a discussion of what Google/O2/Sony want the user to use. In analogy: Windows does not become a good OS, or Microsoft a good company, because a pre-installed Windows can be replaced with another OS.
My first impressions were very favorable: Except for difficulties due the paradigm change and the time needed to find and start many apps that I could have started in a fraction of the time on a “real” computer, things ran smoothly and impressively.
Unfortunately, this impression did not last long—but soon turned into frustration with the near crippling user-unfriendliness and lack of functionality. Indeed, in retrospect, my original misperception resulted from the extremely limited functionality available. By analogy, a car that only has one control/switch/button/whatnot “drive forward” would be easy for even a child to handle; however, it would also be infinitely inferior to an ordinary car with a steering wheel, gears, breaks, ...
But is not a reduction in functionality needed due to the lesser amount of working memory and long-term storage?
It is, but not to the degree exhibited here. Consider that ordinary computers of yore managed to do more with the corresponding hardware. Further, that the default installation wastes, positively wastes, resources on pure bull-shit apps (cf. below).
In the end, I can only call this a user-interface disaster: The unfortunate tendencies of UI design that have long been exemplified by e.g. Microsoft are taken to a new extreme and the strengths of e.g. Unix (which by right should dominate UI and software design) are almost entirely ignored.
The by far most used app by me (at the time of writing) is the built-in browser. Unfortunately, it has so many quirks and inefficiencies that I could write an article on that topic alone. To give a few examples:
Tabbed browsing is cumbersome and with no good way to move quickly from tab to tab—and no indication what tabs are currently open. Effectively, the user has to press the menu button, choose “Windows”, and make a choice in the new menu (possibly after having scrolled to even see the relevant entry).
Opening a link in a new tab is not as bad, but still worse than in a regular browser: Instead of the simple middle-click, the user has to keep his finger on the link for several seconds, after which a menu appears with the option to open the link in a new window (with several other choices). This is particularly annoying on pages with a link/article/whatnot overview, where an experienced user will often want to skim through the entire list and open the entries that seem interesting in new tabs. Here a very noticeably slow-down occurs.
As a further annoyance, the number of tabs that might be open at a time is artificially limited: Suddenly, half-way through such a link list, the entry to open in a new window is gone... Yes, mobile devices have less memory available, but the limit is hit unrealistically soon, which makes me believe that the implementation uses an arbitrary, fix cut-off—even when the device actually could handle more tabs. To make matters worse, the corresponding menu entry is not disabled, but removed entirely, which leaves the user surprised as the exact same tap as earlier suddenly leads to a query for adding a bookmark...
All in all, it might technically be more correct to speak of “windowed browsing”, seeing that the word “window” is used over “tab” and that there are no tabs to be seen.
However, on the desktop, tabbed browsing is usually superior and the main way to have more than one webpage open at once. Further, since there does not appear to be any windows (in a conventional sense) at all in Android (but just a series of screen-filling apps), “tabbed” is the more natural word.
Unlike in ordinary browsers, there is no indication of where on the page the reader is, e.g. through a scrollbar. This information, however, can be highly interesting. Notably, it is possible to include this information without losing screen space—as is proved by the mini-indicator that is shown during scrolling. Why not just keep this mini-indicator visible at all times?
Making a very small scroll to activate the indicator is, obviously, an acceptable work-around—but a work-around for a problem that should not exist in the first place, had the UI designers actually thought the situation through.
The menu options are far too few, leaving the user crippled.
Easy navigation to the top or bottom of the page is not present.
It is not obvious when a link has actually been called, the progress bar sometimes not appearing at all or needing in excess of ten seconds to do so—but appearing immediately after a second tap on the same link.
I would speculate that the progress bar only appears after the server has started to reply (or possibly been contacted with a “get” request), but is not shown during DNS and “head” requests. From a technical point of view, this would not necessarily be unsound; however, for a user it is a confusing hindrance.
Worse: If the user briefly switches to another tab and then returns, the old URL is displayed—with the obvious, but faulty, interpretation that the new URL has been forgotten by the browser and has to be re-entered/-selected.
The bookmark view does not contain a way to remove bookmarks... Instead the user has to counter-intuitively go to “most visited” and unbookmark links there. What happens when a bookmark is not among the most visited links (which is quite common—despite Microsoft’s idiotic fiction of “favorites”) is not clear to me.
Partial correction: It is possible to delete bookmarks directly; however, not in the typical manner of clicking e.g. a delete button or in the manner used for “most visited” (tapping a bookmark symbol next to the entry): A prolonged tap on a bookmark brings up a menu with (among others) a “delete bookmark” entry.
While this is some improvement in that it is now possible to delete even rarely visited bookmarks, it is also unnecessarily slow and is very, very sub-optimal for the initial step of throwing out the many (often) utterly useless bookmarks that come pre-installed. (Which I recommend even with ordinary browsers; however, positively urge in this case: The smaller screen and the Android paradigms make the list of bookmarks cumbersome when it contains more than a handful of entries. Further, cf. below, the pre-installed bookmarks on my phone where routed over O2 in an unconscionable manner.)
When the user scrolls, an idiotic and unrelated zoom button appears: There is no reason to assume that a scrolling user wants to alter the zoom; and zooming is better done by other means in the first place.
To make matters worse, this zoom button appears to block scrolling (!), when the user tries to scroll with his finger in the general area of the button. Further, it has happened quite often that there has been a link that I wanted to click immediately beneath the button.
Idiotically, the FTP protocol is not supported—something regular browsers have managed since at least the mid-1990s. Further, there is no indication in the browser that something is amiss when the user attempts an FTP download. The problem is only clear when manually visiting “downloads”—and even here there is no indication what caused the problem.
Equally idiotically, file-system access does not seem to be possible, attempts being met with the error message that a particular directory is a ... directory. In contrast, Fennec (discussed below) does allow access—as does any and all ordinary browsers with even a sliver of self-esteem.
Entirely and utterly inexcusably, activating images does not merely lead to new tabs having images—but retroactively loads images in any already present tabs! (I have images deactivated by default for several reasons, including saving bandwidth, minimizing annoyances in website appearance, and reducing the risk of unethical tracking of my activities.) Obviously, this is contrary to both what a user expects and what he will plausibly want in this situation. I note that there is no good workaround for this misbehavior, while the opposite behavior (if unwanted) is quite easy to workaround through a reload.
Repeated crashes, with no warning, no error message, and no possibility to recover the pre-crash state. The more annoying as these typically occur when they do the maximum amount of damage—when many yet unread tabs are open.
When the last window is closed, simple reason and standard behavior elsewhere would dictate that the app is either terminated or remains running without any open windows. Here, however, a new window is automatically opened with the default page—a behavior so contrary to reason that I would not believe it, had I not seen it myself.
Of course, the possibly single largest annoyance is the problems that arise through the many scroll movements that inadvertently cause a link to be pseudo-tapped—however, this is a general conceptual problem not specific to this app. Further, it is possible that this is more a problem with the touch-display of the phone than with the software (I lack comparisons).
Had the same problem occurred in 2024, I would have been remiss not to discuss a training effect that might have resolved the issue. Back in 2012, my screen (and the typical screen, in general) was so small that at least the main blame must fall on the makers of phone and/or software. (Similar remarks might apply elsewhere.)
Frustrated with the user-unfriendly “browser” application, I decided to try a few alternative browser—and at the end of this experiment, I was so angered by the horrifying, mind-defying user-hostility of the two alternatives that I actually considered throwing my phone at the wall and be done with it...
Opera Mini (or was it Mobile?) lasted no more than five minutes: It had nothing (in particular no extension to the minimal settings of the default app) new to offer, but endlessly harassed the user with useless and annoying animation after useless and annoying animation. (Unsurprisingly, a setting to disable the animations was not present...)
Fennec (the Mozilla/Firefox counter-part) initially gave a far better impression, including having very extensive settings available under “about:config” (while Opera had only minimal alternatives under “opera:config”). Indeed, Fennec might yet be my ultimate choice, especially if the add-ons available prove able to compensate for some weaknesses.
However, there were several major annoyances, including: The arrow keys rarely worked in various text-fields and they sometimes seemed to work (cursor was re-positioned) but did not (pressing any key afterwards restored the cursor to its original position); in effect, the only way to edit a field was to delete every single character and write something from scratch—and seeing that I was constantly using Google to find various work-arounds for Fennec annoyances, this soon became an evil circle of never-ending frustration. A near unusable overview of the tabs available (with reservations for the existence of some unknown tricks; however, if such are present, major points must still be removed for a counter-intuitive interface). The address bar inexcusably did not show the address of the current page, but its title—something of no use and of great hindrance, and something entirely illogical for an address bar that violates almost twenty years of well-functioning convention.
The latter is a good example of a problem with the mentality of both Opera and Firefox in their standard/desktop versions: They are hell-bent on making “improvements” that in reality make their products worse—and shove these down the throat of the user. (A remedy is either not present or requires research and unnecessary leg-work.) Opera’s idiotic alteration of the standard behavior of a number of keys to include the “fast forward” feature is another excellent example—the feature it self might or might not have brought benefit to the users, but the decision to alter the key-mappings made it highly user-unfriendly—and forcing users to alter each and every key-mapping by hand, instead of just toggling a singe checkbox, made it directly user-hostile. In fact, being exposed to this idiocy for the umpteenth time with a new user account (and therefore the need to make the corrections for the umpteenth time) was what made me finally abandon Opera.
A tangentially related annoyance is that, after the installation of the other browsers, “browser” now insisted on querying with which browser links should be opened—despite itself being a browser and despite it being absolutely clear-cut that if someone clicks on a link (to a HTML page) in a browser, the browser should handle it itself. Not respecting this, is not only illogical—it is a usability disaster, making “browser” unusable when any other browser is installed. This is the more absurd, seeing that installation of an FTP-client (AndFtp) to compensate for the lack of FTP support in “browser” went unnoticed: Every time an FTP link is called in “browser”, it still tries to handle it itself—despite being entirely unable to do so...
A minor, but entirely unnecessary, cause of confusion and a few early mistakes were the idiotic checkboxes: Instead of using the established way to display a checkbox used in most modern UIs (including non-mobile browsers), Android has gone its own way, where a checkbox always contains a “check”. What changes when (de-)activating it, is that the check becomes (de-)high-lighted.
This is particularly idiotic as the new user already has to do a considerable amount of re-learning due to the new concepts forced by touch-screens, limited screen space, and so on.
Further, I strongly suspect that situations arise where e.g. unfortunate light conditions make even experienced users confuse the checked and unchecked versions.
By 2024, homebrewed checkboxes (and other UI elements) have become more common everywhere, including in regular browsers, which makes for similar confusion. The use of colors to indicate the state of a checkbox is a particularly common problem—and different colors on different websites and whatnots, at that. This despite the obviousness of having a checkbox being empty when unchecked and showing a check mark when checked.
(By analogy, would anyone replace the left-/right-turn indicators on a car with a central indicator that used one color to indicate left and another to indicate right? With different car makers using different colors?)
Scrolling is done in what amounts to the wrong direction for someone used to a normal computer. For these, scrolling implies dragging a part of the scroll bar corresponding to the current view port upwards or downwards (with scrolling through page-up/page-down following the same directional convention); in Android scrolling implies moving the document relative the view port—a movement in the opposite direction. While the latter is intuitive in context, it introduces a very unfortunate inconsistency. Indeed, I strongly suspect that the user would be better of with an ordinary scrollbar (or some sort of “scroll handle” which would take up less place than a full scrollbar.
A further disadvantage of the missing scrollbar is that the information it would have provided is also missing: How far into the document is the user? How large is the document relative the view port?
Many of the app names are downright idiotic. Consider e.g. a browser which is simply called “browser”... Such names make it hard to search for support, make informed decisions about alternatives, etc. This is by no means a help for, but a hindrance to, the unskilled user, who is prevented from learning and remains unskilled.
My own experiences with users (not to mention as a user) are crystal clear:
Users benefit from learning concepts, understanding what goes on, seeing the difference between different applications and applications/OS, etc. “Protecting” them from such “complexities” is a bear service. A user should not need to know true complexities, but he should be required to learn the barest basics—and under no circumstances should software makers make life hard for those who want to learn. In an analogy, the driver of a car should not need to learn how the motor functions—but he bloody well should learn when to use what gear, the difference between the brake and the accelerator, etc.
A major annoyance, a clear disadvantage, and a potential danger is formed by the many, many apps that come pre-installed. A few bring value, but most must be written off as some form of “bloatware”—possibly, even de facto malware: No benefit for the average user, no documentation what they do, automatic autostarts, far too excessive rights that potentially make the user an easy victim (and often are not needed for the alleged functionality), ... Notably, these apps are not de-installable without rooting, the autostarts cannot be turned off, and the excessive rights cannot be limited.
Absolutely and utterly inexcusably: Whoever is responsible for this user-hostile outrage should be taken out and shot.
By 2024, the situation has improved in so far as users have somewhat more control and that some built-in sandboxing is present—likely, because the abuse went to such extremes that Google could not ignore user protests. While I have never myself been a victim, I have, for instance, heard of apps that immediately went to the user’s address book and sent recommendations to use the self-same app to all persons listed—in the name of the user.
Note: Working my way downwards, I am surprised to find references to sandboxes even in the 2012 text. I do not remember the scope of these (frankly, had forgotten that they existed), but modern versions have certainly grown stronger.
The first hour or so, was filled with very annoying sounds and buzzes that brought no or only a marginal benefit. Turning these off made life far more enjoyable—and the better decision would have been to have them disabled out-of-the-box. (Or to provide some very obvious and fast way to disable them, say a one-time pop-up querying whether such effects should be allowed.)
For a number of hours, I was frustrated by the attempts of Android to guess what I wanted to write. Its guesses were usually incorrect, often considerably so, and the net-worth was decidedly negative.
While the value and quality of this feature can be discussed in general (others, in particular those who type slower, might see things differently), one aspect is not defensible: Instead of merely suggesting extensions based on what had already been typed, the suggestions quite often altered the already entered text (!)—and did so without giving appropriate notice.
This too is a feature that might be best disabled out-of-the-box. If not, the option to disable must actively be given to the user at an early stage.
At some point between the original writing and 2024, the discussed “market” was re-branded as “Play Store”.
Being strongly deterred by the outrageous conditions for Google accounts, I had to make the tricky choice between foregoing the standard app market and taking the risk of accepting conditions that were not conscionable.
In order to make that choice, I tried to search the market—only to find that even a search was not possible without an account. User-hostile, absurd, and violating a general principle of web development: Restrictions on what a user is allowed to do should only be placed where the restrictions make sense. Cf. a blog entry on the problem of message boards that are afraid of spam block Tor users from reading the boards—where they should obviously only (if at all...) be blocked from posting.
From one POV, this could also be seen as a general principle of software development; however, such a statement would need to be more carefully formulated. Most notably, when it comes to situations involving multiple users, secret data, abilities distributed among certain users or user roles, and similar, the opposite principle should usually apply: That which is not explicitly permitted is forbidden, information is on a need-to-know basis, and so on.
Additionally, this does not make sense from a business POV: What if a regular store would prevent prospective customers from entering the store before they had agreed to provide their billing information? Obviously, there would be many customers who did not even bother to enter the store...
A plague of my work with “browser” (I am uncertain whether this is app specific or a global issue), is how the zoom function is tied to double taps. In my case, these double taps are invariably not intentional—indeed, they occur even when no reasonable algorithm would see a double tap.
A very common scenario is that I change the zoom by pulling out a piece of text with my fingers—and the zoom immediately snaps back to the original position when I remove my fingers from the screen...
It is possible that I misinterpret what happens: Another possibility is that the normal “zoom with fingers” function considers the zoom temporary under some set of conditions, e.g. some timing in the removal of the respective finger from the screen. However, if so, corresponding points have to be deducted for a counter-intuitive and poorly documented interface.
It is unclear when a process is ended, what processes are currently running, and there is no good way to swiftly move from app to app. The built-in “wannabe manager” is near useless.
So far, barring individual exceptions, I have not found any way to terminate an app from the app it self (e.g. through a “close window” button or an “exit” menu entry). The consequence is that apps not currently needed keep on running, wasting resources that could have been better used.
Android has a crippling lack of file access—turning the possibly greatest strength of Unix (the ease with which generic applications can cooperate and interact through files, pipes, and text) into the greatest weakness of Android. Even backups and the like require rooting (or, possibly, some non-default app that I am not yet aware of—but this would be odd in the light of the extreme usefulness of such an app and the many entirely useless apps that are installed; cf. the corresponding section).
To some degree, this can be justified by the “sandbox” concept used to prevent applications from overreaching themselves. However, at a minimum, there should be some privileged, user-only tool with full access to facilitate the user’s work (e.g. a small CLI or a file manager). Further, the sandbox could remain unthreatened, if the user was given the ability to selective grant apps the right to access specific directories.
Further, considering the number of pre-installed bloatware apps with insane rights that are present to begin with, the benefits of the sandbox seem limited—like having a steel door with three locks next to an open window, easily reachable from the ground and large enough to let a grown man through.
More generally, the user has too few rights and possibilities. Among the most glaring and hard to defend left-outs are the rights to de-install the pre-installed applications, to limit the rights of apps, to decide what apps are started automatically, and (as discussed above) to access the file system in an appropriate manner.
This state is not conscionable: The phone belongs to the user and he must have the right to do whatever he likes. This is my phone—not Google’s phone, not O2’s phone, and not Sony’s phone.
Indeed, I would strongly encourage legislation that the owner of any hardware (including smartphones and game consoles) has a non-negotiable right to do whatever he likes with the hardware, without any artificial restrictions, be they legal, contractual, or technical. (Where “legal” refers to regulations directly relating to hardware, use, ownership, whatnot, but not including cases where the use would be illegal through other mechanisms, e.g. as a murder weapon.) This would, in particular, include full administrator rights (not with the default account, however) and the right and opportunity to install any alternative system on the hardware.
The trend between 2012 and 2024 has, unfortunately, gone in the other direction, with commercial operating systems and whatnots trying harder and harder to limit the users. If it was up to e.g. Microsoft, users would never change settings, install “unapproved” applications, whatnot. This while some application softwares, including Firefox, seem set on removing the flexibility that they once had.
My experiments with the email client have been short but very dissatisfying: The UI is severely lacking (but my memories too vague for more specific statements—apart from the thoroughly idiotic placing of the button to load more message at the end of the message list, forcing the user to scroll down the entire list, click on the button, and then scroll all the way back to actually see the messages). The configuration is uncooperative and insists on making ridiculously poor guesses as to what servers, ports, whatnot, should be used—better leave this to the user, who actually knows what they should be. (Or, if he does not, will only be more confused and unknowing after the attempts to “help”.)
It is not clear to the beginning user when a setting has been saved and when not. Based on later experiences, it appears that Android follows the inferior every-change-takes-effect-at-once paradigm, instead of the superior OK/apply/cancel paradigm.
Having a phone with a physical keyboard is a definite benefit; however, this benefit is not used like it could: Most apps do not appear to have any support for e.g. short-cuts. The layout deviates unnecessarily far from a standard computer keyboard. Even after switching (my German phone) to the international layout, the y- and z-keys follow the German convention (they are switched relative their positions on a English/US keyboard)—which makes life tricky for someone used to typing blindly and to mentally make the adjustments y->z and z->y whenever looking at his keyboard.
I use a US keyboard mapping on regular computers, but all keyboards to be normally found in Germany have a German (physical) layout. In those odd situations where I do look at the keyboard, e.g. when typing a new password, a mental adjustment of the keys is necessary.
The pre-installed bookmarks are all routed over an O2 server, implying both increased waiting times and a danger of O2 spying on its users in an unconscionable manner.
Some functions for (at least) input, e.g. marking of words, are local to the current app, when they should be global. There is no sense in app after app re-inventing the wheel in slightly different manners.
On the top of the phone, there is a status/notification bar/dropdown with several weaknesses, including: Always remaining in sight, wasting screen space. Opening on drag instead of tap, implying that a scroll in a browser window can easily lead to the status bar suddenly filling the window, while the scroll is lost. (Generally, there are many “drag” actions that might have been better implemented as “tap” actions; however, there might be circumstances that legitimize some of them—e.g., hypothetically, that a tap-to-unlock would risk too many involuntary activations compared to a drag-to-unlock.) The “clear” functionality does not clear all notifications, but leaves some (at least update notifications), in place.
I note that while updating has some obvious advantages, it also takes an unspecified (but likely large) number of MBs out of my reduced-speed-after-300MB pseudo-flatrate and risks reducing my later ability to root or use an alternate image. This not to mention the risk that functionality is reduced, that alterations to my data take place, whatnot—as has already happened to those allowing updates to iPhones, xBoxes, and similar. Correspondingly, it is user-hostile to pollute the status bar with an update notification after a “clear”—either the user wants to update or he does not.
The following is an automatically generated list of other pages linking to this one. These may or may not contain further content relevant to this topic.