עד שאני מגיע לתרגם משהו, בדרך כלל מדובר בפוסט או מאמר מהשבועות אחרונים. נכון, מדי פעם מתפלק לי איזה פוסט על עשר המכות או על הנדסת אנוש מימי שחר הספּנוּת, אבל הרוב זה דברים ממש מהימים האחרונים, בטווח של שני שינויי ממשק בפייסבוק. ובכן, המאמר הזה נכתב לפני 12 שנה, אבל זה לא מפחית מהרלוונטיות שלו. נתקלתי בו במקרה, וכמובן שאחרי המשפט הראשון לא הייתה לי ברירה אלא לנסות לפתור את הבוחן, ואני לא אטען שידעתי לענות נכון על הכל.
זה מאמר מאוד ייחודי בזה שהוא בבת אחת מעניין, "פותח את הראש", ומאוד רלוונטי לעבודה היומיומית. והוא גם חושף מדוע אנשים מרגישים שכל-כך כיף להם לעבוד עם המוצרים של אפל, ושלא מדובר רק בעיצוב גראפי ושיווק.
ברוס טוגנאזיני (Bruce Tognazzini), שהיה פעם עובד מספר 66 בחברת אפל, הוא היום אחד השמות הגדולים של עולם ה-UX. היום הוא חלק מקבוצת נילסן נורמן, לפני כן הוא עבד בחברת סאן, אבל את עיקר תהילתו הוא הרוויח במהלך 14 השנים בהן ייסד והוביל את תחום ממשקי המשתמש באפל.
הבוחן שייתן לכם את פיטְס ('The Quiz Designed to Give You Fitts)
מאת ברוס טוגנאזיני. פורסם במקור באתר AskTog בפברואר 1999.
תורגם ברשות המחבר ע"י ויטלי מיז'יריצקי.
אז אתם חושבים שאתם מעצבי אינטראקציה? לא אם אינכם יכולים לענות על כל השאלות הבאות במהירות ובאופן סמכותי.
אם אינכם מעצבי אינטראקציה, אבל אתם מכירים כאלה – או שאתם שוקלים לשכור כאלה – הציגו להם רק את השאלות ותראו איך הולך להם. השתמשתי בגרסאות שונות של הבוחן בראיונות במשך שנים, עם תוצאות יפות.
השאלות והתשובות מניחות שיש לכם שליטה מלאה על כל נדל"ן המסך, על מערכת ההפעלה וכולי. פשוט העמידו פנים שאתם המעצבים הראשיים של מיקרוסופט או של אפל.
גם אם אתם חדשים בענייני פיטְס, תעשו את הבוחן לפני שאתם מסתכלים על הטקסט שבא אחריו. התשובות בכל מקרה ילמדו אתכם את העקרונות הפועלים, אבל ניסיון לפתור את הבוחן לפני כן יבהיר לכם את ההנחות שהשתמשתם בהן בעבר. לאחר מכן אתם יכולים לאמוד את ההנחות האלו לעומת התשובות שבהמשך. ואל תרגישו רע עם התוצאות ההתחלתיות שלכם: הרוב המוחלט של האנשים, אפילו כאלה שעוסקים שנים בתחום המחשבים, מגיעים לתוצאות נמוכות בפעם הראשונה שלהם. החדשות הטובות הן שהם מצליחים מאוד בפעם השנייה, ורבים חושבים שזה המאמר המועיל ביותר באתר הזה, והוא בעל השלכות מיידיות וקבועות על עבודת האפיון שיעשו בהמשך.
הבוחן
אולי כדאי לקרוא בהתחלה את כל השאלות (אבל לא התשובות!), פשוט כדי להבין במה מדובר. לאחר מכן תחזרו ותענו עליהן. ובאמת חייבים לענות עליהן. זה לא בוחן שבו אפשר להסתכל על שאלה ולהגיד "אה, בטח, את זה אני יודע", ולהמשיך הלאה. כאן ממש צריך לנסח את התשובה (אחרת זה נחשב כטעות).
אין בפנים שום טריקים, הכל פשוטו כמשמעו. אולם השאלות עשויות להראות מנוגדות לאינטואיציה או לניסיון עבר, כך שהתשובות הברורות מאליהן עשויות לא להתאים.
-
סרגל הכלים של מיקרוסופט מציע למשתמש את האופציה של הצגת תווית מתחת לכל כלי. מצאו סיבה אחת לפחות לכך שהגישה לכלים בעלי תוויות היא מהירה יותר (הניחו לצורך השאלה שהמשתמש מכיר את הכלי ולא צריך את התווית כדי לזהותו).
-
ש לכם מבחר של כלים בתוכנה גראפית, שבנויה ממטריצה של אייקונים 16X16 פיקסל, המסודרים בטבלה 8X2 שמוצמדת לקצה השמאלי של המסך. מבלי להזיז את הטבלה מהקצה השמאלי של המסך ומבלי לשנות את גודל האייקונים, באילו צעדים ניתן לנקוט כדי לצמצם את הזמן הדרוש בשביל לגשת לכלי ממוצע?
-
ידוע שמשתמש ימיני נמצא כרגע בטווח של 10 פיקסל מהמרכז המדויק של מסך גדול, ברזולוציה של 1200X1600. יש למקם על המסך מטרה בגודל פיקסל אחד, שהמשתמש צריך להצביע עליה באופן מדויק. מנו חמישה מיקומים של פיקסלים על המסך, שהמשתמש יכול להגיע אליהם במהירות הגבוהה ביותר. נקודות בונוס למי שמונה אותם בסדר של מהירות גישה יורדת.
-
מיקרוסופט מציעה סרגל משימות (taskbar) שניתן להצמיד אותו לראש המסך, לצדדיו או לתחתית שלו, ולאפשר למשתמשים להגיע לאפליקציות ולחלונות נסתרים. שורת המשימות יכולה להיות חבויה או מוצגת תמידית. מנו לפחות שתי סיבות מדוע אופן חשיפת סרגל המשימות החבוי הוא בלתי יעיל להחריד.
-
הסבירו מדוע זמן הגישה אל התפריט הנפתח (pull-down menu) של המקינטוש קצר לפחות פי חמש מאשר בתפריט נפתח של חלונות. נקודות בונוס למי שיציע לפחות שתי סיבות לכך שמיקרוסופט קיבלה החלטה שהיא מטופשת באופן כה בולט.
-
מהו צוואר הבקבוק בתפריטים הירארכיים ומהן השיטות שמפחיתות את חומרת צוואר-הבקבוק הזה?
-
מנו לפחות יתרון אחד שיש לתפריטים צפים מעגליים (circular popup menus) על פני תפריטים צפים ליניאריים רגילים.
-
מה ניתן לשנות בתפריטים צפים ליניאריים כדי לאזן טוב יותר את זמן הגישה לכל הפריטים?
-
המעצבים התעשייתיים שתפרעו על המאק דפקו את רוב המקלדות בכך שחתכו לחצי את מקשי הפונקציות, וצמצמו את העומק הכולל של המקלדת בחצי מקש. מדוע זה היה מטופש בצורה קיצונית?
-
מה משותף לפתרונות העיקריים לכל השאלות האלו?
אם אינכם יכולים לענות על השאלה האחרונה, יהיו לכם כל מני בעיות עם השאלות האחרות. אתם לא לבד, כמובן, ויש המון עדויות לכך שאף אחד במיקרוסופט ופחות ופחות אנשים באפל יודעים לענות על השאלות האלו.
למיקרוסופט יש סוג של תירוץ. מלכתחילה הם טענו שממשק ויזואלי, עם העכבר וכל השטויות האלה, הוא נחות בהשוואה לממשק המקלדת. אז הם היו יכולים להראות מטופשים אילו הם באמת היו מנסים לבנות GUI אמיתי. על ידי חבלה עקבית בממשק הויזואלי, הם מנעו מעצמם את המבוכה הזו.
מה שקרה באפל הוא קצת יותר מסתורי. פאשלות העיצוב התעשייתי הן דבר שיש לצפות לו. המעצבים התעשייתיים החיצוניים של אפל מאז ומעולם נעו בין חוסר מושג לעוינות בכל מה שנוגע לגורמי אנוש. אולם לאחרונה אפל עשתה כמה דברים מטופשים מאוד גם בתוך החברה. כגון הפיכת תפריט התוויות המהיר לתפריט הירארכי, מה שהאט אותו פי חמש עד עשר.
התשובות
בואו נתחיל עם תצוגה מקדימה של התשובה לשאלה 10, החוק של פיטְס, מאחר ויתר התשובות סובבות סביבו. מתוך "עקרונות ראשונים של עיצוב":
חוק פיטס: “הזמן הנדרש כדי להשיג מטרה הוא פונקציה של המרחק אל המטרה והגודל שלה.”
עובדה זו, קטנה וברורה מאליה, זוכה להתעלמות כה גורפת, שלפעמים אני תוהה שמא זה מכוון. אבל לרוב זהו רק סממן של בורות כללית המוגברת ע"י אמונות תפלות, ואינה מוכתמת בעוּבדות או במחקר כלשהו.
למזלי, קוראי AskTog, העקשנים כשם שהם מהירי תפיסה, יודעים בדיוק מהו חוק פיטס, או לחילופין יידעו את זה לפני שהם הולכים לישון הלילה.
החוק של פיטס הוא פשוט, מוחלט, ובלתי משתנה. בואו נראה כיצד הוא נוגע לשאלות:
שאלה 1
סרגל הכלים של מיקרוסופט מציע למשתמש את האופציה של הצגת תווית מתחת לכל כלי. מנו סיבה אחת לפחות לכך שהגישה לכלים בעלי תוויות היא מהירה יותר (הניחו לצורך השאלה שהמשתמש מכיר את הכלי ולא צריך את התווית כדי לזהותו).
הנה שתי תשובות. ייתכן שיש יותר.
התווית הופכת להיות חלק מהמטרה. אפוא המטרה גדלה. ההגעה למטרות גדולות יותר, כששאר המשתנים שווים, תמיד תהיה מהירה יותר. חוק פיטס.
כשלא משתמשים בתוויות, האייקונים של הכלים מצטופפים קרוב יותר זה לזה.
במבט ראשון אפשר לראות בצפיפות האייקונים יתרון, מאחר וזה מצמצם את המרחקים בין המטרות. אולם המטלה כאן אינה לדלג ממטרה למטרה. למעשה, ברגע שהמשתמש מחליט לגשת לסרגל הכלים, נקודת המוצא שלו לרוב תהיה במקום כלשהו באזור התוכן, הרחק מכל המטרות.
כשהאייקונים מרווחים, המשתמשים נהנים מאזור חיץ בין האייקונים, אזור שבתוכו לחיצה שגויה לא תבצע כל פעולה. ואילו כאשר האייקונים צפופים, קיימת סבירות גבוהה יותר לכך שהמשתמש יפעיל פעולה בלתי רצויה. כדי להימנע מאפשרות זו, המשתמשים שעובדים ללא תוויות לומדים להאט בהרבה את תנועותיהם (אל תטרחו לשאול אותם האם הם האטו. הם יגידו לכם שזה הגדיל את מהירותם. רק שעון העצר יודע בוודאות).
דרך נוספת להגדיל את המטרות היא כמובן בחירה באייקונים גדולים על פני הקטנים. אפשר לרחם על אותו "משתמש על" עם האייקונים בגודל 4X4 שחושב שהוא עובד מהר יותר.
שאלה 2
יש לכם מבחר של כלים בתוכנה גראפית, שבנויה ממטריצה של אייקונים 16X16 פיקסל, המסודרים בטבלה 8X2 שמוצמדת לקצה השמאלי של המסך. מבלי להזיז את הטבלה מהקצה השמאלי של המסך ומבלי לשנות את גודל האייקונים, באילו צעדים ניתן לנקוט כדי לצמצם את הזמן הדרוש בשביל לגשת לכלי ממוצע?
ייתכן שנזדקק לשני צעדים נפרדים כדי לצמצם את זמן הגישה הממוצע. שניהם חשובים.
א. יש לשנות את הטבלה ל-16X1, כך שכל הכלים יימצאו לאורך קצה המסך.
ב. יש לוודא שהמשתמש יכול לבחור כלי בלחיצה על שורת הפיקסלים הראשונה הצמודה לקצה המסך. לא אמור להיות שום אזור חיץ.
הצעד השני הוא חיוני, ולעיתים מאוד קרובות מתעלמים ממנו.
זכרו שחוק פיטס קובע שזמן הגישה הוא פונקציה של מרחק ושל גודל מטרה. אם המטרה גדולה יותר, אז הזמן קטֵן. הוא קטן מסיבה פשוטה: המשתמש אינו נדרש להאט בהתקרבו אל המטרה מהחשש לדלג עליה.
כעת תחשבו על קצה המסך. עד כמה המטרה עמוקה? אם היא באמת הייתה בגודל של פיקסל, כפי שהיא נראית, אז באמת היה קשה מאוד לפגוע בה. אולם מכל בחינה מעשית קצה המסך הוא בעל עומק אינסופי. לא משנה עד כמה גדולה מהירותו של העכבר כשהוא פוגע בקצה המסך, סמן העכבר לא יכול לדלג על המטרה הזו. נדרש הרבה יותר זמן כדי לפגוע בפיקסל שנמצא שני פיקסלים פנימה מקצה המסך, מאשר בקצה עצמו. השתמשו בקצה הזה. הקצה הוא חבר שלכם.
שאלה 3
ידוע שמשתמש ימיני נמצא כרגע בטווח של 10 פיקסל מהמרכז המדויק של מסך גדול, ברזולוציה של 1200X1600. יש למקם על המסך מטרה בגודל פיקסל אחד, שהמשתמש צריך להצביע עליה באופן מדויק. מנו חמישה מיקומים של פיקסלים על המסך, שהמשתמש יכול להגיע אליהם במהירות הגבוהה ביותר. נקודות בונוס למי שמונה אותם בסדר של מהירות גישה יורדת.
לא, זאת לא שאלה מכשילה. וכל מעצב אינטראקציה צריך להיות מסוגל לתת תשובה מיידית על החלק הראשון. שאלת הבונוס היא כבר פחות פשוטה. אבל קודם כל, מיקומי חמשת "הפיקסלים הקסומים":
הפיקסל הראשי נמצא במיקומו הנוכחי של סמן העכבר. תפריטים צפים עושים שימוש בפיקסל הזה, כשהם מופיעים במיקום יחסי אל סמן העכבר, ללא קשר למיקומו. הפיקסל הזה לא דורש לעבור כל מרחק בדרך אליו, ולמעשה מהווה מטרה בעלת גודל אינסופי – לא ניתן לפספס אותה.
ארבעת הפיקסלים הנותרים ממוקמים, בממוצע, הכי רחוק שאפשר להגיע מסמן העכבר. אולם גודל המטרה שלהם מפצה בהחלט על המרחקים שלהם ממנה, מאחר והוא אינסופי בשני ממדים. הפיקסלים הקסומים האלה הם ארבע פינות המסך. זרקו את העכבר בכל כיוון שתרצו, ורוב הסיכויים הם שאם זרקתם אותו במספיק כוח, הוא יגיע לאחת מארבע הפינות האלה. זאת תחת ההנחה שפונקציית ההאצה של העכבר אופיינה כהלכה.
המפתח לשאלת הבונוס הוא ביד ימין הדומיננטית של המשתמש. משתמש ימיני יכול להגיע, בסדר קושי גובר והחל בנקודה שכבר הזכרנו:
– אל הפיקסל הנמצא במיקומו הנוכחי של העכבר: לחץ על העכבר וכבר הגעת אליו.
– אל הפינה הימנית התחתונה.
– אל הפינה השמאלית העליונה.
– אל הפינה הימנית העליונה.
– אל הפינה השמאלית התחתונה.
אם תחזיקו את העכבר ביד ימין ותזיזו את העכבר, תוך שימוש רק במפרק כף היד ובכף היד, בארבע הכיוונים השונים, תראו כיצד זה נובע מהמכאניקה של כף היד. התשובות עבור משתמשים שמאליים הן כמובן הפוכות.
ההבדלים האלה קטנים יחסית, בהשוואה לכוחם של "הפיקסלים הקסומים". כל ארבע הפינות צריכות להיות בשימוש, ובשימוש טוב.
שאלה 4
מיקרוסופט מציעה סרגל משימות (taskbar) שניתן להצמיד אותו לראש המסך, לצדדיו או לתחתית שלו, ולאפשר למשתמשים להגיע לאפליקציות ולחלונות נסתרים. שורת המשימות יכולה להיות חבויה או מוצגת תמידית. מנו לפחות שתי סיבות מדוע אופן חשיפת סרגל המשימות החבוי הוא בלתי יעיל להחריד.
בשלב הזה כבר אמור להיות קל יותר לענות על השאלות.
צדדי המסך הם נדל"ן משובח. לא מבזבזים צד שלם שעשוי היה לאכסן כמה עשרות פריטי גישה מהירה, על אובייקט אחד בלבד – שורת המשימות. את שורת המשימות שמוסתרת אוטומטית, הרבה יותר מדי קל לחשוף בצורה לא מכוונת. המשתמשים כל הזמן מפעילים אותה כשהם מנסים לגשת למשהו שנמצא קרוב אל קצה המסך, אבל לא ממש עליו.
שורת המשימות לא הייתה סובלת מאף אחת מהבעיות האלו, והגישה אליה הייתה מהירה עוד יותר, אילו מוקמה באחת מפינות המסך. למשל, זרקו את העכבר למעלה ושמאלה ותחשפו את שורת המשימות. גישה מהירה ללא ההפעלה הלא-מכוונת.
שאלה 5
הסבירו מדוע זמן הגישה אל התפריט הנפתח (pull-down menu) של המקינטוש קצר לפחות פי חמש מאשר בתפריט נפתח של חלונות. נקודות בונוס למי שיציע לפחות שתי סיבות לכך שמיקרוסופט קיבלה החלטה שהיא מטופשת באופן כה בולט.
מיקרוסופט, סאן ואחרות החליטו לחבר את סרגל התפריט אל החלון, ולא בראש המסך, כפי שעשתה אפל. ההחלטה נבעה משתי סיבות לפחות:
אפל תבעה זכויות יוצרים והוציאה פטנט על סרגל התפריט שלה.
כל השאר הניחו שקירוב סרגל התפריט אל המשתמש, ע"י מיקומו בראש החלון, יזרז את העבודה.
גדודים של עורכי דין דנו בנקודה הראשונה. בואו נדבר אנחנו על השנייה. סרגל התפריט של אפל הוא הרבה יותר מהיר מסרגלי התפריטים בחלונות. מדוע? כי עקב מיקומו בקצה המסך, יש לו גובה אינסופי. כתוצאה מכך, משתמשי המאק יכולים פשוט לזרוק את העכברים שלהם לכיוון הצד העליון של המסך, בידיעה גמורה שהוא לעולם לא יחדור אותו וייעלם.
כמובן שזה קורה רק אם אני לא בוחן את המשתמשים באותו רגע. באפל ערכתי מבחן שבו הרכבתי מסך אחד מעל השני, כשסרגל התפריט היה בראש המסך התחתון. הדרך היחידה שבה המשתמשים יכלו להגיע אל המסך העליון הייתה לחצות את התפריט בדרך.
לאחר מכן נתתי למשתמשים את המשימה של לגשת כל הזמן לפריטי תפריט. כשהם רק התחילו, הם היו נכנסים למסך העליון למרחק של כ-15 סנטימטר בממוצע, רק בגלל שמהירות העכבר שלהם הייתה כה גבוהה. לאחר מכן הם למדו שהם צריכים להאט וממש לכוון אל התפריט. כשהם הסתגלו למצב, זמני הגישה שלהם אל התפריט הפכו לכל כך איטיים, שלקח להם בערך את אותו הזמן כמו למשתמש חלונות ממוצע.
ה"יתרון" השני המיוחס בדרך כלל לתפריט בראש החלון הוא שהמשתמשים תמיד יודעים היכן לחפש את הפריטים הקשורים למשימה אותה הם מבצעים. זה מטופש. המשתמשים עשויים לעשות משימות שונות בחלון נתון, ופריטי התפריט עשויים להשתנות. לא רק זה, אלא שקיימות גם המון אפליקציות מעוותות, במיוחד בעולמה של סאן, שבהן סרגל התפריט הנחוץ לא נמצא אפילו בחלון שבתוכו עובדים! זה ממש מוזר ושובר את הראש.
האפליקציות של מיקרוסופט מתחילות להציע את האפשרות של סרגל תפריט בראש המסך – במצב של מסך מלא. נסו זאת בוורד או באקסל, זה הרבה יותר מהיר. אולם חוסר המושג הכללי של מיקרוסופט מעולם לא הופגן בצורה כה ברורה כפי שזה קורה במיקרוסופט ויז'ואל סטודיו, שבו יש סרגל תפריט בראש המסך, עם מחיצה בעובי של פיקסל בין קצה המסך והתפריט. זה מה שנקרא להפסיד בנס ברגע האחרון.
שאלה 6
מהו צוואר הבקבוק בתפריטים הירארכיים ומהן השיטות שמפחיתות את חומרת צוואר-הבקבוק הזה?
צוואר הבקבוק הוא המעבר בין הרמה הראשונה והשנייה של התפריט. בהתחלה המשתמשים מזיזים את סמן העכבר למטה לקטגוריה הנכונה. לאחר מכן, הם צריכים להזיז אותו בזהירות בקו אופקי אל התפריט המשני.
נראה שאצל המהנדס שעיצב במקור את התפריטים ההירארכיים, האמה הייתה מורכבת על מסילה, והוא היה מסוגל להזיז אותה בצורה אופקית לחלוטין ללא כל מרכיב של תנועה אנכית. אולם אצל רובנו הזרועה מורכבת דווקא על ציר, שנקרא "המרפק". זה אומר שהזזת היד יוצרת צורה של קשת ולא קו ישר. הדרישה שאנשים בעלי ציר יזיזו את העכבר בקו אופקי ישר היא פשוט שגויה. באופן טבעי נחליק כלפי מטה כשאנחנו מנסים לזוז ימינה. כשאסור לנו להחליק למטה, התפריט שאנחנו מחפשים ייסגר ממש רגע לפני שנגיע אליו.
מפתחי חלונות המציאו טריק כדי להתגבר על עניין הציר: אם הם רואים שהמשתמש זז כלפי מטה אל תוך השטח של הפריט הבא בתפריט הראשי, הם לא סוגרים מיידית את התפריט המשני. למעשה הם משאירים אותו פתוח לעוד כחצי שנייה, כך שמשתמשים זריזים יכולים לא לדייק, ועדיין להגיע אל התפריט המשני לפני שהוא נסגר. למרבה הצער, קיימת תופעה ידועה שבמצב של סבירות גבוהה לטעות, אנשים נוטים להאט ולא להאיץ. לכן, מעטים הם המשתמשים שיבינו אי-פעם שתנועה מהירה יותר יכולה לפתור את הבעיה שלהם. הפתרון של מיקרוסופט שגוי לחלוטין.
כשאפיינתי את אלגוריתם התפריט ההירארכי של המאק באמצע שנות ה-80, הגדרתי אזור חיץ בצורת >, כך שלמשתמשים יהיה מרווח טעות גדול יותר ככל שהם מתקרבים אל התפריט, מבלי שיחששו שהם נכנסים לתפריט לא רצוי. כל עוד בממוצע הסמן של המשתמש זז כמה פיקסלים הצידה עבור כל פיקסל למטה, התפריט נשאר פתוח, לא משנה עד כמה התנועה הייתה איטית (ועדיין היה קל לבטל – פשוט תזוזו למטה או למעלה בכוונה). התפריטים ההירארכיים של אפל עדין היו פחות יעילים מתפריטים שטוחים, עקב המטרה הנוספת, אבל לפחות הם היו פחות מאתגרים מאשר משחק המחשב הממוצע.
למרבה הצער, אנשי NeXT, בהגיעם לאפל, העתיקו את חלונות ולא את המאק, כשהם עיצבו את ממשק התפריט ההירארכי ל-OSX. היום, התפריטים ההירארכיים של המאק קשים לשימוש בדיוק כמו אלה של חלונות.
החוק של פיטס לא עוסק רק בגודל מטרה ובמרחק; הוא עוסק גם במספר המטרות. ככל שיש יותר מטרות, כשכל המשתנים שווים, כך יגדל הזמן הדרוש לביצוע המטלה. תפריטים הירארכיים מוסיפים מטרה אחת באופן אוטומטי. יצירת קושי בהגעה אל התפריט המשני מוסיפה מטרה שנייה – התפריט המשני עצמו.
עם התפריטים ההירארכיים שלי, על מאקים שלפני OSX, ברוב המקרים המשתמשים אפילו לא היו צריכים לחשוב על הגעה אל התפריט המשני. התפריט היה נפתח, והמשתמש פשוט כיוון אל הפריט הרצוי. הפעם היחידה בה המשתמש היה צריך לחשוב על התפריט המשני כשלעצמו הייתה כשהיו בו כל כך הרבה פריטים שהפריט הרצוי היה מאוד גבוה או מאוד נמוך ברשימה, מחוץ לטווח הקשת הנתמכת. ואפילו במקרים האלה, המשתמשים בדרך כלל היו יוצרים קשת תלולה יותר כדי להגיע אל הפריט בתנועה אחת, במקום לשבור את התנועה לסדרה של תזוזות מזגזגות שהמשתמשים יוצרים עם התפריטים ההירארכיים של היום.
כשאתם מאפיינים את התנועות הנדרשות מהמשתמש, צמצמו את מספר התנועות הנדרש, יחד עם המרחק והדיוק שנדרשים עבור כל תנועה, ולאחר מכן חשבו על כיצד התנועות המוצעות שלכם ממופות ביחס ליכולתו של האדם לבצע אותן.
שאלה 7
מנו לפחות יתרון אחד שיש לתפריטים צפים מעגליים (circular popup menus) על פני תפריטים צפים ליניאריים רגילים.
כשהאופציות מוצגות סביבך במעגל, אתה צריך לעבור רק פיקסל או שניים כדי להיכנס ל"חתיכת העוגה" הרצויה. פחות תנועה וגודל מטרה טוב. עיצוב טוב.
יש להם יתרון נוסף, וזה של ההזנה לא רק של מרחק אלא גם של כיוון אל תוך הזיכרון המוטורי שלכם. כל עוד האופציות הן מספיק מעטות, די מהר תלמדו להזיז את העכבר למעלה ושמאלה כדי להדפיס, למטה וימינה כדי לפקסס, וכו'. למעשה, ברגע שהתנועות הפשוטות האלה יילמדו, לא יהיה צורך אפילו להציג את התפריט, אלא אם המשתמש משתהה מספיק זמן כדי שיהיה ברור שאינו בטוח (זה נולד במהלך פריקט Fabrik באפל בשנות ה-80 המאוחרות).
שאלה 8:
מה ניתן לשנות בתפריטים צפים ליניאריים כדי לאזן טוב יותר את זמן הגישה לכל הפריטים?
אפשר "לפַטְסֵס" אותם באמצעות הגדלת הפריטים המרוחקים מהעכבר. הם לא חייבים להיות יותר גדולים פיזית, מאחר והמשתמשים אינם מתקשים לראות את הפריטים המרוחקים. אלא המיפוי של עכבר למסך צריך להיות כזה שככל שהמשתמש מתרחק ממרכז התפריט, נדרשת תנועה גדולה יותר של העכבר כדי לעבור מרחק מסוים עם הסמן. בפועל, אתם מנתקים את המפה ההתנהגותית של המסך מהמפה החזותית.
טריקים אחרים שמערבים ניתוקים כאלה כוללים הגדרה של כוח משיכה מקומי, כך שברגע שהעכבר מתקרב אל המטרה, הוא נמשך אליה. ניתן גם להקים מחסומים, כך שברגע שהעכבר מגיע אל אובייקט, קשה לו יותר לחצות אותו ולצאת מהצד השני. זה עשוי לתסכל. אילו היה קיים עכבר שמזהה לחץ משתנה, שהיה יכול "לפרוץ" את המחסום במקרה של לחץ מוגבר, הוא היה מאפשר למשתמש להיתפס ע"י האובייקט, או לחילופין לעבור אל השטח שמאחוריו.
הקורא ויקטור זמברנו הציע שיטה אחרת שיכולה לצמצם את זמן ההגעה למטרה: למרכז את התפריט המשני, כך שאף פריט לא מרוחק מהעכבר יותר מ-(סך הפריטים חלקי שתיים), כפי שויקטור מדגים מטה:
שאלה 9
המעצבים התעשייתיים שתפרעו על המאק דפקו את רוב המקלדות בכך שחתכו לחצי את מקשי הפונקציות, וצמצמו את העומק הכולל של המקלדת בחצי מקש. מדוע זה היה מטופש בצורה קיצונית?
ככל שהמטרה רחוקה יותר, כך עליה להיות גדולה יותר כדי לשמור על מהירות הגישה. לא רק שהמעצבים צמצמו את גודל המטרה, אלא הם הקטינו אותה בדיוק במימד הקריטי ביותר. מטופש, מטופש, מטופש. מה שהם היו צריכים לעשות זה לעגל את המקלדת בחדות כלפי מעלה ליד הקצה האחורי, כך שהרמה של אצבע אחת בכמה מעלות תאפשר לגשת למקשי הספרות ומקשי הפונקציות, ואז הדיוק והמהירות ישתפרו.
שאלה 10
מה משותף לפתרונות העיקריים לכל השאלות האלו?
עכשיו אתם יודעים שמדובר בחוק פיטס. ואתם יכולים להשתמש בו בעיצוב ביומיום, בין אם אתם בונים מערכת הפעלה חדשה או מאפיינים דף אינטרנט. כשכפתור ה-OK הזה, שיש עליו שני תווים בלבד, הופך להיות ממש קטן, תשקלו להוסיף לו כמה רווחים בשני הצדדים כדי להרחיב אותו. אם יש לכם שליטה אמיתית על הסביבה שלכם ואתם מסדרים סרגל כלים, וודאו שהמשתמש יכול לגשת אל הכלים, בכך שתצמידו אותם לקצה המסך. אם יש לכם סרגלי תפריט בראש המסך, השתמשו בהם! הם תופסים הרבה פחות מקום מאוסף של אייקונים או כפתורים, ואם תעשו עליהם בדיקות משתמשים, תגלו שהם מהירים יותר. ואם אתם עובדים במיקרוסופט או באפל, תחשבו על להקשיב לאנשים שיש להם מושג בעיצוב אינטראקציה. הם באמת קיימים. דיברתי איתם בעבר. גם לכם כדאי לנסות לדבר איתם.
אני אסיר תודה לפראנק לודולף וקרייג אושימה על כך שעברו את המבחן ומצאו הרבה תשובות נכונות נוספות, שאת כולן ניסיתי לכלול כאן.
אם ברצונכם לקרוא עוד על חוק פיטס, אני מאוד ממליץ:
Walker, Neff and Smelcer, John (1990). "A Comparison of Selection Time from Walking and Bar Menus." Proceedings of CHI’90, Addison-Wesley, Reading, Mass., pp. 221-225.
ומה באשר להצלחתכם? אם כעת אתם יכולים לענות על 10 מתוך 10, מתוך הבנה, ואם אתם מוכנים ליישם את השיעורים שלמדתם, זה כל מה שמשנה.
ויטלי, תודה. מאמר מעניין ותרגום טוב 🙂
מתסכל שבעיצוב לאינטרנט אין פינות או קצוות, ושימוש בתפריטי הקשר לא מקובל ולרוב המשתמשים לא ישימו לב אליהם אם לא תספר להם.
בדקתי עכשיו בזריזות, ואולי אפשר לשאוף לשים דברים בקצה השמאלי – יש סבירות לא רעה שהוא יהיה צמוד לקצה המסך. הקצה הימני לא רלוונטי בגלל פס הגלילה.
תודה לך 🙂
זה אכן מבאס. כמו גם זה שאפילו באפליקציות, אם אני אתחיל פתאום לאפיין את פונקציית התאוצה של העכבר, מנהל המוצר יחשוב שנפלתי על הראש.
ולגבי האינטרנט – הסתכלתי עכשיו בג'ימייל בכרום, ואזור הרגישות של הלייבלים באמת מגיע עד הפיקסל האחרון משמאל. מייל, אנשי קשר ומשימות לא מגיעים עד לשם, אבל האינבוקס וכל מה שנמצא תחתיו (עד הצ'אט אצלי) – כן מגיע.
תודה על התרגום.
היה מעניין לראות עוד דוגמאות ליישום פיטס על אתרי אינטרנט (כמו שציינת בתגובה בקשר לג'ימייל).
בשמחה!
כן, גם לי. אם עובדים במסך מלא באמת (full-screen), אז גם הטאבים העליונים של ג'ימייל (קאלנדר, דוקס – אלה) הם באמת צמודים לקצה העליון של המסך ומגיבים כבר מהפיקסל הראשון, אבל מי עובד במסך מלא…
כפי שרוני ציין, הצד הרלוונטי היחיד הוא הקצה השמאלי, להוציא אפליקציות ווב שאין בהן גלילה, ואז בעיקרון גם הצד הימני יכול להיות רלוונטי.
[…] היה כל כך יעיל. מי שהייתה לו הסבלנות לקרוא את תרגום המאמר על חוק פיטס היה אמור כבר להבין את זה לבד, אבל סבלנות זה אולי באיזה […]