חוסר אחידות באייקונים של אפליקציית מובייל: היכן הממשק נשבר
אייקונים של אפליקציית מובייל לעיתים נדירות נכנסים לתוכנית השחרור כמשימה נפרדת — מכינים אותם בשבוע האחרון, בין הבנייה לשליחה לבדיקה.
המעצב מוסר את הסמלים כסט אחד, המפתח משבץ אותם כפי שהם, ובאפליקציה מופיע חוסר אחידות גרפי: חלק מהסמלים חתוכים בשוליים, חלקם מתוכננים לנושא בהיר ונעלמים בנושא כהה, וחלקם נמתחים לפרופורציות של פלטפורמה זרה.
בהמשך מצטרפת אי-התאמה של הממשק בין הפלטפורמות. אותו סמל ב-iOS וב-Android מצויר לפי מסכות שונות: במערכת אחת הוא מוכנס לעיגול, בשנייה — לריבוע עם עיגול פינות.
אם הסט הוכן עבור פלטפורמה אחת והועבר כמו שהוא לשנייה, מחצית מהסמלים מאבדים שוליים, ופרטים קטנים מיטשטשים לכתם על המסך בפועל.
המחיר של אי-התאמה כזו — החזרת הבנייה מהבדיקה. כללי העיצוב ב-Apple Human Interface Guidelines וב-Material Design מתארים שוליים, רשת והתנהגות של סמל בנושא כהה; אם הסט אינו עומד בהם, מחזירים את הבנייה, והתיקון נתקל בבנייה חדשה ובתור חוזר למודרציה. בשחרור לשתי המערכות המחזור עובר פעמיים.
כאב נפרד — תיקוני אייקונים אחרי השחרור. אי אפשר להחליף סמל בודד בחנות: הוא תפור לתוך הבנייה, ולכן התיקון ממתין לשחרור הבא ועובר שוב מחזור בדיקה מלא. שגיאה בגרפיקה שנראית על המסך הראשון צריכה להיסבל במשך שבועות.
נבחן כיצד סוגרים את זה: כיצד ממקור אחד נבנים סטים תקינים לשתי הפלטפורמות, לנושא בהיר וכהה, ומדוע אז התיקונים מפסיקים להיות חירום.
מה נותן סט גרפי אחיד: מהירות בנייה ופחות תיקונים
מקור גרפי אחיד במקום איחוד ידני של גרסאות
אייקונים חיים כספריית רכיבים ב-Figma: מאסטר אחד לכל גליף, ציור וקטורי, יישור לרשת פיקסלים. המסך נבנה מהפניות למאסטר, ולא מעותקים של קבצים, ולכן תיקון של אייקון מתפשט לכל הפריסות בבת אחת — איחוד ידני של גרסאות בין מסכים ופלטפורמות יוצא מהתהליך.
מקור גרפי אחיד חוסך זמן לא ברגע הציור, אלא בכל מסך עוקב: פריסה חדשה נבנית מסמלים מוכנים, ולא מצוירת מחדש. שיעור הפריסות שחוזרות לתיקון בגלל אי-התאמות בין מסכים יורד — התיקונים הופכים ממוקדים, ולא גוררים שרשרת.
מערכת סמלים משותפת מסירה סוג שלם של שגיאות
צפיפויות מסך וגדלים של אייקונים מיוצאים ממאסטר אחד, ולכן לא נוצרים עובי קו „זזים” ומסה אופטית שונה בין פלטפורמות. מצבים — פעיל, לא פעיל, לחוץ — מתוארים כווריאציות של רכיב, ולא כסטים נפרדים של קבצים: המפתח לא מרכיב את האייקון מחלקים ולא מנחש מרווחים בזמן הפריסה.
מהירות הפקת המסכים עולה בזכות גדלים צפויים ונקודות עיגון שהפריסה נשענת עליהן. העקביות של הגרפיקה מפסיקה להיות תלויה במי שצייר את המסך הספציפי — אדם חדש בצוות מתחבר למערכת מוכנה, ולא משחזר אותה מקבצים מפוזרים.
אפשרויות אספקה של הסט: ערכות נפרדות או מקור אחיד
אפשר לספק סט אייקונים בדרכים שונות, והבחירה משפיעה על האופן שבו תיקונים מגיעים לשחרור. ערכות נפרדות ל-iOS ול-Android חיות באופן בלתי תלוי, מקור אחיד נבנה לפורמטים של שתי הפלטפורמות מאותם מקורות, וביניהם יש מסלול היברידי עם ליטוש ידני.
ערכות נפרדות ל-iOS ול-Android
כל פלטפורמה מקבלת סט משלה של קבצים רסטריים ווקטוריים, וקובץ המאסטר נמצא לצידם. כך נוהגים כאשר דרישות הפלטפורמות נבדלות בצורת הסימן, והציור המשותף היה ממילא צריך להתפצל. המגבלה צפויה: תיקון חוזר בכל ערכה, אי-ההתאמות מצטברות וצפות בבדיקה לפני הפרסום.
מקור אחיד ובנייה לפלטפורמות
מקורות וקטוריים נשמרים כסט אחד, שממנו הבנייה מפרקת גדלים, צפיפויות ופורמטים לכל פלטפורמה. תיקון במקור מתפשט לכל הסט בבת אחת, והיסטוריית השינויים נשמרת במערכת בקרת גרסאות. ההתאמה הפלטפורמית של הגרפיקה נעשית כאן בפרמטרים של הבנייה, ולא ידנית — זו המגבלה העיקרית של האפשרות הזו.
מסלול היברידי עם ליטוש ידני
מקור משותף אחראי על הצורה והצבע הבסיסיים, וסימנים בודדים מלוטשים ידנית עבור הפלטפורמה ונשמרים כדריסות. מתאים כאשר רוב הסט משותף, אך כמה אייקונים דורשים אופטיקה אישית.
| אפשרות אספקת הגרפיקה | מתי מתאים | מגבלות |
|---|---|---|
| ערכות נפרדות | דרישות הפלטפורמות נבדלות בצורת הסימן | תיקונים משוכפלים, גרסאות מתפצלות זו מזו |
| מקור אחיד עם בנייה | רוב הסימנים משותפים, שחרורים תכופים | ההתאמה הפלטפורמית מוגבלת לפרמטרים של הבנייה |
| היברידי עם ליטוש ידני | בסיס משותף בתוספת סימנים בודדים לפלטפורמה | נדרש סדר בדריסות, אחרת נוצר חוסר סנכרון |
כיצד אנחנו מרכיבים ומטמיעים אייקונים: שלבי העבודה
סט אייקונים נשבר לא בשלב הציור, אלא בהטמעה: קבצים מגיעים עם שמות שונים, חלק מהפורמטים לא נקלטים בבנייה, ועל מסך אמיתי האייקון נופל בקונטרסט בנושא כהה. אנחנו מנהלים את העבודה הזו כתהליך הנדסי עם נקודות בקרה קבועות — מהקטלוג של הגרפיקה ועד לקבלת הסט.
כיצד בנויים שלבי ההטמעה של סט האייקונים
- קטלוג הגרפיקה. מפרקים את ספריות המשאבים הקיימות ואת החומרים בחנויות האפליקציות: מאתרים כפילויות, גרסאות מיושנות וגרפיקה שצוירה עבור מסך מסוים. בתוצר — מרשם אייקונים שמציין היכן כל אחד מיושם.
- סכמת שמות לקבצים. לפני הבנייה מקבעים את מבנה הספריות ואת כללי השמות: השם משקף את הייעוד, הגודל והנושא, ולא את המחבר. זה מסיר שינוי שמות ידני בשחרור הבא.
- בניית הערכות. מכינים מקורות וקטוריים וסטים רסטריים נגזרים למצבי התצוגה הנדרשים, ובנפרד — וריאציות לנושא כהה, למצב נבחר ולחלונות הראווה של החנויות.
- בדיקה על מסכים אמיתיים. מריצים את הסט על מכשירים חיים ובאמולטורים: בודקים קריאוּת באלכסון קטן וגדול, התנהגות בנושא כהה, ויישור לרשת.
- קבלת הסט. משווים את התוצאה למרשם: הכול במקום, השמות תואמים, אין קבצים מיותרים. אי-התאמות סוגרים לפני המסירה.
- מסירה והדרכה. מוסרים מקורות, ספריית משאבים, מרשם וכללי שמות, ומראים לצוות הלקוח כיצד להוסיף אייקון חדש בלי לפגוע במבנה.
מה נשאר בצד הלקוח
הערכה מתחברת לפרויקט בלי תיקון שמות ידני, והמרשם וכללי השמות ממשיכים לעבוד כתקן פנימי. אייקון חדש מתווסף בשלב אחד — בלי לפרק שכבות של אחרים ובלי לבנות מחדש את כל הסט.
מה אנחנו מוסרים לידיים: מקורות, כללי עיצוב ותקנון
להרכיב אייקון — זה חצי מהעבודה. החצי השני הוא שכעבור חצי שנה מדור חדש באפליקציה לא ידרוש לצייר מחדש את כל הסט, ושהבנייה לכל פלטפורמה לא תהיה תלויה בזיכרון של מישהו לגבי הגדלים הנדרשים.
לכן את הסט אנחנו מוסרים לא כתמונות בתוצר, אלא כערכה עובדת: מקורות, כללים ותקנון שלפיו אפשר להרחיב אותו בלעדינו.
מה נכלל בערכה
- מקורות עובדים — קבצים וקטוריים עם שכבות מפורקות, סמלים נפרדים ומאסטרים: תיקון של צורה אחת מתפשט לכל הסט, ולא לעשרה עותקים.
- ערכות בנויות לפלטפורמות — סטים מוכנים בפורמטים ובגדלים הנדרשים, עם שקיפות תקינה וללא ליטוש ידני בצד הפיתוח.
- כללי עיצוב הגרפיקה — רשת ומרווחים, עובי קווים, רדיוסים, התנהגות של פרטים קטנים בגדלים מינימליים.
- כללי שמות — סכמת שמות אחידה לקבצים ולסמלים, כדי שאלמנט יימצא בחיפוש ולא במעבר על תיקיות.
- תיעוד לסט — מדריך קצר: היכן נמצא, כיצד לבנות, מה לעשות כשיש אי-התאמה בין גרסאות.
כללים וסדר עבודה
- תיאור הרשאות גישה למאגר הגרפיקה — בעלים, עורכים, קוראים והסדר להענקת הרשאות לאדם חדש.
- תקנון עדכון הסט — כיצד מתווסף סמל חדש, מי מאשר, באילו לוחות זמנים וכיצד נקבעת גרסה.
ערכה כזו סוגרת תרחיש טיפוסי: הסט חי ומתרחב בתוך הצוות שלכם, ואנחנו נשארים זמינים לסיוע — למשל כשמספר הסמלים גדל עד כדי צורך בעיצוב מחדש של כל המערכת.
מקרה בוחן: מקור גרפי אחיד הסיר אי-התאמות בין הפלטפורמות
המצב לפני
הלקוח הביא גרפיקה כייצוא מהפריסות: כל סמל בשלושה גדלים, חלק כרסטר, חלק כקונטור, ועובי הקו ועיגול הפינות הוגדרו ידנית בנפרד לכל פלטפורמה. סמל חדש צויר פעמיים, קבצים חוברו לפי שמות, ועד סוף מחזור השחרור הצטברו 8-12 תיקונים — הרשת, הגודל האופטי והצבע של המצב הפעיל התפצלו.
מה שינינו ומה יצא
הרכבנו סט מאסטר ב-Figma כמקור אחיד: הרשת, קווי המפתח, עובי הקו והגדלים הוצאו למשתנים, והייצוא לפורמטים וקטוריים נעשה בפקודה אחת. האייקון הפך לרכיב עם וריאציות של מצבים, ולכן סמל חדש נבנה מחלקים מוכנים ולא מצויר מחדש.
שיעור אי-ההתאמות בין הפלטפורמות ירד משליש מהסט לאפס — אי-ההתאמות נתפסות בבדיקה אוטומטית בזמן הבנייה, ולא על ידי הלקוח בקבלה. הזמן להוספת סמל חדש הצטמצם מכמה שעות ל-20-30 דקות יחד עם הייצוא והחיבור לשני הפרויקטים. מספר התיקונים במחזור שחרור — מ-8-12 לאחד-שניים, וגם אלה נוגעים למשמעות האייקון ולא לגיאומטריה שלו.
תגובת הלקוח: „הפסקנו להתווכח איזה קובץ הוא המעודכן” — סט האייקונים מתעדכן ממקום אחד, ושתי הפלטפורמות מקבלות תוצאה זהה.
במה נבדלת ההתאמה של גרפיקה ל-iOS מזו של Android?
ההבדל מתחיל במי שבבעלותו הצורה. ב-iOS המערכת עצמה מחילה מסכה עם עיגול פינות, ולכן המעצב מוסר ריבוע מלא, והפינות נחתכות כבר במכשיר — אסור שתהיה שקיפות במקור, הרקע הוא חלק מהאייקון.
ב-Android משתמשים בסכמה דו-שכבתית: הרקע והסמל מונחים בנפרד, והצורה נקבעת על ידי מעטפת המכשיר ויכולה להשתנות מעיגול לריבוע עם עיגול פינות, תוך הוספת הטיה בסיבוב המסך.
אי-ההתאמה המרכזית — באזורים הבטוחים. ב-Android הסמל חייב להיכנס לעיגול הפנימי, שהוא קטן במידה ניכרת מהקנבס: הטבעת הנותרת נכנסת תחת המסכה והפרלקסה. ב-iOS המסכה חותכת הרבה פחות, ולכן אותו ציור בדיוק, שנדחס היטב לאזור האנדרואידי, נראה ב-iOS קטן ואבוד. מכאן נובעת גם גרסה נפרדת לפלטפורמה — השאלה אינה של טעם, אלא של גיאומטריה.
השכבה השנייה — המשקל האופטי של הסמל. ב-iOS האייקון מונח לרוב על מצע בצבע אחיד, וקווים דקים עליו מאבדים קונטרסט; ב-Android הסמל מחליק מעל רקע נע, ואותם קווים מתפרקים בזמן ההטיה.
את עובי הקווים הסטנדרטיים צריך להפריד: בפלטפורמה אחת אנחנו מעבים את הקו, בשנייה מרפים אותו, ומהדקים את הקומפוזיציה למרכז.
קובץ משותף אחד עובד היכן שהסימן פשוט, ממורכז, עם מרווח בשוליים, על רקע שקט בלי גרדיאנטים ובלי אלמנטים בגבול האזור הבטוח.
גרסה נפרדת נדרשת אם הצללית נשענת על צורת הפינות, יש פרטים קטנים, רקע מורכב, או שנדרשת תמיכה בנושא כהה ובמצב מונוכרום — שם המסכה והצביעה מחדש שוברים את הכוונה המקורית.
לפני המסירה אנחנו מחילים את הפריסות על המסכות האמיתיות של הפלטפורמות, מריצים בדיקת קונטרסט על רקע בהיר וכהה, ומסתכלים על האייקון בגודל קטן, שבו בדיוק מתגלה אי-ההתאמה במשקל. זו הבדיקה של עמידה בדרישות הפלטפורמות לגרפיקה — לפני שהאפליקציה יוצאת לפרסום.
ספקות טכניים נפוצים: שינוי קנה מידה, רקע, עדכון
גרפיקה היא החלק בשחרור שבו תיקונים אחרי היציאה עולים ביוקר רב ביותר, ולכן מוטב לסגור שאלות לגביה מראש. להלן הנפוצות ביותר: עדכון הסט במוצר שכבר פורסם, ציור מחדש חלקי, אי-התאמה בין הערכות בזמן סנכרון, מקורות שאבדו ועבודה מרחוק עם צוות הלקוח.
האפליקציה כבר יצאה לאור, וסט האייקונים מיושן. אפשר לעדכן רק את הגרפיקה?
כן. אנחנו מרכיבים ערכה חדשה עבור העיצוב הנוכחי, מתאמים גדלים לבקרה ומוסרים אותה כחבילה נפרדת — שאר קוד השחרור לא נפגע. חשוב רק להשוות את הצללית לגרסה שכבר פורסמה, כדי שהזיהוי לא יאבד.
צריך לצייר מחדש אייקון אחד מהסט — נצטרך לעשות הכול מהתחלה?
לא. אם קובצי המאסטר עם השכבות נשמרו, מתקנים רק את הסמל הנדרש, והאחרים נשארים ללא שינוי. אנחנו מסנכרנים אותו עם הרשת המשותפת ועם המשקל האופטי של שכניו, אחרת אלמנט אחד מתחיל „ליפול” מהשורה.
מה לעשות אם הערכות לפלטפורמות שונות מתפצלות בזמן העדכון?
אנחנו מחזיקים קובץ מאסטר אחיד, שממנו נוצרים שני הסטים, ולכן אי-ההתאמה נשללת מעצם המבנה. בנפרד מוגדרים כללי שינוי קנה המידה והמצע: כיצד הסימן מתנהג על רקע בהיר וכהה ומה נכנס לגדלים המערכתיים.
המקורות אבדו. אפשר לשחזר את הסט?
אפשר. אנחנו מציירים את הסמל מחדש באופן וקטורי לפי אמת מידה רסטרית ובונים מחדש את המבנה השכבתי, כשבודקים את התוצאה לפי גדלים לבקרה. בתוצר הלקוח מקבל קבצים ניתנים לעריכה, ולא רק תמונות מוכנות.
הצוות שלנו עובד מרחוק. כיצד מתנהל התיאום?
מתאמים לפי דפי בקרה: מציגים את אותו סימן בכמה גדלים ועל מצעים שונים, כדי שההחלטות יתקבלו לפי המצב בפועל ולא לפי הגדלה. התיקונים מתועדים בארכיון משותף, ולכן לשני הצדדים תמיד יש גרסה מעודכנת.
נדון במשימה ונחזור עם תוכנית: הרכב, לוחות זמנים, סדר עבודה
כדי שהשיחה תהיה עניינית, לפגישה הראשונה מספיק לאסוף מינימום של נתוני פתיחה: אנחנו מסתכלים על הסט הנוכחי, משווים אותו לדרישות חנויות האפליקציות וחוזרים עם הערכה ותוכנית עבודה לגרפיקה. להלן מה כדאי להכין, כדי לדון במשימה ישר לעניין ולא לבזבז סבבים על הבהרות.
- פלטפורמות וכיסוי: iOS, Android, טאבלטים, שעונים וגרסאות לבישות — מכך תלוי מספר הגדלים, סט מסכות עיגול הפינות והרכב האספקה.
- מקורות נוכחיים: קובצי מאסטר וקטוריים, שכבות, גופנים, פלטה. אם אין קובץ מאסטר, מתכננים שחזור גיאומטריה לפי רסטר.
- דוגמאות למסכים בעייתיים: היכן האייקון נעלם בנושא כהה, מתמזג עם סרגל ה-dock או נחתך במסכה עגולה.
- דרישות הבדיקה: רקע אטום, שולי בטיחות, עיגול פינות תקין — האוטומציה של החנות דוחה בנייה אם הסט לא עובר בדיקה.
- נקודות תיאום: מי מקבל החלטה בנוגע לגרפיקה, מי מאשר את הסט הסופי ובאילו תאריכים זה קורה.
- סדר מסירת הסט: מאגר או ארכיון, פורמטים של קובצי מאסטר וייצוא, זכויות שימוש, וכיצד להכניס תיקונים אחרי השחרור.
- תאריכי שחרור הבנייה: מהם אנחנו מחשבים את תוכנית העבודה לגרפיקה ואת לוחות הזמנים לתיאום.
אם חלק מהסעיפים עדיין לא נאספו — זה לא חוסם את השיחה: לפי תיאור המוצר נעזור לקבוע מה לבקש מהמעצב או מהקבלן שעשה את הסט קודם. תארו את המשימה — ונחזור עם הערכה, הרכב אספקה וסדר עבודה.