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

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

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

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

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

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

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

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

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

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

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

בהצלחה!

—-

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