Англійська мова для пояснення темного режиму та прийняття рішень щодо дизайну токенів

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

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

** Маркер дизайну ** — значення з назвою, яке можна використовувати багаторазово (колір, одиниця інтервалу, розмір шрифту), яке позначає рішення щодо дизайну, яке використовується замість твердих значень, щоб можна було послідовно змінювати теми. “Замість жорсткого кодування #1a1a1a, ми використовуємо токен color-surface-primary, який розв’ язує до іншого шістнадцяткового значення залежно від того, чи активна світла чи темна тема.”

** Семантичні назви ** — назви символу за його призначенням або роллю (« color- text- danger »), а не за його буквальним значенням (« red- 500 »), щоб назва мала сенс, коли значення змінюється між темами. “Ми перейменували red-500 на color-text-danger — семантичний назви все ще має сенс у темному режимі, де фактичний колір може бути іншим відтінком червоного.”

** Перемикання тем ** — механізм, за допомогою якого програма змінює активний набір значень символів, зазвичай, за допомогою зміни набору змінних CSS або контекстного значення. “Зміна теми відбувається за допомогою перемикання атрибуту data-theme на кореневому елементі — всі наші символи визначені як нетипові властивості CSS, що відповідають цьому атрибуту.”

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

• “Ми повинні перевірити співвідношення контрастності для темного режиму — парування, яке відбувається у світлому режимі, не відбувається автоматично після інвертування тла.” *

** Розв’ язання токена ** — процес розв’ язання токена до конкретного значення під час збирання або виконання, іноді за допомогою декількох шарів псевдоніму. “Ця помилка була проблемою розв’ язання символу — color-button-primary було псевдонімом для символу, який сам по собі не був визначений для темного режиму, тому він беззвучно повертався до типового.”

Звичайні фрази

• «Цей компонент все ще використовує твердий кодований колір замість токена — саме тому він не реагує на перемикання тем»
• «Чи можемо ми зробити цей знак семантичним замість літерального, щоб він все ще мав сенс у темному режимі?»
• «Ми повинні перевірити співвідношення контрастності окремо для кожної теми, а не тільки світлий режим.»
• Це є помилка розв’язання токенів — ланцюг псевдонімів розривається в темному режимі
• «Давайте визначимо значення темного режиму для цього токену перед злиття.»

Приклади висловлювань

Пояснення вади, спричиненої твердим кодом:

• “Рамка цієї карти невидима у темному режимі, оскільки вона закодована у #e0e0e0, світло- сірий колір, який зливається з темним тлом. Якщо ми переключимо його на знак color-border-default, він автоматично підбере відповідне значення в обох темах.”*

Пропозиція семантичних назв для дизайнера: “Замість того, щоб назвати цей символ blue-600, я б запропонував щось на зразок color-action-primary — він описує, для чого призначений колір, а не те, як він виглядає, що має значення, оскільки фактичне шістнадцяткове значення буде відрізнятися між світлими і темними темами.”

Позначити проблему з контрастністю, виявлену під час перевірки темного режиму:

• “Під час тестування темного режиму я виявив, що текст вимкненої кнопки має співвідношення контрасту 2. 3: 1 з його тлом, що не відповідає правилам доступності. Ця комбінація не була проблемою в світлому режимі, тому виглядає, що вона просто не була перевірена для темного режиму.»*

Пояснення архітектури символів новому члену команди:

• “Ми маємо два шари: примітивні символи, які є необробленими значеннями, наприклад gray-900, і семантичні символи, наприклад color-text-primary, які посилаються на примітивний символ і можуть вказувати на інший символ для кожної теми. Компоненти повинні завжди вказувати тільки на семантичні символи, ніколи не на примітивні.»*

Професійні поради

• При повідомленні про ваду темного режиму, вкажіть спеціальний символ (або його відсутність) як кореневу причину — « це закодовано замість використання символу » є точним, дієвим описом вади.
• Використовуйте “семантичне позначення” проти “примітивного позначення” як відмінність під час обговорення архітектури — це стандартний словник у системах проектування і сигналізує про те, що ви розумієте шарування.
• Завжди згадуйте, що ** контрастність потребує окремої перевірки для кожної теми ** — це поширена помилка, і її чітке вказання у перегляді дизайну збереже цикл контролю якості.
• Описувати помилки перемикання тем як ** « розділення символів » ** проблеми, коли значення надходить з неправильного місця у ланцюжку псевдонімів — це більш специфічно, ніж « колір неправильний »
• Коли ви пропонуєте нові символи, обґрунтовуйте назву за її ** метою **, а не за її виглядом — це основний аргумент для семантичного надання назв, і він добре підходить для дизайнерів.

Практичні вправи

1. Напишіть речення, у якому буде описано ваду темного режиму, спричинену твердим кодом (не символом).
2. Напишіть речення, у якому ви запропонуєте семантичну назву знака і поясните, чому вона краща за буквальну.
3. Напишіть речення, у якому буде позначено помилку співвідношення контрастності, виявлену під час перевірки темного режиму.

Навигація Nuance: Специфічна мова для міжнародних команд

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

Розглянемо звичайний сценарій: ви отримали коментар перегляду коду до PR, у якому вводиться нова тема темного режиму. Замість того, щоб просто відповісти « Виправлено », що може бути досить нечітким, спробуйте щось на зразок: « Дякую за позначення цього! Я скоригував символ color-palette-dark, щоб забезпечити послідовне застосування у всіх компонентах. Зокрема, я змінив значення --primary-text-color-dark з #FFFFFF на #212121, вирівнюючи його з рекомендаціями бренду, наведеними в документації системи дизайну. Я також додав коментар у відповідні файли компонентів, де пояснюються ці зміни і вказується на визначення символу для більшої зрозумілості у майбутньому. » Бачите зміну? Ми не просто виправляємо помилку; ми демонструємо розуміння більш широкого контексту, визнаючи відгуки рецензентів і проактивно повідомляючи про логіку нашого рішення.

Інша ситуація виникає при обговоренні рішення про дизайн-токен з дизайнером в каналі Slack. Замість того, щоб сказати: «Темний режим виглядає краще», що є суб’єктивним і не пропонує розуміння, ви можете сказати: «Я регулюю --background-color токен на темніший відтінок - наразі #121212. Це було засновано на даних тестування користувачів, що показують покращену читабельність в умовах слабкого освітлення, як це задокументовано в дослідницькому звіті про дизайн системи. Це також дозволяє нам краще дотримуватися рекомендацій щодо доступності, що стосуються співвідношення контрасту для тексту. » Формування вашого вводу навколо кількісних даних і посилання на встановлену документацію зміцнює ваш аргумент і показує, що ви працюєте у межах спільного розуміння принципів дизайну і технічних обмежень.

Нарешті, при написанні описів PR, уникайте надто технічного жаргону, який може бути не зрозумілим для всіх членів команди. Замість « Впроваджено темний режим за допомогою змінних CSS », спробуйте « Введено нову темну тему, у якій використано символи дизайну для послідовного стилю у всій програмі, покращено доступність і візуальний комфорт у середовищах з низьким рівнем освітлення ». Остання назва є більш доступною, чітко визначає мету і надає контекст, що є ключовим при співпраці з колегами з різних галузей знань. Пам’ятайте, чітке спілкування не стосується технічної досконалості; воно стосується того, щоб кожен розумів цінність вашої роботи і як вона сприяє загальному баченню продукту.