Поведение «назад» в богатых веб-приложениях, истинное предположение пользователя?

Question

Многие клиентские библиотеки кода и наборы инструментов, например, YUI от Yahoo и GWT от Google, поддерживают управление историей состояний для удобства пользователей. При реализации он позволяет пользователю вернуться к предыдущему состоянию приложения на той же странице, когда он нажимает кнопку «Назад» или клавишу «Backspace».

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

Я вижу ценность в таком подходе, но я не уверен, что он действительно соответствует ожиданиям среднего пользователя. Исследуя этот вопрос о StackOverflow, я обнаружил, что многие люди отзываются о зле переопределения функциональности «Назад», разве нельзя утверждать, что этот подход относится к этой категории?

Лично я был разочарован много раз, когда «Назад» просто менял состояние страницы, когда я действительно хотел выйти в мое последнее место просмотра. Для моего использования 99% сценария использования Back - это не изменение состояния, а изменение страницы .

Наконец, мой реальный вопрос: Как мы можем поддерживать управление историей для многофункциональных веб-приложений без переопределения «Назад»?

Редактировать (обзор лучших практик):

• Прочитав запись в блоге Майкла, Теперь я думаю, что для отмены на пользовательский элемент управления без ссылок (выпадающий, текст поля и т. д.) я бы положился на Control-Z и / или кнопка - пользовательский интерфейс шаблон, который широко поддерживается.

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

Answer 1

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

В частности, единственное хорошее решение, которое я вижу, - это вернуть пользователя обратно на всю страницу в браузере. Другими словами, обрабатывайте Back как «Закрыть» или «Отмена» (или просто нажимая на другое окно) в приложении толстого клиента. Это согласуется с моим первым абзацем, потому что пользователи обычно ожидают, что ссылки будут перемещаться по всей странице. Поэтому Назад тоже надо.

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

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

Для веб-приложений требуется не переопределение «Назад» или «История», а полностью независимая функция «Отменить», дополненная собственным буфером «Отменить», для обработки пользовательского ввода на странице.

Все подробности у меня на http://www.zuschlogin.com/?p=41

Answer 2

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

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

Answer 3

На мой взгляд, история страниц и история состояний приложений - это две совершенно разные вещи. Итак, у нас есть две шезлонги: 1. Мы рассматриваем приложение как веб-сайт - в этом случае Back (и Forward тоже) должны работать так, как если бы он был написан на простом html. Как Gmail делает, как упоминал Rjmunro. 2. Мы рассматриваем приложение как приложение (одна страница) - в этом случае кнопка «Назад» откроет вам страницу до запуска приложения. Это твои 99%, верно?

BWT, Backspace самый раздражающий.

Answer 4

«Богатое веб-приложение» должно быть очень осторожным в отношении того, что пользователь воспримет как «новую страницу», и что скорее будет восприниматься как какое-то действие на странице. Это восприятие того, что такое «страница», должно отражаться в поведении истории просмотра (кнопки «назад» и «вперед» - просто способ взаимодействия с историей просмотра).

Многие "многофункциональные веб-приложения" лучше были бы простыми HTML-страницами. В таких приложениях часто очевидно, что такое «страница».

В других приложениях лучше использовать реальную модель клиент-сервер: должна быть возможность загружать клиента только один раз, а не для каждого нового сеанса. Такие приложения часто не имеют явной «страничной» модели, поэтому у каждого пользователя есть свое представление о том, что должна делать кнопка «назад». В такой ситуации было бы хорошо даже не представлять «подобный веб-браузеру интерфейс», чтобы не вызывать ложных ожиданий. Я считаю, что такие технологии, как Java Web Start, являются хорошей основой для таких приложений.