השוואת ממשקים – גרפי לעומת טקסטואלי

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

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

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

עדיין, לפעמים אין ברירה. לפעמים צריך לאפשר ביצוע של התאמות אישיות ברמה מאוד גבוהה, או שהמוצר לא מפיק את הפוטנציאל שלו. במצב כזה, נהוגים כמה פתרונות. אף אחד מהם לא טוב.
2. לשים את כל האפשרויות במסך אחד עצום. המשתמש מקבל מסף מלא מלא אופציות, כתובות צפוף, וללא יכולת להבין מה חשוב ומה לא.
3. לדרג את האופציות, תוך שימוש בתפריטים ותפריטי עזר. זוהי האופציה שבה בחרו מיקרוסופט בשביל Office. זוהי אפשרות שמגדילה באופן משמעותי את האיזון בין הצורך לתת גישה לאפשרויות לבין הצורך לא להעיק יותר מידי על המשתמש. הבעיה היא שאז למשתמש מאוד קשה לזכור איפה ומה הוא מוצא. אתה זוכר שיש אפשרות ב-Word לייצר תבניות של מסמכים עם שמות שונים להדפסה, אבל איפה לעזאזל האפשרות הזו היתה? בחלונות וב-Office ניסו להקטין את הבעיה על ידי זה שאופציות לא מופיעות עד שלא השתמשתם בהן פעם אחת (Personalized menus). באופן אישי, אני מרגיש שזה מוסיף לבילבול מכך שיש הרבה אופציות את זה שהתפריטים לעולם אל נראים אותו הדבר פעמיים.
4. לשים בתפריטים הגרפיים רק את הדברים העיקריים, ואז לשים במקום משני, לא גרפי, את שאר האופציות. על חלונות המקום המשני מכונה “Registry”. מצד אחד, הבילבול למשתמש הפשוט הינו מינימלי. מצד שני, אין שום דרך לדעת אילו אופציות נוספות יש, או מה המשמעות שלהן.

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

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

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

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

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

שני אגבים:
א. בלינוקס יש איזון יפיפה בין השניים. כל השירותים של המערכת מנוהלים על ידי קבצי תצורה מילוליים, אבל קיימים כלים גרפיים שמנהלים אותם. כך אתם יכולים לבחור באיזה עולם אתם מעדיפים לחיות. למעשה, אני למדתי להפעיל את GDB (שהוא debugger שורת פקודה) על ידי זה שהשתמשתי במעטפות גרפיות שלו (בעיקר DDD), וראיתי אילו פקודות הוא מוציא כשאני לוחץ על הכפתור המתאים.
ב. אפילו מיקרוסופט הבינו שלא ניתן (או לא הגיוני) לעשות דברים מסויימים בצורה גרפית. הם הכניסו את Windows Scripting Host, שהם לא פחות מאשר קבצי shell script לעשות את הפעולות שניתן היה, בעיקרון, לעשות רק בצורה גרפית בחלונות. כמובן שמכיון שהכלים האילו אינם בשימוש יומיומי, הם לא באותה רמת הגימור והליטוש כמו מקבילהם בעולם היוניקס.

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

שחר

מאת

שחר שמש

מייסד–שותף וחבר ועד בתנועה לזכויות דיגיטליות מייסד שותף בעמותת „המקור”. פעיל קוד פתוח. מפתח שפת התכנות Practical

8 תגובות בנושא “השוואת ממשקים – גרפי לעומת טקסטואלי”

  1. זה מזכיר לי משהו שחשבתי שצריך להוסיף לכל היישומים הגרפיים.

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

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

    1. זה בסדר, ואף מצויין, לאותם מיקרים שבהם באמת מדובר במעטפת גרפית לכלי command line. מה תעשה, אבל, במקרים שבהם הכלים הטקסטואלים הם רק תת-קבוצה של מה שהמערכת הגרפית יכולה לעשות?

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

      בגדול, אבל, אני מסכים איתך לחלוטין.

      שחר

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

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

    אריק

  3. בתור אחד שבמשך שנים עבד רק על מערכות הפעלה גרפיות (עשיתי הפסקה ארוכה בין Apple Dos לחלונות 3.11), והסתכל על אנשי שורת הפקודה כעל תמהונים, לפני שנתיים בערך נאלצתי לעבוד קצת על vi ונדהמתי מהאפקטיביות של הדבר הזה. לוקח קצת זמן להתרגל, אבל אחרי שמתרגלים לזה – אין דבר יותר טוב ממנו.

    לא לגמרי קשור, אני יודע – אבל גם לא ממש לא.

  4. אולי צריך לדבר על "משהו באמצע"; למשל vi, שהוזכר בתגובה לפני כממשק טקסטואלי, הוא לא בדיוק CLI (ה-CLI המקביל הוא sed).

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

כתיבת תגובה

האימייל לא יוצג באתר. שדות החובה מסומנים *

Bear