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

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

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

Из журнала 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, и в верхней левой части диалогового окна открытия файла (там же, где и всегда) появляется знакомое комбинированное окошко для выбора имени файла. Внизу располагается прокручиваемый список файлов, в котором, как всегда, видно слишком мало файлов и совсем не видно их статуса. Выделите одно из имен файлов, и в сером окне внизу справа (!) появится дата, время создания и размер выделенного файла. За раз можно увидеть описание только одного файла. Нужно постоянно переключать внимание между верхней левой и нижней правой областями экрана. Два разных и далеко отстоящих друг от друга визуальных элемента приходится мысленно совмещать; описания файлов нельзя сравнивать без запоминания; вместо быстрого и легкого просматривания списка нужно выполнять неудобную, последовательную, механическую операцию. Такая неразумная конструкция нарушает основные принципы дизайна интерфейсов и не позволяет пользователю выполнять свою работу.

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

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