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!

July 11, 2012

Making changing your desktop on Mac OS X easier

Filed under: Apple,Experiential,Ideas — admin @ 3:13 pm

When changing your desktop image in System Preferences, wouldn’t it be great if all the windows you had open moved out of the way, like it does when you use Exposé to ‘Show Desktop’? That’d let you see your desktop and would let you see which desktop image you liked best. Then when you close System Preferences (or move to another preference pane) the windows could move back in.

Often I’ll select an image for my desktop that’s too dark, light or distracting — but I never find this out until I can see my desktop (i.e. when most of my open windows are closed). To see if an image is suitable, I currently have to create a new space and switch to it.

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.

May 31, 2012

A nice touch from the makers of Fantastical

Filed under: Experiential,Mac OS X,Software — admin @ 11:36 am

Whilst setting up Fantastical for the first time, you get a lovely little walkthrough that contains this particular gem:

Fantastical intro walkthrough showing you how to 'always allow' it access to your keychain

Above: Fantastical points you at the right button to hit. Nice.

May 3, 2012

Making ATMs more fun to use

Filed under: Experiential,Financial Services — admin @ 9:28 am

This is great –there are ATMs in London that offer cockney rhyming slang as a language option.

[Ron Delnevo] maintains that it makes it more fun for people to use cash machines and that it also creates a conversation piece. So a speckled hen becomes £10, a cab rank is a bank, and sausage and mash is cash.

Ismat Ullah never understood why people laughed as they walked away from the cash machine situated in front on his convenience store in East London’s Commercial Road, until somebody explained to him the intricacies of cockney rhyming slang.

“I am glad to hear about people walking away from the machine laughing because that is how we want people to react to it,” Mr Delnevo says.

“At the same time it helps foster a bit of British culture.”

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 13, 2012

Greater control over when to receive push data on iOS

Filed under: Apple,Experiential — admin @ 2:25 pm

Push data is great. I like knowing that my phone will always have my most up to date contacts and calendar information without me having to go in and manually drag down updates from the cloud.

However, I’m less enamoured about receiving emails at all times, particularly work emails. Wouldn’t it be useful if you had more control over when to receive certain types of push data?

What if your phone was able to determine:

  • When you’re at your desk with your mail client open
  • When you’re not at work
  • When it’s the weekend
  • When you’re on holiday (it’s in your calendar)

And what if it allowed you to set a preference for when to receive push data?

A mockup of iOS allowing greater control over when to receive push data

This is a rather quick & crude mockup, and part of me feels that this is such a non-problem but I love the idea of my phone being super smart with how & when it pulls my work emails down for me.

What if my phone didn’t pull emails down:

  • When I’m at my desk with Mail open (I’m getting my emails via Mail — nobody likes getting a ting on two devices when receiving one email)
  • When I’m not meant to be working (I’ve told iCal what my work hours are)
  • When it’s the weekend (weekends come at the end of every week; they’re pretty predictable)
  • When I’m on holiday (I’ve put my work holidays into iCal)
  • When I’m anywhere I’ve told my phone I don’t want to be disturbed (e.g. the cinema)
  • Anytime I’ve told my phone I don’t want to be disturbed

This is definitely a first world problem. Why not just turn off push data when you don’t want it? It’s relatively easy to find within the Settings app and takes but a moment. A bit of a faff, perhaps, turning it off & on each time you want or don’t want it, but a simple solution — that works in iOS now — that solves the problem.

When Scott Forstall demoed the location-based reminder feature of iOS 5, I had a bit of an ‘ah-ha’ moment — this was using the full power of the whole device (the GPS location & contact data) to make something fairly rudimentary (reminders) better for the user. Yes, setting your phone to ping at the time you think you’re going to be home works most of the time, but what if you could tell your phone where ‘home’ is and have it remind you when you get there, regardless of what time it was? Location-based reminders set off a little lightbulb in my head.

Something similar that allowed me greater control over when to receive push data would be marvellous.

April 7, 2012

“Sometimes, new technology is not progress”

Filed under: Experiential,Technology — admin @ 3:36 am

Marco on Chase’s photo cheque deposit functionality.

A good idea in theory. In practice, not so much.

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 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