Детские болезни игровых интерфейсов

1.
Детские болезни:
между младенчеством и взрослыми заботами

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

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

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

---

Собравшиеся в этом зале, очевидно, имеют опыт проектирования интерфейсов. Однако, как нам кажется, даже вы не сразу ответите на некоторые "простейшие" вопросы. Ну, давайте – в качестве легкой разминки: возьмем обычную интерфейсную кнопку. Ясно, что она может быть нажата и отжата, то есть пребывать как минимум в двух состояниях. А какие еще графически выделенные состояния интерфейсной кнопки вы можете назвать?

Итак, совместными усилиями мы вспомнили, что кнопка может быть не-активна (disabled), реагировать на наезд курсора (mouse over), может быть выбрана по умолчанию (default), может быть выбранной мышью или с клавиатуры сознательно (selected). Плюс сочетания, плюс варианты для нажатой кнопки – итого мы получаем дюжину состояний. Однако, не все из формально вычисленных состояний имеют равные права на существование.

Во-первых, кнопка, которая осталась зажатой после нажатия – не кнопка вовсе, в чекбокс, выполненный в виде кнопки. То есть состояния, отмеченные желтой стрелкой, относятся именно к такому чекбоксу. А состояния, которые отмечены красной стрелкой, вообще бесполезны – нелегко представить себе пользу элемента "чекбокс выбранный по умолчанию". Вид же "настоящей" нажатой кнопки не столь прост, как мы нарисовали вначале – помимо графической информации о своей "нажатости", кнопка продолжает нести информацию о своей "избранности" (selected).

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

---

Не стоит думать, что "младенческими" вопросами мучаются только начинающие. Даже в очень известных программных продуктах вы можете встретить многочисленные неувязки такого сорта. Например, взгляните на диалог выбора параметров шрифта программы MS Word. Можно заметить, что многие из чекбоксов группы Effects (например, Subscript / Superscript) на самом деле таковыми не являются, поскольку взаимоисключают друг друга, то есть являются по сути радиокнопками.

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

---

Итогом нашей разминки должно стать понимание нескольких практически важных идей.

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

Во-вторых, нужно особо отметить значительное количество дополнительной информации, которую может предоставить пользователю компьютерный интерфейс в сравнении со своим физическим прототипом (в нашем примере – обычной кнопкой). Вот почему столь беспомощны бывают попытки симулировать в интерфейсах физические объекты.

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

Читать дальше >>