כשל

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

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

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

והיית חושב שזה די ברור ולא אמור להפתיע אף אחד, אבל לא – אני די בטוח שזה כן יפתיע את בעליה של חנות אינטרנט מסוימת למכירת טלפונים סלולריים. הוא רצה שם מתחם טוב וזכיר שמשדר לעולם "אני מוכר טלפונים סלולריים". בפועל, הוא קיבל שם שמשדר "אל תתקרבו לחנות שלי, אנחנו מתייחסים חרא ללקוחות". www.zilzul.co.il. אין על זילזול, הכי טובים.

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

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

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

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

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

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

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

–המשך קריאה–

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

–המשך קריאה–

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

There are known knowns; there are things we know we know.
We also know there are known unknowns; that is to say we know there are some things we do not know.
But there are also unknown unknowns – there are things we do not know we don't know.

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

–המשך קריאה–

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

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

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

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

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

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

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

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

–המשך קריאה–