Расскажите, пожалуйста, о себе. Чем вы занимаетесь в проекте и чем кроме GIMP?

Я Петер Зиккинг, основатель и ведущий архитектор по вопросам взаимодействия (я правда не могу придумать лучшего перевода должности “interaction architect”, прим. пер.) в man + machine interface works. Задача такого архитектора – приспособить программное обеспечение к окружению (в данном случае – к десктопу), сделать так, чтобы оно работало для людей. А также работа с инженерами над реализуемостью решений.

В GIMP я руковожу работами по концептуальным инновациям в интерфейсе. Это значит – дизайн (и редизайн) интерфейса, его описание (см. gui.gimp.org), а также разрешение множества нюансов (от малых до средних) в юзабилити, возникающих несистематически.

Что вас подвигло работать с интерфейсом GIMP, ведь эта работа не оплачивается?

Моя компания занимается дизайном разных интересных штуковин для софтверных и мобильных компаний. В процессе этого мы решаем весьма сложные проблемы. Правда, я не могу вам ничего об этом рассказать, так как это подпадает под NDA (соглашение о неразглашении, – прим. пер.).

Свободное ПО – это предмет свободы, а не цены. Чтобы понять суть, вы должны думать о свободе, как о свободе слова, а не как о бесплатном пиве”. (The Free Software Definition by FSF, англ.).

Работа над GIMP даёт мне возможность разделить со всем миром все детали моей деятельности архитектора – как подойти к сложному, большому проекту и процессу создания инновационных решений во взаимодействии с пользователем.

Когда вы пришли в проект, что вы хотели изменить в первую очередь. Может быть, что-то повергло в шок или сильно удивило?

В то время, когда я присоединился к работе над GIMP, я не использовал его вовсе (равно как и Photoshop). Поэтому у меня не было никакой личной заинтересованности в каких-либо моментах. И это, пожалуй, наиболее здравая ситуация для архитектора интерфейса.

Вместо этого я был действительно заинтересован в интеграции движка GEGL, которая автоматически обеспечивала множество инноваций, таких как редактирование без потерь. Для чего требовался инновационный интерфейс.

В своем личном блоге, в марте 2008 года, вы обещали освещать то, что будет происходить с интерфейсом GIMP, но это была последняя запись, связанная с редизайном интерфейса. С интерфейсом ничего не происходит?

Случилось то, что для компании “m+mi works” 2008 год был очень успешным и очень напряжённым, а это означало, что у меня не было так уж много времени для совместной работы с остальными участниками команды GIMP UI, и уж тем более для написания в блоге о будущем интерфейса GIMP.

Что нового предполагается сделать с интерфейсом GIMP в ближайшем будущем, если можно, с привязкой к версиям?

Первое, чего вы можете ожидать, – это “тэгирование” всех ресурсов (кисти, градиенты, палитры). Это означает, что каждый сможет организовывать и находить ресурсы таким образом, как ему это нравится. Это, в целом, готово и сейчас интегрируется в следующую версию. Я работал над этим в прошедшем году совместно с Aurimas Juska.

Одна из причин, по которой вы можете ожидать, что я буду значительно больше писать в свой блог о GIMP в 2009 году, состоит в том, что некоторые из множества фундаментальных изменений, которые планировались в GIMP, достигают своей критической массы. И я хочу показать, как они затрагивают UI.

Одно из фундаментальных изменений, которое видимо произойдёт скорее рано, чем поздно (в 2.10?), – это введение однооконного режима, который дополнит текущий многооконный режим. Я должен буду спроектировать его совсем скоро…

Какие планы у группы разработчиков GIMP на далекое будущее?

Долгосрочные планы связаны преимущественно с GEGL и возможностями, которые открываются для введения новых методов работы, вместо того чтобы смотреть назад на ужасные “заплатки” из 90-х годов и копировать их.

Кроме того, есть множество других тем, на которые стоит обратить внимание, чтобы реализовать видение GIMP как продукта. Такие как, например, типографика. Или решение серьёзных изъянов UI, к примеру лучшая интеграция свойств инструментов в общую рабочую область.

Как будет происходить редизайн интерфейса, будет плавный переход от версии к версии или в один прекрасный момент пользователи получат совершенно новый по дизайну продукт?

Конечно, изменения будут происходить по шагам, от версии к версии. Иногда шаги будут больше, иногда меньше. Значимость этих шагов будет варьироваться.

Не забывайте, что команда разработчиков GIMP очень мала, по большому счёту это всего лишь горстка людей. Какие технологические изменения произойдут и будут доступны через интерфейс, зависит фактически от энтузиазма нескольких человек.

Как разработчики относятся к проекту «GIMP UI brainstorm»? Идеи, которые люди там публикуют, каким-нибудь образом помогают проекту?

UI brainstorm – это новаторский метод от UI-команды. Он делается не разработчиками и не для разработчиков. Худшая вещь, которую вы можете сделать для юзабилити, это свести пользователей и разработчиков вместе и позволить им обсуждать, что должно быть сделано. UI brainstorm анализируется моей командой, чтобы понять нужды пользователей и потом глубже прорабатывать отдельные полученные от пользователей идеи. Это относится ко всему процессу дизайна интерфейса.

По-моему, у GIMP есть огромный потенциал. Как вы думаете, GIMP способен конкурировать с коммерческими продуктами?

Всё, что должен GIMP – это отвечать видению продукта, как его определила команда GIMP на первой конференции, на которой я был с ними в 2006 году. Я думаю у нас есть хороший шанс реализовать это видение. Это сделает GIMP очень эффективным и понятным в использовании для тех людей, кто попадает в нашу целевую группу.

Большинство пользователей настраивает редактор «под себя». Разработчики думают над тем, чтобы пользователи автоматически, через GIMP, отправляли пользовательские настройки и отчеты об ошибках в Интернет для увеличения удобства и стабильности работы?

Я вижу 3 момента в этом вопросе – тонкая настройка, юзабилити и стабильность. И они никак друг с другом не связаны.

Тонкая настройка – это сугубо личное. То, что работает для вас, скорее всего не подойдёт миллионам. GIMP – это продукт, который должен быть сделан для миллионов людей, каждый из которых – уникален. Я тот, кто обязан это учитывать.

Юзабилити продумывается профессионалами в этой области. Как я сказал ранее, передача запросов пользователей напрямую разработчикам приводит к негативному влиянию на юзабилити. Помимо UI brainstorm существует непрерывная дискуссия с Ellen Reitmayr о том, как реализовать больше инновационных методов работы в GIMP.

Стабильность зависит от сообщений о найденных ошибках и для этого есть баг-трекер…

Как дизайнеры интерфейсов мы хотим, чтобы наши работы хорошо выглядели и были понятными. Каждый элемент на экране должен ласкать взор, и в то же время, интерфейсы – это не просто объекты. Они должны работать. Интерфейсы должны представлять информацию и ясно указывать возможные направления действий. Эти две стороны – сексапильность и функциональность, привлекательность и простота, оформление и значимость – они часто сосуществуют у опытного дизайнера. Но по-прежнему существует опасность конфликта между тем, как это по нашему мнению должно выглядеть и тем, как это будет воспринято пользователем (им бы только о клиентах (customers), нет чтобы о людях подумать… – мысль вслух пер.). Недавно я обратил внимание на такого рода противоречие между оформлением и значением на сервисе GitHub.

Основная навигация на GitHub

После того как вы авторизуетесь на GitHub, общее навигационное меню появится в правой части заголовка. Навигационный блок обрамлён прямоугольником с закруглёнными углами:

Посмотрите на прямоугольник, который связывает весь блок воедино. У него светло-голубой фон, а вокруг он ограничен рамкой серого цвета. Граница и фон декоративны. Они стилизуют блок и услиливают визуальную привлекательность. Чтобы помочь вам увидеть декоративность этих элементов, я сделал на скорую руку сравнение между оригинальным вариантом (сверху) и новой версией без границы и фона (снизу):

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

Контейнеры меняют значение объединяемых элементов

Когда вы помещаете ссылку внутрь контейнера, вы предполагаете связь между контейнером и ссылкой. Технически говоря, вы делаете одно составной частью другого. В качестве более привычного примера, взгляните на ссылки редактирования, которые вы часто видите в web-приложениях:

Две ссылки для редактирования объединены соответствующими контейнерами. Пользователь ожидает, что верхняя ссылка “edit” предназначена для редактирования записи “Michael Bluth”, поскольку ссылка находится в той же ячейке, что и имя Michael-а. Сами ссылки “edit” одинаковы. Разницу создают контейнеры.

Так как же это относится к навигации на GitHub? Проблема со ссылкой (“repositories: all”). На GitHub размещены тысячи открытых репозиториев, открытые для всех и каждого. И в то же время каждый пользователь может иметь свои собственные репозитории. И как раз тут мы находим двусмысленность в дизайне их навигации.

Когда навигационный блок обрамлён, ссылка “все” (“all”) кажется заключённой в рамки активного пользователя. По ссылке вы ожидаете увидеть все репозитории, принадлежащие только этому пользователю.

Сравните это с версией без рамки. Здесь уже не столь очевидно, ведёт ли ссылка “все” к списку репозиториев Michael-а или к основному списку абсолютно всех репозиториев.

Поначалу рамка вокруг блока навигации GitHub выглядела исключительно как вопрос стиля. Теперь мы видим, что эстетические решения могут также воздействовать на понимание дизайна пользователем. В случае с GitHub ожидания созданные обрамлёнными ссылками не соответствуют реальному поведению. Когда вы нажимаете ссылку “all”, вы не попадаете на список репозиториев текущего пользователя. Вместо этого вы оказываетесь в основном списке публичных репозиториев всех пользователей. Оказывается, для того чтобы увидеть список репозиториев активного пользователя, необходимо нажать на его имя рядом с аватаром. Мудрено!

Предложения

Как мы могли бы изменить дизайн, чтобы исключить путаницу?

[..] – первый вариант “редизайна”, предложенный автором статьи, пропущен, так как откровенно плох, особенно по сравнению с нижеописанным, – прим. пер.

Можно сохранить декоративную рамку оригинала и использовать “авторство” для того, чтобы “перевесить” напрашивающуюся логику:

Этот вариант использует 2 ссылки – “все” (“all”) и “мои” (“mine”) – для разделения между основным списком всех репозиториев и списком репозиториев, принадлежащих только активному пользователю.

GitHub – прекрасный сервис. И я знаю, что придираюсь. Но в то же время дизайн пользовательских интерфейсов – дело тонкое. Как дизайнеры, мы должны осознавать, что иногда, когда мы делаем дизайн для глаз, мы можем забыть о дизайне для мозга. Я надеюсь, эти примеры помогут вам лучше чувствовать грань между декоративными элементами и элементами, которые изменяют значение ваших интерфейсов.

Джоно Ди-Карло, сооснователь Humanized, сформулировал свой опыт дизайнера в сподвигающем на размышления, и даже провоцирующем, манифесте (который он назвал “То, во что я верю” These things I believe, – прим. пер.).

В весьма сжатой форме этот манифест выглядит так:

1. Почему мы пишем код? Для людей, не для машин.
2. Чего хочет большинство людей? Не компьютер.
3. Почему разработки терпят неудачу? Их социальный эффект совсем не в том, чего хотят люди.
4. Почему Линукс, будучи бесплатным, не завоёвывает десктопы? “Линукс бесплатен только в том случае, если стоимость моего времени равна нулю”.
   (Здесь перевод слова “free” как “бесплатный” более уместен, нежели “свободный”, – прим. пер.)
5. Пользователи – тупицы? Никогда. Хороший интерфейс прост.
6. Дизайн пользовательских интерфейсов – это маркетинг? Нет.
7. В чём главная задача дизайнера пользовательских интерфейсов? Заставить интерфейс исчезнуть.
8. Где место науки в дизайне пользовательских интерфейсов? Неприменимо и неизвестно. И ей здесь не место.
9. Изменения – благо или зло? Они имеют свою стоимость.
10. В чём вред плохих интерфейсов? Бесполезная трата времени пользователя, нарушение пользовательских привычек, снижение эффективности его работы.

Я согласен со всем вышесказанным, кроме того, что дизайн пользовательских интерфейсов – это всё же маркетинг. Великолепный дизайн интерфейса может быть основой маркетинга. Рекламные буклеты iPhone, которые на самом деле представляют из себя руководство по использованию устройства, – наглядный пример. Отличный интерфейс порождает великолепный маркетинг. И это не дорога с двусторонним движением. Великолепный маркетинг может порождать весьма убогие интерфейсы. Как справедливо заметил Джоно в своём манифесте, неподдающиеся расшифровке интерфейсы микроволновок – отличный пример.

Манифест содержит много больше, чем сделанные мною выдержки. Кое-что оттуда даже разозлит вас. А что-то – рассмешит. Но всё сказанное там обязательно заставит вас задуматься. Так что прочитайте его (перевод полного “манифеста”, о котором идёт речь, я не планирую, – прим. пер.).

Другие переводы на тему пользовательских интерфейсов: Модальность за рамками диалоговых окон, Уроки “плохого” интерфейса

Перевод статьи “A 36:1 ratio is actually pretty good“.

Праздник “День Труда” не так давно прошёл. А это значит, что вы вполне могли получить ссылку на открытый фото-альбом от ваших друзей или знакомых. Вы знаете как это обычно бывает: десятки или даже сотни снимков воскресного веселья.

Но вам-то это неинтересно. Да, это весело снимать и потом смотреть, что получилось и как это было… Но кому хочется просматривать 200 фотографий чьих-то выходных (или фотографий детишек, или ещё какой-нибудь ерунды)? И к чему это приводит? Да вы просто удаляете письмо со ссылкой и не утруждаете себя просмотром ни одной из фотографий.

Сила редактирования

К вопросу о силе редактирования. Что если бы люди выбрали 5 лучших снимков? 5 кадров, составляющих “сливки” всего “урожая”. Пять неоспоримо выдающихся снимков.

И тогда всё изменится. Из рутинного просмотра того, как прошли выходные, это превращается в удовольствие. Это занимает-то всего несколько секунд. Кроме того, это делает возможным просто прикрепить эти 5 снимков к письму и не утруждать вас заходить (и зачастую регистрироваться) на очередной фото-сайт. Всего 5 снимков, делов-то.

36:1

Мой учитель фотографии (Ричард Стромберг /Richard Stromberg/ из Чикагского Фото-Центра /The Chicago Photography Center/) однажды сказал мне:
- Если у тебя получилось по одному хорошему снимку из каждых 36, ты сделал свою работу хорошо.
Это и есть соотношение 36 к 1. Когда вы проделываете столь безжалостный отбор, вы достигаете великолепных результатов. Люди думают, что вы лучше, чем вы есть на самом деле. Это не означает, что вы становитесь блестящим фотографом. Но вы начинаете тренировать вкус и избирательность.

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

Отфильтруй и публикуй

То, что вы отсеиваете – это то, что делает хорошее великолепным. Отсеянное находится в промежутке между чем-то, что либо 1) никогда не встречалось и не использовалось, либо 2) простенько, аккуратно и может быть безболезненно отсеяно. Это верно для фотографии. Это верно для возможностей программ. И это верно для многого другого.

Позавчера я вернулся из небольшого путешествия по Европе (я был в Монако на матче за Суперкубок UEFA и могу с гордостью констатировать, что ФК Зенит – сильнейший клуб старого света в сезоне 2007/08) и привёз множество фотографий, сделанных свежеприкупленным по такому случаю Sony α300. Придя в гости к родителям я попытался было переписать на их компьютер эти фото, но на обоих разделах жёсткого диска оказалось недостаточно места. О чём я и вынужден был с прискорбием сообщить своему отцу буквально в следующей форме:

- У вас места нет для фотографий.
- Где места нет, в Picasa?, – уточнил отец.
- Ну… типа того, – я попытался было согласиться с такой формулировкой.
- Так запиши в Мои документы. Или в мамины, у неё там пусто, – быстро и легко парировал отец.

Тут, конечно, пришлось напрячься и объяснить какие-то непонятные штуки про жёсткий диск, разделы, квоты (которых нет)… Дело не в том, насколько хорошо он теперь разбирается в данном вопросе. Дело в том, что его и до этого нельзя было бы назвать абсолютно неграмотным пользователем. Он ведёт свой тематический блог о недвижимости в нумизматике, своеобразную онлайн-коллекцию (обоими темами он занимается давно и тут ему удалось весьма удачно, на мой взгляд, выбрать свою интересную и необычную нишу. Кстати, на тему упомянутой поездки в Монако он тоже сделал тематический пост). Путём некоторых усилий он постепенно осваивает всё новые и новые для себя интернет-технологии, сервисы. Так почему же так получается, что столь примитивный для многих опытных пользователей случай оказался для него столь трудным в понимании?

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

Мне показалась интересной идея квотирования дискового пространства на уровне приложений. Операционная система могла бы предоставлять соответствующие механизмы. Это, в том числе, ликвидировало бы необходимость использования нескольких разделов жёсткого диска. Наличие одного лишь “диска С” как для системы, так и для данных, перестало бы быть проблемой. Пользователь на этапе установки (или позднее) мог бы установить квоту желаемого размера для Picasa. А для музыкального плеера – квоту совсем иную. Для офисных документов – третью. При этом можно файловое пространство организовывать на основе неких соглашений, предполагающих относительно осознанное именование файлов и каталогов (в т.ч. на основе различной meta-информации – даты и времени фотоснимка, наименования музыкальной композиции и др.). Это оставляет возможность оперировать на уровне обычных системных инструментов (Far manager, mc, bash – no sense).

Если пытаться в общих чертах прикинуть детали реализации подобной подсистемы, то это некий новый уровень абстракции, лежащий выше средств файловой системы, но ниже уровня прикладных приложений. На уровне аналогии могу привести пример HAL (Hardware Abstraction Layer). Реализовывать предложенную технологию на более низком уровне не факт, что рационально, поскольку способ определения дисковой квоты для программы cp, например, сложно представить.

Кстати, примером механизма сохранения бизнес-объектов (веб-страниц) без всякого внимания к системным нюансам является прекрасное (хоть и не без недостатков) дополнение к браузеру Firefox – Scrapbook. Он, теоретически, мог бы иметь хотя бы примитивный механизм ограничения общего объёма сохраняемых страниц, что было бы своеобразным прототипом описанной технологии.

Аза (Aza) не так давно опубликовал заметку о модальных оверлеях (Здесь и далее по тексту используется именно такой перевод слова overlay, наименее “русский”, но зато не искажающий сути данного понятия). О тех самых диалоговых окошках, которые внезапно выскакивают и блокируют то, что находится позади них. Вы полностью свободны в своих действиях в рамках модального окна, но вы не можете использовать ни один “перекрытый” им элемент до тех пор, пока это окно не исчезнет.

Обычно, когда мы говорим о модальных окнах, мы говорим именно о диалогах, таких как на приведённом ниже фрагменте приложения Google Documents. Критика Аза относится как раз к модальным окнам такого рода. После того, как вы открыли диалог поиска/замены, вы не можете кликнуть мышью нигде, кроме как внутри этого диалога. Это означает, что вы не можете пролистать документ, находящийся под диалогом, или скопировать слово из документа и вставить его в строку поиска, не закрывая диалог.

Но это не единственный вид модальных окон. Взгляните на эту панель настроек с сайта me.com компании Apple. Здесь нет ничего, что могло бы потребовать работы с перекрытым им основным содержимым. С тем же успехом это мог бы быть совершенно отдельный экран.

Вообще говоря, именно тот факт, что это мог бы быть отдельный экран, меня и заинтересовал. В 37 (краткое название компании 37signals, – прим. пер.) мы никогда не используем модальные окна. Панель с настройками – это всегда абсолютно независимый экран приложения. Для исследования разницы между этими двумя подходами, я смакетировал альтернативную версию панели настроек от компании Apple, которая использует всё пространство экрана, как это могло бы выглядеть в любом типичном web-приложении.

Интересно сравнить эти две версии. Должен признаться, модальный вариант нравится мне значительно больше. С одной стороны, его значимость более ощутима визуально. С другой – наводит на интересные мысли о навигации.

Модальные окна как альтернатива навигации

Есть два вопроса, которые чаще всего крутятся в нашем сознании при работе с программным обеспечением – “где я?” и “как мне вернуться обратно?”. Есть множество приёмов упростить заботу об этом: вкладки, кнопки “Отмена” и др. Почему бы нам не подумать о модальных окнах, как о средствах решения тех же проблем? Этот механизм исключительно эффективно сглаживает эти нервирующие вопросы. Вопрос “где я?” просто не возникает, поскольку вы не покидаете основной экран. А ответ на вопрос “как вернуться обратно?” попросту очевидно, поскольку основной экран всегда остаётся видимым на заднем плане.

Размер экрана как отражение важности

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

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

Не все модальные окна плохи

В то время как критика Аза по-прежнему справедлива для таких модальных окон, как вышеприведённый пример из Google docs, me.com наглядно демонстрирует, что модальные оверлеи имеют право на существование, как альтернатива принципу навигации между независимыми экранами. Также весьма интересно порассуждать на тему того, какие экраны на самом деле заслуживают полного отдельного окна браузера, а какие из них должны быть выведены в разряд подуровней других экранов. Могу предположить, что когда люди расхваливают приложения за их “десктопность”, этот недостаток навигации между отдельными экранами порождает немало критических замечаний. Apple показал возможность включения “десктопных” принципов в web-приложения без превращения в полный эквивалент “десктопных” систем. Было бы весьма забавно узнать, а где черпают своё вдохновение другие дизайнеры?

Другие переводы статей по юзабилити: Уроки “плохого” интерфейса

В тот день, когда Грубер (Gruber) впервые опубликовал интерфейс TripLog/1040 от Stevens Creek, я был настроен неблагосклонно. Цвета – яркие, элементы управления казались расположенными в совершенно случайном порядке. Это шло вразрез со всем тем, за что ратуют наши дизайнеры. Просто бардак. Вскоре страница на Flickr превратилась в площадку для нападок и оскорблений. Но тут случилось нечто весьма интересное. Дизайнер TripLog Стив Патт (Steve Patt) посреди всего этого потока желчи опубликовал комментарий, в котором поделился той логикой, что в конечном счёте привела к такому варианту дизайна. Те, кто предпочёл его не слушать, ничему не научатся, но остальные могут многое почерпнуть из наводящего на интересные мысли объяснения и двадцатилетнего опыта мистера Пратта в разработке ПО.

Первый упрёк в адрес TripLog – “хаос,” переизбыток элементов на экране. Мы вернёмся к хаосу, но сперва поговорим о скорости. Патт объясняет, что цель TripLog №1 – помощь людям в учёте компенсируемых поездок. Если люди не могут заносить свои поездки оперативно, сложность ввода данных подавляет мотивацию вести учёт. Для покупателей невнесённые данные – это километры, стоимость которых не будет им компенсирована. Поэтому для Патта скорость имеет наивысший приоритет.

Какое отношение имеет скорость к хаосу? Однажды мне довелось побывать на семинаре Эдварда Тафте (Edward Tufte) в Чикаго, где он представлял интересную концепцию. Речь в ней шла о том, что информация может быть представлена как совмещённая в пространстве (adjacent in space) или как перекрывающаяся во времени (stacked in time). Взгляните, к примеру, на книгу. Если две иллюстрации находятся на одном развороте, они расположены как совмещённые в пространстве. Для переключения внимания между ними достаточно поворота глаз. Сравните это с ситуацией когда две иллюстрации расположены на разных разворотах. Вы не можете видеть их одновременно. Вы вынуждены листать страницы туда-обратно для того, чтобы видеть сначала одну, а потом другую иллюстрацию.

Компромисс между расположением элементов совмещёнными в пространстве или перекрывающимися во времени всегда остаётся на усмотрение дизайнера интерфейса. Размещение множества элементов на одном экране снижает необходимость перемещения (навигации) и даёт пользователю полное ощущение того, что “всё необходимое у него под рукой”. Перемещение фокуса с одного элемента на другой происходит мгновенно и легко. С другой стороны, разделение элементов на различные экраны замедляет навигацию, но повышает ясность и чистоту интерфейса. Меньшее число элементов на странице оставляет больше свободного места, которое можно ипользовать для подсказок или более чёткого разделения элементов за счёт пустого пространства. Глазу легче ориентироваться в меньшем числе сущностей. Действия становятся для пользователя более очевидными.

Так слишком ли много элементов Патт расположил на экране? Может быть ему стоило разделить их “во времени”? В самом ли деле его интерфейс “хаотичен”?

Для ответа на этот вопрос мы должны оторвать себя от компьютера и представить себя в шкуре покупателя. Патт объясняет, что покупатели запускают приложение в двух случаях:

1. Они хотят записать только что пройденные километры
2. Они хотят перепроверить, что записали свою недавнюю поездку.

Первый случай очевиден. Патт объясняет второй:

Причина проста и мы знаем её по 20-летнему опыту продаж Дневника Атлета (Athlete’s Diary), приложения для учёта результатов спортивных тренировок. И она состоит в том, что когда вы запускаете приложение, половину своего времени вы будете ломать голову над тем, записали ли вы вчерашнюю поездку на велосипеде или пробежку по парку… И вы хотите иметь возможность немедленно получить ответ на этот вопрос, всего лишь бросив быстрый взгляд на нижнюю часть экрана.

Половину времени люди склонны потратить на занесение новых записей. Другую половину – на проверку и анализ последних записей. К тому же, люди склонны проверять правильность только что внесённых данных. Эти два фактора определяют обоснованность размещения функций “добавление записи” и “просмотр последних записей” на одном экране. Это решение оптимизирует мгновенный доступ к обеим функциям ценой одновременного размещения большего числа элементов на экране.

Следом за первыми впечатлениями…

Когда мы говорим об “удобных” и “интуитивных” интерфейсах, поклонники Apple и сообщество разработчиков веб-приложений (включая меня самого – прим. автора) ориентируются на заботу о начинающем пользователе их сервиса. Идея состоит в том, что интерфейс прост в использовании тогда, когда новый пользователь может без труда его понять и быстро приступить к его использованию. А все части “чистого” интерфейса можно мгновенно пробежать одним взглядом. Как правило, это означает размещение функций “перекрывающимися во времени”, так чтобы каждая экранная форма содержала меньше элементов и была проще в восприятии. TripLog, будучи пусть далёким от идеала, преследует другие цели. Вместо первых впечатлений Патт заботится о повторении. Пространственная память и совмещённость элементов играют ключевую роль в решении многократно повторяемых задач. Многие ли из вас хранят набор ручек, карандашей, бумаг и других канцелярских мелочей в определённых местах стола, вместо того чтобы каждый раз лазать за ними в ящик? Думаю, большинство.

Склонность Патта к смежности и скорости находит своё продолжение и в блоке добавления новой записи (“Add an entry”). Есть 2 основных способа записать поездку: вручную ввести данные в форму или выбрать одну из преднастроенных пользователем “Частых поездок”. Доступны оба метода. Но всё и всегда доступно быть не может. Есть и некоторые “скрытые” функции. Выбор “другой” (Other) даты, а не “Сегодня” (Today) или “Вчера” (Yesterday), выбор другой машины, а также изменение списка частых поездок – использование этих функций требует навигации.

Так чему же мы научились?

То, что экран перегружен, само по себе не означает, что он плохо спланирован или непродуман. Для многих из нас экранные формы, наполненные множеством элементов – как холодная вода, в которую мы бы предпочли не входить. Тот факт, что TripLog – не наслаждение для глаз, подтверждает сложность обеспечения ясности и порядка на экране, излишне прочно ориентированном на совмещённость функций. Это должно быть весьма захватывающим упражнением – переработка дизайна TripLog для большей визуальной ясности без удаления каких-либо элементов.

Но прежде чем критиковать, мы должны обратить внимание на плюсы. При том, что TripLog имеет неудачный стиль, он исключительно хорош в скорости и прагматичности. Патт продумывал своё изделие и умышленно сделал его дизайн именно таким. Следовать моде – это просто. Думать о жизни людей и создавать нечто практичное – гораздо труднее. Патт может поработать над цветами и размещением элементов и, надеюсь, порадовать своих пользователей полезным инструментом. В то же время, остальные должны быть достаточно мудрыми, чтобы поработать над качеством и значимостью нашей критики.

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

Зло скрывается… Точка. Зло – скрывается! Когда все действия понятны пользователю по причине их очевидности, а результат не соответствует ожидаемому – это, вероятнее всего, означает, что содержание выполненных действий (суть реализация) не соответствует ожиданиям пользователя, сформированным вашим же представлением (т.е. интерфейсу). Почему такое вообще случается? Сначала опишу свежий пример из жизни:

В профессиональной деятельности жена моя использует компьютер для двух основных целей (я не беру сейчас в расчёт специализированные отраслевые программные средства, а нарочно говорю исключительно об общеупотребительных):

• работа с электронной корреспонденцией (e-mail)
• поиск и чтение информации в интернете

По первому пункту всё вроде в порядке. Поскольку она отлично понимает суть своих действий, а не обучена как иная офисная обезьянка нажатию на кнопки с жёстко-зафиксированными в памяти изображениями, то она может свободно пользоваться разными почтовыми клиентами. Мелочь? Возможно. Но не сдавайтесь – читайте дальше и мне, надеюсь, удастся передать Вам степень её значимости.

Что касается пункта второго, то обстоятельства так сложились, что поиском необходимых статей она занимается дома (т.е. там, где есть доступ в интернет), а чтением – преимущественно на работе (“по-русски” говоря – в оффлайне). С поиском нужной ей информации справляется вроде бы неплохо. Но вот найдена та статья, которая завтра обязательно понадобится, когда клиент зайдёт узнать, почему же X и Y имеют разные показания к применению при одинаковом составе активных веществ. Что нужно сделать со статьёй с её точки зрения? Сохранить её. И трудно упрекнуть пользователя в нелогичности её действий. А потом она переписывает сохранённые страницы на флешку, приносит их в аптеку, открывает… Где картинки? Куда делись картинки? Что за г***но этот его линукс, он сохранил мне страницу без картинок! (Да, мой линукс – классический виновник всех проблем :)

Легко догадаться, что она переписала на флешку только файл с html-содержимым, совершенно не подозревая о том, что нужен ещё и некий каталог, в котором отдельно сохранены изображения. И её снова нельзя упрекнуть в неправильных действиях. Ответьте себе на вопрос – что она сохраняла? Ответ – страницу. Не файл, не HTML-код. Страницу со всем её содержимым. Т.е. ровно одну(!) сущность. Так откуда вдруг взялась необходимость переписывать какие-то дополнительные каталоги? Это разве логично, интуитивно понятно? По-моему – это просто полная чушь. От пользователя скрыли то, что ему знать не обязательно. Похвальное стремление. Но плохая реализация фактически привела к обману(!) пользователя. Его ввели в заблуждение и сделали это молча, не дав ни малейшей возможности избежать нежелательных последствий.

Вернёмся к электронной почте. Почему здесь у неё не возникает никаких проблем с использованием различных инструментов? Потому как при работе с каждым из них она всегда остаётся в области прикладных понятий, таких как письмо, адресат, папка и т.д. Не выходя за пределы прикладной области в данном случае она имеет полное право вообще не подозревать о существовании файлов или каталогов в файловой системе.

В случае же с сохранённой страницей она, как пользователь, вынуждена была перейти с понятий прикладной области (таких как сайт, страница или запрос к поисковой системе) на уровень файлов и каталогов. И она с ним не справилась не только и не столько потому, что этот уровень ей хуже знаком. А в наибольшей степени потому, что представленная системой (браузер+ОС) логика этого перехода (воспринимаемая как однозначное соответствие “страница->файл”) оказалась совершенно иной.

Выводов из вышесказанного напрашивается сразу несколько.

1. Одним из ключевых показателей качества программной системы с точки зрения Usability является чёткость, с которой в её интерфейсе соблюдены границы её прикладной области. Хороший пример, явно контрастирующий с описанным примером с сохранением страниц – расширение ScrapBook для браузера Mozilla Firefox. Другой, уже озвученный, пример – MUAs (Mail User Agents).
2. В случае, если система содержит в том или ином виде переход от своей прикладной области к некой другой информационной модели (например, модели файловой системы) или наоборот – этот переход должен быть с исключительной тщательностью продуман архитектором и дизайнером.

PS: Ещё один интересный факт: в описанном мною примере все современные браузеры в любой ОС ведут себя как полнейшее г***о.

Как я уже говорил, был сделан выбор в пользу платформы Ruby On Rails. И, разумеется, далее стояла задача выбора подходящей среды разработки. Но не о конкретном сделанном выборе я хочу в первую очередь поговорить (о нём – лишь вскользь и в самом конце), а вот о чём…

При работе над программным кодом разработчик бесчисленное число раз вынужден метаться от одной части кода к другой, расположенной часто в другом файле. Какие средства навигации предлагают вам IDE всех мастей? На 99% это переключение между файлами с той или иной степенью удобства (быстроты) этих переходов. Как правило, степень этого удобства зависит в том числе и от привычек пользователя, а также требует от него непрерывного удержания в оперативной мозговой памяти текущего состояния окружения (какие файлы открыты? какой файл я редактировал перед этим? нужный мне файл ближе к началу или к концу списка открытых? и т.п.). Плюс к тому – переход внутри файла к конкретным типам, методам… тоже, в общем, требующий дополнительных действий по поиску нужной сущности.

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

Альтернатива данному подходу лежит, очевидно, уровнем выше. В одном из вариантов (возможно, существуют и другие варианты абстракции) – это термины той архитектуры, тесно связанные с используемой технологической платформой, на которых вы основываетесь в своей разработке. Этот принцип можно назвать task domain navigation, поскольку основополагающими сущностями в нём являются те, которые присутствуют в вашей предметной области (в данном случае – в той архитектурной модели, которой вы следуете).

И за примером, раз уж я упомянул про Ruby On Rails, далеко ходить не придётся. Поговорим о шаблоне Модель-Вид-Контроллер, практической реализацией которого является фреймворк Ruby On Rails (весьма близкий, кстати, по своим принципам к популярному Apache Struts). Если перед вами стоит задача изменения логики работы некоторой пользовательской формы и изменение логики потребовало внести коррективы и в её представление? Разве логично искать оба (или даже более) нужных вам файла? Сомнительно… А разве не выглядит очевидной необходимость поиска формы (заметьте, это уже скорее термин конкретной технологии, а не шаблона MVC, но я позволю тут себе некоторую вольность раз уж рассуждаю на примере конкретных платформ)? Единократного поиска формы (“дорогой” для пользователя операции) и быстрого переключения между различными её аспектами (логикой обработчиков, представлением, хранимыми объектами)? Для меня ответ очевиден – ДА! И удобными я могу назвать только те инструменты, которые это обеспечат.

PS: Термины computer domain и task domain navigation мною, фактически, не придуманы. Это своеобразная проекция давно известных принципов организации рабочего стола пользователей на специфичную область разработки программных продуктов. В частности, одно из более общих описаний тех принципов, от которых я отталкиваюсь можно найти в этой статье (англ.).

PPS: Итоговый выбор был сделан в пользу связки vim + набор необходимых расширений. Справедливости ради замечу, что соответствующее расширение для GNU Emacs обладает примерно аналогичной функциональностью, чуточку менее эффективной по сравнению с rails.vim. (Лишь в качестве ремарки замечу, что в основной своей деятельности для разработки на Java я использую NetBeans). Если у вас возникнут какие-то дополнительные вопросы по данной теме, я с удовольствием отвечу на них в комментариях.