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

Reduce Motion doesn’t reduce motion in the macOS Mojave App Store

Accessibility rants on this blog are like busses. One doesn’t show up for ages, and now two are belching fumes into your face.

So, anyway, I just opened the App Store app on macOS Mojave, and I had the audacity to click on something that was featured and looked quite interesting. WHOOSH went the full-window slide transition. BLORCH went my innards. Through squinting eyes I then did a bit more testing. Clicking Done made the window zoom downwards again. And then I clicked a standard list item. WHOOSH went the full-window slide transition, but, excitingly, in a different direction this time (horizontally). GAH went my brain, asking me to JUST SODDING STOP WITH THIS STUPID EXPERIMENT ALREADY.

But, come on, Apple – what is going on here? This kind of thing is not a surprise. I and others have been writing about motion triggers on iOS and macOS for years now. I thought you’d finally got it right when you added Reduce Motion to macOS. But no. Because someone at the Apple interface team is apparently addicted to swoopy whooshy animations, and because apparently no-one thinks to actually test them against accessibility controls, it seems people who have vestibular disorders get to play a fun game of Russian roulette with their wellbeing every time Apple releases a new app.

Sorry, but this is not good enough. Apple is often rightly lauded for its accessibility stance; but as I’ve said before that means accessibility for all, not just the cool stuff that gets the headlines.

(And in case anyone’s wondering, yes I have already emailed accessibility at apple dot com about these issues.)

(Oh, and anyone who dislikes transitions of this type, probably don’t bother with News nor Stocks for macOS either.)

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

2 Comments

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

Beeping hell. Tech companies and movies, please stop with all the *beeping* beeping

I have an induction hob in my kitchen. The second seemingly a single drop of water ends up on its controls, the thing emits an ear-piercing beep. This means when I’m cleaning the thing, it helpfully deafens me until the point it’s dry again. Presumably, the ‘feature’ is designed to help should its owner be furiously tapping out angry blog posts while the spaghetti boils over. In reality, it’s just another example of a notification convention that’s becoming ubiquitous – and that someone needs to take out back and shoot.

Beeps are bloody everywhere. You turn on a piece of electronics. BEEP! You turn it off. BEEP! You change a setting. BEEP! On the telly and in movies, it’s become shorthand for “I just did something on a computer” – from Tony Stark working with cutting edge technology to a detective somehow transferring files from a computer to a USB stick by holding it limply near to a display. BEEP! BEEP! BEEP!

In both cases, it’s lazy. On the telly, better direction or an actual range of sound effects could get across the fact someone has performed an action much more easily without resorting to shrill beeps every single time. As for in the home, companies need to start providing options to turn these hideous noises off. Because the more of these things that assault my ears, I just want to throw the designers into the *beeping* sea.

May 29, 2018. Read more in: Opinions, Technology

2 Comments

Simogo quits iPhone and iPad gaming, and points the finger of blame at Apple

Simogo was my favourite mobile developer. Its games include Device 6, Year Walk, and the amusingly audacious one-thumb stealth/puzzle/platform/route-finding hybrid that is Beat Sneak Bandit. But, as you may have gleaned from the tense used in that opening line, the company has – for now at least – quit iOS.

Apple should treat this as a body blow. Simogo has consistently been one of the best developers on the platform, pushing the boundaries of gaming in new and interesting directions. Device 6, in particular, remains a masterclass in touchscreen game development – a strange puzzle/adventure hybrid, where you explore corridors composed of the very words in the game’s narrative. Sure, it could be made for a traditional console or PC – but it’d make far less sense.

But sadly, Simogo elaborates in a blog post that Apple is the problem, and I suspect the company remains largely oblivious to the pain it’s putting developers through, not only in terms of supporting games, but also regarding the longevity of their output.

Some choice quotes from Simogo’s writings say everything:

Let’s get the rough things out of the way first. This year we spent a lot of time updating our old mobile games, to make them run properly on new OS versions, new resolutions, and whatever new things that were introduced which broke our games on iPhones and iPads around the world. We’ve put months of work into this, because, well, we care that our games live on, and we want you to be able to keep playing your games. Had we known back in 2010 that we would be updating our games seven years later, we would have shook our heads in disbelief.

I’ve heard similar from other developers. It’s such a shift from when I visited an EA developer press event around 2012, when indies they’d got on board were brimming with excitement about iOS gaming. Then, it was a breath of fresh air – less hassle with platform issues and gatekeepers alike. But iOS has become a moving target in a way it never used to be.

This year, a lot of time we had planned to spend on our current project, ended up being spent on just making sure that our games would not be gone from the app store. Because sadly, the platform holder seems to have no interest in preservation of software on their platform.

This in itself is quite curious. I suspect Apple has no senior advocate of gaming. I’ll be amazed if anyone in Apple leadership is a big gamer. Much of the evidence points to Apple still largely considering gaming broadly throwaway. There’s a kind of ‘read and burn’ mentality, which is at odds with how the company thinks about movies, television, music and books.

We can criticize and be angry and mad about it all we want, but we don’t think that any efforts we put in can change that direction.

Developers feel powerless. They feel that Apple isn’t listening – and doesn’t care.

So, instead, we’re thinking a lot about how we can find ways to preserve our games, and our own history, because it is inevitable that our mobile games will be gone sometime in a distant, or not so distant future, as iOS and the app store keeps on changing and evolving. We don’t have a definitive answer, or any final ideas how this would be possible, but we’ll keep on thinking about it, and try to come up with solutions, and we welcome any input and ideas on this from you too!

I at the time wrote about the appocalypse. Many games have since been updated, but then the iPhone X threw another spanner in the works. Regardless, even 64-bit support feels like a stay of execution. Come iOS 12, how many games will fail to work and just disappear?

The response to all this is perhaps inevitable:

As you can imagine, this has led to thoughts about platforms in general.

Simogo notes that the iPhone changed everything, and the ease of mobile development drew the tiny studio to making iPhone games, but:

it’s getting increasingly financially unviable, tiring and unenjoyable for us to keep on making substantial alterations for new resolutions, guidelines, and what have you, as they seem to never end.

The appeal is gone. And, crucially:

Before we started Simogo, we had made console games, and had grown really tired of the clunky processes, politics, certifications and primitive development environments that was involved in making a console game. Today, a lot of that clunkiness is gone, and sadly, for a small developer like us, mobile has become more difficult to support than consoles.

In other words, the advantages mobile had – iOS had – are gone, while console gatekeepers have slowly recognised and removed barriers to entry.

The next Simogo game therefore won’t grace the iPhone and iPad. It feels like the end of an era.

December 12, 2017. Read more in: Apple, Gaming, iOS gaming, Opinions

Comments Off on Simogo quits iPhone and iPad gaming, and points the finger of blame at Apple

« older posts