אחרי מעל 8 שנים שאני לקוח באורנג', הייתם מצפים שהם יגלו שברק דנין זה אדון, לא? מצורף למטה אימייל שקיבלתי מאורנג' היום.

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

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

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

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

בסוף המצגת מסתתרת הנחה על הסדנה הקרובה

אבל היא בתוקף רק עד היום, יום רביעי ה-16/6, בחצות.

ההנחה מסתתרת גם בוידאו

אבל צריך לעבוד יותר קשה כדי למצוא אותה…

שימו לב: חכו כמה דקות כדי לראות את הוידאו, הוא לא יתחיל לנגן מייד: לוקח לו 5-10 דקות להיטען. אלה מגבלות טכנולוגיות זמניות – אני יודע שחוויית השימוש כאן לא מיטבית, אבל היה חשוב לי להביא את התוכן כמה שיותר מהר. בהמשך אשפר את עניין הוידאו.

בשבוע הבא, ביום שלישי ה-15/6/2010 בין 10:00-11:00 בבוקר אקיים מפגש ברשת (וובינר) שבו תוכלו לקבל תשובות לשאלות שיש לכם בנושאי חוויית משתמש, ממשק משתמש, ושמישות (usability). המפגש מיועד קודם כל למשתתפים בסדנה שלי, אבל כולכם יכולים לבוא ולהקשיב, וגם לשאול שאלות.

עדכון 17/6: המפגש התקיים אתמול, המצגת והוידאו של המפגש נמצאים כאן להנאתכם.

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

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

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

להשתמע ביום שלישי!

כמה פעמים ישבתם מול הודעה שאומרת לכם – "[משהו] עומד לקרות. האם להמשיך?", עם כפתורי "המשך" ו"בטל"? כמה פעמים מתוכן קראתם את ההודעה שוב ושוב והתלבטתם על מה ללחוץ, וכמה פעמים פשוט לחצתם על "בטל" או "המשך" בלי לחשוב?

על הודעות אישור פעולה (confirmation messages), מתי להשתמש בהן ומתי ממש לא.

דוגמה

כולנו נתקלנו בהודעות כמו זו מג'ימייל:

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

עדיף לא להסתכן בטעות

מאיר אריאל שר "טעות במחשב עלתה לי מיליון…" – ויטלי כתב על מקרה מהשבוע האחרון שבו זה באמת קרה: סוחר בבורסה לחץ בטעות על הכפתור הלא נכון, והזרים הוראה לרכישה של מיליארדי (ביליונֵי) מניות, במקום מיליונים. הבורסה הגיבה בנפילה. האם המשתמש טעה ולחץ על "b" (עבור billion) במקום על "m" (עבור million)? כנראה שלא נדע. אבל בכל מקרה שבו מציבים מכשול, מקום שבו משתמשים עשויים לטעות, יהיו כאלה שיטעו בו. אפשר לשאול את המשתמש "האם אתה בטוח?", אבל יותר כדאי לעצב את המערכת כך שלא יהיה סיכוי לטעות.

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

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

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

סכנה 1: הטרדה

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

כדי להמנע מהטרדה כזו צריך להפעיל שיקול דעת פשוט ולשאול כמה שאלות פשוטות:

• האם הפעולה הזו בלתי-הפיכה?
• אם היא הפיכה, האם המשתמש ידע בקלות כיצד לבטל אותה?
• אם היא בלתי-הפיכה, האם ביצוע שלה יגרום לאובדן מידע או זמן משמעותיים למשתמש?

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

סכנה 2: ניסוח

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

לא הבנתם? הנה, אריק איינשטיין יסביר לכם:

אז האם זה "Document Recovery task pane" במובן של "גרופן" או במובן של "גראפן"?

אם נשים לרגע את הצחוק בצד, למי מכם שלא יודע, ה"Document Recovery task pane" זו החלונית שבה מופיעים כל המסמכים ש-Powerpoint שמר אוטומטית עבורכם לפני שהתוכנה התרסקה. כלומר, אלה גרסאות של מצגות שלא שמרתם בפעם האחרונה שעבדתם עליהן, וזו ההזדמנות האחרונה להציל אותן. האם אי אפשר היה לכתוב משהו שאומר את זה?

סכנה 3: עיצוב גראפי

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

היה אפשר, למשל, להשתמש באייקון כזה (נלקח ממקינטוש):

אפשר היה לעשות כמה דברים נוספים בעיצוב:

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

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

סכנה 4: ברירות מחדל וכפתורי פעולה

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

סיכום

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

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

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

התמונה שלמעלה: CC by adobemac

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

בסוף כל חודש אני מקבל מאורנג' חשבונית במייל. טוב, לא בדיוק חשבונית, קישור להורדת חשבונית. שירות די נוח ומאובטח, האמת. לוחצים על קישור ומקבלים קוד חד-פעמי ב-sms, מכניסים אותו לטופס ואז מתחיל ה-download:

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

הטופס

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

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

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

בנוסף, ההודעה "הקוד נשלח בהצלחה" בשילוב עם האייקון של ה-V הירוק היא חיזוק מצויין: היא אומרת – אצלנו הכל בסדר. מה שחסר בה הוא מידע חשוב – להיכן הקוד נשלח.

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

ההודעה ב-SMS מגיעה משולח שנקרא "Orange" והיא נראית ככה: "הקש מספר זה להמשך תהליך 999999". תקראו לי קטנוני, אבל אם באתר קוראים לזה "קוד חד-פעמי", לא כדאי גם ב-SMS לקרוא לזה ככה? זה היה מקל על הקישור בין השניים. עוד עניין, יכול להיות שאת החשבון מקבל מישהו שלא מחזיק בטלפון ביד כרגע. למשל – אב המשפחה מקבל אותו עבור הטלפון של הבת שלו, והבת לא בבית כרגע. מה היא תחשוב כשהיא תקבל את ההודעה?

אני מציע את העיצוב החדש הזה:

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

את ה-SMS הייתי משנה ל"הקלד קוד זיהוי זה להמשך התהליך באתר אורנג': 999999". כך השם הוא "קוד זיהוי" כמו בטופס, וגם ברור למי שקיבל את ההודעה שקורה משהו עם הקו שלו באתר אורנג'.

נשמע הגיוני?

מה דעתכם על השינוי הזה? הייתם משנים עוד דברים כאן? כרגיל, אשמח לשמוע את דעתכם.

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

http://uxi.org.il/pages/1789

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

זהירות, הצלחת!

נכנסתי לחשבון הבנק שלי כדי לעדכן את הסיסמה, ולאחר השינוי קיבלתי את ההודעה הזו:

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

• 

  תמרור א-40

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

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

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

אייקונים מוסכמים להודעות

בהנחיות שמיקרוסופט נותנת ליישומים ב-Windows מופיעים האייקונים הבאים:

ההנחיות ברורות:

• X – הממשק מראה שגיאה או בעיה שהתרחשו.
• ! – הממשק מראה מצב שעשוי להיות בעייתי בעתיד.
• i – הממשק מראה מידע שימושי.
• ? – הממשק מראה נקודת כניסה למערכת העזרה

במקינטוש יש גם אייקונים סטנדרטיים שמשמשים באופן דומה, למשל אלה:

במקינטוש נוהגים גם להצמיד אליהם בפינה את האייקון של היישום שהעלה את ההודעה.

ברשת נהוג להשתמש בצבע הירוק ובסימן ה-V כדי לציין הצלחה. כך למשל בטוויטר:

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

חשיבות השימוש בסטנדרטים

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

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

סטדנרטים קיימים לא רק באייקונים של הודעות שגיאה. הם קיימים בהרבה מקומות בממשק. למשל, מוסכם בהודעת אימייל שיש "Reply" כדי להשיב לכותב, ו-"Reply to All" בשביל להשיב לכל הנמענים.

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

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

זה קרה גם לכם?

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

עדכון 15/4: ההרצאה כבר התקיימה. רוצים שאודיע לכם בפעם הבאה שהיא מתקיימת? הכניסו את כתובת המייל שלכם כאן ואודיע לכם.

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

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

ההרצאה תתקיים פעמיים:  (עדכון: ההרצאה התקיימה כבר)

• הרצאת בוקר: ביום רביעי, 14/4/2010, בין 10:30-12:00
  
• הרצאת ערב: ביום שלישי, 13/4/2010 בין 18:30-20:00
  

מבנה ההרצאות

שתי ההרצאות יתחלקו לשניים:

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

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

משתתפים אמרו על ההרצאה…

"אתמול הקשבתי להרצאה שלך, היא הועברה בצורה מאוד מענינת ותרמה לי לא מעט על אף הנסיון שיש לי בתחום”, פנינה

“נתן טעם של עוד”, בילי

“תודה, נהנתי להקשיב. שמחה על ההזדמנות ללמוד ממך”', רוית

“תודה רבה על ההרצאה המעניינת והמעשירה… היה מאוד מעניין לשמוע וללמוד קצת את הנושא. כל הכבוד גם על החדשנות שבהעברת הרצאה ברשת בזמן אמת“, אתי

ההרצאות בשידור חי בלבד

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

הרשמה להרצאות

עדכון 15/4: ההרצאה כבר התקיימה. רוצים שאודיע לכם בפעם הבאה שיש הרצאה? הכניסו את כתובת המייל שלכם כאן ואודיע לכם.

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

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

שתי ההרצאות יתקיימו ביום שלישי שאחרי פסח (איסרו חג / מימונה):

• הרצאת בוקר: 6/4/2010 בין 10:30-12:00.
• הרצאת ערב: 6/4/2010 בין 17:30-19:00.

מבנה ההרצאות

שתי ההרצאות יתחלקו לשניים:

• בחלק הראשון, שיימשך קרוב לשעה, אדבר על נושא ההרצאה – מה זה "עיצוב חוויית משתמש".
• בחלק השני אענה לשאלות של המשתתפים.

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

משתתפים אמרו על ההרצאות ש…

"אתמול הקשבתי להרצאה שלך, היא הועברה בצורה מאוד מענינת ותרמה לי לא מעט על אף הנסיון שיש לי בתחום”, פנינה

“נתן טעם של עוד”, בילי

“תודה, נהנתי להקשיב. שמחה על ההזדמנות ללמוד ממך”', רוית

“תודה רבה על ההרצאה המעניינת והמעשירה… היה מאוד מעניין לשמוע וללמוד קצת את הנושא. כל הכבוד גם על החדשנות שבהעברת הרצאה ברשת בזמן אמת“, אתי

ההרצאות בשידור חי בלבד

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

הרשמה להרצאות

עדכון 6/4: ההרצאה תתקיים שוב בשבוע הבא. לפרטים נוספים

חג שמח!

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

שיהיה לכולכם חג אביב שמח, ובעדינות עם הקניידלעך והמצות!

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

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

דברים קטנים אבל מעצבנים

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

הנה דוגמה לתבנית לא סלחנית מתוך המערכת flex הישראלית לניהול חשבונות:

flex. לא סולחת ולא שוכחת.

למקרה שלא הבנתם את הודעת השגיאה, הייתי צריך להקליד כאן 11/03/2010 ולא 11/3/2010. ברור, לא? כמה היה עולה לתכנת שדה שיודע להבין גם 11/3/2010 ולא רק 11/03/2010? שלא לדבר על 11-3-10 או 11.3.10. במקרה של flex הטעות חמורה אפילו יותר, כי יש כאן מקום להזנת תאריך, אבל אי אפשר לבחור מלוח שנה כמקובל בשדות תאריך. כך שכל מי שרוצה להזין תאריך לעשות את זה לפי איך שהמתכנת של השדה הזה הסכים לקבל תאריכים – his way or the highway.

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

גם טדי קולק ז"ל היה מסתדר עם המפות של גוגל, יוּרשלים

תאריכים סלחניים

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

• 17-3-2010
• 17/3/2010
• 17.03.2010

אני יכול להשתמש בתאריך מקוצר:

• 17/3
• 17

וגם ביום:

• Wednesday
• Wed

אפשר גם ברביעי הבא:

• Wed Week
• Wed W

וכן הלאה. כמה זה מסובך לתכנן ולתכנת את זה? לא מאוד. וזה יכול לעבוד בכל שדה תאריך.

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

• Dinner with John tonight at 19:00
• Dinner at 19:00 with John
• 7pm dinner with John

הוספה מהירה בלוח השנה של גוגל

עמודי נחיתה סולחים בקלות

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

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

טופס בעמוד נחיתה שאוכל הכל (כמעט)

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

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

לבחור קידומת טלפון מרשימה? למה?

יש עמודי נחיתה שעושים את זה פחות טוב:

למה צריך לבחור את הקידומת מרשימה?

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

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

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

תבנית סלחנית – דפוס עיצוב

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

• ב-Quince
• ב-UI-Patterns
• ב-Designing Interfaces (האתר של הספר)
• ב-UXI עוד אין, אבל יהיה בקרוב… ויש שם גם כמה דפוסי עיצוב אחרים.