Публікація на tonsky.me доводить, що знімок екрана застосунку має бути зрозумілим у будь-який момент, а кадри посеред анімації показують, чи справді інтерфейс проєктували ретельно.

Кожен кадр ідеальний

Фраза походить із документації Wayland: «кожен кадр ідеальний» — це заявлена мета протоколу дисплея, який намагається повернути контроль над дедалі складнішими стеками GPU. У публікації на tonsky.me автор стверджує, що той самий принцип варто застосовувати і до інтерфейсів, а не лише до графічного конвеєра.

Правило, яке він пропонує, просте: якщо хтось зробить знімок екрана вашого застосунку в будь-який момент, ви маєте бути здатні пояснити, що на ньому видно. За приміткою в тексті, попереднє формулювання — «це має мати сенс» — було надто суворим, бо передові техніки анімації, зокрема smear frames, навмисно деформують рух.

Чому важлива середина переходу

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

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

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

Дрібні розсинхронізації, великі сумніви

Приклади — з повсякденних програм. У Safari текст-заповнювач рухається з центру, а курсор анімується з лівої позиції, через що два компоненти здаються неузгодженими — і виникає питання, чи проєктували їх разом. У Photos перемикання між Crop і Adjust миттєво ставить зображення на місце, тоді як рамка обрізання анімується, створюючи хибне відчуття, ніби щось трохи змінилося.

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

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

«Кожен кадр ідеальний»: чому інтерфейс оцінюють покадрово