Kicking the Llama

Кикнуть заигноренного

http://okcancel.com/archives/article/2003/...he-llama-2.html

Кевин Чен, 10 октября 2003 года

(IMG:http://okcancel.com/strips/okcancel20031010.gif)

Диалог на картинке:
Босс: - Во время моего отсутствия, я дал тебе свободу с дизайном пользовательского интерфейса. Можешь мне его показать?
Босс: - Хм... Что это?
Программистка: - Что это значит? Да это же наш CD-плеер!!! Эй! Не надо на меня так таращиться! Я такой же пользователь, как и все!

Джоэль Спольски – известный разработчик ПО, который пишет на своем веб-сайте материалы, описывающие разработку ПО от проектирования интерфейса до управления проектом. Недавно он опубликовал книгу, где собрал свои статьи, написанные в последние несколько лет. В этой книге, озаглавленной как «Разработка пользовательского интерфейса для программистов», обсуждается, как программистам следует перестать бояться разработки пользовательского интерфейса (UI) и подчеркиваются некоторые направления и правила для демистификации проектирования UI.

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

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

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

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

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

Эта книга может помочь программистам создать свой собственный UI, когда у них нет доступа к консультантам по HCI, но что же они будут делать? Как книга, подобная этой, повлияет на взаимодействие между HCI и программистами в целом? Давайте во-первых, взглянем на программистов в общем.

Из моего опыта, существует четыре основных класса проблемных программистов, с которыми мне приходилось работать:
Энтузиаст: те, кто стремится идти на поводу требований HCI. Эти разработчики с удовольствием работают над сложными задачами, но любят иногда тратить слишком много времени на вылизывание несущественных аспектов UI;
Угадывальщик: те, кто ничего не понимает, но считает себя полностью компетентным и разрабатывает совершенно непригодные вещи до тех пор, пока не станет слишком поздно, чтобы что-то изменить;
Нильсен: те, кто постоянно цитируют правила юзабилити из Норманна, Нильсена или даже Джоэля Спольски, чтобы оспорить решения по UI;
Напуганные: те, кто тратит больше времени на споры, насколько трудно будет сделать задачу, чем на время, которое бы потребовалось на действительное выполнение задачи. Их первой линией обороны является попытка так изменить требования, чтобы они совпали с их программной моделью, вместо того, чтобы взяться за работу над задачей. Вы уже начинаете думать, что они боятся любого UI.

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

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

Управление Угадывальщиками является проблемой регулярно общиения с ними, чтобы быть уверенным в том, что они понимают требования правильно. Ответственность лежит на обеих сторонах; программисты должны задавать вопросы при любом намеке на двусмысленность, а HCI должны регулярно выполнять то, что я называю «Читать UI код». Точно так же программисты убеждаются в правильности своего архитектурного дизайна через чтение кода, они могут убедиться в правильности реализации UI вместе с HCI.

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

И, наконец, Напуганный – вероятно, он наиболее опасный член команды. Проблема с Напуганным состоит в том, что его приоритетом является программная модель. Говоря терминами Джоэля, программная модель превалирует над всем другим. Если вы требуете выпадающее меню, отсортированное особенным способом, Напуганный может объяснить, что это просто не может быть сделано вследствие структуры базы данных. Давайте забудем на минутку, что база данных должна быть разработана в соответствии с требованиями UI. В конце концов, многие проекты растут, имея дело с устаревшими артефактами, доставшимися по наследству. Решение состоит в коммуникации – с чем? Здесь риск заключается в неспособности HIC специалиста разоблачить отговорки программиста. Если бы я не был техническим специалистом, я бы должен был принять на веру слова Напуганного и таким образом, приспособить свои требования, вместо того чтобы оспорить его отговорки.

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

HCI консультант мог бы облегчить такие переговоры, если бы он был технически подкованным, хотя, с другой стороны, разработчикам легче понять базовые концепции UI, чем дизайнеру изучить нотацию «Большого-О»; что возвращает нас опять к Джоэлю.

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

Возможно, лучшее полное взаимопонимание между разработчиками поможет в этой коммуникации.

Я оставлю вас поразмышлять об архетипе Нильсена. Целевая аудитория Джоэля довольно малознакома с UI, так что его книга является все-таки вводной. Есть несколько, если это возможно, заслуживающих внимание «правил», которых еще не касались ранее. Однако, утверждая набор правил и аксиом для программистов, он несет довольно большой риск. Программисты изначально имеют логический склад ума. Особенно, цифровая логика является областью, где они работают и в терминах которой они думают. Есть 1 и есть 0, и редко – что-то между ними. Так что, когда утверждение представлено как правило, оно может быть понято слишком буквально.

Читая другие статьи Джоэля, я понял, что он не собирался предоставлять в них много жестких и быстрых правил как способ обучения разработчиков. Его книга может рассматриваться как набор общих указаний для формирования структуры мышления. Единственная выгода от правил, цитируемых программистами типа «Нильсен», состоит в том, что они, возможно, представляют санитарный кордон для HCI. Дизайнеры определенно не являются безупречными и у нас редко есть второй HCI специалист, чтобы получить обратную связь. Оставленные наедине с нашими устройствами, мы часто совершаем ошибки и несогласованные действия. Я советую разработчикам правила, которые они взяли на сайте Джоэля, на сайте Джейкоба, на UIE или где-то еще, применять как общие указания и предоставить нам механизм рациональной обратной связи.

Примечание: (по-видимому, это сленг с ПРАВИЛА ПОВЕДЕНИЯ НА CS\HL-СЕРВЕРАХ КОМПАНИИ Cs-TableT

2.3. Kick - отключение игрока с сервера без лишения права игрока вернуться на сервер.
2.7. Llama – игроку меняется ник на llama и лишается возможность общаться say/say_team

Сообщение отредактировал Yukon - 20.1.2010, 8:37

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