Требования к реализации Back-Button

Обновлено 26.11.2018

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

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

Ниже раскрываются 5 основных случаев, когда предположения пользователей идут вразрез с технической реализацией. Решение есть (ниже). Отчего эти случаи крайне важно учесть.

Модальные окна

Различного рода всплывающие окна и формы. Нажимая на кнопку "Обратно" (в браузере), пользователь предполагает, что данная форма закроется. Это особенно актуально, когда форма не имеет крупной кнопки или ссылки "Закрыть" / "Не сейчас".

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

Фотографии во весь экран

Если мы открываем изображение карточки во весь экран, то кнопка "Обратно" должна вести нас не в Каталог, а в базовое представление Карточки.

Фильтрация и сортировка

Для пользователя каждое изменение в выборке каталога (по причине использования фильтров или указания типа сортировки), - это новая страница. По этой логике, при нажатии на кнопку "Обратно" должно отменяться одно действие.

Оформление заказа "шагами" (Accordion Checkouts)

/В зависимости от реализации страницы./

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

Необходимо реализовать все технически так, чтобы при возврате, мы возвращались на "шаг" назад (желательно с сохранением всей введенной информацией).

Пагинация на AJAX (AJAX Pagination)

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

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

Возврат из Карточки в Каталог

Если Пользователь смотрел к примеру нижний ряд товаров в Каталоге, перешел в Карточку товара и вернулся обратно в Каталог, то он должен увидеть именно тот ряд с тем товаром, из Карточки которого он вернулся. Это особенно актуально при реализации с бесконечным скроллингом или show more.

Решение

Решение есть: HTML5 History API

Исключение

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