מעצבים קדימה – על מעצבים, מתכנים וממשקים

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

איור עץ באובב. מקור whynoteight.wordpress.com

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

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

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

ואיפה כאן הבעיה? תשאלו. הרי אם שאיפות המעצבים והמתכנתים דומות, מדוע ישנם פערים?

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

הפער גדל כשאנו באים לטפל בבעיית התאימות לדפדפנים השונים (או, אם נדייק, לגרסאות אקספלורר השונות).

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

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

ולמי פתרונים?

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

דפדפנים, היזהרו מעצי באובב

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

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

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

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

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

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

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

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

יש על מה לדבר

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

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

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

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

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

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

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

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

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

אסב את תשומת לבכם לשני כלים כאלו – Twitter Bootstrap ו Foundation שנראים מתאימים לעזור לנו השיג את מטרותינו, ואציין ראשית שהתמיכה ב responsive design תגיע ל Twitter Bootstrap רק בגרסה 2 (כרגע בבטא, יוצא ב 1 בפברואר) ושנית שאין לי ניסיון מעשי עם שני הכלים הללו, ובחרתי לציינם בהקשר זה לאחר המלצה חמה וקריאת התיעוד.

כמובן, שראוי גם כאן לתאם ציפיות ולומר בפה מלא שאני כמתכנת מצפה ממעצבי ההווה העתיד להתחיל להשתמש בכלים דוגמת Twitter Bootstrap ,Foundation ואחרים (למשל Blueprint או Compass) למען יגור זאב עם פיקסל, ומתכנת עם קוד ירבץ, ויבוא לציון גואל במהרה בימינו אמן.

רעמים וברקים

אני שומע, עוד לפני שהכתבה עלתה את התרעמות המעצבים, על ציפיותי ודרישותי המוגזמות, שהרי לא נשמע שמעצב ישראלי ילכלך ידיו בקוד (אלא אם זה Action Script 2 שחייבים לדעת כי זה מה שלימדו בתואר).

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


הפוסט בחסות uCoz


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

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

בואו לבקר באתר uCoz ותראו בעצמכם כמה זה פשוט

זהר ארד

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

הגב

12 תגובות על "מעצבים קדימה – על מעצבים, מתכנים וממשקים"

avatar
Photo and Image Files
 
 
 
Audio and Video Files
 
 
 
Other File Types
 
 
 

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

סידור לפי:   חדש | ישן | הכי מדורגים
Eyal Kofman Cagan
Guest
אני מעצב UI, וחושב שאתה צודק ב'מאת האחוזים'! בנוסף, ברגע שמעצב מבין Front End Dev, גם העבודה שלו יותר קלה, כי הוא מכיר ויודע למכור את המגבלות (או להשתמש בהן), לגבי Frameworks, גם זה מאוד עוזר לעיצוב, למשל ל Twitter Bootstrap יש גם תבנית UI Kit: http://fireworkswireframingkit.com/2012/02/02/twitter-bootstrap-1-4-assets גם לי אישית לא יצא להשתמש בנ"ל, אך מניסיון במובייל , כשעובדים מול UI kit בתור בסיס בשלב העיצוב הויזואלי , או לפחות מבקרים ב Documentation של ה frameworks. מבינים את המגבלות גם עם לא מתכנתים FED , היתרון הגדול, בלהיות מעצב ממשק משתמש ולדעת פיתוח ממשק משתמש, זה החסכון ב 'ריצות' אחרי… Read more »
דוד
Guest
בתור בן אדם שמצד אחד למד פסקל במגמה בתיכון ומכיר הרבה משפחה וחברים שמתכנתים ומן הצד השני למד במכללה אנימציה מולטימדיה ותלת מימד וסיים תואר ראשון במקצוע הומאני. אני רוצה לעמוד על ההבדלים בין הכתבה למעצבים. מתכנתים כפי שאני מבין אותם, אוהבים את החיים פשוטים, לפעמים מאתגרים אך לרוב פשוטים. במה שקשור לעבודתם ובמיוחד לכתיבת קוד הם מעדיפים קצר, פשוט וקולע עם המון כללים וחוקים, הגדרות ושאר מיני ירקות. אך אני גם מבין את כל המעצבים שעומדים לרעום ולברוק על כותב הכתבה, מכיוון שהם רוח חופשייה שעושה ככול העולה על רוחה וכפי שהיא מבינה את המציאות. ארד כותב ש”האחריות של… Read more »
זהר ארד
Guest

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

אני סבור שהכלים שהזכרתי בכתבה וכלים דומים (יש מגוון עצום) יכולים להוות גשר בין מזרח למערב.

למשל, יש היום הרבה מאוד כלים ווביים שמאפשרים ליצור רכיבי ממשק באופן חי בדפדפן, עם תצוגה מקדימה, ולאחר מכן להעתיק את קוד ה HTML + CSS . כלים כאלו הם ממש גשר בין העולם החזותי והעולם העיצובי.

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

דוד
Guest

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

גיל ש
Guest

זהר – אני אשמח לקבל קישורים לכלים עליהם אתה מדבר, בהחלט יכול לעזור.

תודה מראש וערב טוב.

Ori Idan
Guest

אתה לדעתי מבלבל בין עיצוב לבין תכנות. HTML ו CSS אינן שפות תכנות. הן שפות עיצוב ונועדו למעצבים לא למתכנתים. מתכנת אכן חושב יותר לוגית ולכן קשה לו מאד עם עיצוב. מתכנת אמור לכתוב ב Javascript בצד לקוח או PHP וכד' בצד השרת.
אתה משום מה מדבר על כתיבת HTML כתכנות בעוד שזה בעצם חלק מהעיצוב. אם יש לך מעצב ווב שאינו יודע לכתוב קוד ב HTML, הוא אינו מעצב ווב אלא מעצב דפוס.
מעצב ווב חייב לדעת איך העיצוב נראה על כל דפדפן.

Almog Baku
Guest

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

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

אלמוג בקו
Guest

אהלן זהר,
נהנתי מאוד לקרוא את הכתבה.. והאמת שפשוט לא הפסיק לרוץ לי בראש “סוף סוף מישהו אמר את זה!”

והדבר היותר מעניין.. הכרתי לי את שתי כלי הUI המעניינים האלו..
אבל אני חייב לשאול.. למה לא jquery-ui?
אומנם הJQUI מתעסק יותר באובייקטים ופחות במבנה האתר הכללי אבל הוא הרבבה יותר עשיר..

אשמח לדעתך.. וגם.. איזה כלי ל UI FRAMEWORKING מומלץ לדעתכם?

~ אלמוג.

זהר ארד
Guest
אלמוג, אני שמח מאוד שאהבת את הכתבה! הסיבה שלא jQuery-UI היא ש jQuery היא ספריית ג’אווהסקריפט, בעוד הכלים עליהם אני מדבר הם כלי CSS (נכון שיש גם קצת JS ושימוש ב LESS/SASS אבל התוצר הוא CSS). ממה שאני מכיר, מעצבים גרפיים לא מחוברים לקוד כמו מתכנתים (וזה בסדר כי הם לא מתכנתים) ולכן עקומת למידה של שפת תכנות כמו JS תהיה לדעתי תלולה מדי עבורם. הרעיון הוא למצוא את הנקודות המשיקות כדי למצוא שפה משותפת ו CSS כשפה של הוראות עיצוב הרבה יותר מתאימה לכך. בנוסף, הכלים עליהם דיברתי נותנים פתרונות להגדרה ואפיון של יותר מרכיבי ממשק כמו כפתורים (למשל… Read more »
אלמוג בקו
Guest

אני מדבר עלjquery ui css framework.
כחלק אינגרלי מjqui קיים פרימוורק של css לשימוש בכפתורים אייקונים טפסים וכד׳..
זה אומנם קצת מבולגן אבל הייתרונת ברורים: תאימות גראפית לכל ממשקי הui.

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

זהר ארד
Guest

אני חושב ש Foundations ו Bootstrap לא “צעירים” מדי ובשלים מספיק לעבודה. ישנן תשתיות נוספות שהן בשלות וראויות כמו 960gs שהזכרת.

היתרון הבולט של Bootstrap / Foundation הוא שהן פיתרון כולל ולא רק גריד ויש להן תמיכה ב responsive design.

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

wpDiscuz

תגיות לכתבה: