Шаги прогресса для задач, которые могут принимать неопределенное количество времени?

Question

Еще один случайный вопрос, который ударил меня (я выпил ~ 9 чашек кофе за последние 5 часов, поэтому извините ...) - Какой бар показателей вы бы показывали пользователю для того, что вы делаете, Знаете, сколько времени это займет, но у вас есть хорошая идея о «среднем» времени. Например, задача, которая обычно занимает около 30 секунд, но у вас нет способа узнать о прогрессе (кроме того, что она продолжается или просто не сработала). Что было бы лучшим УБ ?:

• бар прогресса, который начинает быстро и замедляется (возможно, с прогресс будучи 1/х стилем асимптотической кривой), которая поражает 50% по среднему времени задачи (стиль затмения руководство предлагает это).
• Индикатор прогресса, который прогрессирует медленно, с постоянной скоростью и, возможно, попадает в «среднее время» на 15% или что-то (IE/Firefox делает это при первоначальном поиске домена)
• Неопределенная squiggly bar (macs все это имеет место и в новых версиях Windows), которые просто показывают какое-то движение, не предполагая какого-либо прогресса, прядильщика или некоторой анимации, которая просто уведомляет пользователя о том, что что-то происходит.

Будет ли отличаться, если среднее время составило 10 минут вместо 30 секунд?

Спасибо, Роберт

EDIT:

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

Answer 1

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

Что я обычно делаю это:

• Если я знаю, что среднее время, процесс может занять, alocate для немного больше, и идти медленно до последнего 20% -10%, то индикатор ускоряет и догоняет реальный прогресс, с таким сроком, что процесс заканчивается в тот момент, когда бар имеет самую быструю скорость.
• Если я не знаю, как долго это может занять, я измеряю много раз, чтобы иметь стадион (в секунды? Минуты? Часы?)
  • Если его повторяющаяся операция с небольшим изменением между пробегами, я беру в учет последнего времени выполнения.
  • Если у вас длительная работа или высокая изменчивость, я не использую индикатор выполнения, а анимацию, чтобы показать, что я работаю.

Только не ври пользователей. Никогда не должен сказать, что все будет через минуту и ​​полчаса.

Answer 2

Почему бы не увеличить прогрессную панель при выполнении задач в методе?

Срок действия задачи или процесса не имеет значения, можно просто увеличить значение progressbar на величину X, когда Y часть задачи будет завершена, или вы далеко зашли в этот процесс. (т. е. каждые 5 килобайт, которые обрабатываются при загрузке 100 килобайт файла)

Answer 3

Определенно индикатор хода парикмахера. Я думаю, что это стандарт для Mac Human Interface Guidelines (HIG). Я уверен, что аналогичные «неопределенные» индикаторы прогресса существуют и для других платформ.

Я бы также поставил индикатор текстового прогресса (например, количество переданных байт, например). «Угадай» процентное завершение может быть осуществимым, но вы обязательно должны быть очень уверены в среднем времени и его стандартном отклонении, в противном случае вы получите много сердитых пользователей, разозленных и отменивших клики, потому что ваш прогресс застрял на 99 % с одного часа. Это было бы очень неприятно для них и для репутации вашего программного обеспечения.

Answer 4

Я превращаюсь в огромного поклонника вращающегося круга стиля Mac и Vista, который указывает прогресс, не устанавливая вводящие в заблуждение ожидания пользователей.

XKCD комический
http://xkcd.com/612/

Answer 5

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

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

Я думаю, что сложная проблема заключается в том, что вы заранее не знаете, КАКОЙ-ЛИБО разумной меры количества работы. Например, вам нужно обработать набор записей, но у вас нет простого способа получить счетчик записей, кроме чтения всех записей и подсчета их, и как только вы это сделаете, вы могли бы просто обработать их по путь. В этих случаях вместо индикатора выполнения я обычно прибегаю к отображению «подсчета прогресса»: как «1 запись обработана», «2 записи обработаны» и т. Д. По крайней мере, пользователь может видеть, что он движется, и после того, как он сделал это, Несколько раз он, вероятно, имеет представление о том, как далеко он продвинется, т. е. он находится в десятках тысяч против сотен тысяч или что-то еще.

Я работаю над системой, которая обычно использует подход, который я нахожу довольно хромым: они просто прикрепляют абсолютно произвольные проценты к любой удобной контрольной точке. Например, если функция считывает кучу данных, сортирует ее, форматирует и печатает, они скажут 25% при чтении, 50% при сортировке, 75% при форматировании, а затем 100%, когда печать сделан. Полагаю, это лучше, чем ничего.

Answer 6

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

Answer 7

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

Если может занять много времени, то лучше быть многословным, такие как:

============================================================================== 
    Executing command xyz.. 

    Started: 10:30 AM (usually requires about 20 minutes to complete) 

    Status: 10:35:10 AM.. Still working...{this line needs to update frequently} 

    [Send to background] [Cancel] 
============================================================================== 

Я видел такие многословные описания в некоторых крупных монтажников где-то; не может точно помнить, где именно, но это, вероятно, операционная система или серверное программное обеспечение. Фразы типа «Эта задача может занять несколько минут» также не редкость в установщиках.

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

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

1. Невозможно определить, сколько времени потребуется.

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

3. хуже всего, вы не можете отменить выполнение запроса.

В этом случае единственной хорошей возможностью было бы дать пользователю «задание» задачи.