jammylammy Just another WordPress site

March 21, 2014

The Frustration of iOS Banner Notifications

Filed under: Apple,Design,Experiential,Ideas,Interfaces,iOS,Mobile,Usability — admin @ 5:18 pm

Sagi Shrieber has written a thought-provoking piece on his annoyance with iOS notifications, offering some suggested improvements as to how notifications appear and how users might interact with them. The whole piece is worth a read but the basic jist is:

  1. Too often, iOS doesn’t get it right when you try to dismiss a notification by swiping it off the top of the screen. iOS interprets this swipe as a tap, taking you away from your current task. (I believe that you actually have to tap & hold the notification, drag it down a little then ‘throw’ it off the top of the screen to dismiss it — not easily done.)
  2. Because of the inherent clumsiness of the dismiss gesture you might opt to just ignore the notification instead and carry on with what you were doing. However, the position of the notification banner over the top of your currently-running app’s UI means that some of the controls of your current app are obscured for the duration of time the notification persists.

So when a notification arrives that you’re happy to ignore, you’re too afraid to swipe up and dismiss it because of the first issue yet you cannot really ignore it because of the second.

Sagi offers a couple of solutions to these issues:

  1. When a notification arrives, pull it down to show the necessary interface to deal with the notification. Once dealt with, swipe up to ‘put away’ the notification and return to where you were. (Note: Sagi’s initial sketch shows this swipe up feature, but his mockups do not seem to demonstrate it).
  2. Position the notification underneath the currently-running app’s titlebar, thereby keeping relevant UI and/or controls relating to the currently-running app visible and usable. So if you want to ignore a notification and keep doing what you’re doing, you can.

Whilst I love seeing other people’s ideas on improving already well established UIs (I’ve done it myself), I can’t help feeling that these suggestions overcomplicate notifications, their associated interactions and app hierarchy within iOS. A banner notification is designed to notify you of something in way that’s unobtrusive, along with offering you a way of ‘doing’ something with that notification — including dismissing it or ignoring it. In a nut, notifications should be simple, obvious and easy to act on or ignore.

Sagi’s piece focuses on a Whatsapp notification interrupting his use of the Homebudget app, so let’s keep going with that scenario here. I have a few questions on Sagi’s suggested improvements:

  • When I pull the notification banner down to load the Whatsapp interface, am I in the Whatsapp app or still in Homebudget? This is important when considering how I exit the Whatsapp interface to get back to what I was doing in Homebudget.
  • Considering the above, how do I get back to Homebudget? I want to be able to slide it back up to get back to Homebudget — the reverse of what I did to get into Whatsapp. If I can do that, where’s the affordance in the Whatsapp ‘sheet’ to tell me I can do this? And if I can swipe up to dismiss the Whatsapp interface, how will iOS know whether I meant to dismiss the Whatsapp interface or whether I wanted to invoke Control Center, also available by swiping up from the bottom of the screen?
  • If I can’t swipe the Whatsapp UI off the top of the screen to get back to Homebudget, how else do I get back? Double-tap the home button to show recently opened apps and select it from there? How is that any less annoying than what happens today?
  • Because the notification now sits within the content of the currently-running app — underneath the title bar — how will iOS know whether I’m trying to dismiss a notification or scroll? Granted, this is a challenge that applies to the current implementation of notifications (and is, perhaps, a reason why dismissing them is so hit & miss).
  • Is showing the notification underneath the title bar really a better solution? Whilst it avoids obscuring any controls residing in the titlebar, it’s still sitting over the top of content I was looking at. A notification over the top of a photo you’re about to post or a tweet you’re about to send is still in the way. (In either of these two scenarios, I’d most likely try to dismiss the notification before continuing with what I was doing, regardless of whether it obscures content or controls. It’s still in the way.)

I completely agree with the issues Sagi highlights. Dismissing a notification is currently a game of pure luck; the number of times iOS has misinterpreted a dismiss gesture for a tap is far larger than the number of times it’s been able to get it right. But as I was reading Sagi’s piece, it struck me that perhaps a better interaction model for notifications already exists in iOS: those that are shown on the lock screen.

A mockup of an iOS banner notification being swiped to the right

What if, when I receive a notification, I were able to ‘action’ it (read, reply, post etc.) by swiping the icon to the right, as I do on the homescreen? This would take me off to the app that invoked the notification. It’s fairly safe to consider this gesture as something relatively ‘bullet-proof’, in that there’s no mistaking what I want to do if I swipe.

Tapping the notification would therefore do nothing. Swiping to dismiss the notification would therefore be a whole lot more accurate.

Also, what if we let iOS assume that when I receive a notification but carry on interacting with the currently-running app, that I do not want to action it just yet? The notification arrives, I continue tapping or scrolling in the app I’m in, so iOS hides the notification as I’ve made it clear I’m in the middle of something. If I do want to do something with the notification, I can pull down Notification Center to see it and action it from there.

We could take this further and say that swiping an icon invokes an ‘inline’ or contextual interface to let me action it, much as notifications on the desktop in Mavericks does. The notification arrives, I swipe the icon, but instead of taking me to Whatsapp, I get a modal box (like the one Sagi mocked up in his piece) that lets me reply to the message without taking me out of Homebudget. Importantly, it would also let me ‘cancel’, so if I changed my mind and didn’t want to reply immediately, I wouldn’t be forced to do so by a limited UI.

To me, these interactions fit with the notion and purpose of banner notifications much more comfortably.

Sagi’s post really resonated with me and sparked a lot of internal debate, so none of my comments or questions are meant as a negative critique of his original point and subsequent ideas. I wholeheartedly share his frustration with iOS notifications and refuse to accept that there’s not a better way of doing them.

Perhaps that’s why, after reading his post, these ideas have been tumbling around my head all day.

Thanks for the inspiration, Sagi!

June 19, 2013

Michael Heilemann’s Thoughts on iOS 7

Filed under: Apple,Design,Interfaces,iOS,Usability — admin @ 2:01 pm

Michael Heilemann has some thoughtful posts on some of the UI changes in iOS. I’m posting them here primarily because they make a lot of sense to me but also because I want to see how the final product compares to the Beta.

I haven’t used iOS on any device — I’m not part of the developer program — so only have critiques like Michael’s to go on. It appears that there are some fundamental changes to how you interact with the OS that seem careless — even thoughtless. As Michael says:

However, when I look at a beta I see anti-patterns and basic mistakes that should have been caught on the whiteboard before anyone even began thinking about coding it. I get scared. This isn’t a matter of ‘oh, it’s a little glitchy now and then’; these are things that from the looks of it seem simply like poor design decisions.

Here are the things I see as issues with the iOS 7 Beta. It’ll be interesting to see which ones are resolved by ‘this fall’.

  • Circles for signal strength — as Michael and many others have said, this breaks a fairly widespread standard, takes up precious horizontal space, uses the same UI element as pagination and seems to be solving an issue that just doesn’t exist for many users — we all know what those bars at the top of our phones mean.
  • Affordability of controls — I see lots of ‘text as buttons’ in the iOS screenshots I’ve seen. How do I know whether something is a label or a control? And, as Michael says, what issue is this trying to fix? Seems like minimalism for the sake of it.
  • Swipe right on the whole lockscreen — this one shocked me the most. Apparently, you can now swipe right anywhere on the lockscreen and it’ll unlock the device. This doesn’t seem pocket-friendly at all. I also wonder how much of an effect the removal of the UI controls for this gesture will impact the usability & obviousness of the gesture. For example, my 15 month old daughter is able to unlock an iOS device. She knows that by moving the drag handle near the bottom of the screen to the right, the device unlocks. All the affordance that informs & reassures her about this gesture is gone in iOS 7. It’ll be interesting to see if she can still unlock my iPhone when I install the OS later this year.

Yes, yes, it’s a Beta, there are bound to be some glitches. And there’s plenty of time to fix & improve before the OS is released. But I have to agree with Michael — some of these things are just bad design decisions.

I’ll revisit this post in ‘the fall’. Or Autumn, as we say around these parts.

October 23, 2012

Rethinking the App Switcher

Filed under: Apple,Design,Usability — admin @ 9:47 pm

Earlier this month, this redesign of the iOS app switcher garnered a lot of press.

I love almost everything about this idea with the exception of one thing: by using screenshots instead of the app icon I find it much harder to figure out what the apps in the switcher are.

iOS has always used icons to represent apps. The recognition of these icons is key to identifying apps, both on the homescreen and in the switcher. By using screenshots of the apps instead of icons, that link is lost and, for me at least, any benefit in seeing what state an app is in is far outweighed by the additional cognitive load placed on me to try and identify an app.

Yes, the name of the app is shown underneath the icon. But for sheer glance-ability, and for me, icons are a much better solution.

April 30, 2012

A nice take on proving you’re a human

Filed under: Design,Experiential,Usability — admin @ 10:43 am

A refreshingly different way of proving to a sign-up process that you’re not a machine.

A form of captcha that asks you to drag a symbol into an area to prove you're not a machine

April 12, 2012

Nielsen’s view on the mobile web

Filed under: Mobile,Opinion,Usability — admin @ 4:38 pm

Josh Clark takes Jakob to task for his latest alertbox:

There’s a persistent myth that mobile users are always distracted, on the go, ‘info snacking’ in sessions of 10 seconds. That’s certainly part of the mobile experience, but not the whole story.

Totally agree with Josh.

Nielsen has always presented his research as gospel, with little thought or consideration for context or changing trends. See, for example, his thoughts on using tabs as a navigation device. Granted, this is from 2007 but tabs have been used as a method of primary navigation for some time — certainly for a period that began pre-2007. Nielsen cites Amazon as an example (but notes that they ‘recently abandoned’ the tab design). I also remember the Apple site had lovely, shiny, lickable tabs.

To dismiss a common use of tabs as ‘incorrect’ because of a narrow notion of what tabs actually represent strikes me as a rigid and myopic viewpoint. Web interface design is an ever evolving discipline. Trends emerge. Things change.

Would ‘pull to refresh’ ever have happened if we all thought like Nielsen?

Browsers could be more helpful

Filed under: Interfaces,Usability — admin @ 3:06 pm

Speaking of software being a bit more helpful when it comes to common errors, I often mistype URLs which leads my browser of choice (Safari) to throw up the following message:

Safari's standard 'cannot find server' message

I find it mildly infuriating that Safari doesn’t offer more help here. If you mistype a URL in Chrome you get a Google-like “Did you mean:” suggestion and a Google search box.

Why can’t Safari be similarly helpful? If it’s clear I’ve mistyped a URL I’ve visited before, tell me.

A revised message with some more useful links

(Yes, I was trying to visit the Mothercare website. When you get one of these, your browsing habits tend to include such places.)

Sebastiaan de With: Prevention is better than cure

Filed under: Ideas,Interfaces,Usability — admin @ 2:42 pm

Sebastiaan de With has an interesting take on reworking email bounceback messages:

That email I got back was apparently because my attachments were too large. I can barely read that email — let alone my grandmother. Machines can read it just fine, though. Here’s an idea: machines shouldn’t slap us in the face. They should help us along if they fail to do our bidding.

Sebastiaan’s proposal takes the standard ‘undelivered email’ bounceback message and reworks it to be more user-friendly. If I were to receive one of these emails I would better understand why my message failed to be delivered but I’d still have an undelivered email.

To me, the problem here isn’t that people don’t understand email bounceback messages, it’s that they’re receiving them in the first place. What if our email software could pre-empt these kinds of errors based on things we’ve done in the past?

A mockup of a dialog box alerting the user that there might be problems with the email they're about to send

So if I’ve previously tried to send large attachments to this email address that have bounced, perhaps my email software could warn me that the same thing might happen again?

(Yes, I know — this might work for situations where attachments cause email delivery failures but wouldn’t necessarily work for other errors such as ‘host unreachable’.)

April 5, 2012

When the limitations of your backend system negatively affect my experience

Filed under: Experiential,Usability — admin @ 5:08 am

An error on an input field telling me to remove the spaces from my telephone number

Spaces in numbers help us memorise them and we naturally type phone numbers with spaces in them.

If your backend system can’t handle spaces, write some code to strip them out when the form data is submitted. Don’t burden the user by asking them to input data in a way that doesn’t match their mental model of that data.

November 23, 2011

The Cloze Test for Reading Comprehension

Filed under: Content,Usability — admin @ 10:23 pm

A colleague mentioned the Cloze test today, something I had not heard of before. In a nutshell it’s a method by which you can assess the suitability of copy for particular digital environments.

Jakob Nielsen has a useful overview of the technique:

  1. Replace every Nth word in the text with blanks. A typical test uses N = 6, but you can make the test easier by using a higher N value.
  2. Ask your test participants to read the modified text and fill in the blanks with their best guesses as to the missing words. Each person should work alone.
  3. The score is the percentage of correctly guessed words. Because you’re testing comprehension rather than spelling skills, synonyms and misspellings are allowed.

If users get 60% or more right on average, you can assume the text is reasonably comprehensible for the specified user profile employed to recruit test participants.

Of particular interest to me was the difference in meaning between ‘readability’ and ‘comprehension’ regarding the copy being tested.

Here is an example of the technique. (I scored 100% but had to remind myself that it simply meant the copy being used was comprehendible, rather than indicating that I was a literary genius.)

November 22, 2011

An Interesting Take on Verification

Filed under: Experiential,Usability — admin @ 6:45 pm

Came across this interesting verification text as part of a sign-up form today:

Human verification

(I entered ‘electronic calculators’. Worked just fine.)

Older Posts »

Powered by WordPress