למפתחים בפרוייקטים פתוחים אין תמיד את המשאבים הדרושים כדי להקדיש את מלא תשומת הלב הראויה לעיצוב ממשק המשתמש ולפעמים, "יש בעיה אחת קטנה עם חלק גדול של השפע הזה של תוכנות (קוד פתוח) - קשה יותר להשתמש בהן מאשר היה צריך להיות."
המדריך של בנג'מין רואו מתייחס למספר היבטים חשובים של פיתוח ממשק משתמש גרפי, במיוחד כאשר אין לפרוייקט אפשרות להעסיק מומחה בתחום. הוא מתמקד בבעיות שלדעתו קל לפתור באופן יחסי והפתרונות שהוא מציע אינם 'שנויים במחלוקת' מנקודת המבט של שמישות. בכל אופן, חשוב לזכור שבקורת על תוכנות מסויימות, אם ישנה, היא רק לצורך המחשה אז לא לקחת באופן אישי בבקשה.
ממשק משתמש 'שמיש': מדריך קצר למפתחי תוכנות קוד פתוח ותוכנה חופשית
0) המשתמש לא משתמש בתוכנית שלך
הכי חשוב לזכור כאשר מעצבים 'ממשק משתמש גרפי' (GUI) זה שהמשתמשים אינם רוצים "להשתמש" בתוכנית והתוכנית צריכה לכל היותר למאפשר להם לבצע את העבודה במהירות ובקלות ככל שאפשר. תוכנית על כן, היא לכל היותר כלי שמאפשר להם לבצע עבודה. ככל שהתוכנית שלכם מורגשת פחות, כך ייטב. כל דקה מזמנו בה המשתמש צריך להשתמש' בתוכנית, היא דקה שהוא לא משקיע בעבודה עצמה. שני ציטוטים מספרו השני של אלן קופר, About Face 2.0, מסכמים נקודה זו היטב:
- דמיינו לכם את המשתמשים שלכם מאוד אינטלגנטים, אבל גם מאוד עסוקים
- אין זה משנה כמה הממשק שלכם מגניב, עדיף שיהיה כמה שפחות ממנו
נקודות 1 עד 4 במאמר עצמו הן למעשה מקרים פרטיים של כללים אלה.
1) החוק של פיט (Fitt)
זהו למעשה הכלל הבסיסי והמוכר ביותר בעיצוב ממשקי משתמש. הכלל קובע שככל שהאובייקט גדול יותר וקרוב יותר למקום בו נמצא מצביע העכבר, כך גם יהיה קל יותר להקליק עליו. זה נשמע כמובן הגיוני אבל למרות זאת, ברוב המקרים, המפתחים מתעלמים מכלל זה לחלוטין.
קחו את סרגל הכלים (button bar) של פיירפוקס (תמונה 1) כדוגמה. בעת הגלישה באינטרנט, הכפתור הנחוץ ביותר הוא 'חזור', או 'אחורה'. לכן הכפתור הזה צריך להיות הכפתור שהכי קל ללחוץ עליו: מפני שכך אתם מקלים על המשתמש להשתמש בתוכנית שלכם, ומאפשרים לו להתמקד בגלישה. אבל בסרגל הכלים של פיירפוקס כל חמשת הכפתורים זהים בגודלם. האם הכפתור 'עצור' באמת חשוב כמו הכפתור 'חזור'? לא, כמובן שלא. עיצוב טוב יותר הוא העיצוב שאפשר לראות בתמונה 2. כך קל יותר ללחוץ על הכפתור על פי 'החוק של פיט', וגם קל יותר להבדיל בינו לבין שאר הכפתורים.
את הנוכחות של הכפתור ניתן להבליט על ידי הצבתו בשולי המסך. כאשר מצביע העכבר מגיע לקצה המסך, הוא עוצר שם ללא קשר למהירות בא הזזתם אותו. מה שזה אומר בעצם זה שעבור העכבר, אובייקטים הנמצאים על גבול המסך ממשיכים למעשה אל האינסוף. כדי "לפגוע" במטרה בגודל של פיקסל בודד, שנמצאת בחלק הימני העליון של המסך, כל מה שנדרש לעשות למעשה הוא פשוט לגרור את העכבר ימינה ולמעלה הרחק ככל שאפשר. אבל מספיק שתזיזו את מצביע העכבר ולו פיקסל בודד, כדי שידרש קצת יותר זמן כדי "לפגוע" באותה מטרה. כל זה מלמד אותנו שכפתורים חשובים צריכים להמצא בשולי המסך, או בפינות.
הדוגמה הכי פשוטה היא כפתורי הבקרה שניתן למצא על מסגרות כל החלונות ('סגור', 'הגדל' וכו'). כפתורים אלה חשוב שיהיה קל ללחוץ עליהם, כדי לחסוך מהמשתמש עבודה מיותרת ומכיוון שהם נמצאים בכל חלון, הם מועמדים ראשונים לצורך הצבה בפינות. למרות זאת, מעט מאוד מנהלי חלונות עושים זאת: רוב ערכות הנושא של Metacity למשל, ו-Xfce4 אף היא. כל מה שדרוש הוא להזיז את הכפתור פיקסל אחד בודד למעלה וימינה, והמשתמש לא יצטרך אפילו להסתכל בכיוון כאשר הוא רוצה לסגור חלון.
פס גלילה היא דוגמה נוספת. רוב התוכניות בשולחן העבודה שלי מציירות את את השוליים הימניים של פס הגלילה במרחק פיקסל בודד מקצה המסך, כאשר החלון בגודלו המירבי ועל כן הן דוחסות את כפתור הגלילה עצמו מריבוע שקל לכאורה לללחוץ עליו, מכיוון שהוא נפרס משולי המסך אל האינסוף, לריבוע צר ברוחב 10 פיקסלים בלבד שנדרשים מספר שניות נוספות כדי לגלול את המסך בעזרתו.
לסיכום נקודה זו:
- הפכו כפתורים שנמצאים בשימוש תכוף גדולים ובולטים יותר
- השתמשו בשולי המסך כדי להפוך את הפקדים ל'אינסופיים'
- לעולם אל תציבו פקדים במרחק פיקסל בודד משולי המסך או הפינה
2) ממשק מיותר
כאשר משתמשים עובדים, תשומת ליבם ממוקדת במשימה אותה הם מבצעים באותו רגע. בכל פעם שהם צריכים להקדיש תשומת לב לתוכנית עצמה, הם יצטרכו לבזבז זמן נוסף לפני שיוכלו להמשיך מהנקודה בה הפסיקו. לכן, עליכם לצמצם את היסח הדעת כתוצאה מממשק המשתמש. בכל תוכנית יש אזור שהוא מרכז תשומת הלב: במעבד תמלילים, זהו הטקסט עצמו; בדפדפן, זהו הדף; אז פשוט הפכו אותם למרכז תשומת הלב בממשק שלכם.
דוגמה כזו הן תיבות השיחה או ההתקדמות. Evolution, לצורך ההמחשה, מקפיצה תיבת שיחה בכל פעם שאני לוחץ על Send/Recevice כדי להודיע על מצב ההתקדמות במהלך בדיקת תיבת הדואר שלי. התיבה הזו מפריעה לתהליך קבלת הדואר, והיא חוסמת את האפשרות להמשיך לעבוד עם התוכנית עצמה. איזו מטרה היא משרתת? כל מה שהתיבה הזו עושה זה להפריע למשתמש לעבוד. היה רצוי להפטר ממנה, ולהחליף אותה במד התקדמות בשורת הסטטוס.
דוגמה גרועה עוד יותר היא פח האשפה של KDE. שליחת קובץ לפח האשפה צריכה להיות תהליך הפיך, וסביר להניח שהמשתמש עשוי לבצע אותה מספר פעמים בזה אחר זה: אז מדוע לאלץ אותו אם כן ללחוץ על הכפתור OK בכל פעם אם אפשר פשוט לאפשר ביטול (Undo). אם אתם רוצים להסב את תשומת ליבו של המשתמש לכך שהקובץ נשלח לפח האשפה, די באנימציה פשוטה. אל תשימו בפני המשתמשים מחסום בכל פעם שהם מבקשים לבצע פעולה כה בסיסית. לכל היותר תצליחו לעצבן את המשתמשים, להפריע להם ולגרום לכך שהם ילחצו באדישות על כפתורי OK בכל תיבות השיחה.
דוגמה נוספת היא ההודעה הבלתי נמנעת: "הטקסט שחיפשת לא נמצא" שאפשר למצא במעבדי תמלילים לרוב. אם הטקסט אכן לא נמצא, סביר להניח שטעיתי בהקלדה ואני מעוניין לערוך את הטקסט כדי לנסות שוב. אבל עכשיו יש מולי תיבת שיחה עם כפתור OK שאני חייב ללחוץ עליו לפני שאוכל להמשיך. מטרד וטירחה מיותרת עבור המשתמש. דוגמה מוצלחת יותר היא תיבת Find של פיירפוקס אשר פשוט משנה את צבעה לאדום כאשר הטקסט לא נמצא.
לסיכום נקודה זו:
- אל תציבו מכשולים בפני המשתמשים שלכם
- הקפיצו תיבות שיחה אך ורק אם הן מכילות מידע שימושי
- אם אפשר, ספקו מידע באופן שאיננו חוסם את המשתמש (non-modal)
3) השתמשו בעוצמת המחשב
מחשבים הם כלים רבי עוצמה כיום. הם מסוגלים לבצע מילארדי פעולות חישוב בשנייה, ולאחסן נפחים עצומים של נתונים. בני האדם לעומתם, כמעט ולא השתנו במאות השנים האחרונות. אנחנו עדיין נוטים להתעייף, להשתעמם, דעתנו מוסחת וסבלנותנו מוגבלת. לכן, עושה רושם שזה עשוי להיות רעיון לא רע להעביר כמה שיותר מהעבודה מבן האנוש האומלל, למחשב המשוכלל שנמצא מולו.
בתחום עיצוב ממשק משתמש משמעות הרעיון פשוט: בכל פעם שיש צורך לקבל החלטה או לבצע פעולה כלשהי, נסו לגרום לכך שהממשק יעשה אותה עבור המשתמש. לדוגמה, בסרגל המשימות שלי נמצאים כעת שני מסופי xterm (תמונה 7). באחד מהם אני עורך קוד עם SiEd, ואילו בשני אני עורך טקסט עבוד מחקר עם LaTeX. האם תוכלו לגלות איזה מהם הוא איזה בתמונה? אני עצמי לא יכול. כדי לבחור את המסוף הרצוי, אני חייב להשקיע מאמץ נוסף למשל על ידי לחיצה על הכפתור בסרגל המשימות, או על ידי הזזת סמן העכבר כדי לקרא את הtooltip. אבל המחשב דווקא כן יודע איזה חלון זה, אז למה שהוא לא יעשה את העבודה בשבילי?
הפתרון פשוט: עבור יישומים דומים הנמצאים בסרגל המשימות, בדקו מהן הפעולות שהם מבצעים וספקו מספיק מידע כדי לאפשר להבדיל ביניהם. כך אוכל לבחור מבין מספר יישומים, מבלי שאצטרך להשקיע יותר מדי מחשבה. המחשב עושה את העבודה במקומי.
אם במחשב כל כך הרבה שטח אחסון, מדוע תוכניות שוכחות לרוב את כל ההגדרות שקבעתי בכל פעם שאני סוגר אותן? לדוגמה: אני אף פעם לא עורך מסמכים באופן אופיס אלא בחלון מוגדל. ברירת המחדל של אופן אופיס היא 800X600 לערך, לכן אני לוחץ על 'הגדל' תחילה ולאחר שסיימתי לעבוד אני סוגר את התוכנית. בפעם הבאה שאני מריץ אותה, אופן אופיס חוזרת לגודל מסך של 800X600 ולכן מאלצת אותי להפסיק את מה שאני עושה, כדי ללחוץ על הכפתור 'הגדל' שוב. שמירת ההגדרות והמצב האחרון בכל פעם דורשת 20 בתים לכל היותר, מחיר זניח לעומת אלפי ההקלקות המיותרות.
סייר הקבצים Natutilus של GNOME עושה את זה כמו שצריך דווקא: החל בגודל החלון, וכלה במיקום הכפתור בסרגל הגלילה, המידע נשמר עבור כל חלון כך שלאחר שבחרתי בספריה רצויה, אני יכול לשכוח מזה.
לסיכום נקודה זו:
- המחשב הוא כלי רב עוצמה, השתמשו בו
- אפשרו להבדיל בין פריטים דומים
- שמרו את הגדרות התוכנית
4) אפשרו להבדיל בקלות בין פריטים דומים ולאתרם
נקודה זו ברורה למדי: פריטים שנמצאים על המסך ומשמשים למטרות שונות, צריך שיהיה קל להבדיל ביניהם. כדוגמה קיצונית לניסיון לא מוצלח, הסתכלו למשל על סרגל המשימות של Konqueror:
הכפתור מצד שמאל הוא 'חץ למעלה' - קרוב לודאי הפקודה הכי פחות נחוצה בדפדפן. צד שמאל הוא הצד שקל יותר לאתר, לכן הפעולה השכיחה ביותר צריכה להמצא שם. בדיוק מסיבה זו הכפתור 'חזור' נמצא שם בכל דפדפן אחר שאני מכיר.
הכפתור 'חפש' ושני הכפתורים המשמשים לצורך שינוי גודל הטקסט (זום) דומים מאוד; לכפתורים 'קדימה', 'חזור', 'מעלה' ו'בית' אותו הצבע, ולכן קשה להבדיל ביניהם. אבל הכי חשוב, יש 15 כפתורים! אנחנו מסוגלים להבדיל בקלות רבה בין חמישה אובייקטים לכל היותר: לכן אנחנו יכולים לעשות זאת במהירות וללא צורך בתשומת לב מיוחדת. זו הסיבה גם לכך שדפי תיווי מכילים חמש שורות למשל. יותר מאשר חמישה פריטים גורמים לכך שאנחנו צריכים לעצור ולחשוב כדי לזהות מה הוא מה. עיצוב מוצלח יותר היה שם רק את חמשת הכפתורים השימושיים ביותר בסרגל, ועל ידי כך מפחית מהמאמץ הנדרש ברוב המקרים. ברוב היישומים יש מספר רב של פריטים בסרגל הכלים, אבל דפדפן אינטרנט לא זקוק להם. בחנתי משתמשים חדשים שעובדים עם קונקורר ויכולתי לראות בעצמי כיצד הם מתבלבלים. זה מבלבל אותי, ואני דווקא מנוסה.
דוגמה נוספת לקושי להבדיל בין פריטים אפשר למצא בערכת ברירת המחדל של GNOME. הביטו בדוגמה של בחירת טקסט בתמונה 9.
כאשר המשתמש בוחר טקסט, הוא ממוקד בטקסט הזה. אפשר להניח שהוא סימן אותו במטרה לעשות איתו משהו, אז למה הערכה גורמת לכך שצבע הרקע הופך כהה באופן שהופך את הטקסט עצמו לבלתי קריא? לא היה ראוי יותר להבליט את הטקסט דווקא, למשל על ידי הבהרת הרקע והפיכתו לקריא יותר?
לסיכום נקודה זו:
- גרמו לכך שניתן יהיה להבדיל בין פריטים שעושים דברים שונים
- אל תעתירו על המשתמש אפשרויות בחירה
- הפכו את הפריט שנבחר או סומן קל ברור וקריא
מסקנות
אלו הן רק חמש נקודות בסיסיות בעיצוב ממשק משתמש אבל הן חשובות. אין לראות בהן כללי בל יעבור או מענה לכל תחלואי ממשק המשתמש. אבל הקפדה עליהם כחלק מתהליך עיצוב הממשק יכול, לדעתי, לשפר באופן ניכר את שמישותו. אשמח לקבל הערות, תיקונים או תוספות (ראו כתובת בהמשך, הסירו את המילה nospam ).
רעיונות אלו הם רק מבוא. אני ממליץ לכל מי שעוסקים בעיצוב מממשקים בצורה רצינית לקרא את הספרות ברשימה המצורפת בהמשך. הספר של אלן קופר מצוין. הספר של ג'ף רסקין שימושי והוא כולל מספר רעיונות מעניינים מחוץ לטווח המוכר של עיצוב ממשקי משתמש.
- About Face 2.0: The Essentials of Interaction Design, Alan Cooper and Robert Reimann, 2003, Wiley
- The Humane Interface, Jef Raskin, 2000, Addison-Wesley Professional
- The Interface Hall of Shame
- Apple Human Interface Guidelines
אודות הכותב
תורגם לעברית על ידי אורי שרף עבור לינמגזין, נובמבר 2004. המדריך והתרגום זמינים עם רישיון CC. ראו הסברים כאן.
המדריך של בנג'מין רואו מתייחס למספר היבטים חשובים של פיתוח ממשק משתמש גרפי, במיוחד כאשר אין לפרוייקט אפשרות להעסיק מומחה בתחום. הוא מתמקד בבעיות שלדעתו קל לפתור באופן יחסי והפתרונות שהוא מציע אינם 'שנויים במחלוקת' מנקודת המבט של שמישות. בכל אופן, חשוב לזכור שבקורת על תוכנות מסויימות, אם ישנה, היא רק לצורך המחשה אז לא לקחת באופן אישי בבקשה.
ממשק משתמש 'שמיש': מדריך קצר למפתחי תוכנות קוד פתוח ותוכנה חופשית
0) המשתמש לא משתמש בתוכנית שלך
הכי חשוב לזכור כאשר מעצבים 'ממשק משתמש גרפי' (GUI) זה שהמשתמשים אינם רוצים "להשתמש" בתוכנית והתוכנית צריכה לכל היותר למאפשר להם לבצע את העבודה במהירות ובקלות ככל שאפשר. תוכנית על כן, היא לכל היותר כלי שמאפשר להם לבצע עבודה. ככל שהתוכנית שלכם מורגשת פחות, כך ייטב. כל דקה מזמנו בה המשתמש צריך להשתמש' בתוכנית, היא דקה שהוא לא משקיע בעבודה עצמה. שני ציטוטים מספרו השני של אלן קופר, About Face 2.0, מסכמים נקודה זו היטב:
- דמיינו לכם את המשתמשים שלכם מאוד אינטלגנטים, אבל גם מאוד עסוקים
- אין זה משנה כמה הממשק שלכם מגניב, עדיף שיהיה כמה שפחות ממנו
נקודות 1 עד 4 במאמר עצמו הן למעשה מקרים פרטיים של כללים אלה.
1) החוק של פיט (Fitt)
זהו למעשה הכלל הבסיסי והמוכר ביותר בעיצוב ממשקי משתמש. הכלל קובע שככל שהאובייקט גדול יותר וקרוב יותר למקום בו נמצא מצביע העכבר, כך גם יהיה קל יותר להקליק עליו. זה נשמע כמובן הגיוני אבל למרות זאת, ברוב המקרים, המפתחים מתעלמים מכלל זה לחלוטין.
קחו את סרגל הכלים (button bar) של פיירפוקס (תמונה 1) כדוגמה. בעת הגלישה באינטרנט, הכפתור הנחוץ ביותר הוא 'חזור', או 'אחורה'. לכן הכפתור הזה צריך להיות הכפתור שהכי קל ללחוץ עליו: מפני שכך אתם מקלים על המשתמש להשתמש בתוכנית שלכם, ומאפשרים לו להתמקד בגלישה. אבל בסרגל הכלים של פיירפוקס כל חמשת הכפתורים זהים בגודלם. האם הכפתור 'עצור' באמת חשוב כמו הכפתור 'חזור'? לא, כמובן שלא. עיצוב טוב יותר הוא העיצוב שאפשר לראות בתמונה 2. כך קל יותר ללחוץ על הכפתור על פי 'החוק של פיט', וגם קל יותר להבדיל בינו לבין שאר הכפתורים.
את הנוכחות של הכפתור ניתן להבליט על ידי הצבתו בשולי המסך. כאשר מצביע העכבר מגיע לקצה המסך, הוא עוצר שם ללא קשר למהירות בא הזזתם אותו. מה שזה אומר בעצם זה שעבור העכבר, אובייקטים הנמצאים על גבול המסך ממשיכים למעשה אל האינסוף. כדי "לפגוע" במטרה בגודל של פיקסל בודד, שנמצאת בחלק הימני העליון של המסך, כל מה שנדרש לעשות למעשה הוא פשוט לגרור את העכבר ימינה ולמעלה הרחק ככל שאפשר. אבל מספיק שתזיזו את מצביע העכבר ולו פיקסל בודד, כדי שידרש קצת יותר זמן כדי "לפגוע" באותה מטרה. כל זה מלמד אותנו שכפתורים חשובים צריכים להמצא בשולי המסך, או בפינות.
הדוגמה הכי פשוטה היא כפתורי הבקרה שניתן למצא על מסגרות כל החלונות ('סגור', 'הגדל' וכו'). כפתורים אלה חשוב שיהיה קל ללחוץ עליהם, כדי לחסוך מהמשתמש עבודה מיותרת ומכיוון שהם נמצאים בכל חלון, הם מועמדים ראשונים לצורך הצבה בפינות. למרות זאת, מעט מאוד מנהלי חלונות עושים זאת: רוב ערכות הנושא של Metacity למשל, ו-Xfce4 אף היא. כל מה שדרוש הוא להזיז את הכפתור פיקסל אחד בודד למעלה וימינה, והמשתמש לא יצטרך אפילו להסתכל בכיוון כאשר הוא רוצה לסגור חלון.
פס גלילה היא דוגמה נוספת. רוב התוכניות בשולחן העבודה שלי מציירות את את השוליים הימניים של פס הגלילה במרחק פיקסל בודד מקצה המסך, כאשר החלון בגודלו המירבי ועל כן הן דוחסות את כפתור הגלילה עצמו מריבוע שקל לכאורה לללחוץ עליו, מכיוון שהוא נפרס משולי המסך אל האינסוף, לריבוע צר ברוחב 10 פיקסלים בלבד שנדרשים מספר שניות נוספות כדי לגלול את המסך בעזרתו.
לסיכום נקודה זו:
- הפכו כפתורים שנמצאים בשימוש תכוף גדולים ובולטים יותר
- השתמשו בשולי המסך כדי להפוך את הפקדים ל'אינסופיים'
- לעולם אל תציבו פקדים במרחק פיקסל בודד משולי המסך או הפינה
2) ממשק מיותר
כאשר משתמשים עובדים, תשומת ליבם ממוקדת במשימה אותה הם מבצעים באותו רגע. בכל פעם שהם צריכים להקדיש תשומת לב לתוכנית עצמה, הם יצטרכו לבזבז זמן נוסף לפני שיוכלו להמשיך מהנקודה בה הפסיקו. לכן, עליכם לצמצם את היסח הדעת כתוצאה מממשק המשתמש. בכל תוכנית יש אזור שהוא מרכז תשומת הלב: במעבד תמלילים, זהו הטקסט עצמו; בדפדפן, זהו הדף; אז פשוט הפכו אותם למרכז תשומת הלב בממשק שלכם.
דוגמה כזו הן תיבות השיחה או ההתקדמות. Evolution, לצורך ההמחשה, מקפיצה תיבת שיחה בכל פעם שאני לוחץ על Send/Recevice כדי להודיע על מצב ההתקדמות במהלך בדיקת תיבת הדואר שלי. התיבה הזו מפריעה לתהליך קבלת הדואר, והיא חוסמת את האפשרות להמשיך לעבוד עם התוכנית עצמה. איזו מטרה היא משרתת? כל מה שהתיבה הזו עושה זה להפריע למשתמש לעבוד. היה רצוי להפטר ממנה, ולהחליף אותה במד התקדמות בשורת הסטטוס.
דוגמה גרועה עוד יותר היא פח האשפה של KDE. שליחת קובץ לפח האשפה צריכה להיות תהליך הפיך, וסביר להניח שהמשתמש עשוי לבצע אותה מספר פעמים בזה אחר זה: אז מדוע לאלץ אותו אם כן ללחוץ על הכפתור OK בכל פעם אם אפשר פשוט לאפשר ביטול (Undo). אם אתם רוצים להסב את תשומת ליבו של המשתמש לכך שהקובץ נשלח לפח האשפה, די באנימציה פשוטה. אל תשימו בפני המשתמשים מחסום בכל פעם שהם מבקשים לבצע פעולה כה בסיסית. לכל היותר תצליחו לעצבן את המשתמשים, להפריע להם ולגרום לכך שהם ילחצו באדישות על כפתורי OK בכל תיבות השיחה.
דוגמה נוספת היא ההודעה הבלתי נמנעת: "הטקסט שחיפשת לא נמצא" שאפשר למצא במעבדי תמלילים לרוב. אם הטקסט אכן לא נמצא, סביר להניח שטעיתי בהקלדה ואני מעוניין לערוך את הטקסט כדי לנסות שוב. אבל עכשיו יש מולי תיבת שיחה עם כפתור OK שאני חייב ללחוץ עליו לפני שאוכל להמשיך. מטרד וטירחה מיותרת עבור המשתמש. דוגמה מוצלחת יותר היא תיבת Find של פיירפוקס אשר פשוט משנה את צבעה לאדום כאשר הטקסט לא נמצא.
לסיכום נקודה זו:
- אל תציבו מכשולים בפני המשתמשים שלכם
- הקפיצו תיבות שיחה אך ורק אם הן מכילות מידע שימושי
- אם אפשר, ספקו מידע באופן שאיננו חוסם את המשתמש (non-modal)
3) השתמשו בעוצמת המחשב
מחשבים הם כלים רבי עוצמה כיום. הם מסוגלים לבצע מילארדי פעולות חישוב בשנייה, ולאחסן נפחים עצומים של נתונים. בני האדם לעומתם, כמעט ולא השתנו במאות השנים האחרונות. אנחנו עדיין נוטים להתעייף, להשתעמם, דעתנו מוסחת וסבלנותנו מוגבלת. לכן, עושה רושם שזה עשוי להיות רעיון לא רע להעביר כמה שיותר מהעבודה מבן האנוש האומלל, למחשב המשוכלל שנמצא מולו.
בתחום עיצוב ממשק משתמש משמעות הרעיון פשוט: בכל פעם שיש צורך לקבל החלטה או לבצע פעולה כלשהי, נסו לגרום לכך שהממשק יעשה אותה עבור המשתמש. לדוגמה, בסרגל המשימות שלי נמצאים כעת שני מסופי xterm (תמונה 7). באחד מהם אני עורך קוד עם SiEd, ואילו בשני אני עורך טקסט עבוד מחקר עם LaTeX. האם תוכלו לגלות איזה מהם הוא איזה בתמונה? אני עצמי לא יכול. כדי לבחור את המסוף הרצוי, אני חייב להשקיע מאמץ נוסף למשל על ידי לחיצה על הכפתור בסרגל המשימות, או על ידי הזזת סמן העכבר כדי לקרא את הtooltip. אבל המחשב דווקא כן יודע איזה חלון זה, אז למה שהוא לא יעשה את העבודה בשבילי?
הפתרון פשוט: עבור יישומים דומים הנמצאים בסרגל המשימות, בדקו מהן הפעולות שהם מבצעים וספקו מספיק מידע כדי לאפשר להבדיל ביניהם. כך אוכל לבחור מבין מספר יישומים, מבלי שאצטרך להשקיע יותר מדי מחשבה. המחשב עושה את העבודה במקומי.
אם במחשב כל כך הרבה שטח אחסון, מדוע תוכניות שוכחות לרוב את כל ההגדרות שקבעתי בכל פעם שאני סוגר אותן? לדוגמה: אני אף פעם לא עורך מסמכים באופן אופיס אלא בחלון מוגדל. ברירת המחדל של אופן אופיס היא 800X600 לערך, לכן אני לוחץ על 'הגדל' תחילה ולאחר שסיימתי לעבוד אני סוגר את התוכנית. בפעם הבאה שאני מריץ אותה, אופן אופיס חוזרת לגודל מסך של 800X600 ולכן מאלצת אותי להפסיק את מה שאני עושה, כדי ללחוץ על הכפתור 'הגדל' שוב. שמירת ההגדרות והמצב האחרון בכל פעם דורשת 20 בתים לכל היותר, מחיר זניח לעומת אלפי ההקלקות המיותרות.
סייר הקבצים Natutilus של GNOME עושה את זה כמו שצריך דווקא: החל בגודל החלון, וכלה במיקום הכפתור בסרגל הגלילה, המידע נשמר עבור כל חלון כך שלאחר שבחרתי בספריה רצויה, אני יכול לשכוח מזה.
לסיכום נקודה זו:
- המחשב הוא כלי רב עוצמה, השתמשו בו
- אפשרו להבדיל בין פריטים דומים
- שמרו את הגדרות התוכנית
4) אפשרו להבדיל בקלות בין פריטים דומים ולאתרם
נקודה זו ברורה למדי: פריטים שנמצאים על המסך ומשמשים למטרות שונות, צריך שיהיה קל להבדיל ביניהם. כדוגמה קיצונית לניסיון לא מוצלח, הסתכלו למשל על סרגל המשימות של Konqueror:
הכפתור מצד שמאל הוא 'חץ למעלה' - קרוב לודאי הפקודה הכי פחות נחוצה בדפדפן. צד שמאל הוא הצד שקל יותר לאתר, לכן הפעולה השכיחה ביותר צריכה להמצא שם. בדיוק מסיבה זו הכפתור 'חזור' נמצא שם בכל דפדפן אחר שאני מכיר.
הכפתור 'חפש' ושני הכפתורים המשמשים לצורך שינוי גודל הטקסט (זום) דומים מאוד; לכפתורים 'קדימה', 'חזור', 'מעלה' ו'בית' אותו הצבע, ולכן קשה להבדיל ביניהם. אבל הכי חשוב, יש 15 כפתורים! אנחנו מסוגלים להבדיל בקלות רבה בין חמישה אובייקטים לכל היותר: לכן אנחנו יכולים לעשות זאת במהירות וללא צורך בתשומת לב מיוחדת. זו הסיבה גם לכך שדפי תיווי מכילים חמש שורות למשל. יותר מאשר חמישה פריטים גורמים לכך שאנחנו צריכים לעצור ולחשוב כדי לזהות מה הוא מה. עיצוב מוצלח יותר היה שם רק את חמשת הכפתורים השימושיים ביותר בסרגל, ועל ידי כך מפחית מהמאמץ הנדרש ברוב המקרים. ברוב היישומים יש מספר רב של פריטים בסרגל הכלים, אבל דפדפן אינטרנט לא זקוק להם. בחנתי משתמשים חדשים שעובדים עם קונקורר ויכולתי לראות בעצמי כיצד הם מתבלבלים. זה מבלבל אותי, ואני דווקא מנוסה.
דוגמה נוספת לקושי להבדיל בין פריטים אפשר למצא בערכת ברירת המחדל של GNOME. הביטו בדוגמה של בחירת טקסט בתמונה 9.
כאשר המשתמש בוחר טקסט, הוא ממוקד בטקסט הזה. אפשר להניח שהוא סימן אותו במטרה לעשות איתו משהו, אז למה הערכה גורמת לכך שצבע הרקע הופך כהה באופן שהופך את הטקסט עצמו לבלתי קריא? לא היה ראוי יותר להבליט את הטקסט דווקא, למשל על ידי הבהרת הרקע והפיכתו לקריא יותר?
לסיכום נקודה זו:
- גרמו לכך שניתן יהיה להבדיל בין פריטים שעושים דברים שונים
- אל תעתירו על המשתמש אפשרויות בחירה
- הפכו את הפריט שנבחר או סומן קל ברור וקריא
מסקנות
אלו הן רק חמש נקודות בסיסיות בעיצוב ממשק משתמש אבל הן חשובות. אין לראות בהן כללי בל יעבור או מענה לכל תחלואי ממשק המשתמש. אבל הקפדה עליהם כחלק מתהליך עיצוב הממשק יכול, לדעתי, לשפר באופן ניכר את שמישותו. אשמח לקבל הערות, תיקונים או תוספות (ראו כתובת בהמשך, הסירו את המילה nospam ).
רעיונות אלו הם רק מבוא. אני ממליץ לכל מי שעוסקים בעיצוב מממשקים בצורה רצינית לקרא את הספרות ברשימה המצורפת בהמשך. הספר של אלן קופר מצוין. הספר של ג'ף רסקין שימושי והוא כולל מספר רעיונות מעניינים מחוץ לטווח המוכר של עיצוב ממשקי משתמש.
- About Face 2.0: The Essentials of Interaction Design, Alan Cooper and Robert Reimann, 2003, Wiley
- The Humane Interface, Jef Raskin, 2000, Addison-Wesley Professional
- The Interface Hall of Shame
- Apple Human Interface Guidelines
אודות הכותב
About the author
I'm a Free Software advocate and the main developer of SiEd, a GPL-licensed text editor for Palm OS devices. In my real life, I am doing a PhD in Process Scheduling at the Centre for Process Systems Engineering, Imperial College.
This work is licensed under a Creative Commons License and is Copyright Benjamin Roe 2004.
תורגם לעברית על ידי אורי שרף עבור לינמגזין, נובמבר 2004. המדריך והתרגום זמינים עם רישיון CC. ראו הסברים כאן.