יום: 20 בפברואר 2005

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

למרבה השמחה, את השלב הזה הצלחתי לעבור.

עכשיו כל מה שנשאר זה עבודה קשה. עם זה אני אדע להסתדר….

שחר

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

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

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

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

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

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

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

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

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

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

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

שחר