Realistic UI: реалістичний погляд на Optimistic UI

Logo
останнім часом набирає популярність концепція Optimistic UI. На мій погляд, її гідності сильно переоцінені, а недоліки замовчуються. У цій статті я хочу більш явно продемонструвати недоліки, а також запропонувати гідну альтернативу, яку назвав Realistic UI.

TL;DR
Демонстрація концепції Realistic UI — https://yury-dymov.github.io/realistic-ui-concept/
Репозиторій з вихідним кодом — https://github.com/yury-dymov/realistic-ui-concept
Історія питання
Крім Realistic UI я зміг згадати три інших способи взаємодії з бекендом в інтернеті і мобайле.
1. "Традиційний" UI
До поширення AJAX для виконання майже будь-якої дії потрібно перезавантажити сторінку, тому UI виглядав приблизно так:
Traditional UI
Такий підхід і зараз досить поширений, але очевидно, що сучасні технології дозволяють досягти значно більш приємного UX.
2. "Block-the-world" UI
Block-the-world
Після поширення AJAX розробники змогли зробити крок вперед і впровадити можливість виконання віддалених запитів без необхідності перезавантаження сторінки в браузері для окремих операцій, як це було в "Традиційному UI". Однак, такі веб-додатки все ще залишалися з точки зору архітектури "тонкими" клієнтами і не мали можливості керувати своїм станом. Таким чином, перехід на іншу сторінку міг перервати виконання віддаленої операції, та кращим рішенням цієї проблеми були блокування інтерфейсу і демонстрація індикатора завантаження на стороні клієнта.
3. Optimistic UI
Далі, з появою і поширенням концепції Single Page Application з'явилася можливість розробляти "товстий" клієнт і керувати станом додатки. Optimistic UI припускає, що ми, розробники, знаємо, що повинно статися в результаті виконання операції, і можемо відразу оновити інтерфейс так, як якщо б операція виконалася успішно, а в цей час у фоновому режимі виконати відповідний AJAX запит. У 1 – 3 % випадків операція закінчиться невдачею, і ми просто покажемо повідомлення про помилку. Optimistic UI активно просувається facebook'ом, і їх рішення начебто Relay використовують цей механізм за замовчуванням.
Критика Optimistic UI
Optimistic UI може здатися гарною і свіжою ідеєю, але при найближчому розгляді стає зрозуміло, що її застосування якщо і виправдано, то в дуже рідкісних випадках. Я можу назвати наступний проблеми:
1. Поділ операцій на "важливі" і "низькі"
Optimistic UI не підходить для "важливих" операцій, наприклад, якщо ви купуєте квитки в кіно, то вам необхідно знати на 100%, чи вийшло це зробити, або сталася помилка. Також Optimistic UI не підходить для тих операцій, для яких сервер формує частину даних, які ми не можемо передбачити на стороні клієнта, таких як унікальні номери транзакцій.
Це створює відразу кілька проблем. По-перше, сервіс майже завжди містить кілька "важливих" операцій, інакше не дуже зрозуміло, навіщо він в принципі існує. А це означає, що розробникам доведеться реалізовувати і підтримувати два різних способи взаємодії з бекендом: для "важливих" і "неважливих" операцій, що вимагатиме більше часу і зусиль. З іншого боку, користувачам теж треба звикнути, що частина операцій виконується одним чином, а частина — іншим. Це може стати джерелом непорозумінь і проблем, що у свою чергу може збільшити витрати на підтримку користувачів і привести до погіршення UX відповідно.
По-друге, має бути людина, яка вирішує, які операції "важливі", "низькі". Будь-яке рішення буде завжди суб'єктивним. Наприклад, "лайк" може здатися "неважливою" операцією, але насправді для окремих користувачів сервісу відсутність лайка може зіпсувати настрій, а комусь і хороший вечір. Сама необхідність приймати подібні рішення забирає час і сили, тому було б краще як для розробників, так і для користувачів, щоб мати універсальне рішення, яке можна використовувати для всіх типів операцій.
2. Проблеми синхронізації даних, транзакционности і вирішення конфліктів
Optimistic UI в теорії добре працює з offline режимом. На практиці ж існує багато проблем, добре знайомих мобільним розробникам.
По-перше, транзакционность.
Transactional
Так, для месенджера порядок виконання операцій не може мати вирішального значення, але для інших типів додатків часто це не так. А це означає, що необхідно як на стороні клієнта, так і на сервері придумувати механізми, які б забезпечували належний порядок виконання операцій, що потребує додаткових зусиль і часу.
По-друге, припустимо, клієнт виконав п'ять різних операцій в offline і тепер намагається їх синхронізувати з сервером. Перші дві виконано успішно, а третя завершилась помилкою. Що слід зробити в цій ситуації? Зупинити виконання? Відкотити перші дві успішно выполнившиеся операції? Постаратися виконати четверту і п'яту? А якщо вони залежать від виконання третьою? А як повідомити про проблему користувачеві?
unknown error
Як ми бачимо, з'являється безліч питань, кожен з яких вимагає роздумів і часто індивідуального підходу. Такі рішення дуже погано піддаються підтримки і неважливо масштабуються, так як є більшою мірою state of art, ніж тиражованих рішення або набором кращих практик. Також, існує величезна кількість можливих послідовностей дій користувача, що перетворює процес тестування різних комбінацій в пекло.
3. Обман користувача
Коли ми демонструємо користувачу, що його дія виповнилося успішно, хоча насправді воно ще тільки виконується, ми створюємо відчуття, що нашій системі не можна довіряти в разі невдачі.
Realistic UI
Disclaimer
Хоча я придумав і визначив концепцію Realistic UI, я не претендую на лаври першовідкривача. Як і принципи REST були визначені більш, ніж через 10 років після широкого поширення Інтернету в його сучасному вигляді, так і ідеї Realistic UI можна зустріти в різних проектах вже зараз. Зокрема панель управління Azure реалізована у відповідності з принципами Realistic UI.
Принципи Realistic UI
  1. Блокується тільки частина інтерфейсу. Наприклад, якщо користувач заповнює форму і натискає кнопку «Надіслати», ніхто не буде йому заважати перейти на іншу сторінку або виконати інше незалежне дію за умови, що зміна даних форми буде неможливо до завершення виконання віддаленої операції. realistic-ui block
  2. UI містить віджет, який відображає всі активні операції. За допомогою цього віджета користувач може відстежувати поточний статус виконання операцій, а також переходити на відповідну сторінку і / або частину сторінки при бажанні.
  3. UI містить ще один віджет, який відображає операції, які завершилися невдало. З цього віджета користувач може повторно запустити виконання невдалої операції, перейти до відповідної сторінки та / або частини сторінки або проігнорувати помилку.
Realistic UI vs. Optimistic UI
Realistic UI передбачає єдиний механізм для всіх типів операцій.
Realistic UI не обманює.
Realistic UI дозволяє виконувати кілька операцій одночасно, але гарантує, що їх виконання станеться незалежно один від одного, що істотно спрощує процес вирішення конфліктів.
Realistic UI дає користувачеві повне уявлення про виконуваних і виконаних операціях.
Таким чином, Realistic UI бере кращі риси від всіх підходів взаємодії з бэкендами, але позбавлений більшості недоліків.
Висновок
Мене дуже хвилює існуюча хвиля хайпи навколо концепції Optimistic UI, і я сподіваюся, що у мене вийде викликати дискусію, яка б змогла більш об'єктивно підійти до її оцінки.
З метою демонстрації ідей Realistic UI на практиці я реалізував невеликий Proof Of Concept, який можна подивитися, перейшовши за посиланням — https://yury-dymov.github.io/realistic-ui-concept/.
Вихідний код демки я виклав на GitHub — https://github.com/yury-dymov/realistic-ui-concept.
Якщо мої доводи здалися вам переконливими, я буду дуже вдячний за ретвіт і зірочку. Я вважаю, що вкрай важливо донести ці ідеї до колег, так як існуючі проблеми Optimistic UI можуть принести багато шкоди тим командам, які зважаться їх впроваджувати, не усвідомлюючи всіх можливих труднощів.
Звичайно, я буду дуже радий як запереченням, так і критиці в коментарях, що дозволить зробити концепцію ще краще.
Джерело: Хабрахабр

0 коментарів

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