התחלתי מלכתוב רעיון כללי לפוסט אותו תכננתי להציע לכל דורש כי לא חשבתי שאספיק להרחיב אותו, אבל מסתבר שדברים כאלה מתרחבים מאליהם. בעקבות Ubiquity של אזא רסקין שממשיך את מורשתו של אביו עם Archy, ממשקים טקסטואליים חוזרים (שוב) למרכז העניינים, ואלו כמה דעות ראשוניות מאוד שלי בנושא.
המבוא הנדרש (שממילא כתבתי כהקדמה לנושא עבור הגיקים, אז אני בעצם מצטט כאן את עצמי):
מוזילה שחררו גרסה ראשונה של התוסף Ubiquity שפותח בראשות אזא רסקין, ממשק טקסטואלי לרשת שהוא שכלול קיצוני למדי של רעיונות מהטרמינל בלינוקס ובסביבות דומות, YubNub, ה-AwesomeBar, וכמובן פרוייקט Archy של ג'ף רסקין, אביו של אזא. Ubiquity מבין פקודות כמו map או email או add-to-calendar, הוא יודע לקחת קלט מעמודים ברשת, משירותים מקוונים או ישירות מהמשתמש, והוא יכול לעשות מהכל סלט מאוד שימושי שחוסך הרבה לחיצות ונסיעות עם העכבר. אם ניסיתם כלים דומים סביר להניח שהתמכרתם כבר ממילא, ואם לא אז אין ממש דרך קלה להסביר את זה בפסקה אחת של טקסט. צפו בסרטון ההדגמה או פשוט הורידו גרסת אלפא של התוסף ונסו אותו בעצמכם.
רק לשם הבהרה, אני מעריץ גדול של העבודה של משפחת רסקין, ובהקשרים רבים אני נוטה באופן מובהק לטובת ממשקים טקסטואליים שמאפשרים לי להמנע ככל האפשר משימוש בעכבר. בפוסט הזה התייחסתי לכמה מהבעיות בגישה הזו, שלצערי רוב הפרוייקטים שנוקטים בה לא מתאמצים מספיק לפתור.
Ubiquity דומה לטרמינל שמשתמשי לינוקס אוהבים כל כך או ל-QuickSilver שמשתמשי מק אוהבים כל כך. ההשוואה לממשק הפקודה הטקסטואלי של הטרמינל אולי קצת מוגזמת בהתחשב בפשטות של Ubiquity, אבל העקרון הבסיסי זהה, ושניהם משרים אותה תחושת חוסר ביטחון שנובעת מהעדר ביטוי ויזואלי לממשק.
בממשק ויזואלי, כל האלמנטים והפקודות גלויים והממשק מתעד ומסביר את עצמו. התפיסה של המשתמש כאילו הממשק מגלם ומכיל את המערכת כולה משרה תחושת ביטחון מיידית שנחוצה כדי לדרבן את המשתמש לחקור את הכלי ולהתנסות בו.
עקרונות השימוש פשוטים מאוד ולעיתים קרובות אף מובנים מאליהם, ובמקרים רבים אין צורך בהדרכה או תהליך הסתגלות. עקומת הלמידה נמוכה עד אפסית.
הממשק מתגמל משתמשים חדשים, אבל כתוצאה מכך לעיתים קרובות מעניש משתמשים מנוסים. קל ללמוד לבצע משימות חדשות על סוגי אובייקטים קיימים, אבל קשה יותר או בלתי אפשרי ללמוד לבצע אותן מהר יותר או באופן אוטומטי, או להוסיף סוגי אובייקטים חדשים.
דוגמה קלה היא ניהול קבצים באמצעות סייר הקבצים של חלונות או ה-Finder של המק. רשימת הקבצים והתיקיות מוצגת תמיד על המסך בצורה מובנה ומובנת, ורשימת הפעולות מסודרת בתפריטים עם שמות תיאוריים. בחירת אלמנטים ובחירת פעולות מצריכות רק ידע מוקדם בסיסי, וידע זה ממשיך לשרת את המשתמש כמעט בכל ממשק ויזואלי אחר. כל פעולה גוררת תגובה מיידית והתוצאה שלה מופיעה בבירור על המסך. שום דבר לא הולך לאיבוד.
לעומת זאת, ביצוע פעולות מתקדמות או מורכבות על קבצים ותיקיות היא כמעט תמיד משימה מייגעת (עד כדי כך שהן בדרך כלל פשוט לא מתבצעות), ומגבלות טכניות טריוויאליות כמו שטח הנדל"ן הפנוי על המסך מכתיבות את מגוון הפקודות או הפעולות המוכנות מראש הזמינות.
בממשק טקסטואלי, כל הפקודות חבויות ואם קיים תיעוד, הוא מופיע בדרך כלל רק בדיעבד או לפי דרישה, ולעיתים נדירות מאוד תוך כדי שימוש. התפיסה כאילו המערכת כולה *מסתתרת* מהמשתמש מאחורי פקודות שהוא לא מכיר משרה תחושת *חוסר ביטחון* ורתיעה מיידיות, ומקשה על המשתמש בעת חקירת הכלי והתנסות בו.
כל האובייקטים מומצאים ומופשטים, ואין שום עוגן בו אפשר להאחז כדי להבין את התהליך. המשתמש נדרש להחזיק בראשו מודל מורכב שכולל את כל האובייקטים ואת כל הפעולות, ולנתח אותו מחדש לפני כל משימה חדשה. עקומת הלמידה מתחילה בזווית של כמעט 90 מעלות.
הממשק מעניש ומרתיע משתמשים חדשים, אבל מתגמל משתמשים מנוסים. קשה מאוד ללמוד לבצע משימות חדשות, אבל אחרי טיפוס ארוך על עקומת הלמידה התלולה, אפשר לגלות דרכים יעילות יותר או לעיתים אוטומטיות לגמרי לבצע את אותן משימות, ואפשר להעשיר את המערכת בפעולות וסוגי אובייקטים חדשים.
דוגמה קלה היא ניהול קבצים באמצעות פקודות טקסטואליות בממשק הפקודה שכל מערכות ההפעלה הנפוצות מציעות. רשימת הקבצים והתיקיות חבויה עד שהמשתמש מבקש לראות אותה, וכך גם רשימת הפקודות, ושתי אלו נעלמות מהמסך ברגע שמבצעים פעולה אחרת. בחירת אלמנטים ובחירת פעולות מצריכה ידע מוקדם ניכר, וידע זה לא בהכרח משרת את המשתמש בביצוע משימות אחרות בממשק הטקסטואלי. הרעיון של "דברים הולכים לאיבוד" אפילו לא בא לידי ביטוי מכיוון ששום דבר לא ממש "נמצא" מלכתחילה, והתוצאה של פעולות בדרך כלל לא מוצגת בצורה ברורה על המסך.
לעומת זאת, המודולריות והגמישות של הפקודות השונות הזמינות למשתמש בממשק טקסטואלי מאפשרות לבצע משימות מורכבות מאוד במהירות, תוך מעורבות ידנית מינימלית או באופן אוטומטי לגמרי, ואין שום מגבלה מעשית על מגוון הפקודות או הפעולות המוכנות מראש שאפשר להציע למשתמש.
ההתבססות על שפה טבעית, הן עבור אוצר המילים והן עבור התחביר, נראית מרשימה מאוד בעת ההדגמה, אבל רק בגלל שהמדגים כבר מכיר את השפה אותה הכלי דובר. באנגלית יש אינספור אפשרויות לתיאור כל פעולה, בעוד שממשק טקסטואלי שמבוסס על גרסה מלאכותית של אנגלית מכיר רק אוצר מילים מוגבל ומבנים תחביריים שרירותיים.
מלבד זאת, מגוון הפעולות שכלי מסוגל לבצע לא קשור למודלים קיימים בעולם האמיתי, ואף שפה לא יכולה לסייע בהבנה אינטואיטיבית של היקף הכלי ויכולותיו. בממשק טקסטואלי, טבעי ככל שיהיה, כל הפקודות חבויות וכל סוגי האלמנטים לא ידועים, ושמות הפקודות בדרך כלל לא מסבירים את עצמם, או לא מסבירים את עצמם מספיק.
ואם כבר מתעכבים על Ubiquity עצמה, יש פגם קטן אך מעצבן במודל השימוש שלה. למרות שהיא מתבססת באופן בלעדי על המקלדת, כדי לבחור קטע מהעמוד ולבצע עליו פעולה צריך להתחיל מלסמן אותו עם העכבר ואחרי זה להקליד את הפקודה במקלדת, והמעבר הזה מסרבל מאוד את התהליך.
Ubiquity, וכלים אחרים כמו QuickSilver במק או HotWire בלינוקס, משלבים אלמנטים שונים של ממשקים ויזואליים כדי להקל במידה מסוימת על עקומת הלימוד החדה האופיינית לממשקים טקסטואליים ועל תחושת הניתוק מהתהליך. בין היתר, אפשר להציע השלמה אוטומטית של שמות פקודות ואובייקטים, להמליץ על פקודות או אובייקטים על בסיס תהליך למידה של הרגלי שימוש, לשלב דימויים חזותיים כמו אייקונים או תצוגה מקדימה, ועוד.
Quicksilver עושה את זה בצורה האלגנטית והשימושית ביותר, וזה לדעתי אחד הפיתוחים המעשיים המעניינים ביותר בתחום הזה ובכלל מזה הרבה זמן. למרבה הצער הפרוייקט דעך בשנה האחרונה, ולמרות מאמצים מצד פרוייקטים כמו Launchy בחלונות או Deskbar בלינוקס, Quicksilver זה עדיין תענוג ששמור למשתמשי מק בלבד.
אבל בסופו של דבר, למרות כל המאמצים בכיוון הנכון, הסמן המהבהב של שורת הפקודה יכול להיות מאיים עבור המשתמש בדיוק כמו עמוד לבן וריק עבור כתב.
(השתמשתי בפוסט בהגדרה "שפה טבעית" בצורה חופשית מאוד. לפי מיטב הבנתי, השפה של Ubiquity למשל לא עונה על הדרישות של שפה טבעית.)
תודה על האבחנה המעניינת.
ובכל זאת, שתי שאלות:
1. האם עיקר הבעיה שאתה מציג בעניין השפה הסגורה לא תיפטר בזה שמוזילה בונה את כל מודל בניית השפה על "שבט הפיתוח" (Herd) שיגדל מסביב לתוסף? בתחזית אופטמיאלית, הרבה מילות פקודה בשפה ברורה ומילות חיבור יאפשרו לעבוד בשפה טבעית. אחרי התנסות של שלוש שעות שהסתיימה כרגע אני חושב שפקודה כמו זו כבר לא כל כך בשמים:
Translate this page to french, export it to PDF, mail it to Ranh with cc to HanitC plus this note: "Hi ran, call me about this thing". remind me at 20:00 tomorrow to find out if he replied.
ואפילו פקודת, כמו: buy and send Flowers to my .wife או Order 4 seat at Tike(herzelia) for Monday evening
יצליחו אם התוסף יתפוס תאוצה ואתרים כלכליים יפיצו את אוצר המילים הנדרש לעניין.
שוב, יש סיכוי שאתה מאוד צודק, אבל יש לי תחושה טובה לגבי העניין הזה.
היה לי גם 2… ברח לי
נהנתי לקרוא. ונהנתי להשתמש ב- Ubiquity!
Ubiquity כן נותן לך אפשרות למיזוג בין ממשק חזותי לממשק מללי(טקסטואלי) בכלי המפה לדוגמה.
בסופו של דבר שורת הפקודה היא רק הקישור בין הכלי, מה זאתה צריך אתה מכיר. ואם לא יש ממשק מאוד חזותי שמציג לך את כל הפקודות.
ונשאלת השאלה אם צריך לממש את כל הפקודות מחדש בשפות אחרות (במיוחד שפות RTL הבעיתיות מהנודניקים הלבנטינים שם באסיה). האם סיני צריך ללמוד את הפקודות באנגלית או שיוביקוויטי צריכה לבוא אליו?
אל תבין אותי לא נכון, אני חושב שזה תוסף מצוין, כי אני בא מעולם שורות פקודה ואוהב את הכח שזה נותן, אבל זה ישאר תוסף ולא המנשק הראשי. ככל שמנשקים עוברים יותר למגע אישי למשתמש (כמו מסכי מולטיטאץ' וניחושים על מטרת הפעולה לפי התחלת הפעילות), שות הפקודה תעלם לה מהשימוש היומיומי (לממרות שתשאר כרגע בתחום המקצועי), והפונקציונליות של יוביקוויטי תופיע במנשקים של דיבור בטווח של השנים הקרובות יותר ויותר. בינתיים זה מתעכב לא בגלל שהטכנולוגיה של ניתוח דיבור לא כאן, אלא בגלל שהיא עוד לא יצאה מעולם הפטנטים והסודות המסחריים לעולם התוכנה החופשית. אני מאמין שבסוף גם זה יגיע איכשהוא.
העצוב הוא שאין כאן מהפכות תפיסתיות. מה שיוביקוויטי עושה עם תוכן של עמודי טקסט (או הסרטון של רסקין על שימוש מוסכל בפתיחה של טאב ריק חדש), זה לא קפיצה משמעותית ממה שעשה האפל ניוטון זצ"ל בהתחלת שנות התשעים. להזכיר לקוראים – זה היה PDA חביב שהופעל עם כתב יד (ולא הגראפיטי של פאלם שבא מאוחר יותר), וכבר אז עשה ניתוחי טקסט חכמים (לפחות בדמו) כמו כשהיוזר כותב "ארוחת צהריים עם יוסי בהרצליה", לנחש לבד שזו פגישה, לקבוע אותה ביומן עם זמן הצילצול-מראש שאתה מעדיף לארוחות צהריים, וגם להזכיר לך 24 שעות מראש להרים טלפון להזמין מקום במסעדה החביבה עליך בהרצליה (ואני מניח שעם פרוץ האינטרנט הוא גם היה עושה את זה אלקטרונית בלי להטריח אותך)
בסוף זה יקרה. בסוף יהיה גוגל מפות לישראל (אני מנסה בימים אלו לברר מה מעכב את זה), וכבר היום יש מסעדות שמאפשרות לך להזמין מקום דרך הרשת, כולל בחירת שולחן כמו בחירת כסאות בקולנוע. השלב הבא הוא איחוד הAPI של כל המסעדות האלו כדי להגיד בקולך לPDA שלך להזמין לך את "השולחן הרגיל שלי" במסעדה מסוימת ולקבל אישור קולי בזמן נהיגה.
כל זה מגניב אבל כאמור הוא רק הרחבות של מה שקיים היום, הוא עדיין לא מהפכני, אלא רק אבולוציוני.
אני קצת בשוק מהתוסף הזה, כי מייד התחלתי לדמיין איך הוא יעבוד בשילוב ממשק קולי. הפוטנציאל הוא עצום.
רו"ש- זה היה 2 שלי! :)
ממשקים קוליים כבר ממילא עובדים כך – התהליך הוא הפוך לדעתי, זו טקסטואליזציה של ממשק קולי ואין צורך לעשות קוליזציה לממשק הטקסטואלי הזה
מה שיש פה ואין בממשקים קוליים זה יכולות המאש-אפ. לי זה נראה כמו הוספה של פונקציונליות טבעית שפשוט לא היתה קיימת עד היום. בשילוב עם ממשק קולי, אתה מקבל את המחשב של האנטרפרייז.
רו"ש ורי"ה, איך הצלחתם לבלבל בין המנשק (קולי או מוקלד) לבין הפונקציונאליות של המאש-אפ? :-) נא לא לעשות סלט רבותי.
לגבי האנטרפרייז – כאן עוד לא מדובר בAI כזה מתוחכם. מדובר בכלי התחלתי למאש-אפים של כל הבאזוורדים החביבים ממשפחת ה"מיקרופורמטים", ומה שכל המומחויים מוכרים לנו כבר שנה וחצי על רשת סמנטית ו"וב 3.0" (למה אין 2.1 לפני? לא ברור לי למה שומרים אם ככה את הנקודה-אפס)
שוב אני אומר, אין כאן רבולוציה, יש כאן אבולוציה פשוטה למדי, שנדרשת כבר מזמן אבל לאף גוף מסחרי אין את האינטרס לממש אותה, ולכן טוב שיש תוכנה חופשית וקרן מוזילה. אני בטוח שגוגל יצאו בסוף עם פתרון GUI לפונקציונליות דומה, כבר קיימים כל מיני נסיונות דומים בתחום כמו תוסף בלואורגנייזר ובטח אחרים, כאן פשוט מדובר בגמישות של שורת פקודה, מה שמאפשר לקפל יותר פונקציונליות, אבל בינתיים לא פונקציונליות מהפכנית ושונה מהכיוון הכללי של השוק, נגיד עוד שנה-שנתיים (שלוש שנים אם מדובר במיקרוסופט).
עוד שתי גרסאות, ואנשים יתחילו לזרוק פנימה פקודות נוספות ומקוריות, יתחיל להיות שמח…
ושלא תבינו אותי לא נכון, אני מאוד מרוצה מהתוסף הזה, הוא גורם לי כאבי לחיים מרוב חיוכים, ובכל זאת, עד שיוכח אחרת, אני לוקח אותו בפרופורציות :)
דווקא לא בלבלנו כלום – בין אם מדובר בהפעלה קולית או בהקלדה על מקלדת, הממשק הוא אותו ממשק. ההבדל היחיד הוא באמצעי הקלט.
כשמנסים לתפעל ממשק ויזואלי באמצעות קלט קולי, התוצאה היא באופן בלתי נמנע ממשק טקסטואלי.
רק לשם תזכורת, אזא רסקין אכן מימש את העיקרון הזה בגוף מסחרי – החברה Humanized אותה הקים אחרי מות אביו כדי להמשיך את העבודה שלו יצרה את Enso. כרגע הוא מופץ בחינם.
http://humanized.com/enso/
אמצעי קלט הוא חלק אינטגרלי מהמנשק (או ממשק, איך שתרצו). אחרת שורת פקודה, פקודה קולית ותנועת עכבר הם "אותו מנשק" כי אתה עדיין עורך קובץ במעבד תמלילים בסוף.
לא, זה לא ויכוח על קטנוניות סמנטית. "כשמנסים לתפעל ממשק ויזואלי באמצעות קלט קולי, התוצאה היא באופן בלתי נמנע ממשק טקסטואלי" – מה?! כשאתה מנסה להפעיל את חלונות XP בעזרת מיקרופון התוצאה היא שורת פקודה מוקלדת? באיזה ספירה המשפט הזה עושה הגיון? אני חושב שאתה מערבב "מנשק קולי" עם "שפה אנושית" או משהו.
שורת פקודה לרוב באה עם מבנה וסינטאקס, המנשק כאן גם משלים לך ניחושים למה התכוונת תוך כדי הקלדה.
לעומתו מנשק קולי לא משלים לך אלא דוגם את כל המשפט שאתה אומר ואז מנתח אותו סינטאקטית. הוא צריך להבין ניסוחים שונים בשפה אנושית ולאו דווקא את הניסוח ה"קשיח" של הפקודות שיוביקוויטי מקבל כיום. בהחלט מנשק שונה (ולא רק בגלל טכנולוגית אמצעי הקלט, למרות שזה חלק מהמנשק, כמו שאמרתי)
אנזו נראה מעניין, מעין חיבור של יוביקוויטי ולונצ'י. יש לזה שוק שמצדיק הקמת חברה? מסופקני…
פינגבאק: גם-שם » שובו של הממשק הטקסטואלי
לא נראה לי שאנחנו מדברים על אותו סוג של תפעול קולי – אני לא מכיר משהו שיבין ניסוחים שונים בשפה האנושית או יבצע ניתוח תחבירי. התוצאה היא אכן שורת פקודה, פשוט לא מוקלדת אלא מוקראת. בכל ספירה, פקודה היא פקודה – זה לא משנה אם אתה מקריא למחשב פקודות או מקליד לו אותן.
עם זאת, אין ספק שקלט קולי הוא צורה ידידותית וטבעית בהרבה למתן פקודות טקסטואליות – במיוחד כשהוא מגובה על ידי ממשק ויזואלי.
(אגב, הפלת אותי בפח – התכוונתי לכתוב שפה טבעית או פשוט אנגלית)
הפלתי אותך בפח? איפה?
אבל זה בדיוק מה שהתכוונתי. שורת פקודה תבוא בד"כ עם תחביר מאוד קשיח ומוגדר. מה שמאפשר למנשק לנחש בשבילך את מה שאתה מתכוון להקליד כשרק התחלת להקליד אותו ולקצר תהליך. לעומת זאת ניתוח טקסט שנקלד (או נאמר) בשפה טבעית זו בעיה מסוג אחר, ולרוב לא תתן לך השלמות וניחושים לפני שכל הפקודה נאמרה אלא אם כן הניסוח פשוט וברור מספיק.
זה שאתה "לא מכיר משהו שעושה את זה" זה לא אומר שזה לא קיים. יש כמה וכמה חברות שעוסקות בזה, כולל לא מעט ישראליות, וזה למעשה הבסיס להרבה מתקני כתיב אינטיליגנטיים, מסכמי מסמכים אוטומטיים (יש כאלו), מנתחי טקסטים בגוגל להסקת רלוונטיות של דפים לנושאים מסוימים ובקיצור כל יישום של בלשנות גנרטיבית א-לה נועם חומסקי. אם אתה רוצה הדגמה מהירה, קח למשל את מנשק בירורי זמני האוטובוסים של אגד בSMS, שם המערכת מצפה לקבל פניות מאנשים לא מחשביים בסגנון "סליחה מה שלושת האוטובוסים האחרונים בשישי מנהריה לחיפה, תודה מראש" או "איזה קווים לקחת מצפת לרחוב הרצל באשדוד ומתי הם יוצאים בעזרת השם" ולדעת לענות. נדמה לי שזה אמור לעבוד גם באנגלית ונדמה לי שהם מנתחים אפילו יידיש.
אגב, אני רואה שהשירות הזה של אגד כבר בן 4 שנים (ותיק יותר מ"ווב 2.0" אני חושב), ושם החברה שפיתחה אותו היא אינטליגייט.
http://www.ynet.co.il/articles/0,7340,L-2982247,00.html
לא שאני מתיימר להבין איך השירות המסויים הזה של אינטליגייט עובד, אבל אני לא חושב שאני טועה כשאני אומר שמחשבים לא יודעים לדבר או להבין אנגלית.
ומכיוון שהשירות הזה לא התקדם הרבה מעבר לאותו יישום בדיוק, ייתכן מאוד שגם הוא לא עובד ממש:
http://www.intelligate.co.il/index.php?option=com_content&task=view&id=13&Itemid=19
פינגבאק: » בין ממשק ויזואלי לממשק טקסטואלי » וובסטר 4 - חנן כהן
יצרתי פקודה!
הפקודה מביאה לך את התרגום של מורפיקס:
http://yardensachs.com/ubiquity/
@ירדן: ראיתי בטוויטר שלך, כבר יש שם שתי פקודות עכשיו. סחטיין!
תודה! :)
תראה שוב! הוספתי שתיים ממש חושבים! (הפוך עך הפוך כזה)
הנני כאן. חדש בשיחה אבל מעוניין בדיעה.
לפי הכתיבה של כולכם, הייתי מעוניין בדיעה שלכם על אובדן ייצוג המשתמש: סמן העכבר הוא ייצוג של המשתמש על המסך. רואים את זה במצגות בייחוד, אבל גם משתמשים 'קוראים' באמצעות העכבר ועושים פעולות נוספות. ממשקים חכמים יודעים לראות איפה תשומת הלב של המשתמש על ידי המיקום של סמן העכבר (נעזוב לרגע יתרונות וחסרונות של ממשקים כאלו). נאמר שנחזור לעולם של שורת קוד, האם יש לנו דרך לדעת היכן המשתמש נמצא?
למה לעצור שם? נאמר שנחזור לעולם של לוחות חרס וחרטים, ואז נשב לחשוב על דוגמאות עוד יותר היפוטתיות ולא רלוונטיות. האם אז נשעין את הסנטר על אגרוף ימין או שמאל בשביל לחשוב?
"ייצוג המשתמש" אם אני מבין את המושג, הוא כלי עזר לתוכנה כדי לעזור לנו. בשורת הפקודה זהו עדיין סמן שמבין איפה אנחנו רוצים להקליד עוד אותיות, ויוביקוויטי מגיב ע"י השלמה לפי מה שהקלדנו עד אותו הרגע. לדעתך העכבר עושה משהו יותר טוב? האם כשאנו מגלגל את הגלגל קורה תמיד מה שאני רוצה? למעשה עשרות פעמים ביום אני גולל בחלון אחד רק כדי לגלות שאני מגלגל את החלון הישן שעדיין בפוקוס אבל העין שלי עזבה אותו מכבר. אולי הזזתי את העכבר לחלון אחר אבל מערכות הפעלהמסוימות יתעלמו מזה עד שלא ארביץ איזה "קליק" בריא בחלון החדש. אחרות יבינו שאני גולל במקום חדש אבל הפוקוס עבור המקלדת ישאר בישן. וכמובן שיהיו כאלו שיקחו עוד דרכי ביניים "משעשעות". לפעמים אגב בתוך החלון עצמו. אם לחצתי על "פליי" באפלט הפלאש של יוטיוב, הזזתי החוצה את העכבר ואז אני מנסה לגלול, אני אגלה שהגלגל לא עובד אלא אם אלחץ בשטח עמוד הווב בדפדפן בשטת שאינו הפלאש קודם… (יש עוד עשרות דוגמאות)
אז לדעתי הצנומה, שורת פקודה יש לה סמן אחד דו מימדי והיא יודעת איפה אני הרבה יותר טוב מאשר סמן העכבר שבוחר פוקוס בטיולו על הדסקטופ או לא בהתאם לרצונו הטוב של התוכניתן של הכלי שאיתו אני עובד, כי אין מוסכמות מוגדרות, אפילו לא בחלונות. אני מקווה שבמאק זה טיפה יותר טוב.
@ישי – זו נקודה מצוינת, הסמן הוא אחד העוגנים החשובים בממשק גרפי כפי שאנחנו מכירים אותו היום.
אם להמשיך את הדימוי הזה, אז בממשק גרפי המערכת סטטית ומוגדרת מראש והמשתמש נע בתוכה (מזיז את הסמן על המסך), ובממשק טקסטואלי המערכת מתשנה ומתחלפת והמשתמש תמיד נשאר במקום (הסמן המהבהב של שורת הפקודה).
לחלופין, בממשק טקסטואלי המשתמשת נמצאת במרכז והמערכת מתאימה את עצמה אליה. בממשק ויזואלי המערכת במרכז והמשתמש מתאים את עצמו אליה.
מעבר למשמעות הסימבולית של "המשתמשת במרכז", זה גם אומר שיותר כלים יכולים להיות זמינים למשתמשת בכל רגע נתון, אם היא רק יודעת איך להגיע אליהם ולהשתמש בהם. שוב – עקומת הלמידה חדה יותר, אבל התגמול גדול יותר.
כשהמשתמש נע בתוך המערכת במקום שהיא תנוע סביבו קורה דבר מעניין – קל יותר למשתמש להרגיש בשליטה למרות שבפועל מידת השליטה שלו קטנה בהרבה. הגבולות המוגדרים והברורים של הממשק הגרפי (גבולות המסך…) תורמים לתחושות היציבות והביטחון שנחוצות לתחושת השליטה.
זה גם מעלה שאלות מעניינות לגבי ממשקי זום (או ZUI) – עוד תחום בו עסק ג'ף רסקין. בממשקים כאלה, המערכת מיוצגת על ידי שטח מסך בלתי מוגבל, והמשתמש נע במערכת בשלושה ממדים – מלבד גלילה אופקית ואנכית, אפשר גם להתקרב ולהתרחק, וכך לגלות או להסתיר פרטים נוספים. אפשר לדוגמה להתקרב לערימה קטנה של אייקונים על שולחן העבודה ולגלות גלריית תמונות באיכות גבוהה.
תמונות הן הדוגמה הקלה ביותר וגם היישום הפופולרי ביותר, אבל אלו יכולים באותה מידה להיות מסמכים מכל סוג אחר. מיקרוסופט התעסקה בזה קצת, זו דוגמה מהעבודה של רסקין:
http://rchi.raskincenter.org/demos/zoomdemo.swf
בממשק כזה אמנם יכול להיות סמן, אבל אין מגבלות ואף פעם אין מושג ברור של התחלה וסוף, וקשה ליצור נקודות התייחסות וציוני דרך שיקלו על ההתמצאות.
@עירא – לא נמנה את כל המודלים השונים לפעולה בממשק טקסטואלי…
אבל אם יורשה לי להרחיב את הדוגמה שלך, קח למשל את השילוב של נגן פלאש כמו זה של יוטיוב בתוך פוסטים, בעת קריאה של הפוסטים האלה בגוגל רידר:
לחיצה על spacebar שווה לגלילה של כמעט מסך שלם, קיצור דרך ל-page down. אם מגיעים לפוסט שיש בו נגן פלאש, אז הדפדפן עדיין קולט את הלחיצה כקיצור לגלילה ואכן ממשיך לגלול ומסתיר את הנגן, אבל הוא עדיין נמצא שם ופלאש קולט גם הוא את הלחיצה, ומפרש אותה כקיצור דרך לפליי (במקרה של הנגן של יוטיוב בכל אופן).
כך, כשהרמקולים שלך מוגברים עד הסוף, אתה יכול פתאום להתחיל לנגן בטעות וידאו רועש במיוחד שבכלל לא יהיה מוצג על המסך באף לשונית פתוחה. עבור כל מי שגוגל רידר כבר ממילא הפך אותם למטומטים, זה יכול להיות מצב מאוד מבלבל.
גם ב-Aurora של Adaptive Path יש ZUI:
http://adaptivepath.com/aurora/
פינגבאק: מנוע חיפוש מונחה מקלדת » תומר כהן
אחד הפלאג אינים המדוברים ללא ספק.
רן, מה לגבי הבלוג של נענע, זנחתם אותו לגמרי?
או שהביקורת על האתר החדש הוציאה לכם את כל האוויר??
דרך אגב, כל החלק של התגובות נראה נורא על דפדפן אופרה, היישור לימין לא כפי שצריך ככל הנראה.
@דרזיק: אתה משתמש באופרה?
אני אתקן את זה היום
@עירא: "למה לעצור שם? … דוגמאות עוד יותר היפוטתיות ולא רלוונטיות…?" וגו'. ציניות. אחלה. גורם לי לרצות להמשיך.
"ייצוג המשתמש" אם אני מבין את המושג, הוא כלי עזר לתוכנה כדי לעזור לנו" — לא רק. ייצוג המשתמש הוא הדרך של המשתמש לראות שיש תגובה של המערכת לפעולות שלו. יש כאן גם עניין פסיכולוגי.
""לדעתך העכבר עושה משהו יותר טוב?"– לצערי לא תמיד. ברוב המערכות אכן רק הלחיצה על העכבר מציינת פעולה. למרות שבאופ(י)ס 2007 של מיקרוסופט התפריט שמופיע אחרי הגדשה של טקטס ומוריד או מעלה מהשקיפות הוא יישום נחמד של תנועת העכבר = רצון המשתמש. אם ביוביקוויטי השורה הייתה מופיעה אחרי שהדגשתי את הטקסט אז אכן היה מעיין הבנה של המערכת:'הדגשת משהו, מה תרצי לעשות עם הקטע המודגש?'
@ רן יניב: תודה על התגובה. אני אוהב מאוד ZUI-ים.פעם נדבר עליהם. לגבי ההערה שהעלית על תחושת המשתמש: אני מאוד מקבל את זה: תחושה של שליטה לפעמים חשובה משליטה אמיתית, כמו שגורסת כל אסכולת 'חווית המשתמש'.
אני חושב שממשק טקסטואלי מתאים יותר לפעולות רפטטיביות ולסביבות עבודה מהירה, למשל בקופת חולים שם האחות יודעת להקיש פעמיים אנטר, 3 פעמים רווח, שם חולה, פעמיים אנטר,תעודת זהות וכו'.הן בד"כ לא מסתכלות אפילו על השאלות של המחשב. אני חושב שממשק טקסטואלי לא מתאים לרשת משום שיש כל פעם פעולה אחרת על הקטע הנבחר ומספר הפעולות ילך וייגדל. דווקא לחיצה על אייקון מסויים תהיה קלה יותר למשתמש: אני לוחץ על האייקון של tiny URL וזה נותן לי את הפעולה של כיווץ הכתובת.
רן, אכן אני משתמש באופרה.
אבל עכשיו כנראה אעבור לכרום. המהירות שלו מהשטן, וזה ממכר.
ד"א, נענע 10 לא ממש נראה מזהיר עם הכרום, הרבה בעיות.
נראה לי שיותר מדי עשו אופטימיזציה לפיירפוקס ואקספלורר במקום לתקן.
בכל אופן, גם בכרום הטקסט פה נראה משובש.
מה עם איזה התייחסות לכוכב החדש?
ומה לגבי קצת סיפורים על נענע, על פיצ'רים חדשים, אולי תיבת מייל מודרנית סופסוף?
פינגבאק: שימושיות, שימושיות ועוד פעם שימושיות. רן מדווח על תוסף שימושי חדש ל
פינגבאק: שימושיות, שימושיות ועוד פעם שימושיות. רן מדווח על תוסף שימושי חדש ל