часть страницы занимает либо актуальный контент (ESPN), либо список популярных видеороликов (YouTube) (рис. 4.3).
Минуточку! Если контент всегда важнее навигации, то как найти на мобильном сайте необходимую информацию? Разве без навигации это возможно? Разумеется, она необходима, но для того, чтобы использовать сайт и взаимодействовать с ним, вовсе не требуется создавать громоздкую систему навигации, способную похоронить под собой сам контент.
Например, мне нравится, что на мобильном сайте Facebook актуальный контент занимает основную часть страницы.
Но при этом в верхней ее части разработчики разместили сразу три навигационные панели, из-за чего на экране умещается всего одна новость. Мобильный сайт Google Finance содержит актуальные данные, но этот контент спрятан под пятью навигационными панелями. Иными словами, драгоценное экранное пространство заполнено навигационными опциями, которые могут и не потребоваться пользователям, в то время как на их месте могла бы находиться полезная информация (рис. 4.4).
Недавно Facebook изменил дизайн мобильного сайта, уменьшив число элементов навигации (рис. 4.5). Если не считать фильтров «Главные истории» и «Последние» в ленте новостей, их стало вдвое меньше (пять вместо десяти). Так держать!
Примеры сайтов YouTube и ESPN (рис. 4.3) показывают, что контент важнее навигации, однако они по-разному решают задачи доступа к основному содержанию и навигации. Чтобы перемещаться по сайту YouTube, необходимо использовать иконку, открывающую отдельную страницу с элементами меню (рис. 4.6). То есть для того, чтобы перейти к навигации, пользователю необходимо совершить действие, которое выводит его из общего контекста сайта (на отдельную страницу).
Кроме того, он должен заранее знать, что иконка с решеткой в шапке сайта — это вход в навигационное меню.
В шапке мобильного сайта ESPN есть хорошо заметная кнопка «Меню», при нажатии на которую открывается обширный (и многоуровневый) перечень пунктов навигации (рис. 4.7). Это позволяет посетителю выбирать направление движения по сайту, не покидая текущей страницы. Кроме того, навигационное меню дублируется в подвале большей части разделов веб-ресурса, что соответствует логике их просмотра: дойдя до конца страницы, пользователь решает, что делать дальше — и облегчает взаимодействие с сайтом при управлении одной рукой. Дизайнеры мобильного сайта YouTube не предусмотрели такой возможности, поэтому их пользователи просто доходят до конца страницы, так как дальше им двигаться некуда (рис. 4.8).
Меню в подвале страницы удобно для дальнейшего перемещения по сайту, но все же оно не должно дублировать все элементы навигации. Лучше, если кнопка меню в верхней части экрана будет просто направлять пользователя к списку навигационных пунктов, расположенному в нижней части страницы (после контента). Мы, например, применили этот прием при разработке мобильного сайта Bagcheck (рис. 4.9). Помимо этого в меню в нижней части каждой страницы мы добавили ссылку на верхнюю часть страницы. Это дает пользователям возможность вернуться в начало раздела, если потребуется еще раз просмотреть его содержимое.
Такой дизайн предполагает минимум навигационных элементов (в сущности, единственную ссылку в начале страницы). Он позволяет пользователям продолжить взаимодействие с сайтом после того, как они достигли конца страницы. Содержание меню не дублируется, а главное, для его работы требуется всего лишь ссылка-якорь, отсылающая посетителя в нижнюю часть страницы. Никаких скриптов JavaScript, оверлеев, отдельных навигационных страниц… Это своего рода HTML0 (который, как я слышал, поддерживается большинством браузеров, за исключением Internet Explorer).
Каждая страница Bagcheck имеет уникальное навигационное меню, позволяющее более детально изучать контент сайта (рис. 4.10). Перейти в другие разделы посетители могут, также воспользовавшись и главным меню.
Возможности контекстной навигации крайне полезны.
На мобильном сайте Gmail (рис. 4.11) контекстное меню расположено в верхней части экрана. Поскольку навигация по сайту напрямую связана с отображаемым в окне сообщением электронной почты, размещение элементов навигации в подвале страницы было бы не очень эффективным. А в этом случае все необходимые функции остаются наверху и всегда доступны.
Всегда интересно наблюдать за тем, как мигрируют решения в области дизайна. Например, в шапке многих нативных приложений для iPhone есть кнопка возврата к предыдущей странице (рис. 4.12). У мобильных устройств компании Apple нет физической кнопки для возврата к предыдущему окну, iOS также не предлагает пользователю каких-либо системных инструментов для этой операции.
C iPhone кнопка «Назад» перекочевала в шапку многих сайтов, хотя зачастую она совершенно не нужна. Многие устройства (Android, Blackberry, Windows Phone 7 и т. д.) имеют физические кнопки «Назад» (рис. 4.13). Такая кнопка есть даже на панели управления мобильного браузера Apple (рис. 4.14). И появление еще одной в шапке мобильного сайта способно лишь запутать пользователя. У него может возникнуть вполне обоснованный вопрос: «А она предназначена выполнять то же действие?»
При разработке дизайна мобильного сайта пусть кнопка «Назад» останется уделом нативных приложений. Если вы хотите помочь пользователю вернуться на предыдущий уровень, дайте этому навигационному элементу другое название.
У многих нативных приложений для iPhone навигационные панели зафиксированы в нижней части экрана, что позволяет управлять приложением при помощи большого пальца. И в отличие от мобильного браузера в нативных приложениях отсутствует нижняя панель инструментов, пожирающая драгоценное экранное место. На примере сайта Yahoo! Mail можно увидеть, как инструменты управления браузером влияют на отображение мобильной веб-страницы. Две панели браузера и два фиксированных меню сайта Yahoo! Mail оставляют крайне мало места для просмотра содержимого почтового ящика (рис. 4.15).
Мобильным сайтам приходится учитывать особенности не одного, а множества браузеров для различных операционных систем. А на устройствах с физическими кнопками определенные проблемы может создавать программное меню, расположенное в нижней части окна (рис. 4.16). Подобное соседство неминуемо приведет к тому, что пользователи будут промахиваться и, выбирая необходимый пункт меню, нажимать на физические кнопки устройства.
Разрабатывая нативные мобильные приложения, вы можете учесть наличие кнопок, расположенных под экраном устройства. Однако мобильные сайты должны работать на любых устройствах, независимо от того, есть у тех такие кнопки или нет.
Таким образом, если для нативных приложений навигационное меню в нижней части экрана может стать неплохим решением, то в случае мобильных сайтов эта идея, скорее всего, окажется не столь удачной с точки зрения юзабилити. Если вам нужно фиксированное меню, пусть лучше оно будет располагаться сверху. Именно так поступил Twitter, разрабатывая новый дизайн своего мобильного сайта (рис. 4.17).
