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.

June 8, 2012

Cheating or good design?

Filed under: Apple,Design,Experiential,iOS,Mac OS X,Software — admin @ 10:25 am

Dmitry Fadeyev on a clever technique used by iOS when switching apps:

[…] when you switch apps, the device saves a screenshot of what the last screen looks like for that app so that when you switch back again, that saved screenshot is the first thing you see. This is done to buy time for the app to fully load.

A commenter on this post notes that this technique is used in other interactive systems and is documented in Jef Raskin’s “The Humane Interface: New Directions for Designing Interactive Systems” (something I cannot verify as I do not own the book).

Somewhere else I’ve noticed this technique being used is in Safari on Lion. Within Safari there’s a gesture that does the same as the ‘back’ button – swiping left to right with two fingers takes you back to the previous page you were looking at. There’s a big visual clue that this is happening – the page you’re currently on moves over to the right to reveal the page you’re going back to ‘underneath’. This technique is also used to replicate the behaviour of the ‘forward’ button in Safari, it’s just the gesture (right to left) and the visual clue (next page slides in from right to left) that differ.

The page that you see ‘underneath’ looks to be an image of the page, rather than the page itself. What’s more, it looks to be a badly compressed image. This is very apparent when you look at a site with lots of links rendered in small point sizes. The best example I’ve found is the Autosport website.

A screenshot of the Autosport website

This is the Autosport website as rendered by Safari. If you navigate away to a different page and swipe to go ‘back’, here’s what you see:

Swiping left to right to go 'back' shows a badly compressed image of the previous page

Look at the compression, particularly around the smaller blue links. If you’re not getting it, here’s a closeup of the Autosport website as rendered by Safari:

Close-up of the Autosport website

And here’s what Safari shows if you swipe to go back:

Close-up of the badly compressed image of the Autosport website

Look at all the noise in the graded boxes at the top and around the blue text links.

So it seems Safari is using the same technique as iOS here, showing an image – a badly compressed one – of the previous page for immediacy and speed.

In this case the technique falls down a bit, partially due to the compression giving the game away but also because there’s a very obvious visual ‘jerk’ when the actual HTML renders back in.

Powered by WordPress