Человеческий фактор в программировании - Ларри Константин

Разные инструменты и методы и даже разные правила и принципы можно применять в переходном интерфейсе, но не в интерфейсе приобретения и интерфейсе производства. Юзабилити-тестирование (глава 36), в котором исследуется взаимодействие пользователей с системой, может помочь точно настроить интерфейс приобретения. Однако, скорее всего, такое тестирование не будет полезным для переходного интерфейса и интерфейса производства. Почему? Потому что к тому времени, как начинающий пользователь превратится в середнячка или эксперта, в видеокамере уже закончится пленка или у психолога рассеется внимание.

Благодаря хорошему проектированию и всестороннему юзабилити-тести-рованию в некоторых ГПИ удалось создать разумный интерфейс приобретения. Например, интерфейс в Apple Macintosh был разработан так, что-бы с момента открытия упаковки до начала выполнения полезной работы проходило не более 20 минут.

Проблема состоит в том, что по мере прогресса пользователя типичный интерфейс остается неизменным. Начинающие пользователи системы нуждаются в программных учебных роликах. Ролики помогли многим детям научиться ездить на велосипеде, но они не предназначаются для постоянного использования. По существу, такие ролики не помогают детям научиться ездить на велосипеде. Они учат ездить на велосипеде с присоединенными опорными роликами! Для формирования навыков равновесия и движения на велосипеде опорные ролики нужно снять.

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

Ладно, поеду кататься на лыжах!

Из журнала Software Development, том 1, № 2, февраль 1993 г.

39

Пригодны ли вы

2.70! Это число может вам ни о чем не говорить, но курс машиностроения, который обозначен этими цифрами в Массачусетском технологическом институте, довольно знаменит. Студенты получают наборы разнообразных деталей и затем соревнуются в проектировании и построении лучшего робота, собирающего шарики для пинг-понга, или компьютеризированного передвижного моста, или другого устройства, выдуманного преподавателями. Профессор Вуди Флауэрз (Woody Flowers), научный сотрудник Государственной службы радиовещания (Public Broadcasting System, PBS) и основатель курса 2.70, хочет помочь будущим конструкторам и инженерам создавать более практичные продукты, которые действительно работают для человека. Его университетские курсы способствовали организации соревнований между студентами высшей школы. Даже учеников средней школы он вооружает видеокамерами для того, чтобы вокруг себя они находили и документировали недружелюбные для пользователя или просто непригодные конструкции и схемы.

Если бестолковое проектирование так легко распознать, то почему на миллионах индикаторов видеомагнитофонов или микроволновых печей по всему миру загораются цифры 12:00 или 88:88? Почему программное обеспечение, основанное на ГПИ, не ускоряет нашу работу? Несмотря на созданные «отделы изучения человеческих факторов» и «лаборатории юзабилити-тестирования», ведущие производители продолжают выпускать глупое программное обеспечение с серьезными изъянами в юзабилити, которые даже двенадцатилетний ребенок может заметить с другого конца комнаты.

Представьте: мой компьютер сообщает, что 8 283 файла занимают почти 550 Мбайт дискового пространства (о, конечно, это были старые добрые времена… еще до появления Win95 и 98). Для удержания лидерства в области консультирования необходимо разбираться в этих цифровых джунглях и находить в них нужный материал. Размер файла и дата его создания зачастую помогают быстрее найти нужную версию или вариант, поэтому нам нужно видеть эти данные, когда мы собираемся открыть файл из приложения. При открытии или сохранении файлов, когда мы видим их и думаем о них, нам удобнее всего заниматься уборкой в доме — перемещением файлов или папок, переименованием или удалением. Каждый знает об этом, но только небольшая часть продуктов предоставляет такую возможность. Нам необходимо расширение/дополнение, способное стандартизировать и расширить набор диалогов «Открыть», «Сохранить», «Сохранить как» в Windows. Каждое приложение должно отображать информацию о статусе файлов и их описание непосредственно в диалоговых окнах, а также поддерживать в них выполнение рутинных операций с файлами.

Это хорошая идея. В некоторых больших продуктах эта возможность предусмотрена. В одном из таких чудесных пакетов вы можете нажать Ctrl-O, и в верхней левой части диалогового окна открытия файла (там же, где и всегда) появляется знакомое комбинированное окошко для выбора имени файла. Внизу располагается прокручиваемый список файлов, в котором, как всегда, видно слишком мало файлов и совсем не видно их статуса. Выделите одно из имен файлов, и в сером окне внизу справа (!) появится дата, время создания и размер выделенного файла. За раз можно увидеть описание только одного файла. Нужно постоянно переключать внимание между верхней левой и нижней правой областями экрана. Два разных и далеко отстоящих друг от друга визуальных элемента приходится мысленно совмещать; описания файлов нельзя сравнивать без запоминания; вместо быстрого и легкого просматривания списка нужно выполнять неудобную, последовательную, механическую операцию. Такая неразумная конструкция нарушает основные принципы дизайна интерфейсов и не позволяет пользователю выполнять свою работу.

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

Должностные обязанности

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