Лого vc.ru

Почему предпросмотр структуры страницы лучше индикатора загрузки

Почему предпросмотр структуры страницы лучше индикатора загрузки

Front-end разработчик Коллум Харт в своем блоге рассказал о том, почему при загрузке страницы необходимо отображать её структуру, а не показывать индикатор загрузки.

В рубрике «Интерфейсы» — адаптированный перевод заметки. 

Что это такое

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

Харт считает, что одним из решений может стать предпросмотр интерфейса во время его загрузки. Превью макета и структуры страницы должно отображаться мгновенно, в то время как информация загружается с некоторой задержкой. Разработчик ссылается на ленту Facebook, которая использует превью для загрузки:

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

Почему это хорошо

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

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

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

Степени использования

По мнению Харта, пользователи должны видеть превью интерфейса в течение доли секунд. В идеальном случае, информационное наполнение страницы должно загружаться мгновенно. Метод предпросмотра интерфейса можно разделить на три уровня по степени его использования, считает автор: bare bones, aspiring и perfectionist.

Bare bones

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

Aspiring

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

Perfectionist

При использовании такого метода все детали выглядят достаточно конкретно и различаются на отдельных страницах ресурса.

Однако текст, который никак не связан с сервером, не несет в себе никакой информации до тех пор, пока информация не загрузится. Поэтому пользователь не сможет произвести какие-либо действия до полной загрузки данных:

Реализация

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

Помимо архитектуры и инструментов для реализации предпросмотра интерфейса можно использовать еще несколько методов. 

Во-первых, структуру страницы следует отделить от того, что в неё загрузится. Для этого можно использовать два шаблона: первый — для структуры и второй — для контента (появляется при полной загрузке данных).

Автор считает, что несмотря на все преимущества метода, у него есть и существенные недостатки.

  • Как правило, в зависимости от состояния элемента его структура различается. Поэтому эффективней иметь один шаблон, включающий в себя два комплекта разметки, которые соответствуют каждому состоянию объекта (показан или скрыт).
  • Сложная логика.
  • Пользователь не должен взаимодействовать со структурой. Наполнение «каркаса» (кнопки, поля ввода и так далее), должны быть удалены, потому что это вводит посетителя в заблуждение.

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

Харт рекомендует использовать при разработке эмулятор Network Link Conditioner. С его помощью можно тестировать загрузку интерфейса на разных скоростях интернет-соединения.

Хорошим помощником для Network Link Conditioner являются критерии эффективности от Якоба Нильсона. В книге Usability Engineering определены три временных предела, которые показывают насколько важна скорость отклика интерфейса:

0,1 секунды

Операции на странице, которые выполняются за 100 миллисекунд практически незаметны пользователям. Такое время является золотым стандартом, к которому должны стремиться все разработчики.

Одна секунда

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

10 секунд

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


Присылайте свои интерфейсные кейсы на interface@siliconrus.com
Теги
Статьи по теме
Почему при проектировании интерфейсов нужно забыть о визуальном оформлении
Почему уникальные интерфейсы мешают пользователям

Сразу Lenta.ru вспоминается, где шрифт загружается по 10 секунд.

Лучше подождать, когда всё загрузится и уже потом смотреть страницу, а иначе всё кусками будет грузиться.

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

Год назад я написал статью «Три правила проектирования интерфейсов с высокоскоростным пользовательским взаимодействием»
habrahabr.ru/post/211659/ (правила, которыми я руководствуюсь при разработке своего приложения для поиска и прослушивания музыки seesu.me/o ). В статье как раз об этом, и не только.

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

0

Читал вашу статью, хорошая работа.

У меня сайт полминуты грузится и ничего.

0

Пол минуты слишком долго для "ничего". Добавьте хотя бы картинок фоном.

Странно такое слышать от front-end-а.

Во-первых, все современные браузеры начинают рендер страницы сразу же по ходу парсинга её тела.

Во-вторых, в том примере с картинкой, что ему нравится - у блоков жёстко заданы размеры, поэтому их легко отрендерить до получения контента. Это сработает для приложений, но для обычных сайтов такое невозможно - нельзя нарисовать блок, не зная какие размеры у его контента.

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

Прямой эфир
Узнавайте первым важные новости
Подписаться