פיתוח מצב בהיר (ערכת נושא בהירה) לאפליקציות מובייל
לאחרונה פנה אלינו לקוח עם פרויקט של גשש כושר: אפליקציית SwiftUI עם יותר מ-50 מסכים, ערכת הנושא הכהה הייתה מוכנה, אבל הערכת הנושא הבהירה פשוט ירשה צבעים מאבות העיצוב ללא מערכת. לאחר חודש של בדיקות, משתמשים התלוננו שטקסט לא קריא באור שמש חזק וכפתורים התמזגו עם הרקע. מצב טיפוסי: ערכת נושא בהירה היא לא רק היפוך צבעים, אלא מערכת צבעים מחושבת היטב עם טוקנים סמנטיים, יחסי ניגודיות והתאמה למסכים שונים. לקחנו על עצמנו את הפרויקט ובנינו מחדש את כל ארכיטקטורת הצבעים תוך 3 ימים — עכשיו האפליקציה עובדת גם על מסכי OLED וגם על מסכי LCD בתנאי תאורה שונים. במשך יותר מ-7 שנים, יישמנו מצב בהיר ליותר מ-30 פרויקטים, מגששי כושר ועד אפליקציות בנקאות, וטוקנים סמנטיים האיצו בעקביות עיצובים מחדש פי 5–10 בהשוואה לערכי HEX ישירים.
למה טוקנים סמנטיים הם הבסיס לערכת נושא בהירה
טעות אופיינית בתחילת פרויקט היא שימוש בערכי HEX קונקרטיים ישירות ברכיבים. זה עובד בהתחלה, אבל בעיצוב מחדש הראשון או בהוספת ערכת נושא כהה, זה הופך לסיוט: 200 מקומות עם #F5F5F5 שצריך לאתר ולהחליף. הקצאת צבע ישירה היא חוב טכני שמגדיל דרמטית את עלויות התחזוקה.
הגישה הנכונה היא טוקנים סמנטיים מההתחלה. שמות הטוקנים מתארים את מטרת הצבע, לא את המראה שלו:
-
background.primary— רקע מסך ראשי -
background.secondary— רקעי כרטיסים, סרגל צד -
surface.default— משטחי רכיבים -
text.primary,text.secondary,text.disabled -
accent.default,accent.pressed,accent.disabled -
border.default,border.focused
הטוקנים מאוחסנים במקור אמת יחיד — ב-iOS זה UIColor צבעים בעלי שם ב-Asset Catalog (Color Set עם וריאנט Light עכשיו, Dark מאוחר יותר). ב-SwiftUI, אנו משתמשים ב-Color("backgroundPrimary") או ב-extension Color מותאם אישית. באנדרואיד, השתמשו ב-Material Design 3 ColorScheme דרך MaterialTheme. Flutter — ThemeData עם ColorScheme מלא. חיסכון בזמן תחזוקה בגישה זו מגיע ל-70%.
| גישה | גמישות | זמן עיצוב מחדש | סיכון לשגיאות |
|---|---|---|---|
| ערכי HEX ישירים | נמוכה | 2-3 שבועות | גבוה |
| טוקנים סמנטיים | גבוהה | 2-3 ימים | נמוך |
איך לבנות נכון סולם טיפוגרפי?
הסולם הטיפוגרפי הוא חלק מערכת הנושא הבהירה. לא רק "גודל גופן", אלא מפרט מלא: משפחת גופנים, גודל, משקל, גובה שורה, ריווח אותיות לכל סגנון טקסט. סט מינימלי כולל Display / Large Title, Headline, Body, Body Small, Caption, Overline. כל סגנון צריך להיות מוגדר באובייקט יחיד — לדוגמה, Font.TextStyle ב-SwiftUI או Typography ב-Material Design.
ב-iOS, סולם הגופנים בנוי על UIFont.preferredFont(forTextStyle:) — זה Dynamic Type, שמתאים את הגודל אוטומטית להגדרות הנגישות של המשתמש. התעלמות מ-Dynamic Type פירושה שבירת האפליקציה עבור אנשים עם ליקויי ראייה וסיכון לדחייה על ידי אפל לפי הנחיות סקירת App Store, סעיף 4.2.
| רמת ניגודיות | יחס | המלצה |
|---|---|---|
| AA (טקסט רגיל) | 4.5:1 | מינימום לקריאות |
| AAA (טקסט רגיל) | 7:1 | אופטימלי לנגישות |
איך להבטיח ניגודיות במסכים שונים?
ניגודיות היא פרמטר קריטי לקריאות. WCAG AA דורש 4.5:1 לטקסט עד 18pt ו-3:1 לטקסט גדול ואלמנטים של ממשק משתמש. עבור מוצרים עם קהל רחב, אנו שואפים ל-AAA (7:1) במקום שבו אפשר בלי לפגוע בעיצוב. אנו בודקים ניגודיות בכל שלב — מאבות עיצוב ועד לבנייה הסופית.
כלי בדיקה: פלאגין Figma A11y - Color Contrast Checker, Xcode Accessibility Inspector, Android Accessibility Scanner. אנו בודקים לא רק את הטקסט הראשי אלא גם טקסט מציין מיקום בשדות (לעיתים קרובות אשם בניגודיות נמוכה), מצבים מושבתים, אייקונים וגבולות.
צללים והגבהה: ההיררכיה הבלתי נראית
במצב בהיר, צללים הם הדרך העיקרית להראות היררכיית שכבות. Material Design 3 משתמש ב-elevation + shadowColor. iOS UIKit משתמש ב-layer.shadowOffset, shadowRadius, shadowOpacity. הטעות היא שימוש באותו צל לכל הרכיבים. הכלל: 3–4 רמות של צללים, מעדין (כרטיס ברשימה) לבולט (מודאל, גיליון תחתון). המהנדסים שלנו מכוונים פרמטרי צל כך שייראו טבעיים על כל מסך ולא ייטשטשו בתנאי תאורה שונים.
טעויות נפוצות ביישום צללים:
- שימוש בצל יחיד לכל האלמנטים (היררכיה שטוחה)
- אטימות גבוהה מדי (הצל נראה מלוכלך)
- התעלמות מ-shadowColor באנדרואיד (ברירת המחדל היא שחור — עדיף לציין גוון)
מה כלול בעבודה שלנו
כשאתם מזמינים פיתוח ערכת נושא בהירה, אתם מקבלים:
- מערכת עיצוב צבעים — סט מלא של טוקנים סמנטיים עם תיעוד ודוגמאות שימוש ל-iOS (SwiftUI/UIKit), אנדרואיד (Jetpack Compose), Flutter.
- סולם טיפוגרפי עם מפרטים לכל סגנון, כולל Dynamic Type.
- הגדרת צללים עם 3–4 רמות והמלצות הגבהה.
- בדיקות ניגודיות לפי WCAG AA/AAA עם דוח.
- קבצי מקור ב-Asset Catalog / ThemeData — מוכנים לאינטגרציה.
- תיעוד על מיגרציה והוספת מצב כהה עתידי.
- תמיכה לשבועיים לאחר המסירה.
לוחות זמנים ואיך להתחיל
זמן משוער: בין יום ל-3 ימים תלוי בגודל האפליקציה ובשאלה אם כבר קיימת מערכת עיצוב. העלות מחושבת באופן אישי לאחר ניתוח הקוד הנוכחי ואבות העיצוב. אנו מבטיחים שערכת הנושא הבהירה תעבור את הבדיקות של Apple ו-Google Play ללא בעיות נגישות.
צרו קשר כדי להעריך את הפרויקט שלכם. קבלו ייעוץ על יישום טוקנים סמנטיים וסכמת צבעים עם ניגודיות — זה לוקח לא יותר משעה.