Поделиться

понедельник, 1 февраля 2010 г.

Игры vs. остальное ПО: интерфейс или чему у чего поучиться?

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

На самом деле, безумной идея кажется только с виду. Вспомним, что компьютерные игры вышли изначально из университетской среды, то есть их делали, в общем, умные люди. За все эти годы игры эволюционировали. Мне еще не доводилось слышать выступлений под лозунгом "игровой интерфейс в текстовые редакторы", зато:
  • уже отовсюду слышатся новости о том, что правительства США и стран Западной Европы выделяют деньги на игры для тренировки своих военных и других специалистов;
  • валом идут статьи о роли интерактивных и, в том числе, компьютерных игр в развитии младших и прочих школьников и студентов;
  • только что проходил тест Are You Certifiable? (Достойны ли Вы сертификации?) от Microsoft, выполненный в виде вариации на тему игры "Кто хочет стать миллионером?" (и многих ей подобных) - довольно забавно.
Замечаете тенденцию? Так что пока "просвещенные" мира сего в области взаимодействия, такие как А.Купер и Д.Раскин говорят о том, что неправильно в современных интерфейсах ПО, и пытаются изобретать новые парадигмы (или реанимировать "забытые общеизвестные", которым, правда, никто и никогда не следовал):
К сожалению, перечень из сотен функций, к которому сводится интерактивный продукт, слабо пригоден для создания тонкой гармонии, которая делает сложную технологию полезной. Добавление в перечень требований фразы "должен быть простым в использовании" никоим образом не улучшает ситуацию. - Купер А., Рейман Р., Кронин Д. Алан Купер об интерфейсе. Основы проектирования взаимодействия. - СПб.: Символ-Плюс, 2009.
В основе разработки хороших интерфейсов лежат некоторые основные принципы, которые на сегодня не являются общеизвестными. И вопрос о необходимости изучения этих принципов не возникает, поскольку кажется, что уже определено, как должны выглядеть и работать интерфейсы: ведь они непрерывно совершенствовались в течение двух десятилетий, основные разработчики программного обеспечения опубликовали руководства по созданию интерфейсов, чтобы обеспечить совместимость между ними, а существующие средства разработки позволяют быстро создавать любые интерфейсы, которые выглядят по современному... - Раскин Д. Интерфейс: новые направления в проектировании компьютерных систем. - Пер. с англ. - СПб.: Символ-Плюс, 2007.
Я возьму на себя смелость утверждать, что изобретать новые подходы не требуется, поскольку они уже давным-давно существуют и успешно реализуются в той части цифровых продуктов, которые называются развлекательными. Оцените иронию или, точнее, сарказм ситуации: в игре, скажем, Dragon Age: Origins я могу повысить характеристики своих персонажей, одеть их в новую броню, дать им новое оружие, предварительно оценив его характеристики, и наложить все нужные заклятья за пару минут... и та же пара минут (в лучшем случае, а в худшем - намного больше) уйдет у меня на то, чтобы в очередной раз найти в справке по Microsoft Word комбинацию действий, позволяющую отменить эти несчастные переносы, или другую комбинацию действий для объединения фигур нужным образом в справке по Corel Draw. Кстати, двумя минутами мои сложности при взаимодействии с этими программными продуктами не ограничиваются, потому что до того, как я полезу в справочную систему, я еще 5-7 минут буду силиться вспомнить, как сделать то, что мне нужно, без залезания в нее. Я столько раз уже проделывал упомянутые для примера действия в упомянутых программных продуктах, что подумать страшно: с Corel-ом и Word-ом я провел времени куда больше, чем, наверное, со всеми играми вместе взятыми за всю жизнь, но это не помогает: интерфейс меняется от версии к версии и пункты меню мигрируют, появляются и исчезают, а справочная система на любой четко поставленный вопрос пытается подсунуть ответ под обнадеживающим заглавием "Новые возможности MS Word XXXX" (или "Corel XXXX") - видимо, она "считает", что это универсальный ответ на все вопросы, который меня в любом случае устроит, или, что в крайнем случае я сдамся. - Нет! Не устроит! Информация о том, что "теперь можно печатать в любом месте", никак не помогает мне в устранении переносов из уже напечатанного. Ей Богу, иногда складывается впечатление, что справочная система не то, чтобы искала и не нашла нужное, а просто и не пыталась (поучиться бы создателям справочных систем у Google что-ли в смысле поиска по заданным словам)! Впрочем, документация вообще и поиск в частности - это отдельная тема. Лично мне кажется, что нужно как-то законодательно установить "Всеобщий мировой стандарт по реализации функции полнотекстового поиска" для любого ПО, включая отдельные веб-сайты и поисковые системы, а потом военной мощью, шантажом и подкупом заставлять всех разработчиков ему следовать. Конечно, я утрирую, но другого выхода нет. Вернемся к играм и "нужному" ПО. Есть несколько фундаментальных различий между этими типами продуктов:
  • Игры не предназначены для тех, кто должен их использовать - они предназначены для тех, кто хочет их использовать, поэтому разработчики обязаны не просто наляпать интерфейс, а сделать его как можно более удобным. Да, в случае игр характеристики "симпатичный", "удобный", "функциональный", "эффективный" и "реализованный" относятся к одному интерфейсу, а не к разным! Если пользователь запутался в интерфейсе игры в первые 3 минуты и не распутался за последующие 10 - следующий ваш продукт он не купит, а если он похож на меня, то успеет еще написать кучку пасквилей о нынешнем продукте, чем отобьет охоту платить вам за него у некоторого количества людей (и будет воспринимать это как справедливую месть)!
  • На некоторых играх стоит маркировка "12+" или даже "7+". С точки зрения содержания игры это означает, что в нее могут играть дети, а вот с точки зрения реализации взаимодействия все интереснее, потому что в нее могут играть не только дети. В таком случае разработчики обязаны (и у них нет другого выхода) обеспечить такой интерфейс, чтобы и детям было не сложно, и взрослым комфортно. Это та еще задача, и без исследований и всестороннего проектирования взаимодействия здесь не обойтись (кстати, это наводит на мысли о том, что и телевизионные программы можно делать такие, чтобы и детям была забава, и взрослые не опасались за свой рассудок - на сегодняшний день телевидение об этом не подозревает, поэтому, чем более программа "детская", тем дальше она от "нормальной" для взрослого восприятия). Успешных примеров реализации такого подхода - масса:
    Little Big Planet на Playstation 3

    Loco Roco 1 и 2 на PSP

    и др.

    В случае с "нужным" ПО такой необходимости нет.
  • При организации взаимодействия в играх разработчики ориентируются на парадигму восприятия игры или жанра, к которому она относится, пользователем. Чтобы надеть на героя броню, вам не нужно последовательно щелкать на командах "Открыть каталог "Герой" -> "Перейти в подкаталог "Инвентарь" -> "Открыть файл "Супердубина.aaa" -> "Сохранить "Супердубина.aaa" в подкаталог "Герой/Торс Героя". Действия в играх связаны и основаны на терминологической базе самой игры, включающей, например в случае с RPG, такие понятия как: "предмет", "одетое", "оружие", "броня", "здоровье", "мана", "сила" и так далее. Здесь "Супердубина" - это не файл "Супердубина.aaa", в котором описана форма и числовые характеристики игрового предмета под названием "Супердубина" - это просто Супердубина (или Супердубина+1), оружие, которым бьют врагов, и вам не нужна электронная таблица или калькулятор, чтобы просчитать, что оно лучше, чем все имеющееся у вашего героя. В случае с "нужным" ПО ситуация кардинально иная: интерфейс строится из готовых элементов управления, они выстраиваются по заранее определенным схемам (иногда автоматически), операции производятся над файлами, пункты меню имеют шаблонные названия (хотя и ведут себя часто по-разному - это вообще маразм). Считается, что если выстроить взаимодействие на основе такой парадигмы, то сами по себе выплывут и будут гарантированы "удобство" и "эффективность" программного продукта вне зависимости от его назначения, чего не происходит, и, если вдуматься, не может происходить. Разница между подходами, применяемыми при проектировании игр и другого ПО здесь - это классическая разница между парадигмой реализации (компьютера, программы, операционной и файловой систем) и парадигмой восприятия (сути и понятийной базы, связанных с тем, что именно вы делаете - уничтожаете демонов или разгадываете головоломки).
Маленькое замечание: когда я говорю об игровом подходе к проектированию приложений, я не имею в виду "раскрасить" традиционные окна и этим ограничиться - указанный подход требует переосмысления самих основ проектирования.

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

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

Комментариев нет:

Отправить комментарий