Юзабилити: как сделать сайт удобным

Проектирование программного обеспечения и интерфейса

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

В начале создания программного продукта необходимо обдумать и сформулировать требования к графическому интерфейсу.

Программный продукт должен предназначаться некоторому ги­потетическому пользователю. Например, вспомните кота или скрепку — «помощников» в последних версиях MS Word. Мож­но предположить, что компания Microsoft при разработке интер­фейса этой программы исходила из того, что работать с ней бу­дут малоопытные, начинающие пользователи.

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

Поскольку пользователи Web обладают разными компьютерами, разрешениями монитора, мышами, принтерами, то интерфейс должен обеспечивать удобное и правильное взаимодействие со всем этим оборудованием. ^Го же самое касается и программного обеспечения, в частности браузеров.

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

Что можно безболезненно удалить из такого телефона, чтобы он не лишился своего прямого предназначения? Все, что угодно, только не звонок, не микрофон, не динамик и не возможность связаться с другим абонентом, набрав его номер. Прямое пред­назначение телефона — быть телефоном, а уже потом фотоаппа­ратом, записной книжкой, будильником и всем остальным. Если вы создаете текстовый редактор, вы Можете сколь угодно долго отыскивать иконки покрасивее, но вы никак не можете убрать из интерфейса возможность сохранять файлы.

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

Та часть требований, которая есть «телефон» в телефоне, кото­рую никаким образом нельзя исключить, без которой система теряет свой смысл, обеспечивает концептуальную целостность Системы. Концепция системы неразрывно связана с предметной областью[2]. А интерфейс системы служит, в свою очередь* Для поддержания предметной области приложения в полном объеме.

Концептуальная целостность системы будет нарушена, если мы поддержим в «Электронном телефонном справочнике» ВОЗМОЖ­НОСТЬ сканировать и сохранять документы, Может, вам и удастся встроить такую функцию, но это нарушит понимание самой сис­темы и ее интерфейса пользователем. Поддержание подобны* функций если и выгодно для кого-нибудь, то не для системы и не для вас. Примером грубейшего нарушения концептуальной це­лостности может быть идея вмонтировать тостер в телевизор. Это может быть удобно для тех, кто любит поесть за хорошим фильмом румяные хлебцы, но телевизор и все его составляющие должны улучшать изображение и звук, а не качество еды.

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

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

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

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

Часто реализацию стремятся сделать как можно более легкой (особенно в том, что касается интерфейса), чтобы едва ли не ди­зайнер смог писать полноценные системы или их части. Именно по этой причине начали изобретать визуальные среды разработ­ки интерфейсов, визуальные редакторы и т. п. Наверняка вам не раз приходилось видеть: «Самая простая и легкая в настройке система управления контентом сайта!!!» Эти объявления рассчи­таны именно на те компании, которые хотят, чтобы один Web-ди - зайнер мог работать и как программист, и как специалист по ин­терфейсам, и как HTML-кодер. На самом деле так не бывает, но многие в это свято верят.

Во время программной реализации системы, особенно если она не новая, почти всегда происходит ее рефакторинг. Рефакто­ринг — изменение программных решений без принципиального изменения основных функций и внешнегр вида (если, конечно, речь идет не о рефакторинге интерфейсных решений). Простей­шим примером может служить перевод сайта на язык XML. Представьте себе, что ранее сайт был написан на чистом HTML, а затем он так разросся, что поддерживать его стало трудно, и было принято решение использовать технологию XSL/XML для генерации HTML-страниц. Внешний вид сайта останется прежним, но изменится способ создания и передачи браузеру пользователя информации. Возможно и обратное явление: сама логика работы сайта останется прежней, но после многочисленных нареканий со стороны пользователей, дизайнеров и специалистов по юзабилити интерфейс системы необходимо будет переделать.

Приступать к тестированию необходимо с самых ранних стадий создания программного продукта. Это же касается и тестирова­ния приложений. Начинайте пораньше И избежите осложнений.

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

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

Если программисту были переданы требования к интерфейсу и удобству использования, то необходимо обязательно прове­рить их выполнение: "везде ли есть всплывающие подсказки, проставлены ли ріазмерьі картинок, правильно ли работают не­стандартные идеи, поддержана ли переносимость системы (напри­мер, в разных браузерах) и т. п. Некоторое отношение к интерфейсу пользователя имеют и другие виды тестирования: тестирование производительности, нагрузочное и стрессовое тестирование, тестирование надежности и запаса прочности при работе в ре­альных условиях, проверка степени безопасности и уязвимости программного продукта, легкости развертывания и размещения, настройки и обновления, анализ сетевого трафика в условиях конкретной сети и т. д. В рамках данной книги мы подробно рас­смотрим тестирование юзабилити.

Резюме

1. Существуют разновидности программного обеспечения: про­грамма, программный продукт, программный комплекс, сис­темный программный продукт.

2. Создание качественного программного продукта предполагает детальную и тщательную проработку интерфейса.

3. Интерфейс Web-приложения практически не зависит от ис­пользуемых технологий, способа организации компонентов приложения и способов хранения данных.