UI-стек: пять слоев дизайна интерфейса

Случалось ли вам сталкиваться с пользовательским интерфейсом, который казался безжизненным? Или создавать UI, в котором как будто чего-то не хватало?

Если да, то вы знаете, как выглядит неловкий UI.

Неловкий UI — это отсутствующий индикатор загрузки; это ситуация, в которой вы забываете сказать пользователю, что что-то пошло не так, или делаете это при помощи сообщения об ошибке; это странно выглядящие графики всего с несколькими точками; это сбой системы при вводе новых данных. Если вы еще не поняли, что такое неловкий UI, вот вам простой пример из реальной жизни. Я смотрю Apple TV. Очень часто. (Честно сказать, я это делаю и сейчас, когда пишу эти строки.) Каждый раз, когда я открываю папку с купленными фильмами, я вижу картину, которая представлена на рисунке 6.3.

Рис. 6.3. У Apple TV отсутствует индикатор загрузки для вызова списка приобретенных фильмов. И меня это пугает. Каждый раз

Каждый раз я на секунду пугаюсь. А я ведь открываю эту папку очень часто. Я знаю, чего ожидать.

Но что меня пугает? Из-за чего мой мозг считает, что я вижу именно то, что Apple TV хочет мне показать?

На этом экране отсутствует индикатор загрузки, равно как и любые другие следы деятельности. Так что через мгновение в моей голове появляются жуткие вопросы: где мои фильмы? Я их потерял? Удалил? Их кто-то украл?

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

Как же это бесит!

Сравните эту процедуру с воспроизведением фильма. Нажав кнопку Play на пульте, я вижу индикатор, что «Назад в будущее» готовится к запуску (рис. 6.4).

Рис. 6.4. Успокаивающий индикатор воспроизведения

Видите разницу в ощущениях?

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

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

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

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

Что это за правила?

Правила UI-стека. Давайте-ка поговорим о нем.

ЧТО ТАКОЕ UI-СТЕК?

Каждый экран, с которым вы имеете дело при работе с цифровым продуктом, состоит из нескольких слоев — точнее, из пяти (рис. 6.5).

Рис. 6.5. UI-стек состоит из пяти слоев, присутствующих в каждом экране пользовательского интерфейса, а также из логики перемещения пользователя между ними

В зависимости от контекста клиент видит отображение одного из этих слоев. На языке дизайнеров они еще называются состояниями[117], именно их необходимо учитывать для каждого создаваемого вами экрана.

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

Будьте честны сами с собой. Когда вы в последний раз создавали экран, состоящий только из одного слоя? Даже если вы разрабатываете приложения для прогноза погоды (здесь должна быть шутка про Dribbble), одного слоя вам не хватит.

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

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

Вот почему каждый экран, который вы создаете, может иметь до пяти состояний:

• Идеальное состояние

• Пустое состояние, включая состояние при первом использовании

• Состояние ошибки

• Промежуточное состояние

• Состояние загрузки

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

Но для начала давайте совершим краткий экскурс в историю интернета. В 2004 году компания Basecamp (ранее известная как 37signals) выпустила книгу, которая, как мне кажется, перевернула разработку цифровых продуктов с ног на голову. Эта книга называлась The Three State Solution («Решение с тремя состояниями»)[118], и в ней говорилось, что каждый экран должен рассматриваться в трех возможных состояниях — «обычном, пустом и ошибочном». Это открытие изменило мое сознание и заставило иначе взглянуть на дизайн сетевых продуктов.

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

Изменились и требования, и ожидания от UI. UI-стек — это моя адаптация идеи, которую Basecamp создал более десяти лет назад.

А теперь давайте поговорим об идеальном состоянии.

ИДЕАЛЬНОЕ СОСТОЯНИЕ

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

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

И все эти изменения имеют огромное значение для остальных слоев.

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

Если вы еще не до конца понимаете, что я имею в виду под идеальным состоянием, давайте рассмотрим несколько примеров (см. рис. 6.6–6.8).

Рис. 6.6. Живописный вид идеального состояния приложения Qik — видеоклиента Skype. Мы видим несколько групп, из которых можно выбирать, и активных пользователей, готовых получить ваше видеосообщение

Рис. 6.7. Tinder — это лучшее приложение для знакомства с новыми людьми. Здесь мы видим его в идеальном состоянии: человек, с которым вы не были знакомы до этого, и множество других опций, от которых вас отделяет лишь одно движение пальцем

Рис. 6.8. Идеальное состояние приложения Starbucks, в котором отображаются различные карты пользователя и остатки на них. Единственное, что меня печалит на этой картинке, — это суммы, которые мне приходится тратить каждую неделю, чтобы поддерживать баланс всех этих карт. Что ж, бывают и более дорогостоящие хобби

ПУСТОЕ СОСТОЯНИЕ

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

Существуют три варианта пустого состояния. Первый — что клиент видит, когда впервые открывает ваш продукт. Второй — что появляется, когда пользователь добровольно удаляет с экрана все данные, например при выборе опции Inbox Zero. А третий — что возникает, когда вам нечего показать клиенту, к примеру, если его поиск не дает результатов.

Главная проблема с пустыми слоями в том, что их часто оставляют на потом. В итоге получается либо полная мешанина (рис. 6.9), либо холодный и безликий интерфейс.

Рис. 6.9. О боже! Мне нравится приложение для записи музыки Figure от Propellerhead, но эти подсказки подавляют и отвлекают внимание. С чего вообще начать? И как все это запомнить?

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

Давайте поговорим о состоянии первого использования более подробно.

ПЕРВОЕ ИСПОЛЬЗОВАНИЕ / ЗНАКОМСТВО

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

Это состояние кажется мне похожим на то, что в литературе и кино называют «путешествием героя» (рис. 6.10). Это понятие, введенное Джозефом Кэмпбеллом, лежит в основе мифологических сюжетов всего мира, от «Одиссеи» до «Звездных войн». Краткое описание того, что оно в себя включает, выглядит так.

Рис. 6.10. Путешествие героя

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

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

Но как это сделать? Вот вам несколько идей.

• Напишите воодушевляющие и мотивирующие тексты, чтобы честно рассказать о том, что вы делаете. Слова вроде «здесь нет ничего интересного» не говорят вашему клиенту, чего ему следует ожидать, и вряд ли кому-то хочется увидеть их, начиная работу с новым продуктом. Вместо этого попробуйте рассказать клиенту, какую кнопку ему нужно нажать и зачем.

• Используйте контент своего продукта, чтобы объяснить клиенту, что ему следует делать. Например, если вы создаете продукт для обмена сообщениями, то можете начать с отправки сообщения клиенту. Попробуйте сделать заголовком такого сообщения фразу вроде «нажмите, чтобы открыть», а в тексте объяснить, как можно управлять сообщениями и отвечать на них.

• Покажите, как должен выглядеть экран вашего продукта в идеальном состоянии. Так ваш клиент почувствует, что он может достичь чего-то похожего. К тому же вы продемонстрируете, насколько полезным может быть ваш продукт.

• Отслеживайте прогресс клиента и реагируйте соответствующим образом. Если он слишком долго задерживается на каком-то экране, напишите ему в чат и спросите, не нуждается ли он в помощи.

На рисунках с 6.11 по 6.14 изображены примеры экрана для первого использования, которые я считаю удачными.

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

Рис. 6.12. Facebook Paper постепенно рассказывает вам о своей функциональности и обучает основным действиям. Этот процесс красиво выглядит, но, к сожалению, активируется практически сразу же после входа в систему, не давая мне возможности рассмотреть продукт как следует. Кроме того, некоторым может не понравиться, что для выхода из обучающего режима нужно нажать Х

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

Рис. 6.14. После первого входа в вишлист Airbnb вы видите стильный пустой слой. Мне нравится, что в этом дизайне не чувствуется навязчивость (что вообще характерно для дизайнерского языка Airbnb), но при этом он вполне четко призывает вас начать сбор данных

Тема экранов для регистрации и первого использования настолько широка, что ей можно было бы посвятить отдельную книгу. И, оказывается, такая книга существует. Если вы хотите заняться этим вопросом более подробно, рекомендую великолепную работу Сэмюэля Хьюлика The Elements of User Onboarding («Элементы адаптации новых пользователей»)[119].

ДАННЫЕ, УДАЛЕННЫЕ ПОЛЬЗОВАТЕЛЕМ

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

Этот слой дает возможность вознаградить клиента или мотивировать его на дальнейшие действия (рис. 6.15). В вашем почтовом ящике больше нет писем? Отлично! Получайте за это красивое фото. Вы загрузили всю музыку? Здорово, теперь прослушайте ее. У вас больше не осталось уведомлений? Вот еще парочка, которые могут вас заинтересовать.

Рис. 6.15. Да, это винтажный скриншот из iOS 6, но он позволяет вспомнить тот небольшой прилив дофамина, который ощущали многие из нас, полностью очистив почтовый ящик. Моя награда — выбранная специально для меня фотография из чьего-то Instagram-аккаунта (сцена в кафе или красивый закат). Кроме того, я могу поделиться ею с друзьями, чтобы рассказать им, что у меня в почте больше нет писем, и заодно прорекламировать Mailbox. Тройная польза!

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

ОТСУТСТВИЕ РЕЗУЛЬТАТОВ

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

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

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

В случае с Pinterest (рис. 6.17) результаты не совсем такие же, как в Amazon, но, в конце концов, это Pinterest. Учитывая, как их поисковая система обрабатывает запрос, клиент легко может скорректировать его, чтобы получить желаемое.

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

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

СОСТОЯНИЕ ОШИБКИ

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

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

В данном случае можно перефразировать Джефа Раскина, создателя первого компьютера Macintosh и автора книги «Интерфейс: новые направления в проектировании компьютерных систем»[120]. Он пишет:

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

На этот совет следует обратить внимание злостным нарушителям правила Раскина — сайтам авиакомпаний. Стоит пользователю забыть заполнить крошечное поле, например с кодом кредитной карты, и страница перезагружается, стирая все тщательно введенные данные, а незаполненное поле еще и подсвечивается раздражающим красным цветом (рис. 6.18).

Рис. 6.18. American Airlines уже выучили урок, и, я уверен, Wordpress последовал их примеру. Но зачем злить людей, показывая им бессмысленные сообщения об ошибках? Зачем уничтожать все результаты их труда? Это неприемлемо

НЕТ! ДА! МОЖЕТ БЫТЬ?

Наконец, вот пример контекстного сообщения об ошибке, которое легко понять. Юмор делает его более человечным (рис. 6.19).

Рис. 6.19. Прекрасное, очень человечное и полностью понятное сообщение об ошибке, возникшей при регистрации аккаунта в Basecamp

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

Кроме того, состояния ошибки не должны выглядеть слишком драматично или непонятно. Помните «синий экран смерти»? Или «панику ядра» на старых iMac? Или, если вы совсем уж ветеран, команды Abort, Retry, Fail? Каждое из этих состояний указывало на существенную системную ошибку, требовавшую перезагрузки или повтора операции. Мы не забыли их до сегодняшнего дня из-за того шока, ужаса и непонимания, которое они вызывали.

«Синий экран смерти» Microsoft (рис. 6.20) получил печальную известность именно потому, что ужасно раздражал людей. Он появлялся внезапно, вне контекста, и был нашпигован специальными терминами, которые казались пугающими даже тогда, когда действительно были полезны для решения проблемы.

Рис. 6.20. Легендарный «синий экран смерти» Microsoft Windows

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

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

Итак, хорошее сообщение об ошибке должно быть:

• Написанным для аудитории

• Конструктивным, четким и эффективным

• Позитивным, то есть не пугающим и не слишком драматичным

• Содержащим информацию об основной проблеме и, если это возможно, о ее решении

• Четко показывающим, где именно возникла проблема

• Своевременным

• Написанным грамматически и тематически верным языком без специальных терминов и избытка сокращений

• Предлагающим четкие способы или варианты решения проблемы и не выдвигающим избыточных требований (особенно в том случае, если речь идет о безопасности, обеспечиваемой паролем)

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

ПРОМЕЖУТОЧНОЕ СОСТОЯНИЕ

Разница между идеальным состоянием и состоянием ошибки очевидна. Но как выглядит экран, если на нем присутствует всего одна строка данных? А если несколько фотографий? Или наполовину заполненный профиль?

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

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

В данном случае можно использовать некоторые принципы разработки игр. Я не говорю о том, что ваш пользователь должен собирать кристаллы, как в Clash of Clans (рис. 6.21), речь идет об «ускорении», которое можно задействовать на этом этапе.

Рис. 6.21. Огромная стрелка показывает, что я могу построить пушку, потратив при этом кристаллы, чтобы потом купить еще больше кристаллов. Да, так это и работает[121]

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

Игрок, вступающий в фазу ускорения, не думает о скучных повторениях, которые ему придется совершить, чтобы попасть на следующий уровень. Он просто делает это и наслаждается увеличивающимся результатом… Такие игроки мыслями уже находятся в будущем, где их герои наделены могуществом, недоступным на текущем этапе. Говоря более техническим языком, они видят перед собой экспоненциально увеличивающуюся силу, которая исчезает за горизонтом предвидения их героев. Это не самый традиционный подход, но субъективно игроки получают от него точно такое же удовольствие[122].

На рисунках 6.22–6.24 представлены прекрасные примеры промежуточного состояния.

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

Рис. 6.23. Dropbox показывает, насколько вы близки к увеличению объема памяти — основной цели для большинства его пользователей. Dropbox не просто демонстрирует, сколько шагов осталось выполнить, но и образовывает и мотивирует своих пользователей

Рис. 6.24. Приложение «Активность» на Apple Watch ставит задачу «заполнить» все круги

СОСТОЯНИЕ ЗАГРУЗКИ

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

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

Об этом пишет Люк Вроблевски, эксперт в области продуктового дизайна, руководивший дизайнерскими отделами в eBay, Yahoo и Google (где он работает и по сей день после продажи своего стартапа Polar, занимавшегося созданием мобильного приложения для проведения соцопросов).

Вроблевски и его команда заметили, что после того, как они добавили к каждому опросу круговые прогресс-бары, пользователи Polar начали жаловаться, что приложение работает медленнее, чем обычно: «Приходится долго ждать обновления и загрузки страниц. Предыдущая версия была быстрее».

Вроблевски пишет о своем осознании:

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

КАРКАСНЫЕ ЭКРАНЫ

Благодаря этому пониманию родилось то, что Вроблевски называет «каркасными экранами» (рис. 6.25). Эта технология, в частности, используется в десктопных и мобильных версиях Pinterest и Facebook.

Рис. 6.25. Приложение Люка Вроблевски Polar и его каркасные экраны в действии[124]

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

Pinterest не только применяет концепцию каркасных экранов, но и обогащает ее некоторыми уникальными чертами. Например, определяет «средний цвет» изображения и заполняет им фон до тех пор, пока само изображение не будет загружено. Таким образом, вы получаете примерное представление о картинке еще до того, как ее видите. Сегодня та же технология применяется и в поиске Google Images.

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

Рис. 6.26. Facebook изобрел собственную технологию загрузки экрана, аналогичную каркасным экранам Вроблевски. Методика Вроблевски комбинируется с так называемым эффектом мерцания, благодаря которому формы пульсируют, указывая на загрузку контента

ОПТИМИСТИЧНЫЕ ДЕЙСТВИЯ КАК ПОКАЗАТЕЛЬ ВЕРЫ В УСПЕХ

«Никому не нравится ждать, даже пока он ждет», — сказал основатель Instagram Майк Кригер в 2011 году, описывая инженерные решения, формирующие впечатление высокой скорости работы его приложения (рис. 6.27)[125].

Рис. 6.27. «Оптимизм» в ранней версии Instagram

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

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

Оптимистичные действия позволяют уменьшить воспринимаемое время загрузки. Instagram начинает загружать фото сразу после того, как вы выбрали для него фильтр, а не когда вы нажали «Готово». Это не оптимальное инженерное решение (ведь если пользователь передумает, загруженные данные могут оказаться ненужными), но зато с пользовательской точки зрения загрузка происходит очень быстро. Правило «Перемещайте биты, пока никто не видит» позволяет сделать скорость работы продукта одним из его преимуществ.

ГИПОТЕТИЧЕСКИЙ ПРИМЕР

Мы рассмотрели несколько примеров UI-стека и его пяти слоев по отдельности (рис. 6.28). Но как они взаимодействуют друг с другом? Как пользовательский интерфейс обеспечивает переход из одного состояния в другое?

Рис. 6.28. Напомню, так выглядят UI-стек и его элементы

Сила UI-стека в том, что слои не существуют сами по себе. Они расположены вдоль вертикальной оси, которую в любое время может вызвать продукт. Ваша задача не только создать каждый из этих слоев, но и обеспечить переход экрана между ними.

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

Почему именно сообщения? Потому что в подобном приложении все пять состояний проявляются не самым очевидным образом. Мне кажется, это прекрасный пример того, как даже временные UI вроде интерфейсов для передачи сообщений следуют правилам стека. Кроме того, он показывает, какую огромную ответственность разработчики несут за обеспечение плавного перехода экрана из одного состояния в другое.

Итак, с чем нам предстоит иметь дело в нашем приложении?

Сначала у нас вообще не будет сообщений. Это наш пустой слой.

Промежуточный слой — когда лишь один участник диалога отправил сообщение.

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

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

Можно забыть о механизме устранения ошибки и попытаться отправить сообщение еще раз. Это будет еще одна версия слоя загрузки.

Наконец, мы достигнем идеального состояния — когда одно сообщение превратится в беседу.

ГИПОТЕТИЧЕСКИЙ МЕССЕНДЖЕР

Предположим, Марти и Док Браун из фильма «Назад в будущее» обменялись контактами, и Марти хочет рассказать Доку о том, что он видел в магазине Twin Pines Mall.

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

Рис. 6.29. Переход из пустого состояния в промежуточное

Но что происходит с этим состоянием, когда кто-то отправляет сообщение? Нам нужно аккуратно перейти с пустого слоя в промежуточный. В данном случае промежуточное состояние наступает, когда Марти отправляет Доку первое сообщение.

Давайте перейдем к моменту, когда Док ему отвечает (рис. 6.30). Он уже отправил одно сообщение, но разговор еще не закончен! Поэтому появляется индикатор набора текста, еще одна форма состояния загрузки.

Рис. 6.30. Состояние загрузки (в данном случае отображенное в виде индикатора набора текста) и переход к новому входящему сообщению

После того как один из собеседников отправляет сообщение, индикатор набора текста пропадает, а вместо него появляется новый текст, который подвигает старые вверх.

Но что будет, если Марти захочет ответить (рис. 6.31)? Для начала нам нужно показать готовность приложения к работе, когда текст будет введен в поле. Обратите внимание, что кнопка «Отправить» из серой (неактивное состояние) превратилась в синюю (активное состояние). Затем, после отправки сообщения, возникает еще одно состояние загрузки. В это время сообщение выглядит тусклым, потому что оно еще не доставлено. Наконец пометка «Доставлено» сообщает отправителю, что его действия увенчались успехом.

Рис. 6.31. При отправке сообщения меняется состояние кнопки «Отправить», затем происходит переход в состояние загрузки, а затем подтверждается доставка

Рис. 6.32. Повторная попытка отправить сообщение. Обратите особое внимание на выход из состояния ошибки

Что произойдет, если наше сообщение не будет доставлено (рис. 6.32)? Экран перейдет в состояние ошибки. Вместо индикатора загрузки появится красный маркер, и сообщение по-прежнему будет выглядеть тусклым.

Нажав (или, в данном случае, кликнув в Quartz Composer) на неотправленное сообщение, пользователь сможет повторить попытку.

На этот раз нам повезло. Агрессивный красный восклицательный знак пропадает, сообщение становится ярким, и мы видим индикатор доставки.

Вот так, друзья, работает UI-стек.

Я рассказал о пяти состояниях экрана и плавных переходах между ними. Без переходных элементов наш клиент может смутиться или растеряться, когда перед ним появится экран в новом состоянии. А доставлять дискомфорт, вроде бы, не входит в наши должностные обязанности.

Кстати, о комфорте. Давайте перейдем к вопросам эргономики, которые должен учитывать UI в современном мире тачскринов и мобильных устройств.