Візуальні зміни в системах дизайну

Ми поважаємо API коду. А як щодо кольору, типу та простору?

№4 з 6 із серії випуску систем дизайну:
Виходи | Каденція | Версії | Порушення | Залежності | Процес

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

Тож запитайте себе…

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

Semantic Versioning (SemVer) пропонує чіткі критерії для передачі змін у релізах за допомогою основних, мінорних та патч-позначень. Кожна система дизайну, з якою я стикаюсь, використовує SemVer і відстежує зміни в інтерфейсі програмування програмного забезпечення або API. Це звична територія для розробників, що кодують реквізити JavaScript та розмітку HTML. Розбийте свій API, і ваша наступна версія повинна збільшити версію до наступної основної версії, наприклад, від 1.4.0 до 2.0.0.

Визначення інтерфейсу до композиційного візуального стилю нам ухиляється. Дуже важко визначити чіткі, прості правила для моніторингу змін стилю. Виробники системи намагаються сформулювати, що або чому "Зміна цього стилю порушує користувальницький інтерфейс", а не "Зміна цього стилю не відповідає". Мало хто із системних команд документує такі критерії. Я запитую «Які конкретні типи візуальних змін викликають для вас основну версію?» Їх відповідь: ¯ \ _ (ツ) _ / ¯.

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

Розрив кольору

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

Налаштування кольору фону основної кнопки

Звичайно, приймаючі команди не повинні перекривати стандартний набір кольорів первинної кнопки. Переосмислення вибору системи перериває зв'язок із системою. У цей момент усиновлювач самостійно. Тому коригування відтінку кольору основного клавіша є безпечним і не є переломним.

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

Приклад: Системний текст на користувальницьких фонах

Уявіть, що команда системи налагоджує інтерактивний синій колір, щоб покращити кольоровий контраст. Інтерактивно-блакитний колір v1.4.0 був доступний на білому тлі, але не вдався на тлі деревного вугілля.

Перевірка контрастності кольорів через Contrast-grid.eightshapes.com

Так, для v1.5.0 команда налаштувала інтерактивно-блакитний на більш світлий, насичений тон, який працював як на білому, так і на вугільному.

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

Однак усиновлювач використовував кнопку «Привид», що залежить від цього кольору, на світло-сірому тлі. Після зміни системи контраст кольору тексту мітки є недоступним. Ваша система зламала їх продукт.

Приклад: Системні фони зі спеціальним накладеним текстом

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

Налаштування кольору фону картки, що дозволяє містити нестандартний вміст

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

Уявіть, що в незначну версію вашої системи були включені ці налаштування. Ви сказали, назад сумісні? Немає ризику в оновленні, вони довіряли? Ні! Ваша система зламала їхній продукт!

Тому оцініть властивості змінених кольорів, щоб визначити, чи змінилася система, наприклад:

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

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

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

Розбиття типографіки (шляхом обгортання)

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

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

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

Приклад: Обгортання вкладок жахливо

Уявіть, що ваша система коригує вагу вкладки від нормальної до жирної.

Після незначного оновлення версії невідповідальні вкладки завершуються. Не добре.

Удосконалювач оновлення. Їх наявні невідповідні вкладки перевищують виділений простір, тому вони обертаються. Ганебно! Ваша система зламала їх продукт.

Приклад: Поглинання листів Поглинання

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

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

Налаштування типографії системи може бути небезпечним. Для вас - це освіжаюча типографічна еволюція, яка легко розгортається в бібліотеці. До них текст починається неправильно. Вони звинувачують вас. Можливо, вони спалахують вас у каналі # system-design Slack. Нікому цього не потрібно.

Винос: До 1.0.0 ретельно працюйте, щоб експериментувати, вдосконалювати та доопрацьовувати стилі типів, що підходять до різноманітності клієнта. Як тільки 1.0.0 пройде, підтримуйте стабільну базу та обмірковуйте зміни. Розгляньте можливість резервувати небезпечні зміни для наступного великого випуску. До цього часу поступово додайте вміщені функції, такі як компонент "Текст довгих форм" для стилізації просто копії статті.

Порушення простору та розміру

Принаймні можна побачити колір та типографіку. Простір і розмір? Їх важче визначити як конкретно багаторазові, не кажучи вже про моніторинг для порушення змін.

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

Приклад 1: Видалення вертикальних відстаней

Ваша системна команда вирішує видалити вертикальні міжрядкові елементи керування форми у вигляді нижнього поля. Це впливає на ,