Реалистичные оценки времени для баров прогресса и т.д.

Я знаю, что я не единственный, кто не любит индикаторы прогресса или оценки времени, которые дают нереалистичные оценки в программном обеспечении. Лучшие примеры - это инсталляторы, которые прыгают с 0% до 90% за 10 секунд, а затем занимают час, чтобы завершить финальные 10%.

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

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

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

Кто-нибудь знает о передовых решениях этой проблемы?

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

ИЗМЕНИТЬ: Я могу придумать, как вручную настроить оценку времени, и даже с помощью "библиотеки оценщиков" мне придется точно настроить алгоритм. Но я думаю, что эту проблему можно было бы решить с помощью статистических инструментов. Разумеется, оценщик собирал данные во время процесса для создания более качественных оценок для следующих шагов.

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

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

Ответ 1

В то время как undergrad, Julian Missig, и я провел эксперимент, не похожий на Harrison et al. бумага. Как и следовало ожидать для проекта класса, на самом деле мы не получали достаточного количества данных, чтобы принимать сильные претензии, за исключением того, что для 5-секундного интервала, показывающего отсутствие индикатора выполнения, фактически воспринималось как более короткое.

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

Если вам интересно, у Джулиана есть paper и poster на своем сайте.

Ответ 2

Слава Богу, я не единственный!

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

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

Ответ 3

Я не думаю, что проблема в том, что они оценивают количество шагов настолько, насколько это часто используется неправильное определение "шаг". В вашем примере установки с 0 до 9% за 10 секунд, а затем на час для остальных, я видел, что это произошло, когда программист решил подсчитать количество копируемых файлов, а не количество байтов.

Скажем, что было 10 файлов, 9 из них были по 5K каждый (readme, лицензия, значок и т.д.), а последний был 2Gig ISO, ну, первые 9 бы скопировали очень быстро, а последнее было бы медленным! Подсчет файлов был неправильным, чтобы считать, должен был подсчитать байты. Проблема в том, что если вы хотите подсчитать байты, вам необходимо реализовать свою собственную процедуру копирования, чтобы вы могли предоставлять обновления статуса во время копирования большого файла. Действительно ли стоит реализовать свою собственную программу копирования?

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

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

Ответ 4

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

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

Загрузить обновление
Прекратить выполнение процессов
Обновление программного обеспечения
Настройка программного обеспечения
Перезапустить программу

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

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

И индикатор выполнения не делает никаких promises о том, как долго будут выполняться более поздние задачи.

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

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

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

-Adam

Ответ 5

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

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

Какие контролируемые показатели применяются (скорость копирования, скорость распаковки и т.д.)?
Какая средняя наихудшая ставка для этого процесса?

Затем вам нужно создать список того, что вы собираетесь делать для всей работы, например:

Распаковка файла 100meg (группа: распаковка, значение: 100)
Копирование 120megs (group: copy, value: 120)
Настройка значений реестра (группа: реестр, значение: 25)
Очистка (группа: удаление, значение: 100)

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

Microsoft потребовалось десятилетие, чтобы понять это правильно, поэтому не будьте слишком обеспокоены, если сначала не работает =)

Ответ 6

Другой (и гораздо более простой способ) - просто подставить оценку и восприятие пользователя.

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

Если я жду задания, и он заканчивается на 50% в течение 10 секунд - я расстраиваюсь, когда требуется 50 секунд для завершения последних 50%.

Для той же задачи, если она идет до 50% за 30 секунд, продолжается до 60%, а затем магически переходит на 100% - я удивлен, но не раздражен.

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

Если вы находитесь в парах случаев, где вам действительно нужна точность, то, вероятно, стоит потратить некоторое время в коде для повышения надежности панели.

Ответ 7

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

Я использую таблицу базы данных для хранения моих исторических данных. Я повторно построю свою функцию оценки на основе последних 100 записей в таблице.

У меня есть аннотации на длительные методы для определения переменной определения скорости.

YMMV, но в следующий раз оценка учитывает это.