Token နာမည်ပေးခြင်းအနုပညာ — Field Notes
contents Design Token တစ်ခုကိုမြင်လိုက်တာနဲ့ ဒီ token က ဘာအတွက်သုံးတာလဲဆိုတဲ့ decision ကို သူ့ကိုအသုံးပြုမယ့်သူတိုင်းအတွက် သိသာနေဖို့လိုအပ်ပါတယ်။ ဒီအတွက်ကြောင့် naming system ကောင်းကောင်းနဲ့ နာမည်ပေးဖို့လိုပါတယ်။
နာမည်ဘယ်လိုပေးရမလဲဆိုတာ မလေ့လာခင် Design tokens ဆိုတာဘာလဲ အသေးစိတ်ရှင်းပြထားတဲ့ အရင် note ကို အရင်ဖတ်လို့ရပါတယ်။
Tokens တွေရဲ့ concept က ဘယ်ကစသလဲ Design System တစ်ခုမှာ color, font, shadow, radius အစရှိသဖြင့် style တွေရှိသလို အဲ့ style တစ်ခုစီတိုင်းအတွက် option တွေများစွာရှိပါတယ်။
ဥပမာ - red-50 ~ 1000, font-size-sm ~ xl, etc.
Design System ကောင်းတစ်ခုဖြစ်ဖို့ဆိုရင် ဒီ ရွေးခြယ်ထားတဲ့ design option တွေကို ဘယ်နေရာမှာသုံးမှာလဲဆိုတဲ့ decision အနေနဲ့ မြင်ရဖို့လိုပါတယ်။ ဘာကြောင့်လဲ။ Design System တစ်ခုမှာ component ပေါင်းများစွာရှိသလို ဒီ component တွေကို styling လုပ်တဲ့အခါ option တွေများစွာထဲကနေ ထပ်ခါထပ်ခါ apply လုပ်နေရတာက ရေရှည်မှာ အဆင်မပြေနိုင်တဲ့အရာပဲဖြစ်ပါတယ်။ အရင်က author ဆိုရင် ရံဖန်ရံခါတိုင်း primary text ကို neutral-500 ပေးရမယ့်အစား မေ့ပြီး neutral-600 ဆိုပြီး ပေးမိတဲ့အခြေအနေမျိုးတွေများစွာကြုံတွေ့ရပါတယ်။ ဘာလို့ဆို option တွေသာရှိပြီး ဘယ် option ကိုတော့ ဘယ်နေရာမှာ သုံးမယ်ဆိုတာမျိုး decision မှ မမြင်ရတာ။ မှန်းပြီးတော့ apply လုပ်နေတာကြောင့် ဖြစ်ပါတယ်။
ဆိုတော့ $red-500 လိုမျိုး color option တစ်ခုကို hand-off လုပ်လိုက်တဲ့အခါမှာ Developer တွေက Sass လို preprocessor တစ်ခုခုမှာ
variables $red-500: #fd404d;
$font-size-m: 16px;
$border-radius-sm: 4px;ဆိုပြီး variable အနေနဲ့ သိမ်းပါတယ်။ ဒီ variable တွေကို system ရဲ့ လိုအပ်တဲ့ နေရာတိုင်းအတွက် reusable လုပ်နိုင်ပါတယ်။ ဒါပေမယ့် ဒီ variable တွေက option တွေကို naming သီးသန့်ပေးပြီးသိမ်းထားတာသာ ဖြစ်ပြီး ဘယ်လိုအသုံးပြုမှာလဲဆိုတာမပါဝင်ပါဘူး။ အကယ်၍ ဒီ option တစ်ခုစီတိုင်းမှာတိုင်းသာ use of context ပါဝင်မယ်ဆိုရင် ဒီ variable တွေရဲ့ power ဟာပိုပြီး strong ဖြစ်လာမှာဖြစ်ပါတယ်။
ဥပမာ -
context ပါတဲ့ variables $color-bg-primary: $red-500;
$font-size-subtitle: $font-size-m;
$border-inset-default: $border-radius-sm;ဒီလို variable တွေမှာဆိုရင် ဘယ်နေရာမှာ သုံးမယ်ဆိုတဲ့ decision မျိုးကို တွေ့နိုင်ပါတယ်။ နောက်ပြီးတော့ ဒီလို decision မျိုးတွေကို သက်ဆိုင်ရာ product ရဲ့ repository တွေမှာတင် မသိမ်းထားတော့ပဲ designer တွေပါ မြင်တွေ့နိုင်တဲ့နေရာကို ခေါ်လာပြီး အခြားသော product တွေပါ reusable ဖြစ်နိုင်မယ့် centralized living system တစ်ခုအနေနဲ့ထားမယ်ဆိုရင် designer ရော dev ရော လူတိုင်းအတွက် ပိုပြီး အသုံးဝင်ပါတယ်။
ခုလို concept မျိုးကို အခြေခံပြီးတော့ Salesforce ကနေစပြီး ၂၀၁၄ ခုနှစ်လောက်ကထဲက ဒီ tokens concept ကိုစတင်အသုံးပြုလာတာဖြစ်ပါတယ်။
မှတ်ချက် ✓ resolved Variable concept ဆိုပေမယ့် Design Tokens တွေက variables တွေတော့မဟုတ်ဘူးဆိုတာ သတိချပ်စေလိုပါတယ်။ Variables တွေက technology dependent ဖြစ်ပြီး tokens တွေကတော့ technology agnostic format တစ်ခုဖြစ်ပါတယ်။ Design Tokens ဆိုတာ method တစ်ခုဖြစ်ပါတယ်။ဒီ concept ကြောင့် စောနက design options တွေဟာ နားလည်ရလွယ်၊ ဖတ်ရလွယ်ပြီး update ပြုလုပ်ရလည်းလွယ်သွားပါတယ်။
Design Tokens တွေကို ကောင်းကောင်းနားလည်ပြီး ဖတ်ဖို့အတွက်ဆိုရင် naming system ကောင်းကောင်းပေးဖို့လည်း လိုအပ်ပါတယ်။
ဒါဆို Tokens တွေကို ဘယ်လိုနာမည်ပေးမလဲ။
လက်ရှိမှာ tokens တွေကိုနာမည်ပေးဖို့ naming convention အမျိုးမျိုးရှိပါတယ်။
ဘယ် convention ကမှ အမှန် ဆိုပြီးမရှိသလို ကိုယ့် organization နဲ့ ကိုက်ညီမယ့် system ကို အသုံးပြုမယ့် team နဲ့အတူ သေချာလေ့လာဆွေးနွေးရင်း အသုံးပြုနိုင်ပါတယ်။ ဒါပေမယ့် ကိုယ်ရွေးချယ်ထားတဲ့ convention တစ်မျိုးထဲကိုတော့ consistent ဖြစ်အောင်သုံးသင့်ပါတယ်။
Token တွေကို နာမည်ပေးရတာ တော်တော်ဦးနှောက်ခြောက်တဲ့အလုပ်ပဲဖြစ်ပါတယ်။ Developer တွေရော Designer တွေရောခေါင်းချင်းဆိုင်ပြီး ဘယ် convention က organization အတွက် အဆင်ပြေဆုံးဖြစ်မလဲ research and discuss အကြာကြီးလုပ်ပြီးမှ အဖြေထွက်လာနိုင်တဲ့အရာပဲ ဖြစ်ပါတယ်။
Tokens တွေကို Token tier တွေပေါ်မူတည်ပြီး alias လုပ်ရင်း နာမည်ပေးလို့ရပါတယ်။
Tokens tiers ယေဘုယျအားဖြင့် Core၊ System၊ Component ဆိုပြီး tier (၃) ခုရှိပါတယ်။
diagram · token.tiers Core, system, component ဆိုတဲ့ tier (၃) ဆင့်။
First tier tokens ဒီ tier မှာဆိုရင် design option တွေရဲ့ raw value တွေကို store လုပ်ထားပြီး Design System တစ်ခုစီအလိုက် Base Tokens၊ Global Tokens၊ Core Tokens၊ Primitive Tokens ဆိုပြီး အခေါ်အဝေါ်တွေကွဲပါတယ်။ ဒီ article မှာတော့ Core token ဆိုပြီးပဲ ဆက်ရေးသွားပါမယ်။ e.g. red-500, grey-500, teal-500, etc
Second tier tokens ဒီ tier ကတော့ အပေါ်က core tokens တွေကို reference ယူပြီး ဘယ်နေရာမှာ၊ ဘယ်အခြေအနေမှာ သုံးမယ်ဆိုတဲ့ decision ပါတဲ့ second tier token တွေပဲဖြစ်ပါတယ်။ e.g. color-bg-primary-red, color-bg-primary-grey, color-bg-primary-teal, etc.
Second Tier Tokens တွေကို semantic tokens၊ alias tokens၊ system tokens၊ public tokens ဆိုပြီးလည်း အမျိုးမျိုးခေါ်ကြပါသေးတယ်။ ဒီ article မှာတော့ System token ဆိုပြီးပဲ ဆက်ရေးသွားပါမယ်။
Third tier tokens ဒီ tier က တော့ system token ရဲ့ value ကို reference ယူပြီး ဘယ် component မှာသုံးမှာလဲဆိုတာမျိုး အထိပါပါတဲ့ Component tokens တွေပဲဖြစ်ပါတယ်။ e.g. color-button-bg, color-checkbox-bg, color-radio-bg, etc.
တစ်ချို့ system တွေမှာ ဒီ component tokens တွေအထိ မသုံးတာမျိုးလည်းရှိကြပါတယ်။
ဒီလို Tier တွေခွဲပြီး နာမည်ပေးတာကို aliasing လုပ်တယ်လို့ခေါ်ပါတယ်။ ဒါဆို Alias မလုပ်ပဲရော နာမည်ပေးလို့မရဘူးလား...။
Alias လုပ်ရခြင်းရဲ့ရည်ရွယ်ချက်ကိုပြောပြပါမယ်။
diff · alias မလုပ် ↔ alias လုပ် button checkbox radio
→ red-500
button checkbox radio
→ color-button-bgcolor-checkbox-bgcolor-radio-bg
→ red-500
alias မလုပ် alias လုပ်
Component တွေ base token ကို တိုက်ရိုက်သုံးတာနဲ့ alias ကနေ တစ်ဆင့်သုံးတာ။ ပုံပါအတိုင်းမှာဆိုရင် button၊ checkbox၊ radio button စတဲ့ component တွေဟာ red-500 ဆိုတဲ့ base-token လေးကို ဘုံအသုံးပြုထားပါတယ်။ အကယ်၍ သူတို့ ၃ မျိုးထဲက တစ်ခုခုကို အရောင်ချိန်းဖို့လိုလာသည်ဖြစ်ဖြစ်၊ သီးသန့်တစ်ရောင်စီ ချိန်းတာဖြစ်ဖြစ်ဆိုရင် အမြဲတမ်း တစ်ခုချင်းဆီမှာ သပ်သပ် ပြန်ပြင်ရမှာဖြစ်ပါတယ်။ ဒီ ၃ခု ထဲဆိုသိပ်မသိသာပေမယ့် Design System တစ်ခုလုံးကိုသာ ပြင်ရမယ်ဆိုရင် တော်တော်စိတ်ရှုပ်ဖို့ကောင်းမှာ အမှန်ပါပဲ။
အကယ်၍ အစကထဲက tier တွေခွဲပြီး alias လုပ်ခဲ့မယ်ဆိုရင် component တစ်ခုစီအထိ လိုက်ပြင်စရာမလိုပဲ Design Tokens တွေမှာ reference ယူထားတဲ့ master ကို လိုချင်တဲ့ token ပြောင်းလိုက်ရုံပဲဖြစ်ပါတယ်။
diagram · alias.swap Master token ကို တစ်ခါပြောင်းလိုက်ရင် alias ယူထားတဲ့ component အားလုံး လိုက်ပြောင်းသွားတယ်။
Token name တစ်ခုရဲ့ အခရာများ Tokens တွေကိုနာမည်ပေးဖို့အတွက် ယေဘုယျအားဖြင့် ဒီအရာတွေကို ထည့်သွင်းစဉ်းစားသင့်ပါတယ်။
Case convention Token name တစ်ခုပေးတဲ့အခါ case convention ကိုလည်း တစ်သတ်မှတ်ထဲအသုံးပြုသင့်ပါတယ်။ အသုံးများတဲ့ case convention တွေကတော့
case conventions kebab-case color-bg-primary
camelCase colorBgPrimary
PascalCase ColorBgPrimary
snake_case color_bg_primary
Neutralization ဒါကတော့ system tokens နဲ့ component tokens တွေမှာ ကိုယ်သုံးတဲ့ စကားလုံးအသုံးအနှုန်းတွေကို neutral ဖြစ်တဲ့ အသုံးအနှုန်းမျိုး ရွေးသင့်တာကိုဆိုလိုချင်တာပါ။ ဥပမာ - အဓိက အသုံးပြုမယ့် button ရဲ့ color name ကို color-button-bg-red ဆိုပြီး ပေးမယ့်အစား color-button-bg-primary ဆိုပြီးပေးတာမျိုး။ ဘာလို့ဆို အနီရောင်မဟုတ်ဘူး အပြာရောင်ကို main အနေနဲ့သုံးမယ်ဆို ပြန်ပြင်နေရဦးမှာမိုလို့ ဖြစ်ပါတယ်။
Brand name ကိုယ့်ရဲ့ brandname ကိုထည့်သွင်းစဉ်းစားခြင်း။
Tier name Core, System, Component tier တွေကို သတ်မှတ်ခြင်း။
Abbreviations Token name တွေမှာ brand name, tier စတာတွေကို အရှည်မသုံးပဲ အတိုကောက်ပြတာမျိုးတွေလည်းရှိပါတယ်။
ဥပမာ sizing မှာဆိုရင် small ကို sm လို့သုံးမှာလား S လို့သုံးမှာလား၊ brandname ကို salesforce လို့သုံးမှာလား sf လို့သုံးမှာလား စသဖြင့်။
ဒါပေမယ့် လူတိုင်းနားလည်တဲ့ common term တွေလောက်မှာသာ သုံးသင့်ပြီး အကုန်လုံးကိုတော့ အတိုကောက်တွေမသုံးသင့်ပါဘူး။ Decision မပေါ်ပဲ ဒီအတိုကောက်က ဘာကိုဆိုလိုချင်တာလဲ စဥ်းစားနေရပါလိမ့်မယ်။
Prefixing or suffixing ဒါကတော့ ကိုယ်သုံးမယ့် object တွေကို ရှေ့မှာထားမှာလားနောက်မှာထားမှာလား ဆိုတာမျိုးပါ။
ဥပမာ background အတွက် token ကို color-bg or bg-color လို့ သုံးမှာလား ဆိုတာမျိုး။ Author ကတော့ prefix လုပ်ရတာကို ပိုသဘောကျပါတယ်။
Scales Scales ဆိုတဲ့နေရာမှာ Numeric scale တွေဖြစ်တဲ့ 100, 200, 12px,.. စတာတွေသုံးမှာလား၊ Ordinal scale တွေဖြစ်တဲ့ small, medium, large တွေသုံးမှာလား အစရှိသဖြင့် သတ်မှတ်ရပါတယ်။
Numeric scale တွေကတော့ သိပ်ပြောစရာမရှိပါဘူး။ Ordinal scale အမျိုးအစား ဥပမာတွေကတော့ -
• Importance: Primary, Secondary, Tertiary, …
• Intensity: none, low, normal, medium, high, max
• Strength: Weak, Moderate, Strong, Extreme
• Level: Level-1, Level-2, …
• Speed: instant, immediate, quick or fast, moderate, slow, deliberate
ဒီအပိုင်းကတော့ basic system တွေမှာ သိပ်မပါပေမယ့် advanced system တွေမှာဆို မြင်တွေ့ရပါတယ်။
Dark mode, Light mode စသခြင့် theming အပိုင်းတွေ၊ Responsiveness အတွက်ဖြစ်တဲ့ mobile, iPad, tablet, web စတဲ့အပိုင်းတွေကို ထည့်သွင်းစဥ်းစားခြင်းဖြစ်ပါတယ်။
Categories ကိုယ့် system ရဲ့လိုအပ်ချက်အပေါ်လိုက်ပြီး categories အမျိုးမျိုးရှိပါတယ်။
category တွေမှာဆိုရင် များသောအားဖြင့် ကိုယ်အသုံးပြုမယ့် UI Element တွေဖြစ်တဲ့
categories color
font (aka type, typography, text)
space (aka units, dimension, spacing)
size (aka sizing)
elevation (aka z-index, layer, layering)
breakpoints (aka media-query, responsive)
shadow (aka depth)
touch
time (aka animation, duration)
Naming hierarchy or levels ကိုယ့် system မှာ အသုံးပြုရမယ့် Tokens တွေများလာတာနဲ့အမျှ စနစ်ကျတဲ့ pattern တစ်ခုဟာ အလွန်အရေးပါလာပါတယ်။ ဒီ pattern ကို သူ့ရဲ့ hierarchy ပေါ်လိုက်ပြီး ဖန်တီးလို့ရပါတယ်။ Convention တွေက ဒီ hierarchy ပေါ်မူတည်ပြီး ကွဲပြားသွားကြပါတာဖြစ်ပါတယ်။ Core tokens တွေမှာ 2 levels လောက်ပဲရှိတဲ့ hierarchy ကိုသုံးရုံနဲ့လုံလောက်ပေမယ့် system tokens, component tokens တွေမှာတော့ ပိုပြီးရှုပ်တဲ့ level တွေကိုအသုံးပြုရလေ့ရှိပါတယ်။
Leveling နဲ့ပတ်သက်ပြီး ခရေစေ့တွင်းကျ လေ့လာချင်ရင်တော့ Nathan ရဲ့ Naming Tokens in Design System article ကိုဖတ်လို့ရပါတယ်။
diagram · token.name Token name တစ်ခုကို segment တွေအဖြစ် ခွဲကြည့်တာ။ Salesforce ရဲ့ hierarchy ပုံစံ။ အထက်ပါပုံကတော့ Design Token ရဲ့ ဖန်တီးရှင် Salesforce ရဲ့ Token hierarchy ပဲဖြစ်ပါတယ်။ ကိုယ့် system နဲ့အဆင်ပြေမယ့် hierarchy ကို သင့်လျော်သလို research လုပ်ပြီး ရွေးလို့ရသလို ကိုယ့်ဘာသာ ကိုယ်ပိုင် hierarchy တစ်ခုကိုလည်း စုတုပြု ဖန်တီးလို့လည်းရပါတယ်။
Some design token naming conventions I like:
conventions I like Material Design System
Atlassian's ADS
Adobe's Spectrum
GitHub's Primer Design System
အနှစ်ချုပ် Token naming လုပ်တဲ့အခါမှာ ကိုယ့်နာမည်ပေးသလိုပဲ တစ်ခါပေးပြီး တစ်သက်လုံးပြင်လို့မရတော့ဘူးဆိုတဲ့အတွေးနဲ့ သေချာ စဥ်းစားပြီးမှ ပေးစေချင်ပါတယ်။ (ပြင်လို့တော့ရပေမယ့် then you are making the whole concept wrong)
ကိုယ်ပိုင် convention တစ်ခုကို ဖန်တီးချင်တယ်၊ ဒီထက်ပိုပြီး ထဲထဲဝင်ဝင်လေ့လာချင်တယ်ဆိုရင်တော့ author အနေနဲ့ Design System Course တစ်ခု ဖွင့်ဖို့ရှိတာကြောင့် အဲ့သင်တန်းကနေ လေ့လာနိုင်မှာဖြစ်ပါတယ်။ Market ထဲမှာ English subtitled course တွေများစွာရှိပေမယ့် UX Maturity နိမ့်တဲ့ ဒီနိုင်ငံက organization တွေမှာ သူတို့ approach တွေကို apply လုပ်ဖို့က အရမ်း challenge ဖြစ်ပါတယ်။ ဒါကြောင့်မို့ မြန်မာ UX လောကက သူတွေအတွက်လည်း အဆင်ပြေသလို၊ သူတို့ရဲ့ advanced design system approach တွေကိုပါ လေ့လာသင်ယူနိုင်မယ့် course တစ်ခုကို ဖန်တီးပေးမှာဖြစ်ပါတယ်။
အမှာစာ Solo designer တစ်ယောက်အနေနဲ့ design system တစ်ခုဖန်တီးဖို့ ဝန်လေးနေတယ်ဆိုတာ နားလည်ပါတယ်။ ငါက ဒီ company မှာ ကြာကြာ မနေဘူးဆိုတဲ့အတွေးကြောင့်လည်း ဒီလို အချိန်ပေးရတဲ့ အရာတစ်ခုကို မလုပ်ချင်တာမျိုးရှိတာမျိုးလည်းဖြစ်ကောင်းဖြစ်နိုင်ပါတယ်။ Design System မှ မဟုတ်ဘူး အခြားအရာတွေလည်း ပါပါတယ်။
Instead ဒီလိုတွေးကြည့်ပါ။
ကိုယ့်အတွက် case study ကောင်းကောင်းရမှာဖြစ်သလို နောက်အလုပ်ဝင်မယ့် designer အတွက်လည်း အများကြီးအဆင်ပြေသွားနိုင်ပါတယ်။ တစ်ယောက်ကောင်းကနေစလို့ community အတွက် အများကြီး ကောင်းလာပြီး UX maturity လည်း တတ်လာနိုင်ပါတယ်။
ဒီအပိုင်းမှာတော့ ဒီလောက်ပါပဲ။ 👋 အဆုံးထိ ဖတ်ပေးတဲ့အတွက်ကျေးဇူးတင်ပါတယ်။
References and further reading:
https://medium.com/user-experience-design-1/naming-design-tokens-9454818ed7cb
https://medium.com/eightshapes-llc/naming-tokens-in-design-systems-9e86c7444676