ХВАТИТ НОСИТЬ ВОДУ РЕШЕТОМ

Сорокина Лариса Викторовна

студент факультета прикладной информатики, Кубанский государственный аграрный университет, г. Краснодар,

E-mail: laricasorokina@gmail.com

Янаева Марина Викторовна

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

Как сделать программу дружелюбной к пользователю:
изготовить печать и поставить на каждой коробке
штамп «USER FRIENDLY».

Билл Гейтс

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

Юзабилити-тестирование важно, поскольку помогает оценить удобность и когнитивную комфортность для пользователя программного продукта или веб-сайта до его публичного релиза. Однако, 90 % всех юзабилити-тестов оказываются бесполезны, поскольку не являются частью процесса проектирования, проводятся, как правило, в конце графика сдачи работ и являются попыткой откупиться от маркетологов, которым очень нравятся фокус-группы и возможность рассказать о том, какой замечательный продукт выходит на рынок. При этом никого не интересует, что выполнение такой простой операции, как выключение компьютера, вызовет затруднение у большинства пользователей [1, 4, 6, 8].

Отсутствие юзабилити-тестирования веб-сайтов приводит к редуцированию их функционала, возможно, реализованного, но скрытого из-за невозможности добраться до него. К примеру, на сайте Управления Федеральной миграционной службы Российской Федерации по Краснодарскому краю нами была найдена «битая» ссылка на пример заполнения анкеты для получения загранпаспорта и предприняты попытки связаться с администратором ресурса. Попытки не увенчались успехом. Если бы техническая поддержка сайта была организована грамотно, досадная оплошность была бы исправлена. Перед написанием этой статьи автор записала адрес электронной почты своего научного руководителя в черновик SMS-сообщения своего мобильного телефона; после каждого прочтения сохраненного в черновике сообщения предлагается его удалить, хотя, несомненно, если бы автору хотелось удалить что-то, была бы вызвана соответствующая функция. Вместо этого, было получено диалоговое окно с нулевой информационной теоретической эффективностью, успешно игнорируемое, как всегда бывает с такими окнами, и мы остались без возможности организовать нужную связь, чтобы выбрать название статьи. Несомненно, если бы юзабилити-тестирования проводили чаще, то добрая часть диалоговых окон, справляющихся, уверена ли я, что хочу удалить тот или иной документ, перестала бы существовать.

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

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

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

Своей целью мы ставим создание дизайнера форм, который позволит оценить информационную эффективность интерфейса на основе различных методов и оценок, таких как:

1.классическая модель GOMS, позволяющая предсказать, сколько времени потребуется опытному пользователю на выполнение конкретной операции при использовании данной модели интерфейса;

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

3.закон Хика, позволяющий количественно определить наблюдение, заключающееся в том, что чем больше количество вариантов заданного типа вы предоставляете, тем больше времени требуется на выбор [7].

Для выполнения оценки эффективности спроектированного взаимодействия дизайнер может либо заново построить форму стандартными средствами дизайнера нашей программы, либо импортировать .xml файл формы своего программного продукта. Естественно, что юзабилити-тестирование проблематично без наличия людей, поэтому следовало бы создать возможность проведения дистанционного юзабилити-тестирования, с возможностью записи всех действий пользователя в окне программы, где пользователь мог бы работать так же, как если бы у него был установлен тестируемый программный продукт. Так же необходимо разработать режим тестирования, режим отправки результатов разработчикам —это разумно, поскольку позволит сэкономить на аренде помещения для тестирования и уменьшить контакт с людьми; разработать систему оценки эффективность взаимодействий с пользователем программного продукта, которая позволит в доступной форме объяснить, что воспринимается пользователем не так, как было задумано разработчиком; предоставить комфортный дизайн, как для проектировщиков взаимодействия, так и участников юзабилити-тестирования. Провести юзабилити-тестирование созданного приложения. Отличие данной разработки от существующих программ для прототипирования интерфейсов, таких как: Bolsamic Mockups, Prototyper, Alee GUI Machine, —заключается в интегрированном механизме количественных методов и оценок эффективности интерфейса. Последний может сочетаться с данными включенного наблюдения и юзабилити-тестирования, полученным от пользователей, что поможет скоординировать работу разработчиков взаимодействия вокруг одного инструмента, позволяющего создать и апробировать прототип,без привлечения сторонних продуктов для публикации, видео-граббера изображения, мессенджера для координации действий с респондентами.

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

Список литературы:

1. Беккер Л. 90 % всех юзабилити-тестов бесполезны // — [Электронный ресурс] — Режим доступа — URL: http://www.webmascon.com/topics/testing/16a.asp (дата обращения: 17.09.2012).
2. Брукс Ф. Мифический человеко-месяц, или Как создаются программные системы — М.: Символ-Плюс, 2010. — 304 с.
3. Как выключить, или перезагрузить компьютер в Windows 8 // — [Электронный ресурс] — Режим доступа — URL: http://osmaster.org.ua/?p=4101 (дата обращения: 17.09.2012).
4. Круг С. Веб-дизайн: книга Стива Круга или «не заставляйте меня думать!» — М.: Символ-Плюс, 2005. — 200 с.
5. Купер А. Психбольница в руках пациентов. — М.: Символ-Плюс, 2009. — 336 с.
6. Норман Д. Дизайн привычных вещей. — М.: Вильямс, 2006. — 384 с.
7. Раскин Дж. Интерфейс. — М.: Символ-Плюс, 2005. — 272 с.
8. Спольски Дж. Джоэл о программировании. — М.: Символ-Плюс, 2006. — 352 с.