Wednesday, October 11, 2006

שמנטורה באויר

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

http://shmentura.blogspot.com

Friday, October 06, 2006

פאוור פוינט חשוב לדמוקרטיה?

פאוור פוינט חשוב לדמוקרטיה? בסדר. גם דף A4 חשוב לדמוקרטיה.

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

Friday, September 22, 2006

חיים, מוות ואינדיקציה ויזואלית



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

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

Friday, September 15, 2006

לינקים מהירים



מספר לינקים מהירים:

קאתי סיירה מCreating Passionate Users בפודקאסט (mp3) באורך מלא שהוקלט בהרצאה. סיכום של פוסטים רבים, איך לעשות משתמשים שמחים ומאושרים, איך לגרום להם להשתפר ולאהוב את עצמם יותר, במקום לדאוג בגלל שהם לא מצליחים לתפעל איזה פיצ'ר עלום בתוכנה שלך\י..

בלוג חדש לאשלי ווד. (לינק - מאיה.)

רעיונות על רעיונות - בלוג על עיצוב, כתיבה עיצובית ומחשבות על מחשבות..

קודינד הוררור - תכנות ואימה, דוט נט וממשקי משתמש

סרט באורך מלא - Pollinate



הסטודיו Belief שקד על סרט נהדר ששמו Polliate. (ניתן גם להורדה באורך מלא כקובץ 70Mb - quicktime).

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

מומלץ ביותר.

Wednesday, September 13, 2006

אז מה אני, בעצם?



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

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

דיאלוגים מורכבים ובחירת פקדים



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


הבעיה המרכזית שאנחנו נתקלים בה היא שקשה באופן קיצוני להתאים את הגרף לצרכי המשתמשים או המתכנתים, כיוון שדיאלוג העריכה בלתי ניתן לניווט - הוא מכיל 5 (!) רמות של טאבים (לשוניות) ובכל אחת מהם בין 3 ל7 לשוניות שונות - בדוגמא שלפנינו לדוגמא ניתן לספור 25 לשוניות על המסך!

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

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

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

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

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

יש עוד המון תמונות של דיאלוגים מפלצתיים ועמוסים בלשוניות בThe Interface Hall of Shame - Tabbed Dialogs.