UI/UX Design в приложениях реального времени

Question

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

В Meteor совершенно бесполезно обновлять браузер, изменения данных напрямую переносятся на клиента.

Какая практика применения UI/UX соответствует этому виду поведения приложения?

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

Answer 1

В последнее время я общаюсь с этим, и есть несколько разных способов, с которыми я справился, в зависимости от сценария.

Иногда это не имеет большого значения для UX, который пользователь обновляет. Как правило, для часто изменяющихся данных вы можете использовать такие методы, как описанные in this link about designing for realtime (предоставленные с помощью ответа larsbuur), чтобы ваш пользователь понял, что они не нуждаются в обновлении. Общая идея состоит в том, чтобы использовать ненавязчивые, но видимые и четкие сигналы, которые изменили данные.

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

Вы также можете напомнить пользователю, что после обновления они не нуждаются в обновлении. Например, с помощью web storage API:

Meteor.startup(function() { 
    var reload = !!sessionStorage.getItem('reload'); 
    var manualReload = reload && !Session.get('hotReload'); 

    if (manualReload) { 
    // Tell the user they don't need to manually reload the browser 
    } 

    sessionStorage.setItem('reload', true); 
    Session.set('hotReload', true); 
}); 

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

Это можно сделать, если у вас есть окно времени повторного подключения, где пользователь может восстановить свою позицию, или пользователь потеряет свое место в фойе после таймаута. Это полезно с помощью mizzao:user-status. Это, на мой взгляд, самый дружественный вариант UX, и вы даже можете отображать значок spinner рядом с именем пользователя, чтобы указать другим пользователям, что пользователь может повторно подключиться. Тем не менее, мои попытки реализовать это оказались немного ошибочными и непредсказуемыми, когда дело доходит до целостности данных/надежности сервера.

На данный момент я решил просто использовать the beforeunload event, как и StackOverflow, когда вы печатаете. Он не очень настраиваемый и не такой дружелюбный, как прозрачная перезагрузка/повторное подключение, но иногда это лучший компромисс, когда вы просто хотите предупредить пользователя, почему они не хотят обновляться прямо сейчас.