Apple: it’s time to bin the Home indicator when we’re playing games

I wrote yesterday, with a perhaps uncharacteristic lack of snark and cynicism, about Apple’s latest event. Much of my disappointment was in other people being disappointed about Apple having apparently done something entirely different in these people’s dreams from reality. (Such is life.) But I was largely happy with what Apple showed. I will however make one exception – and it’s readily apparent in a big chunk of the Apple Arcade section of the keynote video. Once again, I’m talking about the dreaded Home indicator.

Said indicator is the strip that appears at the bottom of every iPhone and iPad that lacks a Home button. It more or less replaces a physical control with a virtual one, providing a place to swipe that switches apps or takes you back to the Home screen. Given that Apple was roundly – and rightly – criticised for a lack of affordances in the overly minimal iOS 7 overhaul, this indicator is a necessary and useful piece of interface design.

The snag is that it’s in certain cases abhorrent. Apple wisely has it fade out when you’re watching video, because it would otherwise wreck the immersive experience, much in the same way your telly wouldn’t be the same if someone scrawled across the bottom of the screen with a fat marker pen. But video isn’t the only immersive experience on iOS. In reading apps – especially with comics – the Home indicator is a distraction. And in games, the indicator is an eyesore – the worst of interface design.

Whatever you’re doing, the Home indicator remains, scything its way across the bottom of the display, often in a contrasting colour that makes it the most prominent thing that’s visible on the screen. (Check out the bright white stripe in Capcom’s game demo at around the eight-minute mark of the keynote video.) Some games fade the Home indicator, and a few have somehow figured out how to turn it off entirely; but it always springs back to life when you interact with the screen. In videogames – and this might come as a shock to Apple execs, who probably don’t play games that often – this tends to happen rather frequently.

The Home indicator should be on by default. I have no argument with that. But reading apps and games should be allowed to disable this interface component. And if that’s too much for Apple to stomach, users should be able to delve into Settings and turn it off themselves.

September 13, 2019. Read more in: Apple, Design, Opinions, Technology

2 Comments

Trying to explain reduce motion to designers who don’t have a vestibular disorder

With my recent griping about Apple and reduce motion, I should note many other companies/designers fail this test. The web remains rife with such issues, as does the app and gaming ecosystem.

In part, I can understand why. Vestibular issues are weird. I never used to have one, and now I do. I’ve no idea where it came from. It also makes little logical sense to people. They think I’m lying that I get triggered by animations because I also write about videogames. But here’s the thing: I’m fine with racing games, just as I’m fine with roller-coasters. Whatever’s going on in my head manifests when 1) too much of my focus is taken over by a screen, and; 2) whatever’s happening on the screen is outside of my control.

So I can play Super Duper Racing Games VI, but an abrupt full-screen slide transition in an otherwise static puzzle game on the iPad might make me woozy for hours. This is why iOS 7’s transitions were a problem for many people – they couldn’t be ‘prepared’ for. That sounds weird, I know, and I recognise it’s tricky for designers to test against. You can have a crack at dealing with visual impairment by using your app or website with your eyes closed. Vestibular issues? Nope. So you need to fallback on testing and rules.

The first of those is pretty simple: find some people who have such issues, and ask them if your app/website causes problems, and for suggestions on how to fix it. On iOS, this might simply mean adding a preference to toggle some animations, such as parallax backgrounds. Regarding rules, ask yourself: do I really need this animation? Do I really need that full-window slide transition? In book and comic apps, can I offer an option to turn off transitions entirely? Have I checked transitions elsewhere within our apps?

The last of those is where Apple fails. The company’s accessibility people have been broadly impressive when it comes to being reactive to comments and requests I’ve made. But it seems there’s no systematic checking of triggers throughout the operating system. That might sound like I’m asking for too much, but if you have reduce motion baked in at system level, use it! It’s absurd to create something that can make millions of people’s lives better, and then pepper the OS and first-party apps with slide animations.

In a sense, I’m fortunate. After I figured out I have this issue (back in the Mac OS X Lion era, where I felt sick for days), I can usually recover from being blasted within minutes; if not, it takes a few hours. I’ve heard from people who can be knocked out for days.

So as web/app designers, ask yourself: what can I do to improve my work for people with vestibular disorders? And then think widely: what can I do to make my content accessible to everyone? That should be the goal of computing, not saying “well, just don’t use that”.

October 16, 2018. Read more in: Apple, Design, Opinions

Comments Off on Trying to explain reduce motion to designers who don’t have a vestibular disorder

In macOS Mojave, Reduce transparency has broken logic and terrible design

I have motion issues, which I’ve written about on this blog before. I got sick from Mac OS X Lion and iOS 7, due to the animations Apple welded to them. Fortunately, the iOS team recognised the problems fairly quickly; the macOS team… less so, although the Mac did eventually get a Reduce motion control in the Display section of Accessibility.

Even so, I’ve long believed the Mac team doesn’t fully understand visual/balance accessibility issues, and isn’t good with details, and that opinion is rather upheld with Reduce transparency.

The standard macOS interface has quite a few semi-transparent elements, which like frosted glass provide a glimpse of what’s beneath them. At Apple events, execs go giddy about how pretty this is. In use, these elements vary from being distracting to outright dangerous. For example, if you have a motion-sickness issue and an animating web page is sitting behind a semi-transparent element, it can take a while before you realise it’s affecting you, by which time it’s too late and you’re already dizzy.

“Fine”, says Apple, grumpily, “so just turn on Reduce transparency”. Only it’s not that simple. Because when you do, Apple designers get in a strop and hurl logic out of the window. What you’d expect to happen is for macOS to remove the semi-transparent bits. So instead of Finder sidebars or the macOS app switcher showing what’s beneath them, they’d just have a neutral solid background. Nope. Instead, in its infinite wisdom, Apple’s decided those components should instead be coloured by your Desktop background.

This makes no logical sense. Why should the colour of an interface component be influenced by elements that may be several layers beneath them? Also, this decision can make interface elements less accessible, because you end up with an inconsistent interface (colours shifting as you move a window around the screen) and can impact on legibility (such as when moving a Finder window to the right on the default background, whereupon the sidebar goes a weird brown colour).

In tech circles, there’s the phrase ‘dogfooding’. This refers to ‘eating your own dog food’ – in other words, testing your own products in real-world usage. It feels like although Apple is happy to add accessibility controls to macOS, and regularly enthuses about such things relating to people who are blind, its internal teams need to down a whole lot more dog food regarding visual/balance elements. Apple prides itself on sweating the details when it comes to hardware; it needs to do the same with its system software too.


Update: 512 Pixels has created a gallery to illustrate the problem.

October 15, 2018. Read more in: Apple, Design, Opinions, Technology

5 Comments

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

4 Comments

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?

« older posts