Столкнулся с дизайн-системой, где у всех компонентов отрисованы состояния «скелет» — это типа как выглядит элемент, пока он не загрузился. Дизайнеры вообще говорили «скелетон», но скелетон — это такой бобслей для одиночек, а skeleton — это скелет. С этим состоянием есть проблема, сейчас объясню.
Пока экран приложения загружается, вместо индикаторов загрузки хорошо показывать скелет экрана. Тогда вместо того, чтобы привлекать внимание к тормозам, мы создаём у пользователя впечатление, что экран почти загрузился. Секундные задержки перестают ощущаться, человек успевает сориентироваться на экране.
Так что же не так с состоянием компонента «скелет»? То, что скелет — это состояние экрана целиком, а не отдельного компонента. (Если уж на то пошло, у компонента может быть состояние «кость», а не «скелет».)
В-первых, рисование отдельных скелетных состояний компонентов провоцирует дизайнеров на рисование излишне детализированных скелетов экранов. Вот Вконтакте например:
Зачем столько мусора? Чтобы показать, что экран ещё грузится, достаточно такого:
Да и ещё спокойнее можно.
Во-вторых, во время загрузки экрана он обычно не знает, какие именно компоненты на нём будут, чем они будут наполнены, какого они будут размера. То есть даже непонятно, какие именно компоненты в этом состоянии «скелет» туда ставить, приходится выдумывать. В то же время, если какие-то элементы на экране нужны независимо от подгружаемых данных, скажем, кнопки навигации, то их стоит сразу показывать в нормальном виде, безо всяких скелетов.
Во-третьих, даже если представить, что сам набор элементов известен сразу, а подгружается только их наполнение, то получается довольно неприятный эффект, когда во время загрузки на экране в случайные моменты появляются разные блоки, постоянно что-то прыгает, отталкивает то, что ниже. То есть даже в этом случае лучше нарисовать весь экран в скелетном состоянии, а когда загрузилось достаточно данных для его стабильного построения — тогда показать всё на своих местах.
Я работал в разных компаниях над супернагруженными приложениями с огромным набором данных и с маленькими приложениями с небольшим набором данных. И почти в каждом проекте наступал момент, когда дизайнер приходил ко мне, или к начальнику выше с предложением сделать «скелетон» у какого-то блока, а ещё лучше у всех блоков на всех страницах потому, что что-то стало медленно загружаться. Главный бекэндер понимающе кивал. Это происходило независимо от размеров проекта, данных, числа пользователей.
Я говорил, что в этом нет никакой необходимости, и нам нужно думать и прилагать усилия к тому, как поставлять данные и страницы быстро, а не как пытаться замаскировать эту проблему. Дизайнер, бекэндер и девопс были против и говорили, что это, если не невозможно, то точно сложно и займёт много времени. Я приводил примеры, как можно настроить кэш веб-сервера, и его инвалидировать, как предугадывать, какие данные потребуются в первую очередь, или даже хранить все данные в оперативной памяти в тех проектах, где данных мало. Ещё можно страницы на сервере предформировать. Ну ещё можно сервера поближе переместить к пользователям. Бекэндер был против, но технический директор был за потому, что это увеличивало возможную выдерживаемую нагрузку.
И каждый раз оказывалось, что за месяц или меньше и вправду мы настраивали всё так, что страницы загружались молниеносно и «скелетоны» оказывались ненужными. Однажды в одном большом проекте контрагент решил в понедельник с утра залить к нам невероятный объём своих данных. Клиенты почувствовали это и некоторые даже пожаловались. Страницы в это утро загружались не молниеносно, а за полсекунды. Жалко, но «скелетоны» всё ещё были не нужны с такой скоростью загрузки.