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

8.
Некритичное восприятие готовых решений

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

---

Боязнь разрушить магическое единство

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

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

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

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

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

---

Даже устоявшиеся решения могут быть несовершенны

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

Оцените, например, широко распространенное построение диалогов с кнопками OK, Cancel (Отмена) и Apply (Применить).

Пусть пользователь что-нибудь "подергал" в диалоге и после этого обратил внимание на командные кнопки внизу. Нажмет "ОК" – внесенные изменения вступят в силу, нажмет "Cancel" – отменит свое неразумное воздействие. Пока все нормально. Но вот мы нажимаем кнопку "Apply" – как вы думаете, что после этого происходит? Отвечаю – наступает полный хаос.

Теперь кнопка "ОК" ничего не делает, только закрывает диалог – то есть это кнопка "Close" (Закрыть). Но с кнопкой "Cancel" дела обстоят еще хуже, она уже не способна спасти пользователя от ранее совершенного неверного действия – эта кнопка ничего не отменяет, метаться поздно! Теперь это всего лишь еще одна кнопка "Close".

А ведь правильное решение лежит на поверхности – достаточно переименовать кнопку "Apply" в "Preview" (Предпросмотр) и обеспечить откат к прежнему состоянию по команде "Cancel" – и все заработает как надо.

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