Тарас Бакусевич написал об индикаторах загрузки.

— Видимость состояния системы — одна из эвристик Якоба Нильсена;
— Наличие информации о загрузке увеличивает допустимое время ожидания (в эксперименте: 23 секунды против 9);
— Неопределённые индикаторы, в отличие от определённых, не показывают прогресс и сколько времени осталось до окончания;
— Если ждать меньше секунды, индикатор загрузки показывать не надо, чтобы не сбивать пользователя с толку;
— Если больше 3 секунд, нужны определённые индикаторы;
— Не используйте сложные анимации, так как для их корректного завершения может не хватить времени. И не стоит искусственно увеличивать время загрузки ради завершения анимации;
— Не отображайте несколько одинаковых индикаторов для отдельных элементов экрана;
— Показывайте скелет экрана, чтобы повысить воспринимаемую скорость загрузки. А лучше постепенно отображайте готовый контент (прогрессивная загрузка);
— Во время долгой загрузки дайте пользователям возможность продолжить работу с интерфейсом и при необходимости прервать процесс, чтобы у них было чувство контроля за ситуацией;
— Встраивайте индикаторы прогресса в другие элементы интерфейса, например, в кнопки, чтобы показать связь между действием пользователя и реакцией системы;
— Если процесс долгий, рассказывайте об этапах загрузки или выполняемых фоновых процессах;
— Можно показывать подсказки, советы, интересные факты или просто забавные надписи.

In English. #loader

Самхита Танкала написала о каркасных экранах (Skeleton screen).

— Они заполняют экран на время загрузки, имитируя его внешний вид;
— Применяются при загрузке всей страницы целиком, а не отдельных её блоков;
— Наиболее распространённый вариант — имитация структуры страницы и её контента серыми прямоугольниками. Помогает сформировать ожидания от структуры страницы;
— Они могут быть анимированными (мерцание, движение слева направо, постепенное появление элементов) и таким образом показывать, что загрузка идёт, и сокращать воспринимаемое время загрузки;
— Каркасные экраны снижают когнитивную нагрузку, не показывая пользователю пустой экран со спинером. Переход к новому экрану с контентом становится более плавным;
— Их лучше использовать, когда загрузка занимает от 2 до 10 секунд. Меньше — будет мельтешение. Больше — нужен прогресс-бар.

In English. #loader

Антон из X5 Tech написал о загрузочных экранах.

— Чем сложнее страница, тем дольше ждать, пока её отобразит браузер. Из-за долгого ожидания пользователь может уйти;
— Сайт может отдавать браузеру часть кода, чтобы пользователь мог что-то увидеть (загрузочный экран), пока загружается всё остальное;
— Загрузочный экран нужен, если ждать (даже периодически) надо больше 3 секунд;
— Чтобы он не мелькал при быстрой загрузке, поможет анимация появления: 350−500 мс для страницы и 250−350 мс для отдельных блоков;
— О необходимости и типе загрузочного экрана стоит думать при проектировании продукта, чтобы потом не переписывать код;
— Надо понять причины долгой загрузки: тормозить может часть страницы (большая таблица, длинный список) или отдельный компонент (получает данные из стороннего сервиса с низкой производительностью);
— На загрузочном экране может быть спиннер или другая зацикленная анимация (включая стилизацию под скелетон), которая даёт понять, что загрузка идёт;
— Технически сложнее отображать прогресс, чтобы пользователь понимал, сколько ещё ждать. Надо уметь определять, какие файлы нужны, их вес, скорость загрузки. Лучший вариант для ожидания больше 10 секунд;
— Скелетон — серые плашки вместо практически каждого элемента загружаемой страницы, показывающие реальную её структуру. Обычно с анимацией волны (для быстрой работы) или пульсации (для неспешной работы, когда цена ошибки высока);
— Отображается на доли секунды позже других загрузочных экранов, так как содержит вёрстку страницы;
— Позволяет загружать страницу частями. Если первой загрузится навигация, пользователь сможет перейти в другой раздел, не дожидаясь загрузки ненужного контента;
— Ещё можно загружать данные фоном. Пользователь выбирает файл для редактирования, можно загружать ресурсы редактора;
— Или попытаться отвлечь, отображая во время ожидания советы по функциональности, мини-игры и так далее;
— Консистентность: если используете скелетоны, спиннер в раскрывающемся списке будет выглядеть неоднородно;
— Приёмы можно комбинировать, например, отображать скелетон и ненавязчивый прогресс-бар, если загрузка длится долго.

#loader

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

— На примере ресторана: гость за столиком (клиент) заказывает карбонару (запрос), который официант передаёт на кухню (сервер). Повар берёт ингредиенты со склада (база данных) и готовит. Официант подаёт готовое блюдо (ответ);
— Возможны состояния: гость заказывает то, чего нет в меню, и об этом сообщает официант (ошибка пользователя), на складе закончился пармезан (ошибка сервера), официант приносит приборы (скоро появится ответ сервера);
— Всё, что видит пользователь в интерфейсе, — либо хардкод (неизменное содержимое вроде скатерти, солонки с перечницей и салфетницы), либо поступает с сервера (значит, потребуются дополнительные состояния);
— Чтобы понять, какие нужны состояния, спросите аналитика, какие отправляются запросы;
— Последовательные — данные загружаются один за другим, и состояние следующего блока данных зависит от предыдущего. Чаще всего они отправляются при инициализации экрана;
— Покажите, что данные загружаются. Если запрос упадёт, нужна полноэкранная ошибка;
— Параллельные запросы отправляются одновременно и не ждут друг друга. Каждому блоку данных нужен лоадер (спиннер или скелетон-шиммер) и состояние ошибки;
— Синхронный запрос в отличие от асинхронного блокирует интерфейс. После его отправки часто показывают блокирующий лоадер поверх затемнённого интерфейса;
— Обязательные запросы отвечают за ключевое действие на экране. Если они падают, пользователь видит полноэкранную ошибку с кнопкой повторной отправки;
— Необязательные загружают второстепенные данные. Например, похожие видео на Ютубе. Не страшно, если не загрузятся. Проблемные блоки иногда просто скрывают;
— Фоновые запросы происходят за кулисами. В случае ошибки пользователю часто ничего не показывают или отображают снек;
— Почти все коллекции контента подгружаются порциями по триггеру. Нужно состояние загрузки в том месте, где пользователь ожидает увидеть очередную порцию;
— Типовые ошибки: нет интернета, проблемы на сервере, тайм-аут, валидация;
— Важно понять, на клиенте или сервере происходит удаление, добавление и изменение порядка элементов, чтобы понять, когда показывать загрузку и ошибки;
— Спросите у аналитика, кешируются ли данные. Если да, то когда актуализируются. Возможно, потребуется определить, сколько единиц контента хранить в кеше, что если пользователь долистал их до конца, как отобразятся обновлённые данные.

#loader #error

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

— Во время загрузки даже незамысловатый контент повышает время, которое пользователь готов ждать. Загрузки экрана с логотипом ждали на 1 секунду дольше, чем пустого экрана;
— При 10-секундном ожидании анимированный персонаж вместо прогресс-бара уменьшает воспринимаемое время ожидания на 1 секунду, а люди оценивают опыт на 1 балл выше. Но для 5- и 2-секундного ожидания прогресс-бар лучше;
— В развлекательных приложениях лучше работает энергичная анимация (например, персонаж куда-то летит). В полезных — медленная (персонаж расслабленно крутит обруч);
— В цифровой среде ожидание обычно меньше минуты. Лишняя информация о процессе ожидания привлекает к нему ненужное внимание. Поэтому пустой экран может быть лучше лоадера: в тесте из первого абзаца загрузки пустого экрана ждали на 1,5 секунды дольше, чем экрана со спинером;
— Прогресс-бар, быстро заполняющийся до 70% и затем замедляющийся, уменьшает воспринимаемое время ожидания лучше тех, которые заполняются равномерно или ускоряются в конце;
— Attentional Gate Model: счётчик ожидания запускается тогда, когда мы обращаем на него внимание. Чем больше мы уделяем ему внимания, тем дольше кажется событие. Поэтому лучше отвлекать человека от идеи ожидания и не показывать связанные с ней прогресс-бары (если это не длительное ождание).

#loader

Антон из X5 Tech написал о скелетонах.

— Это такая загрузка экрана, когда сначала отображаются серые прямоугольники, а потом вместо них появляется контент;
— Их важно анимировать, чтобы всё это не было похоже на баг;
— Прижилась пульсация (мерцание) и волна (единое для всех блоков смещение градиента, background: fixed);
— Плюс скелетона в предварительном представлении структуры экрана и возможности отображать контент по мере его загрузки;
— Каждый прямоугольник скелетона — обёртка для контента и заглушка на время загрузки;
— Но что должно быть внутри обёртки: атом, молекула или организм в терминах атомарного дизайна?
— Отдельными блоками скелетона может быть то, что запрашивается с сервера отдельными запросами;
— Скелетировать можно всю страницу (высоконагруженные проекты, у значимой доли пользователей плохой интернет), её части (тяжёлые блоки с таблицами, статистикой) или отдельные элементы (результат множества запросов, сложного вычисления и так далее);
— Будьте последовательны. Если где-то есть скелетоны, спиннеры в раскрывающихся списках смотрятся странно;
— Заглушки должны соответствовать размеру контента (в первую очередь высоте), чтобы при загрузке ничего не скакало, а также его внешнему виду, чтобы не сильно контрастировать с контентом;
— Если в карточках может быть разный состав контента, ради простоты можно сделать для всех карточек одну усреднённую заглушку;
— Высокая детализация требует затрат, которые не всегда оправданы. Например, вкладки могут быть одним прямоугольником. Обычно это один компонент на странице, его заглушка воспринимается как заголовок, да и показывать заглушки отдельных табов непросто;
— Но иногда повышение детализации имеет смысл и помогает сразу привлечь внимание к определённой части страницы;
— Повторяющиеся элементы вроде ячеек с текстом в таблице можно скелетировать красиво, сделав заглушки разной ширины (90, 75, 85, 80, 65% от ширины ячейки) и сохранив выравнивание.

#loader