–UPDATE: Hello readers of Marco’s blog! I’m John Kneeland and enjoying my 15 minutes of fame. Feel free to follow me @SirKneeland on the Inter-twits.–
Apple’s iPhone wasn’t the first touchscreen portable device, but it was the first one that didn’t make you want to stab yourself (or the device) with its stylus. One of the many reasons for this was that they were the first big company to realize that a touchscreen should not simply take desktop metaphors designed around a mouse and cursor and shoehorn them into a tiny touchscreen being used with your fat fingers.
One of the most obvious ways in which this is apparent is the replacing of small tiny buttons designed to be hit with a fine point (a cursor or stylus) with much larger buttons that can be accurately tapped with a finger.
Except, of course, for when Apple simply shoehorns desktop metaphors into a touchscreen:
I hope you brought your stylus...
The most egregious example of this interface inconsistency is in the teeny tiny close buttons that pop up on the iOS interface when you want to close apps in the app switcher, delete apps from the homescreen, or close a browser tab. it’s even worse in Apple’s new iOS notifications system, which decided being hard to use wasn’t enough and it should be hard to see as well.
Now featuring low-contrast colors for added inconvenience!
Naturally, since iOS made this mistake, Google made the same mistake when copying iOS designing Android.
Apparently great artists steal bad ideas, too.
In fact, the Android one may be even worse than the iOS one because while the iOS button is located halfway outside the window object’s border and thus catches the attention of the mind that identifies these jarring aberrations in shapes, the Android button is completely nested in the window.
How to avoid using the close button then? People still need to close things after all. I think there are two valid methods. In increasing order of awesomeness, they are: holding down for a contextual menu (exemplified in Windows Phone 7), and swiping away to dismiss (exemplified in webOS).
CONTEXTUAL MENU
Well MS stuck with the teeny tiny close button in their browser windows, they have made a great contextual menu system in other areas, such as app management on the homescreen: Hold down your finger on something, and a contextual menu of actions pops up.
This successfully avoids the problem of having the teeny tiny close button. It also is potentially extensible as it allows for a large number of relevant contextual choices (for example, archive vs delete in Gmail). but runs the risk of replacing the teeny tiny close button with a teeny tiny text menu and leaving it open for the user to accidentally select the wrong contextual option. It also can wind up being used by app developers as a lazy catch-all for actions, leaving users with too many options, rather than forcing the developers to spend more time thinking about minimizing complexity and putting these other options elsewhere.
SWIPING
Swiping things away is, in my opinion, the most natural way to dismiss things as it is the most similar to how one might get rid of things in the physical world–toss them away!
- Just swipe it away. No teeny tiny buttons required!
Of course, swiping has some problems of its own in terms of extensibility (it has none) and discoverability. In a few years the average user may be sufficiently ‘trained’ in expected touchscreen behaviors to know to try swiping, but for now any system using a swipe gesture should be sure to educate their users on the availability of swiping, ideally on device first-run.
Bottom line, to paraphrase Steve Jobs, is this:
if you see this button:
They blew it.
It should really be called the “blew it button.” I want to see a touchscreen OS that doesn’t have a single one of these (and unfortunately webOS added them in 3.0 for deleting apps on the homescreen). It’s one of those rare cases in which I can say Palm should take a lesson from Android and look at how removing an app from Android’s homescreen involves dragging an app to the trash:
Now THIS is how you delete an app!
John vs. Internet 
Deleting apps from the TouchPad launcher like on a webOS phone…..do we have a patch for that?
You need a certain hardware button for that.
pass this to the UI guysof the webOS launcher:
tap and hold makes a trash bin appear on the screen, moving icons to the screen deletes them.
I 90% agree. Swiping off-screen instead of a close button is far better. The one exception is when moving items around on the screen. I think WebOS got it right with including the close button in that case, just like they got it right with the swiping off-screen in the first place. I’ve used the Android method as well with my old phone, but I find tap-hold-drag to be very awkward. Tap-hold-tap however is super easy.
I would also like to point out that the only webOS device with these close buttons are TouchPads, and that’s due to the lack of a hardware key to change the screen tap behaviour like the phones.
I also think it’s acceptable to have a close button on a tablet because screen real estate isn’t an issue so if the button can be made large enough that fat fingers aren’t an issue either.
I don’t think so because the phone method relies on having a physical keyboard with the orange/gray secondary function button. That’s one thing webOS didn’t get right, alas!
While I agree, the X button on the Publisher dialog for incredible! ain’t goin’ anywhere.
Both of your recommendations have no affordance on the screen.
How about “make the close buttons bigger”?
I know it’s cool to paraphrase Steve Jobs, but the main argument is that the close buttons are tough to see or touch. Replacing them with an invisible gesture (tap and hold for a context menu, or swipe to delete, or drag to the trash) isn’t all that helpful to users who don’t know that gesture is available.
That’d be nice. Actually that gives me an idea. TO THE PHOTOSHOP!! (well, if I had Photoshop 😉 )
Lee speaks to a larger point. As long as contextual menus are brought up via tap-and-hold, they slow down work flow. MS is very clear about this — in their touch design language for Metro they make a big deal about using alternatives to the contextual menu as much as possible so as not to slow down interaction.
It doesn’t have to be this way, of course. There could, for example, be a chording button on the side of a device that gives instant “right click” when used with a tap. But as of today, contextual menu = tap-and-hold = delay, and it’s a PITA.
Completely agree. Tap and hold slows down the workflow and “flick offscreen” might look cool, but I bet it’d get old real quick.
Also, whilst the existing close buttons are small, ill bet my bottom dollar that the hit area is greater than the visible button. I’ve never had a problem hitting it, and I have stupid fat fingers!
Try tapping near the close button on a Safari window. Chances are it will correctly interpret your intent. There are buttons all over iOS that have a touchable area that expands beyond the borders of the visible button. I’m surprised you didn’t touch (hah!) on this.
nice pun, and a good point too 😉
Agreed with @Lee. Never underestimate the need for discoverability in UI design. The tap and hold/swipe methods you suggest are good secondary shortcuts, but the primary interface for such critical functions needs to be visible.
Bigger targets is the easiest solution. Although it’s worth mentioning that the tappable areas for many of the small buttons in iOS are actually quite a bit larger than the visible button boundaries.
Wouldn’t it be nice if users could have a choice? X buttons for noobs, swipe actions for the advanced gesture-happy.
I can’t say I agree that they blew it, at least in the case of the Mobile Safari tabs view. Sure, the close button seems legacy, but it has none of the drawbacks that would make it unsuitable for the task: it’s entirely discoverable, it’s intuitive, it’s familiar, and contrary to what you’ve said in this post, the hit target is actually quite large. The tab view is designed the way it is — with low information density — to allow for a hit target on the close button that is pretty close to 9x the area of what you actually see. Tap a little above or below, left or right of the circle, and the tab will close. It’s a huge hit target. Just because you’re only seeing a small button doesn’t mean you’re gonna have to target it with pinpoint accuracy.
The notification sheet is similar, but since the “x” button is so snug against the right edge, the hit target is only 4-6x larger than the button image. Tap a little above or below, or to the left of the “x”, and you’ve hit the target. It’s certainly more fiddly, but in my two months of usage, it hasn’t actually failed me once.
On a UI-related note, you may want to take a closer look at the iPad-specific theme you’re using on this blog. The scroll-view-within-scroll-view that happens when posting a comment seems to prevent the default behavior of tap-hold to move the cursor or get the copy/paste popover. So I can’t go back and edit, nor dismiss spelling suggestions, nor copy my post before hitting submit (I hope it doesn’t get lost).
There’s an iPad-specific theme??
The problems with the comment posting text area extend beyond iOS: its automatically-growing-height behaviour in response to additional typing is kinda broken on desktop browsers, too.
Specifically, in the ways it responds to events that push it beyond the preset “maximum allowed height”. If you paste a block of text that would push it beyond that height, it pops up a scroll bar while keeping the current (small) height the same. Whereas if you actually typed out that block of text, it would gradually increment the height up to that maximum, and then keep it there when resorting to using a scroll bar. Similarly, there’s perhaps some weirdness if you’re not typing at the end of the entered text — it fails to evaluate its need to grow in height in the correct way.
While typing another comment, I somehow managed to get it into a state where the text area was at max height, but it was still refusing to show a scroll bar. (Only way to scroll the text was through carat movement.) While typing THIS comment, I somehow managed to get it to do the opposite: it’s now insisting on displaying the scrollbar and setting the still-growing height to a line or two less than what is actually needed to display what I’ve typed. Argh. I suspect the theme’s JavaScript/CSS is second-guessing the height needed to show the text but getting the calculation wrong from a failure to acknowledge that showing the scroll bar eats into the effective WIDTH of the text area, which in turn ALTERS the word-wrapping inside the paragraph, and it turn can alter its height by a line, creating a mismatch that can grow with the number paragraphs.
Who said the close button in mobile safari needs “a fine point”?
I never had a problem hitting it with my fat old fingers. Could it be because the target is actually larger than the icon area (i.e somewhat around it also)?
In any case, it is big enough as it is –and it’s also alone in where it stands.
Which somehow makes all the Job’s paraphrasing irrelevant.
Yes, and it works very well. It’s a testament to Apple’s awesomeness that they think to make the actual target larger than the button.Be that as it may for the Safari buttons, it’s definitely not true for the Notification Center’s X buttons, which are neither big enough nor “alone in where they stand.”
Could it be that delete and close buttons are difficult to touch on purpose? Those buttons invoke potentially destructive actions, and should require the user to be sure of wanting doing that. Avoiding accidental trigger might be the guiding principle.
Swipe to delete already exists on Mail in iOS and other apps with lists, but still requires a further confirmation to delete. If deleting and closing something is too easy, you need to implementate undo actions for it, adding another GUI problem to solve. In iOS devices there is not even a trash for recovering a file or an app you deleted by accident.
Except… It’s NOT a close button. Not in iOS anyway. X may mean close in Windows, but in iOS you’ve shown DELETE buttons. It’s not a common operation. The close button is the physical home button. Yes, that doesn’t actually quit the app, but you’re not grokking iOS here… why worry about whether the app is really resident in memory? iOS doesn’t let it consume battery. And on the iOS app screens, it’s a DELETE button.
Also I’ve never never ever had trouble hitting the buttons when I needed to. Probably good heuristics determining when a touch is “close enough.”
Haven’t used iOS 5 not notifications yet though, so can’t comment on that.
But even there, it’s not a close button.
Well then boy are you in for a treat with the iOS 5 notification system 😉
Worth noting that using the verb “close” in this fashion is a product of the “window” metaphor. (Prior to that, you ran programs, rather than opening them.)
Personally: Never had a problem with the Safari tab / Home screen style “delete” buttons, but I have on several occasions been frustrated by the “clear this text field” buttons. Somehow I find them both too easy to hit accidentally and too hard to hit intentionally.
And then there’s the aggravating issue with the text box on Google search result pages: Google’s mimicking that native behaviour themselves inside the web form with some JavaScript trickery, and it completely messes up the iOS text selection. If your search terms extend beyond the right edge of the field, it’s practically impossible to move the carat beyond what is displayed, to see/modify/add to the stuff on the end. Which, in my experience, is by far the most likely portion of the search terms that I will want to modify, but placing the carat there is never the default. Arggh.
Apple at least gets that last part right: when you open Mobile Safari’s search field, if there’s a previous search entered, it defaults to placing the carat at the end. They nearly do the same for the URL bar, but without placing the carat — the (correct) assumption being that you’re more likely to want to type something completely new rather than modify the end of the current URL. The problem is that if you DO want to modify the current URL, you’re likely to want to place it at the far right … which is right next to that damn clear button! A clear button that’s quite redundant when the default response to typing is to clear the field and start fresh.
As an FYI, the example you give of Google using the close button doesn’t seem to be from stock Android and therefore was not designed by Google. Wild guess that it’s from the browser on Sense UI phones? Correct me if I’m wrong…
(P.S the stock browser still uses a close button, but it is very large and easy to click, and does not overlay)
That was taken from my Galaxy S so it’s quite possible it’s the work of Samsung’s TouchWiz team…if you want to donate a Nexus S to me so I can further research I won’t mind 😉
Must be TouchWiz then, which also explains the weird colors. I don’t have a Nexus S to give you, but if you want I can send you a screenshot from my Nexus One.
sure, go for it!
I thought your name was familiar 🙂 I just told Ramanan about this post.
That’s not how you delete apps in android. That only removes them from the homescreen. You have to go to menu, manage apps, wait for the app list to load, select an app, click uninstall, confirm. Clunky and terrible system. Tested on Nexus S.
Well that does explain the otherwise incongruous instance of ease-of-use in Android 😉 Thanks!
Minimum button size per UI guidelines is 32×32. This works well. Even if the button looks smaller, this is the area. Discoverability is still very important.
Having said that, gestures are much more natural and far more space efficient and I use them in my development perhaps too much. The problem is that you need to add a button that let’s the user discover them. Ah, catch 22 🙂
P.S., jeez I hate OnSwipe. Turn it off!
This reminds me of that episode of the Simpsons where Homer’s fingers are too fat to dial the phone.
“please mash the keypad with your palm now”
Amen to this post, I mean my index finger is 3/4″ wide, there are apps with buttons just a few small millimeters in size.
If you see someone make a blanket statement and expect it to be true all the time…
…they blew it.
The small tiny [sic] put-away x buttons in, say, iOS’ version of Safari function quite well, and are unambiguous in their function (an area where many more, by far, interface designers blow it; e.g.: Facebook in its entirety). The reason it works well there? There is nothing else close to it. While the Incredible Hulk might have trouble with this x button, Bruce Banner wouldn’t.
A better critique of the Teeny Tiny Button Fail would be to point out failure to make use of whitespace in touchscreen interface design.
But to tout contextual menus in handheld touchscreen design: unforgiveable. They are hard enough to navigate on mouse-driven interfaces. If you want headaches, go down that path. There lies madness.
I still think contextual menus, when done properly (and I think WP7 is much closer to that than Android), are great. The system of menus in the Emblaze concept phone are even better (and I’m happy that the man behind that now works at Palm).
But thanks for your input! And I would agree that the implementation of the teeny tiny close button in Safari is significantly better than the same button in the Notification Center, which fails at having “nothing else close to it”
“But to tout contextual menus in handheld touchscreen design: unforgiveable. They are hard enough to navigate on mouse-driven interfaces. If you want headaches, go down that path. There lies madness.”
You understand that iOS uses contextual menus all the time? That’s what the cut/copy/paste system is.
The worst close/quit/delete/clear button I’ve seen on the iPhone (including the Notification Center, which works fine for me, btw) is Google’s search field on the web. You type, and it redraws the page, and the search field has a little X in it to clear what you’ve typed, but it’s impossible to hit, and the entire search field becomes unusable because it’s crammed up against the top of the viewport so you can barely hit the x to clear the field, and it’s too close to the edge to properly select text (or something else is wrong) so selecting/erasing/editing what you’re searching for is next to impossible. I’d rather go back up to Safari’s window chrome and use the search field there instead.
/rant
I’ll drink to that. Thanks for your input!
Hehe, I posted an earlier comment where I accidentally wound up ranting about this exact same thing. Google needs to realize that this is a case where their current, poor implementation is worse than not having the feature at all.
hrmm interesting. I agree entirely with your point, but I’ve never had much of a problem with hitting those buttons.
Your WordPress theme also has close buttons on the iPad. And what’s worse: if you come in via a link to this article, then take the navigation button to your home screen, and then click on your Steve Jobs article and then use the mentioned close button and then try to reopen this article, ( sorry for long sequence) it is unopenable because it closes itself each time you try to open it.
At least, that’s what happens on my iPad with iOS 5 beta installed.
Horrible 😉
John, I think there is a need to explain the necessity of the close button within Notification Center. It is exactly that: a notification center. To alert and inform you of little bits and pieces of information. Most of the notifications require some kind of action to dismiss, so that means most of the time you will be tapping on, say, a new email. Then that notification will dismiss itself. Knowing that, I think that the system will be dismissing more notifications more than the users will be closing notifications him/herself. It’s not the same as closing Safari pages, which are in a total another realm of interactivity and also do not have the opportunity to close themselves.
I think a bigger issue, and one I hope they address in a future update, is the double-tap for accessing the app drawer/quick app switching. What a waste! If they are to designate a certain row of pixel(s) on the top of the screen to access the Notification Center (it slides down as the movement of the finger does), then it ought to be that when swiping up from the bottom will bring up the app drawer. How many times a day do we tap the home button to do access that functionality? Too many times. Note that swiping up from the bottom pixels while the Notification Center is open will bring the Notifcation Center up.
Let me know your thoughts, thanks.
I prefer close buttons in mobile Safari.
The actual clickable area is much larger than the button graphic, closing (or deleting, as someone pointed out correctly) a tab or application this way is discoverable and familiar from former experience on other OS and it requires fewer and easier actions from the user.
With the close buttons, you can tap a number of browser tabs or applications in delete-mode *shakeshake* and just have to move you finger across the app grid (or not at all, if you want to delete apps that where following in the grid after the one you deleted first).
With a context menu, you would have to touch each app two times, first to open the context menu, second to delete the app – and possibly a third time to confirm deletion.
Using gestures or a trashcan on the UI would require you to flick the app in some direction with you finger or drag it to the trash.
The requires moving you finger around, becoming tired if you have to delete a larger number of things and dragging apps around on the iOS homescreen really sucks (sorting apps on your iPad etc).
Google Chrome features an awesome detail while closing tabs, the close-button stays at the same spot until you move the cursor away from the tab-bar.
This way you can close dozens of open tabs without moving the mouse, you may never notice this great function when using Chrome, but you’ll totally miss it, if you have to use Firefox again later, where you have to move the mouse after closing each single tab.
The close button in iOS kinda works like closing tabs in Chrome, having a gesture to close or delete applications, which you maybe have to do a few times in a row, is like going back to Firefox.
Pingback: Apple aiming to improve iOS notifications further with fresh talent – JailBake
I can see a lot of people swiping their pages away into oblivion by accident using that Web OS method. Maybe that’s why Apple didn’t institute it.
Pingback: Apple aiming to improve iOS notifications further with fresh talent |
thanks. was looking for something like this