Как пользователи будут взаимодействовать с информацией? Будут ли они обращаться к ней независимо от приложения, которое на неё ссылается, требуя отдельной навигации или инструментов поиска? И, что важно, как мы будем управлять обновлениями и дополнениями? Обязательно определите рабочую политику с самого начала проекта.

Отдельные окна

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

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

Использование JavaScript в Битриксе "Управление сайтом" вместо обычных ссылок может помочь справится с этой проблемой. Мы можем контролировать размер нового окна, чтобы убедится, что оно не перекрывает целиком старую страницу, и мы можем отключить навигационную панель и другие вещи, не подходящие к случаю. Но это накладывает на разработчиков большую нагрузку по правильной обработке многооконного интерфейса. Рассмотрим следующий типичный сценарий:

1. Новое окно создаётся с:
   window.open('widget-1-help.html','help_window','width=450')
2. Пользователь читает содержимое и затем возвращается назад в исходной странице, не закрывая окно справки.
3. Пользователь нажимает следующую справочную ссылку с:
   window.open('widget-2-help.html','help_window','width=450')

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

Управление окнами — не единственная сложность, которую привносит длинная форма справки, и подобные проблемы составляют мощный аргумент для использования встроенной справки везде, где возможно. Но даже когда это невозможно, ссылки на справку должны быть контекстно-зависимыми. Гораздо более эффективно давать ссылки на нужную страницу, чем общую кнопку «справка», требующую от пользователя искать нужную тему.

В примере ниже Github информирует нового пользователя о том, что он должен сгенерировать SSH ключи для публикации кода. Генерация ключей — непростая тема, так что сайт даёт ссылки на инструкции. Ссылка открывает отдельное окно с длинной формой справочной страницы, но за всем этим, сайт автоматически определяет MacOS или Windows, и отображает подходящий для системы набор инструкций. Это отличный пример зависимости от контекста.

Github ссылается на инструкции по созданию ключей SSH.

Вопросы и ответы

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

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

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

Рьяные фанаты

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