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

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

Эта страничка рассматривает некоторые шаблоны и методы разработки для того, чтобы сделать доступным help в Вашем приложении. Здесь приведены советы по созданию содержимого help для пользователей, которые нуждаются в помощи (перевод документации [1]).

[Не показывайте незапрашиваемую справку, за исключением ограниченных случаев]

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

Почти всегда так лучше не делать по следующим причинам:

• Агрессивные подсказки отрывают пользователя. Люди будут стремится начать использовать Ваше приложение или что-то, что Вы помещаете перед ними, и натыкаясь на неожиданную подсказку будут чувствовать её как препятствие и возможно будут раздражаться - несмотря на все Ваши благие намерения. И поскольку пользователи не просили подсказки, они наверняка не обратят должное внимание на неё.

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

Сначала каждый пользователь попадает на экран всех приложений, где в ответ  на каждый жест появляется полупрозрачная картинка подсказки

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

К примеру, мы используем содержимое help, чтобы обучить пользователя, как разместить приложение на домашнем экране Android (Home screen). Эта функциональность заключается в следующем:

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

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

[Следуйте стандартам разработки для размещения справки]

На каждом экране Вашего приложения предоставьте возможность получения справки. Это можно сделать в Action Bar и в контекстном меню. Всегда делайте пункт вызова справки последним элементом в меню и пометьте его текстом "Help" ("Справка").

	Даже если у Вашего экрана нет никаких других пунктов контекстного меню, пункт справки "Help" должен находиться именно здесь, и его не нужно выносить в строку статуса программы (action bar).

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

[Считайте каждую просьбу о помощи срочной и важной задачей]

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

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

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

Когда кто-то выберет подсказку "Help":

Так никогда не делайте. Представленный диалог ставит пользователя перед выбором справки наряду с другими опциями.	Так уже лучше. Сразу запускается веб-браузер с содержанием справки. Другие опции помещены в нижнюю часть.	Так всегда лучше. Создайте экран справки в своем приложении, и предоставьте другие опции в строке меню (action bar). Например, Вы могли бы позволить пользователям связываться с Вами через форму обратной связи или через специальную кнопку. Выпадающее меню (Action overflow) идеальное место для не справочной информации, которая редко нужна. Такой подход усложняет разработку по сравнению с запуском браузера для справки, но это наиболее удобный вариант для пользователей, потому что для получения справки им не приходится покидать Ваше приложение, и не требуется подключение к сети Internet.

[Принципы написания содержимого справки, отображаемой на экране]

• Help должен быть частью интерфейса пользователя (UI)

Экранная подсказка является расширением UI Вашего приложения, но не описанием его. Все слова на экране, от ядра приложения до подсказки должны следовать единым принципам написания (см. Writing Style), чтобы сквозной опыт пользования системы был логичным и связным.

• Учитывайте каждый пиксел

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

• Картинки часто эффективнее, чем слова

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

• Помоги мне пролистать, не читая

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

• Направьте меня прямо к ответу на вопрос

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

[Ссылки]

1. Designing Help into Your App site:developer.android.com.
2. Как сделать Android-приложение быстрым и отзывчивым.