Опишіть стани, перш ніж малювати індикатор
Це запропонований процес туристичного застосунку розробника, а не запис спостереженої поведінки API. Мандрівник вводить offline maps, запитує історичне обговорення й чекає. Застосунок має відрізняти незайману форму, незавершений запит, повернені записи, успішну порожню відповідь та помилку. Одна порожня панель не може пояснити всі ці ситуації.
Почніть із нейтрального початкового екрана, який пояснює, де відбуватиметься пошук. Саме введення тексту не обов’язково запускає запит. Після явного надсилання збережіть надіслане запитання разом із запитом і покажіть позначку завантаження. Залиште ввід читабельним і не допускайте багаторазового надсилання тієї самої дії повторними натисканнями. Індикатор повідомляє про очікування, а не доводить просування через архів.
Прив’язуйте пізню відповідь до її запитання
Уявіть, що мандрівник змінює ввід на downloaded regions, поки запит offline maps ще очікує. Це ілюстративна взаємодія, а не приклад отриманого пошуку. Застосунок має вирішити, чекати, починати інший запит чи дозволяти людині залишити екран. Який би вибір ви не реалізували, попередня відповідь не повинна мовчки ставати відповіддю на нову фразу.
Пов’язуйте кожен запит із надісланим вводом у власному стані застосунку. Після отримання перевіряйте, чи відповідь досі належить поточному представленню. Не показувати пізню відповідь — не те саме, що скасувати роботу сервера: уже надісланий запит може завершитися успішно й бути оплачений. Перевірте цю відмінність у своїй реалізації.
Сприймайте успішну порожню відповідь як результат
Для повернених записів показуйте наявні поля й залишайте позначення історичного джерела. Для порожнього масиву data використовуйте окреме повідомлення про те, що цей запит не повернув записів. Запропонуйте змінити фразу чи фільтри, зберігаючи їх для усвідомленого вибору. Не замінюйте порожню відповідь вигаданими популярними дописами.
Успішні порожні запити коштують один кредит, як і успішні відповіді із записами. Це причина робити зміни запиту свідомими, а не приховувати порожні відповіді як помилки. Уникайте твердження, що відповідного обговорення ніде не існує: архів неповний, а відповідь стосується певного запиту й обмеженого вікна.
Передавайте технічну проблему оператору
Відповідь 400 вимагає перевірки вводу запиту. Якщо застосунок передав неправильну дату чи непідтримуваний параметр, не звинувачуйте мандрівника в помилці контракту бекенду. 401 вказує на відсутній або недійсний ключ сервісу; перезавантаження застосунку чи прохання до мандрівника увійти не обов’язково виправлять ці облікові дані.
402 означає недостатньо кредитів в обліковому записі сервісу. Скеруйте це рішення оператору, а не показуйте рахунок мандрівникові. 429 вимагає дотримання Retry-After і зменшення повторних запитів. Оскільки застосунок може використовувати один обліковий запис для багатьох читачів, не повідомляйте автоматично одній людині, що саме вона спричинила обмеження.
Відрізняйте відому помилку від невідомого результату
Шлюз повертає 502, коли запит до джерела завершується помилкою. Зарезервований кредит звільняється або позначається як такий, що очікує звіряння. Збережіть запитання й раніше видиму сторінку, а потім запропонуйте обмежену можливість повтору. Повторні автоматичні спроби можуть створювати нові запити, не допомагаючи читачеві зрозуміти, що сталося.
Якщо застосунок узагалі не отримує відповіді, він може не знати, чи сервер завершив запит успішно або з помилкою. Зафіксуйте невизначеність для звіряння; не показуйте впевненого повідомлення про повернення коштів чи успіх. Публічний /v1/status є статичною перевіркою призначення сервісу та HTTP-відповіді, тож не вирішує це питання й не підтверджує справності архівного пошуку.
Перевіряйте переходи, а не лише знімки екранів
Пройдіть запропоновану послідовність із власником застосунку: надсилання, редагування під час очікування, порожня відповідь, повтор після помилки, наступна сторінка та вихід з екрана. Для кожного переходу визначте збережений ввід, видимий вміст і наступну дію. Привабливий макет не доводить, що ці переходи працюють.
Тримайте діагностику оператора, сирі відповіді сервісу й облікові дані подалі від повідомлень для користувачів. Дайте мандрівникові достатньо контексту, щоб продовжити підготовку без недоступної функції обговорень. У /uk/#field-notes наведено рішення щодо бюджету запитів і дії «Показати ще», які формують цей процес станів.
