14:06 12-03-2006
ЧЕТЫРЕСТА ДВАДЦАТЬ ЧЕТВЕРТАЯ :: Програмка
Нашел наконец любимую мной программу Advanced Desktop Calendar. Удобная вещица.
12:58 12-03-2006
ЗАПИСЬ ЧЕТЫРЕСТА ДВАДЦАТЬ ТРЕТЬЯ :: Статья
http://www.webmascon.com/topics/tools/09a.asp

Проверочный список для веб-стандартов


Список

1. Качество кода
1. Указан ли у страниц правильный Doctype?
2. Указан ли у страниц charset?
3. Валиден ли (X)HTML код страниц сайта?
4. Валидны ли CSS-таблицы сайта?
5. Использует ли сайт какие-либо CSS-хаки?
6. Используются ли на сайте какие-либо лишние и ненужные классы (class) и идентификаторы (id)?
7. Хорошо ли структурирован код страниц?
8. Есть ли на сайте сломанные ссылки?
9. Как у сайта со скоростью загрузки страниц и с их размерами?
10. Выдает ли браузер какие-либо ошибки JavaScript при работе со страницей?
2. Степень разделения контента и представления
1. Используется ли на сайте CSS для всех аспектов оформления страницы (шрифты, цвета, отступы, границы и т.д.)?
2. Перенесена ли вся декоративная графика в CSS, или она все еще встречается в (X)HTML-коде?
3. Доступность для пользователей
1. Используется ли атрибут "alt" во всех значимых изображениях?
2. Используется ли на сайте для шрифта относительные единицы измерения вместо фиксированных?
3. Ломается ли каким-либо образом компоновка страницы при увеличении размера шрифта?
4. Есть ли на странице видимая ссылка "пропустить"?
5. Используются ли на сайте доступные формы?
6. Используются ли на сайте доступные таблицы?
7. Достаточно ли контрастны и ярки цвета на страницах сайта?
8. Используется ли только цвет для выделения критической информации?
9. Используется ли задержка в выпадающих меню (для пользователей с медленной моторикой)?
10. Все ли ссылки содержат описания (для слепых пользователей)?
4. Доступность для устройств
1. Достаточно ли хорошо сайт работает и в современных и в старых браузерах?
2. Можно ли работать с материалами сайта при отключенном CSS или в броузере, где нет поддержки CSS?
3. Можно ли работать с материалами сайта при отключенных изображениях или при отсутствии поддержки их вывода на экран?
4. Работает ли сайт в текстовых броузерах, таких как Lynx?
5. Хорошо ли выглядит сайт при распечатке?
6. Работает ли сайт на наладонных устройствах?
7. Снабжен ли сайт детальным набором метаданных?
8. Работает ли сайт в окнах различных размеров?
5. Основы юзабилити
1. Имеется ли на странице четкая визуальная иерархия элементов?
2. Легко ли отличить один уровень заголовков от другого?
3. Достаточно ли легко понять навигацию по сайту?
4. Используется ли однообразная навигация на всех страницах сайта?
5. Используется ли на сайте приемлемый и однообразный язык текстов?
6. Есть ли у сайта карта и страница с контактной информацией? Легко ли их найти?
7. Если ваш сайт очень большой, есть ли на нем инструмент поиска?
8. Присутствует ли на каждой странице сайта ссылка на его главную страницу?
9. Подчеркнуты ли ссылки?
10. Четко ли выделены цветом ссылки, которые пользователь уже посетил?
6. Управление сайтом
1. Есть ли у сайта понятная и полезная страница ошибки 404, которая работает с любого уровня сайта?
2. Используются ли на сайте дружественные URL-ы?
3. Можно ли к вашему сайте доступиться, набрав адрес без "www"?
4. Есть ли у сайта пиктограмма для закладок?

1. Качество кода
1.1 Указан ли у страниц правильный Doctype?

Doctype (сокращенно от 'document type declaration' - "декларация типа документа") сообщает валидатору, какая версия (X)HTML используется в вашей странице. Декларация должна присутствовать в начале каждой веб-страницы. Doctype - ключевой компонент страницы, претендующей на соответствие стандартам: ваша разметка и CSS не пройдут валидацию, если в вашем документе отсутствует Doctype.
статья на webmascon.com Почему так важен DOCTYPE

См. также:

* http://www.w3.org/QA/2002/04/valid-dtd-list.html
* http://css.maxdesign.com.au/listama...ut-boxmodel.htm
* http://gutfeldt.ch/matthias/articles/doctypeswitch.html

1.2 Указан ли у страниц кодировка (charset)?

Если пользовательский агент (например браузер) не может самостоятельно определить кодировку вашей веб-страницы, пользователи увидят на экране нечитаемый текст. Эта информация в особенности важна для тех, кто создает и поддерживает многоязычные веб-сайты. Но вообще объявление кодировки очень важно для тех, кто создает страницы в XHTML/HTML и CSS.
http://www.w3.org/International/tut...orial-char-enc/

См. также:

* http://www.w3.org/International/O-charset.html

1.3. Валиден ли (X)HTML код страниц сайта?

Валидный код браузер выведет быстрее, чем невалидный. Валидный код браузер выведет лучше, чем невалидный. Все больше и больше браузеры подчиняются стандартам, и потому все более важным является валидный и стандартный HTML-код.
http://www.maxdesign.com.au/presentation/sit2003/06.htm

См. также:

* http://validator.w3.org/

1.4. Валидны ли CSS-таблицы сайта?

Не забывайте убедиться, что ваш HTML-код и CSS-страницы не содержат ошибок, так как ошибки приведут к искаженному отображению документа на экране.
http://www.meyerweb.com/eric/articl...rev/199904.html

См. также:

* http://jigsaw.w3.org/css-validator/

1.5. Использует ли сайт какие-либо CSS-хаки?

В сущности каждый сам решает, какие хаки ему использовать. Это зависит от того, насколько хорошо вы знакомы со всеми вариантами, и от того, какой дизайн вы хотите создать.
http://www.mail-archive.com/wsg@web...g/msg05823.html

См. также:

* http://css-discuss.incutio.com/?page=CssHack
* http://css-discuss.incutio.com/?page=ToHackOrNotToHack
* http://centricle.com/ref/css/filters/

1.6. Используются ли на сайте какие-либо лишние и ненужные классы (class) и идентификаторы (id)?

Я заметил, что разработчики, осваивая новые приемы и технологии, часто создают замечательные CSS-таблицы, и при этом - плохой XHTML-код. В особенности часто в XHTML-коде встречаются ненужные и лишние "div" и "id". Из-за этого HTML-код теряет стройность, а CSS-файлы становятся запутанными.
http://www.clagnut.com/blog/228/
1.7. Хорошо ли структурирован код страниц?

Семантически правильная разметка подразумевает использование html-элементов по их прямому назначению. Хорошо структурированный HTML-документ хорошо воспринимается всем спектром пользовательских программ (браузерами без поддержки стилевых таблиц, текстовыми броузерами, наладонниками, поисковыми роботами и т.д.)
http://www.maxdesign.com.au/present...its/index04.htm

См. также:

* http://www.w3.org/2003/12/semantic-extractor.html

1.8. Есть ли на сайте "сломанные" ссылки?

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

См. также:

* http://validator.w3.org/checklink

1.9. Как у сайта со скоростью загрузки страниц и с их размерами?

Не заставляйте меня ждать... Вот какую мысль подразумевают пользователи при проведении всех исследований. Даже пользователи с широким каналом устают от медленной загрузки.
http://www.websiteoptimization.com/speed/
1.10. Выдает ли браузер какие-либо ошибки JavaScript при работе со страницей?

Internet Explorer для Windows позволяет включить отладчик, который будет выскакивать на экран всякий раз, когда на странице будет обнаружена ошибка в JavaScript. Эта опция находится в меню "Internet Options" на закладке "Advanced". Уберите галочку с пункта "Disable script debugging".

* * *
2. Степень разделения контента и представления
2.1. Используется ли на сайте CSS для всех аспектов оформления страницы (шрифты, цвета, отступы, границы и т.д.)?

Используйте стилевые таблицы для управления компоновкой страницы и ее внешним видом
http://www.w3.org/TR/WCAG10/wai-pag...ch-style-sheets
2.2. Перенесены ли вся декоративная графика в CSS, или она все еще встречается в (X)HTML-коде?

Ваша цель, как веб-разработчика, состоит в том, чтобы убрать из html-кода вашей страницы все оформительские элементы. Благодаря чему код станет чище и семантически правильнее.
http://www.maxdesign.com.au/present...its/index07.htm

* * *
3. Доступность для пользователей
3.1 Используется ли атрибут "alt" во всех значимых изображениях?

Каждый нетекстовый элемент сопровождайте текстовым описанием
http://www.w3.org/TR/WCAG10/wai-pag...text-equivalent
3.2. Используется ли на сайте для шрифта относительные единицы измерения вместо фиксированных?

В коде и в стилевых таблицах используйте относительные, а не абсолютные единицы для указания размеров элементов
http://www.w3.org/TR/WCAG10/wai-pag...-relative-units

См. также:

* http://www.w3.org/TR/WCAG10/wai-pag...-relative-units
* http://www.clagnut.com/blog/348/
* Власть народу - относительные размеры шрифтов
* Размер шрифта пусть выбирают сами пользователи

3.3. Ломается ли каким-либо образом компоновка страницы при увеличении размера шрифта?

Проведите простой тест. Откройте свой веб-сайт в любом браузере, где есть функция изменения размера шрифта. Теперь увеличьте размер шрифта. Еще раз увеличьте. И еще раз... Посмотрите на свой веб-сайт. По-прежнему ли компоновка страницы осталась неизменной? При разработке сайта не рассчитывайте, что у посетителя в браузере размер шрифта совпадает с вашим.
3.4. Есть ли на странице видимая ссылка "пропустить"?

"... Следует предусмотреть способ, который позволяет пользователю перейти к контенту сайта, пропустив навигацию..."
http://www.section508.gov/index.cfm...n=Content&ID=12

"... сгруппируйте родственные ссылки, опишите группу и представьте способ пользователям пропустить эту группу при просмотре..."
http://www.w3.org/TR/WCAG10-TECHS/#tech-group-links

".. масса навигационных на странице ссылок доставляет неприятности не только слепым пользователям. Вспомните и о тех, у кого затруднена моторика и кому придется нажимать много раз клавишу Tab, чтобы пройти по всем этим ссылкам к тексту страницы..."
http://joeclark.org/book/sashay/ser...08.html#h4-2020

См. также:

* http://www.niehs.nih.gov/websmith/508/o.htm

3.5. Используются ли на сайте доступные формы?

Формы на веб-страницах не самая простая вещь для людей с физическими недостатками. Одно дело - навигация по странице с текстовым материалом, и совсем другое - переход по полям формы и ввод информации в нее.
http://www.htmldog.com/guides/htmladvanced/forms/

См. также:

* http://www.webstandards.org/learn/t...ible-forms.html
* http://www.accessify.com/tools-and-...orm-builder.asp
* http://accessify.com/tutorials/bett...sible-forms.asp

3.6. Используются ли на сайте доступные таблицы?

Что касается таблиц. Не забудьте указать заголовки для столбцов и рядов... Для таблиц, где имеются два и более логических уровней рядов и столбцов, воспользуйтесь вспомогательными элементами языка html, чтобы связать логически ячейки данных с ячейками заголовков.
http://www.w3.org/TR/WCAG10/wai-pag...h-table-headers

См. также:

* http://www.bcc.ctc.edu/webpublishin...rces/tables.asp
* http://www.accessify.com/tools-and-...ilder_step1.asp
* http://www.webaim.org/techniques/tables/

3.7. Достаточно ли контрастны и ярки цвета на страницах сайта?

Убедитесь, что разница между цветом фона и цветом текста достаточно контрастна, чтобы не вызывать затруднений при чтении у людей с пониженным восприятием цвета.
http://www.w3.org/TR/WCAG10/wai-pag...colour-contrast

См. также:

* http://www.juicystudio.com/services/colourcontrast.asp

3.8. Используется ли только цвет для выделения критической информации?

Убедитесь, что вся важная информация, выделенная цветом, также выделена при отсутствии цвета, например с помощью контекста или элементами логической разметки.
http://www.w3.org/TR/WCAG10/wai-pag...h-colour-convey

Существует в основном три типа нарушения цветовосприятия: дейтеранопия (нарушение в восприятии красного и зеленого цветов), протанопия (другая форма нарушения восприятия красного и зеленого цветов) и тританопия (нарушение восприятия синего и желтого цветов - очень редкий случай)

См. также:

* http://colorfilter.wickline.org/
* http://www.toledo-bend.com/colourblind/Ishihara.html
* http://www.vischeck.com/vischeck/vischeckURL.php

3.9. Используется ли задержка в выпадающих меню (для пользователей с медленной моторикой)?

У людей с медленной моторикой могут возникнуть трудности при работе с меню, которые для них будут работать слишком быстро.
3.10. Все ли ссылки содержат достаточно описательный текст (для слепых пользователей)?

Ссылки должны быть достаточно понятными, чтобы они имели смысл при чтении вне контекста - либо при простом чтении или при чтении в виде списка.
http://www.w3.org/TR/WCAG10/wai-pag...eaningful-links

* * *
4. Доступность для устройств
4.1. Достаточно ли хорошо сайт работает и в современных и в старых браузерах?

Прежде чем начинать верстать страницы с использованием CSS, определитесь, какие браузеры вы собираетесь поддерживать и до какой степени.
http://www.maxdesign.com.au/present...ndex_step01.cfm
4.2. Можно ли работать с материалами сайта при отключенном CSS или в броузере, где нет поддержки CSS?

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

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

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

См. также:

* http://www.delorie.com/web/lynxview

4.5. Хорошо ли выглядит сайт при распечатке?

К любому (X)HTML-документу можно прикрепить стиль для вывода на печать и для этого не потребуется трогать разметку самого документа.
статья на webmascon.com В печать!

См. также:

* http://www.d.umn.edu/itss/support/Training/Online/ webdesign/css.html#print

4.6. Хорошо ли работает ли сайт на наладонных устройствах?

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

См. также:

* Дизайн для портативных устройств: ваш веб-сайт на маленьком экране

4.7. Снабжен ли сайт детальным набором метаданных?

Метаданные - это информация, которая понятна для машин.
http://www.w3.org/Metadata/

Метаданные - это структурированная информация, которая создается людьми специально для того, чтобы описать ею какой-либо ресурс. Другими словами, метаданные - это "данные о данных".
4.8. Работает ли сайт в окнах различных размеров?

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

* * *
5. Основы юзабилити
5.1. Имеется ли на странице четкая визуальная иерархия элементов?

Организуйте и выделяйте важность того или иного материала с помощью размеров, отступов и логических связей.
http://www.great-web-design-tips.co...design/165.html
5.2. Легко ли отличить один уровень заголовков от другого?

Используйте заголовки для того, чтобы раскрыть структуру документов, при этом используйте их в соответствие со спецификацией.
http://www.w3.org/TR/WCAG10/wai-pag...ogical-headings
5.3. Достаточно ли легко понять навигацию по сайту?

Навигация вашего сайта должна подсказывать посетителю, на какой странице сайта он сейчас находится и куда он может следовать дальше.
http://www.1stsitefree.com/design_nav.htm
5.4. Используется ли однообразная навигация на всех страницах сайта?

Если на каждой странице вашего сайта навигация придерживается одного и того же стиля, посетителям легче будет работать с сайтом и они быстрее будут находить нужную им информацию.
http://www.juicystudio.com/tutorial.../navigation.asp
5.5. Используется ли на сайте приемлемый и однообразный язык текстов?

Ясный и простой язык материалов позволяет эффективно вести диалог с посетителем. Не забывайте, что ваш сайт могут читать пользователи, для которых ваш язык не является родным.
http://www.juicystudio.com/tutorial...ility/clear.asp
5.6. Есть ли у сайта карта и страница с контактной информацией? Легко ли их найти?

Большинству карт сайтов не удается раскрыть многоуровневую структуру архитектуры сайта. В тестах на юзабилити пользователи часто игнорируют карту сайта или просто не могут ее найти. Сложность карты также является проблемой: карта должна быть именно картой, а не головоломкой по навигации.
http://www.useit.com/alertbox/20020106.html

См. также:

* Карта сайта и индекс: что это такое и для чего это нужно?

5.7. Если ваш сайт очень большой, есть ли на нем инструмент поиска?

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

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

Для полноты восприятия пользователями ссылок текст ссылок должен быть оформлен другим цветом и подчеркнут. Посетители не должны метаться по странице в поисках ссылки.
http://www.useit.com/alertbox/20040510.html
5.10. Четко ли выделены цветом ссылки, которые пользователь уже посетил?

Самое главное, если четкое выделены ссылки, которые пользователь уже посетил, он не нажмет на них случайно, и не будет попадать на ту же самую страницу, где уже побывал.
http://www.useit.com/alertbox/20040503.html

* * *
6. Управление сайтом
6.1. Есть ли у сайта понятная и полезная страница ошибки 404, которая работает с любого уровня сайта?

Вы запросили страницу - либо набрав URL в адресной строке, либо щелкнув по ссылке - и обнаружили, что провалились в Ничто. Дружественные к пользователю веб-сайты подадут руку помощи потерявшемуся пользователю, а другие сайты будут рассчитывать на то, что браузер пользователь сам их как-нибудь вытащит из бездны киберпространства.
статья на webmascon.com Совершенная 404-ая страница
6.2. Используются ли на сайте дружественные URL-ы?

Большинство поисковых серверов (за исключением лишь некоторых - например, Google) не будут индексировать страницы, в чьих URL-ах присутствует символ "?" или какой либо иной символ (скажем "&" или "="). Что хорошего в веб-сайте, если его никто не может найти?
http://www.sitepoint.com/article/se...e-friendly-urls

С точки зрения пользовательского интерфейса самым ужасным является URL-ы. Тем не менее, если они коротки, логичны и самоисправляющиеся, с ними становится удобно работать.
http://www.merges.net/theory/20010305.html
12:24 12-03-2006
ЗАПИСЬ ЧЕТЫРЕСТА ДВАДЦАТЬ ВТОРАЯ :: Статья
http://www.webmascon.com/topics/designgeneral/21a.asp

Юзабилити: наука или идеология?


Usability: Empiricism or Ideology? (June 27, 2005)
автор: 2005.06.27 Якоб Нильсен
перевод: 2005.12.20 Александр Качанов

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

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

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

Экономист Арноль Клинг (Arnold Kling) недавно отобразил в цифрах, как выглядит исторический рост экономики. Для этого он прибег к весьма любопытной системе измерения: мешкам с мукой. Если подсчитать, сколько вы можете приобрести мешков с мукой на свою зарплату, то окажется, что средний работник сегодня производит ценностей в 450 раз больше, чем средний работник, живший в 1500 году. (Клинг использует мешки с мукой для сравнения производительности потому, что это одна из немногих вещей, которая постоянно производилась и производится на протяжение долгого исторического периода, а ее потребительская стоимость осталась примерно той же, что была несколько столетий назад).

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

Обучение происходит двумя путями: по науке и по Дарвину. При научном методе мы придумываем гипотезу, а затем производим эксперименты, стараясь эту гипотезу опровергнуть. Если достаточное количество опытов не может опровергнуть нашу гипотезу, мы принимаем ее за теорию, а инженеры берут и изготавливают на ее основе новые товары. Бизнес же работает все больше по Дарвину. Множество предпринимателей одновременно предлагают свои услуги по решению той или иной потребности покупателя. Большая часть этих предпринимателей выходит из бизнеса поскольку "невидимая рука" экономики отвергает их предложения.

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

Юзабилити в некотором роде это тоже проверка на соответствие реалиям. И делается это двумя способами:

* До того, как начался процесс дизайна. На этом этапе используются такие методы юзабилити, как исследования на месте, исследования конкурентов. Они дают возможность дизайнеру определить направление, в котором движется реальный мир. Эти методы ближе к научному подходу "гипотеза-опыт": вы выводите какие-то закономерности, а затем пытаетесь найти им подтверждение, наблюдая за реалиями, чтобы в дальнейшем пользоваться ими как путеводной нитью при создании наилучшего из возможных дизайнов.
* После того, как закончился процесс дизайна. Здесь используются уже другие методы дизайна такие как, тестирование, наблюдение. Точно так же как предприниматели соревнуются друг с другом в том, чья бизнесс-идея лучше для покупателя, так и специалисты по юзабилити, показывают альтернативные варианты дизайна пользователям и определяют, какой из них работает лучше всего. Главное преимущество лишь в том, что тестирование бумажного прототипа вам обойдется дешевле, чем предпринимателю - основание целой компании.

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

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

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

В то же самое время юзабилити является идеологией - это система веры в определенные права человека:

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

Эти права не всегда уважались. В 60-е годы большинство пользовательских интерфейсов требовали от человека подчинения себе. То же самое происходило с веб-сайтами в эпоху моды на "крутые и навороченные" сайты.

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

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

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

Как защитник прав пользователей вы должны освоить обе стороны юзабилити: научную и идеологическую. Каждая сторона требует своего подхода в освоении.

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

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

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

Якоб Нильсен
Закрыть