49808 (Разработка программного обеспечения виртуальной библиотеки), страница 3

Тут возможно три варианта развития событий: либо вы обнаружите, что вы что-то забыли задокументировать в схеме, либо обнаружите, что свеженаписанный рассказ значительно лучше схемы, вероятнее же всего, что и то и другое произойдет одновременно. На четвертый вариант, а именно на полное отсутствие проблем, рассчитывать, как правило, не стоит.

3.4 Экспертная оценка

Весьма эффективным средством оценки получающегося интерфейса является его экспертная оценка. Часто оказывается, что сравнительно дорогое тестирование показывает то, что было бы легко видно постороннему, тем более вооруженному опытом и квалификацией, взгляду. Хотя экспертная оценка не может быть полноценной заменой тестирования, она обладает одним существенным преимуществом - для её проведения не требуется прототип. Это значит, что эксперт может быть приглашен на ранних стадиях работы, когда польза от обнаружения ошибок максимальна.

Для проведения экспертной оценки нужно знать следующее:

• разные люди обнаруживают разные ошибки. Это значит, что метод работает лучше, когда количество экспертов больше единицы;

• лучше привлекать несколько экспертов не одновременно, но последовательно;

• чем больше информации о проектируемой системе будет предоставлено эксперту, тем более сложные проблемы он сможет выявить;

• нельзя требовать от эксперта работы по весу. В большинстве случаев результатом его работы будут одна или две страницы текста (поскольку описание одной проблемы требует обычно всего двух или трех предложений). Если от эксперта будет требоваться объемный результат работы, он включит в него много несущественных подробностей;

4. Построение прототипа пользовательского интерфейса

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

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

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

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

4.1 Этапы построения прототипа

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

4.1.1 Бумажный

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

Эта распечатка и является первым прототипом. На нём вполне можно тестировать восприятие системы пользователем и её основную логику.

Достоинствами бумаги являются исключительная простота и скорость рисования (Рисунок 4.2). Польза начального прототипирования на бумаге заключается, во-первых, в простоте и скорости рисования, во-вторых, в исключительной простоте модификации по результатам тестирования, а в-третьих, в относительной простоте привлечения представителей целевой аудитории. Значительно легче завлечь субъекта к письменному столу, нежели к компьютеру, на котором надо что-то запускать, ждать, пока запустится и так далее. Кроме того, бумага помогает не думать о том, как интерфейс выглядит, позволяя сосредоточиться на том, как интерфейс работает.

При рисовании прототипа на бумажке очень важно не стараться нарисовать его так, чтобы он был красив, например, не нужно стараться рисовать линии прямыми. На понимание работы интерфейса это не повлияет, зато здорово замедлит работу. Красоту же всё равно придется выбрасывать, когда будет нарисована новая версию. Так что основным критерием живописности должна стать скорость работы.

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

Разумеется, значение слова «версия», весьма условно. В действительности после обнаружения каждой ошибки схема и прототип исправляются, а тестирование продолжается уже на новом прототипе. Так что на этом этапе прототип может пережить множество исправлений и, соответственно, много версий (Рисунок 4.3).

4.1.2 Презентационный

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

Самым распространенным инструментом для создания прототипов второго типа является MS Visio. Некоторую конкуренцию ему могут составить MS PowerPoint и MacromediaFreeHand (и вообще любой иллюстративный пакет, обладающий возможностью работать с несколькими страницами).

При работе с Visio можно выбрать одну из двух возможностей: можно либо рисовать все экраны на одном листе, соединяя взаимосвязанные элементы управления и экраны линиями, либо рисовать каждый экран на отдельном листе, связывая экраны ссылками. Первый вариант хорош для вас, поскольку позволяет оценить интерфейс в целом, второй – для заказчика и субъектов тестирования, поскольку его легче понять. Как правило, превратить второй вариант в первый оказывается гораздо легче. Если рисовать в PowerPoint, каждой экран удобно создавать как отдельный слайд, а результат нажатия кнопок имитировать переходами между слайдами.

Среди многочисленных наборов заготовок в Visio есть и набор с элементами интерфейса Windows, однако эти заготовки выполнены довольно грубо, с огромным количеством лишних деталей. Пользоваться можно только заготовками для радиокнопок и чекбоксов (которые реализованы неплохо), а также заготовкой для полоски прокрутки. Поскольку создание собственных интерактивных заготовок непроблематично, рекомендуется создать свой набор и пользоваться им.

Большим достоинством Visio является возможность записывать результат в HTML-файл, что позволяет без проблем тестировать интерфейс на территории субъектов тестирования. Раньше это мог только PowerPoint, чем, во многом, и объяснялась его популярность в качестве инструмента для создания прототипов. Сейчас это умеет и Visio (сохранение в HTML начало нормально работать только в Visio 2001).

У многих разработчиков, особенно кто не понаслышке знаком с программированием есть соблазн воспользоваться для создания прототипа средствами быстрой разработки приложений (Delphi, VisualBasic и т.д.). В этом случае прототип интерфейса воспринимается лишь как вспомогательная оболочка над программным кодом. Как следствие возникают следующие недостатки:

• для тестирования прототипа на пользователях крайне желательно, чтобы он «немного работал», то есть, например, нажатие на кнопку вызывало другое окно или чтобы из выпадающего списка можно было выбрать значение. Так вот, в данном случае любое взаимодействие, как между отдельными элементами интерфейса, так и между различными формами реализуется только с помощью написания программного кода. Что совершенно незачем в данном контексте. Зачем усложнять то, что можно сделать проще? Ведь основной критерий создания прототипа это скорость;

• чрезвычайно сложно создать принципиально новый элемент интерфейса либо модифицировать уже имеющийся. Подобные задачи очень часто встречаются на практике, так как для «хорошего» интерфейса стандартных элементов, как правило, не хватает. Затраты на создание/модификацию собственного элемента управления в данных средах разработки нельзя назвать адекватными;

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

• естественный недостаток: нельзя разрабатывать веб-интерфейс.

Фактически для большинства систем этой версии прототипа оказывается достаточно.

4.1.3 Псевдореальный

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

4.1.4 Реальный

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

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

5. Тестирование и модификация прототипа

Какими бы не были совершенными логические соображения, приведшие к созданию интерфейса, всегда остается вероятность того, что интерфейс получился плохой, либо, что более вероятно, не такой хороший, каким бы он мог быть (Рисунок 5.1).

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

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

• не обладают всей необходимой информацией о системе;

• ничего не знают о проектировании интерфейсов;

• их мотивация существенно отличается от необходимой - вместо того, чтобы стремиться сделать хороший интерфейс, они стремятся оставить в этом интерфейсе свой след.

Вообще, слушать потребителей обычно неправильно. Разве мы спрашиваем канарейку, в какой клетке она хочет жить? Сюжет проамериканский автопром, например, стал уже частью истории бизнеса: все американские потребители в семидесятых годах дружно утверждали, что они хотят большие, мощные машины, при этом так же дружно покупая маленькие и маломощные японские автомобили. Или другой пример - в советское время измученные коммунизмом люди мечтали вовсе не об отпуске на Тенерифе, о котором они ничего не знали, но о финском хромированном смесителе, который поставил себе сосед - хотя Тенериф, безусловно, в качестве мечты интереснее.

В то же время, даже не слушая пользователей, обязательно нужно принимать во внимание их потребности, способности и предпочтения. Например, нередко дизайнер интерфейса знает о предметной области меньше, нежели будущие пользователи. В таких условиях потеря контакта с пользователями грозит крахом продукта, просто потому, что система оказывается неспособна решать задачи, о которых дизайнер ничего не знал. Чаще, однако, случается так, что уровень «компьютерной грамотности» дизайнера оказывается выше уровня аудитории. В этом случае все получается ещё хуже: дизайнер выбирает решения, которые обеспечивают эффективность работы, а потребителям нужны решения, которые они могут понять, в результате они оказываются неспособными воспользоваться системой (это совершенно нормальная ситуация, особенно в интернете). Например, замечено, что опытные пользователи (к которым относятся дизайнеры) создают значительно менее работоспособные иерархии меню, нежели пользователи начинающие.

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

ЗАКЛЮЧЕНИЕ

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

Электронная форма позволяет хранить информацию в более надёжном, компактном и удобном виде. Значительно увеличивается скорость поиска нужной информации, простота её распространения.

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