נתקלתי בשתי תמונות מעניינות. הראשונה היא המסך המודלף של אקספלורר 10.
והשנייה היא זו:
אולי בתמונה הזו שצולמה בעמק סונומה שבקליפורניה אין שום דבר שמתקשר מיידית לחוויית משתמש, אבל אם נקח כמה שנים אחורה, לפני שנשתלו הגפנים הללו, ונתפוס את העמק ביום של שמיים קצת יותר כחולים, יש לנו סיכוי לא רע לראות את העמק כך:
ולמי שרוצה לקפוץ לשם בעצמו, המקום נמצא כאן.
הכרתי פעם איזה חמש בדיחות שיכולות היו להתחיל את הפוסט הזה, אבל אני לא זוכר אותן. וכנראה שלפחות ארבע מהן היו ברוסית, וזה אף פעם לא עובד בתרגום. לכן רק אסביר בקצרה מה זה קארגו קאלט (cargo cult) , ומי שבכל זאת מעוניין לגלות את העולם הביזארי של בדיחות רוסיות, מוזמן לקרוא את הרשומה המדהימה הזאת בוויקיפדיה. אני מבטיח לכם שעה של WTF אנתרופולוגי טהור.
כמו כל דבר אחר בעולם, גם המושג קארגו קאלט מוסבר בוויקיפדיה, אבל מאחר וכותרת העמוד שם היא "כת מטען", מה שמעיד על חוסר הבנה בסיסי של המושג, אני מעדיף את התיאור של ריצ'רד פיינמן: בזמן מלחמת העולם השנייה כמה מהשבטים הפרימיטיביים המאכלסים איים באוקיינוס השקט נפגשו עם התרבות המערבית. הם ראו מטוסים שנוחתים על האיים שלהם ומביאים איתם סחורה וכל מיני דברים מופלאים. הם רוצים שהמטוסים יחזרו, ולכן הם מנסים לשחזר את התופעה – הם מפנים רצועות שטח ארוכות, מדליקים מדורות לצידי 'מסלול הנחיתה' הזה, בונים בקתה גבוהה שבה יושב אדם עם חתיכות עץ על ראשו, ועל הגג מותקנים מקלות במבוק גבוהים – זה מגדל הפיקוח עם הפקח בעל האוזניות ועם האנטנות על הגג. וכך הם מקווים להביא את המטוס. זו דוגמא אחת, הדוגמא הקלאסית, למה שמכונה "קארגו קאלט".
הנה דוגמא נוספת.
עד שאני מגיע לתרגם משהו, בדרך כלל מדובר בפוסט או מאמר מהשבועות אחרונים. נכון, מדי פעם מתפלק לי איזה פוסט על עשר המכות או על הנדסת אנוש מימי שחר הספּנוּת, אבל הרוב זה דברים ממש מהימים האחרונים, בטווח של שני שינויי ממשק בפייסבוק. ובכן, המאמר הזה נכתב לפני 12 שנה, אבל זה לא מפחית מהרלוונטיות שלו. נתקלתי בו במקרה, וכמובן שאחרי המשפט הראשון לא הייתה לי ברירה אלא לנסות לפתור את השאלון, ואני לא אטען שידעתי לענות נכון על הכל.
זה מאמר מאוד ייחודי בזה שהוא בבת אחת מעניין, "פותח את הראש", ומאוד רלוונטי לעבודה היומיומית. והוא גם חושף מדוע אנשים מרגישים שכל-כך כיף להם לעבוד עם המוצרים של אפל, ושלא מדובר רק בעיצוב גראפי ושיווק.
ברוס טוגנאזיני (Bruce Tognazzini), שהיה פעם עובד מספר 66 בחברת אפל, הוא היום אחד השמות הגדולים של עולם ה-UX. היום הוא חלק מקבוצת נילסן נורמן, לפני כן הוא עבד בחברת סאן, אבל את עיקר תהילתו הוא הרוויח במהלך 14 השנים בהן ייסד והוביל את תחום ממשקי המשתמש באפל.
השאלון שייתן לכם את פיטְס ('The Quiz Designed to Give You Fitts)
מאת ברוס טוגנאזיני. פורסם במקור באתר AskTog בפברואר 1999.
תורגם ברשות המחבר ע"י ויטלי מיז'יריצקי.
לפני כמה חודשים נסעתי ברכבת והבחנתי בבחורה שהקלידה הודעת SMS על מסך המגע של הנייד שלה. אך מה שייחד אותה בין מאות הבחורות האחרות שמקלידות הודעות SMS על מסכי המגע של הניידים שלהן הוא שהיא השתמש במקלדת הטלפונית הישנה, רק שזו הייתה מוצגת על מסך מגע. במילים אחרות, זה נראה בערך כך, חוץ מזה שזה לא היה אייפון:
אני הגבתי בהלם קל. מדוע היא לא משתמשת במקלדת המלאה? מדוע בכלל יש אפשרות להקליד SMS על הדבר הזה? כנראה שלא צריך להוריד את האותיות לחלוטין, כדי שנוכל להמשיך להקליד מספרי טלפון בסגנון של מילה-1-800-800. אבל אם כך, אין סיבה לכלול בה אותיות עבריות, ונראה גם שאין סיבה להציג את כל המקלדת הזו מחוץ לאפליקציית החייגן. המקלדת שמוצגת בהקשר של הקלדת טקסט צריכה להיות מקלדת QWERTY מלאה רגילה.
אבל מצד שני, אצבעותיה של הבחורה ברכבת נעו במהירות שבד”כ מלווה בקריירת פסנתרות מפוארת, ואני נזכרתי במאמצים שהשקעתי בזמנו כדי לדכא את רפלקסי ההקלדה הטלפונית הקלאסית, אותם פיתחתי וטיפחתי במשך עשור, ולהתחיל להקליד במהירות סבירה במקלדת ה-QWERTY המוקטנת הפיזית של הפאלם פרה:
וכאן נשאלת השאלה: האם, בתור ממשקולוגים, אנחנו צריכים לאפשר למשתמש לדבוק בתהליכי עבודה מיושנים ולא אופטימליים, אבל כאלו שהוא מיומן בהם (קרי, לתת לבחורה להקליד SMS-ים במקלדת הטלפונית הקלאסית), או להכריח אותו לבצע את המעבר הכואב והמתסכל לתהליכי עבודה חדשים (קרי, מקלדת מלאה), מתוך ידיעה שבטווח הקצר התהליך החדש יפגע ביעילות עבודתו באופן קיצוני, ומתוך תקווה שבטווח הרחוק היעילות תעלה. אם נשאיר את הבחירה בידי המשתמש, אז כנראה שרק המשתמשים בעלי המודעות הטכנולוגית הגבוהה, ו/או בעלי נטיות מאזוכיסטיות, יבחרו באפשרות השנייה.
למזלנו, לשאלה זו קיימת התשובה ברורה שאינה משתמעת לשתי פנים: “זה תלוי”. תלוי במשתמש, בעקומת הלמידה הצפויה, בתוספת היעילות הצפויה, במחיר הטעות, במצב רוחו של מקבל ההחלטות בבוקר של הדיון וכד’. אפיינתי בעבר מערכת שבה לא יכולנו לנצל את היכולות הטכנולוגיות המודרניות בגלל תהליכי עבודה שעוצבו ע”י שימוש רב-שנים במערכות קודמות ומיושנות. אין הרבה מה לעשות עם זה. למעשה, כולנו משתמשים במערכות כאלה מדי יום. דוגמא קלאסית היא מקלדת QWERTY עצמה, שסידור המקשים בה נובע ממגבלות טכניות של מכונות הכתיבה הישנות, ואינו אופטימאלי מבחינת יעילות ההקלדה. סידור טוב יותר קיים במקלדת Dvorak, שיש לה קהילת חסידים מצומצמת ברחבי העולם. מי שרוצה לדעת עוד על סיפור המקלדת, מוזמן לקרוא את הדיון שהיה לנו בנושא אצל ברק דנין לפני כשבועיים (בתגובות), וההשוואה בין שתי המקלדות מפורטת בוויקי.
את הדיון בשאלה הזו עשו לפני כמה שנים גם במיקרוסופט, והוא ליווה את הפיתוח של האופיס 2007, שבמסגרתו הכריחו את המשתמשים לשכוח את התפעול המוכר ולעבור לממשק מבוסס ribbon. המחקרים של מיקרוסופט הראו שממשק הריבון יעיל יותר מהממשק מבוסס התפריטים, והמודל הישן נזנח ברובו (אמנם אוטלוק 2007 עדיין משתמש בממשק התפריטים במסך הראשי, אבל אוטלוק 2010 כבר לא). מי שרוצה לקרוא על השיקולים שעמדו מאחורי התהליך, יכול לקרוא על כך בסדרת פוסטים בבלוג של ג’נסן האריס, ראש צוות ה-UX באופיס 2007.
יחד עם זאת, אפשר להגיד שבמידה מסוימת מיקרוסופט כן השאירו את הבחירה בידי המשתמש, כי רבים עדיין משתמשים באופיס 2003, ולמיטב ידיעתי מיקרוסופט לא ביצעה מהלכים אגרסיביים כלשהם שנועדו לדחוק את האופיס הישן החוצה, כפי שהם עשו למשל עם ה-XP.
עד כאן פילוסופיה ממשקולוגית. והנה שני סרטונים בנושאים קשורים:
בנושא מערכות שיובאו מהעולם הפיזי אל העולם הוירטואלי:
בנושא הרכבת. הסרטון הזה מוצג בגאווה באתר רכבת ישראל, ומתאר את בניית המעבר התת-קרקעי בבאר יעקב.
הסרטון יפה, אבל שמישהו יסביר לי מה משמעות המילים “ק”מ 115.47″ בהתחלה. באמת, מה זה המספר הזה? מן הסתם שזה לא אורך המעבר התת-קרקעי. האם זה המרחק מאיזושהי נקודה מסתורית? אולי מהכותל? מדדתי ולא. זה בערך המרחק מעכו בצפון או משדה בוקר בדרום (או פרברי עמאן במזרח). ואולי בכלל משהו השתבש בתצוגת העברית בתוכנה בה יצרו את הסרטון, וק”מ היה אמור להיות מ”ק, כלומר מטרים קבועים (שהם למעשה מקובעים, יענו קוּבּ) וזה נפחו של המעבר התת-קרקעי? לפי המידות שמובאות באתר, זה גם לא מסתדר. למישהו יש מושג?
לפני כמה ימים נתקלתי בבאנר הבא באחד האתרים הישראליים. אני מביא אותו בגודל אמיתי, ותיכף תבינו מדוע אני מציין את זה.
המחשבה הראשונה שעברה בראשי הייתה שהבאנר יכול להיות לגיטימי רק בתנאי שבצד השני מסתתר שוטר מהיחידה למלחמה בפדופוליה ברשת, כי הילדה הזאת נראית מקסימום בת 15. לחצתי על הבאנר, אבל להפתעתי הימ"מ לא פרץ לדירתי (אפילו חיכיתי כמה דקות), אז אני הנחתי שטעיתי.
הסיפור התבהר כשנתקלתי בבאנר אחר בכיכובה של אותה מתבגרת בודדה, אבל הפעם הוא נראה כך:
אני חייב להודות שזה עדיין די מטריד, אבל לפחות הפעם זה נראה כאילו שהיא כבר התחילה את הבגרויות.
מה קורה פה? התשובה מצויה במיתולוגיה היוונית, בסיפור על השודד פרוקרוסטס, שהיה משכיב את קורבנותיו על מיטה – ומקצץ את איבריהם כאשר היו גבוהים מדי, או מותח אותם בחבלים במידה והיו נמוכים מדי (ועכשיו גיליתי שבמסורת היהודית קיים סיפור דומה על מיטת סדום). את תפקיד השודד משחק כאן מעצב הבאנרים, שהחליט שהבחורה מהבאנר הנמוך אינה גמישה מספיק בשביל לככב גם בבאנר הגבוה, ולכן עשה לה הצרת היקפים נמרצת ועל הדרך גם מתח אותה קצת לגובה. כך נראות שתי הגרסאות צד אל צד.
כידוע, פרופורציות הגוף שלנו משתנות (בעיקר לרוחב) כשאנחנו יוצאים מגיל ההתבגרות, ואם נשנה אותן בצורה מלאכותות, למשל בפוטושופ, אפשר גם להוריד כמה שנים במשיכת עכבר אחת. ואמנם סקס מוכר, אבל זה לא אומר שלא צריך לחשוב לפחות דקה כשחותכים באנרים, אפילו אם מככבת בהם בחורה במכנסיים קצרים על חוף הים.
נ.ב. בנושא לא קשור לחלוטין. הרגע נתקלתי בידיעה על כך שמיקרוסופט הכריזה על טלפון סלולרי מתוצרתה. המכשיר נקרא Kin, כלומר כנראה שלא תהיה ברירה אלא לקרוא לו קין בעברית. חייבים להודות שזה שם קצת יותר מוצלח מבחינת לוקליזציה מאשר Zune, אבל לא נראה לי שהשיא של Zune בכלל ניתן לשבירה. מעניין אם הלוגו של Kin ייקרא אות קין. ואם אנחנו בנושא לוגואים, אז אפשר להזכיר שבתחום הזה ההישג של Zune בתור השם הכי לא מתאים לעברית דווקא כן נשבר, אבל המתחרים רימו קצת. השם אנדרואיד כשלעצמו הוא בסדר גמור, אבל הכיתוב שעל הלוגו בהחלט אינו מותאם לעיניים קוראות עברית.
(מי שאין לו כוח לניתוחי UI מוזמן לדלג לחלק האמנותי החווייתי של הפוסט)
ניתוחי UI
אחד הדברים הראשונים שלמדתי כשהתחלתי להתעסק באפיון מפורט של מערכות desktop מורכבות, היה להעריך את אפיון התוכנות של מיקרוסופט. לפני כן קצת הפריע לי שבכל פעם שנדרש לאפיין מנגנון כלשהו, פשוט מעתיקים אותו אוטומטית מאפליקציית האופיס המתאימה. וזה לא קשור לסטנדרטים או להרגלי השימוש המוּכרים – אפשר לתפור פתרון ייעודי ללקוח תוך כדי הקפדה על הסטנדרטים גם בלי שזה יהיה זהה לאוטלוק. אבל ברגע שמתחילים לאפיין ברמה באמת מפורטת, כזו שבסוף התהליך מתגלה שחסכת ל-QA חצי מעבודת כתיבת התרחישים, אז נאלצים לנתח לעומק את הפתרונות של אופיס ולהבין את ההגיון שמאחורי הדברים. ואז מורגשות אותן אלפי שעות אדם שהחברה משקיעה בהנדסת האנוש של הפרטים הכי קטנים של הממשקים שלהם. זה לא שהכל מושלם (למשל אני עדיין חושב שהפתרון הגראפי של כפתור "שולחן העבודה" מהפוסט הקודם הוא גרוע), אבל רוב הדברים המורכבים מאופיינים למופת.
למה אני מקשקש על זה? בגלל תחביב קטן שיש לי. אני נהנה למצוא את המקרים בהם החברה חורגת בצורה בוטה מהסטנדרטים, ולהבין מדוע זה נעשה. כמובן שאין בעיה למצוא דוגמאות כאלה בתוכנות אחרות, אבל שם זה לא ממש מעניין כי ברוב המקרים פשוט מדובר באפיון גרוע (אפשר לחפש דוגמאות בבלוג הזה תחת התגית תקנים). אצל מיקרוסופט, לעומת זאת, זה מעיד בדרך-כלל על ההשקעה באפיון, כי זאת לא חברה שמקבלת החלטות כאלה בלי לחשוב על זה טוב-טוב.
את הדוגמאות אני שומר בצד למקרים בהם אני אצטרך להפר את אותו סטנדרט בעצמי, ואז יגידו לי שאי אפשר כי זה לא עובד ככה, ואז אני נדרש להוכיח שזה כן יכול לעבוד גם ככה, כשבאמת צריך.
הדוגמא החביבה עליי תמיד הייתה של צ'קבוקסים שמתנהגים כמו כפתורי רדיו. זה קורה בכמה מקומות, אבל הדוגמא המועדפת עליי היא בוורד, בדיאלוג "גופן". לכאורה, כל הצ'קבוקסים נראים בסדר, אבל עבור כל אפשרות יש לפחות אפשרות אחת אחרת שלא יכולה להתקיים יחד איתה, וכך קורה שהצ'קבוקסים מכבים זה את זה. ואי אפשר היה להחליף אותם בכפתורי רדיו – גם בגלל המצב שכולן כבויות, וגם בגלל המצב שיותר מאפשרות אחת דולקת – כי עבור כל אחת יש גם הרבה שאינן מתנגשות איתה. כך נראות הקבוצות בפועל (התיבות המוקפות באותו עיגול מכבות זו את זו, לחצו להגדלה):
ואתמול נתקלתי בדוגמא נוספת: כשמגדירים כללים באוטלוק, ובוחרים באפשרות "למחוק לצמיתות", היא אוטומטית מדליקה גם את הצ'קבוקס "הפסק לבצע כללים נוספים" (מכיוון שההודעה הולכת להימחק, ולא ניתן יהיה לבצע עליה פעולות נוספות). זה לא נדיר שיש תלות בין שני צ'קבוקסים, אבל במקרים כאלה בדרך כלל יש לזה גם ביטוי גראפי בצורת הזחה (indendation) או קישור אחר כלשהו. כאן לא ניתן היה לנקוט בפתרונות המקובלים משום שהתיבה הנשלטת יכולה לפעול גם בזכות עצמה, או בצירוף עם תיבות אחרות. זאת גם הסיבה לכך שבעוד שהדלקת התיבה הראשונה מדליקה את השנייה, כיבויהּ של הראשונה אינו מכבה את השנייה – המערכת אינה יודעת מדוע השנייה דולקת, וייתכן שהמשתמש הדליק אותה בעצמו בכוונת תחילה.
החלק האמנותי החווייתי של הפוסט
קודם כל, המון המון ברכות לחברת אינקוד-הייפרה על הזכייה בקטגוריה "האתר הנבחר של היום" באתר TheFWA (Favourite Website Awards). למי שלא מכיר, מדובר כנראה באתר המשפיע ביותר בתחום עיצוב אתרים, עם יותר משלושה מיליון ביקורים בחודש. בכל יום הם בוחרים אתר אחד מכל רחבי הרשת, ומציינים אותו בזכות עיצוב "חדשני, יצירתי ופורץ גבולות". לאחר מכן בוחרים מתוכם את אתר החודש ואת אתר השנה.
ב-19 למרץ, החנות האינטראקטיבית למכירת פוסטרים מותאמים אישית, canv-as.com, שעוצבה ופותחה ע"י אינקוד-הייפרה, נבחרה לאתר היום. (תיקון – החנות פותחה ע"י אינקוד-הייפרה ע"פ העיצוב המקורי של בעלי החנות, יהודה אזולאי).
ולבסוף, אם כבר מדברים על חוויית משתמש, אני רוצה לציין את אתר השבוע האישי שלי – http://lab.andre-michelle.com/tonematrix. אין הרבה מה להגיד עליו חוץ מזה שהוא פשוט ממש ממש כיפי. תוודאו שהרמקולים פועלים. אפשר להקליק ואפשר לגרור עם העכבר. תתחילו באלכסונים. ותהנו.
שלושה סוגי כפתורים צדו את עיניי לאחרונה.
הכפתור הרקורסיבי.
בדיחת גיקים ידועה אומרת שבמילון, בערך "רקורסיה" רשום "ראה רקורסיה". על הפופולריות של הבדיחה יכולה להעיד העובדה שחברת גיקים מסוימת שהולכת ומשתלטת על העולם הפכה אותה למציאות – כשמקלידים בגוגל את הביטוי recursion, גוגל שואל "האם התכוונת ל recursion"?
ובכן, היום הורדתי כמה עדכונים לחלונות 7, ובסיום ההתקנה צץ לי דיאלוג קטן שאומר שאני צריך לאתחל את המערכת. לנוחיותי מצורף גם כפתור איתחול. וזה נראה כך:
אז לחצתי על הכפתור. המסך הבא שהתקבל הודיע לי שאיני יכול לאתחל את המערכת כל עוד הדיאלוג הקודם פתוח.
אני בהחלט מבין שעדיף לאתחל את המערכת כשכל התוכנות סגורות. ולכן התעשייה יצרה שני פתרונות מקובלים – או שמודיעים לך שעליך לסגור את כל התוכנות, כולל את זו שמציגה את ההודעה, ואז לאתחל בצורה ידנית, או שכפתור האתחול בדיאלוג יודע לכבות אותן בעצמו. אין לי אפילו בעיה עם זה שיש תוכנות חיצוניות שאינו יודע לכבות. אבל זה לא ממש הגיוני שעצם קיומו של הכפתור מונע ממנו לפעול. זה כמובן מזכיר את ההודעה המפורסמת הזו (בשתי השורות האחרונות):
הכפתור הממוקם היטב.
אם יש "חוק ראשון בממשקולוגיה", אז זה כמובן לעולם לא לדבר על ממשקולוגיה חוק פיטס. לשון החוק היא "הזמן הנדרש להשיג מטרה הוא פונקציה של המרחק אל המטרה והגודל שלה" ורוח החוק היא שככל שהפקד נמצא רחוק יותר וככל שהוא קטן יותר, כך יותר קשה ללחוץ עליו. מי שמעוניין, יכול לקרוא על זה בהרחבה אצל ברק, שממנו גם העתקתי את התרגום. בין שאר הדוגמאות, הוא מביא גם את הדוגמאות הקלאסיות – כפתור Start וכפתור ה-X. מאחר והם ממוקמים בפינות המסך, אפשר להגיד שהם תופסים גם את כל השטח שמעבר לפינות אלו, ואז אפשר ללחוץ עליהם בקלות מבלי להזדקק לתנועות מדויקות ומדודות אלא פשוט להעיף את העכבר באלכסון לכיוון הכללי של קצה המסך – במקום לצאת מגבולות המסך, הוא ייעצר בפינה, בדיוק מעל הכפתור.
לפני כמה שבועות, כשהתקנתי את חלונות 7 לראשונה, חיפשתי בו את כפתור ה-Show Desktop. הכפתור לא היה בנמצא. אמנם יש את קיצור המקלדת הסופר-שימושי Win+D, אבל זה לא תמיד מספיק ואני מעדיף שיהיה גם כפתור. לא הצלחתי למצוא אותו. מחיפוש מהיר באינטרנט הבנתי שהכפתור אינו קיים יותר, ויש סקריפטים וטריקים שונים שיודעים ליצור משהו שעובד כמעט כמו הכפתור הזה. הסקתי שזו הייתה החלטה עיצובית של מיקרוסופט, והיא הייתה מאוד תמוהה בעיניי. ואז, כשהתלוננתי על זה באזני אחד החברים שלי, הוא גילה לי שהכפתור קיים, בריא ושלם, ושהוא מסתתר בפינה הימנית התחתונה של המסך. לפי כל המתואר מעלה, זהו מיקום מושלם לכפתור כל-כך שימושי, מה גם שעד עכשיו הפינה הזאת הייתה חתיכת נדל"ן מסכי נחשק ביותר, ששימשה לשעון המסכן הזה שלא מתקרב למיצוי הפוטנציאל שלה. אם תרצו, זאת הייתה המקבילה החלונאית למתחם השוק הסיטונאי בת"א. הבעיה עם הכפתור בחלונות 7 הייתה שבמיקרוסופט שכחו את עקרון ה-Discoverability שאומר במילים פשוטות "אם זה חשוב, תדאג שהמשתמש יראה את זה". וזה אחד ההבדלים בין נדל"ן אמיתי לנדל"ן מסכי – בעולם האמיתי נדל"ן נחשק הוא תמיד בולט ונמצא במרכז תשומת הלב. על המסך – לא תמיד.
הכפתור שאינו ממוקם היטב.
הבדל נוסף בין נדל"ן אמיתי לנדל"ן מסכי הוא שפינת המסך תמיד תשאר פינת המסך, והכפתור ששמת שם ימשיך ליהנות מכל היתרונות הנובעים ממיקומו. לעומת זאת, אם רכשת בית על שפת הים, בעוד כמה שנים אתה עשוי להתעורר לקולות של בולדוזרים שבאו להכין את הקרקע לבניית מגדל חדש בדיוק בינך לבין הים. זה בערך מה שעשו HP באחד המחשבים הניידים שלהם, ועל כך בהמשך.
אנשים נוטים לשכוח שחוק פיטס התייחס במקור לאובייקטים פיזיים, ולא וירטואליים. והדוגמא הרלוונטית לענייננו היא המקלדת, שבפינתה השמאלית העליונה נמצא מקש Еsc, שזה מיקום מעולה לפי חוק פיטס. וכפי שאין צורך לכוון את העכבר בדיוק לכפתור Start, כך גם אין צורך ללחוץ עם האצבע בדיוק על מקש Esc – מספיק להניף כמה אצבעות לכיוון הכללי של קצה המקלדת, ואחת מהן כבר תפגע ב-Esc. ובגלל המיקום הפינתי, אין הרבה סיכויים שהיא תפגע באיזה מקש אחר – לפחות לא במשהו חשוב. שימו לב לדפוס ההקלדה שלכם, ותראו שגם אתם עושים את זה לא מעט.
למעלה, ב"כפתור הממוקם היטב", הבנו שמיקרוסופט מכירים את חשיבות הפינות הגדולות. אבל כנראה שזה תופס רק לחטיבות התוכנה, כי חטיבת הציוד ההיקפי פיתחה את מקלדת Microsoft Digital Media Pro שאני משתמש בה בעבודה, ושהפינה השמאלית העליונה שלה נראית כך:
הכפתורים הקטנים שולטים על הווליום, וקשה לי לספור את מספר הפעמים ביום שאני מגביר את הווליום בטעות, כשכל מה שרציתי היה ללחוץ על –Esc (מסתבר שזו עוד דרך להרוס כפתור ווליום, בנוסף לשתיים שתיארתי לפני כמה פוסטים).
אבל אני יכול לחיות עם זה, זה לא עד כדי כך נורא. למשל, זה לא נורא כמו הרעיון הגאוני של HP להצמיד אל ה-Esc את כפתור כיבוי המחשב! כך נראית המקלדת של אחד ממחשבי ה-Compaq מלפני כמה שנים.
בכל פעם שאני מגביר בטעות את הווליום, אני נזכר באחד הקולגות שלי ב-UI שעבד על מחשב כזה, ועבורו מחיר אותה הטעות היה טיפה יותר גבוה – כמה פעמים ביום הוא היה בטעות מכבה את המחשב.
אפרופו,
פוסט ישן שלי בבלוג הקודם על פשלה אטומית במקלדות, עם כמה דוגמאות מרגיזות נוספות בתגובות.
חברים, השעה שבע בבוקר ואין לי כרגע זמן לכתוב על זה, אבל מצד שני גם אין לי כל כך מה לכתוב על זה, הכל כבר נכתב בפוסט הזה. זה פשוט ענק. חבל שאני לא יכול להשתמש יותר מפעם אחת בתגית fail בפוסט.
שלשום, בזמן שכתבתי את הפוסט על שדות סיסמא, כל האתרים שקישרתי אליהם היו פתוחים לי בפיירפוקס, כל אחד בטאב נפרד. וכשסיימתי, רציתי לסגור את כולם (אבל להשאיר את הדפדפן פתוח). אז תפסתי את העכבר ולחצתי על ה-X של הטאב האחרון, ואז על ה-X של הטאב האחרון החדש, ואז על ה-X של הטאב האחרון החדש (אם אי-פעם תהיתם מה משותף לטאבים בדפדפן ולראשי החמאס בגדה…). ואז הבנתי שמשהו מוזר לי בתהליך – בהתחלה הטאבים נסגרו לי מבלי שנאלצתי להזיז את העכבר כלל, פשוט לחצתי תמיד באותו מקום, אבל באיזשהו רגע התחלתי להזיז אותו שמאלה בשביל להגיע אל ה-X של הטאב האחרון. אז החלטתי לבחון את העניין הזה לעומק.
מה שקורה, מרגע פתיחת הטאבים, זה ככה: בהתחלה הטאבים החדשים נפתחים בגודל קבוע, עד שהם ממלאים את רוחב החלון. מרגע שלא נכנסים יותר טאבים ברוחב המקורי, רוחבם של כל הטאבים מתחיל לקטון עם פתיחת כל טאב חדש, כי צריך להכניס יותר טאבים באותו חלון. באיזשהו שלב הם מפסיקים להצטמצם, הרוחב שלהם נשאר קבוע (הרוחב המינימלי), ומופיעה גלילה שמאפשרת להגיע לטאבים שלא נכנסים בחלון.
אבל אותנו יותר מעניינת סגירת הטאבים. אז אותו העקרון פועל גם בסגירה, רק להיפך – אם התחלת עם המון טאבים (במצב של גלילה), רוחבם לא משתנה עם סגירת כל טאב, לאחר מכן הגלילה נעלמת וכל טאב שנסגר מאפשר לטאבים הנותרים להתרחב קצת, עד שמגיעים למצב של רוחב מקסימלי קבוע – כשרוחבם המצטבר כבר לא ממלא את כל רוחב החלון. ואז הם מפסיקים לגדול, מסכנים.
ההשפעה של האלגוריתם הזה על תהליך סגירת טאבים מרובים ע"י המשתמש היא לא נעימה, בגלל ששינוי גודל הטאבים מזיז את כפתור ה-X, וצריך לרדוף אחריו.
כאשר יש לנו הרבה טאבים בעלי רוחב קבוע (כלומר, יש גלילה במסך), מצבנו טוב: הטאבים ממלאים את כל המסך, וסגירתם אינה גורמת לשינוי רוחב הטאבים הנותרים. אז אין לנו בעיה, כי טאב חדש תופס את מקומו של זה שנסגר, ומאחר והם בעלי אותו רוחב, ה-X החדש יושב בדיוק באותו מקום כמו בטאב שנסגר.
זה מתחיל להיות מעניין (ואני יודע ששאלתם את עצמכם מתי זה כבר יתחיל להיות מעניין) במצב שרוחב הטאבים משתנה. כי אז יש הבדל בין סגירת טאבים מהסוף (מימין בממשק אנגלי, כלומר סגירת הטאב האחרון) לבין סגירת טאבים מהאמצע. כי סגירתם מהסוף מציבה את כפתור ה-X החדש בדיוק במקום של הכפתור הישן, ואין צורך לכוון מחדש. אבל סגירתם מהאמצע גורמת בד"כ לכך שהעכבר עכשיו נמצא באמצע הטאב החדש, ולא על ה-X, בצורה כזו (השורה למטה זה המצב לאחר סגירת הטאב):
העכבר מגיע לאמצע הטאב החדש, מלבד מצב של סגירת טאב אחרון
אז לכאורה כל עוד אנחנו סוגרים מהסוף, אנחנו מסודרים. אבל גם זה הולך להשתנות, כי ברגע שהטאבים כבר לא ממלאים את כל המסך, רוחבם נשאר קבוע (רוחב מקסימלי), אבל הטאב האחרון מתחיל לזחול שמאלה עם כל טאב שנסגר. אז עכשיו כפתורי ה-X הפנימיים כן חופפים, אבל האחרון כל פעם משנה את מקומו:
העכבר נמצא מימין לטאב האחרון החדש
מה שמחמיר את המצב עוד, זה כל מיני משחקים שהדפדפנים עושים עם הטאבים וכפתורי ה-X. יש כאלה שמציגים את ה-X רק כשהטאב בפוקוס (IE8), יש כאלה שמציגים אותם רק כשהטאב ב-mouseover (ספארי), ויש שמשתדלים להציג אותו כל עוד המקום מאפשר (אופרה וכרום – והם גם אלה שממשיכים עם צמצום הטאבים הכי הרבה – בכרום הטאבים ממשיכים לקטון עד שיש כמאה טאבים, ואז רוחבם הופך לקבוע, וזה נראה בערך ככה
:
כל הדפדפנים שבדקתי מעלימים את ה-X כשיש ממש המון טאבים ואז מציגים אותו רק בפוקוס על הטאב – אבל יש כאלה שמעבירים את הפוקוס אל הטאב שתופס את מקומו של זה שנסגר, ואז אפשר להמשיך ללחוץ על ה- X((IE8, ויש גם כאלה שמעבירים את הפוקוס טאב אחד ימינה, ואז העכבר נמצא מעל טאב שאין בו X (פיירפוקס) וצריך ללחוץ פעמיים.
בקיצור, כשיש הרבה טאבים שמשנים את רוחבם, אם נסגור מהסוף לא נצטרך להזיז את העכבר, אבל אם נסגור מהאמצע אז כן נצטרך.
זאת כל עוד משתמשים בפיירפוקס (המחשה למעלה), באקספלורר
באופרה
ובספארי
אבל לא בכרום! האנשים הטובים מגוגל המציאו לנו טאבים קסומים!
בכרום, כל עוד יש מספיק טאבים בשביל למלא את המסך, הטאב הבא תמיד ימוקם כך שכפתור ה-X שלו נמצא במקום בו היה הכפתור של הטאב שנסגר זה עתה. וזאת ללא קשר למיקומו – אם סגרתי מהסוף אז הטאב האחרון מחליק ימינה, ואם סגרתי מהאמצע אז הטאב הימני מחליק שמאלה.
אבל זה לא הכל. אם חושבים על זה לשניה, מבינים שזה לא לגמרי מסתדר – כיצד הטאבים יכולים גם להחליק ימינה (ולהתרחק ע"י כך מקצה המסך), וגם לתפוס את כל המסך, בשביל שכפתור ה-X הימני ביותר יישאר במקומו? אמנם הם משנים את רוחבם, אבל הם עדיין חייבים גם למקם את כפתור ה-X החדש בדיוק במקומו של הישן, וגם להיות בעלי רוחב זהה. בקיצור, כל התנאים האלה לא ממש מסתדרים.
מבולבלים? גם אני. לא בטוח שהייתי עולה על הסתירה לבד אלמלא שמתי לב למנגנון שפותר את זה. והפתרון הוא שהתהליך יכול לקרות בשני שלבים: אם סוגרים מהאמצע, אז בהתחלה הטאבים מחליקים שמאלה ואכן מתרחקים מקצה המסך, אבל לאחר שהזזנו את העכבר משורת הטאבים, הם נפרסים מחדש, ברוחב גדול יותר, ושוב תופסים את כל המסך. כך נראים שלושת השלבים:
(העכבר תמיד נמצא במקום הנכון (פתגם סיני עתיק
השינוי קורה רק אם סגרתי מהאמצע – כשסוגרים מהסוף, זה קופץ ישר למצב הסופי. והקסם כן נפסק ברגע שאין מספיק טאבים בשביל למלא את המסך, כי יש להם גודל מקסימלי קבוע.
אגב, אני לא רואה סיבות אחרות שבגללן גוגל היו רוצים ליישם את המנגנון המסובך הזה מלבד לענות על התרחיש הספציפי הזה, בו המשתמש סוגר הרבה טאבים בבת אחת ומעוניין לעשות זאת מבלי להזיז את העכבר. וזה אומר שהם חושבים עלינו.
מומחה לחוויית משתמש, עוסק בתחום יותר מחמש שנים וכותב עליו יותר מארבע.
חלק מצוות UXI -- חוויית משתמש ישראל , ומשמש כ-moderator ב-UX.StackExchange.
סיים תואר ראשון במדעי ההתנהגות, ומסיים את התואר השני בפסיכולוגיה קוגניטיבית - שני התארים מאוניברסיטת בן-גוריון.
היום מאפיין ממשקים למערכות דסקטופ, ווב ומובייל בחברת
Netcraft ברמת גן.
