Проектирования. Во многих случаях действует правило «чем больше - тем лучше»

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

Проектирование гармоничного взаимодействия 247

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

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

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

Классическая книга Маллета (Mullet) и Сано (Sano) «Designing Visual Interfaces» (Mullet and Sano, 1995) содержит плодотворное обсужде-

248 Глава 10. Оркестровка и состояние потока

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

Минималистичный подход к проектированию продуктов неизбежно связан с четким пониманием назначения: чего пытается достичь пользователь, применяя инструмент? Без понимания назначения интерактивные продукты - не более чем неорганизованное нагромождение функций, демонстрирующих работу технологий. Показательным примером того, как глубокое понимание назначения привело к созданию минималистичного пользовательского интерфейса, является поисковая система Google, где есть лишь текстовое поле, две кнопки («Поиск eGoogle», отображающая перечень результатов, и «Мне повезет!», выполняющая переход к первому сайту из результатов поиска), логотип компании Google и пара гиперссылок на вселенную функций Google (рис. 10.1). Другой хороший пример минималистичного пользовательского интерфейса - iPod Shuffle. Компания Apple, определив со всей тщательностью набор уместных возможностей, служащий конкретным потребностям пользователей, создала превосходный по удобству продукт с одним переключателем, пятью кнопками - и без экрана! Невероятно простой текстовый редактор WriteRoom (Hog Bay Software) вообще не имеет пользовательского интерфейса - только область, в которой можно набирать текст. Текст сохраняется автоматически, избавляя от необходимости иметь дело с файлами.

Рис. 10.1. Знаменитый поисковый интерфейс Google - классический пример минималистичного проектирования интерфейса, в котором каждый элемент на экране содержателен и понятен

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

Проектирование гармоничного взаимодействия 249

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

Позволяйте пользователям управлять, не принуждайте их

принцип к диалогу.

Дата добавления: 2015-10-24