Comments 108
Экран загрузки придает приложению солидности в глазах пользователя.
Код из прошивки роутера Netis n5
if(data.cpu == "100%"){
var cpu = Math.floor(Math.random()*30) + 50;
data.cpu = cpu + "%";
}
Если знаете похожие примеры - пишите. Мне важно знать что я не самый злостный обманщик. А то кошки скребут на душе.
Старался забыть, а тут пришлось вспоминать не самый успешный опыт
А так хоть коллективная ответственность размывает индивидуальную вину.
Крайне редко тут что-то пишу, но в данном случае не смог устоять.
2000-й или 2001-й год. Весёлое время WinAPI/ATL/MFC. А также Ultimate Toolbox, BCG, CodeJock и прочих улучшайзеров. Я ещё толком не знаю C++, но изучаю его по хардкору, на примерах из Direct3D (конечно же IM, а не RM) и пишу свой 3D Studio MAX, с блэкджеком, проекционным полиэкраном, импортом 3DS, окном свойств, редактором объектов и мегафичей — ТУМАНОМ.
Приложение написано за месяц, да вот беда — оно запускается слишком быстро, и сплэш-скрин с маскотом (низкополигональным ГНОМОМ), которого нарисовал коллега, не удаётся рассмотреть. А ещё на сплэш-скрине внизу есть компонент progress bar'а, который одна из библиотек (уже не помню, Ultimate Toolbox, кажется) слямзила из новинки тех времён, браузера Netscape Navigator. (Для самых маленьких радиослушателей: по горизонтальной полоске влево-вправо ездил серый градиент, точнее, его пик насыщенности). И его тоже не удаётся рассмотреть, что обидно вдвойне.
Тогда я добавляю в Init() кучу Sleep()'ов, но вдруг вижу, что градиент перестаёт ездить, а картинка при щелчке становится белой. Еду в библиотеку, зарываюсь в книжки, и узнаю, что есть, оказывается, такая штука — МНОГОПОТОЧНОСТЬ. И если сделать Sleep() в главном потоке UI, то градиент (как и картинка) перестаёт перерисовываться.
Архитектура срочно меняется на многопоточную. Заодно в свете новых знаний движок переписывается с нуля. И вот, наконец, сплэш-скрин висит секунд десять, всё тормозит, как в лучших домах Лондона и Парижа, сразу видно — СЕРЬЁЗНЫЙ ПРОДУКТ. Но чего-то не хватает. Чего? А вот чего: экран висит, градиент ползает, а индикатор жёсткого диска не моргает! Липа, короче. Фейк.
Штош, начинаю создавать в отдельном потоке кучу файлов и писать в них rnd(). Заодно узнаю, как правильно работать с папкой tmp, с каталогами юзерского профиля, что нельзя писать в Program Files и т.д. Опять переписываю движок.
Наконец, всё готово. Экран не только тормозит, но и отчаянно трещит жёстким диском. Ну прямо Microsoft Word и Adobe Photoshop. С этим приложением я иду в одну контору, показываю его на собеседосе, и меня берут, несмотря на малый возраст, писать софт для трёхмерной визуализации месторождений. Хэппи енд.
Drake
Приложение написано за месяц, да вот беда — оно запускается слишком быстро, и сплэш-скрин с маскотом (низкополигональным ГНОМОМ), которого нарисовал коллега, не удаётся рассмотреть.
Т.е. что бы фотошопе успеть прочитать все имена?:)
ps писал фэйковый вывод при загрузке курской PC XT совместимой машины, для чего-то было надо в офис, там ещё было смешное: При двух мегах памяти (если не ошибаюсь), писало: load memory emulator 16 Mb...
Мы делали свой прогресс бар (в одной старой игре) относительно честным. Немножко мухлевали в начале (до 15%) и в конце (после 85%). Работало это так: до 15% ползунок идет плавно в течении одной секунды. Далее честная загрузка с отображением реальных 0..100 в 15..85 на экране. Ну и с 85 до 100 тоже плавно за секунду. Даже несмотря на то, что загрузка шла на 2 секунды дольше, чем могла бы, визуально воспринималась бодрее.
Я пробовал решать этот вопрос на сборе статистики (скорость исполнения конкретного отчета [sql]). Реализовал, но не внедрил :(
Да, это "детское" решение, но явно лучше полного отсутствия решения от ДБ для пользователей (у Оракла есть, но не статистика, а предрасчет).
Лайфакх - ставишь спиннер + отсчет времени сколько примерно осталось. Никого не обманывая, легче можно рассчитать примерное время выполнения, корректируя его на ходу, я бы так сделал)
У меня была подобная ситуация при написании диплома в ВУЗе. Задача была переписать одну древнюю софтину, которая что-то там вычисляла. Вычисление делалось путём перемножения матриц конского размера. Считалось всё очень долго, а матрицы были очень специфические, поэтому я забурился в математику, и нашёл алгоритм вычислений, который считал их моментально. На предзащите мне предъявили, что "это фигня какая-то, раньше считало чуть ли не час, а сейчас меньше секунды, так не бывает", поэтому мне пришлось рисовать прогресс-бар, который красиво полз около минуты...
Думаю в контексте защиты диплома надо было понимать это так: "Сейчас зададим ему какой-нибудь вопрос и посмотрим как выкрутится. Делал сам - ответит, делал не сам или мухлевал - смутится и откажется комментировать". Ну, т.е. провокация на для того чтобы началась паника у тех кто не знает своей собственной работы.
Полагаю что их бы устроил ответ в духе: "обычно считают алгоритмом со сложностью О(n^2), но у нас есть специфика благодаря которой мы можем рассчитывать на определённые вещи и использовать алгоритм который считает за O(1)".
Тем самым Вы бы показали что разбираетесь в альтернативах, Вам понятен и вопрос и проблема и предметная область. Эмуляция прогресс бара в этом случае скорее бегство от диалога с комиссией.
Хотя комиссии и члены комиссии разные бывают, может вам не повезло и попался кто-то действительно вредный, кому вообще ничего не докажешь какие бы аргументы не привести.
Нет, там достаточно специфические преподы были, про "алгоритмы со сложностью O(n^2)" они вряд ли знали вообще.
Сочуствую, знающие преподаватели это важно. Мне вот с вузом повезло - преподаватели в большинстве хорошо разбирались в материале, причем не только своем. Когда я на защите начал рассказывать про дискретное преобразование Фурье (с которым не сталкивался в программе вуза и узнал только при работе над темой) меня в итоге перебили и попросили не углубляться в то, что и так всем известно)
Яркий пример, но в другой области, это телефонные гудки, созданы, чтоб пользователи понимали, что телефон работает, длинные гудки после набора номера, чтоб пользователи понимали, что надо просто ждать, а не паниковали из-за тишины
пришлось однажды писать "второй прогрессбар" - фейковый прогрессбар, который показывал, что приложение не зависло, а просто очень медленно скачивает (это сейчас старлинк есть, а тогда через спутник оооооочень медленно байтики скачивались у некоторых денежных клиентов)
Давным давно делал прогрес бар для загрузки и парсинга авиабилетов с одного популярного сервиса. Зачем-то там в дизайне нарисовали прогрес бар. Я честно пытался сделать его честным), но в итоге посчитал среднее время загрузки json-а на несколько различных размеров и поставил таймер 33/66/99/~100 :)
У нас в школе была лабораторная на q Basic, что-то вроде введите значения, получите результат
Я там сделал в начале экран, мол загрузка текстур, моделей... Ну, и прогрессбар, конечно же.
Мы писали программу на ПЛК для установки, которая сохраняла в CSV файл термограмму процесса. И необходимо было термограммы с ПЛК скачивать на флешку. Мы точно знали размер файла, но никак не могли узнать сколько байт передано (либо в библиотеке не было этой информации, либо просто не хватило времени разобраться). Но нам повезло, что на ПЛК был медленный USB 1.1, а все флешки работают быстрее. Поэтому скорость загрузки файла всегда была константной.
Зная скорость USB и общий размер файла, мы достаточно точно определяли время загрузки и отображали ход на сэмулированном прогресс-баре, естественно на всякий случай писали прогресс от 0 до 98%.
Где-то именно на Хабре в комментах было: мол, в одной конторе прикрутили красивую фичу – отправляешь заявку во внутреннюю техподдержку и любуешься на прогресс-бар по срочным заявкам. В какой-то момент выяснилось, что прогресс-бар – просто картинка. Ребятам в техподдержку падала срочная заявка, и пока они её руками делали, пользователю отрисовывался красивый прогресс выполнения ))
Иногда полоса загрузки или хотя бы спиннер очень нужны в приложении. Пусть даже на несколько секунд.
В приложении "Huawei Health" есть кнопка "Проверить обновление прошивки носимого устройства". Ты её тыкаешь и через доли секунды появляется результат, что уже установлена самая свежая версия ПО. Даже не верится, что там что-то проверялось. Вот если бы покрутился спиннер пару секунд, то такой результат был бы более уважительным :)
P.S. Это не шутка. Часто тыкаю кнопку "Проверить обновления" дважды из-за слишком быстрого ответа :)
Где-то писали похожее про кнопку "сохранить" в офисе или libreoffice, не помню. Типа, многие нажимают несколько раз, потому что слишком быстро сохраняется и не понятно, то ли сработало, то ли нет. Хотя вроде как сейчас обозначают и цветом значка кнопки и сообщением где-то в строке статуса, звездочкой в названии или ещë как-то.
Типа, многие нажимают несколько раз, потому что слишком быстро сохраняется и не понятно, то ли сработало, то ли нет.
А у нормальных людей после сохранения текст на кнопке меняется на "СОХРАНЕНО!" и она становится неактивной.
Дык, в той же Винде, бывает, сделаешь двойной клик по ярлыку на рабочем столе — и чо-то никакой реакции не видно, и сиди, гадай: а оно запускается или чо? а может, я не докликнул? а может, оно упало уже? Подождёшь, ещё раз даблкликнешь, потом ещё. Через несколько секунд оно возникает на экране в пяти экземплярах. В каком-то линуксовом оконном мессенджере, помню, было интуитивнее: кликнул, иконка начала как-то жмыхаться туда-сюда — значит, ты, во всяком случае, всё правильно нажал.
В одном очень и очень давно ученом мануале по улучшению UX приложения было написано, для улучшения отзывчивости приложения не обязательно реально улучшать отзывчивость, достаточно показать пользователю, что приложение работает, самый простой способ это прогресс бар. Ну а если нет данных о прогрессе процесса, замедление по экспоненте наш выход )
Самый тут простой способ - это крутящееся колесико, и ничего с заполнением мудрить не надо.
С колёсиком работу не отличить от зависания, а вот прогрессбар, который заполняется (пусть и фальшиво) сразу успокаивает.
Колесико не крутится - значит все зависло.
Если колесико реализовано через показ gif, то оно и будет крутится, только бесконечно)
Обычно за отрисовку колесика отвечает система, и даже если UI тред завис - оно будет продолжать крутиться. Чтобы было "по-честному" - надо, чтобы именно из рабочего потока периодически вызывалась функция поворота колесика на несколько градусов, но кто с таким будет заморачиваться?
Успокаивает он только до тех пор пока программа не зависнет с этим прогресс-баром.
Колесико не дает ощущения работы и какого то прогресса в ее выполнении, а прогресс бар дает.
Давным-давно, лет 19 назад, писал на vb6 программу для диплома, по обработке данных (численное вычисление магнитных полей было вроде). Так комп не особо шустрый, и вычисления занимали много часов. Пришлось почти сразу придумывать прогрессбар или два даже, иначе не видно было, движется там или повисло всë по какой-то причине. И вроде ничего, норм было. Пока не узнал что можно приоритет процесса через winapi менять, ну и поставил в высокий очень - а при нëм вычисления довольно быстрее стали, но прогрессбар уже не отрисовывал - его приоритет был ниже, и казалось, что зависает. Потом сделал крутилку для оперативного переключения приоритета прямо во время вычислений - можно было выбрать что важнее - несколько быстрее вычислить, или чаще видеть изменения прогресса. Без него проблемно прям.
А вот в mathcad'е не было прогрессбара, и когда забиваешь огромную формулу чтобы он что-то там упростил или решил уравнение в символьном виде - всë зависало, и непонятно было, сколько ждать. На некоторых задачах у меня комп жужжал часов 6. Кто-то из однокурсников говорил, что было и сутки ожидания, пока посчитает, но того стоило. Вручную все эти фурье и z-transform считать и дифференцирование-интегрирование - ну его нафиг. Вот что мешало там тоже встроить прогрессбар?
Если вычисления становятся быстрее при повышении приоритета — значит, запущена куча ненужных программ которые надо бы закрыть. Так что это не нормальное решение, а трюк из разряда выживания на свалке.
А прогрессбару (точнее, потоку UI) тоже можно приоритет менять, странно что вы этого не нашли...
Так я не программист :) Там и код не очень-то был, я подозреваю. В то время интернета-то нормального не было, диалап по карточкам, и как бы не соврать, всё ещё WinME стояла на на компе. Про закрытие программ я экспериментировал, вплоть до замены shell :-) Но на одном ядре AMD Duron 800 далеко не уедешь, как ни крути.
одно из двух:
1 реально некогда переключить контекст (т.е шевеление прогрессбаром замедлит обсчёт задачи) - вполне реально на железе тех времён
2 Объём задачи точно не известен, в процессе выполнения могут образоваться новые штуки, которые надо считать - т.е. хрен знает что взять за 100%. Если сделать в лоб, прогресс будет отползать назад, а люди такого не любят =)
В одном приложении на Дельфях прогрессбар должен был рисоваться, исходя из размера файла. Иногда функция, которая читала размер файла сбоила и возвращала -1. В результате приложение вылетало с ошибкой.
Ааааа, так вот кто пишет эти прогрессбары, которые останавливаются на 99% и висят там дольше, чем до этих 99% прогресс шёл...
Насколько я помню, когда взломали шифрование файлов какой-то из первых версий Word, в программу для дешифровки добавили задержку, чтоб выглядело будто программа числа перемалывает.
Проводнику Windows уже не один десяток лет, и никто даже не пытается написать ему корректный прогресс-бар...
Как я понимаю, он корректный для больших и желательно однотипных файлов. То есть считает исключительно по средней скорости за последнее время и оставшемуся размеру. Как только в дело вмешиваются мелкие файлы - все, предсказать невозможно. Кстати интересно, существуют ли реальные (и не замедляющие процесс) способы сделать там реальный прогресс, учитывая разный размер файлов в очереди.
Старый добрый Total Commander наличие разных/мелких файлов не смущает. А ещё эта "подготовка к копированию", которая длится дольше, чем само копирование. Вы там файлам шапочки надеваете перед походом в другую папку?
Вот вспомнил Total Commander, но показалось, что там тоже были проблемы какие-то с точностью. Надо ради интереса что-нибудь мелкое в больших количествах покопировать.
Подготовка к копированию - загадочная штука, давно интересно, что они реально там готовят. Не удивлюсь, если все это время пытаются собрать данные для прогресс-бара.
Там просто идет пересчет размера файлов и составления списка копирования. Так файлов может быть много и вложенных директорий много, по каждой из которых нужно получить список файлов и узнать из размер - эта операция может занимать много времени. Это необходимо как раз ради подготовки прогресс бара. Однако, можно копировать на лету без этого, но тогда будет известно время копирования и возможные проблемы (например, файл только для чтения или есть такой же файл в директории назначения).
Насколько помню, в настройках Total Commander была галочка, которая позволяла не подсчитывать время копирования, тем самым копирование ускорялось, но при этом прогресс-бар не показывал точную статистику.
Это юзер порядка ста лет уже подождал и ещё примерно столько же осталось?
Зато при поиске в проводнике Windows есть та самая - фейковая загрузка, которая расположена на адресе директории. Постепенно замедляясь бежит к краю, но никогда не доходит.
Десятая винда, прогресс-бар доходит до конца (после чего исчезает, оставляя обычную строку "Результаты поиска в ...").
В npm есть пакет для фронтэнда который делает тоже самое, почти миллион загрузок в неделю https://www.npmjs.com/package/nprogress
Ну что делать если пользователям так больше нравится
Пришли однажды юзеры с жалобой - жмешь кнопку, говорят, и понять невозможно, что происходит, покуда операция не завершится.
Ок, мы сочинили прогресс индикатор в виде окошка, где есть горизонтальная полосочка, символизирующая процент прогресса, а так же текстовое поле с названием текущей операции.
Откуда брать процент? Насочиняли всякой сложной логики, как учитывать распараллеливаемые операции, как вложенные, что делать, если текущая операция добавит другую (дада, прогресс откатывался) и еще всякие интересные кейсы.
Юзеры довольны, разработчики - нет. Подсчет процента оказался сложным.
В один прекрасный момент я просто выбросил всю сложную логику.
Вместо нее начал считать так: от момента начала операции в течении ожидаемого максимального времени операции (эмпирическое значение, десятки секунд) процент равномерно бежит от 0 до 60, далее - каждые 10 секунд добавляется по проценту, и так до 99.
С тех пор прошел год. Никто не жаловался.
Эх, сервелат, ностальджи
Таким образом мы дурим пользователя за его же деньги. И обмануть его не
трудно! Он сам обманываться рад! И это не фигура речи, дословно не
помню, но желание коллективного пользователя было сформулировано как-то
так: “Сделайте хоть что-нибудь чтобы мы видели что приложение не
зависло, и примерно представляли сколько ещё осталось ждать”.
Простите, а вывести таймер чем плохо? И видно что процесс не завис и обмана нет.
Вот так делают поддельные экраны загрузки, а потом пользователи удивляются, а что же это у них на ста процентах ещё на несколько десятков секунд застревает программа или игра)
Я и сам как пользователь этому удивляюсь. Но...
Тут всё гораздо хуже чем кажется:
загрузка идёт плавно - пользователи удивляются
загрузка идёт рывками - пользователи удивляются
загрузка не идёт но приложение думает - пользователи удивляются
приложение запустилось без загрузки - пользователи удивляются
Пользователи всегда удивляются. Можно потратить много времени на честную оценку но пользователи всё равно будут удивляться.
Это и для реальных экранов нормально, ведь экран загрузки обычно показывает прогресс по некоей конкретной, заданной разработчиками, очереди задач, а после ее окончания может проделываться еще какая-то тяжелая работа в главном потоке, из-за которого собственно все и подвисает.
Но, в отличие от поддельного, тут есть два преимущества: время подвисания более-менее фиксированное и зависит обычно только от производительности девайса, а еще это можно зарефакторить и таки сделать по-человечески =)
Разрабатывали мы один проект АРМ на базе Линукс. По сути, запускалось наше ПО автоматически при старте системы в полноэкранном режиме, но начальные экраны загрузки системы были видны, что раздражало заказчика и коробило общее чувство прекрасного. Пришли к тому, что в качестве изображения silent boot поставили "лого" проекта, на экране загрузки самой системы - то же лого с названием проекта и статическое изображение прогрессбара на 4%. Затем на рабочем столе стояло то же изображение с прогрессбаром на 11%. Потом уже, когда стартовало наше приложение, начинали с того же изображения, готовности 15% и потихоньку доводили до 100% под контролем сложной логики с получением ответов о готовности разных железяк вперемежку с несколькими sleep()ами.
Эта картинка подходит тут как никогда
Мне вот как раз больше нравится, когда приложение (или ОС) честно показывает текстом, что сейчас делается, и не надо особо прогресса никакого, ну можно счётчик типа "1 из 20: запуск службы хххх", если применимо и заранее известно количество. Можно ведь и в программах так делать (и во многих делают), что если программа что-то загружает, пишет, какой файл загружается, если что-то вычисляет - что именно вычисляет (если это может быть долго). А всякие splash-screen'ы только в неведении держат. Может оно и оправдано, если нужно скрыть от пользователя внутреннее устройство (неважно что мы там делаем, вот тебе готовый результат, а пока смотри картинку).
Делали внутренний продукт и там был один тяжелый запрос в БД. Ответ ехал около 40 сек после всех оптимизаций. Чтоб юзеры не думали что все подвисло, я прикрутил фейковый прогресс-бар (спиннеров тогда еще не придумали), он мелкими рандомными рывками шел к 100% в течение тех 40 секунд. Потом поменяли это дело на спиннер, медитировать на который юзерам нравилось больше. Процент "загрузки" отрисовывали внутри спиннера по тому же алгоритму, по которому двигался прогресс-бар.
Год эдак 2004, мы пишем на Дельфи 7. На нашем заводе активно внедряют юникса и делают локалку.
Мы пишем программу, которая - о чудо, локалка же! - ходит не только в промышленную сеть, но и в локалку. Установщик все подтягивает, подкачивает, настраивается, опрашивает профибас, гребет данные с серверов в соседнем здании по эзернет.
Но блин - сеть иногда тупит, а сроки горят. Надо представить цеху красивую поделку на радость начальнику смены. Мы им приносим не просто программу, а программу с установщиком! (ой да это как я игрушки дома ставлю, покажите? Интересно)
В принципе все хорошо, но в двух местах программа не может четко понимать время, оставшееся до конца работы и наш прогресс бар "подвисает". Мы делаем гениальное для того времени решение - изобретаем спиннер! - делаем прогресс бар который закрашивается в обе стороны.
Устанавливаем программу на рабочем месте начальника смены - и дядька задумчиво смотрит как прогрессбар добежал до 100% и побежал к нулю. И примерно при 50% все закончилось.
Хммм... - сказал дядька
Программа установлена! - сказали мы. - Можно работать. Обновление поставится таким же способом.
Хорошо.... - сказал очень задумчивый босс цеховиков. - Мы сами сможем поставить, тут все просто...
Если бы я увидел как прогресс бар побежал обратно, я бы испугался: "эй куда, всё же было, вернись я всё прощу"
Мы импровизировали, а заказчик задачи "завис" на стадии приемки. Но принял :)
Тем более, в каком-то из стандартных установщиков (то ли InstallShield, то ли MSI) если при установке происходил сбой, прогресс реально откатывался на 0. Так что повод волноваться действительно был.
"Удаление временных файлов и прочего мусора"
У меня такое буквально позавчера было. В Factorio при игре по сети сначала загружается статический файл сохранения, а потом подтягивается и применяется дифф событий, которые произошли на сервере за время, прошедшее с начала загрузки. Хост, ожидая пока я загружусь, подошел к месту с высокой активностью ботов, которые, судя по всему, генерировали события быстрее, чем мой клиент успевал их загружать и применять, в результате чего у меня шкала загрузки натурально поползла влево.
Мы когда в колледже делали курсовые и дипломы для понтов вставляли меню загрузки, типо смотри как могу
Тоже была задача сделать прогресс-бар при получении данных из БД. Сделал таблицу для хранения замеров производительности в зависимости от параметров и отборов, и подставлял нужное количество секунд.
Довродилось ковыряться в системе загрузочных задач движка одной мобильной игры, так вот у нас все было относительно честно: общий прогресс определяется количеством запланированных и завершенных задач, а так же локальным прогрессом самих задач. Те таски, которые могли (и хотели) точно сообщать о своих достижениях, сообщали, некоторые мухлевали и выдавали приблизительный результат, некоторые о прогрессе не сообщали и результат бинаризовался.
Прикольно делать процентные индикаторы для процессов продолжительность которых вы не знаете и которые всегда разные в зависимости от 100500 факторов.
Во времена ремонта сотовых телефонов, товарищ писал мне программу, изображающую что комп подключен к телефону, бежит полоса загрузки и потом выдает ошибки.
Клиенты стоят над головой и просят что бы сделал телефон прямо сейчас, а когда показываешь -вот смотри программа видит кучу неисправностей и за пол часа не устранить, клиент с спокойной душой оставляет телефон в ремонт.
Продвинутые юзеры знают что если пристально смотреть на полосу загрузки, то загрузка происходит немного быстрее.
Если серьёзно - какой-то блоггер почему-то решил что полоса обязательно должна означать время и двигаться равномерно.
Но обычно она показывает сколько из этапов задачи пройдено и сколько осталось. На многих экранах загрузки приложений можно видеть ещё и подпись к текущему процессу. Типа "загрузка шрифтов", "инициализация библиотеки такой-то" и т.п.
Пользователи к этому привыкли и вполне лояльно относятся.
Не надо искать проблему там где её нет.
Мы так для одной конторы контроллер делали для сбора данных с картридеров по Wiegand, стартовал то он моментально, но чтобы прибор казался солиднее - я добавил визуальный процесс инициализации: по дисплею 16х2 две секунды полз прогрессбар. Все были в восторге.
Прогресс-бар делается для пользователя, чтобы тот не скучал. Поэтому не важно как он выводится, если пользователь не злится, значит всё норм.
Всегда интересно наблюдать как в кино когда ищут по отпечаткам на экран монитора выводятся фото и отпечатки проверяемого человека. При этом ты понимаешь, что в реальности это просто мишура потому что это адски тормозит процесс.
Из-за этих киноделов наверно не одно когнитивное искажение появилось. Понаснимают всякого ради красивый картинки, а пользователи потом удивляются почему программы не выглядят так как в кино, - приходится подстраиваться под ожидания.
Вот она - фабрика грёз, со всеми последствиями
Если пользователи требуют, чтобы на экране "быстро-быстро мигали те, кого сейчас проверяет", можно зациклить гифку из 50 условных скриншотов интерфейса, поставить длительность кадра доли секунды, и показать поверх остального) никто прочитать все равно не успеет, но зато успокаивает: работа ведется, ожидайте :)
Я когда переписывал толстую server-side генеренную страницу на модный асинхронный JS, прикручивал специально спиннер - общее время загрузки хоть и немного увеличилось (пустая страница со спиннером и запрос в api), но по ощущениям сильно лучше стало восприниматься, чем "подзависшее" пустое окно браузера
А размеры модулей сильно менялись? Почему бы было не захардкодить размер в коде, если в заголовках пусто? Это было бы куда менее трудозатрадно
Если знать нужное место где надо хардкодить то да, было бы куда менее трудозатрадно и более того привычно. Но я такого места не нашёл. А тратить дальше время на поиски было не целесообразно.
Можете помотреть первоначальный код aspx страницы, я его самым первым листингом приложил. Куда там можно захардкодить!? По этой странице вообще не скажешь, что есть какая-то полоса загрузки, а она всё же была. Очевидно, что если и хардкодить размер файла, то явно не там.
Изначально планировали сделать быстро заглушку, а потом поискать ещё, но заглушка всех устроила и поиски забросили. Нет ничего более постоянного чем временное.
Как-то раз меня с честным прогрессбаром достал главный продажник: мол чо это у тебя полоска доходит только до 90 и на этом месте все нужное уже появляется на экране? Не объяснишь ведь продажнику, что последний файл залетает быстрее его ожиданий... Пришлось добавить "процентов" прогрессбару, чтобы он успевал доползти до 100 и продажник ушел довольный.
Но тут вмешался тимлид: нафик ты это очковтирательство захардкодил, убирай! Лишние проценты пришлось отрезать, а продажника стравить с тимлидом: пусть сами разбираются.
Закончилось не помню чем, но эта задача на меня больше не падала.
В следующий раз в другой задаче я не стал ориентироваться на настоящую загрузку, а поставил бутстраповский прогрессбар, который по сути ничего не показывал, а только запускал анимацию полосок на всю ширину индикатора. Этот вариант ни у кого не вызвал вопросов и ушел в прод сразу...
Это было давно.... Был Qbasic, который поставлялся отдельно с редактором и компилятором на "Англицком" языке :-). Тестовый интерфейс программы с поддержкой мыши. "Аля драйвер" был написан на псевдокодах и грузился в память. В зависимости от мощности ПК 286, 386, 486.. Было найдено оптимальное время которое требовалось на загрузку всего (что бы мышка заработала) и был сделан экран загрузки в котором через цикл была загрузка экрана.... Это был 2000 год.... 11 класс....
В некоторых играх: анимация, прогресс бары, и прокручивающиеся счетчики - это вообще основа игрового процесса, гарантия того, что пользователь не будет слишком быстро проходить игру и зарабатывать очки. И вот это вот бесит максимально.
На одной из работ происходила проверка оборудования. Длительность ее была неизвестна, но не должна была превышать 1.5 минут. Поэтому прогресс бар просто заполнялся как текущее время от начала/1.5 минуты.
Признаюсь: я писал поддельный экран загрузки