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

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

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

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

שימוש באב טיפוס טוב מהסיבות הבאות:

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

מטרות השימוש באב טיפוס:

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

יתרונות ומוקשים

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

ליאור הראה הרבה דוגמאות של יציאת אב טיפוס בשימוש ב-axure ליצירת אב טיפוס, ייצוא שלו ל html וגם ייצוא שלו לאפליקציית סלולר.

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

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

רחלי ברט טננבאום | 9 באוגוסט 2010 | כללי | אין תגובות

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

אני חושב שכבר אמרתי את זה באחד הפוסטים הקודמים שכתבתי, אבל אחת הדילמות העיקריות שלנו דנה בעניין פיתוח מערכת לניהול תוכן. באופן עקרוני, הגרסא הראשונה של כליקיט פותחה כבר במאה הקודמת (1999) כיוון שלא הרבה אפשרויות אחרות – מערכות ה-CMS היו עוד בחיתוליהן, היה מבחר מועט ות’כלס אף אחת מהן לא היתה כזה גליק, אז החלטנו לפתח בעצמנו מערכת שכזו, וככה נוצרה כליקיט. באופן טבעי, במרוצת הזמן המשכנו לתחזק ולפתח את המערכת – מכליקיט לכליקיט2, מכליקיט2 לכליקיט3 ומכליקיט3 לכליקיט לייט, שהעבודה עליו הסתיימה לפני שנה לערך.

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

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

אה,
וגם שדרגנו את גרסת המודל שלנו ל-1.9.7.

יהונתן לרנר | 4 בינואר 2010 | אינטרנט, פיתוח | 2 תגובות

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

ועכשיו נתחיל מההתחלה…

מוטיבציה

במשך שנים רבות היה עורך אחד ויחיד בכליקיט3 – עורך של חברת מייקרוסופט. הוא הכיל את כל הכפתורים המוכרים מ-Word, וגם כמה כפתורים מיוחדים למערכת שלנו: כפתור הוספת אינטראקציות, כפתור יצירת קישור למטלת LMS, כפתור של ציור חופשי. בקיצור, אידיליה.
יום אחד, יצא לשוק דפדפן חדש : אינטרנט אקספלורר 7.  מיד עם יציאתו לשוק הוחלט שחלק מחברי הצוות ישדרגו את דפדפנם לגרסה החדשה, כדי להתנסות בו עם מערכת הכליקיט ולתקן בעיות אם ישנן. ואכן לאחר זמן קצר התברר שקוד ה-JavScript של העורך אינו תואם את הסטנדרטים של הדפדפן החדש, ומספר כפתורים מקפיצים הודעות שגיאה. מהר אצנו-רצנו ותיקנו את השגיאות כדי שכולם יוכלו להשתמש בעורך בכל גרסאות אקספלורר, והשקט שב לאזורנו.  זה היה הרמז הראשון כי זמנו של עורך לא סטנדרטי עומד להסתיים, והתחלנו לחשוב מה לעשות.
ובכן, זמן מרובה למחשבה לא היה לנו, מפני שאך סיימנו להתמודד עם IE7, צצה וקפצה לה מערכת הפעלה חדשה: Windows Vista. כאן לא עזרו לנו תחבולות שונות בעורך – מערכת ההפעלה אבחנה את העורך כיצור עוין מבחינה אבטחתית, ואנחנו היינו מוגבלים ביכולת שלנו לשנות את דעתה בגלל הקוד המורכב של העורך.
בשלב ההוא עדיין לא שקלנו הכנסת עורכים אחרים מלבד זה של מייקרוסופט. היתה תחושה של – זה העורך שלנו ואיתו ננצח. עם זאת, כדי לתת פתרון למשתמשי ויסטה, עמדה לרשותנו מתכנתת מדהימה, והיא קיבלה על עצמה לכתוב עורך שיתאים לסטנדרטים. חיש קל ניגשה לעבודה, ותוך מספר שבועות עמד על רגליו עורך סטנדרטי, המכיל את הכפתורים העיקריים הנחוצים לערכית טקסט באינטרנט, ועובד בכל מערכות ההפעלה ודפדפני האינטרנט (כן, גם פיירפוקס!). האם הגענו אל המנוחה ואל הנחלה? ממש לא – התברר שהכפתורים שלא הספקנו ליישם בעורך החדש (המכונה במחוזותינו "העורך הקל") – כגון אותם כפתורים מותאמים למערכת כמו אינטראקציות ודומיו – היו מאד חסרים למשתמשי המערכת, והגבילו מאד את שימושם בעורך הקל. הבנו שהפתרון הזה הוא זמני בלבד. עם זאת, העורך הזה בכל זאת קיבל עדנה כאשר החלטנו להשתמש בו גם במקרים שהכותב גולש בדפדפן סטנדרטי, כגון פיירפוקס, וכך הוא הוכנס כעורך בין השאר גם לפורומים ולתגובות, לשמחתם הרבה של הגולשים הסטנדרטיים.
הקש ששבר את גב הגמל היה לא אחר מאשר אינטרנט אקספלורר 8. מיד עם יציאתו לשוק בדקנו בו את העורך, וראינו שגם הוא, כאחיו 7, סרב לתמוך בעורך בלתי סטנדרטי, אך הוא הוסיף חטא על פשע – הוא לא שלח לקוד זיהוי ברור של זהותו, ועל כן היה קשה מאד לזהות משתמשי אקספולרר 8 ולהגיש להם את העורך הקל. לאחר עבודה קשה הצלחנו למצוא דרך לזהות את אדון 8, אבל הבנו שבגרסה הבאה של אקספלורר שוב תיווצר הבעיה, והחלטנו לשים לעניין סוף – הקש הזה גרם לנו להחליט לעבור לעורך מלא וסטנדרטי לחלוטין. בשלב זה של חיינו המקצועיים כבר היינו אחרי הקמת מערכת כליקיט לייט, ואחרי הטמעת מערכת וורדפרס אצלנו, ולכן היתה לנו כבר היכרות עם עורך כזה – TinyMCE. מצאנו מתכנת שיודע היטב JavaScript שיוכל להוסיף לעורך הנפלא הזה את הכפתורים המיוחדים למערכת שלנו, ויצאנו לדרך.

היישום – עם באגים

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

(אנחת רווחה)

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

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

היישום – ללא באגים?

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

הפסקת אש

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

ואחרי זה?

מי יודע? זה מה שכיף בעבודה עם אנשים – אתה אף פעם לא יודע מה יהיה הסוף. ימים יגידו.

לאה כהן | 9 בנובמבר 2009 | פיתוח, שמישות ושימושיות | 2 תגובות

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

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

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

באופן עקרוני, על מנת להטמיע את גוגל אנאליטקס באתר צריך להעתיק חתיכת קוד ולהשתיל אותה בפוטר של דף הבית. לאחר בחינה קלה, ראינו שכל חתיכות הקוד שגוגל אנאליטקס נותן לצורך השתלה באתר זהות זו לזו – אותן 13 שורות קוד הנדרשות להוספה בפוטר ש לאתר א’ זהות לאלו הנדרשות לאתר ב’ – חוץ ממחרוזת אחת שמופיעה בתחתיתו ושמתחילה ב-UA-xxxxxxx-xx. לכן, בתוך דף הניהול של האתר בכליקיט 3 יצרנו שדה שמאפשר למנהל האתר להזין את המחרוזת הזו, וככה הוא לא צריך להכנס לנבכי ה-HTML של דף הבית של האתר.

זהו זה, קל ופשוט.

יהונתן לרנר | 20 באוקטובר 2009 | אינטרנט, פיתוח | 2 תגובות

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

להלן הרשמים מהמשחקים שלי איתה בחודשים האחרונים.

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

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

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

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

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

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

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

זהו זה.

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

שנה טובה!

יהונתן לרנר | 10 בספטמבר 2009 | כללי | אין תגובות

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

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

לאה כהן | 11 באוגוסט 2009 | פיתוח | 2 תגובות

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

תכנון חוויית משתמש איננו…

1. …תכנון ממשק משתמש
   ממשק הוא מרכיב בחוויית המשתמש, אבל יש הרבה יותר. עיצוב אינו עניין קוסמטי, הזזת פיקסלים ומיקום כפתורים. זהו דבר הוליסטי ומהווה עניין לכולם, לא רק לטיפוסים "יצירתיים".
2. …צעד בתהליך
   הוא עצמו התהליך. כדי ליצור חוויה מצויינת למשתמשים שלך ולא רק לעצב משהו שהיינו רוצים להשתמש בו, אנחנו חייבים להמשיך לחזור ולהקשיב ולעצב בהתאם. עיצוב חוויית משתמש אינה משהו חד פעמי. זה חיב להיות מוטמע בכל מה שאתה עושה.
3. …קשור לטכנולוגיה
   חווית משתמש גם אינה קשורה לטכנולוגיה. היא קשורה לדרך החיים שלנו, לכל מה שאנו עושים. מעצבי חוויית משתמש משתמשים בטכנולוגיה כדי לעזור לאנשים לממש את מטרתם. אבל המטרה העיקרית היא לעזור לאנשים, לא ליצור טכנלוגיה מדהימה. באמת, מעצב חוויית משתמש יכול לסייע בשיפור חויה של אדם כמעט עם כל דבר – ידית, ברז, עגלת קניות. אנחנו פשוט בד"כ לא מתייחסים לאנשים הללו כ"משתמשים", אבל זה מה שהם.
4. …קשור רק לשמישות
   אנשים בד"כ חושבים שעיצוב חוויית משתמש היא דרך להפוך מוצרים לא מוצלחים למוצרים מוצלחים ע"י הפניית משאבים לעיצוב המוצר. אבל יצירת מוצרים קלים ואינטואיטיביים היא ממש לא המטרה היחידה. שמישות היא אמנם חשובה, אבל ההתמקדות שלה ביעילות ותועלת מטשטשת את המרכיבים החשובים הנוספים בחויית משתמש, כולל קלות לימוד ותגובות רגשיות והתנהגותיות למוצרים ולשרותים שבה אנו משתמשים. לא כל דבר חייב להיות הכי פשוט בעולם, אם קל ללמוד אותו. והעיצוב שלו כמוצר מושך היא קריטית, אחרת אנשים לעולם לא ירצו בכלל להתממשק איתו
5. …קשור רק למשתמש
   רוס אונגר אוהב לומר שהמיתוס הגדול ביותר ב-UX הוא ה-U. יש גם כמה מטרות עסקיות שצריך לממש, והעיצוב מתייחס גם אליהן. אנחנו לא תמיד יכולים לעשות מה שטוב למשתמש. אנחנו חייבים לוודא שאנחנו מציגים חוויה כוללת היכולה לשרת מטרות וצרכים רבים ככל האפשר לעסק ולמשתמשים.
6. …יקר
   לפעמים תהליך עיצוב חוויית משתמש מלא הוא ממש לא מה שדרוש. בהחלט יתכן לבצע מספר שיפורים קטנים הן  לפרוייקט והן ולמוצר ע"י שימוש בטכניקות חווית משתמש
   אנשים נצמדים לדברים כמו פרסונות, סקר משתמשים וכד’. במציאות, למעצבים הטובים יש סט כלים המאפשר בחירה ושימוש במתודות עפ"י הצורך בכל פרוייקט.
7. …קל
   רק בגלל שאנחנו יודעים לבצע כמה פעולות מגניבות ומועילות, ומכירים את העסק שלנו ממש טוב, זה לא אומר שכל התהליך הזה הוא קלי קלות. להפך – נסיון לעגל פינות בצעדים חשובים הוא מתכון לאסון.
8. …תפקידו של אדם אחד או של מחלקה אחת
   אנחנו כתעשיה לא השכלנו להפריד בין תתי התמחויות ותפקידים בעיצוב חוויית משתמש וכך לקוחות אינם מבינים שעליהם להעזר בסוגי אנשים שונים בנקודות שונות בחיי הפרוייקט.
9. …דיסציפלינה יחידה
   יתכן שעדיין אי אפשר לומר שמדובר בקהילה. במקרה הטוב מדובר במודעות משותפת, חוט המקשר יחד אנשים מדיסציפלינות שונות שאכפת להם מעיצוב טוב.
   אנשים שונים מתמחים בחלקים שונים בתהליך. כשם שלא היית הולך לקרדיולוג כדי שירפא את הרגל השבורה שלך, אל תצפה מכל מומחה בתחום חוויית המשתמש להשיג את כל המטרות שלך.
10. …אופציה
    ג’ארד ספול, המייסד והמנכ"ל של חברת המחקר הגדולה בעולם בתחום חוויית המשתמש, ביצע חקירות נרחבות על איכות צוותי מוצר מוצלחים ומרוצים. בפשטות, הפגם הנפוץ ביותר שהוא מצא הוא חברות החושבת ש"חוית משתמש טובה היא תוספת, לא דרישה יסודית".

לאה כהן | 8 ביוני 2009 | כללי | אין תגובות

לאה כהן | 18 במאי 2009 | כללי | אין תגובות

לאה כהן | 7 במאי 2009 | כללי | אין תגובות

User Interface Engineering היא חברה בראשותו של Jared Spool, מומחה usability ידוע. באתר החברה הוא מפרסם מאמרים רבים בנושא שמישות וחווית משתמש.
במאמר שקראתי שם לאחרונה, מוצגות 3 שאלות שכל חברה שרוצה ליצור מוצר עם חוויית משתמש נפלאה צריכה לשאול את עצמה.

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

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

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

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

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

לאה כהן | 25 בינואר 2009 | מנשק משתמש, פיתוח, שמישות ושימושיות | תגובה אחת