מתוך OdedWiki

ברוכים הבאים ל-wit

• עודד חיים בריינר
• מחקר על שימושיות במערכות מידע ותוכנה.

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

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

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

אפליקציות יעילות מבצעות מקסימום עבודה עם מינימום קלט מהמשתמשים.

תוכן עניינים 1 אפס הדרכה 2 אוטונומיה 3 עיוורון צבעים 4 עקביות 5 ברירות מחדל 6 יעילות המשתמש 7 ממשקים חקירים 8 חוק פיטס 9 עצמי ממשק-אדם 10 צמצום זמן אחזור 11 למידות 12 שימוש במטאפורות 13 הגנו על עבודת המשתמשים 14 קריאות 15 שימור מצב 16 ניווט נראה 17 עקרונות חדשים 17.1 כפתורים 17.2 סיסמות 17.3 דיאלוגים להמשכי פעולה 17.4 הלקוח לא תמיד צודק 17.5 גלילה 17.6 רמות לקוח 17.7 מדידת שימושיות 18 שונות 18.1 הנחייה 18.2 מקורות 18.3 משוב

[עריכה] אפס הדרכה

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

[עריכה] אוטונומיה

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

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

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

[עריכה] עיוורון צבעים

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

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

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

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

[עריכה] עקביות

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

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

1. פרוש התנהגות משתמשים, לדוג': מקשי קיצור ששומרים על הפונקציונליות שלהם.
2. מבנים בלתי נראים.
3. מבנים קטנים ונראים.
4. המראה הכללי של אפליקציה יחידה- מסכי דיאלוג, אלמנטים עיצוביים.
5. ערכה של מוצרים.
6. עקביות פנים ארגונית.
7. עקביות לרוחב פלטפורמות.

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

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

• חוסר עקביות: חשוב להיות חסר עקביות מבחינה ויזואלית כאשר עצמים מתנהגים בצורה שונה באותה מידה שחשוב להיות עקבי כאשר עצמים מתנהגים בצורה זהה.

• העקביות החשובה ביותר היא עם ציפיותיהם של המשתמשים, הדרך היחידה לודא את ציפיותיהם של המשתמשים היא ע"י בדיקות משתמשים.

[עריכה] ברירות מחדל

• כאשר ישנו דיאלוג כלשהו והמשתמש צריך לבחור אופציה אחת מבין כמה. יש להדגיש (או למקם בראש) את הפעולה הבטוחה ביותר. כלומר, הפעולה שתגרום להכי פחות נזק, ואפשר לחזור ממנה (Rollback) בקלות הרבה ביותר למצב הקודם או לאלטרנטיבות האחרות. לדוג': דיאלוג המתעורר מלחיצה על "יציאה" ושואל: "האם לשמור את הקובץ?" האפשרות "בטל" צריכה להיות הבולטת ביותר והנבחרת בברירת מחדל (Default). מכיוון שלחיצה עליה תחזור שלב אחורה ותאפשר לשחזר את הדיאלוג.
• ברירות מחדל צריכות להגיב במהירות ולא לגרום ללוגיקה מיותרת של המערכת.
• אין להשתמש בביטוי "ברירת מחדל". ניתן להשתמש ב"סטנדרטי", "הגדרות מקוריות", "הגדרות ראשוניות" או כל ביטוי ספציפי אחר שמתאר את הפעולה שתתרחש.

[עריכה] יעילות המשתמש

• בחן את הפרודוקטיביות של המשתמש ולא של המחשב.

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

לדוגמא, איזו מהפעולות הבאות מהירה יותר? חימום מים במיקרוגל במשך דקה ועשר שניות או במשך דקה ואחת עשרה שניות?

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

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

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

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

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

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

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

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

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

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

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

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

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

• תוויות של תפריטים וכפתורים צריכים להתחיל ממילות המפתח.

דוגמה ממעבד תמלילים דמיוני:

תוויות גרועות:

• הכנס מעבר עמוד.
• הוסף הערת שוליים.
• עדכן תוכן עניינים.

תוויות טובות:

• הכנס:
  • מעבר עמוד.
  • הערת שוליים.
  • תוכן עניינים.

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

[עריכה] ממשקים חקירים

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

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

• לפעמים, לעומת זאת, חייבים לספק שביל בטוח.

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

• תנו למשתמשים רמזים תפיסתיים קבועים בכדי שירגישו "בבית".

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

• לכל פעולה צריכה להיות פעולה מתקנת.

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

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

• תמיד לאפשר UNDO (בטל).

המשמעות הבלתי נמנעת של אי תמיכה ב-UNDO היא דיאלוגים אין-סופיים בסגנון של "האם אתה באמת באמת בטוח?". וכמובן שכך נפגעת היעילות.

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

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

• תמיד לאפשר דרך יציאה החוצה.

משתמשים לא צריכים להרגיש כלואים. צריכה להיות להם דרך יציאה קלה וברורה.

• אולם, להישאר בפנים צריך להיות קל יותר.

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

[עריכה] חוק פיטס

• הזמן שלוקח להשיג מטרה הוא פונקציה של המרחק ממנה והגודל שלה.

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

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

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

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

[עריכה] עצמי ממשק-אדם

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

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

[עריכה] צמצום זמן אחזור

• בכל הזדמנות, השתמשו ברב-משימתיות (Multi-tasking) בכדי לצמצם המתנה בזמן אחזור (Latency).

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

• צמצם את את חוויית זמן האחזור של המשתמש.
  • הכר בלחיצה על כפתורים באמצעות משוב ויזואלי או קולי בתוך 50 אלפיות השנייה.
  • הצג שעון חול או סימן ויזואלי דומה אחר לכל פעולה שלוקחת בין 1/2 ל-2 שניות.
  • הוסף אנימציה לשעון החול בכדי שהמשתמשים ידעו שהמערכת לא קרסה.
  • הצג הודעה עם אינדיקציה לאורך זמן ההמתנה הפוטנציאלי לכל פעולה שלוקחת יותר מ-2 שניות.
  • המחש את זמן ההמתנה באמצעות בר התקדמות עם אנימציה.
  • הצג הודעות טקסט ומידע מעניין למשתמשים בעודם ממתינים לסיום תהליכים ארוכים כגון התקנה של אפליקציות.
  • השמע ביפ והצג חיווי ויזואלי בולט כאשר המערכת מסיימת תהליך ארוך (>10 שניות), בכדי שהמשתמשים יידעו לחזור להשתמש במערכת.
  • חסום לחיצות חוזרות על אותו כפתור או אובייקט. מכיוון שהאינטרנט איטי, אנשים נוטים ללחוץ מספר פעמים על אותו כפתור ובכך מאיטים את העניינים אפילו יותר.

• עשו את המערכת מהירה יותר.

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

[עריכה] למידות

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

• למידות ושימושיות

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

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

• הגבילו את הויתורים של למידות-שימושיות.

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

[עריכה] שימוש במטאפורות

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

מטאפורות טובות הן סיפורים שיוצרים תמונות מוחשיות במחשבה.

• הפעילו את המטאפורות ע"י משחק עם החושים- ראייה, שמיעה, מגע, תנועה ועם הזכרונות שלהם.

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

[עריכה] הגנו על עבודת המשתמשים

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

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

[עריכה] קריאות

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

[עריכה] שימור מצב

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

עלינו לדעת:

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

ועוד...

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

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

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

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

[עריכה] ניווט נראה

• המנעו מניווט בלתי נראה.

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

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

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

[עריכה] עקרונות חדשים

[עריכה] כפתורים

• מיקום כפתורים יכול להיות:

1. ממורכז בסוף המסך
2. מיושר לצד השפה (ימין-עברית, שמאל-אנגלית) בסוף המסך

[עריכה] סיסמות

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

[עריכה] דיאלוגים להמשכי פעולה

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

[עריכה] הלקוח לא תמיד צודק

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

[עריכה] גלילה

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

[עריכה] רמות לקוח

1. פרטי
2. עסקי
   1. עסקי משתמש
   2. עסקי מפתח

ישנה הנחה רווחת שהשימושיות יכולה לפחות ברשימה זו אך היא שגויה.

[עריכה] מדידת שימושיות

המדדים המקובלים ביותר למדידת שימושיות הם:

• השלמת משימה
• משך המשימה
• מספר שגיאות
• ציוני שביעות רצון

נדרשים שלושה שלבים למדידה:

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

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

1. שגיאות ושיעורי השלמה: משתנים בדידים, אין משמעות למצבי ביניים ולא ניתן לחלק את התוצאות. אין כזה דבר חצי שגיאה.
2. זמן ושביעות רצון: משתנים רציפים בעלי משמעות גם במצבי ביניים שיכולים להיות מחולקים עד אין-סוף. אפשר להשלים משימה ב-5 דקות או לחלופין, ב-5 דקות ו-22 שניות.

השיטה הראשונה, למשתנים בדידים:

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

• מספר התקלות \ מספר ההזדמנויות = שיעור התקלות (או הסיכוי לתקלה).
• שיעור התקלות - 1 = רמת האיכות.
• רמת האיכות + 1.5% = סיגמת התהליך. אנחנו מוסיפים 1.5% לרמת האיכות בכדי להתחשב לשינויים שיתרחשו לאורך זמן (אנחנו מקשיחים את המדד).

השיטה השנייה, למשתנים רציפים:

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

• שיעור התקלות = השטח מתחת לגרף ההתפלגות הנורמלית מ"ימין" לציון ה-Z (תרשים התפלגות).
• רמת איכות = השטח מתחת לגרף ההתפלגות הנורמלית מ"שמאל" לציון ה-Z (תרשים התפלגות).
• רמת האיכות + 1.5% = סיגמת התהליך.

תרשים התפלגות: עקומה נורמלית המציגה את איזור התקלות מעבר לגבול המטרה של 120 שניות. זמן ממוצע המדגם הוא 104 שניות, סטיית התקן היא 12 שניות שנותנת ציון Z של: (104-110)\12 = 1.32sigma- ורמת איכות של 91%.

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

[עריכה] שונות

[עריכה] הנחייה

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

[עריכה] מקורות

1. http://www.useit.com
2. http://www.foxnews.com/story/0,2933,241578,00.html
3. http://www.pronetadvertising.com/articles/my-50-favorite-design-resources.html
4. http://userexperience.spaces.live.com/feed.rss
5. http://www.measuringusability.com/sauro-kindlund_paper.pdf
6. קבצי VISIO - תרשימים

[עריכה] משוב

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

עיוורון צבעים - לדעתי מדובר ב- 8% מהגברים (למרות שבויקיפדיה כתבו 10%). עקביות - על סמך מה אתה אומר שרוב האנשים היו מסדרים את העדיפות בסדר הפוך? היה מחקר בנושא?

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

הקריאה לא שוטפת מספיק לדעתי. אם זו לא היתה העבודה שלך הייתי יוצאת מהאתר די בהתחלה (-: תעשה הגהה חוזרת.

צורת פנייה - או שאתה פונה לקוראים בציווי לאורך העבודה כולה או שלא, אבל תהיה עקבי (אם זה מדריך אז עדיף ציווי).

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