מדריך זה מוקדש לנושא ממשק אדם-מחשב. ממשק אדם מחשב (מכונה) הוא מהנושאים המרכזיים המשפיעים על איכות המערכת. הוא משמש חלון הראווה של המערכת מול המשתמש (והלקוחות) ומהווה גורם מרכזי בהצלחה או בכישלון של הטמעת המערכת. ממשק אדם מחשב נועד לתמוך בתהליכי ארגון ושיטות של הארגון (נהלי עבודה), לאפשר למגוון רב של משתמשים (משתמש רגיל, חכם, ומנהל מערכת) לעבוד במערכת בפשטות ויעילות להשגת יעדי הארגון.
מדריך זה מתווה עקרונות, דרישות וכללים מנחים בסיסיים בנושא זה, לצד שיטות לשיפור האינטראקציה בין המשתמש למערכת, אשר תבטיח שימוש נכון ביכולות המערכת, פריון עבודה ושביעות רצון של המשתמשים. המדריך מנחה את המשתמש מה מומלץ לבצע בכל אחד משלבי מחזור החיים של הפרויקט והמסמכים הנדרשים.
פעילות הנדסת גורמי אנוש בפרויקט פיתוח מערכת מידע נועדה להבטיח שהממשק בין המשתמש לבין המערכת יותאם בצורה הטובה ביותר לדרישות התפקיד ולכישורי המשתמש. מימוש נכון של עקרונות הנדסת אנוש במערכת נועד להבטיח קלות למידה ותפעול, הטמעה מהירה ויעילה בארגון, ושביעות רצון של המשתמשים.
מערכות ממוחשבות מצליחות או נכשלות בהשגת יעדיהן (תפעול אפקטיבי בארגון), בין השאר, כתוצאה מהיכולת ו/או הרצון של המשתמשים במערכות אלו. לפיכך:
מטרת שילוב היבטי הנדסת אנוש היא להבטיח, שהאינטראקציה בין המשתמש למערכת תוביל לתפוקה ולשביעות רצון מרביים.
מדריך זה מיועד לסייע, בשלבים הרלוונטיים השונים של מחזור החיים, בהגדרת דרישות בנושא מבנה המסכים ושיטת תפעול המערכת. תכנון היבטים אלה של המערכת באופן שיטתי ותוך התייחסות להמלצות המופיעות כאן, ישביח את המוצר הסופי.
השימוש בסטנדרטים כמו עבודה בסביבת אינטרנט תקל בצורה רצינית ותחסוך במשאבים בזמן הטמעה כך שהמערכת תיטמע בארגון בקלות יחסית.
המדריך הוא כללי, ונותן מענה לדרישות התכנון של מגוון מערכות מידע. הוא אינו תקן מחייב אלא המלצה בלבד. לפיכך, אין המתכנן פטור מהפעלת שיקול דעת לגבי מידת הרלוונטיות של כל המלצה למערכת שלו, וממציאת האיזון הנכון בין עקרונות שאינם יכולים להתקיים במלואם יחדיו. לדוגמא, התנגשות בין העיקרון הקובע שמסך צריך להכיל את כל האינפורמציה הנדרשת לצורך קבלת החלטה נכונה באותו שלב תפעולי ובין העיקרון של הבטחת קריאות ובהירות הנתונים במסך. מציאת האיזון הנכון במצבים כאלה והגדרת פתרון אופטימלי, תוך התחשבות באילוצי המערכת, הם תפקידו העיקרי של מומחה להנדסת אנוש, אשר מומלץ להעסיקו בשלבים השונים של מחזור החיים .
מחקרים אחרונים מראים שחלק נכבד מהוצאות הפיתוח של מערכות מידע מוקצה לנושא הנדסת אנוש. חשוב איפה לוודא שההשקעה היא בכיוון הנכון ולאור העקרונות והכללים המותווים להלן וחשוב לשתף גורמים מקצועיים המתמחים בתחום.
הנדסת אנוש היא אחד הגורמים העקרים בהצלחת ההטמעה של המערכת בארגון. הנדסת האנוש הינה הגדרה של סטנדרטים לאופן המימוש של המערכת שיבוא לידי ביטוי בצורה הויזואלית (המראה) וכן בדרך ההפעלה (פונקציונאלית אפשרית). יש לזכור שתהליך זה צריך להיתמך (להיות מלווה) על ידי תהליך משלים של ארגון ושיטות לצורך שינוי בתהליכים ארגונים במידת הצורך.
מערכת מחשב קלה ללמידה ונוחה בתפעול השוטף, היא יעד הניתן להשגה בעלות סבירה ותוך עמידה בלוח הזמנים של הפרויקט. זאת בתנאי שמומחיות הנדסת אנוש תשולב בצורה אפקטיבית בשלבים השונים של מחזור החיים, כאשר ניתן להשפיע על תהליכי קבלת ההחלטות בנושאי ממשק אדם-מערכת (ראה פירוט בסעיפים קודמים).
סעיף זה מציג רשימת עקרונות הנדסת אנוש המתייחסים להיבטים השונים של הממשק בין המשתמש והמערכת. להלן מספר כללים ליישום נבון של העקרונות המפורטים בהמשך:
· לא כל העקרונות המפורטים כאן רלוונטיים לכל מערכת מידע. יש להפעיל שיקול דעת מקצועי באבחנה בין העיקר והטפל לגבי המערכת הספציפית.
· תכנון נבון של ממשק אדם-מחשב נבחן במידה בה הוא נותן מענה למערכת בכללותה ובמידה בה הוא מביא לידי איזון ושקלול נכון את מכלול היבטי ממשק אדם-מחשב. פעמים רבות יש לשקול בעיות שלTrade-off בין עקרונות ממשק שונים, שלא תמיד יכולים לבוא לידי ביטוי מלא זה לצד זה. לדוגמא: העיקרון הדורש שהמערכת תנחה את המשתמש שלב אחר שלב בתהליך העבודה עומד לעיתים בסתירה מסוימת לעיקרון הדורש תפעול מהיר וקיצורי דרך.
· במקרה של קונפליקט בין שני עקרונות ממשק אדם-מחשב המקשה על יישומם במערכת, יש לבחון בזהירות את היתרונות והחסרונות של מתן עדיפות לאחד מהם מבחינת המשמעות התפעולית. בחינה זאת רצוי מאד שתיעשה על בסיס האינפורמציה והמסקנות של שלב ניתוח התפקיד. מומלץ מאד להתייעץ עם מומחה הנדסת אנוש וחיוני ביותר לקבל את הסכמת מומחה היישום ונציגי המשתמשים.
ישנם כיום אפיוני תפעול סטנדרטיים למערכות מחשב, שהוגדרו ע"י חברות המחשבים הגדולות, סטנדרטים אלו משתנים מעת לעת ולשם עדכון נדרש להיכנס לאתר החברה הנדרשת.
בכל סביבה בה תפותח המערכת יש לבחון, באיזו מידה עונה הסביבה התפעולית הסטנדרטית המוצעת על דרישות הנדסת אנוש של המערכת העתידית. לאחר מכן יש להגדיר ולתכנן היבטי הנדסת אנוש משלימים העונים לדרישות הספציפיות של המערכת, במסגרת האילוצים שמכתיבה סביבת העבודה.
ההמלצות וההנחיות בפרק זה מאחדות, משלימות ומוסיפות נקודות והיבטים שונים מהדוחות והתקנים השונים, אשר הם ההמלצות לשיפור ממשק אדם – מחשב.
העקרונות המוצגים להלן תקפים לחלק ממערכות המידע. יש לשקול בכל מערכת לגופה את הצורך וההצדקה (עלות/תועלת) בניצול היכולת הגראפית שמציעה התצוגה הגראפית בהשוואה לתצוגה הרגילה ואת האיזון הנכון בין גרפיקה מתוחכמת וטקסט פשוט.
להלן "כללי אצבע" ורשימת הנחיות מעשיות לשיפור ממשק אדם-מחשב (הנדסת אנוש) במערכות מידע:
3. אחידות ועקביות בהגדרות, דגשים למסכי הזנה
6. פשטות תפעול
7. פישוט תהליכים התגברות על שגיאות
9. מינוח ושפה
11. חלונות עזר
12. אחזור מידע
13. מסכי עזרה
15. זמני תגובה
17. התאמה אישית
18. אמצעי קלט
19. נגישות
יש להקפיד שהאלמנטים השונים של המערכת (כגון: עץ המסכים, מבנה המסכים, שיטת הניווט וההתמצאות, שדות קלט, מושגים ומונחים, שלבי עבודה ומבנה פלט של המערכת), יתאימו לדרישות ולאילוצי התפקיד של משתמשי המערכת. תפעול המערכת לא יציב בפני המשתמש דרישות החורגות מהגדרת תפקידו מחד גיסא, ומכישוריו מאידך גיסא.
· ניתן לנצל את המהלך של הכנסת המערכת החדשה, על יתרונותיה הטכנולוגיים, לטובת שיפור וייעול תהליכי העבודה במערכת, גם במחיר של שינוי הרגלי עבודה קודמים. תהליך זה חייב להיות מלווה בתמיכה בתהליכים על ידי מומחי ארגון ושיטות.
רוב ההנחיות להלן מתאימות יותר לשלב העיצוב מאשר לאפיון. בכל מקרה, ברור שאלה המלצות בלבד.
תכנון ותפעול ממשק גרפי למשתמש(GUI) היינו עבודה בסביבת חלונות יתחשב בנקודות/המלצות הבאות:
א. מבנה של תצוגות ופעולות ספציפיות יהיה לפי כללי הנדסת אנוש מקובלים ובהתאמה לתהליכי העבודה (משימות) אותם צריך החלון לשרת ובחלוקה מושכלת ונכונה ל"משטחי תצוגה".
ב. סוג ומספר האלמנטים הגרפיים והטקסטואליים המוצגים בכל חלון או משטח תצוגה יתאימו למשימה אותה הוא בא לשרת, לבעל התפקיד ובמקרים מיוחדים גם לסוג ציוד הקצה (גודל המסך, רזולוציה, צבעים וכו').
ג. הקפדה על חלוקה לחלונות ראשיים וחלונות משנה. חלון ראשי עומד "מול" משימה ראשית, תהליך עבודה, או מקטע (סכימה) בבסיס הנתונים (קובץ, תיקיה, סגמנט וכו'). ממנו ניתן להפעיל חלונות משנה כגון: חלון סטטוס, חיפוש, הודעות (כולל "הודעות מתפרצות"), בחירת פונקציות עבודה נוספות (תת-משימות), שינוי מצב (Mode), חלון להפעלות זמניות וכו'.
ד. אפשרות להפעלה של יותר מחלון ראשי אחד, תוך שמירה על פעולות GUI תקניות של הקטנה(Minimize), הגדלה(Maximize) , שחזור(Restore) והזזה של כל חלון ראשי ומעבר ביניהם בפקודת "חלון" או מקש פונקציונאלי קבוע. כל חלון ייפתח לפי גודל הנקבע כברירת מחדל. מס' החלונות הראשיים הפתוחים בו זמנית ייקבע לא רק משיקולי הנדסת אנוש אלא גם משיקולים של תקינות תהליכי עבודה ושלמות בסיס הנתונים.
ה. פעולות דומות, המופיעות בחלונות שונים (חיפוש, למשל), יופעלו במנגנונים זהים ויהיו עקביות ולא ישתנו מחלון לחלון. אם כי יתכן ויתווספו או ירדו (יצבעו בצבע אפור) פרמטרים לא רלוונטיים במסכים אחרים.
ו. חלון ראשי (ומשני) יציג את כל המידע הנחוץ לביצוע הפעולות שהוא מכיל ואת כל ה"כפתורים" והבקרות(Controls) הקשורים בו. פעולות שאינן "פעילות" במצבי חלון מסוימים יוצגו בצורה "חיוורת" ותחסם הפעלתן. ניסיון הפעלה יגרום להצגת הודעת חיווי מתאימה בחלון "הודעות מערכת". החלון יכיל את המרכיבים הבאים:
· כותרת המתארת את תפקיד החלון.
· שטח עבודה: שילוב של כותרות, שדות שיחה עם המפעיל, תפריטים, כפתורי הפעלה, תצוגות גרפיות וכו', המיועדים להצגת מידע למפעיל ולקבלת קלט ממנו כפי שנדרש ע"י הפונקציה של היישום הממומשת בחלון.
· מסגרת לתפעול החלון
ז. חלון עבודה המשמש לצורך הצגת נתונים ו/או להכנסת/שינוי נתונים יאפשר למשתמש ביצוע הפעילויות הנדרשות (בהתאם להרשאות המשתמש) ויכיל את הפונקציות הבאות:
· מקש "סיים/יציאה" - סגירת החלון ללא עדכון נתונים או ביצוע פעולה כלשהו. בפתיחה הבאה החלון יפתח באותו מקום ויהיו בו אותם נתונים.
· מקש "שמור/עדכן" - ביצוע הפעולה ואי סגירת החלון.
· מקש "חזור" - אי ביצוע הפעולה ואי סגירת החלון. החזרת הנתונים האחרונים שנשמרו ("חזור לקובץ שמור").
· הזנת הנתונים תיתכן במספר שיטות: הקלדה, בחירה מטבלה, עריכה גרפית וכו' ותכלול "יישור" לשמאל (לערכים נומריים) ולימין (למלל עברי), תמיכה בשדות חסומים, שדות בלתי נראים ועוד.
· אפשרות לתיקון שגיאות, "בטל", עריכה, בדיקות לוגיות והתראות על אי חוקיות נתונים.
· שלימות ותיאום מלא עם בסיס הנתונים: ברור למשתמש הרגע בו מוזנים הנתונים ומשנים את מצב בסיס הנתונים.
· במערכות עתירות גרפיקה תיתכן דרישה לתמיכה בעריכה והזנה של נתונים גראפיים כולל שילוב מידע טקסטואלי כחלק מהישות הגראפית.
א. סדר פעולות אחיד ועקבי ושימוש זהה בתהליכי תפעול והזנת נתונים במסכים השונים. חשוב שפעולות דומות תתבצענה בצורה זהה, בפונקציות שונות ובמסכים שונים.
ב. ריבוי כפתורים/תפריטים סטנדרטים בעלי אחידות תפעולית בכל המערכת.
ג. אחידות עם מערכות מחשב אחרות בארגון, אם כי חשוב להתיישר מול סטנדרט חלונאי או אינטרנטי מאשר להנציח שיטת עבודה מיושנת שקיימת בארגון.
ד. אחידות במשמעות ושימוש במונחים זהים בכל חלקי המערכת.
ה. פורמט אחיד (סטנדרט) של האלמנטים השונים הכלולים במסכי המערכת :
1. שורת כותרת ברורה, הכוללת את שם היישום ופרטים רלוונטיים.
2. מקום קבוע ואחיד לשורת הודעות, התרעות מערכת, הודעת נחייה ושגיאה.
3. פורמט קבוע למבנה "חלונות", מיקומם במסך, שיטת תפעולם.
4. פורמט קבוע למבנה תפריטים/סרגלי כלים/תפריט קליק ימני, מיקומם במסך, שיטת תפעולם ויכולת למקם אותם כך שיסתירו כמה שפחות תוך שימוש במזעור/הצפה/שינוי גודל/שינוי מיקום.
5. ניתן לבצע סטייה מהמבנה הסטנדרטי שהוגדר, לצורך הדגשה או הדגשה של נושא. רצוי לבדוק אם קיים סטנדרט או לקבוע חדש לפני החריגה.
6. סדר הצגת הנתונים במסך צריך לתאום את סדר הפריטים בטופס הידני המשמש להזנת המערכת.
7. לאפשר הפעלת חלונות במקביל (לבצע פעילות בחלון אחד גם ללא סיום פעולה קודמת בחלון אחר. בסיום הפעולה ניתן לחזור לפעילות הקודמת). הגדרה זו נכונה בדרך כלל לגבי פעילות מקבילה המאפשרת להעלות ולתפעל חלונות שונים בו זמנית.
ו. פורמט קבוע ל-Tooltip (כשהעכבר נמצא על אובייקט/כפתור/תפריט... מופיע תיבת הסבר/הנחייה).
ז. אחידות בשיטת הזנת הנתונים בכל סוגי המסכים במערכת.
א. בדיקות תקינות אוטומטית (הפעלת חוקים עסקים, תקפות הנתונים שהוזנו ותנאים מורכבים) יבוצעו בכל מקום אפשרי (תוך כדי הזנת נתון/לאחר הזנת נתון/לפני הזנת נתון) מומלץ לא לחכות לסיום הזנה של כל הטופס לביצוע הבדיקות.
ב. שמירת/עדכון הנתונים ע"י המערכת יתחיל רק לאחר "אישור" המשתמש.
ג. הצורך להקיש בו זמנית על מספר מקשים (למשל- הקשה סימולטאנית על מקש Ctrl ומקש אחר) נועד לביצוע פעולות מורכבות ובעייתיות שברצוננו לוודא שהמשתמש אומנם התכוון (לדוגמא אתחול מערכת יכול לגרום לאיבוד נתונים של מספר שעות עבודה).
ד. המערכת תציין בבירור מצב של אי-קליטת נתונים, והתנאים לביטול מצב זה.
ה. שדה הזנת מלל חופשי יאפשר הוספה קלה של שורות בהתאם לצורך.
ו. המערכת תאפשר הכנסה אוטומטית של אלמנטים קבועים בקלט, כגון נקודה עשרונית.
ז. בהקלדת נתונים בזמן אמת יושם דגש מיוחד בתכנון על: מינימום הקשות, שימוש מרבי בברירת מחדל, בחירה מתוך תפריטים, קיצורי דרך, זמן תגובה מהיר של המערכת והתאמה לסוג המשתמש (קלדנית בניקוב, מזכירה וכד').
א. במסך יוצגו רק הנתונים הרלוונטיים לביצוע הפעולה הנדרשת, שאר הנתונים יוסתרו.
ב. למשתמש תהיה אפשרות להרחיב את הנתונים המוצגים בכל זמן נתון ע"י בקשה (לדוגמא לחיצה על כפתור "הרחב"/Options)
ג. אם המקום מאפשר הצגת נתוני רקע "לידיעה בלבד" - יופרדו אלה באופן בולט מנתוני התפעול העיקריים בצורה ויזואלית תוך שימוש בתיחום (מסגרת) צבע רקע שונה וכדומה.
ד. הנתונים יאורגנו בפורמט מוכר ומקובל למשתמש. סידור ועריכת הנתונים ייעשה לפי סדר הגיוני, המשקף את תהליך העבודה.
ה. יש ליצור אבחנה ויזואלית בין שדה נתונים שהוא חובה להקשה ושדה רשות.
ו. יש קשר הדוק בין רמת העיצוב הגראפי/אסתטי של הנתונים במסך ובין מידת הקריאות, הבהירות והמובחנות של הנתונים במסך.
ז. ציון המיקום העכשווי להכנסת הנתונים יעשה ע"י שינוי צבע שדה ההזנה (לכחול לדוגמא) או ע"י הסמן (במקרה של שימוש בסמן יהיה בעל צורה בולטת ומובחנת להקל על איתורו, ויעוצב כך שלא יסתיר תווים במקום עליו הוא עומד).
ח. עודפות מידע (הצגת אותו פריט מידע באופנים שונים או בפעמים חוזרות) מקטינה את הסיכוי לטעות והיא רצויה במצבים הדורשים קשב רב מהמשתמש. למשל - הודעה על שגיאה גם בערוץ הקולי וגם בערוץ הוויזואלי. בכל מקרה יש לשקול את עיקרון העודפות מול עקרונות אחרים, כגון עומס אינפורמציה, הטרדת המפעיל המיומן וכו'.
א. עץ התפריטים יהיה פשוט והגיוני, וישקף את מבנה התפקיד. חיוני שמבנה התפקיד יהיה מקובל ומוסכם על המשתמש.
ב. מומלץ להשתמש בתפריטים או בקיצורי דרך כאמצעי כניסה ראשוני למערכת, או למעבר בין תת-מערכות עיקריות. מעברים אחרים בין פונקציות מומלץ לבצע באמצעות סרגל כלים או תפריטים נגללים.
ג. שימוש בתפריטים השונים (לוח תפריט, סרגל קיצורי דרך, סרגל כלים, ומקשי קיצור) יבוצע לפי הסטנדרט החלונאי, תוך קלות הפעלה מכל מקום במערכת. למשתמש תהיה האפשרות לבחור את הפונקציונאליות הנדרשת מכל אחת מהאפשריות הנדרשות (לדוגמא הדפסה: בתפריט - קובץ הדפסה, סרגל כלים – אייקון מדפסת, קליק ימני הדפסה, מקשי קיצורCtrl+P).
ד. אם משתמשים בתפריטים כדי להפעיל האופציות השונות סדר אותם באופן לוגי בעץ תפריטים הירארכי, ואל תאגד אותם רק בצורה שרירותית. בתוך אשכול האופציות הקיימות בצומת אחד בעץ, תאבחן בצורה גרפית, בין הקבוצות השונות של אופציות משותפות (לדוגמא, בתפריט קובץ, תבחין בין הדפס ותצוגת הדפס מחד, ומסמך חדש ופתח מסמך מאידך). חשוב שלמשתמש תהיה אינדיקציה אלו פעולות אפשריות ברגע זה ומה ניתן לבצע בכלל.
ה. סעיפי התפריט המשני יאורגנו על פי תדירות השימוש בהם לעומת התפריט הראשי שיאורגן לפי הסדר הלוגי והמשפחתי של הפעילויות.
ו. ניסוח סעיף בתפריט יופיע בצורה זהה ככותרת במסך הנובע מהסעיף, רצוי להיצמד לניסוחי כותרות זהה לסטנדרט (לדוגמא קובץ, עריכה, תצוגה....)
ז. יש להציג למשתמש זיהוי מובחן לגבי מיקומו העכשווי בעץ התפריטים. כל תפריט חייב לקבל כותרת, ופריטים או אופציות שנבחרו הופכים להיות הכותרת של התפריט הבא בהירארכיה או בעץ התפריטים.
א. כל חלון יישום ראשי, מכיל לוח תפריטים (menu) אשר יכול לכלול תפריטים נגללים (pull down menus), המתארים את הפעולות האפשריות בחלון.
ב. תפריט pop up מציג אוסף של פעולות הנוגעות ישירות לאותו עצם. הפעלתם נעשית בשיטת "בחר ופעל" (select and act), כלומר, קודם נבחר העצם (object) ולאחר מכן מופעל התפריט תוך הצגה של האפשריות הרלוונטיות
קיים סרגל קיצורי דרך המאפשר גישה ישירה למערכת/תת מערכת ע"י בחירה ישירה ללא צורך בטיול בתפריטים.
כל חלון יישום, מכיל סרגלי כלים עם צלמיות סטנדרטיות שלחיצה עליהם מפעילה פונקציונאליות נדרשת (לדוגמא לחיצה על צלמית מדפסת תגרום למסך הדפסה להופיע).
הפעלת מקשי קיצור תגרום להפעלת הפונקציונאליות הנדרשת (לדוגמא הקשה על Ctrl+P תגרום למסך הדפסה להופיע).
למשתמש תהיה התמצאות ושליטה מלאים במערכת ויהיה ברור לו בכל רגע:
א. היכן הוא נמצא במערכת.
ב. מה "מצב" המערכת איזה חלון פעיל ומה הפונקציונאליות אפשרית במצב זה: קליטה, עדכון, חזרה (ביטול) וכו'
ג. לאילו פונקציות/מצבים אחרים ניתן לעבור מהמצב הנוכחי.
ד. כיצד ניתן לנווט בחלון במהירות לתפריטים הרלוונטיים (תפריטים, סרגלי כלים, תפריט קליק ימני..) ושם בחירה של הפונקציונאליות הנדרשת (לדוגמא : יציאה עם שמירה או ללא שמירה).
ה. במקרה של מערכות משולבות: לאילו מערכות אחרות ניתן לעבור בכל רגע, באיזו מערכת אני נמצא כעת.
ו. ניווט (navigation): המערכת תספק שירותי ניווט יעילים ברמות הבאות:
· רמת החלון: הניווט הסטנדרטי יתבצע באמצעות עכבר תוך אפשרות של שימוש במקשים (לדוגמא tab ו- enter אשר עוברים בין השדות או התצוגות במסך). בדרך זו יכול המשתמש לעבור בין ישויות תצוגה על פי סדר ההפעלה הנורמטיבי. השימוש במקשים יהיה יעיל יותר במסכי הזנה שקלדנית מבצעת הקשה של חומר מטפסים לדוגמא.
· רמת המערכת: סרגל קיצורי דרך/סרגלי כלים/תפריטים/כפתורים יזכירו למשתמש לאן ניתן להמשיך ומאין הוא בא.
ז. חזרה למצב ברירת מחדל: בהפעלת המערכת מגיעים לתצוגת ברירת מחדל אליה ניתן לחזור בקלות מכל מצב ע"י יציאה וכניסה מחדש או ע"י בחירת פונקציונאלית של חזרה למצב ברירת מחדל.
ח. מסך עבודה שיבחר בהוספת חדש תופענה התצוגות (סוג, הרכב, סידור על המסך) ע"פ ברירות המחדל.
ט. הגדרת פרופיל משתמש מאפשרת למשתמש להגדיר את תצוגות ברירת המחדל שיופעלו בעת הפעלת מסך או תצוגה כל שהיא לפי העדפותיו.
י. חזרה למצב עבודה אחרון תקין: מאפשר שיחזור המצב האחרון של המערכת. שמירת המצב האחרון תתבצע באופן אוטומטי ע"י המערכת (לדוגמא בעת נפילת מתח, דילוג עמדה וכו') והחזרה אליה תתבצע באופן אוטומטי כאשר לא הייתה הורדת מערכת מסודרת ובצורה יזומה לאחר הורדת מערכת מסודרת.
א. המערכת תאפשר כניסה נוחה ומהירה למשתמש, בלא צורך להקיש נתונים שניתן להסיקם מהמספר המזהה אותו (למשל- מס' עובד) או ממידע אחר שגרם לכניסה לחלון הנוכחי.
ב. יש לצמצם למינימום את מספר ההקשות הנדרש להשלמת פונקציה כלשהי, רצוי שהמערכת תציע ותציג מספר ערכים אפשריות לשדות שההקשה בהם זהה.
ג. השימוש בלחיצה על מספר מקשים בו-זמנית (למשל: לחיצה על ctrl-f2, או: shift-f2) נועדה לוודא שביצוע פעולה בעייתית לא תבוצע בטעות.
ד. רצף הפעולות יהיה פשוט ומאורגן, עם התחלה, אמצע וסוף ברורים ומובנים למשתמש.
ה. העברת נתונים שהוזנו (או "נבחרו") במסך אחד אוטומטית למסכים/ פונקציות אחרים, בהם נתונים אלה רלוונטיים. המשתמש לא יידרש לזכור נתונים (או לרשום על פתק) במעבר ממסך אחד לשני.
ו. שימוש בברירות מחדל בכל מקום אפשרי במערכת. המערכת תציג את ברירות המחדל שבתוקף, או תאפשר את הצגתן בקלות. תסופק שיטה נוחה לשינוי ברירות המחדל ע"י המשתמש המוסמך לכך.
ז. כשנתונים בשדה מסוים יכולים להיות בעלי אורכים שונים, תבצע המערכת אוטומטית פעולות יישור או מילוי המקומות הריקים. חשוב להציג למשתמש את התבנית הנתונים הנדרשת בשורת ההנחיה לדוגמא תאריך יש להציג את פורמט התאריך הנדרש DD/MM/YYYY .
ח. רצוי לתת למשתמש סרגל קיצורי דרך בו ניתן לחסוך הקשות ולהגיע למקום רצוי על הקשה אחת.
א. למשתמש המתחיל תתאפשר שיטת תפעול עם עזרה והנחיה. המשתמש יפעיל את פונקצית אימון (tutor, סימולציה), המאפשרת תרגול והמחשה של אופן פעולת המערכת. תפעול פונקציה זאת לא ישפיע על מאגר הנתונים של המערכת. לפונקצית האימון יהיה תפקיד פעיל בשלב ההדרכה הראשונית והדרכות שוטפות בעתיד.
ב. חשוב לתת למשתמש WIZARD מנחה שילווה את המשתמש בביצוע פעולות מורכבות שלא מבוצעות ביום יום ובכך יגרום למשתמש להגיע לתוצאות טובות יותר ומהר.
ג. רצוי שהמערכת תספק משוב למתאמן בהיבטים הבאים:
· משך הזמן שהמשתמש יצטרך לצורך ביצוע הפעילות הכוללת והגדרה של כל שלב.
· שכיחות שגיאות לסוגיהן, בפונקציות השונות.
· רמת המשתמש יחסית לנורמה הנדרשת (קריטריון מוגדר מראש שהמשתמש יוכל לבחור באיזו רמת קושי לעבוד).
· המערכת תפיק סיכום אימון, שיכלול את פרטי המתאמן ותוצאותיו בפרמטרים הנ"ל. והמלצות לשיפור או הצעה לתוכנית אימון נדרשת, הפניה והמלצה לחזרה על פרקים שהמשתמש חלש בהם ועוד.
· המערכת תפיק סיכום סטטיסטי תקופתי של האימון, בחתכים שיוגדרו מראש.
א. המערכת תבדוק אוטומטית את חוקיות הנתונים המוזנים, ובמקרה של איתור נתון לא סביר - תתריע על כך מיידית ע"י התרעה קולית, וסימון (למשל הבהוב) השדה השגוי תוך מתן הנחייה לתיקון השגיאה בשורת ההנחיות.
ב. המערכת תבחין בין סוגי שגיאות שונים, ותציג הודעה משמעותית המנחה על פעולת התיקון הנדרשת, או מה נדרש מהמשתמש בשדה זה (מה הפורמט הנדרש למילוי שדה זה).
ג. פעולת התיקון תהיה פשוטה, קצרה ועקבית בכל המערכת. חשוב מאוד ששדה מלל באורך גדול המערכת תאפשר למשתמש לבצע תיקון של תו אחד במחרוזת ולא תחייב את המשתמש להקיש מחדש את כל השדה מהתחלה.
ד. במקרה שהמערכת מאתרת מספר שגיאות - היא תסמן באופן בולט את כולן, ותשאיר את הסימון עד לתיקון כל השגיאות. חשוב להגיע למצב ששגיאה שהתגלתה ע"י המערכת תחזיר חיווי למשתמש תוך כדי הקשה/בסיום הקשה הנתון ולא בסיום ההקשה כללי של כל הטופס ובכך תהליך תיקון השגיאה יצומצם למינימום.
ה. רצוי שהמערכת תציג פיתרון/ערכים אפשריים במקרה של שדה שגוי, בכך יחסך זמן רב בתיקון השגיאות.
א. שיטת התפעול תקטין את ההסתברות לביצוע בשוגג של פעולה חמורה שתוצאותיה אינן הפיכות, או שהן מצריכות מאמץ רב יחסית לשם כך.
ב. רצוי לבצע "הקשחה" של המערכת כלומר מחיקת/מניעת ביצוע פעולות בלתי הפיכות ע"י המשתמש כך שהמשתמש לא יגיע לביצוע פעולה בלתי הפיכה.
ג. המערכת תגן מפני שינוי נתונים במאגרים מסוימים, בלא לסמוך על זיכרון המשתמש, כולל מניעת כניסה לפונקציות או קבצי נתונים שיוגדרו כך.
ד. רצוי שכל פעולה תהיה הפיכה, ותאפשר חזרה בקלות למצב שלפני ביצועה - UNDO .
ה. כשפעולה אינה הפיכה - רצויה הודעת מערכת ברורה על כך, כמו כן נדרש לקבל אישור נוסף לכל פעולה שהמשמעות שלה שהיא בלתי הפיכה.
ו. במסכי האישור של ביצוע פעולה בלתי הפיכה חשוב שברירית המחדל היא שהפעולה לא תבוצע (לדוגמא האם ברצונך למחוק – ברירת המחדל היא לא) כך מקבלים בעקיפין אישור נוסף לביצוע פעולה מבלי להרגיז את המשתמש.
ז. הערה – אין במטרה של סעיף זה להחליף את מערכת הגיבויים והשחזורים המבוצעים באופן שוטף.
א. יש להשתמש במונחים בשפה המוכרת ומקובלת על המשתמשים והמתאימה למערכת הנידונה. ראה רכיב 2.1.4 – מילון מונחים בעץ המערכת הנידונה.
ב. יש לנסח הנחיות בשפה פשוטה וברורה. לדוגמה:
מומלץ: "תקלה במקלדת".
לא מומלץ: "תקלה במעבד".
ג. ההודעות יהיו ספציפיות ככל האפשר ולא כלליות. לדוגמה:
מומלץ: "הקשה שגויה יש להקיש מספר תעודת הזהות כולל ספרת בקורת " (הודעה משמעותית הכוללת הגדרת השגיאה והנחיה לתיקון השגיאה).
לא מומלץ: "טעית בהקשה" (הודעה סתמית)
ד. שמות הפקודות צריכים להיות מובחנים זה מזה, קצרים, ומרמזים בבירור על מהות הפקודה. מאידך, גם עקביים. חשוב להיצמד לביטויים לפי הסטנדרט החלונאי לדוגמה : קובץ, עריכה, תצוגה, חלון...
ה. יש להשתמש במשפטים חיוביים קצרים ולהימנע ממשפטים שליליים. יש לומר למשתמש מה לעשות ולא ממה להימנע. לדוגמה:
מומלץ: "מחק המסך לפני הכנסת הנתונים".
לא מומלץ: "אין להכניס נתונים לפני מחיקת המסך".
ו. יש להשתמש במשפטים פעילים שהנם קלים ומהירים יותר להבנה. לדוגמה:
מומלץ: "מחק הנתון ע"י לחיצה במקש DELETE".
לא מומלץ: "הנתון ימחק רק לאחר לחיצה על מקש DELETE ".
ז. סדר המילים בניסוח הודעה המתארת רצף של פעולות, צריך להיות תואם לסדר ההתרחשויות במערכת. לדוגמה:
מומלץ: הקש אישור למעבר למסך הבא.
לא מומלץ: למעבר למסך הבא יש להקיש אישור.
ח. מומלץ להשתמש במילון הודעות אחיד בכל המערכת, כך נוצר בנק או מאגר הודעות מרכזי אחיד. היתרונות של מאגר מרכזי ששינוי נוסך הודעה אינו גורם לשינוי תוכנה וכן הנוסח אחיד ומשתמש יקבל הודעות זהות ומוכרות במערכת. יתרון נוסף הוא תוסף לתמיכה של המערכת בריבוי שפות.
א. כל המידע הנדרש לביצוע המטלה צריך להיות זמין/נגיש במסך – לא תמיד חלק פיזי של המסך ( טבלת קודים, סרגל קיצורי דרך, טבלת נתוני עזר, הנחיות לביצוע וכו').
ב. מידע העשוי להיות נחוץ ואין לו מקום במסך - יוצג ב"חלון" נפרד כמסך עזרה (Help) מקושר, כפתורי הרחבה ועוד.
ג. הודעות מערכת ו/או הנחיות קבועות במסך יזכירו למשתמש את התהליך הארגוני (תהליך האו"ש) שהמסך תומך בו.
ד. המשתמש לא יידרש לזכור נתונים ממסך אחד למשנהו.
ההנחיות להלן הן תמצית בלבד ומוקדשות בעיקר לתפעול של חלונות עזר. לנושא חלונות מוקדש סעיף ראשי מיוחד להלן.
א. מידע חיוני שלא ניתן להציגו במסך מטעמי עומס יוצג ב"חלון".
ב. ייעשה שימוש בחלון לצורך תפעולי (למשל- בחירה מתפריט), כדי למנוע צורך לצאת לתפריט או מסך אחר לשם כך.
ג. החלון יופיע באזור קבוע במסך, ולא יסתיר אינפורמציה חיונית.
ד. האלמנטים הקבועים של החלון, כגון מסגרת, כותרת, שורת הנחיות, שדה קלט וכו', יקבלו הבלטה גרפית הולמת.
ה. הצגת החלון והעלמתו תיעשה ע"י פעולת הקשה אחת.
ו. בחירת פריט מתוך חלון תשולב אוטומטית בשדה הקלט המתאים במסך.
ז. במקרה הצורך (דינאמי לפי כמות המידע) ניתן יהיה לבצע ב"חלון" פעולות Scroll, באותן שיטות הנהוגות בחלונות, נדרשת תמיכה במקשי פעולה לקיצור ולגיבוי שימוש בעכבר לדוגמא הגעה לסוף ENDוקפיצה להתחלה HOME ועוד.
ח. רצוי שמידע לא רלוונטי או עודף למשתמש יוסתר ויהיה נגיש למשתמש לפתיחה/הצגה במידת הצורך בלבד.
למידע נוסף ומפורט בנושא חלונות וממשק משתמש גרפי (GUI), ראה סעיף 2 תכנון ותפעול חלונות לעיל.
א. חיפוש פריט ברשימה ארוכה ע"י הקשת קידומת חלקית של הפריט ((wild card.
ב. "חיפוש מחדש" של הפריט הבא המתאים לבקשת האחזור המקורית.
ג. חיפוש ע"י חיתוך תנאים פשוטים ומורכבים, ותחום בחירה (תת-אוכלוסייה).
ד. יכולת מעבר נוחה מאחזור לעדכון, יחד עם בקרה ואבטחת מידע.
ה. אחידות בפרמטרים ובאפשרויות החיפוש השונות (ויזואליות אחידה) בתתי המערכות השונות.
למידע מפורט יותר על הנושא עיין בקיט אחזור טקסט TRS בכרך התמחויות/מערכות מידע.
מבנה מסך העזרה שהוא מבנה סטנדרטי ואוסף כלים המאפשר בניית העזרה בצורה נוחה ומהירה – סטנדרטית.
א. עץ נושאים
ב. הקשת מלל וחיפוש לפי איזו פעולה ברצונך לבצע ?
ג. אינדקס המאפשר הקלדת בחירה מילות מפתח לצורך ביצוע חיפוש לפיהן
ד. סייען (אופציונאלי)
ה. Wizard (אופציונאלי)
ו. הצגת מסך עזרה וחזרה למסך הראשי - ע"י פעולת הקשה אחת בלבד.
ז. ניסוח מסך העזרה יהיה פשוט, קצר ובשפה ברורה למשתמש. רצוי לתת דוגמאות למבנה הקלט הנדרש.
ח. רצויה עזרה ברמות השונות : רמת מערכת, תת מערכת, מסך, נושא והשדה הספציפי בו נמצא הסמן.
ט. חשוב להוסיף אפשרות לחיפוש ודפדוף בעזרה (ראה סעיף אחזור מידע נוח).
י. במידת הצורך יש לאפשר ביצוע פעולת "בחירה" במסך העזרה, שתועבר אוטומטית למסך התפעול הראשי.
יא. חייבת להיות התאמה בין מסכי העזרה ובין המדריך למשתמש.
א. יוצג משוב ברור לכל אירוע במערכת שהמשתמש צריך להיות מודע להתרחשותו, לשם התמצאות במצב המערכת בכל רגע נתון:
· לכל הקשת מקש (פקודה/פונקציה ועוד).
· לציון ביצוע פעולה (טרנזקציה) שמשכה עולה על- 2 שניות יש להציג בר התקדמות והערכה כמה זמן תארך הפעולה.
· לציון סיום פעולה ותוצאותיה.
· ביציאה שתגרום לאיבוד מידע באם לא נשמור את הנתונים.
ב. סוג המשוב ומידת ההדגשה שלו צריכים להיות פונקציה של חשיבות ו/או שכיחות האירוע (משוב בולט יותר לאירוע נדיר), המשוב צריך להתבטא בצורה ויזואלית (צבע, הדגשה...), קולית, תיבת אישור המחייבת את התערבות המשתמש להמשך (לדוגמא הודעה מתפרצת עם אישור).
ג. המשוב השכיח ביותר הוא המשוב החזותי (הודעה, הדגשה, הבהוב וכו'). השימוש בו צריך לצאת מתוך הנחה, שכדי לראות את המשוב החזותי צריך המשתמש להביט במסך.
ד. המשוב הקולי נועד להבטיח שתשומת ליבו של המשתמש תופנה למערכת, גם אם אינו מביט במסך באותו רגע (למשל - התרעה המחייבת התייחסות מיידית, הקשת שדה או תו שגוי, סיום טרנזקציה ממושכת). למשוב הקולי יש נטייה להטריד, לאחר תקופה מסוימת, משתמשים מיומנים. לפיכך יש לתת למשתמש אפשרות לשלוט בעוצמת המשוב, או לבטלו לחלוטין.
ה. לעתים קרובות יש לשקול שימוש במשוב חזותי וקולי במקביל, ליצירת עודפות (redundancy) שתבטיח את תשומת ליבו של המשתמש. עודפות זאת חשובה בעיקר אם ניתנת למשתמש אפשרות להחליש או לבטל את עוצמת המשוב הקולי.
הצגת סטטוס באה לאפשר התמצאות טובה במצב המערכת בכל רגע בלי צורך לסכם, לרשום על נייר או לזכור בע"פ מידע כלשהו. הצגת הסטטוס היא חלק בלתי נפרד מהמסך ומופעיה מתקיימים על גבי צג העמדה. תמצית נתוני הסטטוס תבוצע במקום קבוע על גבי התצוגה כך שלא יהיה צורך לחפשם. הגעה לפירוט וחלק מהתפעול המתייחס לתצוגת הסטטוס יבוצעו באזור תצוגה זה, כך שניתן יהיה להגיע בקלות לרובדי המידע הנוספים שאינם בתצוגה הקבועה. במקרה של שינויי סטטוס המסכנים את המערכת או חלק ממרכיביה, ו/או המשימה תופיע "הודעה מתפרצת" על גבי התצוגה הגרפית.
זמן תגובה ארוך של המערכת נסבל ע"י המשתמש ואינו פוגע בתפקודו בשני תנאים: כשהמשתמש תופס את זמן התגובה כסביר למטלה שמבצע המחשב, וכשהמערכת מספקת משוב ברור על מצב "המתנה" ועל סיומו. (לדוגמא בר התקדמות כולל אחוז נוכחי מתוך השלם - % 100 ).
תגובות המערכת צריכות להיות מהירות עבור אותן פעולות הנתפסות ע"י המשתמש כפשוטות, ואשר יש צורך לבצען בזמן אמת.
להלן המלצות לזמן תגובת המערכת מרגע ביצוע הפעולה ע"י המשתמש:
|
להקלדת תו אלפאנומרי: |
עד 0.1 שנייה |
|
להזזת הסמן ע"י עכבר: |
עד 0.1 שנייה |
|
לפעולת בקרה כגון דפדוף: |
עד 0.5 שנייה |
|
להחלפת מסך: |
עד 2.0 שניות |
|
להופעת הודעת שגיאה: |
עד 2.0 שניות |
|
לאישור עדכון בסיס הנתונים: |
עד 2.0 שניות |
|
לאחזור נתון מבסיס נתונים : |
2 שניות (במקרה קיצוני- 15 שניות) |
|
ליצירת קשר עם מערכת אחרת: |
2 שניות (במקרה קיצוני- 15 שניות) |
בכל מצב שזמן התגובה הצפוי מעבר ל- 2 שניות יש להציג משוב על כך.
זמני תגובה אלה הם המלצות שיש לשאוף אליהם, אך אינם "תורה מסיני". בכל פרויקט יש לדון לגופו של עניין. ברוב המקרים של זמן תגובה לא טובים חשוב לבצע ניתוח הגורמים ולשאוף להוריד את זמני התגובה כמה שקרוב לסטנדרט שפורט. (לדוגמא טעינת הדף הראשון והצגתו וברקע לבצע טעינה של דפי ההמשך או טעינת X רשומות ראשונות והצגתם ואחר הצגה של ההמשך.
יש לנצל באופן מושכל את תכונות התצוגה, בהתאם לקריטריונים הבאים:
א. רצוי להשתמש בשתי רמות בהירות בלבד.
ב. רמת בהירות גבוהה בחלק נרחב במסך עלולה לגרום לבוהק מטריד.
מתאים להבלטה של אות, מילה או מספר מילים. לא רצוי להשתמש בשיטה זו לצורך הבלטה של שטח גדול בתצוגה. ניתן לשינוי בתחנת העבודה של המשתמש ע"י שינוי של הגדרות התצוגה של תחנת העבודה.
א. להבהוב יש אפקט חזק של משיכת תשומת לב ולכן כל שימוש בלתי נחוץ בו עלול לגרום להפרעה רצינית למשתמש, או התמקדות בתפל במקום בעיקר.
ב. יש להשתמש בהבהוב למשיכת קשב מיידי לנתון מסוים המחייב התייחסות מיידית.
ג. בכל מקרה של שימוש בהבהוב - הוא יבוטל אוטומטית כשהאירוע שגרם להבהוב הסתיים.
ד. אין להגדיר מצב של הבהוב מתמשך לציון אירוע מסוים שאינו מפריע לתפעול השוטף. למשל - הבהוב של המילה "הודעות" כל עוד יש הודעה במאגר. בכל מקרה, יש לאפשר למשתמש לבטל את ההבהוב.
ה. יש לשקול לעתים שלא להבהב את הנתון עצמו, אלא סימן נוסף (כגון כוכבית) שישמש כמציין המהבהב. הבהוב מקטין את רמת הקריאות של התווים המהבהבים ומפריע גם לקריאות תווים אחרים סמוכים.
ו. קצב ההבהוב הרצוי הוא בתחום של 2-3 הרץ. רצוי להשתמש בשתי רמות בלבד: מהבהב לעומת לא מהבהב.
בעבודה שוטפת מומלץ לא להשתמש בהבהוב – אלא בהודעות מתפרצות או כל אמצעי אחר.
א. רצוי לשקול שילוב צבע רק במערכת מידע בה המסכים עמוסים והשיטות המקובלות להבלטת הנתונים וארגון המסך אינן מספקות.
ב. הוספת צבע במקרה בו הוא אינו נחוץ אינה מעלה ואינה מורידה ולעתים קרובות אף עלולה להזיק מהסיבות הבאות:
· העייפות הוויזואלית מוגברת במסכי צבע, חשוב להתיישר מול הסטנדרט החלונאי. תופעה זו באה לידי ביטוי לאחר מס' שעות עבודה. העיפות משתנה ממשתמש למשתמש לכן חשוב לתת למשתמש אפשרות לשינוי הצבעים לפי רצון המשתמש ולאפשר לו לשמור אותם.
· הקצאת צבעים לקויה לסוגי המידע השונים בתצוגה, שלא לפי שיקולי הנדסת אנוש ועיצוב גראפי/אסתטי נכונים, עלולה לגרום לתוצאות שליליות כגון: הפרעה במיקוד הראייה על נתונים מסוימים במסך, קונטרסט (יחס אות/רקע) נמוך מדי.
ג. תכנון השימוש בצבעים במסך צריך להתחשב בתופעת "עיוורון הצבעים". כאשר קוד הצבע חשוב לצורך תפעול - יש לוודא שיהיה במקביל קוד נוסף (למשל- מיקום, קו תחתי וכו') לשימושו של עיוור הצבעים. זאת דוגמא ליישומו של עקרון ה"עודפות" (redundancy) במערכת.
ד. הצבעים המומלצים ביותר לסביבה משרדית בעלת תאורה טובה, הם רקע בהיר וכיתוב אלפאנומרי כהה (אנלוגי לדף של ספר). יש לשקול לגופו של עניין את הגוון המדויק של כל צבע, בהתאם לשיקולי הנדסת אנוש ועיצוב גראפי/ אסתטי.
ה. השימוש בקוד צבע צריך להיות עקבי עם האסוציאציה המקובלת של משמעותו בקרב המשתמשים. לדוגמה: אדום מקושר עם סכנה, צהוב מקושר עם זהירות, ירוק וכחול מייצגים תנאים רגילים, ויכולים לשמש להצגת נתונים תקינים ו/או שגרתיים.
ו. להבלטת קבוצות נתונים בעלות מכנה משותף המקובצות יחד במסך, או מפוזרות על פני המסך, ניתן לשקול הצגתן בצבע אחיד , אם כי השימוש היום (הסטנדרט) הוא קיבוץ בעזרת מסגרות המתחמים את הנתונים במקום שימוש בצבעים שונים.
ז. שימוש בצבע אחיד במסך (לבן, אפור וכדומה) עדיף מאחר והוא מרגיע את העין וחלקי מסך אחרים אינם קופצים לעין.
א. תדר הצליל
· לשימוש בתדר אחד בלבד: 1,000 הרץ.
· לשימוש בשני תדרים: 800 הרץ ו- 1,600- הרץ (הצורך בכך נדיר ביותר).
ב. משך הצליל:
· מומלץ צליל באורך- 150 Msec ולא פחות מ- 100 Msec.
· מומלץ לאפשר למפעיל יכולת ויסות מהירה ופשוטה של עוצמת הקול במערכת, עד לביטולו המלא.
הגודל של מסך המחשב הסטנדרטי והרזולוציה שלו הולכים וגדלים בצורה מתמדת. כיום גודל המסך הסטנדרטי הוא לפחות 21 אינטש, ואילו הרזולוציה הסטנדרטית היא לפחות 1024 X 768 פיקסלים. כמות המידע שניתן להציג בצורה הנוחה למשתמש הוא פונקציה של גודל המסך וחדות הרזולוציה שלו. כשמכנים את ממשק המשתמש צריכים להחליט מראש לכמה גדלי רזולוציה רוצים לתכנן אותו ולאיזה מהן לפי השיקולים הבאים:
· תצוגות בעלות רזולוציות נמוכות מכילות פחות מידע, אבל ניתן לראותן גם במסכים בעלי רזולוציות גבוהות.
· ניתן לראות תצוגות בעלות רזולוציות גבוהות גם במסכים בעלי רזולוציות נמוכות אבל רק בגלילה.
· בתמיכה בו-זמנית ברזולוציות אחדות כרוכות משאבי פיתוח ותחזוקה נוספים.
א. שמירה אוטומטית/לפי דרישה של המצב האחרון שהמשתמש היה בו לפני היציאה, כך שבכניסה מחודשת המשתמש יחזור בדיוק למצב בו היה כברירת מחדל.
ב. כיום נפוץ מאוד לתת למשתמש אפשרות להגדיר פרופיל אישי:
· קובץ ini, או Setup אישי
· כניסה ישירה למסך השכיח
· עץ תפריטים ספציפי למשתמש (בהתאם להרשאות)
ג. שימוש במקשים מתוכנתים (soft keys).
ד. שימוש בסרגל קיצורי דרך לעבודה שוטפת של המשתמש.
א. חשוב להתאים את אמצעי הקלט לסוג העבודה של המשתמש כך שעיקר העבודה שלו תהיה באמצעות אותו כלי קלט (מקלדת או עכבר), או שיתוף בניהם אבל מינימאלי כך שהמשתמש יעבוד ברצף.
ב. יש לתת למשתמש אפשרות לבצע את מגוון הפעולות דרך לוח המקשים או דרך העכבר לפי רמת המיומנות שלו, כל אחד בנפרד ולא על חשבון השני.
ג. "עכבר"/כדור עקיבה - העכבר הוא אמצעי הקלט הנפוץ היום בסביבת חלונות.
ד. יש לשקול היטב בחירה ב"עכבר" כאמצעי קלט. אם התפעול כולו נעשה באמצעות ה"עכבר" והמקשים הצמודים אליו - זהו פתרון יעיל. אם חלק ניכר מהתפעול צריך להיעשות באמצעות מקשי המקלדת - הצורך לעבור באופן תכוף בין ה"עכבר" והמקלדת מייגע ומתסכל את המשתמש.
ה. כאשר הלקוח דורש שתפעול המערכת יהיה ע"י לוח מקשים או "עכבר" - יש להבטיח שהתצוגה תכלול את כל האלמנטים הנדרשים לתפעולה באמצעות העכבר. זאת - מבלי ליצור עומס ויזואלי המפריע לתפעול השוטף, או כל מצב אחר היוצר בלבול בין תפעול המקלדת ותפעול ה"עכבר".
לכדור העקיבה שלושה מקשי הפעלה:
א. המקש השמאלי משמש לשם:
· בחירת אובייקט לשם ביצוע מניפולציה עליו.
· ביצוע הפעלה (כגון: בחירה מתפריט)
ב. מקש אמצעי משמש לפעולות שהוגדרו מראש ללחיץ זה.
ג. המקש הימני משמש להצגת תפריט פעולות על גבי אובייקט שנבחר בהתאם להרשאות. דוגמא לפעילויות מסוג זה: (הרחב נתונים, הסר, העבר,UNDO וכו').
הגלגלת הקטנה מאפשרת דפדוף בטבלה או במפה ע"י סיבוב בגלגלת או קביעת קצב הדפדוף של המסך.
קיימים מספר רב של עכברים (בעלי 2 לחיצים, 3 לחיצים, 2 לחיצים וגלגלת, 3 לחיצים וגלגלת ועוד) שהגדרת הפונקציונאליות של כל אחד מהלחיצים נקבעת ע"י הגדרות העכבר.
הסעיף הזה מיועד רק לפרויקטים שכוללים פיתוחו של מקלדת מיוחדת.
א. מיקום המקשים במקלדת יהיה בהתאם לסדר הפעולות ושכיחותן.
ב. המקשים יקובצו בקטגוריות משמעותיות.
ג. יצירת סרגל ייחודי של מקשים ותיאור הפונקציה שמפעילה.
ד. הבלטה מתאימה למקשים חשובים ו/או שכיחים.
ה. הגנה מתאימה למקשים בעלי פעולה חמורה/בלתי הפיכה.
ו. רצוי שימוש בקוד צבע להקלת ההתמצאות במקלדת.
ז. כשנעשה שימוש במקלדת סטנדרטית רצוי לשמור ככל האפשר על שמות ומיקום של מקשים סטנדרטיים, כגון: PgUp, Esc, PgDn, Enter, Caps Lock ומקשי חצים.
ח. "מקשים חמים". אפשרות, למשתמש מנוסה, להגדיר לעצמו את מקשי הפקודות בהם הוא משתמש בתדירות.
ט. יצירת מספר אופציות להגיע לאותה הפעולה (מקש פונקציונאלי או צרוף מקשים).
נגישות מתייחסת למדת השימושיות של תוכנה על ידי אוכלוסיות מגוונות, במיוחד אוכלוסיות בעלי מוגבלויות. בארה"ב לבד יש יותר משלשים מליון אנשים בעלי מוגבלויות כלשהן (ובכלל העולם יש הרבה יותר מזה) שעבורן תיכנון תוכנה כנגישה, אמור להכריע אם תהיה שימושית עבורן או לא. בנוסף לכך בהרבה ארצות, כולל ישראל, יש חוקים שמחייבים רמה מינימלית של נגישות. ולכן הצורך להנגיש תוכנה נגזר לא רק מתוך חובה מוסרית כלפי האוכלוסיות בעלי מוגבלויות, אלא גם מתוך שיקולים כלכליים וחוקיים.
בטבלה למטה רשומים חמשה סוגים של מוגבלויות, השלכותיהן על שימוש במחשב, והצעות הנגשה כדי להפוך את התוכנה לנגישה לבעלי מוגבלויות אלו. (ראוי לציין שלכל סוג של מוגבלות קיימות רמות שונות של מוגבלות, ובלא מעט מקרים, אנשים סובלים מיותר מסוג אחד של מוגבלות.)
|
סוג המוגבלות |
ההשלכות השליליות על שימוש במחשב |
הצעות הנגשה |
|---|---|---|
|
ראיה |
הבחנה בניגוד צבעים קריאת המסך הפעלת מכשיר להצבעה כמו עכבר (דורשת תיאום עין-יד) |
שימוש בצבעים בעלי ניגוד גבוה יכולת הגדלת רכיבי המסך באמצעות חומרה או תוכנה תמורות טקסטואליות לכל רכיב זיזואלי במסך לצורך "תרגומם" באמצעות כלי לקריאת-מסך או לתצוגת ברייל הפעלה מלאה באמצעות מקלדת בלי צורך לעכבר |
|
שמיעה |
הפרעות מרעשי רקע שמיעה של פלט אודיאלי הפעלת מערכת הנשלטת ע"י קול |
יכולת הגברת הקול, אזניות תמורות טקסטואליות או גרפיות לכל פלט שמיעתי הפעלה מלאה באמצעות מקלדת או עכבר |
|
תנועה |
הפעלת מקלדת או עכבר זמני תגובה לפלטי המערכת |
שליטה בהגדרות של המקלדת והעכבר כולל זמני תגובה קלט המבוסס על קול, תזוזת הראש, כיוון העניים או מוט היגוי בפה |
|
קוגניטיבי או לשוני |
קושי בהבנת ציפיות המערכת מהמשתמש הבנת טקסטים |
שיטת ניווט עקבית, תצוגות פשוטות, סדר פעולות ברור ומרומז שימוש בשפה פשוטה או לחילופין בתמורות לא טקסטואליות |
|
רגישות להתקפה אפילפטית |
רענון מסך או הבהוב בקצבים מסוימים של צורות/אותיות במסך |
ביטולו או שליטת המשתמש ברענון המסך, הבהוב, וכו' |
להרחבה ראה אתר נגישות ישראל, של עמות נגישות ישראל ואתר נגיש שעיסוקו בהנגשת אתרי אינטרנט בישראל
יעילות העבודה במערכת מידע תלויה לא רק בטיב המערכת, אלא גם במידת ההתאמה של עמדת העבודה כולה לצרכיו של המשתמש. כדי להשיג עמדה המתוכננת נכון מבחינה ארגונומית יש להתחשב באינטראקציה בין גורמי התפקיד, הסביבה ועמדת העבודה.
מרכיבי עמדת העבודה כוללים את התצוגה, אמצעי הכנסת נתונים (לוח המקשים, "עכבר"), מדפסת, ניירת (טפסים, אמצעי עזר אחרים), כיסא ומדרך הרגליים. ביישומים מסוימים יתכנו גם אלמנטים תפעוליים אחרים שיש להתחשב בהם, כגון משקל אלקטרוני, קורא שיקים, מגירה שולחנית ועוד.
בתכנון עמדת העבודה הממוחשבת יש להתייחס לכל האלמנטים הללו כאל יחידה אינטראקטיבית אחת, ולתת להם מענה אופטימאלי מבחינת מיקומם במרחב העמדה.
שמירה על עקרונות אלה תבטיח תנוחת ישיבה יעילה ונוחה למשתמש, החשובה בעיקר למשכי עבודה ארוכים (מספר שעות).
תכנון ממדי העמדה ואביזריה צריך להתחשב במידות האנתרופומטריות (מידות גוף האדם) של המשתמש. ניתן להגדיר מידות אלה לפי נתונים סטטיסטיים ידועים. ההתאמה הספציפית לכל משתמש צריכה להיות אפשרית ע"י ניצול דרגות החופש של המושב, הדום הרגליים, התצוגה ולוח המקשים.
· תאורה - יש למנוע השתקפויות של גופי תאורה (מנורות, חלונות, משטחים בוהקים וכו') במסך. יש להבטיח רמת תאורה כללית בחדר של כ- 300 עד 500 lux. יש להימנע משימוש במשטחים בוהקים ומחזירי אור בעמדה עצמה.
· רעש - מקורות הרעש העיקריים בסביבת עמדות עבודה ממוחשבות הן המדפסות. בעדיפות ראשונה יש לבודד את המדפסות בחדר נפרד. אם יש הכרח למקם את המדפסת בקרבת עמדת העבודה - יש להכניסה לתוך מעטפת אקוסטית. רמת הרעש הכללית בסביבת עמדת העבודה לא תעלה על Db 55.
המשתמש הממוצע אינו יודע, בדרך כלל, להתאים את עמדת העבודה שלו לצרכיו האישיים. ברוב המקרים גם אינו מודע לאפשרות לעשות זאת. רצוי מאד לתת הדרכה אישית חד-פעמית לכל אחד מהמשתמשים בעמדתו.
שילוב היבטי הנדסת אנוש בפיתוח מערכת מידע מלווה את הפרויקט לאורך כל מחזור החיים. הנושא עשוי לבוא לידי ביטוי ממשי כבר בשלב הייזום, ולהמשיך ברמת אינטנסיביות משתנה בשלבים הבאים. אופי הפעילות וההדגשים משתנים בהתאם לשלב, כמתואר בסעיפים הבאים.
הקפדה על עקרונות הנדסת אנוש נכונים תשמר את ההשקעה בממשק אדם-מחשב לאורך זמן ובמעבר למהדורות וגרסאות חדשות של המערכת. תהפוכות טכנולוגיות יגרמו לשינוי ויזואלי, ולא לשינוי פונקציונאלי. (אבל מעבר מפלטפורמה אחת, כמו Windows, לפלטפורמה אחרת כמו ב-אינטרנטס, עלול להוביל גם לשינויים פונקציונליים.
בשלב זה נמצאת המערכת בתהליך של גיבוש תפיסתי, ופעילות הנדסת אנוש תתמקד בבחינה של כישורי המשתמשים הפוטנציאליים וניסיונם הקודם, והשלכות אפשריות של המערכת העתידית בתחומים אלה.
אוכלוסיית המשתמשים היא לרוב מגוונת. קיימת שונות ניכרת בהיבטים כגון ותק וניסיון בעבודה, רקע בתפעול מערכות מחשב, מוכנות לקליטת מערכת מחשב וכו'. לעתים הבדלים אלו מהווים את הקו המכתיב העיקרי לקביעת אופי הממשק למשתמש.
הנושאים העיקריים שיש לתת עליהם את הדעת הם:
· זיהוי קבוצות המשתמשים במערכת העתידית (כישוריהם, ניסיונם הקודם בתפעול מערכות דומות),
· זיהוי מערכות בסביבה הרלוונטית בעלות מאפייני תפעול הדומים למערכת המבוקשת,
· בדיקת רצון ונכונות ל"חדשנות ומהפכות",
· ביצוע תיאום ציפיות בין רצונות הלקוח וההנהלה על סמך התוצרים.
התוצרים הנדרשים הנם:
· הערכת דרישות ההכשרה שתציב המערכת העתידית למשתמשים,
· הגדרה פונקציונאלית אמיתית של המערכת.
חשוב שהממצאים בנושאים אלה יוצגו לא רק בפני הצוות המקצועי, אלא גם בפני הלקוח והצוות הניהולי (ועדת ההיגוי) של הפרויקט.
התוצר הסופי של פעילות הנדסת אנוש בשלב הייזום יהיה סעיף 2.4 במסמך הייזום (ממשק תפעולי).
במסגרת שלב האפיון הדגש העיקרי בפעילות הנדסת אנוש הוא על ניתוח המערכת מנקודת מבטם של המשתמשים, והגדרת המסקנות המתחייבות מכך על אופי הממשק אדם-מערכת.
פעילות חשובה עליה מתבסס חלק נכבד משיקולי תכנון ממשק המשתמש בהמשך, היא ניתוח התפקיד של המשתמש העתידי. ניתוח זה מהווה שלב אנליטי רצוי בכל תכנון הנדסת אנוש, ואם הוא נעשה בצורה מקצועית ויסודית - ניתן לגזור על בסיס ממצאיו מסקנות רבות לגבי מאפייני הממשק אדם-מערכת הנדרשים.
היעדר ניתוח תפקיד טוב בשלב האפיון עלול לגבות מחיר, בגלל שיפורים ושינויים שנחיצותם תתגלה בשלבים מאוחרים של מחזור החיים, או לחילופין - באי שביעות רצון מהמערכת
יש לזכור שניתוח התפקיד צריך לכלול את מבנה התפקיד הנוכחי (אם קיים), אך יש גם להעריך נכונה את השינויים הצפויים במבנה התפקיד בעקבות הכנסת המערכת העתידית, ומשמעויותיהם לגבי הממשק.
ניתוח התפקיד מתבצע על ידי הגדרה שיטתית של כל אחת מהמטלות ותת-המטלות הכלולות במסגרת התפקיד, ובחינת משמעויותיה מבחינת הממשק אדם-מערכת. ההתייחסויות העיקריות לכל מטלה תהיינה:
· ניתוח סדר הפעולות, משך כל פעולה וחשיבותה,
· ניתוח והגדרת האינפורמציה הנדרשת לביצוע כל מטלה,
· תהליכי קבלת ההחלטות הנדרשים בכל מטלה, ומורכבותם,
· הערכת רמת הקריטיות של ביצוע שגיאה תפעולית בכל מטלה,
· הגדרת חלוקת התפקידים בין המשתמש והמערכת (לדוגמא: באיתור שגיאות, בהנחיית תהליך ביצוע הפעולות וכו'),
· הגדרת עומסים צפויים, צווארי בקבוק ומצבי לחץ,
· דרישות ההיזון החוזר בכל מטלה,
· סיכונים צפויים ובעיות אפשריות,
· מגבלות אנושיות וטכניות.
ברור שרשימת הקריטריונים הנ"ל אינה רלוונטית במלואה לכל מערכת מידע. לפיכך תפקידו של מומחה להנדסת אנוש להבחין בין העיקר והטפל בהקשר למערכת הספציפית.
האינפורמציה שתיאסף בשלב ניתוח התפקיד תעובד לפי קריטריונים ידועים של הנדסת אנוש, ומסקנותיה יוצגו ע"י מומחה להנדסת אנוש בפני צוות ההיגוי של הפרויקט לקבלת היזון חוזר.
התוצר הסופי של פעילות הנדסת אנוש בשלב האפיון הם שני רכיבים במסמך האפיון: 2.4 - ממשק משתמש ו- 4.7 - השתלבות בארגון, אשר מכילים את התכנים הבאים:
· 2.4.0 הגדרת עקרונות וכללי הנדסת אנוש הנדרשים במערכת.
· 2.4.1-2.4.2 הגדרה של מבנה מסכים נדרש ושיטת התפעול המומלצת. הגדרה זו צריכה להביא לידי ביטוי את הכללים שנקבעו ב- 2.4.0.
· 4.7.4 הגדרת עקרונות למדריך למשתמש, מבנהו ודגשים מיוחדים למערכת הספציפית.
לחלק מהתוצרים של שלב זה עשויה להיות רלוונטיות רבה גם לרכיבים אחרים של עץ המערכת. השתמש בהם!
כשלב מקדים לפעילות העיקרית כאן, יש לוודא שהמפרט כולל את כל היבטי הנדסת אנוש הרלוונטיים שהוגדרו בשלב האפיון. כמו כן יש לבחון את המשקל שניתן להנדסת אנוש בשקלול הצעות הספקים, במפ"ל. במקרים מסוימים יש לשקול גם ציון דרישות סף.
במסגרת שלב הבקשה להצעות תתמקד פעילות הנדסת אנוש בהערכת המידה בה עונות הצעות הספקים על דרישות הנדסת אנוש, כפי שהוגדרו במפרט (שהוא למעשה מסמך האפיון).
מומלץ שתהליך ההערכה יעשה בשני אופנים עיקריים:
· בחינת אנליטית של הפרקים הרלוונטיים במסמכי ההצעות, כנגד דרישות הנדסת אנוש במסמך האפיון.
· בחינה אמפירית של היבטי הנדסת אנוש באבות-טיפוס של המערכת המוצעת (במידה וישנם), ע"י תכנון סימולציות, עריכתן וניתוח ממצאיהן. במידת האפשר רצוי שהסימולציות יבוצעו ע"י המשתמשים העתידיים.
התוצר הסופי של פעילות הנדסת אנוש בשלב הבקשה להצעות יהיה סעיף 2.4 במסגרת מסמך סיכום הבדיקה הכללי (המפ"ל הממולא, ראה קיט בקשה להצעותRFP - בכרך יסודות/מחזור חיים), שיכלול את ההיבטים הבאים:
· הצגה השוואתית של היתרונות והחסרונות של כל הצעה מבחינת הקריטריונים של הנדסת אנוש שהוגדרו במפרט, והמלצה על ההצעה המועדפת (אחת או יותר).
· ליקויי הנדסת אנוש עיקריים בהצעות הנבחרות, המלצות לכיווני פתרון מוצעים, ומשמעויותיהן בעלות כספית ובזמן פיתוח.
למרות מרכזיות רכיב 2.4 בהערכת הנדסת אנוש בהצעות השונות, יש לזכור שהנדסת אנוש באה לידי ביטוי בעקיפין גם ברכיבי יישום רבים אחרים וגם ברכיבי טכנולוגיה ומימוש כגון: 3.13 – כלי פיתוח ותחזוקה, 4.7 – השתלבות בארגון ועוד.
פעילות הנדסת אנוש בשלב העיצוב והבניה תתמקד בתיכון המפורט של ממשק אדם-מערכת, בתחומים הבאים:
· עץ התפעול הכללי של המערכת, ניווט והתמצאות כלליים,
· שיטת התפעול של המערכת בכללותה, ובכל אחת מהפונקציות בפרט,
· מסכי המערכת,
· אמצעי הקלט (מקלדת, עכבר וכו'),
· מבנה הפלט והקלט של המערכת (טפסים, דו"חות וכו'),
· כתיבת המדריך למשתמש.
תיכון הנדסת אנוש של ממשק אדם-מערכת ייעשה במסגרת כלי הפיתוח שנבחרו, ויהיה מתואם עם תהליכי התכנון והפיתוח של קבוצות העבודה האחרות בפרויקט. לפיכך חשובה מאד אינטראקציה שוטפת בין המומחה להנדסת אנוש ובין אנשי התוכנה והחומרה בפרויקט. אינטראקציה זו חשובה משתי סיבות עיקריות:
· תיאום לוחות הזמנים בין פעילות הנדסת אנוש ובין פעילויות הפיתוח האחרות,
· הצגת תוצרי התיכון של הנדסת אנוש בפני קבוצות הפיתוח האחרות, במועדים שיקבעו מראש ובכל עת שיידרש, לקבלת היזון חוזר לגבי התאמת תכנון הנדסת אנוש לתכונות ומגבלות המערכת.
תוצרי התיכון בשלב זה יוצגו במספר אופנים (בהתאם לצורך):
· תדפיסי נייר מפורטים של מסכים,
· מסכים ושיטת תפעול המוצגים באמצעות תוכנת Demo כלשהי או באמצעות אבטיפוס,
· מסמכים המגדירים בפירוט את מבנה המסכים, שיטת התפעול, אמצעי הקלט (לוח מקשים, עכבר וכו'), המדריך למשתמש.
תיכון הממשק אדם-מחשב בשלב העיצוב ובניה יסתמך על העקרונות המפורטים בסעיף עקרונות לתכנון ממשק אדם-מחשב שלהלן. כל תוספת ממקור רלוונטי אחר בתחום הנדסת אנוש תבורך.
בחינת חלקי המערכת השונים והמערכת בכללותה, ובדיקתם מההיבט של הנדסת אנוש, צריכים להתנהל בצורה מסודרת ומבוקרת.
התוצר הסופי של פעילות הנדסת אנוש בשלב המבדקים יהיה סעיף הנדסת אנוש בתיק הבדיקות (2.4.0 - ממשק המשתמש), שיכלול התייחסות לתכנים הנ"ל.
יש לגבש קריטריונים באופן ספציפי לכל מערכת מידע, בהתאם לדגשים החשובים למערכת. הקריטריונים לבדיקה יהיו בתחומים הבאים:
· דיוק ומהירות התפעול בפונקציות השונות,
· שגיאות שכיחות (שגיאות שסיבתן טעות אנוש, טעות מערכת),
· זמני תגובה של המערכת בפונקציות השונות,
· פעולות בלתי הפיכות הגורמות לאובדן נתונים, נפילת המערכת,
· איתור ירידה בביצועי המשתמש כתוצאה מעייפות ומצבי לחץ,
· התאמת המדריך למשתמש למערכת, קלות השימוש בו מבחינת המשתמש, עמידתו בקריטריונים המפורטים בסעיף 4.7.4: מדריך למשתמש בקיט עץ מערכת אוניברסלי בכרך יסודות,
· שביעות רצון המשתמשים,
· משך הזמן הדרוש ללימוד המערכת.
לכל קריטריון יוגדר מדד כמותי שניתן להשיגו בהשקעת זמן ומשאבים סבירה, וברמת דיוק סבירה.
פעילות הנדסת אנוש בשלב המבדקים תתמקד בביצוע המטלות הבאות:
· תכנון, ליווי ועיבוד ממצאי סימולציות, שיבוצעו באמצעות המשתמשים הפוטנציאליים של המערכת,
· תחקור המשתמשים (לאחר הסימולציות),
· הגדרת בעיות הנדסת אנוש והמלצות לשיפורים.
בדומה להבחנה הכללית בין סוגי התחזוקה השונים: תיקון שגיאות, שינויים כפויים ושו"ש (שינויים ושיפורים) - ראה קיט תפעול ותחזוקה - גם בתחזוקה של ממשק המשתמש ורכיבי הנדסת אנוש אחרים חשוב להבחין בין:
· תקלות או ליקויים הגורמים לבעיות משמעותיות בשימוש במערכת ובפרט כאלה שקל יחסית לתקנם),
· ביקורת שוטפת של שינויים הכרחיים ובין שיפורים ותוספות שמשמעותם מהדורה או גרסה חדשה.
חשוב במיוחד להבחין בין שינויי הנדסת אנוש שבאים מצד הלקוח (צד הביקוש) לבין שינויים הבאים מצד הספק וה"שוק" (צד ההיצע) שבאופן מתמיד דוחפים לטכנולוגיות חדשות.
יש לבחון היטב גם שינויים ברכיבים אחרים (טרנזקציות, משתמשים, קבצים וכו') מנקודת המבט של הנדסת אנוש, ולוודא את עמידתם בקריטריונים הכלליים של הנדסת אנוש במערכת.
אחד הקריטריונים החשובים ביותר בהיבט זה הוא שמירה על אחידות תפעולית של כל שינוי או תוספת, עם כללי התפעול והמסכים של המערכת הכוללת.
תחקור שלבי מחזור החיים במערכת בכללותה, ובדיקתם מההיבט של הנדסת אנוש, צריכים להתנהל בצורה מסודרת.
התוצר הסופי של פעילות הנדסת אנוש בשלב התחקור והערכת המערכת תוך שימוש בקיט כולל התייחסות לתכנים הנ"ל.
יש לבדוק התאמת הדרישות ומימושם בפרויקט:
· עמידה ביעדי הפרויקט בהיבטי הנדסת אנוש
· שביעות רצון המשתמשים
· משך הזמן הדרוש ללימוד המערכת.
· התאמת המדריך למשתמש למערכת, קלות השימוש בו מבחינת המשתמש, עמידתו בקריטריונים המפורטים בסעיף 4.7.4.
פעילות הנדסת אנוש בשלב התחקור ופעולת הערכה תתמקד בביצוע המטלות הבאות:
· תחקור המשתמשים במערכת
· הגדרת בעיות הנדסת אנוש והמלצות לשיפורים.
שיקולי הנדסת אנוש מלווים את פיתוח המערכת לכל אורך מחזור החיים. שיקולים אלה יבואו לידי ביטוי ברכיבים הבאים בעץ המערכת:
· התאמה תפקודית
· פישוט תהליכי התגברות על שגיאות
· הגנה מפני פעולות חמורות
· התמצאות במערכת
· פשטות תפעול (כך שתתאים לכל סוגי המשתמשים) ואימון והמחשה מקוון
· פישוט תהליכי התגברות על שגיאות
· הגנה מפני פעולות חמורות
· התאמה תפקודית
· עקרונות ארגונומיה
· תפעול תפריטים פשוט ויעיל
· תכנון ותפעול חלונות
· אחידות ועקביות בהגדרות, דגשים למסכי הזנה
· זמני תגובה
· עקרונות ארגונומיה
· פשטות תפעול (כך שתתאים לכל סוגי המשתמשים) ואימון והמחשה מקוון
· אחידות ועקביות בהגדרות, דגשים למסכי הזנה
· פשטות תפעול (כך שתתאים לכל סוגי המשתמשים) ותמיכה באימון והמחשה
· תפעול תפריטים פשוט ויעיל