מ-UI-kit למערכת עיצוב

חווית קולנוע מקוון של אייבי

כאשר בתחילת 2017 חשבנו לראשונה על יצירת מערכת משלוח עיצוב לקוד משלנו, רבים כבר דיברו על זה וחלקם אפילו עשו זאת. עם זאת, עד היום מעט ידוע על הניסיון בבניית מערכות עיצוב חוצות פלטפורמות, ולא היו מתכונים ברורים ומוכחים המתארים טכנולוגיות ושיטות להפיכה כזו של תהליך יישום העיצוב למוצר שכבר עובד. וב"רכיבים בקוד" הם מתכוונים לעתים קרובות לדברים שונים מאוד.

בינתיים החברה הכפילה את צוות העובדים שנה אחר שנה - היה צורך להרחיב את מחלקת העיצוב ולייעל את תהליכי היצירה וההעברה של פריסות לפיתוח. אנחנו מכפילים את כל זה ב"גן החיות" של הפלטפורמות שצריך לתמוך בהן, ומקבלים מראית עין של מגפה בבלית, שפשוט לא מסוגלת "לעשות את זה כרגיל" ולהניב הכנסה. הפיתוח של פלטפורמות התנהל לרוב במקביל, וניתן היה לשחרר את אותה פונקציונליות בפלטפורמות שונות בפיגור של מספר חודשים.


ערכות פריסה נפרדות לכל פלטפורמה

באופן מסורתי, התחלנו עם בעיות שמערכת עיצוב תעזור לפתור וגיבשה דרישות לעיצוב שלה. בנוסף ליצירת שפה ויזואלית מאוחדת, הגברת מהירות הפריסה והפיתוח ושיפור איכות המוצר הכוללת, היה חיוני לאחד את העיצוב עד כמה שניתן. זה הכרחי כדי שפיתוח הפונקציונליות יתאפשר בכל הפלטפורמות שלנו בו זמנית: אינטרנט, iOS, Android, Smart TV, tvOS, Android TV, Windows 10, xBox One, PS4, Roku - מבלי לעבוד על כל אחד מהם בנפרד. ועשינו את זה!

עיצוב → נתונים

כשהושגו ההסכמות היסודיות בין מחלקות המוצר והפיתוח, התיישבנו לבחור מחסנית טכנולוגית ולבנות את הפרטים של כל התהליך - מהפריסה ועד לשחרור. כדי לבצע אוטומציה מלאה של תהליך העברת העיצוב לפיתוח, בחנו את האפשרות של ניתוח פרמטרים של רכיבים ישירות מקבצי Sketch עם פריסות. התברר שמציאת פיסות הקוד שהיינו צריכים וחילוץ הפרמטרים הדרושים לנו הייתה משימה מורכבת ומסוכנת. ראשית, מעצבים יצטרכו להיות זהירים ביותר במתן שמות לכל השכבות של קוד המקור, שנית, זה עובד רק עבור הרכיבים הפשוטים ביותר, ושלישית, תלות בטכנולוגיה של מישהו אחר ובמבנה הקוד של פריסת Sketch המקורית מסכנת את העתיד של כל פּרוֹיֶקט. החלטנו לנטוש את האוטומציה בתחום הזה. כך הופיע האדם הראשון בצוות מערכת העיצוב, שהקלט שלו הוא פריסות עיצוב, והפלט הוא נתונים המתארים את כל הפרמטרים של הרכיבים ומסודרים בצורה היררכית לפי מתודולוגיית התכנון האטומי.

הדבר היחיד שנותר לעשות הוא איפה ואיך לאחסן את הנתונים, איך להעביר אותם לפיתוח ואיך לפרש אותם בפיתוח בכל הפלטפורמות בהן אנו תומכים. הערב הפסיק להיות רופף... התוצאה של פגישות קבועות של קבוצת העבודה המורכבת ממעצבים ומובילי צוות מכל פלטפורמה הייתה ההסכמה על הדברים הבאים.

אנו מנתחים באופן ידני את הוויזואל לאלמנטים אטומיים: גופנים, צבעים, שקיפות, כניסות, עיגולים, אייקונים, תמונות ומשכי זמן לאנימציות. ואנחנו אוספים מזה כפתורים, תשומות, תיבות סימון, ווידג'טים של כרטיסי בנק וכו'. אנו מקצים שמות לא סמנטיים לסגנונות של כל אחת מהרמות, למעט סמלים, למשל, שמות ערים, שמות נימפות, פוקימון, מכונית מותגים... יש רק תנאי אחד - אסור למצות את הרשימה לפני , איך הסגנונות מסתיימים - ההצגה חייבת ללכת! אתה לא צריך להיסחף עם סמנטיקה, כדי שלא תצטרך להוסיף כפתור אמצעי בין "קטן" ל"בינוני", למשל.

שפה ויזואלית

למפתחים נותר לחשוב כיצד לאחסן ולהעביר נתונים בצורה שתתאים לכל הפלטפורמות, והעיצוב היה צריך לעצב רכיבי ממשק שיוכלו להיראות טוב ולעבוד ביעילות על פני כל צי המכשירים הנתמכים.

בעבר כבר הספקנו "לבדוק" את רוב מרכיבי העיצוב באפליקציה לווינדוס 10, שבאותה תקופה הייתה פלטפורמה חדשה עבורנו, כלומר דרשה רינדור ופיתוח "מאפס". על ידי ציור זה, הצלחנו להכין ולבדוק את רוב הרכיבים ולהבין אילו מהם אמורים להיכלל במערכת העיצוב העתידית של Eevee. ללא ארגז חול כזה, ניסיון כזה יכול להתקבל רק באמצעות מספר רב של איטרציות על פלטפורמות שכבר עובדות, וזה ייקח יותר משנה.

שימוש חוזר באותם רכיבים בפלטפורמות שונות מצמצם את מספר הפריסות ואת מערך הנתונים של מערכת העיצוב באופן משמעותי, כך שהתכנון נאלץ לפתור בעיה אחת נוספת, שלא תוארה בעבר בפרקטיקות של עיצוב ופיתוח מוצר - איך, למשל, האם ניתן לעשות שימוש חוזר בלחצן לטלפונים וטאבלטים בטלוויזיות? ומה עלינו לעשות עם גדלים של גופנים ואלמנטים בפלטפורמות שונות כל כך?

ברור שהיה צורך לעצב רשת מודולרית חוצת פלטפורמות שתגדיר את גדלי הטקסט והאלמנטים הדרושים לנו עבור כל פלטפורמה ספציפית. כנקודת מוצא לרשת, בחרנו את גודל ומספר כרזות הסרטים שנרצה לראות על מסך מסוים ועל בסיס זה גיבשנו כלל לבניית עמודות רשת בתנאי שרוחב עמודה אחת שווה לרוחב הכרזה.

כעת עלינו להביא את כל המסכים הגדולים לאותו גודל פריסה ולהתאים אותם לרשת משותפת. Apple TV ו-Roku מעוצבים בגודל של 1920x1080, אנדרואיד TV - 960x540, טלוויזיות חכמות, תלוי בספק, זהות, אבל לפעמים 1280x720. כאשר האפליקציה מוצגת ומוצגת במסכי Full HD, 960 מוכפל ב-2, 1280 מוכפל ב-1,33 ו-1920 מופק כפי שהוא.

בדילוג על פרטים משעממים, הגענו למסקנה שבאופן כללי כל המסכים, כולל מסכי הטלוויזיה, מבחינת אלמנטים וגדלים שלהם, מכוסים בפריסה עיצובית אחת, וכל מסכי הטלוויזיה הם מקרה מיוחד של הרשת הכללית בין הפלטפורמות, ומורכבים מחמש או שש עמודות, כמו טאבלט או שולחן עבודה ממוצעים. מי שמעוניין בפרטים שיכנס להערות.

ממשק משתמש יחיד לכל הפלטפורמות

כעת, כדי לצייר תכונה חדשה, איננו צריכים לצייר פריסות עבור כל פלטפורמה, בתוספת אפשרויות הסתגלות עבור כל אחת מהן. זה מספיק כדי להציג פריסה אחת ויכולת ההתאמה שלה לכל הפלטפורמות והמכשירים בכל רוחב: טלפונים - 320-599, כל השאר - 600-1280.

נתונים → פיתוח

כמובן, ככל שנרצה להשיג עיצוב אחיד לחלוטין, לכל פלטפורמה יש תכונות ייחודיות משלה. למרות שגם האינטרנט וגם הטלוויזיה החכמה משתמשים בערימת ReactJS + TypeScript, אפליקציית Smart TV פועלת על לקוחות WebKit ו-Presto מדור קודם ולכן אינה יכולה לשתף סגנונות עם האינטרנט. ועלוני דוא"ל נאלצים לחלוטין לעבוד עם פריסת טבלאות. יחד עם זאת, אף אחת מהפלטפורמות שאינן HTML משתמשות או מתכננות להשתמש ב-React Native או באף אחד מהאנלוגים שלה, מחשש לירידה בביצועים, מכיוון שיש לנו יותר מדי פריסות מותאמות אישית, אוספים עם היגיון עדכון מורכב, תמונות וסרטונים. לכן, הסכימה הנפוצה של אספקת סגנונות CSS מוכנים או רכיבי React אינה מתאימה לנו. לכן, החלטנו להעביר נתונים בפורמט JSON, המתארים את הערכים בצורה הצהרתית מופשטת.

אז רכוש rounding: 8 אפליקציית Windows 10 הופכת ל CornerRadius="8", אינטרנט - border-radius: 8px, אנדרואיד - android:radius="8dp", iOS - self.layer.cornerRadius = 8.0.
תכונה offsetTop: 12 אותו לקוח אינטרנט במקרים שונים יכול לפרש כ top, margin-top, padding-top או transform

ההצהרה של התיאור מרמזת גם שאם הפלטפורמה מבחינה טכנית לא יכולה להשתמש בנכס או בערך שלו, היא יכולה להתעלם ממנו. מבחינת טרמינולוגיה, עשינו מעין שפת אספרנטו: חלקן נלקחו מאנדרואיד, חלקן מ-SVG, חלקן מ-CSS.

אם בפלטפורמה מסוימת אתה צריך להציג אלמנטים אחרת, הטמענו את היכולת להעביר את יצירת הנתונים התואם בצורה של קובץ JSON נפרד. לדוגמה, מצב "בפוקוס" עבור Smart TV מכתיב שינוי במיקום הטקסט מתחת לפוסטר, מה שאומר שעבור פלטפורמה זו רכיב זה בערך של המאפיין "indent" יכיל את 8 נקודות ההזחה הדרושות לו. למרות שזה מסבך את התשתית של מערכת העיצוב, זה נותן מידה נוספת של חופש, ומותיר לנו את האפשרות לנהל את ה"שוני" החזותי של הפלטפורמות בעצמנו, ולא להיות בני ערובה לארכיטקטורה שיצרנו.

פיקטוגרמות

איקונוגרפיה במוצר דיגיטלי היא תמיד תת-פרויקט רחב היקף ולא הפשוט ביותר, הדורש לעתים קרובות מעצב נפרד. תמיד יש הרבה גליפים, לכל אחד מהם יש כמה גדלים וצבעים, ופלטפורמות בדרך כלל זקוקות להם בפורמטים שונים. באופן כללי, לא הייתה סיבה לא להכניס את כל זה למערכת העיצוב.

גליפים נטענים בפורמט וקטור SVG, וערכי צבע מוחלפים אוטומטית במשתנים. אפליקציות לקוח יכולות לקבל אותן מוכנות לשימוש - בכל פורמט וצבע.

תצוגה מקדימה

בנוסף לנתוני ה-JSON, כתבנו כלי לתצוגה מקדימה של רכיבים – אפליקציית JS שמעבירה נתוני JSON תוך כדי תנועה דרך מחוללי הסימון והסגנון שלה, ומציגה וריאציות שונות של כל רכיב בדפדפן. בעיקרו של דבר, תצוגה מקדימה היא בדיוק אותו לקוח כמו יישומי פלטפורמה ועובדת עם אותם נתונים.

הדרך הקלה ביותר להבין כיצד פועל רכיב מסוים היא באמצעות אינטראקציה איתו. לכן לא השתמשנו בכלים כמו Storybook אלא עשינו תצוגה מקדימה אינטראקטיבית - אפשר לגעת, הצבע, ללחוץ... כשמוסיפים רכיב חדש למערכת העיצוב, הוא מופיע בתצוגה המקדימה כך שלפלטפורמות יש במה להתמקד כאשר ליישם אותו.

רשומות

בהתבסס על הנתונים המסופקים לפלטפורמות בצורה של JSON, תיעוד עבור הרכיבים נוצר באופן אוטומטי. מתוארת רשימה של מאפיינים וסוגי ערכים אפשריים בכל אחד מהם. לאחר היצירה האוטומטית, ניתן להבהיר את המידע באופן ידני ולהוסיף תיאור טקסט. התצוגה המקדימה והתיעוד מוצלבים זה לזה ברמת כל רכיב, וכל המידע הכלול בתיעוד זמין למפתחים בצורה של קבצי JSON נוספים.

מבטל

הכרח נוסף היה היכולת להחליף ולעדכן רכיבים קיימים לאורך זמן. מערכת העיצוב למדה לומר למפתחים באילו מאפיינים או אפילו רכיבים שלמים לא ניתן להשתמש ולהסיר אותם ברגע שהם אינם בשימוש יותר בכל הפלטפורמות. יש עדיין הרבה עבודה "ידנית" בתהליך הזה, אבל אנחנו לא עומדים במקום.

פיתוח לקוח

ללא ספק, השלב המורכב ביותר היה הפרשנות של נתוני מערכת התכנון בקוד של כל הפלטפורמות בהן אנו תומכים. אם, למשל, רשתות מודולריות באינטרנט הן לא משהו חדש, אז מפתחי אפליקציות מובייל מקוריות עבור iOS ואנדרואיד עבדו קשה לפני שהבינו איך לחיות עם זה.

לפריסת מסכי יישומי iOS, אנו משתמשים בשני מנגנונים בסיסיים המסופקים על ידי iviUIKit: פריסה חופשית של אלמנטים ופריסה של אוספי אלמנטים. אנו משתמשים ב-VIPER, וכל האינטראקציה עם iviUIKit מרוכזת ב-View, ורוב האינטראקציה עם Apple UIKit מרוכזת ב-iviUIKit. הגדלים והסידור של האלמנטים מוגדרים במונחים של עמודות ומבנים תחביריים שפועלים על גבי אילוצי ה-SDK המקוריים של iOS, מה שהופך אותם למעשיים יותר. זה פשט את חיינו במיוחד כאשר עובדים עם UICollectionView. כתבנו מספר עטיפות מותאמות אישית לפריסות, כולל מורכבות למדי. היה מינימום של קוד לקוח וזה הפך הצהרתי.

כדי ליצור סגנונות בפרויקט אנדרואיד, אנו משתמשים ב-Gradle, והופכים את נתוני מערכת העיצוב לסגנונות בפורמט XML. במקביל, יש לנו מספר גנרטורים ברמות שונות:

• בסיסי. הנתונים של פרימיטיביים עבור מחוללים ברמה גבוהה יותר מנותחים.
• מַשׁאָב. הורד תמונות, אייקונים וגרפיקה אחרת.
• רְכִיב. הם נכתבים עבור כל רכיב, המתאר אילו מאפיינים וכיצד לתרגם אותם לסגנונות.

שחרור יישומים

לאחר שהמעצבים ציירו רכיב חדש או עיצבו מחדש רכיב קיים, שינויים אלו מוזנים למערכת העיצוב. המפתחים של כל פלטפורמה מכווננים את יצירת הקוד שלהם כדי לתמוך בשינויים. לאחר מכן, ניתן להשתמש בו ביישום פונקציונליות חדשה כאשר יש צורך ברכיב זה. לפיכך, אינטראקציה עם מערכת התכנון אינה מתרחשת בזמן אמת, אלא רק בזמן הרכבת מהדורות חדשות. גישה זו גם מאפשרת שליטה טובה יותר על תהליך העברת הנתונים ומבטיחה פונקציונליות קוד בפרויקטי פיתוח של לקוחות.

תוצאות של

חלפה שנה מאז שמערכת העיצוב הפכה לחלק מהתשתית התומכת בפיתוח הקולנוע המקוון אייבי, וכבר אפשר להסיק כמה מסקנות:

• מדובר בפרויקט גדול ומורכב הדורש משאבים ייעודיים קבועים.
• זה איפשר לנו ליצור שפה ויזואלית חוצת פלטפורמות ייחודית משלנו העונה על המטרות של שירות הווידאו המקוון.
• אין לנו עוד פלטפורמות בפיגור מבחינה ויזואלית ופונקציונלית.

תצוגה מקדימה של רכיבי מערכת עיצוב Ivy - design.ivi.ru

מקור: www.habr.com