Читать онлайн «Человеческий фактор в программировании». Страница 77

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

Для чего же нам нужна вся эта абстракция? Так жв как объектно-ориентированные программисты превращают формы в классы и аннотации в код, так и мы хотим видеть, как контексты взаимодействия преобразуются в реальные компоненты: экраны с линейками прокрутки и инструментами редактирования, текстовые редакторы с меню и панели инструментов со множеством «интуитивных пиктограмм». Тогда зачем проходить через все эти промежуточные этапы абстрактных моделей и символических переходов, когда можно просто перетащить нужную «штучку» в форму, проектируемую в Delphi?

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

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

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

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

Как любил отмечать французский пуантилист Жорж Сера (Georges Seu-rat), именно пустой холст, а не законченный портрет наводит на изобретение нового. Наверное, пришло время для того, чтобы объектно-ориентированная технология применила силу абстракции к проблеме взаимодействия.

По материалу из журнала Object Magazine, декабрь 1996 г.

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

С другой стороны, если объектная технология способна обеспечивать рационализацию и упрощение процесса разработки и проектирования, если она действительно позволяет создавать системы, более полно отвечающие потребностям наших пользователей, тогда программное обеспечение, которое является просто «хорошим», — это не совсем то, что наши покупатели по праву ожидают получить. Объектно-ориентированное программное обеспечение должно быть узнаваемым для пользователей, но не по знакомой неуклюжести его интерфейсных классов или по упоминанию Smalltalk или С++ на коробке, а по более широким возможностям, предоставляемым пользователям, и более эффективному и совершенному способу их представления. При разработке пользовательского интерфейса нет поводов не применять новые методы повышения эффективности и расширенные возможности доработки и повторного использования компонентов, которые дает объектная технология.

В таком случае, как именно следует применять наши отточенные умения и мощные инструменты? Какую форму могут иметь новые, удобные интерфейсы? Как приступить к изменению способов взаимодействия между пользователями и нашими объектно-ориентированными системами?

Как нам говорят, непротиворечивость является критерием хорошего пользовательского интерфейса (см. главу 34). Пользователи предпочитают интерфейсы, которые выглядят и работают подобно уже известным им интерфейсам. Такие интерфейсы для них более комфортны. Каждое предполагаемое новшество, каждое новое устройство или средство наталкивается на высокий барьер в виде некоторого естественного сопротивления. Даже более совершенные интерфейсы могут категорически отвергаться пользователями, которые не хотят или не могут научиться новым способам взаимодействия со своими компьютерами. Пользователи Apple Macintosh хорошо известны тем, что всегда настаивают на непротиворечивости и отвергают программное обеспечение с «немакинтошевским» поведением или функциями. Но многие ли сейчас помнят, что среди первых тестеров ОС Macintosh нашлись такие, которые посчитали ее крайне неудобной, ставя в вину отсутствие стандартных команд и какого-либо из принятых приглашений вида «С:›».