Reduce Motion coming to ‘OS X’, in macOS Sierra

I’ve been regularly writing about motion sickness and vestibular issues in computing for years now, on this blog and elsewhere. The problem is poorly understood and broadly ignored by designers and engineers alike, who thrill at the prospect of infusing interfaces with dynamic movement, without pausing to consider how this affects a sizeable proportion of the population.

Apple’s response has been better than most, but still half-hearted at times. iOS is an exception. Although niggles remain, Apple’s iOS team has clearly worked very hard to ensure the iPhone and iPad interfaces are truly usable for all. But on tvOS, Reduce Motion does relatively little, and on the Mac, the system does not exist at all. This is something I find maddening, given how prominent animation is within OS X, how long Apple’s had to fix the problem, and the fact underlying settings have existed for years — but clearly in a half-finished state that users could not easily access.

Last October, I posted the following on Twitter:

Hey, Apple: this —
☑️ Reduce Motion
— would fit almost perfectly in the area I’ve outlined in red.

System Preferences pane with area marked out where Reduce Motion setting could go

It turns out all I got wrong was the placement. At WWDC 2016’s keynote yesterday, while no mention was made of Reduce Motion in macOS Sierra, I’m informed it’s coming. In fact, I was sent the following image:

Reduce Motion checkbox in macOS Sierra

I’m told when this box is checked, major system animations switch to crossfades, much like on iOS. This includes entry/exit animations for Mission Control, Launchpad and full-screen apps, along with swiping between spaces. I’ve no idea whether other integrated and problematic animations are also affected (such as full-page swipes in Safari and Preview), but there’s a checkbox there. It’s a start. It’s something to build on. It’s something to report feedback on regarding improvements rather than it’s very existence. And I’m delighted.

As much as it might irritate John Gruber, I really think this one merits a finally.

June 14, 2016. Read more in: Apple, Design, Technology


What’s more important in UI: what you tap or what you see?

Daring Fireball recently linked to Maps Plus. The app uses Google Maps data but filters it through an Apple-style interface. John Gruber says:

It’s close to what you’d get if Google Maps were still providing the data for Apple Maps.

And this is true. It even has Street View. It doesn’t, though, have turn-by-turn, and there is, to me, a worse problem: the roads are the wrong colour. This is because when Google shifted its system to a faster vector-based approach, it dispensed with varying road colours individual nations used, preferring US ones worldwide. Instead of blue motorways, green A roads and yellow B roads, UK motorways became orange, A roads were coloured yellow, and B roads were white, not differentiated from smaller roads. Motorways and A roads since received correctly coloured markers, but that only helps when one is in the viewing area. Otherwise, at a glance, the M3 diagonally crossing the screen looks at a glance like an A road.

Apple Maps got this right in iOS 7b4. This means in the UK, you can more easily spot the roads you need, just by what colour they are. By contrast, Maps Plus loses this, through working with Google’s mapping system. So you end up with a user interface that’s more suited to iOS, but content where its ‘user interface’ is far worse. Complicating matters further, Google remains far superior to Apple when it comes to points of interest and with Street View versus the oddball Flyover. So either Apple needs to get way better with POI or Google needs to get over itself and start recognising everywhere isn’t the USA. Usually, I’d suggest there’d be no chance of Apple winning such a race, but Google doesn’t seem to want to budge on this one.



June 6, 2016. Read more in: Apps, Design

Comments Off on What’s more important in UI: what you tap or what you see?

How big an issue is the nausea problem for Virtual Reality products?

On Quora, helmet mounted displays expert Steve Baker talks about the issue of nausea in VR. It’s an excellent post that should cause lots of people within the industry to sit up and take notice. The short of it is VR confuses the brain, contradicting what we feel and see, to the point some people’s automatic response is that they’re hallucinating, and therefore must eject whatever they just ate that poisoned them. In other words, VR makes them sick.

I’m not optimistic much will change. Vestibular conditions through to basic nausea are not very well understood in the tech industry. Engineers and designers are broadly ignorant of any such issues, and companies don’t appear that concerned about taking steps to rectify them. That might sound like hyperbole, but the evidence is everywhere you see an interface that moves. Our Samsung TV’s ‘smart’ screens spin around; my iMac’s full-screen mode slides before my eyes; and countless web pages hurl content about with merry abandon.

Apple seems to have precisely zero interest in addressing motion issues, and yet it is strong on accessibility elsewhere: vision, hearing, motor. And if even Apple doesn’t care enough (bar when there’s bad press, which made the company take notice in iOS 7), how likely is it anyone else will deal with such problems?

At least with VR, you know you’re placing yourself in a situation where you might get sick. You put on a headset. You can prepare yourself. What concerns me more is that extreme motion is becoming ubiquitous, pervading all interfaces, and hardly anyone seems bothered about addressing this. It’s one thing when you can escape, but another when the problem is all around you.

May 23, 2016. Read more in: Design, Technology

1 Comment

Instagram’s new logo: about fitting in, not thinking different

The Guardian reports on Instagram’s new logo. I’m not going to comment on the specifics of the design — there are far more qualified writers for doing that kind of thing. What disappoints me, though, is any sense of individuality has been eroded from the icon, in a desire to ‘fit in’.

instagram logo

I recently wrote a piece about inspiring icon design (yet to be published), and praised Instagram:

Thumbing its nose to Jony Ive, Instagram’s icon remains resolutely old-school (as far as an app icon can be), suiting its retro nature. Even if it sticks out a bit, the icon may stand the test of time better than minimal rivals.

As of now, this is no longer the case. Instagram’s icon is yet another slice of flat design. It doesn’t look distinct, now resembling dozens of other camera app icons.

Two blog posts outline the reasoning for the changes. The new logo apparently intends to reflect the evolution of the service and “how vibrant and diverse your storytelling has become”, while “staying true to Instagram’s heritage and spirit”. Notably, the company argues that it wanted to

create a look that would represent the community’s full range of expression — past, present, and future.

It certainly succeeds on the present, in that Instagram’s logo now looks much like any other app logo in this era of flat design with occasional gradient use. But it’s largely jettisoned Instagram’s past (suggesting the gradient recalls the old logo’s rainbow is a stretch). As for the future, I suspect Instagram will find itself redesigning again once the next interface design evolution takes hold.

May 12, 2016. Read more in: Design

1 Comment

Ratings screens in children’s apps need to die — and they’re not the only thing

Mini-G has been faffing about with an iPod touch and — whenever possible — her parents’ iPhones for some months now. If ever you need a reminder about your generation’s looming obsolescence, stick a toddler in front of a high-tech device and see them master it before they’ve even figured out how to talk. Anyway, since we’re at the point where mini-G can use apps alone (albeit supervised), I’ve made some observations.

First, I’m broadly positive about the whole screens thing. I don’t believe a kid should be glued to any kind of screen for long periods of the day, but mini-G learned how to attempt to say ‘mouth’ from Metamorphabet, and has apps that have boosted aspects of empathy and dexterity. After a session has gone on for perhaps 20 minutes, an iPhone is — typically without prompting — turned to sleep mode and returned to the relevant parent. (Elsewhere, books are read, Lego is played with, puzzles are completed, telly is watched, and wheeled walkers are driven around the kitchen as if it’s the Indy 500. So: balance.)

Secondly, however, it’s clear some developers of apps for children either haven’t tested them all that much on actual children using them on their own, or fundamentally don’t care about the user experience as it relates to said children. Here are some things developers should avoid when making apps for kids:

Ratings screens.
These aren’t exactly loved in apps for adults, but it’s reasonable to include them — reviews and ratings can be important for an app’s success. But throwing up a screen along these lines on an app being used by a 20-month-old child? At best, a parent will be there and grumpily turn off the app. If not, the child will get frustrated and bounce out to the App Store. (And developers who reason very young kids do not remember their favourite apps — as in, apps that don’t annoy them — let me tell you: you are wrong.)

Long launch animations.
 Yes, we know you’re probably very proud of that lengthy animation you had commissioned, your company logo bouncing around like a cartoon character hopped up on sugar. But here’s the thing: no kid cares a jot. In fact, mini-G exits apps with remarkable speed if they don’t ‘do’ anything interactive. You’ve probably got two or three seconds. By all means include your intro, but make it immediately skippable with a single tap. Otherwise, you’re just this tech generation’s DVD producer.

Visible IAP.
 I’m not against IAP in general, not even in apps for children. Developers just need to ensure apps aren’t exploitative. However, in apps designed for children, the IAP needs to be hidden behind some kind of settings screen. I’ve seen too many apps now where you get the first bit for free, and then a kid taps on something that flings up an IAP window. Sure, they’re not going to purchase anything at that moment (well, unless they’re very tech savvy and you are asleep); but the child will get frustrated at not being able to easily exit that screen and get back to the fun parts, or when they inevitably end up back on that screen on a fairly regular basis.

Fiddly navigation.
 It takes time for the dexterity of young children to improve, and yet children’s apps are full of fiddly navigation elements. So make interfaces chunky. Ensure that if a kid accidentally exits to the main screen, they can continue by tapping a suitably massive button (it turns out a big Play symbol is a good one to use). If you don’t, you may find kids simply exit the app and don’t go back.

April 7, 2016. Read more in: Apps, Design, Opinions, Technology

Comments Off on Ratings screens in children’s apps need to die — and they’re not the only thing

« older posts