Від одного дизайну до багатьох екранів: більш раціональний процес створення активів екрана запуску

Екран запуску є одним із найменших елементів мобільного додатку, проте він часто затримує його випуск значно більше, ніж може видатися з огляду на його розмір. Логотип готовий, палітра кольорів бренду визначена, але все одно потрібно створювати ресурси для запуску у різних форматах, для різних пристроїв та платформ. Жоден з цих кроків не є складним, але вони трудомісткі, схильні до непомітних помилок та з’являються з кожним новим проектом. У цьому посібнику розглядається, куди насправді йде час та зусилля, як створити екран запуску, який буде добре виглядати на будь-якому екрані, та що має (та чого не повинно) робити для вас невеликий інструмент-генератор.

Дизайн — це швидко; експорт — це клопіт

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

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

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

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

Чому екрани запуску складніші за іконки додатків

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

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

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

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

Конвенції платформ спрямовані в одному напрямку. У нових версіях Android екран запуску створюється з іконки на фоновому кольорі, а екрани запуску iOS визначаються як макет, а не як окреме фіксоване зображення, тож композиція, яка вже складається з „знака на простому фоні“, легко підходить для обох. Для отримання точних вимог перевірте документацію поточної платформи, адже вони змінюються між версіями ОС.

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

Робочий процес, до якого варто прагнути

У спрощеному вигляді ідеальний процес складається з п’яти кроків:

1. Надайте вихідне зображення або елементи брендингу.
2. Налаштуйте їх розміщення: фон, розмір логотипу, відступи.
3. Перегляньте результат на різних форматах екранів.
4. Створіть необхідні ресурси для запуску.
5. Поверніться до розробки додатку.

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

Інструменти, які не заважають

Корисною властивістю такого інструменту є те, що він майже нічого не вимагає спочатку. Немає жодних обґрунтованих причин, чому одноразове завдання з обробки даних мало б вимагати від користувача:

• створення облікового запису
• підтвердження електронної адреси
• налаштування робочого простору
• надання назви проекту
• вибору плану підписки
• пройшення багатоетапної процедури налаштування

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

Чому обробка в браузері є правильним стандартом

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

Виконання роботи на клієнтській стороні має практичні переваги:

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

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

Навіть невеликі проблеми вимагають хороших інструментів

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

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

• генератор іконок додатку
• генератор екрана запуску
• генератор скріншотів для App Store та Google Play

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

Ключові висновки

• Час, який витрачається на екрани запуску, йде на адаптацію одного дизайну під різні форми екранів, а не на його створення.
• Створюйте дизайн навколо центрованої візуальної точки, фону, який може вільно розтягуватися, та без чогось критичного біля країв.
• Перегляньте зображення у кількох співвідношеннях сторін перед експортом; саме тоді проявляються проблеми з обрізанням та масштабуванням.
• Для одноразових завдань з активами краще використовувати легкі інструменти без реєстрації, а повноцінні інструменти дизайну — для справжньої роботи з дизайном.

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

Пов’язана література

• Планування оновлення Expo SDK 58: iOS 27, React Native 0.88 та нові інструменти — практичний огляд бета-версії Expo SDK 58: які зміни в iOS 27 та React Native 0.88, які функції є експериментальними та як безпечно протестувати оновлення.
• Вибір мови залежно від типу завдання: уроки з портування TypeScript на Go — що дає вибір Go для нативного компілятора TypeScript щодо підбору інструментів під конкретні завдання, важливості швидкості інструментів та поетапного портування великих кодових баз.