Правдива брехня оптимістичних інтерфейсів

Нещодавно опублікована у Smashing Magazine стаття Дениса Мишунова здалася нам дуже цікавою: вона присвячена підходу, про який багато хто до цих пір не замислюються, хоча він вже оточує нас в популярних сервісах. З дозволу автора і першоджерела ми вирішили перевести цей матеріал для хабрасообщества.

Три користувача інтерфейсу заходять в паб. Перший замовляє напій, потім ще кілька. Парою годин пізніше він просить рахунок і залишає паб п'яним. Другий замовляє напій, платить за нього відразу ж, замовляє ще один, сплачує за нього, продовжує в тому ж дусі, і через пару годин покидає паб п'яним. А третій заходить в паб вже п'яним, він знає, як працюють паби, і досить ефективний, щоб не втрачати час. Чули про це третьому? Його називають оптимістичним UI».



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

Останнім часом, обговорюючи психологічну оптимізацію продуктивності на цілому ряді конференцій, присвячених як фронтенду, так і UX, я помітив, як мало уваги в співтоваристві приділено темі оптимістичних інтерфейсів. Навіть сам термін «оптимістичний UI» не дуже добре визначений. У цій статті ми розберемося, на яких концепціях він заснований, і подивимося на приклади, а також розберемося з його психологічним обґрунтуванням.

Але перш ніж ми почнемо, треба визнати: «оптимістичним UI» не можна назвати щось конкретне. Швидше, це ментальна модель, яка стоїть за впровадженням інтерфейсу. У оптимістичного UI є своя історія і своє логічне обґрунтування.

Одного разу давним-давно
Колись давно- коли слово «tweet» застосовували в основному до птахів, Apple була на межі банкрутства, а люди поміщали на свої візитки номери факсів — веб-інтерфейси були досить аскетичними. І переважна більшість з них була позбавлена навіть натяку на оптимізм. Взаємодія з кнопкою, наприклад, могло слідувати за таким сценарієм:

  1. Користувач натискає на кнопку.
  2. Кнопка змінює стан на деактивированное.
  3. Запит відправляється на сервер.
  4. Відповідь від сервера прямує назад на сторінку.
  5. Сторінка перезавантажується для відображення результатів відповіді.




У 2016-му це може здатися дуже неефективним, але, як не дивно, той же сценарій, як і раніше використовується великою кількістю веб-сторінок і додатків, будучи невід'ємним елементом взаємодії для багатьох продуктів. Причина в тому, що цей тип взаємодії передбачуваний і більш-менш захищений від помилок: користувач знає, що дія була запрошена від сервера (деактивированное стан кнопки натякає на це), і коли сервер відповідає, оновлена сторінка явно свідчить про закінчення взаємодії «клієнт-сервер-клієнт». Проблеми з цим типом взаємодії досить очевидні:

  • Користувач повинен чекати. А ми вже знаємо, що навіть незначна затримка у часі відповіді негативно відбивається на сприйняття користувачем всього бренду, а не тільки конкретної сторінки.

  • Кожен раз, коли користувач отримує відповідь на свої дії, це відбувається досить деструктивно (завантажується нова сторінка замість оновлення вже існуючої), що змінює контекст користувача завдання і може збити з думки. Нехай мова в цьому випадку не обов'язково йде про багатозадачності, будь перемикання розумового контексту неприємно. Так що, якщо тільки сама дія не передбачає неминучу зміну контексту (онлайн-платежі — хороший приклад такої зміни), перемикання задасть негативний тон спілкування користувача з системою.
Не-такі-вже-старі добрі часи
Потім з'явився так званий Web 2.0, надавши нові способи взаємодії з веб-сторінками. Їх основою стали XMLHttpRequest і AJAX. Ці нові способи доповнилися «спиннерами»: найпростішою формою індикації прогресу, єдине завдання якої — донести до користувача, що система працює над якоюсь операцією. Тепер нам не треба було перезавантажувати сторінку після отримання відповіді від сервера, ми могли просто оновити частину вже отрендеренной сторінки. Завдяки цьому веб став динамічнішим, а користувальницьке взаємодія стало відбуватися більш гладко. Типове взаємодія з кнопкою тепер могло виглядати так:

  1. Користувач натискає на кнопку.
  2. Кнопка переходить у неактивний режим, і з'являється який-небудь спиннер, щоб показати, що система працює.
  3. Запит відправляється на сервер.
  4. Відповідь від сервера відправляється назад на сторінку.
  5. Візуальне стан кнопки і сторінки оновлюються у відповідності зі статусом відповіді.
Ця нова модель взаємодії справляється з однією із зазначених вище проблем попереднього методу: оновлення сторінки більше не супроводжується перемиканням з однієї дії на іншу, зберігаючи для користувача контекст і залучаючи його в процес набагато краще, ніж раніше.



Такий шаблон взаємодії поширений повсюдно. Однак, одна проблема залишається: користувачі як і раніше потрібно чекати відповіді від сервера. Так, ми можемо змушувати наші сервера працювати швидше, але як би ми не намагалися прискорити інфраструктуру, користувачам ще потрібно чекати. А вони цього, м'яко кажучи, не люблять. Наприклад, дослідження показує, що 78% споживачів відчувають негативні емоції з-за повільних або ненадійних сайтів. Більш того, згідно з опитуванням Harris Interactive для Tealeaf, 23% користувачів зізнаються, що проклинають свої мобільні пристрої, 11% кричать на них, а цілих 4% буквально кидають їх, зіткнувшись з проблемами при здійсненні онлайн-транзакцій. Тимчасові затримки входять до числа таких проблем.



Сьогодні, навіть коли під час очікування ви показуєте якийсь індикатор прогресу, якщо тільки ви не підійшли до його створення вкрай оригінально, цього може бути недостатньо просто. В цілому, люди звикли до того, що спінер свідчать про повільність системи. Вони стали асоціюватися з пасивним очікуванням, коли у користувача немає іншого вибору, крім як чекати відповіді сервера або повністю закрити вкладку/додаток. Так що давайте спробуємо ще поліпшити це взаємодія і подивимося на концепцію оптимістичного UI.

Оптимістичний UI
Як вже було сказано, оптимістичний UI — не більше ніж спосіб обробки взаємодії користувача з інтерфейсом. Щоб зрозуміти його головні ідеї, ми продовжимо говорити про сценарії «користувач натискає на кнопку. Але принцип залишиться тим же для практично будь-якої взаємодії, що ви захочете зробити «оптимістичним». Як повідомляє нам Oxford English Dictionary:

mn-ti-mis-tic, adj. hopeful confident and about the future.
оптимістичний — повний надій і впевнений у майбутньому
Давайте почнемо з частини про «впевненість у майбутньому».

Як ви думаєте, як часто ваш сервер видає помилку у відповідь на дію користувача? Наприклад, часто ваш API робить це при натисканні на кнопку? Або при кліку на посилання? Чесно кажучи, не думаю. Зрозуміло, це залежить від конкретного API, навантаження на сервер, рівня обробки помилок і інших факторів, які ви як фронтенд-розробник або UX-спеціаліст можете зовсім не хотіти вникати. Але поки API стабільний і передбачуваний, а фронтенд коректно передає можливі дії з інтерфейсом, кількість помилок у відповідь на дії користувача буде досить низьким. Я б навіть припустив, що воно не буде перевищувати 1-3%. Це означає, що у 97-99% випадків, коли користувач натискає кнопку на сайті, сервер відповість успішно і без помилки. Це варто проілюструвати:



Задумайтеся на мить: якщо ми на 97-99% впевнені в успіху певної відповіді, то ми можемо бути впевнені і в майбутньому — ну, принаймні, значно більшою мірою, ніж кіт Шредінгера був упевнений у своєму. Отже, ми можемо змінити весь сценарій взаємодії з кнопкою наступного:

  1. Користувач натискає на кнопку.
  2. Візуальне відображення кнопки негайно змінюється на «успішне».
І все! Принаймні, з точки зору користувача, більше тут нічого немає — ні очікування, ні необхідності спостерігати неактивну кнопку, ні ще одного дратівної спиннер. Взаємодія користувача з системою відбувається набагато більш гладко, без нагадування про себе.



З точки зору розробника, повний цикл виглядає наступним чином:

  1. Користувач натискає на кнопку.
  2. Візуальне стан кнопки негайно змінюється на успішне.
  3. Запит відправляється на сервер.
  4. Відповідь сервера відправляється назад на сторінку.
  5. 97-99% випадків ми вже знаємо, що він успішний, так що не потрібно відволікати користувача.
  6. Тільки у випадку помилки система дає про себе знати. Не хвилюйтеся про це зараз — до помилок ми ще дійдемо.
Давайте подивимося на приклади такого оптимістичного взаємодії. Вам, мабуть, знайомі кнопки «like» на зразок тих, що є в Facebook і Twitter.

Все починається, зрозуміло, з натискання на кнопку. Але зверніть увагу на її візуальне стан після цього. Воно моментально відображається як успішне!



Давайте подивимося, що в цей момент відбувається на вкладці «Network» у Developer Tools нашого браузера.



Вкладка показує, що запит до сервера було надіслано, але все ще знаходиться в процесі обробки. Лічильник «лайків» ще не було збільшено, а зміною кольору інтерфейс вже явно повідомляє користувачеві про успіх, ще до отримання відповіді від сервера.

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



Інший приклад оптимістичного взаємодії — Facebook з його кнопкою «like». Це досить схожий з попереднім сценарій, за винятком того, що Facebook оновлює лічильник одразу ж, разом зі зміною кольору кнопки, не чекаючи відповіді сервера.



Дещо тут слід зазначити. Якщо ми подивимося на час відповіді сервера, виявимо, що воно трохи більше 1 секунди. Це досить довго, враховуючи, що модель RAIL рекомендує 100 мілісекунд в якості оптимального часу відгуку на простий запит користувача. Проте в цьому випадку не відчуває ніякого часу очікування з-за оптимістичною природи взаємодії. Це ще один приклад психологической оптимізації продуктивності.

Але давайте визнаємо: як і раніше залишається ймовірність в 1-3%, що сервер видасть помилку. Або користувач просто в офлайні. Або, що ще ймовірніше, сервер видасть відповідь, який технічно є успішним, але містить інформацію, яку треба додатково обробити на клієнті. В результаті користувач не отримає індикації помилки, але ми не можемо вважати це успіхом. Щоб зрозуміти, що робити в таких випадках, нам насамперед потрібно розглянути, які психологічні принципи лежать в основі оптимістичних UI.

Психологія, що стоїть за оптимістичним UI
Я поки що жодного разу не чув, щоб хто-небудь скаржився на вищезазначені оптимістичні взаємодії в популярних соцмережах. Тому припустимо, що оптимістичні UI працюють. Але чому вони працюють з точки зору користувачів? Просто тому що люди ненавидять чекати. От і все! Можна переходити до наступної частини статті.

Але якщо ви все ще читаєте, ймовірно, ви хочете дізнатися, чому все-таки це так. Давайте розглянемо трохи глибше психологічне обґрунтування цього підходу.



Оптимістичний UI складається з двох базових компонентів, які заслуговують нашої уваги:

  • Швидкий відгук на дії користувача.
  • Обробка потенційних помилок сервера, мережі і так далі.

Швидкий відгук на дії користувача
Говорячи про оптимістичному підході до UI, ми маємо на увазі оптимальний час відгуку по взаємодії користувача з системою. І рекомендації для такої взаємодії існують ще з далекого 1968-го. Тоді Роберт Міллер опублікував свою фундаментальну роботу «Response Time in Man-Computer Conversational Transactions» (PDF), де виділив цілих 17 різних типів відгуку, які користувач може отримати від комп'ютера. Один з них Міллер назвав «відповіддю на активацію контролю» — затримку між натисканням клавіші та візуальним відгуком. Ще тоді, в 1968-му, воно не повинно було перевищувати 0.1-0.2 секунди. Так, модель RAIL не першою це запропонувала раді вже близько 50 років. Міллер зазначає, однак, що навіть ця невелика тимчасова затримка може бути занадто повільної для досвідчених користувачів. Це означає, що в ідеалі користувач повинен отримувати підтвердження своєї дії протягом 100 мілісекунд. Це близько до одного з найшвидших несвідомих дій, яке здатне зробити людське тіло: до морганию. З цієї причини 100-миллисекундный інтервал зазвичай сприймається як моментальний. «Більшість людей моргає близько 15 разів у хвилину, і кожне моргання триває в середньому 100-150 мілісекунд», каже Дейвина Брістоу з Інституту неврології в Університетському коледжі Лондона, додаючи, що це «означає, що в цілому ми витрачаємо не менше 9 днів у рік на моргання».

З-за моментального візуального відгуку (відбувається до того, як отримано відповідь), оптимістичний UI — один з прикладів технік раннього завершення, використовуваних у психологічної оптимізації продуктивності. Але той факт, що люди люблять інтерфейси, що відповідають в мить ока, не повинен здивувати більшість з нас. І його не так вже й важко досягти. Навіть раніше ми деактивували кнопки моментально після натискання на них, і цього було досить, щоб продемонструвати «система знає про дії користувача». Але неактивний елемент інтерфейсу означає пасивне очікування: користувач нічого не може з ним зробити і не контролює процес. А це дуже дратує користувача. Ось чому в оптимістичному UI ми пропускаємо всю «неактивну» стадію цілком — ми повідомляємо про позитивному результаті замість того, щоб змушувати користувача чекати.

Обробка потенційних помилок
Давайте перейдемо до другого цікавого психологічного аспекту оптимістичного UI — обробці потенційних помилок. Існує велика кількість інформації і статей про те, як краще всього обробляти помилки в інтерфейсах. І хоча пізніше в статті ми розглянемо і це, головне в оптимістичному UI — не те, як ми обробляємо помилки, а то, коли ми це робимо.

Справа в тому, що людям властиво розбивати свою діяльність на підзадачі, часто звані «train of thought», «flow of thought» (PDF) або просто «flow». Це стан «потоку» характеризується піком задоволення, енергетичного фокусу і максимальної концентрації. Користувач в «потоці» повністю занурений у свою діяльність. Твіт Теммі Евертс добре ілюструє це:



У мережі тривалість таких періодів активності зазвичай набагато коротше. Давайте повернемося до роботи Роберта Міллера. У типи відповідей, які він перераховує, є такі:

  • Відповідь списком інформації на простий запит
  • Відповідь в графічній формі на складний запит
  • " Відповідь на «Система, ти мене розумієш?»
Всі їх він пов'язує з одним і тим же 2-секундним інтервалом, протягом якого користувач повинен отримати відповідний тип відповіді. Не забираючись глибше, зазначимо, що цей інтервал також залежить від робочої пам'яті людини (проміжок часу, протягом якого людина може утримувати певну кількість інформації в голові і, що важливіше, проводити дії з цією інформацією). Для нас, розробників та UX-фахівців, це означає, що протягом 2 секунд після взаємодії з елементом інтерфейсу користувач буде в «потоці» і зосереджений на відповіді, якого чекає. Якщо сервер видає помилку протягом цього проміжку часу, користувач, можна сказати, все ще буде в «діалозі» з інтерфейсом. Це схоже на діалог між двома людьми, в якому ви говорите щось, а інша людина м'яко заперечує вам. Уявіть, якщо б співрозмовник довгий час кивав на знак згоди (еквівалент успішного відповіді UI), а потім у підсумку сказав «ні». Було б дивно, правда? Так що оптимістичний UI повинен повідомляти про помилку користувачу протягом 2 секунд «потоку».



Збройні психологічними знаннями про обробку помилок в оптимістичному UI, давайте нарешті доберемося до цих 1-3% відмов.

Песимістична сторона оптимістичного підходу до UI
Найпоширеніше заяву про оптимістичному UI, яке я чув, полягає в тому, що це антипаттерн — якщо завгодно, обман користувачів. Ймовірно, якщо підходити до питання суто формально, то так воно і є. Тим не менш, я вважаю це технікою передбачення або вираження надії. (Пам'ятаєте визначення слова «оптимістичний»? Ось ми і дісталися до «повний надій» в ньому.) Різниця між «обманом» і «виразом надії» в тому, як ви обходитеся з цими 1-3% відповідей з помилкою. Давайте подивимося на те, як оптимістична кнопка «like» у Twitter веде себе в офлайні.

Спочатку, згідно з оптимістичним UI-паттерном, кнопка переключається на стан успіху відразу після натискання — знову ж таки, без очікування, у точності як якщо б користувач знаходився в онлайні.



Але оскільки користувач в офлайні, запит завершується невдачею.



Тому інформація про помилку повинна бути донесена до користувача настільки швидко, наскільки можливо. Знову ж таки, зазвичай для цього у нас не більше 2 секунд, поки користувач знаходиться в «потоці». Twitter повідомляє про це самим ненав'язливим способом з можливих — просто повертаючи кнопку у первісний стан.



Свідомий тут читач може сказати, що при обробці помилок можна зайти далі, прямо повідомляючи користувача про те, що його запит не міг бути відправлений або сталася помилка. Це б зробило систему максимально прозорою. Але тут є підступ — або, скоріше, ряд складнощів:

  • Будь-яке повідомлення, несподівано показане на екрані, змінює контекст завдань користувача, змушуючи його аналізувати причину відмови, швидше за все представлену в повідомленні про помилку.
  • Як і будь-яке інше повідомлення про помилку або повідомлення, це повідомлення має направляти користувача в новому контексті, надаючи йому інформацію, на підставі якої можна здійснювати дії.
  • Така інформація, у свою чергу, ставить ще один контекст.

Тут ми вже можемо погодитися, що ситуація стає занадто складною. Незважаючи на те, що така обробка помилок була б доречною, наприклад, для великої форми на сайті, для такого простого дії, як натискання лайка, це занадто — як щодо необхідної технічної розробки, так і у відношенні робочої пам'яті користувачів.

Так що, так, в оптимістичному UI ми повинні бути «прозорими» щодо помилок і повинні повідомляти про них як можна швидше, щоб наш оптимізм не перетворювався в обман. Але наші дії в такому випадку повинні відповідати контексту. Для невдалого лайка простого повернення кнопки у вихідне стан, швидше за все, буде досить — ну, звичайно, крім випадку, коли ви лайкаете статус своєї другої половини, тоді системі краще б працювати завжди.

Екстремальний песимізм
Може виникнути таке питання: що відбудеться, якщо користувач закриє вкладку браузера вже після відображення успіху, але до того, як запит повернеться з сервера? Самим неприємним випадком було б, якби він закрив її навіть до того, як запит відправився на сервер. Але якщо користувач не надзвичайно спритний або володіє здатністю уповільнювати час, це навряд чи можливо.

Якщо оптимістичний UI використовується правильно, і цей тип взаємодії застосовується тільки до тих елементів, які ніколи не чекають відповіді сервера довше 2 секунд, тоді користувачу буде потрібно встигнути закрити вкладку протягом цих 2 секунд. Це не дуже складно зробити натисканням клавіш; однак, як ми знаємо, у 97-99% цих випадків запит був би успішним незалежно від того, чи відкрита вкладка (відповідь просто не було б повернуто клієнту).

Так що проблема може виникнути тільки для тих 1-3%, які отримали помилку сервера. Як багато людей поспішають закрити вкладку за 2 секунди? Якщо тільки вони не беруть участь у конкурсі щодо закривання вкладки на швидкість, навряд чи їх число буде значним. Але якщо ви вважаєте, що це у вашому конкретному випадку це може мати значення і призвести до негативних наслідків, тоді використовуйте інструменти для аналізу користувальницького поведінки; якщо ймовірність такого сценарію досить висока, то обмежте оптимістичне взаємодія виключно не-критичними елементами.

Я навмисно не став згадувати випадки, в яких відповідь сервера штучно затриманий — це зазвичай не входить в область інтересів оптимістичного UI. Тепер, коли ми витратили більш ніж достатньо часу на песимістичну сторону речей, давайте підведемо невеликий підсумок, що стосується правильного використання оптимістичного UI.

Практичні правила
Я щиро сподіваюся, що ця стаття допомогла вам зрозуміти деякі головні принципи, на яких ґрунтується оптимістичний підхід до UI. Можливо, вам захочеться спробувати його в своєму наступному проекті. В такому разі, ось деякі речі, на які варто звернути увагу перед початком:

  • Перш за все, переконайтеся, що ваш надійний API і повертає передбачувані результати. Це надзвичайно важливо.
  • Інтерфейс повинен знаходити потенційні помилки і проблеми до того, як запит відправиться на сервер. Ще краще — повністю позбавитися від чого-небудь, що може призвести до помилки з API. Золоте правило: чим простіше UI-елемент, тим простіше буде зробити його оптимістичним.
  • Застосовуйте оптимістичні патерни лише простим «бінарним» елементів, від яких не очікується нічого, крім відповіді про успіх чи невдачу. Скажімо, якщо кнопка передбачає варіанти відповіді сервера «так», «ні» і «може бути» (кожен з яких може означати успіх в деякій мірі), то таку кнопку краще залишити без оптимістичного патерну.
  • Знайте час відповіді свого API. Це критично. Якщо ви знаєте, що для якогось конкретного запиту час відповіді ніколи не виявляється нижче 2 секунд, то для початку займіться роботою над API. Як ми вже з'ясували, оптимістичний UI працює найкраще для часу відповіді менше 2 секунд. Вихід за ці межі може призвести до несподіваних результатів і великій кількості незадоволених користувачів. Я попередив.
  • Оптимістичний UI — це не тільки про натискання на кнопки. Цей підхід може бути застосований до різних подій у життєвому циклі сторінки, включаючи її завантаження. Наприклад,skeleton screens слідують тим же принципом: ви сподіваєтеся, що сервер відповість успішно, і заповнить плейсхолдеры, показуються користувачеві як можна раніше.


Як ми побачили, оптимістичний підхід до UI не є якимось нововведенням, ні сучасною технікою. Це просто ще один спосіб, який допомагає вам керувати сприйняттям продуктивності свого продукту. Базуючись на психологічних аспектах, оптимістичний UI, при правильному застосуванні, може допомогти у створенні позитивного і більш однорідного взаємодії користувача з вашою системою, вимагаючи від вас при цьому мінімальних ресурсів. Але щоб домогтися від цієї техніки максимальної ефективності і не обманювати користувачів, нам необхідно розуміти принципи її роботи.

Посилання





Автор цієї статті (і її ілюстрацій!) Денис Мишунов 11 грудня виступить в Москві на конференції HolyJS кейноутом про те, як запускати дебагер» для себе самого. Влітку на петербурзькій HolyJS він розповідав про психологічному сприйнятті продуктивності, і тоді його виступ потрапило в топ-3 найбільш сподобалися глядачам — так що і в цей раз варто очікувати, що буде цікаво.
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.