Почему у свободного программного обеспечения убогое юзабилити и как это исправить

Предлагаю хабросообществу свой перевод статьи Мэттью Пола Томаса, которую он недавно опубликовал в своем блоге. Томас — программист из Новой Зеландии, работающий в команде разработчиков проекта Launchpad — детища компании Canonical, более известной как коммерческий спонсор самого популярного Linux-дистрибутива Ubuntu.
Что самое интересное:
— первый вариант этой статьи вышел еще 6 (!) лет назад.
— скорее всего появление второго варианта навеяно недавним громким заявлением основателя компании Canonical Марка Шаттлворта, в котором он предложил сообществу свободного программного обеспечения создать в течении 2 ближайших лет интерфейс операционной системы, который был бы «приятнее» Mac OS X.
— в статье прослеживается четкое разделение между volunteer designers и dedicated designers, при этом первые не пользуются у автора особой лаской. Это интересно, потому что судя по словам Томаса, он таковым и является.


Да, я не дипломированный переводчик, поэтому не обессудьте…

Когда я написал первую версию этой статьи 6 лет назад, я назвал ее «Почему у свободного программного обеспечения такое херовое юзабилити» (это мой перевод, в оригинале Why Free Software usability tends to suck — прим.перевод.). В данный момент лучшие открытые приложения и операционные системы более юзабельны, чем это было тогда. Но это в значительной степени объясняется медленным развитием и низким уровнем конкуренции между проектами и дистрибутивами. Главные проблемы дизайна в большинстве своем остались нерешенными.

Многие из этих проблем касаются не конкретно свободного программного обеспечения, а всех программ, созданных на добровольческих началах. Проприетарные программы, созданные в результате хобби, часто сложны в использовании по множеству тех же причин. Но самый легкий путь получить вклад добровольцев в программирование — объявить программу открытой. И поскольку в данный момент в разработку свободного программного обеспечения вовлечены тысячи людей, большинство из них — добровольцы. Поэтому в мире открытого программного обеспечения мы видим проблемы юзабилити программ, созданных добровольцами, наиболее часто.
Это дает нам ключ к первым двум проблемам.

1. Слабый стимул. Поставщики проприетарного программного обеспечения в основном делают деньги путем производства программ, которые нравятся людям. Это сильный стимул делать их более юзабельными (это не всегда работает: к примеру, программы Microsoft, Apple и Adobe иногда становятся хуже, но все же остаются доминирующими по причине массовости. Но они работаю большую часть времени).
У проектов добровольцев, однако же, любые стимулы гораздо слабее.
Такой показатель как количество пользователей редко каким-либо финансовым способом влияет на разработчиков, а в свободно распространяемых программах практически невозможно посчитать количество пользователей вообще. Существуют другие стимулы — произвести впечатление на будущих работодателей или добиться включения своего программного продукта в популярную ОС, но это скорее косвенные мотивы.

Решение: создать больше сильных стимулов. К примеру, могли бы оглашаться ежегодные награды в сфере дизайна свободного программного обеспечения, что воздавало бы должное разработчикам за хороший дизайн. Поставщики программ могли бы публиковать статистику о том, как много их пользователей используют программы, и как это количество меняется со временем. Система премий могла бы позволить людям депонировать деньги любому кто сделает особые улучшения юзабилити. И система управления выпусками могла бы способствовать более быстрой состязательности: дистрибьюторы могли бы выбирать не только какое приложение выпустить, а и какой именно вариант выбрать из ветки приложения, учитывая простоту использования как фактор выбора.

2. Мало хороших дизайнеров. Некоторые музыканты также бывают хорошими композиторами, но большинство из них нет. Некоторые программисты также бывают хорошими дизайнерами, но большинство из них нет. Программирование и разработка интерфейса пользователя — это разные навыки, и люди, одинаково хорошие в обоих сферах, редкость. Поэтому так важно, чтобы у программного обеспечения были профессиональные дизайнеры. Но только несколько проектов из мира свободных программ могут похвастаться этим. Несколько юзабилити-специалистов наняты такими разработчиками свободного программного обеспечения как Mozilla, Sun, Red Hat и Canonical. Но их немного, а квалифицированных дизайнеров-добровольцев очень сложно найти.

Решение: снабжать программистов и дизайнеров-добровольцев легкодоступными учебными материалами, чтобы улучшить общий уровень дизайнерских знаний. Воспитывать в сообществах необходимость сотрудничества программистов со специалистами по юзабилити. И поощрять проекты свободного программного обеспечения иметь в своем штате ведущего программиста, ведущего дизайнера интерфейса пользователя, редактора справочной информации, инженера контроля качества. И это должны быть разные люди.
Но почему на первом месте нехватка добровольных дизайнеров? Ответ на этот вопрос ведет нас к третьей проблеме.

3. Улучшения в дизайне часто не приветствуются и не одобряются. Свободное программное обеспечение имеет давнюю и полезную традицию «покажи мне код». Но когда кто-нибудь указывает на ошибки в юзабилити, эта традиция превращается в “patches welcome”, которая бесполезна, по причине того, что большинство дизайнеров — не программисты. И не понятно как еще специалисты по юзабилити могут в этой ситуации помочь.

Решение: установить способ участия в проекте специалистов по юзабилити. К примеру, ведущий дизайнер может публиковать спецификации на веб-сайте проекта и побуждать к ответной реакции в блоге, вики или списке рассылки. Дизайнер может любезно отвечать на предложения в улучшении дизайна (даже если они неправильные). А руководитель проекта может установить редактируемый баг-трекер, взамен накопительного — делая проще процесс улучшения, утверждения или отклонения предложений, при этом уделяя внимание внедрению дизайнерских предложений так же, как и отчетам об ошибках.
Тогда почему программисты реагируют на предложения по улучшению простоты использования программ не так, как на технические отчеты об ошибках?

4. Юзабилити сложно измерить. Некоторые качества программного обеспечения можно легко и точно измерить: работает ли вообще, как быстро запускается, как быстро работает и правильно ли все с технической точки зрения. Но это только частная замена для более важного качества, которое трудно поддается измерению: полезно ли программное обеспечение, насколько отзывчиво, ведет ли себя так, как ожидают люди, каковая доля людей, достигших цели с его использованием, как быстро они могут его использовать, и насколько довольны после использования. Эти зависящие от человека качества часто можно измерить при помощи пользовательских тестов. Но на это уходят часы или дни, которые добровольцы не желают тратить. Пользовательские тесты обычно сложны в трактовке, фокусируются на крупных проблемах, и оставляют дизайнеров без твердых доказательств для убеждения программистов в существовании мелких проблем. И даже если определена проблема, должно быть разработано ее решение, а для этого тоже могут понадобиться тесты.
Без частого использования пользовательских тестов проекты добровольцев полагаются на субъективные впечатления таких людей, которые настолько увлечены, чтобы подписаться на список рассылки проекта. Но то, что говорят эти люди, может быть не репрезентативно даже по отношению к их собственному опыту использования, не говоря уже об опыте обычных пользователей.

Решение: поддерживать низкоуровневые технологии пользовательских тестов, которые удобны для добровольцев. Развивать и поддерживать использование скриншотов, видеозаписей и другого программного обеспечения, которое облегчает проведение тестов. Поощрять разработчиков доверять результатам пользовательских тестов больше чем просто мнениям пользователей. И писать дизайнерские руководства, которые дают решения по распространенным мелким проблемам, которые пользовательскими тестами не возможно отследить.
Нехватка профессиональных дизайнеров, среди прочего, способствует трем культурным проблемам в проектах свободного программного обеспечения.

5. Сначала программирование, затем дизайн. Программное обеспечение имеет тенденцию становиться более простым в использовании, если, грубо говоря, дизайн был сделан перед написанием кода. Желаемый пользовательский интерфейс для программы может оказать влияние на модель данных, выбор алгоритмов, порядок выполнения операций, необходимости использования конвеерности, выборе формата сохранения данных на диске, и даже в выборе набора функциональности программы вообще. Но все это выглядит скучным, поэтому программисты часто просто начинают кодить — они побеспокоятся об интерфейсе позже.
Но чем больше написано кода, тем сложнее решать проблемы дизайна — поэтому программисты вероятнее всего не будут переживать по этому поводу, или будут убеждать себя, что это в действительности и не проблема. И если они наконец-то пофиксят интерфейс после версии 1.0, существующие пользователи будут вынуждены переучиваться, разочаровываясь и подумывая о рассмотрении конкурирующих программ.

Решение: посадить попарно дизайнеров с программистами, которые хотят разрабатывать новый проект или новый функционал. Создать культ в мире свободного программного обеспечения — сначала дизайн, а затем код.

6. Слишком много поваров. В отсутствие профессиональных дизайнеров, многие помощники проекта пытаются участвовать в разработке дизайна интерфейса, независимо от того, как много они знают в этой области. И большое количество дизайнеров ведет к несогласованности, как в общем видении, так и в деталях. Качество разработки интерфейса обратно пропорционально количеству дизайнеров.

Решение: проекты должны иметь ведущего дизайнера пользовательского интерфейса, который будет отслеживать предложения всех желающих и работать с программистами в вопросе выбора того, что может быть внедрено. А более детальные дизайнерские спецификации и руководства могут помочь предотвратить специфические для программистов недостатки.

7. Погоня за солнечным зайчиком. При отсутствии собственного определенного дизайна, многие разработчики полагают, что то что делают Microsoft или Apple — это хороший дизайн. Иногда это так, но иногда нет. Имитирую дизайн, разработчики свободного программного обеспечения повторяют их ошибки и навсегда лишают себя возможности получить дизайн лучше, чем могут предложить Проприетарные альтернативы.

Решение: поощрять инновационный дизайн через конкурсы и другие публичные мероприятия. Обновить существующие дизайнерские руководства для отображения результатов успешных дизайнерских экспериментов.

Существуют причины плохого юзабилити, которые не зависят от наличия профессиональных дизайнеров. Эти проблемы решить сложнее.

8. Своя рубашка ближе к телу. Добровольные разработчики работают над проектами и функционалом, которые интересны им, что, как правило, означает, что они сами собираются использовать это программное обеспечение. Будучи разработчиками, они в то же время и продвинутые пользователи. Поэтому программное обеспечение, которое задумывалось для общего использования, выходит слишком «гиковым» и сложным. И функции, необходимые больше новым или непродвинутым пользователям, такие как родительский контроль, помощник в установке или наличие возможности импортировать настройки из конкурирующих программ, могут быть заброшены или не реализованы вообще.

Решение: ввести культ простоты, восхваляя умеренный дизайн. Призывать программистов-добровольцев наблюдать за использованием их программ друзьями и родственниками, что вдохновит их решать проблемы других пользователей.

9. Игнорирование мелких недочетов. Множество мелких деталей, которые улучшают интерфейс программы, не вызывают вдохновения или удовольствия от работы над ними. Это такие детали, как например, установка наиболее подходящего размера и позиции окна при первом открытии, фокусировка на установленных по умолчанию настройках открытого окна, хорошие формулировки сообщений об ошибках и другой текстовой информации, с тем чтобы они были более полезными, или придание прогресс-бару более аккуратного отображения длительности процесса. Поскольку такие вещи не вызывают восхищения и удовольствия, проходят годы прежде чем они будут реализованы. Это вызывает у пользователей общее впечатление убогости дизайна, и это может отбить желание участвовать в проекте у обескураженных юзабилити-специалистов.

Решение: в процессе работы над ошибками определять, как долго они существуют. Возможно, решать ошибки интерфейса в первую очередь, если это можно сделать быстро. Вовлекать дизайнеров в процесс планирования исправлений ошибок, чтобы защититься от брешей в юзабилити, заниженных в значимости только потому, что " да это просто UI ошибка".

10. Успокаивание людей опциями. В любом программном проекте с множеством помощников иногда возникают разногласия касательно дизайна. В случае нанятых сотрудников работа обычно продолжается даже при наличии несогласованности. Но в случае с добровольцами, скорее всего лидер проекта согласится успокоить помощника путем добавления настройки конфигурации. Количество, мутность и банальность таких настроек приводит в смущение обычных пользователей, хотя любой наказывается за раздувание конечного результата и ослабление тщательности тестирования.

Решение: строгие лидеры проекта и культ простоты. Системы управления выпусками также должны помогать ослаблять давление, предлагая легкую поддержку своего собственного варианта программы с нужным функционалом.

11. Пятнадцать пикселей славы. Когда добровольцы добавляют новые возможности в популярные приложения, они ожидают получить признание за проделанную работу, чтобы иметь возможность показать кому-нибудь на интерфейс и сказать «это сделал я». Иногда это приводит к появлению новых опций или пунктов меню, для которых в действительности не нужен отдельный интерфейс. С другой стороны, удаление беспорядочных или бесполезных функций может вызвать гнев авторов-разработчиков.

Решение: обеспечить альтернативную огласку, такую как блог, для выражения благодарности участникам. Проводить дизайнерские обзоры тех изменений кода, которые влияют на пользовательский интерфейс. Регулярно осматривать весь интерфейс целиком, спрашивая себя: «Нам действительно необходим это код?».

12. Дизайн широкополосный, Интернет низкоскоростной. Программные проекты добровольцев обычно широко распространены среди участников из разных городов и даже континентов. Поэтому проектное сотрудничество осуществляется, как правило, с помощью текста, по электронной почте, через клиенты обмена мгновенными сообщениями, IRC-каналы или систему отслеживания ошибок. Но коллективный дизайн — многомерный, включает в себя планирование и учет поведения элементов во времени, организацию этих элементов во всем интерфейсе. Когда разработчики находятся в одной комнате, они могут обсуждать взаимный дизайн, используя презентации, прототипы на бумаге, слова и жесты. Но в Интернете это часто невозможно, делая обсуждение значительно более медленным и приводящим к непониманию.

Решение: развивать и продвигать использование VoIP, видео-чатов, виртуальных презентаций, эскизов и анимационного программного обеспечения, которое позволит облегчить обсуждение дизайнерских идей через Интернет. И всегда когда возможно, проводить реальные встречи разработчиков для персонального сотрудничества.

Наконец, некоторые проблемы специфичны для разработки именно свободного программного обеспечения.

13. Выпускай раньше, выпускай чаще, застрянь. Общая практика «выпускай раньше, выпускай чаще» может стать причиной накопления ошибок дизайна. Когда в одной версии программы выполнение операции пользователем осуществляется одним способом, которого придерживаются тестировщики, то они естественно жалуются, когда следующая версия ведет себя по-другому, даже если новое вариант лучше. Это отбивает желание у программистов улучшать интерфейс, и может приводить к увеличению количества непонятных настроек конфигурации.

Решение: публиковать дизайнерские спецификации как можно раньше в процессе разработки, чтобы тестеры знали, что, в конечном счете, ожидать.

14. Посредственность из-за модульности. Хакеры свободного программного обеспечения ценят повторное использование кода. Часто они говорят о написании кода для выполнения только функционала, так чтобы другие программисты могли написать «front end» (или множественные альтернативные «front ends»), позволяющий простым людям пользоваться таким кодом. Они считают это важным для того, чтобы иметь возможность смены любого уровня системы с целью альтернативной реализации. Это хорошо для долгосрочной жизнеспособности системы, потому что позволяет избежать зависимости от какого-либо одного компонента. Но это также ведет к нехватке интеграции, которая в свою очередь ослабляет юзабилити, особенно если интерфейс взаимодействия уровней системы не был разработан с учетом юзабилити. К примеру, большинство терминальных команд не предоставляют информацию о том, насколько завершен процесс или не дают оценку, сколько на это понадобится времени. Это традиционное поведение в терминале, но в графическом программном обеспечении отображение процесса критично. Если графические утилиты разработаны только как «front end» терминальным командам, они не могут с легкостью предоставить эту информацию.

Решение: сначала разработать примерный дизайн графического интерфейса, так чтобы требования интерфейса низкого уровня были известны перед написание кода.

15. Закрытые сообщества разработчиков. Когда вы делаете что-либо на компьютере, вы зависите от программ, разработанных разными командами разработчиков. К примеру, если вы распечатаете эту веб-страницу, чтобы показать кому-нибудь, то выполнение этого задания будет включать в себя работу не только веб-браузера, но и движка шаблона, оконного менеджера, набора инструментов интерфейса, других разнообразных библиотек, графической подсистемы, подсистемы печати, драйвера принтера, файловой системы и ядра, а большинство их этих элементов реализовано различными командами. Зачастую эти команды разработчиков не взаимодействуют друг с другом. И в отличие от их проприетарных конкурентов, они почти всегда имеют разные циклы выпуска. Это делает улучшение юзабилити сложным и медленным в реализации, если для этого потребуется координация изменений между многими частями системы.

Решение: поставщики свободного программного обеспечения могут координировать между собой такие крос-компонентные изменения, если у них есть сотрудники, работающие над всеми соответствующими уровнями программного стека. А добровольные участники разных программных уровней могут встречаться на конференциях для урегулирования этих вопросов.

Это длинный список проблем, но я думаю, что все они решаемы. Следующие несколько месяцев я посвящу обсуждению примеров каждого решения, и что я могу сделать, чтобы помочь свободному программному обеспечению стать успешным.