В какой момент пользователь теряет доверие к Busy Spinner?

Первый сценарий - это действие, которое может занять примерно 2-5 секунд для выполнения, как только пользователь нажал кнопку. Нажимайте кнопку «Занят», пока процесс не будет завершен.

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

Второй сценарий - это действие, которое может занять пару минут. В этом случае я не считаю целесообразным просто отображать Busy Spinner в кнопке. Я думаю, что пользователь начнет сомневаться, если будет достигнут какой-либо прогресс. Поэтому вместо этого появится диалоговое окно:

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

Мой вопрос - как долго это слишком долго для простого Busy Spinner? В какой расчетный период времени я должен начать вводить диалог, в котором упоминается, как долго будет выполняться действие?

169 голосов | спросил Ralt 12 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowMon, 12 Sep 2016 11:59:54 +0300 2016, 11:59:54

8 ответов


179

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

Основной совет относительно времени отклика был примерно таким же в течение тридцати лет [Miller 1968; Card et al. 1991]. Он написал это в 1993 году:

  
  • 0,1 секунды - это ограничение для того, чтобы пользователь почувствовал, что система реагирует мгновенно , что означает, что никакой специальной обратной связи не требуется, кроме как для отображения результата.
  •   
  • 1.0 секунды - это ограничение для потока мысли пользователя , чтобы оставаться без перерыва, даже если пользователь заметит задержку. Как правило, при задержках более 0,1, но менее 1,0 секунды, никакой специальной обратной связи не требуется, но пользователь действительно теряет чувство работы непосредственно на данных.
  •   
  • 10 секунд - это ограничение для сохранения внимания пользователя , ориентированного на диалог. Для более длительных задержек пользователи захотят выполнить другие задачи в ожидании завершения работы компьютера, поэтому им следует дать обратную связь, указывающую, когда компьютер ожидает выполнения. Обратная связь во время задержки особенно важна, если время ответа, вероятно, будет сильно изменяться, так как пользователи тогда не будут знать, чего ожидать.
  •   

В 2014 году он обновил свое руководство следующим образом:

  
  • 0,1 секунды . Ограничьте пользователей тем, что они напрямую манипулируют объектами в пользовательском интерфейсе. Например, это ограничение с момента, когда пользователь выбирает столбец в таблице, пока этот столбец не выделит или иным образом не даст отзыв, который он выбран. В идеале это также время отклика для сортировки столбца - если это так, пользователи будут чувствовать, что они сортируют таблицу. (В отличие от чувства, что они заказывают компьютер для сортировки для них.)
  •   
  • 1 секунда . Ограничение для пользователей, которые чувствуют, что они свободно перемещаются в командное пространство без необходимости чрезмерного ожидания компьютера. Задержка в 0,2 - 1,0 секунды означает, что пользователи замечают задержку и, таким образом, считают, что компьютер «работает» над командой, в отличие от того, что команда является прямым эффектом действий пользователей. Пример. Если сортировка таблицы в соответствии с выбранным столбцом не может быть выполнена за 0,1 секунды, это, безусловно, должно быть выполнено за 1 секунду, или пользователи будут чувствовать, что пользовательский интерфейс вялый и потеряет смысл «потока» при выполнении их задача. При задержке более 1 секунды укажите пользователю, что компьютер работает над проблемой, например, изменив форму курсора .
  •   
  • 10 секунд . Ограничьте для пользователей сохранение внимания в задаче. Для чего-то медленнее, чем 10 секунд, требуется индикатор процентного показателя , а также четко обозначенный способ для пользователя прервать операцию. Предположим, что пользователям придется переориентироваться, когда они вернутся в пользовательский интерфейс после задержки более 10 секунд. Задержки более 10 секунд приемлемы   во время естественных перерывов в работе пользователя, например, при переключении задач.
  •   
ответил SteveD 12 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowMon, 12 Sep 2016 12:32:24 +0300 2016, 12:32:24
76

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

  1. Я сразу же начинаю отменять набор инструкций

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

  3. Я говорю, что не знаю, но я встречаюсь с кем-то другим, кто знает, и я могу написать вам ответ через несколько минут.

  4. Я стою там, ничего не делая, почти так, как будто я тебя не слышал.

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

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

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

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

ответил Roger Attrill 12 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowMon, 12 Sep 2016 12:57:32 +0300 2016, 12:57:32
37

эмпирическое правило Скотта Клеммера:

  

Ответ короче секунды: без обратной связи

     

Ответ от 1 до 5 секунд: BusySpinner

     

Ответ более 5 секунд: индикатор выполнения

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

ответил Pierre.Sassoulas 12 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowMon, 12 Sep 2016 14:54:47 +0300 2016, 14:54:47
12

В соответствии с этой статьей из NNGroup на основе исследований когнитивной психологии:

  • через 1 секунду пользователь может начать терять мысли о текущем процессе.
  • через 10 секунд пользователь, скорее всего, переключит свое внимание на другую задачу.

Мы не хотим, чтобы пользователь переключил свое внимание на что-то другое, поэтому мы должны отобразить диалог до этих 10 секунд. Кроме того, исследованиям исполнилось 25 лет, поэтому компьютеры стали намного быстрее, и пользователи ожидают, что все загрузится быстрее.

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

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

  • использовать индикатор выполнения
  • объясните, почему требуется время для загрузки.
  • показать приблизительное время загрузки
ответил Kristiyan Lukanov 12 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowMon, 12 Sep 2016 12:23:07 +0300 2016, 12:23:07
7

Десять секунд, после чего я начинаю думать, что «это не работает», и я беспокоюсь о том, что моя кредитная карта обрабатывается или не обрабатывается дважды, если мне нужно это сделать снова.

Хорошо изменить сообщение через 10-15 секунд, чтобы «он по-прежнему загружается, не нужно беспокоиться» или какое-либо другое положительно успокаивающее сообщение.

Просто пример отправляет электронное письмо в gmail, не вставляя вложение в preupload. Сообщение меняется с «отправки» на «он все еще работает».

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

ответил Ivan Venediktov 12 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowMon, 12 Sep 2016 12:18:20 +0300 2016, 12:18:20
5

Извините, вы все цитируете старые исследования. Google обновил это.

125 мс пользователь ожидает отклика какого-либо типа, например, значок загрузки после нажатия.

250 мс пользователь начинает замечать, что действие происходит.

500 мс ожидает, что пользователь будет обновлен в ответ.

1 пользователь ожидает, что содержимое будет загружено.

10 лет я сдаюсь.

Слайд 12: https://docs.google.com /presentation/d/13AJe2Ip4etqA8qylrva7bEgu1_hAvsq_VQiVOAxwdcI/mobilepresent?slide=id.g1e697bbb_0_7

https: //разработчики. google.com/web/tools/chrome-devtools/profile/evaluate-performance/rail?hl=en

ответил James Wilkinson 16 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowFri, 16 Sep 2016 23:45:00 +0300 2016, 23:45:00
1

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

ответил blackpen 14 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowWed, 14 Sep 2016 15:35:32 +0300 2016, 15:35:32
0

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

Если мы покажем индикатор выполнения (или даже прядильщик), он может просто мерцать на экране и немедленно исчезнуть, что, по моему мнению, смущает UX.

Менее идеальным решением для этого (иногда реализуемым) является просто решить, что пользователь будет ждать некоторое время независимо от того, насколько быстро эта задача завершена ... например. 1 секунда + время задачи, таким образом, счетчик /индикатор выполнения, по крайней мере, остаются видимыми в течение некоторого времени.

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

ответил Brad Thomas 19 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowMon, 19 Sep 2016 16:21:23 +0300 2016, 16:21:23

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132