«Caring about accessibility leads to extremely loyal users»: John Fox (Netflix) on accessibility
It’s known that accessibility matters, but a lot of developers overlook it.
And it’s known that the NeXT company was an important part of Steve Jobs’ career, but few people actually worked on software for NeXT computers.
John Fox (iOS UI Engineer at Netflix) will present a talk on accessibility at Mobius. In anticipation of that we asked him questions regarding different topics, starting with his long-spanning career and then moving to the subject of accessibility.
— Hi John! It’s interesting to talk to someone who has started working in mobile development since 2010 and has been working in IT for decades. Could you please tell our readers what were you first steps in IT?
— When I was still at NYU, a student group I belonged to managed to convince the administration to fund the purchase of a Mac, a laser printer and a copy of a page layout app called QuarkXPress. This was cheaper than the cost of typesetting a single issue of the academic journal we put out, which was already a funded activity. After graduating, my first real job was at a language training and translation company in NY. Among our clientele were financial services companies and law firms who needed documents translated under extremely tight deadline; much shorter times than a single human translator could manage.
There was a company in New Jersey that offered machine translation services using a timeshared mainframe computer. The original work for machine translation in the US was done by IBM for Defense purposes during the Cold War, and the results were not very poetic. If you fed in the sentence “the spirit is willing, but the flesh is weak” (a Biblical phrase), you would get an extremely literal result, something like “the vodka is good, but the meat is rotten.” Even though it was crude, it could be trained, and a single human translator could edit a lengthy document after a first-pass machine translation. The dirty work of making this system function involved getting documents sent by direct-connect modems from a proprietary hardware word processing system onto our Mac, back and forth to the mainframe, and then returned, beautifully formatted, to the client’s computers.
I can sense everyone rolling their eyes at this description of stone-age technology. My teenage son falls on the floor laughing when I tell him about video games when I was his age. The thing is, today’s bleeding edge technology is tomorrow’s museum piece. The enduring skill is piecing together a solution to create something new.
— How did you shift to mobile development?
— Soon after I moved to San Francisco from NY, the original NeXT computer was released. It was at least a decade ahead of its time, and took advantage of two other aspects of the famous research at Xerox PARC (the first being Graphical User Interfaces made famous by the original Mac), namely networking and object-oriented programming. The 30th anniversary of the World Wide Web project at CERN celebrates an achievement made possible by giving the power of software development to people whose primary training wasn’t Computer Science. Without the NeXT, I doubt I would have ever thought about getting into software engineering. After having learned to design and prototype apps using Interface Builder, I moved to doing webapp development (thanks to NeXT’s WebObjects tool). From there, when NeXT did a “reverse acquisition” of Apple, I was already well-versed in the technology and patterns that Cocoa and Cocoa Touch developers still use today.
— Before iOS development you had experience programming on Mac OS. That time it was not a mainstream as for now. How was it for you?
— The main promise of Cocoa, the set of APIs derived from NeXTSTEP, is that it gave you an amazing head start compared to MS Windows APIs at the time. It meant that even a single developer could ship beautiful, sophisticated software. When OS X came out there were a number of “indie” developers, many of which came from the NeXT world (e.g. Wil Shipley who created Delicious Library) who chose to be a “big fish in a small pond” until the pond itself grew into an ocean. I chose that same route creating MemoryMiner. It received great critical acclaim, sold pretty well, and allowed me to create a number of derivative products and consulting engagements as a result.
— You work at Netflix since 2015. What are your responsibilities in that company?
— I joined the team when they were completely re-writing the app from a hybrid app (UI in HTML/Javascript/CSS, video player in compiled code) into a top-to-bottom Cocoa Touch app. Since shipping the rewritten app, we have made extensive refinements and new features as a result of A/B tests, that were much easier to do with a modern Cocoa app.
— On LinkedIn your job title is “product-focused engineer”, and it’s an unusual one. What does it mean and how does is differ from “software engineer”?
— Elegant, maintainable code that compiles without error is a great start for having a complete product, but there’s so much more. Customers care about things like User Experience, polished design, first-run experiences that help them get started (particularly for consumer apps). You have to care about these as much as the general aspects of software engineering (e.g. Class design, unit testing, etc.) if you want to ship a complete product.
One of the reasons I got into software design, and then software engineering was that I was constantly frustrated trying to explain to a fairly stubborn UNIX “greybeard” colleague (who spent his life in a terminal shell with Emacs) why elegant graphical User Experiences mattered. I was delighted to learn that learning programming languages wasn’t that much different from learning spoken languages. Even so, while mastering a programming language’s grammar and syntax get you started (just like learning chord progressions or drum rudiments), that’s just the beginning.
— And on Twitter you write that you are “UI Engineer”. Does it actually mean that this phare just in context of combination “back-end” vs front-end or you are really working only with mobile UI layer like animations, visualization, etc?
— Currently, I’m almost exclusively working on the user-interface (lots of animation, video playback, localization, accessibility). I’ve done plenty of server-side development in my life, but always in service to a rich graphical experience.
— What does it mean to be a mobile developer at Netflix? What are the daily activities and tasks?
— A combination of A/B testing to develop brand new features, maintaining and improving existing features, knowledge-sharing, and improving our processes (QA, localization, etc.) We’re responsible for our own end-points so our app can access just the right data it needs at the right time.
— How does the team structure at Netflix look like? Is it a product team with backend + frontend + mobile + QA, or a horizontal structure where iOS developers do not see Android team?
— The iOS UI team and Android UI teams work together all the time in conjunction with the mobile design and QA teams. We all sit together, and genuinely enjoy each others’ company.
— How do QA engineers interact with mobile developers?
— Quality is everyone’s responsibility, so it’s the developer’s responsibility to help develop a testing plan in conjunction with their QA partners. Whatever can be automated (e.g. screen-shot generation) is, so that we can use humans to do what they do best.
— Netflix has a tech blog on Medium. Do you have something like that but specifically for mobile developers?
— We have a pretty active Twitter account which covers all UI Engineering. From time to time, we host talks, which are recorded and made available on YouTube. Here are some that are mobile-specific.
— We have questions regarding the topic of your talk. When speaking about accessibility, visually impaired users usually come to mind first. But they are not the only group of people who benefit from accessibility. What are the other cases that a mobile developer should bear in mind?
— Last fall, me and two other developers did a Hack Day experiment using AR Kit to enable hands-free navigation of the iOS app. It sparked a lot of interest in the press. The goal of this experiment was to help people with limited mobility.
— What happens when we don’t think about accessibility of our apps, how hard does that affect users?
— Apple has done a remarkable job of providing basic Accessibility “for free.” If you use the standard UIKit components your app should mostly work. If you use custom UI components, then the responsibility is yours. If you use web-based technologies for your UI, it’s quite likely that your app will be poorly accessible. By default, UIView has no accessibilityLabel, so it will be invisible to VoiceOver, the most-used Accessibility technology on iOS.
There is a very vocal Accessibility community for Apple software, a great example of which is the website AppleVis. There are lively discussions about apps which work well, and which don’t.
— Do accessibility considerations conflict with other priorities? For example, are there cases when a designer insists on a beautiful unusual font, but that font is less readable than a boring one? How to deal with such situations?
— For low-vision or color-blind users, the biggest issue is font size and contrast. If your app supports Dynamic Type, that’s an enormous help. Beauty and usability need not be mutually exclusive. Even if your app doesn’t support Dynamic Type, the Zoom and Color Inversion capabilities help people navigate.
— A developer working on a new app can think “it’s too early for care about accessibility when the core functionality isn’t implemented yet”. When is the best moment to start working on accessibility? Does it impact design decisions so it’s better to think of it from the beginning?
— Generally speaking, it’s better to think about it in the beginning. That said, the work needed to deliver “Minimum Viable Accessibility” is really not that much, so if you’re in the most experimental phase of your app’s development, and are not thinking about it there’s no penalty to adding it later when a feature set is locked down. It’s been my experience however, that, that thinking about Accessibility helps tune overall User Experience in surprising ways.
— While empathy is important, decisions are often based on business metrics, so it’s much easier to persuade a manager “we should put resources into accessibility” if the numbers show it will drive new users to the app. Do you know any statistics that can be of assistance?
— Statistics like this would be very difficult to come by, I think about it in a different way. If you’re shipping any app, even brand new ones, chances are, there are other apps in the market that perform similar functions. When it comes time to getting people to talk about your app, you need a “hook” in order to give people a reason to care. People who depend on accessible software will loudly sing your app’s praises. This in turn helps generate buzz.
— Some developers would probably say “OK, there’s no shortage of resources at Netflix, but we’re a small team and there’s too much on our hands to work on the accessibility stuff”. Is there anything you’d like to say regarding that?
— It’s certainly true that we have more resources than a tiny development team, but the way we look at it is leverage. A lot of the work that’s needed to make testing automation work is providing accessibilityIdentifiers to your UI elements. A QA engineer on our team who was responsible for that work cared enough to add accessibilityLabels, and it grew from there. To me, it’s similar to localization. It’s tempting to say, “it’s much easier to use hard-coded strings in your UI elements”, but that would make it impossible to address the broadest possible market. Caring about accessibility means making your app available to a subset of extremely loyal set of users.
— You have participated on different conferences before as a speaker. How was your first time?
— My first talk was back in 1995, when I was on stage with a customer of a NeXT-based routing and approval system I worked on. We gave a presentation at the Seybold Publishing Conference in Boston. I was completely nervous, but the demo Gods were with me, and it all worked out. I’ve had some catastrophic failures, which is why even when attempting a live demo, I have a screen movie as a backup.
— Have you ever been in Saint-Petersburg before and have you heard of the white nights? Mobius will be in May when the white nights season starts!
— This will be my first time in Saint Petersburg, and only my second time in Russia. I’m very much looking forward to it. As for White Nights, before starting college, I visited a dear friend in Sweden in early Summer. We took advantage of the un-ending day to attend a party which was broken up by an angry parent who came home much earlier than expected. He was none too pleased to find a drunken group of teenage boys and girls up to no good in a sauna. Since then, I’ve become somewhat more responsible in life.
Mobius will take place on May 22–23, the program is published on its website.
We also published a Russian translation of this interview.