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.

July 10, 2012

What’s changed in iOS 6

Filed under: Apple,Interfaces,iOS,Mobile — admin @ 9:27 am

Jurajivan has put some slides together showing what’s changed in the iOS 6 user interface.

I haven’t yet interacted with the new OS so can only go on the screenshots in this deck (and from elsewhere around the interweb) but this feels like a Marmite update to me: there are aspects that I love (the revamped bottom tab bar treatment) and aspects that I hate (the top menu bar taking the colour of whatever app is open).

Something else that struck me as I browsed these slides is that iOS seems to be going away from the shiny style UI that’s been present since it’s inception and moving towards a more subtle gradient approach, just like Mac OS X did. Mac OS X 10.1 was uber shiny, whereas 10.8 has a much subtler look.

If this is the direction iOS is moving in, I wholeheartedly approve.

April 12, 2012

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’.)

November 23, 2011

Susan Kare’s Sketchbook

Filed under: Apple,Design,Interfaces — admin @ 9:25 pm

An intriguing insight into the sketchbook of Susan Kare as she was developing the original Mac icons. All hail checkered sketchbooks.

Fascinating and delightful. And I did not know that the ‘command’ symbol (⌘) was meant to be a castle as viewed from above.

November 4, 2011

A Great Tip for Giving Feedback on UI Details

Filed under: Design,Interfaces — admin @ 6:12 pm

As some of the commenters have pointed out, this method of illustrating differences in spacing between an element is very Edward Tufte.

October 14, 2011

Siri looks really well thought out

Filed under: Apple,Geekery,Interfaces — admin @ 5:00 pm

Through sites like this and this I’m beginning to think that Siri — the new ‘personal assistant’ on the iPhone 4S — is incredibly well done. Those sites — whilst humourous — illustrate the breadth of things that Siri understands.

Whilst Scott Forstall demoed it well during the keynote, he obviously didn’t touch on everything it could do. It looks like there’s much more to explore.

My favourite at the moment is this one.

Powered by WordPress