תבניות-עיצוב, Design Patterns, הן פתרונות מוּכּרים לבעיות נפוצות. זה מושג שמוכר בדרך-כלל בעולם הנדסת התוכנה, ובשנים האחרונות החלו לקום אתרים שמגדירים כאלה גם עבור ממשק המשתמש. הם מציגים תבניות-עיצוב כמו פרורי לחם – breadcrumbs (כמה מוזרים התרגומים לעברית), אשפים – wizards, דירוג – rating, עצים ואחרים. את התבניות צריך להתאים בדרך-כלל לכל יישום, אבל הן יכולות לשמש גם כהתחלה טובה, בסיס לממשק, וגם כהשראה לרעיונות חדשים.
Smashing Magazine הוא כמעט תמיד מקור מעולה לידע וקישורים. אתמול התפרסם שם מאמר עם סקירה מקיפה של תבניות-עיצוב לממשק משתמש. במאמר יש גם קישורים למקורות מידע מצויינים על שימושיות וממשק ברשת, שביניהם בלטו בחסרונם המגזין A List Apart, הפורום העצום של IXDA, איגוד השימושיות UPA והמגזין שהוא מפרסם – User Experience. אם יש לכם עוד קישורים, אתם מוזמנים להוסיף בתגובות.
באותו מאמר מצאתי, בין שאר האוצרות, את Konigi. יש בו אוסף דוגמאות די גדול של ממשקי משתמש מצויינים, וגם של עיצובים יפיפיים. תמיד טוב שיש כאלה בתיק, להשראה.
הנה המאמר, פנו לעצמכם כמה שעות טובות 
לצלול וליהנות:
40+ Helpful Resources On User Interface Design Patterns
או כאן
אמיר דותן כתב על אותו הנושא פוסט מעניין לפני כמה חודשים, ממליץ לקרוא גם אותו.
רוצים ללמוד עוד?
בסדנת עיצוב חוויית המשתמש תוכלו להכיר את תחום "חוויית המשתמש" בצורה יסודית ומדוייקת. הסדנה בהנחייתי כוללת 4 מפגשים של 4 שעות ובהם שפע רב של ידע מקצועי וגם תרגול.
"הסדנה היתה שילוב מצוין בין רוחב ועומק, ובין תיאוריה לפרקטיקה. אני מרגישה שקיבלתי הכרות מצוינת עם עולם חווית המשתמש, כלים והתחלה התחלה של פיתוח אינטואיציות. הדוגמאות אמיתיות ומצוינות, וגם ההפניות למקורות אחרים פותחות עולם ומלואו.", נגה עמית, מעבדות חדשנות, מיקרוסופט
16 ביוני 2009 בשעה 11:21
תודה!
מתוך ים המידע בנושא, חשוב באמת למצוא את אלו שעוצבו על סמך מחקר שימושיות.
דוגמא יפה שעוזרת בבחירת העיצוב המתאים מתוך שלל האפשרויות הנה להציג מדגם שימושיות סטטיסטי, כמו שמובא בתחילת המאמר –
http://media2.smashingmagazine.com/wp-content/uploads/images/ui-design-patterns/br.gif
זה בהחלט עוזר.
תודה על הקישור
16 ביוני 2009 בשעה 11:34
בכיף, אוריאל.
הדוגמא שהתכוונת אליה היא מהאתר הזה:
http://www.webdesignpractices.com/
אני מסכים שזה מידע חשוב, ואף ייחודי בין האתרים שראיתי עד כה בתחום של תבניות עיצוב, אבל חשוב לשים לב לתאריך שבו נאספו המדגמים שלהם. למשל עבור ה-pattern הראשון, Global Navigation, הנתונים נאספו ב-2002!
http://www.webdesignpractices.com/navigation/globalnav.html
הם לא ממש מדגישים את זה, זו ממש הטעיה של הקוראים, זה מידע חשוב – הרי הטרנדים ברשת משתנים כל הזמן. מה שהיה נכון ב-2002 נחשב ב-2009 להיסטוריה עתיקה. סקירה מהירה של האתר מראה שרוב המידע בו נאסף ב-2002-2003.
דו"חות מהסוג הזה אפשר לקנות (בהרבה $$$), אצל נילסן-נורמן:
http://www.nngroup.com/reports/
לא השתמשתי בהם בעצמי, אבל אנשים שדיברתי איתם, שקנו אותם והשתמשו בהם, אמרו שהם מצויינים. חוסכים הרבה זמן מחקר.
16 ביוני 2009 בשעה 20:53
הנה קישור לאתר תבניות עיצוב יחסית חדש המבוסס על טכנולוגיית silverlight:
http://quince.infragistics.com/
אחד הדברים המעניינים יותר הוא אופן התצוגה "by wireframe" – דרך מקורית ואינטואיטיבית להצגת התבניות.
וקישור נוסף להרצאה של אמברוז ליטל, איש צוות בכיר באתר הנ"ל, שמדבר על ספריית תבניות בכלל ועל quince בפרט:
http://videos.visitmix.com/MIX09/T30F
17 ביוני 2009 בשעה 5:25
תודה, מרטין, יופי של טיפ. הייתי בעצמי ב-quince כמה פעמים, ולא שמתי לב לצורת התצוגה הזו. לפעמים קצת קשה למצוא את הידיים ואת הרגליים בספריות האלה, וזה בהחלט עוזר.
17 ביוני 2009 בשעה 21:43
הי ברק,
תודה על הקישורים! בפברואר שעבר קישרנו לעוד אתר בנושא, כאן: http://blogs.microsoft.co.il/blogs/ui/archive/2008/02/07/56999.aspx
ויטלי
17 ביוני 2009 בשעה 21:44
אוי, איזה כיף לי, זה פירמט את התגובה הקודמת שלי בסגנון "הטוקבקיסט המתלהב ב-ynet". כנסו-כנסו.
18 ביוני 2009 בשעה 7:29
תודה, ויטלי. התכוונת לקישור ל-http://ui-patterns.com? הוא מופיע גם בסמאשינג.
הנה עוד מאגר מצויין שמופיע בסמאשינג, אומנם רק אוסף צילומי מסך, אבל אוסף מכובד ומקיף:
http://www.flickr.com/photos/factoryjoe/collections/72157600001823120/
וגם שני פודקאסטים של גָ'ארֶד ספּוּל על הנושא:
Patterns and anti-Patterns with Bill Scott
Achieving Pattern and Component Reuse with Nathan Curtis – מציג רעיון של קומפוננטות UI, לעומת תבניות עיצוב של UI. ההבדל העיקרי כפי שהבנתי אותו מהפודקאסט, הוא שקומפוננטות הן התאמה ספציפית של תבנית עיצוב כללית, שחוזרת על עצמה בתוך האפליקציה. כמו, למשל, נגן וידאו. הוא יהיה דומה לתבנית הכללית של נגן וידאו שמופיעה בספריית תבניות עיצוב (כפתור Play וגם Pause ועוד כמה), אבל יהיה לו גם כפתורים שמיוחדים לאפליקציה הספציפית שהוא מופיע בה כמו הוספת כתוביות או קישורים. הקומפוננטה תחזור על עצמה ברחבי האפליקציה בצורות שונות.
יש לספול גם דף שמוקדש לקישורים בנושא.
18 ביוני 2009 בשעה 9:22
הזכרת את ג'רד ספול וקומפוננטות – באותו הקשר, אני ממליץ לקרוא את המאמר הבא של רוברט הוקמן:
http://www.uie.com/articles/web_anatomy_frameworks
הוקמן טוען שתבניות עיצוב מיועדות לפתרון בעיה מאד ספציפית ולכן בהגדרה הן מוגבלות.
הוא מציע להסתכל על פתרון הבעיה כמכלול ולדבר במונחים של "מערכות עיצוב" (design frameworks).
לדעתי זה רעיון מעניין.
לא קל להשתמש בתבניות עיצוב לפתרון בעיה חדשה. הספריות הנ"ל משמשות בעיקר להשראה, כפי שכתבת.
18 ביוני 2009 בשעה 10:57
ג'רד ספול ורוברט הוקמן מקדמים שניהם את המושגים של Components ושל Interaction Design Frameworks. אני לא זוכר אם זה הוקמן או EightShapes, אחד מהם עובד על ספר בנושא של Frameworks (כנראה הוקמן). ספול כותב עוד על הנושא כאן:
http://www.uie.com/articles/componentspatternsframeworks/
18 ביוני 2009 בשעה 11:48
אז האם לדעתך frameworks ו-patterns הם דברים פרקטיים? ניתן להיעזר בהם בשוטף?
אשמח לשמוע איך אתה משתמש בספריית תבניות בעבודה שלך.
20 ביוני 2009 בשעה 21:53
כפי שכתבתי בבלוג -תבניות עיצוב הן נקודות התחלה מצויינות לעיצוב ממשק. הצוות שלי משתמש בהן באופן שוטף כדי לקבל רעיונות לתכנון אינטראקציה. מאחר ואנחנו עוסקים בעיקר בתכנון של תוספות ושינויים לאפליקציות מדף קיימות, ולא בפרוייקטים חדשים שצריך לתפור עבורם פיתרון, השימוש ב-patterns אצלנו הוא מצומצם. לא קורה אצלנו כל יום שצריך להגדיר מסך login או מערכת ניווט חדשה. אבל כשאנחנו מגיעים למקומות כאלה, בהחלט – אנחנו מחפשים דוגמאות לפתרונות קיימים במגוון מקומות, ביניהם ספריות תבניות כמו אלה שהוזכרו פה.
Frameworks הן אוסף תבניות סביב נושא מסויים. למשל, עבור Login צריך גם תבנית לכניסה לאתר, אבל גם לשחזור סיסמא שנשכחה. שתי תבניות אלה יכולות להיות ביחד חלק מ-Framework של כניסה למערכת. כך שבהחלט, גם לכאלה יש מקום. גם כאן, השימוש היותר אינטנסיבי יהיה כשמעצבים מערכת חדשה. אז נחוצות אבני בניין סטנדרטיות עבור יכולות סטנדרטיות, כדי לחסוך בזמן תכנון. מובן שתמיד יש צורך לבדוק את התבנית/framework מול הצרכים של המערכת הספציפית, אבל היתרון בפתרון מוכן שרק דורש התאמה נראה די ברור.