שיקולים בעיצוב אפליקציות מובייל

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

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

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

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

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

The Hotzone - האזור בו אצבע המשתמש חופשיה ועלולה להקיש (tap) בטעות. כדאי להרחיק את האזורים הלחיצים ממנה. מקור: http://answers.oreilly.com/topic/1802-designing-iphone-apps-the-rule-of-thumb/

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

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

"פרויקט התאמה" קוראים לזה, Mobile Adaptation או Mobile Enablement ומנסים, בעזרת צוות של כמה מפתחים ואיש UI חסר מזל, "לדחוס" את האלמנטים הגרפיים ממסך של "22 למסך של "4.
בעוד ב Desktop יש עכבר שהוא כלי הצבעה דיי מדויק, במובייל אזורים לחיצים צריכים להיות גדולים בהרבה - מה שמותיר מקום מועט אפילו יותר לתוכן שעל המסך.

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

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

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

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

מה ניתן היה לעשות אחרת?

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

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

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


ככלל אצבע, לאפליקציית מובייל טובה לרוב יהיו:

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

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

חשבו לדוגמה על ההבדל בין אאוטלוק ל Mail ב iPhone: כמה עשרות, אולי מאות, פונקציות של אאוטלוק לא מצאו מקבילה בגרסת המובייל? בכל זאת, השימוש באפליקציה הוא נוח למדי ומתאים למרחב רחב מאוד של משתמשים. 
דוגמה נוספת: חשבו על המקלדת של המובייל מול מקלדת של Desktop, איפה כל כפתורי ה F-masheu? כיצד ביטלו את כפתור ה del (מחיקה ימנה) וניתן להסתדר רק עם מחיקה שמאלה[ב]?

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


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

הקלדה היא מאמץ מוגבר - שמור עליה

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

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

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

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

ססמאות בנייטיב אפ - במערכות ווב שדורשות הקלדת משתמש / סיסמה, דבר מקובל הוא לייצר מעטפת (למשל PhoneGap) שתשמור את הסיסמה ב Secured Storage של המכשיר. יכולת זו בלבד מצדיקה שימוש ב PhoneGap ופיתוח Hybrid App.

אל תצפה ממשתמש לנווט במסך של 4 אינץ'

חיפוש - הוא סוג הניווט המועדף. ללא פירורי לחם (breadcrumbs) ובטח ללא עץ ניווט. רשימת הפריטים האחרונים / הנפוצים יכולה להיות גם נקודת פתיחה טובה (חשבו על ה App Store).

שמור קצת מידע בצד ליום סגריר (connectivity issues)

אלו אלמנטים שקצת יותר קשורים למימוש הטכני מאשר להגדרת השימושיות per se.

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

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

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


בהצלחה!


----

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


[ב] בעברית, כמובן, הכיוונים הפוכים.