Attila's Den

One of the things that are worth mentioning about VoiceOver is that any control that you’re picking from various sources is likely to NOT have VoiceOver features enabled or dealt with properly. Here is a perfect example: the excellent SVProgressHud by Sam Vermette, that anyone and my grandmother seem to use in their projects, as soon as an operation needs a bit of time to complete. Check it out on Github, it is great.

Now, let’s put ourselves in the situation of a visually impaired user. If nothing is added to it, when you launch the action that requires the use of the hud, the user will not hear anything… and given the fact that he cannot see the hud, its usage amounts to zero, the UI is wholly inappropriate and the UX is broken. There is, however, a neat trick that you can use, it will only add a couple of lines to your code. Say you are searching a long list, for this example (probably retrieved asynchronously from a webservice). Your code should read:

    [SVProgressHUD showWithStatus:@"Searching"];
if (UIAccessibilityIsVoiceOverRunning()) {
    UIAccessibilityPostNotification(UIAccessibilityAnnouncementNotification,@"Searching");
}

Try it, your user with VoiceOver enabled will be told that the search is underway. Don’t forget to pair that with the end statement, say when your data has been retrieved:

    [SVProgressHUD showSuccessWithStatus:@"Success"];
if (UIAccessibilityIsVoiceOverRunning()) {
    UIAccessibilityPostNotification(UIAccessibilityAnnouncementNotification,@"Success. Results found");
}

And that’s all that was needed. This does not need to be paired with SVProgressHud by the way, but that’s a great example I think. This method can be applied everywhere in your code, you may want to use categories to extend the classes in order to support it. But that will be for another day.

If you really want to know the difference between iOS and Android, look no further than VoiceOver¹. This past week, I have re-opened one old project of mine, TipToe, which is a sleek search engine I optimized a few years ago for it to be usable by visually impaired people. It sort of has been abandonware for a year: I make $200 per year with it, and it’s never been my first priority to update… Yet I was reminded by one of my users that this matters to some people, and did update it. I have been extensively playing with VoiceOver as well, and am in awe². If you are developing an app - and let’s face it, if you read me here there is a strong chance you do - you should definitely try it.

It does work extremely well everywhere, and particularly on the web. The only critic I would have is that the Settings menu sort of sucks when you are on Accessibility, as the static table is way too long, running over several screens (VO and Accessibility lets you swipe down a screen height with a swipe of 3 fingers). AS a dev, the only critic I would have is that the VoiceOver class is not directly accessible in iOS, whereas it is in OS X. Is this a bug? For some reason, during my tests, I found that VO is different on the Mac and in OS X. Particularly for pictures. One thing came out immediately: VO use on the Mac is sort of a pain, due to the more complex UIs and menus laying everywhere on the screen. The only way it makes sense on the Mac is when you are running an app in full screen. I haven’t tried the voice command, maybe it makes things easier.

Now, I want to share a particular feat with you. Here’s what you’re going to do: switch on your iPhone, get yourself to Settings > General > Accessibility and switch VoiceOver on. Now, give or take 3 minutes of furious swiping and double-tapping (it’s not so easy to pick when you’re starting with VoiceOver - rmemeber that visually impaired users just tap first to know what control they’re on, and double tap to activate that control), go open Safari and navigate to Steve Jobs’ Wikipedia entry. You will be greated by a picture of Steve holding an iPhone 4 at WWDC. What really kicked me out of my socks is this: tap the picture, and here’s what you will hear:

“Shoulder high portrait of smiling man in his fifties wearing a black turtleneck shirt with a day old beard holding a phone facing the viewer in his left hand.”

I have been shipping two apps this week. As we all know, this involves a lot of last minute tiny adjustments, swearing, wondering if we’ll get there eventually. I’ve also taken a strange habit to switch to VO, go to listen to that picture. For two reasons: 1) it reminds me what “great” and “excellence” mean, and that they are different words, and 2) VoiceOver would not be useful if it was only text-to-speech. At some point during the development of iOS, someone (I’d like to know who) realized that it must be object-to-speech. And Boy, did they deliver on that!

Here’s a small compilation of the things that end up driving me completely nuts when I’m working with a designer on an app. I guess all those are pretty common. They’re not a deal breaker but I find it exhausting to have to go through it over and over again… And generally end up pissed off at some point. So here we go. My top recommendations for not driving your developer completely crazy:

• Know UIKit. Read Apple’s doc, use apps, read a dev book for beginners
• Read the fucking HIG
• Deliver vector graphics only (SVG is a great format, compatible everywhere… Wait Photoshop doesn’t export that? That’s because that bloated turd one calls a software is not doing vectors. Ditch it and work with real tools)
• Don’t use shitty fonts. Thin fonts should be banned forever in the HIG
• Designing an app and a web page are completely different tasks. Go back to points 1 & 2
• crop your pictures correctly
• use transparent backgrounds
• group and name your pictures correctly
• don’t send me fucking photoshop files. They’re unusable unless you do the exports and I’m not paid to do your job
• be flexible, or read the HIG
• listen to the dev when he points out the differences between the various screen sizes
• things you cannot storyboard or explain in plain English have little to no chance to look and feel like you imagined it would. Devs do not have access to your unconscious brain - thanks god for that
• things that cannot be skinned in UIKit are probably a bad idea and will cost you in dev time. I don’t care if it’s really simple to do it in photoshop, it might be a real shit task in objective-C
• when I’m doing contract work, I’ll make sure to make you or your customer pay for those 2 pixels that denature your “art”. Particularly if the solution is not obvious
• read a few posts on the icon dimensions. Don’t round the corners, iOS does it for you. Heck, download one of the [insert number here] templates off the web.

One of my all times favorite pieces is Ravel’s Piano Concerto in G Major. I’ve been melting over the second movement for as far as I can remember, and must own 15 or so different versions of it. That second movement is very particular (if you’ve never listened to it, please do and come back later… or not). From the most basic level, you can hear that it splits the piano from the rest of the orchestra, and then proceeds like arranging the piano with the orchestra and the orchestra with the piano, until all blends again perfectly. Beautiful piece, played perfectly by Helen Grimaud here (second movement), and by Leonard Bernstein here (the second movement discussed here starts around 9 minutes). I’m including two versions as Grimaud is considered by many the best alive player of that piece, and Bernstein remains my favorite interpret for this one. LB was a true genius and, if you have never seen him in concert, I would definitely encourage you to do so right now: he directs and plays at the same time, which is rare.¹ Which probes the question: is it really a concerto for piano, or the piano for a concerto? In other words, which supplements the other? Is the soloist making the piece or the piece making the soloist²?

When I look at the state of iOS and the App Store, I am amused by the same kind of paradox. It appears that the most successful apps in non-gaming categories have been successful because of the UI innovation they brought to the table, often supplementing a service that was needed. It comes to one of the things I am trying to teach at the moment, namely that the tool does not make the result, the programmer makes the result. In all cases, one should always start by designing the UI on paper, and describe with a few simple words what each screen will do. In my experience, that’s the best way to streamline the programming after. Most beginners I know will essentially pick up components and try to mash them up into something coherent. It does not happen like this, the result is often completely incoherent. It is always preferable to start from the result, the vision, and then walk back to a solution to the problem. That’s how we do for most engineering problems I’ve ever solved, that’s how we do for project management, etc… So, there are two creative processes at play, that should not be split, but be kept independent in the early stages of development: 1- create the app, and 2- code the app within certain constraints. Think about the pull-to-refresh feature we all enjoy: how would you code it without devising it first? And this is how very successful apps, which provide a beautiful, simple and usable UI, achieve it.

Back to my piano analogy. In iOS, the system does a lot for us. It is really optimized for the device, animations are so smooth that they can be easily abused, particularly as they’ve become really easy to implement with the block syntax. I do believe, however, that iOS is just our orchestra, and the one thing that makes an app special is the piano. If you want to make your app better than anything else, what you should strive for is the same as that concerto for piano, where the piano and orchestra cannot be discerned anymore. In a sense, your app should blend into the system, naturally: what better way for the system to blend into your app?

A last interesting point, is to see where the analogy breaks. That one is quite easy: the concerto provides a unit of space and time. This is never the case for your app, as it will need to evolve with the system, and will be used everywhere and in situations you cannot imagine yet. Food for thoughts…