Известно, что accessibility — это важно, но далеко не все уделяют доступности своего приложения достаточное внимание.
Ещё известно, что появление компании NeXT и её последующая покупка Apple — важный эпизод карьеры Стива Джобса, но мало кто лично писал софт для компьютеров NeXT.
К нам на конференцию Mobius с докладом об accessibility приезжает iOS-разработчик Джон Фокс из Netflix, и в преддверии этого мы решили его расспросить: начали с его продолжительной карьеры, в которой фигурировали NeXT, а затем перешли к теме доступности. На Medium опубликовали опубликовали оригинальный англоязычный текст интервью, а для Хабра перевели на русский.
— Здравствуйте, Джон. Интересно пообщаться с человеком, который пишет мобильные приложения ещё с 2010 года, а работать в IT начал и вовсе десятилетия назад. Расскажите нам о том, как вы начали заниматься IT.
— Когда я был студентом в Нью-Йоркском университете, кружок, в котором я состоял, уговорил администрацию выделить ресурсы на покупку Mac, лазерного принтера и приложения для вёрстки страниц QuarkXPress. Всё это выходило дешевле стоимости типографского набора одного номера академического журнала, который мы выпускали, а на этот набор средства уже выделялись. После окончания учёбы я устроился в нью-йоркскую компанию, которая занималась переводами и обучением языку. Среди наших клиентов были финансовые фирмы и юридические конторы, которым требовались переводы в чрезвычайно короткие сроки — более короткие, чем посильно для любого живого переводчика.
В Нью-Джерси в то время существовала фирма, которая предоставляла время на мейнфрейме, выполнявшем машинный перевод. Изначально в США машинным переводом занималась IBM, это были оборонные заказы во время холодной войны, и тогда результат был лишён образности. Библейскую цитату «the spirit is willing, but the flesh is weak» («дух бодр, плоть же немощна») алгоритм прямолинейно переводил в духе «водка хорошая, но мясо протухло». Несмотря на этот примитивный уровень, алгоритм можно было обучать. Он выдавал только первичный вариант текста, который переводчик затем редактировал. Налаживание работы этой системы было неблагодарным трудом: мы посылали документы по прямому соединению с проприетарной машины для обработки текстов на наш Mac, затем по многу раз отправляли их на мейнфрейм и редактировали результат, и, наконец, возвращали прекрасно отформатированный готовый документ клиентам.
Представляю, как все закатили глаза при описании такой допотопной технологии. Мой сын-подросток давится со смеху, когда я рассказываю ему, как выглядели игры, когда я был в его возрасте. Но это нормально: то, что сегодня является наиболее прогрессивной технологией, уже завтра будет пылиться в музее. Сохраняется со временем только способность собирать новые решения.
— Как вы перешли к работе с мобильными приложениями?
— Вскоре после моего переезда из Нью-Йорка в Сан-Франциско вышел первый компьютер NeXT. Он опередил своё время по меньшей мере на десятилетие. Здесь нужно сказать про исследования Xerox PARC, которые дали множество очень ценных плодов — например, первые GUI, получившие распространение благодаря Mac. В NeXT были использованы два других результата этих исследований: сетевые технологии и объектно-ориентированное программирование. CERN сейчас отмечает 30-летие World Wide Web — это достижение стало возможным благодаря тому, что доступ к программированию был открыт для людей, не имеющих диплома в computer science. Если бы не было NeXT, я вряд ли занялся бы написанием софта. Вначале я научился проектировать и прототипировать приложения при помощи Interface Builder, затем стал писать веб-приложения с WebObjects (другой инструмент NeXT). К тому времени, как Apple приобрели NeXT, я уже неплохо владел технологиями и паттернами, которые до сих пор используются разработчиками Cocoa и Cocoa Touch.
— До iOS вы разрабатывали для Mac OS, а она тогда была менее распространённой, чем сейчас. Какими были ваши впечатления?
— Cocoa (набор API, унаследованных от NeXTSTEP) тогда давал разработчикам куда больше, чем Windows API. Благодаря Cocoa программист мог даже в одиночку создавать красивый и сложный софт. К моменту появления OS X существовало значительное число инди-разработчиков, многие из которых до этого разрабатывали для NeXT — например, Уилл Шипли (Will Shipley), создатель Delicious Library. Они предпочли быть первыми в деревне, а не вторыми в городе, и в итоге их деревня превратилась в мегаполис. Этим же путём прошёл и я — моё приложение MemoryMiner получило отличные отзывы, хорошо продавалось, и позволило мне сделать несколько других продуктов на основе него, а также дало мне работу как консультанту.
— Вы работаете в Netflix с 2015 года. Какие ваши обязанности в этой компании?
— Когда я пришёл в Netflix, их приложение было гибридным (UI на HTML/JavaScript/CSS, плеер на компилированном коде), и они переписывали его целиком на Cocoa Touch. После того, как оно было переписано, мы на основе A/B-тестирования сделали много усовершенствований, которые было гораздо проще проделать с современным Cocoa-приложением.
— В LinkedIn ваша должность обозначена как «product-focused engineer», это довольно необычная формулировка. Что она значит, и в чём отличие от «software engineer»?
— Безусловно, для качественного приложения важно, чтобы его код был лаконичным, чтобы его было легко поддерживать и чтобы он компилировался без ошибок. Но помимо этих критериев есть множество других, не менее значимых: удобство использования, красивый внешний вид, понятность приложения при первом запуске (особенно для пользовательских приложений). Если вы хотите создать полноценный продукт, то эти аспекты настолько же важны, как и правильное проектирование приложения (хорошо спланированные классы, юнит-тестирование и т. п.)
В своё время я потратил много нервов, пытаясь объяснить упрямому «бородатому» коллеге (который всю жизнь работал под UNIX в командной строке с Emacs), почему элегантные графические интерфейсы важны. Из-за этих споров я и начал заниматься разработкой софта, и для меня стал приятным открытием тот факт, что обучение языку программирования не слишком сильно отличается от обучения обычному языку. Но знакомство с синтаксисом и грамматикой — это всегда только начало, как знакомство с аккордами в музыке.
— У вас в Twitter написано, что вы — «UI Engineer». Значит ли это, что вы работаете исключительно с UI мобильных приложений — с анимацией, визуализацией и т. п.?
— Да, сейчас я занимаюсь почти исключительно UI: анимацией, воспроизведением видео, локализацией, доступностью. В прошлом я довольно много работал и с кодом для серверов, но конечной целью всегда было создание качественного UI.
— Расскажите нам, какие каждодневные задачи приходится решать мобильному разработчику в Netflix.
— Мы выполняем A/B-тестирование, по результатам которого создаём новые фичи, занимаемся поддержкой и улучшением существующих фич, делимся знаниями, и совершенствуем нашу работу (контроль качества, локализация и т. п.). Поскольку мы контролируем свои конечные точки, наше приложение может получить доступ к нужным данным ровно тогда, когда необходимо.
— Какая у вас структура команды — например, контактируют ли iOS-разработчики с Android-разработчиками?
— Наши команды — и iOS, и Android, и мобильная разработка, и контроль качества — работают вместе. Мы все сидим рядом, и у нас очень дружеская атмосфера.
— Как именно тестировщики взаимодействуют с мобильными разработчиками?
— Ответственность за качество лежит на каждом, так что ответственность разработчика — помочь создать планы тестирования совместно с тестировщиками. Мы автоматизируем всё, что возможно (например, создание скриншотов), чтобы люди могли делать только то, что у них получается лучше всего.
— У Netflix есть технологический блог на Medium. А есть ли что-то подобное конкретно для мобильных разработчиков?
— У нас довольно активный Twitter Netflix UI Engineers, посвящённый разработке UI в целом. Иногда мы проводим выступления, записи которых доступны на YouTube. Есть подборка из четырёх, посвященных именно разработке мобильных приложений.
— Давайте обсудим тему вашего выступления на Mobius. Когда речь заходит о доступности приложений, часто люди задумываются о слепых и слабовидящих, но accessibility может помочь не только им. Какие ещё случаи нужно иметь в виду мобильному разработчику?
— Прошлой осенью мы с двумя другими разработчиками на хакатоне провели эксперимент, в котором управление iOS-приложением выполнялось без рук с помощью AR Kit. Этот эксперимент привлек внимание СМИ. Его целью было помочь людям с заболеваниями опорно-двигательного аппарата.
— Что происходит, если не задумываться о доступности своего iOS-приложения — насколько сильно это затрудняет жизнь пользователям?
— Здесь надо отдать должное Apple: они предоставляют основные функции для доступности «из коробки». Если вы пользуетесь компонентами из стандартного UIKit, то в целом ваше приложение будет работать. Но если вы используете собственные компоненты, то ответственность лежит уже на вас. Если вы используете веб-технологии, то, скорее всего, ваше приложение будет малодоступным. По умолчанию у UIView нет метки accessibilityLabel, так что он не будет распознаваться VoiceOver, наиболее часто используемой технологией доступности в iOS.
У вопросов доступности Apple-софта очень живое сообщество, у него есть сайт — AppleVis. Там всё время идут бурные обсуждения того, какие приложения хорошо доступны, а какие — нет.
— Вступают соображения доступности в конфликт с другими задачами? Например, дизайнер хочет использовать красивый шрифт, но он читается хуже, чем более скучный. Как разрешать эти конфликты?
— Для людей с нарушениями зрения и дальтонизмом главные трудности возникают не из-за самого шрифта, а из-за его размера и контраста. Очень помогает, если ваше приложение использует Dynamic Type.
А вообще говоря, красивое оформление и удобство для пользователя вовсе не взаимоисключающие характеристики. Даже если ваше приложение не поддерживает Dynamic Type, настройки увеличения и инверсии цвета могут существенно облегчить работу с приложением.
— При разработке нового приложения вопросы доступности легко отложить на потом: мол, рано об этом думать, когда основная функциональность ещё не реализована. Когда пора об этом задумываться? Влияют ли соображения доступности на решения, касающиеся всего приложения, так что надо думать о них сразу?
— Вообще говоря, лучше всего принимать во внимание проблемы доступности с самого начала. Но при этом обеспечение «программы-минимум» по доступности требует немного труда, так что если у вас ранний экспериментальный этап и вам не до этого, от более поздней реализации вы каких-то дополнительных издержек не получите. Однако, судя по моему опыту, решение вопросов доступности помогает по-новому взглянуть и на другие вопросы удобства для пользователя, включая неожиданные.
— Как бы ни была важна эмпатия, многие решения принимаются на основе экономических показателей. Может быть куда проще убедить менеджера вложить ресурсы в обеспечение доступности, если есть данные, сколько новых пользователей это приведёт. Есть ли статистика по этому вопросу?
— Такую статистику найти сложно. Я предпочитаю смотреть на этот вопрос иначе. У любого приложения, даже у самого нового, на рынке всегда есть конкуренты, которые выполняют те же функции. Чтобы создать имидж вашему приложению, необходимо чем-то «зацепить» пользователей, тогда они начнут рассказывать про него всем остальным. Если вы сделаете свой продукт удобным для пользователей, которые зависят от софта с доступностью, то они, в свою очередь, начнут вовсю расхваливать ваше приложение, оно будет у людей на слуху.
— Некоторые разработчики скажут: «Ну, у Netflix прорва ресурсов, а мы тут в маленькой команде завалены задачами, поэтому нам не до работы над доступностью». Хочется ли вам что-то ответить?
— У нас действительно больше ресурсов, чем у маленькой компании, но мы смотрим на эту работу ещё и как на полезную в других отношениях. Например, значительная часть проблем с автоматизацией тестирования решается благодаря предоставлению идентификаторов accessibilityIndentifier для элементов UI. QA-инженер из нашей команды, который занимался этим, уделял этому достаточно внимания, чтобы проставить ещё и accessibilityLabels, и дальше всё разрослось из этого. Здесь можно провести аналогию с локализацией: есть искушение захардкодить строки в элементах UI, но это существенно ограничит рынок, на котором вы сможете продавать ваше приложение. Уделяя внимание вопросам доступности, вы создаёте крайне преданных вам пользователей.
— Вы выступали с докладами уже на многих конференциях. А как прошел ваш самый первый доклад?
— Это было в 1995 году, я представлял свою систему маршрутизации и утверждения для NeXT вместе с одним пользователем этой системы на Seybold Publishing Conference в Бостоне. Я очень переживал по поводу выступления, но боги выступлений были на моей стороне, и в итоге всё прошло хорошо. У меня случались и катастрофические сбои по ходу доклада, поэтому при обращении к живому демо я всегда на всякий случай держу заранее заготовленное видео, чтобы был запасной вариант.
— Были ли вы раньше в Санкт-Петербурге и слышали ли о белых ночах? Mobius пройдёт в мае, когда они уже начнутся.
— В России я был только один раз, а в Санкт-Петербурге — ещё ни разу, и мне очень интересно будет посмотреть на ваш город. А что до белых ночей, могу рассказать историю, которая произошла со мной ещё до учёбы в колледже, когда я был у друга в Швеции ранним летом. Там мы решили воспользоваться нескончаемым световым днём для вечеринки. Вот только веселье закончилось с досрочным появлением дома родителя, который был очень не рад обнаружить у себя в сауне компанию пьяных подростков. С тех пор я стал несколько более ответственно подходить к жизни.
Mobius пройдёт в Петербурге 22-23 мая. Джон выступит там с темой «Accessibility for iOS: Doing well by doing good», а кроме этого, будут десятки других докладов по мобильной разработке. Увидеть полную программу можно на сайте конференции, приобрести билеты — там же.
