Теоретическая часть



страница4/6
Дата04.05.2018
Размер0.98 Mb.
ТипРуководство
1   2   3   4   5   6

Другие ошибки


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

Рекомендация

Почему (юзабилити)

Почему (оптимизация)

Не нужно делать сайты на фреймах

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

На таких сайтах плохо распределяется цитируемость, затрудняется расстановка внешних ссылок на конкретные страницы.

На страницах должны быть «хлебные крошки»

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

Обеспечивают дополнительное ссылочное ранжирование корневых страниц за счет внутренних ссылок.

Визуальный шум должен быть сведен к минимуму

Страница не должна быть сразу «обо всем» – пользователь в такой ситуации теряется. Должны быть выделены 2-3 блока информации, на которых необходимо сконцентрировать внимание пользователя.

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

Страница должна быстро грузиться

Пользователи быстро теряют терпение.

Некоторые поисковые роботы имеют ограничение на объем скачиваемого кода страницы. Другие устанавливают «медленным» сайтам пониженные приоритеты при индексации.

Внешние ссылки должны вести вглубь сайта

Если вы рекламируете какой-нибудь товар либо даете ссылку на статью, не правильно заставлять пользователя искать эту страницу самостоятельно.

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

Должна обрабатываться ошибка 404 (страница отсутствует)

Для пользователя полезно давать специальную страницу, позволяющую ему понять, что произошло (запрошенной страницы нет на сервере) и перейти либо в вышестоящий раздел, либо воспользоваться поиском.

Поисковому роботу необходимо отдавать сообщение с кодом 404 (часто настраивают просто редирект с передачей кода 302 на главную страницу либо на специальную страницу). Корректная обработка 404 ошибки позволит оперативно удалять из базы устаревшие страницы.

Исключения


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

Тема 6. «Использование usability guidelines для повышения качества
веб-разработок»

ISO 9241-11:1998 Ergonomic requirements for office work with visual display terminals (VDTs) – Part 11: Guidance on usability

Расположенная в Женеве, ISO (Internation Standartization Organization, Международная организация по стандартизации) – неправительственная сеть национальных институтов по стандартизации, в которой участвуют представители из 146 стран.

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

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


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

Существует несколько стандартов, разработанных в ISO и относящихся к сфере юзабилити и человеко-компьютерного взаимодействия:

> ISO 13407:1999 Human-centred design processes for interactive systems

This standard has been revised by: ISO 9241-210:2010


> ISO/TR 18529:2000 Ergonomics – Ergonomics of human-system interaction - – Human-centred lifecycle process descriptions.
UCD — User Centered Design (дизайн ориентированный на пользователя)

ISO 13407 — описан процесс проектирования интерактивных систем, ориентированных на пользователей. Этот стандарт содержит рекомендации по организации процесса проектирования интерфейсов и органичному встраиванию этого процесса в общий процесс производства ПО. В стандарте описаны методы юзабилити, необходимые для: определения контекста использования продукта, выявления требований пользователей и заказчиков к системе, прототипирования и юзабилити-тестирования продукта.

ISO 18529 — эргономика человеко-компьютерного взаимодействия — описание процесса проектирования интерфейсов, ориентированных на пользователей
В стандарте детально описана модель зрелости организации с точки зрения уровня использования в ней UCD-процесса. Даются рекомендации по переходу на более высокие уровни зрелости.

ISO-стандарты

>ISO 14915-1:2002 Software ergonomics for multimedia user interfaces

>ISO/TS 16071:2003, Ergonomics of human-system interaction – Guidance on accessibility for human-computer interfaces

>ISO/TR 16982:2002 Ergonomics of human-system interaction – Usability methods supporting human-centred design

>ISO 20282 Measuring the usability of everyday products

ISO 14915 — эргономика программного обеспечения мультимедийных пользовательских интерфейсов. В стандарте даются рекомендации по созданию элементов управления для мультимедийных продуктов, таких, например, как обучающих систем, справочных киосков, электронных справок.

ISO 16071 — эргономика взаимодействия "человек-система". Руководящие указания по доступу к интерфейсам "человек-машина“.

ISO 16982 — эргономика взаимодействия человек-система. Методы, основанные на удобстве применения, для обеспечения проектирования, ориентированного на человека

ISO 20282 — юзабилити повседневных вещей. В первой части стандарта рассказывается о методе определения свойств контекста, в котором будет использоваться разрабатываемый продукт. Во второй части описывается методика измерения юзабилити для повседневных вещей.

тестирование юзабилити
Разработка стандартов
W3C (World wide Web Consortium, Всемирный Веб Консорциум) – состоит из 450 организаций. Цель этого движения – максимально эффективно использовать потенциал сети Интернет. Основная деятельность этой организации — разработка стандартов.
WAI (Web Accessibility Initiative, Программа по организации доступа к Сети для людей с ограниченными возможностями) – признанный стандарт консорциума, в котором деклалируется доступность веб-сайтов для всех людей, в независимости от используемой ими платформы или недостатков.

В этом стандарте содержаться рекомендации по доступности в трех сферах:

>веб-контента,

>средств для создания контента

>пользовательских агентов (браузеры и подобное ПО).

К первой сфере относится стандарт "Рекомендации общедоступности веб-контента" (WCAG, Web Content Accessibility Guidelines 1.0), который был впервые опубликован в 1999 году.

В рекомендациях приводится таблица контрольных проверок, разбитая на три группы по уровню влияния на общедоступность. В зависимости от количества выполненных правил, веб-сайту присваивается одна из трех степеней соответствия: "A", "AA" и "AAA" (степень "A" означает, что сайт удовлетворяет основным требования и имеет низкий уровень доступности, а степень "AAA" означает 100% доступность сайта).

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

Будь то:


>обязанность заполнять ненужные поля в формах заявлений и справок;

>обязательные требование предоставить какие-то документы и справки, в которых объективно нет никакой необходимости, но которых требует процедура;

>простаивание в очередях и пробках и т.д.

пример бумажной бланка с ненужным для заполнения полем

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

Надо понимать, что никто не создаёт плохие системы специально.

Даже самые опытные специалисты и крупные производители допускают ошибки.

в форме на сайте hp используются неподходящие контролы




UCD (User Centered Design)

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

На данный момент крупные компании, как западные (Microsoft, Google), так и российские (Билайн, РТС, 1С) внедряют практики UCD в свои процессы.

тяжёлая для заполнения форма

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

Но как в дальнейшем придётся тем, кто будет с этой формой работать? Заполнение каждого поля происходит методом проб и ошибок, что становиться настоящим кошмаром для пользователей. Это приводит к неэффективной работе.

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

Высокие показатели юзабилити продукта достигаются за счёт внедрения в разработку подхода UCD (User Centered Design или дизайн ориентированный на пользователя). Данный подход характеризуется активным вовлечением пользователя в процесс разработки для достижения понимания пользовательских требований и надлежащего распределения функций между пользователями и технологиями, а также итеративным характером подхода и его мультидисциплинарностью (ISO 13407).

Usability guidelines

Будучи реалистами, мы понимаем, что требования описанные ранее пока являются слишком высокими для большинства малых и средних компаний веб-разработчиков и веб-студий России, а тем более Беларуси. Их основные потребности в этой области — оперативно и с малыми затратами определить (задать) требуемый уровень юзабилити для своих проектов и продуктов, сформировать требования и рекомендации, задать критерии (метрики) для последующей оценки и анализа.

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

Usability guidelines — документ, описывающий правила применения как общих, так и отдельных, конкретных элементов интерфейса.

Формирование и проверка на соответствие usability guidelines — это методика, позволяющая повысить юзабилити сайта или ПО, задачи которого типичны или сводимы к типичным.



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

В гайдлайне собраны правила — «эвристики», часто выработанные опытным путём — которым следуют при разработке сайта. Эти правила могут касаться как совсем мелких, отдельных элементов интерфейса, так и больших частей взаимодействия.

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

Чтобы быть объективным, стоит упомянуть и некоторых недостатках, которые, правда, недостатками можно назвать условно.

>Неполнота содержания. У каждого продукта есть свои особенности и часто свои элементы интерфейса. Создать универсальный гайдлайн не получится.

>Гайдлайн не решает проблем взаимодействия.


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

>Для составления контрольных списков потребуется некоторое время и терпение, опыт, изучение лучших практик, ну и некоторые знания в юзабилити, конечно.


Можно привлечь к такой работе экспертов. Не лишней будет ревизия вашего гайдлайна экспертом.

В качестве основы для своего гайдлайна вы можете использовать контрольный список Влада Головача и Research Based Web-designand Usability guidelines.

На текущий момент он содержит правила (эвристики), сгруппированные по следующим элементам:

>Формы,


>Кнопки,

>Поля ввода,

>Списки,

>Системные сообщения и обработка ошибок,

>Флажки и переключатели,

>Текст,


>Пошаговые действия (мастер),

>Капча.


Правило 1.1: «Поля, обязательные для заполнения, обозначены звёздочкой перед своим названием. У формы есть пояснение об обозначении обязательных полей».

рисунок к правилу 1.1

Это правило добавлено из-за гипотезы о том, что читая слева на право, пользователь быстрее увидит обязательные для заполнения поля и заполнит их сразу.


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

Правило 1.2: «Названия полей выровнены по правой стороне. Расстояние от названия до поля для всех полей одинаковое».

рисунок к правилу 1.2

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


Также длинные расстояния (если выравнивание было по левой стороне) сильно затрудняют ассоциацию названия поля с самим полем. Не редко приходится проверять правильность заполнения несколько раз.

Правило 2.2: «Надписи на кнопках начинаются с большой буквы. Если надпись состоит из нескольких слов, то каждое слово начинается с большой буквы, кроме предлогов».

Правило 2.3: «Подписи к интерфейсным элементам начинаются с прописной буквы и заканчиваются двоеточием»

Правило 2.4: «Кнопка негативного действия «Удалить», «Стереть», «Отменить» всегда самая правая»

Правило 3.3: «Для полей ввода количественных характеристик (длинна, вес, рост, скорость, расстояние, размер и т.д.) необходимо указывать единицы измерения».

рисунок к правилу 3.3

Данное правило позволяет избавиться от путаницы, которая возникла бы, если единицы измерения были бы не подписаны.



Юзабилити-преступления

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

Рассмотрим классические, но непростительные ошибки в области веб-дизайна и способы их решения.

Преступление #1:


В формах метки не связаны с полями ввода.

Использование атрибута «for» позволит пользователям кликать по метке, для выбора соответствующего поля формы. Это особенно важно для чекбоксов и радиокнопок — необходимо увеличивать область клика.
crime1

Преступление #2:



Логотип не ведёт на главную страницу.

crime2

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

Преступление #3:

Не помечены посещённые ссылки.

crime3

Об этом забывают очень часто, но посетителям нужно знать по каким ссылкам они уже кликали.

Преступление #4:

Не подсвечено в форме активное поле.

crime4

Используйте псевдо-класс ":focus" для добавления к полям ввода рамки или смены фона.

Преступление #5:



Изображения без описания.

crime5

В атрибуте «alt» укажите описание изображения. А если картинка носит оформительно-декоративный характер, то оставьте его пустым (но не удаляйте!). Если же это кнопка-ссылка, то укажите в описании куда она ведёт.

Преступление #6:



Фоновые изображения без фонового цвета.

crime6

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

Преступление #7:

Использование длинных скучных абзацев текста.

crime7

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

Преступление #8:

Подчёркивание того, что не является ссылкой.

crime8

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

Преступление #9:



Призывать посетителей «кликнуть здесь».

crime9

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

Преступление #10:



Выравнивать текст по ширине.

crime10

Старайтесь не использовать «text-align: justify». Текст может красиво выглядеть, но на самом деле становится трудночитаемым (особенно для людей с ограниченными возможностями) из-за разного расстояния между словами.

Гайдлайны лидеров рынка разработки ПО

Среди компаний, создающих и поддерживающих свои usability guidelines, такие известные и крупные компании, как: SAP, Microsoft, Apple, Sun, Oracle, Nokia.

Следование гайдлайнам производителя делает интерфейс консистентным.

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


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

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

2.Другая точка зрения заключается в том, что использование гайдлайнов позволяет создавать интерфейсы идеально совместимые с продуктами и сервисами производителей, уменьшают количество ошибок в создаваемых ПИ для сторонних разработчиков.
Например, компания 1С передаёт своим партнёрам по кастомизации 1C Бухгалтерии гайдлайны на диске.

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



пример из гайдлайна microsoft

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



правила для ribbon bar



Поделитесь с Вашими друзьями:
1   2   3   4   5   6


База данных защищена авторским правом ©vossta.ru 2019
обратиться к администрации

    Главная страница