A polite rant on mobile UX(blog.hipwerk.com)
blog.hipwerk.com
A polite rant on mobile UX
http://blog.hipwerk.com/a-polite-rant-on-mobile-ux/
40 comments
I’m right handed, but I use my phone with my left hand. Most of the time because I need my dominant hand to do something more complex. I don’t know if “handiness” really determines the hand in which you hold your phone.
You are correct. Let me point this out in an update.
I'd like to stress that this is the correct solution. It is not enough to just slap on a "left-handed mode" that mirrors the UI. Most left-handed people don't use just their left hand when operating their phones - they use both, but prefer their left.
"Android is Android"
I don't like the fact that Google's apps, all of them, feel foreign on iOS and OSX. Chrome has its own PDF renderer, settings pane, maximize behavior (before Yosemite), other little things. The iOS apps feel like the Android ones.
Google seems to be creating its own little OS inside of every other OS and the baseline is Chrome (OS). Wasn't there an effort, or talk about, to have Chrome do its own thing in Windows 8? This is why Material Design is important to Google. It targets the lowest common dominator, web browsers, and seems like it runs the same on a powerful computer or low-spec'd phone. While Material looks good, I feel that they may have held back a little because of browser limitations (you cannot do overlay blurring like iOS, for example).
Anyway, a lot of people love the common feel of apps across platforms. People seem to really like that about SublimeText and Chrome. I personally don't. I thought it was in poor taste when Apple made Safari and iTunes behave as if it were on OS X when running on Windows and I think Apple even had its on OS X-style update windows for the windows apps.
It's a fine line. As a developer Id rather code once and ship than to figure out all of the little idiosyncrasies for every platform. As a certain type of user I want apps to act like the other apps on my platform of choice, most users probably don't care or notice though.
I don't like the fact that Google's apps, all of them, feel foreign on iOS and OSX. Chrome has its own PDF renderer, settings pane, maximize behavior (before Yosemite), other little things. The iOS apps feel like the Android ones.
Google seems to be creating its own little OS inside of every other OS and the baseline is Chrome (OS). Wasn't there an effort, or talk about, to have Chrome do its own thing in Windows 8? This is why Material Design is important to Google. It targets the lowest common dominator, web browsers, and seems like it runs the same on a powerful computer or low-spec'd phone. While Material looks good, I feel that they may have held back a little because of browser limitations (you cannot do overlay blurring like iOS, for example).
Anyway, a lot of people love the common feel of apps across platforms. People seem to really like that about SublimeText and Chrome. I personally don't. I thought it was in poor taste when Apple made Safari and iTunes behave as if it were on OS X when running on Windows and I think Apple even had its on OS X-style update windows for the windows apps.
It's a fine line. As a developer Id rather code once and ship than to figure out all of the little idiosyncrasies for every platform. As a certain type of user I want apps to act like the other apps on my platform of choice, most users probably don't care or notice though.
I don't care much about native feel. When the things I like in a platform aren't preserved (cmd-comma for preferences), I get annoyed. When the things I dislike (OSX maximize) aren't preserved, I like it.
Overall, I think a little convention breaking is good. First, code once is a genuine advantage. It means faster releases across more platforms and more benefit to users. Second, it generates a little internal competition. If more apps break OSX maximize and users like it, maybe Apple will change it.
In the best cases, the freedom to invent the wheel yields gradually improving wheels.
Overall, I think a little convention breaking is good. First, code once is a genuine advantage. It means faster releases across more platforms and more benefit to users. Second, it generates a little internal competition. If more apps break OSX maximize and users like it, maybe Apple will change it.
In the best cases, the freedom to invent the wheel yields gradually improving wheels.
> In the best cases, the freedom to invent the wheel yields gradually improving wheels.
Except on mobile we have a bunch of reinvented wheels of varying non-round shapes and they all suck, leaving the user to guess what weird combinations of touching, tapping, swiping, double fingered tapping, etc will perform the desired action for this particular app.
Except on mobile we have a bunch of reinvented wheels of varying non-round shapes and they all suck, leaving the user to guess what weird combinations of touching, tapping, swiping, double fingered tapping, etc will perform the desired action for this particular app.
Call me strange, but I prefer the old maximize. It only took up what space was needed for the window to not scroll horizontally, but did a full vertical. This had a few advantages for me: 1. I can see, and interact with, all of the other windows that I have open in the bkg without too much context switching (command+click to interact without giving a window focus) and 2. since I have an ultra wide monitor at work (and a 27 inch iMac at home), full screening for a browser or text editor is wasted space when I needed reference materials open too.
Apple's own iTunes app breaks a lot of pre-defined ui behavior -- cannot double click titlebar to minimize, the strange mini-mode, and it doesn't quite respect the screen boundaries. I just prefer for things that I use often to have an expected, common behavior.
Apple's own iTunes app breaks a lot of pre-defined ui behavior -- cannot double click titlebar to minimize, the strange mini-mode, and it doesn't quite respect the screen boundaries. I just prefer for things that I use often to have an expected, common behavior.
Thanks for writing down your thoughts on this. I became an Android user first, and only after that I became a dev. As a dev, I ended up in some cases implementing apps with foreign design, and the user in me said 'Hey, this is wrong'. Of course it would be easier to code once, but, in my opinion, the user chose a platform for a reason. Also, I would like to point out that the design guidelines should be respected on every platform.
> you cannot do overlay blurring like iOS, for example
this may change in the future - the backdrop-filter CSS property should allow you to do exactly that, and support has already landed in chrome
this may change in the future - the backdrop-filter CSS property should allow you to do exactly that, and support has already landed in chrome
Nice, very nice. I remember years ago I thought that I could do gaussian blur by copying the transparent layer in photoshop and repeating the tile in html/css. I think html/css/js would benefit if it just recreated everything that flash could do 10 years ago. Is that whats happening?
There was a tweet about this today, thought I'd share
https://vine.co/v/OxmjlxdxKxl
https://twitter.com/_ryanmack/status/567795669848616960
https://vine.co/v/OxmjlxdxKxl
https://twitter.com/_ryanmack/status/567795669848616960
> Network data access costs a lot of money in some countries
Very much this. I live in a country which has country wide LTE coverage in populated areas. While the network is fast, data is very expensive. Here 1GB of data in a bundle is around 35 USD, where as back home I can get 25GB for the same.
I have mobile data turned off for most apps because of this. Everytime I open one (even if it works perfect offline) iOS pops up "Mobile data is turned off for XXX".
Very much this. I live in a country which has country wide LTE coverage in populated areas. While the network is fast, data is very expensive. Here 1GB of data in a bundle is around 35 USD, where as back home I can get 25GB for the same.
I have mobile data turned off for most apps because of this. Everytime I open one (even if it works perfect offline) iOS pops up "Mobile data is turned off for XXX".
In addition, there's a good point to be made about network access related to the previous point: network traffic means battery drain.
Thanks. In the past I downloaded some large files and I had to pay heavy money for them, so, as a developer, I will keep this in mind for a long time :)
I couldn't agree more with point one on the 'ow zone.' I really can't understand why since ICS, google insists on putting so many important UI elements at the top of the screen, even as screens are getting bigger and bigger.
That's right. I have a few more thoughts on reasonable screen sizes, maybe I'll write another blog post on that topic as well.
> Depending on your target audience, strive for accessibility, create layouts that can be used while e.g. driving, try to make your application adapt to the environment (for example mind the time of the day)
Spotify (at least the iOS version) does this both wrong and right.
When you browse for music, the app offers playlists based on the time of day. This is great, as the time of day has a lot of influence on the mood you'll want your music to convey.
On the other hand, player view got one thing wrong. In this view, you can swipe down anywhere to exit the player view - as the player is "minimized" when you're browsing for music. However, swiping down anywhere really means anywhere - even when you're trying to skip the current song, and your finger happens to move down a little (maybe because you're driving), it minimizes the player rather than skipping the song. The minimized player is a smaller touch target than the playback icons, which makes returning to the player view and ultimately skipping the song extra-hard.
Spotify (at least the iOS version) does this both wrong and right.
When you browse for music, the app offers playlists based on the time of day. This is great, as the time of day has a lot of influence on the mood you'll want your music to convey.
On the other hand, player view got one thing wrong. In this view, you can swipe down anywhere to exit the player view - as the player is "minimized" when you're browsing for music. However, swiping down anywhere really means anywhere - even when you're trying to skip the current song, and your finger happens to move down a little (maybe because you're driving), it minimizes the player rather than skipping the song. The minimized player is a smaller touch target than the playback icons, which makes returning to the player view and ultimately skipping the song extra-hard.
Thanks for the example. One of the motivations behind this article was to draw attention to the handedness of the mobile user and to the fact that the mobile user's attention is usually divided, the mobile user is usually 'multitasking' while using a smartphone. Under such circumstances, the user could easily miss a button that is not placed in the best location.
Spotify has a massive UX flaw.
To access the options for a track there is a button on the right hand side, this is also where the scroll menu appears. I often find myself half way up the playlist when I wanted to queue a song.
To access the options for a track there is a button on the right hand side, this is also where the scroll menu appears. I often find myself half way up the playlist when I wanted to queue a song.
On Android? That's where I experience this same infuriating problem.
At what screen size will the "ow zone" problem become moot because it's impossible to use a phone with one hand? Are we already there with phones like the Galaxy Note 2 and iPhone 6+?
If you double-tap the iPhone 6 home button, it moves the content of the screen down so you can reach it with your thumb.
That doesn't sound particularly discoverable. That sounds like a power-user keyboard shortcut for what should be simple functionality.
Most of the touchscreen functions are not discoverable. Pinch-to-zoom, long-press, swiping with multiple fingers, etc. It's very easy to do though, not what I would call a power-user thing. Remember there is only one physical button on the front of the device, and this is one of the things that it does.
Yes, I misuse "power user" to mean "someone who reads the fine manual" or "someone who does a websearch to learn about nice features".
At least for some features like pinch-to-zoom they included very clear examples in the massive ad campaigns. I don't remember seeing this feature in an ad but it wouldn't surprise me. At least it's on this page https://www.apple.com/iphone-6/design/
In my opinion Galaxy Note 2 is just too large for using it with one hand. Still, it has a comfort zone where you can reach UI elements with one thumb (either left or right), so maybe the developers should take this into consideration when designing layouts.
Sidenote: at the top is a "tl;dr" link to a summary of key points at the bottom. The link is a named anchor #toolongdidntread. When you click it, the page scrolls down to the bottom but the location doesn't change to the anchor. That means you can't hit "back" to get back to the top of the page.
It's just a small thing, but I find the cumulative weight of little touches that break basic browser functionality for marginal aesthetic reasons really start to grate on me.
It's just a small thing, but I find the cumulative weight of little touches that break basic browser functionality for marginal aesthetic reasons really start to grate on me.
Thanks for the observation. I'll fix this UX issue :)
True to your word. Nicely done. Thank you!
I haven't held a phone with one hand since 2011. I do mean that literally has I've owned a 5.1-5.2" phone since then. Therefore don't use my thumb to interact with it at all.
The whole "The 'ow' zone" section assumes small phones, small hands, and right handed users.
The whole "The 'ow' zone" section assumes small phones, small hands, and right handed users.
Just because you don't doesn't mean that nobody does. Ever tried to use a phone two-handed while holding onto a subway pole? Or walking home with groceries? Or holding your kid's hand?
> Just because you don't doesn't mean that nobody does.
The article claims though that everyone does which is what I take issue with.
The article claims though that everyone does which is what I take issue with.
> The reason behind this term is that in many cases Mobile Users hold their device with one hand, and perform actions using their thumbs.
Many, not all. It's enough of a problem for enough people that developers should pay attention to it.
Many, not all. It's enough of a problem for enough people that developers should pay attention to it.
The standard android and iOS navigation controls are directly within the "ow zone". Application "up" in the top left, system "back" in the bottom left. App switcher in the bottom right. The "go/search" button on the keyboard, bottom right.
Article is fine, but:
One of the worst examples for the "above the fold" image: a) it is pixelated like crazy and to big to comfortably read its contents, b) the headline is really hard to read and find, because it is white text on a background of white text on black...
One of the worst examples for the "above the fold" image: a) it is pixelated like crazy and to big to comfortably read its contents, b) the headline is really hard to read and find, because it is white text on a background of white text on black...
Thanks for pointing that out. I will change it to something that fits better.
The part about Android actually applies to all mobile operating systems - they would all rather you'd use their native UX language than invent your own.
That is correct, the user is used to a platform's behavior, and, in my opinion respecting the native UX language will keep that specific platform's user happy.
The image that goes along with this point demonstrates the areas that are hard to reach for right-handed users, ignoring that ~10% of people are left-handed and have trouble reaching the opposite corners. Your design shouldn't assume that two particular corners are bad and the other two are fine, all four corners should be used for uncommon options only.