בואו נדבר על הפער שיש בין העיצוב ל-UI הסופי. טוב, אולי פער זו מילה קצת קיצונית ואפשר לומר הבדל. כי תמיד יהיו הבדלים בין הרצוי למצוי: גם אם המצוי הוא תוצאה מדויקת כמעט ב-100%, תמיד יהיה שוני.
פעם דיברנו על pixel prefect, אבל היום כבר קשה לשייך את ההגדרה הזאת למשהו ממשי, לאור העובדה שהאתרים שנבנים הינם רספונסיביים, ואי אפשר לעצב מסך לכל שבריר רזולוציה.
יש מעצבים בקהל? השורה הזאת היא בשבילכם: כמה פעמים העברתם עיצוב לצוות ה-front-end והרגשתם ככה:
בעיניים בלתי מזויינות של מפתחי front-end, התוצאה שמועברת ל VQA (בדיקת איכות של יישום העיצוב) משביעת רצון. אז איך זה שלפעמים התוצאה מזכירה קצת את הסיטואציה שלמעלה בתמונה?
זכיתי להיות בכל אחד משני מצידי המתרס, ולכן אני מרגישה הזדהות גם עם העיצוב וגם עם היישום שלו. במהלך פרויקט שאני עובדת עליו לאחרונה עלו לי כמה תובנות על הבדלים בין פוטושופ (או אדובי XD או כל כלי עיצוב אחר, מחריגה את סקץ' כי איתו לצערי לא עבדתי מעולם) לבין הדפדפן. בפוסט הזה ניסיתי לרכז אותם לכמה נקודות שיכולות להיטיב עם הקשר בין העיצוב והיישום שלו. בואו נתחיל:
סטטי VS דינאמי
כמעט כל פלטפורמות העיצוב הן סטטיות, אבל דף אינטרנט הוא דינמי. נכון, יש פלטרפורמות שתומכות ב"לוחות" שמאפשרים עיצוב מקביל לרזולוציות השונות (בגדול – מובייל, טאבלט ודסקטופ אחד או שניים) אבל צריך לזכור שגם במעבר בין 320 פיקסלים של נייד הכי קטן לבין 414 פיקסלים של ניידים גדולים יותר יש התרחבות. נכון שלא צריך לעצב מצב לכל פיקסל, אבל צריך להביא בחשבון את השינויים. כמו למשל, מה קורה כשמשתמש מסובב את הטלפון הנייד שלו ומסתכל על האתר לרוחב? במצב הזה אנחנו מגיעים כבר ל-560 או אפילו ל-640 פיקסלים. הרבה פעמים את הפער הזה במידע ימלא מי שכותב את ה-CSS, ולא תמיד זה בול מה שהתכוונו בעיצוב, אם בכלל חשבו על המקרה הזה…
עוד דוגמה לפער בין הסטטי והדינמי היא למשל עיצוב של חלונות פופ-אפ שהם סוג של wizard. אם מעצבים כל אחד מהם בנפרד, אז הכל טוב. אבל אם יש תהליך, לא תמיד החלונות באותו גובה (נניח שנקבע מראש רוחב קבוע…) ואז כשהאתר עובד וה-wizard מתפקד, פתאום רואים את הקפיצה בגובה, או אפילו במיקום (אם חלון הפופאפ מתמרכז ביחס למסך למשל) וצריך לשבת ולהחליט מה עושים ומה ההתנהגות או הפתרון הרצויים.
אז מה אפשר לעשות כדי לגשר על הפער הזה?
בגדול, הנסיון אופה את ההבדל. בקטן – הכי טוב לדבר עם מי שעיצב.ה את האתר ולקבל החלטות משותפות. למשל ברמה הטכנית, כדאי כמה שפחות להגדיר רוחב סטטי לאלמנטים ובמקום זה לתת גדלים דינמיים, או להשתמש בערכים יחסיים של פלקס או ב-fractions של גריד.
גריד שמונת הפיקסלים
או בשמו הסקסי והמדוייק יותר באנגלית The 8-Point Grid System. מה זה? על קצה המזלג – שיטה של עיצוב שבעצם שואפת להשתמש בערכים שמתחלקים בשמונה (או ארבע, אם הולכים על חיתוכים קטנים יותר), מתוך הבנה שזה הכי נכון והכי זורם במסכי אינטרנט. מה שזה אומר בפועל זה שכל האלמנטים יהיו בכפולות של 8. ממליצה שלא להסתמך על התקצירון שלי ולקרוא קצת יותר לעומק (בעיקר את השניים הראשונים):
- Intro to The 8-Point Grid System
- 8-Point Grid: Borders And Layouts
- Responsive Vertical Rhythm with CSS Custom Properties and CSS Calc
- Why is Vertical Rhythm an Important Typography Practice?
כשקראתי את הפוסטים ואת השיטה התלהבתי מאוד, וכשב-investing.com אמרו בעיצוב שהולכים על השיטה הזאת – ממש שמחתי. אבל אז עלו כמה עניינים…
מי מגדיר גובה לאלמנט?!
קצת על גובה ורוחב של אתר: לכל אתר יש רוחב קבוע. מזתומרת קבוע? יש את המקסימום רוחב של המסך. לפי הרוחב של המסך אנחנו יכולים לשנות את המראה של האתר וזאת על ידי מדיה קוורי.
ומה לגבי גובה? בעיקרון, אין גובה קבוע, והתוכן הוא שקובע את הגובה של העמוד. מה עם להגביל גובה? עדיף שלא, כי אנחנו בונים על דינמיות, ואם נגביל גובה – העיצוב יישבר. בשביל מה אני מספרת לכם את כל זה? כי משהו בשיטה של ה-8 פיקסלים לא זרם לי. למה? כי פוטושופ זה לא ווב.
במאמר 8-Point Grid: Borders And Layouts מדברים על דרכים שונות לחישוב רוחב של כפתור עם ובלי בורדר:
עד כאן הכל טוב, אבל מה קורה אם באלמנט מסוים חשובים הרוחב או הגובה? כשאנחנו מתרגמים את האלמנט ל-HTML ו-CSS לא תמיד הכל יושב בול, מהסיבה הפשוטה שטקסט בדפדפן הוא לא בדיוק טקסט בפוטושופ – הוא לא מתרנדר אותו הדבר בכל הדפדפנים, וגודל ה"אזור" שתוחם אותו לא באותו גודל שחישבו בפוטושופ. נשמע לא ברור ולכן אני אדגים.
בתמונה למטה, בעיצוב (הכפתור מצד ימין) הטקסט בכפתור נתחם בדיוק לקצוות שלו, ומעבר לזה מתחילה ספירה של padding. לעומת זאת בדפדפן (הכפתור השמאלי בתמונה), גובה האזור התוחם את הטקסט מושפע מה-line-height של הטקסט, והרוחב מושפע גם מריווח דיפולטי או משתנה בין האותיות (האות האחרונה תמיד תקבל גם את ה-letter-spacing שמוגדר לה):
ואז עולה השאלה – מה אנחנו מגדירים? האם שומרים על ערכים בכפולות של שמונה בהגדרות של padding ו-margin ובגודלי פונט, או שמעגלים פינות ונותנים ערכים לא מדויקים (כמו 9 פיקסלים למשל) כדי שהתוצאה הסופית תהייה בכפולות של 8? אני אישית מחבבת את השיטה הראשונה: לא משנה בעיניי הסכום הסופי אלא שמירה על כפולות של שמונה.
ואם אנחנו כבר מדברים על הבדלים ותיקונים, הנה משהו קטן שלא לגמרי קשור ליישום של ה-UI אבל גם לא לא-קשור: בפוסט ממש מעניין על Optical adjustments in components, מדהים לראות איך שינויים ממש קטנים משנים את התחושה שלנו. אם מסתכלים על זה מכיוון של קומפוננטות CSS – אוי ואבוי כמה החרגות; אבל מהצד של UI ועיצוב – וואוו!! לא יכולתי שלא לצרף את הפוסט הזה 🙂
תוכן אמיתי
בתקופה שעיצבתי אתרים טענתי שתוכן תמיד הורס את העיצוב 😉 . הרי כשמעצבים, בוחרים את כמות המלל איך שרוצים, ובוחרים תוכן שהוא אופטימלי ויושב טוב עם העיצוב (במילים אחרות – מעגלים פינות). אז איפה מתחילה הבעיה? כשיש תוכן באתר והוא מגיע ממזיני התכנים/DB או איך שתרצו לקרוא לזה. אז פתאום צצות בעיות…
אני תמיד דוגלת בגישה של להתכונן לגרוע מכל, ככה אפעם לא מתאכזבים ותמיד מוכנים להכול:
מסתבר שככה זה גם בעיצוב אתרים. הכי טוב להכניס את המלל הכי ארוך שיש (ואז לבדוק גם את הקצר דווקא), להכניס את הודעות השגיאה של הטפסים ולראות איך הן יושבות עם השדות, לעצב עמוד שאין בו תוכן, כי גם זה קורה. ל-Vivek Karthikeyan יש פוסט נחמד בשם – Designing for the worst cases ממליצה בחום.
בהקשר הזה, ובמיוחד לאור הפרויקט שאנחנו עובדים עליו, אני חייבת לציין את עניין הטבלאות. אני באופן אישי לא אוהבת טבלאות, לא בחיים האמיתיים ולא ב-HTML, אבל מה לעשות שלפעמים זאת הדרך הטובה ביותר להציג נתונים. העניין הוא, שמשהו באיך שטבלאות מתנהגות בדפדפן לא אינטואטיבי לי. בגדול, העמודות מקבלות רוחב לפי התוכן שלהם, ואם יש הרבה, הוא יקבע את הרוחב של כל העמודה, אלא אם כן הגדרנו אחרת… אבל בעיצוב משום מה לא תמיד מתחשבים בהתנהגות הדיפולטית של טבלה, מה שמביא לזה שטבלאות בעיצוב נראות מעלף והכל יושב פיקס, והפער בין העיצוב לתוצאה הסופית גדול יותר. מה אפשר לעשות? לא להשתמש בטבלאות 😉 . ובפועל, צריך להגדיר רוחב לעמודה אחת ספציפית, צריך לשבת עם העיצוב ולראות איך מיישרים את העמודות, איך ומתי נותנים רחבים מיוחדים, ומתי מוותרים על עימוד מושלם 🙂
אם כבר מדברים על תוכן אמיתי, אני רוצה להעלות את עניין המכשירים. כן כן, ברור שמעצבים למובייל. אבל מה קורה כשרוצים שהעמוד יהיה בגובה של 100%? נכון שב-CSS זה קצת יותר מאתגר לתת גובה ולמתוח על פני כל העמוד, אבל מאז עידן הפלקס זה הרבה יותר קל. עם זאת, צריך לזכור כמה דברים חשובים גם בצד של העיצוב וגם בצד של התכנות:
- אם רוצים שהכול ייכנס בגובה של המסך – לאיזה מסך הכוונה? האם לוקחים את האפשרות הכי נמוכה ומשם מרווחים? מה קורה אם יש הרבה תוכן? צריך להביא בחשבון שתהייה גלילה.
- אנדרואיד ואייפון הם לא אותו דבר: לאנדרואיד יש את השורה של הניווט בתחתית המסך, ובאייפון החדש יש את המגרעת בחלק העליון של המסך.
דיזיין סיסטם (סטייל גייד)
לפני קצת יותר משנה כתבתי פוסט על חשיבות הסטיילגייד ודרכים לממש אותו. היום יותר מתמיד אני מאמינה שסטיילגייד / דיזיין סיסטם, לא משנה איך תקראו לזה, ממש ממש חשוב! צריך מקום אחד שמרכז את כל האלמנטים שיש לנו באתר – צבעים, אייקונים, כותרות, ניווט, כפתורים ועוד ועוד ועוד. אז אם האתר קטן – אחלה, אולי לא צריך; אבל ככל שהאתר גדל וממשיכים לעצב עוד ועוד עמודים/קומפוננטות, וצוותי העיצוב והתכנות משתנים, רק סטיילגייד יעזור לשמור על אחידות. והוא שומר לא רק על אחידות של מראה, אלא גם על אחידות של מבנה HTML, שמות של קלאסים ועוד.
כשהתחלתי לעבוד עם אלעד, הוא לימד אותי להסתכל נכון על עיצוב ולפרק אותו לאלמנטים, לקומפוננטות. להסתכל על מגוון קובצי PSD ולהוציא מהם אלמנטים מאחדים. גם בתכנות אמיתי (לא HTML ו-CSS 😉 ) משתדלים ליצור כמה שיותר דברים גנריים כי זה מקל על התחזוקה ומפשט את הקוד. ככה למדתי להעריך את חשיבותו של המכנה המשותף – את האלמנטים והקומפוננטות. העניין הוא שאם עובדים עם פוטושופ ולא משתמשים ב-smart object לעיצוב של קומפוננטות באופן כזה שהוא cross files, אז בעצם יוצא שמעצבים שוב משהו דומה ממש, אבל לפעמים קצת שונה. גם בקוד, אם לא שמרנו על קומפוננטה אחידה, גם אז יווצר שוני במבנה ה-HTML-לי ו/או גם ב-CSS. ואם הפרויקט הוא ארוך, ופתאום מגיעים עמודים חדשים ליישם, הכי קל זה שוב לפנות לסטיילגייד ולשלוף אותם משם!
הערת אגב – כן אני יודעת שיש אלטרנטיבות לפוטושופ, וסקץ' לעניין הזה ממש מושלמת, אבל אני לא יכולה לכתוב על משהו שלא התנסיתי בו. מוזמנים להוסיף בתגובות תובנות שלכם על סקץ'/פיגמה/זפלין/אדובי XD ועוד.
כמה מילים על אלמנטים, קומפוננטות ווריאציות
לפני שנתחיל, ממליצה בחום על הפוסט של אלעד Naming Things in CSS שהוא חלק מסדרת הפוסטים שלו על ארכיטקטורה.
מעבר לזה שבעצם כל האלמנטים והקומפוננטות נמצאים בסטיילגייד, אפשר בקלות לראות וריאציות שלהן וזה ממש נחמד. למשל, באתר שאני עובדת עליו יש כפתורי שיתוף. אבל הם מופיעים ב-2 אופנים של עיצוב, ומה שמבחין ביניהם הוא הצבע.
ברמת ה-HTML + CSS הקומפוננטות זהות. ההבדל היחיד הוא תוספת של קלאס של clean. מה היתרון? אנחנו מתחזקים רק קומפוננטה אחת. אם יהיה שינוי בעתיד, הוא יחול במהירות ובקלות על כל המקומות שהכפתורים מופיעים בהם.
מקומי (native) או מעוצב
הרבה מהאלמנטים שהם "נייטיב" בדפדפן יש לנו אפשרות לעשות מניפולציה וליישם עליהם את העיצוב. זה בא לידי ביטוי בעיקר באלמנטים של טפסים (checkbox, כפתורים, חלונות select וכו'), סקרול, טולטיפ ועוד. בגדול, נראה שרוב האלמנטים עובדים אחלה עם העיצוב שמיישמים עליהם. חלקם נתמכים בכל הדפדפנים וחלקם מצריכים סינטקס נפרד, אבל בגדול הכל זורם. אז מה לא?
tooltips
השימוש ב-tooltip מאוד נפוץ, בעיקר בשביל לתת רמזים למשתמש. למי שמתעניין ברמת חווית המשתמש ממליצה על:
- Tooltip Guidelines / Nielsen Norman Group
- Tooltips: How to use this small but mighty UI pattern correctly
- What are Tooltips and Why Should You Use Them
אפשר לממש אותו בכמה דרכים. דרך אחת היא שימוש data-tooltip ומצריכה רק CSS (שימוש ב-before ו-after). שיטה אחרת משלבת שימוש באלמנט HTML-לי ומיקום שלו ע"י שימוש ב-JS. אפשרות שלישית היא להשתמש באפשרות הנייטיב של הדפדפן הלוא היא ה-title. יש פוסט מאוד מעניין של JON ROHAN על התהליך שהם עברו במעבר משימוש בטולטיפ באמצעות JS לכזה שמבוסס על CSS בלבד: Implementing an all CSS tooltip. זה פוסט מעניין מאוד, אבל עבור אלה שפחות רוצים לפרוש מהפוסט המעניין שלי ולשקוע בפוסט אחר, אתמצת שהוא מדבר על שיפור בביצועים בגלל נטישה של ספריית Tipsy.js. דבר נוסף שהוא מדבר עליו הוא המחיר שהם שילמו במעבר לטולטיפ מבוסס CSS. ומה המחיר? המחיר הוא שאם הטולטיפ נמצא בגבולות של אזור שתחום עם overflow:hidden לא יראו אותו, או שחלק ממנו ייחתך. ופה נכנס שיקול של עיצוב-התנהגות ומהירות טעינה.
אפשר לשלב גם JS בשביל להתמודד עם עניין ה-overflow:hidden אבל בעייני זה סתם מכביד ולא שווה בחישוב של עלות מול תועלת. אז מה עושים? אצלנו החלטנו שתלוי במצב: אם אפשר היה לעצב את הטולטיפ, הלכנו על זה. ובמקומות שלא, נשארנו עם title והעיצוב הנייטיבי שלו, עם כל החסרונות שלו: שהוא לא מספיק אסתטי, שהוא משתנה במראה שלו מדפדפן לדפדפן, ושהוא לא קשור לעיצוב בכלל. אבל היי, לפחות תמיד רואים אותו 🙂
לסיכום
ככל שההבנה של איך מתנהג הדפדפן גדולה יותר, כך התקשורת תהייה קלה יותר והעיצוב יהיה מכוון יותר. אבל לא רק זה, גם מי שמיישם את העיצוב צריך הבנה לעיצוב, לחשיבות של ריווחים, צבעים ועוד. אבל זה לבדו לא מספיק. אני חושבת שהמפתח נמצא בדו-שיח, בתקשורת בין מי שכותב.ת את ה HTML + CSS לבין מי שמעצב.ת.