דף זה מפרט את ההנחיות ליצירת חוויית משתמש מעולה ברשתות איטיות ובמצב אופליין.
איכות החיבור לרשת יכולה להיות מושפעת מכמה גורמים, למשל:
- כיסוי מצומצם של ספק הרשת.
- תנאי מזג אוויר קיצוניים.
- הפסקות חשמל.
- כניסה ל'אזורים מתים' קבועים, למשל בבניינים עם קירות שחוסמים את החיבורים לרשת.
- הזנת 'אזורים מתים' זמניים, למשל בזמן נסיעה ברכבת ומעבר דרך מנהרה.
- חיבורי אינטרנט לפי תיבת זמן, כמו בנמלי תעופה או במלונות.
- נהלים תרבותיים המצריכים גישה מוגבלת לאינטרנט, או ללא גישה לאינטרנט, בשעות מסוימות או בימים ספציפיים.
המטרה שלכם כמפתחים היא לספק חוויה טובה שמפחיתה את ההשפעה של שינויים בקישוריות.
החלט מה להציג למשתמשים כשהחיבור שלהם לרשת חלש
השאלה הראשונה שצריך לשאול היא איך נראים הצלחה או כשלים בחיבור לרשת באפליקציה שלך. חיבור מוצלח הוא חוויית האינטרנט הרגילה של האפליקציה. הכשל בחיבור כולל את התנהגות האפליקציה במצב אופליין וברשתות ממושכות.
כדי לדעת איך להתמודד עם כשל בחיבור, כדאי לשאול את עצמכם את השאלות החשובות הבאות לגבי חוויית המשתמש:
- כמה זמן אתם מחכים לקבוע אם החיבור הצליח או נכשל?
- מה אפשר לעשות בזמן שקובעים אם הצלחת או כישלון?
- מה לעשות אם החיבור נכשל?
- איך אתם מסבירים למשתמש מה קורה?
הודעה למשתמשים על המצב הנוכחי ועל שינוי המצב שלהם
מודיעים למשתמש גם את מצב האפליקציה וגם אילו פעולות הוא יכול לבצע כשיש תקלה ברשת. לדוגמה, בהודעה עשוי להיות כתוב:
נראה שהחיבור שלך לרשת חלש. אין מה לדאוג! ההודעות יישלחו כשהרשת תשוחזר.
![אפליקציית Emojoy
לשליחת הודעות אמוג'י מיידעת את המשתמש כשמתרחש שינוי במצב.](https://web.dev/static/articles/offline-ux-design-guidelines/image/the-emojoy-emoji-messagin-70c51ef118a7.png?authuser=5&hl=he)
![אפליקציית I/O 2016
מודיעה למשתמשים כשמתרחש שינוי במצב.](https://web.dev/static/articles/offline-ux-design-guidelines/image/the-o-2016-app-informing-f644b43fd92eb.png?authuser=5&hl=he)
הצגת הודעה למשתמשים כשהחיבור לרשת משתפר או משוחזר
האופן שבו מודיעים למשתמש שהחיבור לרשת השתפר תלוי באפליקציה. אפליקציות שמתעדפות מידע עדכני, כמו מזג אוויר או מעקב אחר שוק מניות, צריכות להתעדכן באופן אוטומטי ולהודיע למשתמש על כך בהקדם האפשרי.
מומלץ ליידע את המשתמש שאפליקציית האינטרנט שלכם התעדכנה 'ברקע' על ידי שימוש בסימן חזותי כמו רכיב טוסט של Material Design. התהליך הזה כולל זיהוי הנוכחות של קובץ שירות (service worker) ועדכון של התוכן המנוהל שלו. כאן אתם יכולים לראות דוגמה לקוד של הפונקציה בפעולה.
דוגמה למצב כזה היא סטטוס הפלטפורמה של Chrome, ששולח הערה למשתמש אחרי שהאפליקציה מתעדכנת.
![דוגמה
לאפליקציית מזג אוויר.](https://web.dev/static/articles/offline-ux-design-guidelines/image/an-example-weather-app-656cb36f8252f.png?authuser=5&hl=he)
![הסטטוס של Chrome
משתמש בהודעה קופצת.](https://web.dev/static/articles/offline-ux-design-guidelines/image/chrome-status-uses-toast-0157248fc0b6d.png?authuser=5&hl=he)
באפליקציות מסוימות תמיד אפשר לראות את הפעם האחרונה שבה הן עודכנו. לדוגמה, האפשרות הזו שימושית במיוחד באפליקציות להמרת מטבעות.
![אפליקציית Material
Money לא מעודכנת.](https://web.dev/static/articles/offline-ux-design-guidelines/image/the-material-money-app-be-d96547b7d1b9b.png?authuser=5&hl=he)
![כסף מהותי עודכן.](https://web.dev/static/articles/offline-ux-design-guidelines/image/material-money-has-been-u-1b9996995200f.png?authuser=5&hl=he)
באפליקציות של חדשות, ניתן להציג התראה פשוטה לעדכון המשתמש בנגיעה על תוכן חדש. עדכון אוטומטי של כתבה יגרום למשתמשים לאבד את המקום שלהם.
![דוגמה
לאפליקציית חדשות, החלק האחורי, במצב הרגיל שלה](https://web.dev/static/articles/offline-ux-design-guidelines/image/an-example-news-app-tail-33ace032d408.png?authuser=5&hl=he)
![דוגמה לחלק האחורי של אפליקציית החדשות
כשהיא מוכנה לעדכון](https://web.dev/static/articles/offline-ux-design-guidelines/image/example-news-app-tailpie-a423153089499.png?authuser=5&hl=he)
עדכון ממשק המשתמש כך שישקף את מצב ההקשר הנוכחי
לכל רכיב בממשק המשתמש יכולים להיות הקשר והתנהגות משלו שמשתנים בהתאם לצורך, אם נדרש חיבור מוצלח. דוגמה אחת היא אתר מסחר אלקטרוני שאפשר לגלוש בו אופליין, אבל משבית את התמחור ואת הלחצן 'קנייה' עד שיהיה חיבור מחדש.
סוגים אחרים של מצבים לפי הקשר יכולים לכלול נתונים. לדוגמה, האפליקציה הפיננסית Robinship משתמשת בצבעים ובגרפיקה כדי לעדכן את המשתמש מתי שוק המניות פתוח. כל הממשק הופך ללבן ואז מופיע באפור כשהשוק נסגר. כאשר הערך של מניה מסוימת עולה או יורד, כל ווידג'ט של מניה בודד הופך לירוק או לאדום בהתאם למצב שלו.
הדרכת המשתמש כך שיבינו מהו מודל האופליין
רוב המשתמשים רגילים שיש להם חיבור תמידי לרשת. צריך להסביר להם מה משתנה באפליקציה כשאין להם חיבור. תוכלו להודיע להם איפה נשמרים כמות גדולה של נתונים ולתת להם הגדרות לשנות את התנהגות ברירת המחדל. כדאי להשתמש בכמה רכיבי עיצוב של ממשק המשתמש (למשל שפה אינפורמטיבית, סמלים, התראות, צבעים ותמונות) כדי להעביר את הרעיונות האלה, במקום להסתמך על עיצוב אחד בלבד, כמו סמל בלבד, כדי לספר את כל הסיפור.
מספקים חוויה אופליין כברירת מחדל
אם לאפליקציה לא נדרש הרבה נתונים, כדאי לשמור את הנתונים במטמון כברירת מחדל. התסכול בקרב המשתמשים הולך וגובר אם הם יכולים לגשת לנתונים שלהם רק באמצעות חיבור לרשת.
כדאי לנסות ליצור חוויה יציבה ככל האפשר. חיבור לא יציב גורם לאפליקציה להרגיש לא מהימנה. אפליקציה שמפחיתה את ההשפעה של כשל ברשת מעסיקה את המשתמשים שלה.
אתרי חדשות יכולים להפיק תועלת מהורדה אוטומטית ושמירה אוטומטית של החדשות האחרונות, ואולי שמירת הנתונים על ידי הורדה של הטקסט בלבד, כך שהמשתמש יוכל לקרוא את החדשות של היום ללא חיבור לאינטרנט. אפשר להתאים את ההתנהגות הזו להתנהגות המשתמש, על ידי מתן עדיפות להורדת קטגוריות החדשות שבהן המשתמש צופה הכי הרבה.
![כיסוי האחיזה
משתמש בווידג'טים עיצוביים שונים כדי ליידע את המשתמש שהוא במצב אופליין.](https://web.dev/static/articles/offline-ux-design-guidelines/image/tailpiece-informs-user-3cf8f64ad441c.png?authuser=5&hl=he)
![על רצועת השעון יש אינדיקטור חזותי שמראה אילו קטעים מוכנים לשימוש במצב אופליין.](https://web.dev/static/articles/offline-ux-design-guidelines/image/tailpiece-has-visual-ind-e45dbae7b63c5.png?authuser=5&hl=he)
הודעה למשתמש כאשר האפליקציה מוכנה לצריכה במצב אופליין
כשאפליקציית האינטרנט נטענת בפעם הראשונה, צריך לציין למשתמש אם היא מוכנה לשימוש במצב אופליין. ניתן לעשות זאת באמצעות ווידג'ט שמספק משוב קצר על פעולה דרך הודעה שמוצגת בתחתית המסך, למשל, אחרי שקטע מסוים מסונכרן או הורד קובץ.
חשוב לוודא שהשפה שבה אתם משתמשים מתאימה לקהל שלכם, ולהשתמש באותו ניסוח בכל המקרים שבהם היא רלוונטית. לעיתים קרובות, קהלים לא טכניים לא מבינים את המילה 'אופליין', ובמקום זאת צריך להשתמש בשפה מבוססת-פעולה שהקהל יכול להתחבר אליה.
![אפליקציית I/O במצב אופליין.](https://web.dev/static/articles/offline-ux-design-guidelines/image/io-app-offline-e8851102c8a54.png?authuser=5&hl=he)
![האתר של סטטוס Chrome במצב אופליין.](https://web.dev/static/articles/offline-ux-design-guidelines/image/chrome-status-site-is-off-aa745a23d2117.png?authuser=5&hl=he)
הצגת האפשרות 'שמור למצב לא מקוון' בממשק באופן ברור
אם האפליקציה משתמשת בכמות גדולה של נתונים, חשוב לוודא שיש מתג או סיכה שמוסיפים פריט לשימוש במצב אופליין. תתבצע הורדה אוטומטית של קבצים רק אם משתמש ביקש באופן ספציפי לעשות זאת דרך תפריט ההגדרות. חשוב לוודא שממשק המשתמש של ההצמדה או ההורדה ברור למשתמש ולא מוסתר על ידי רכיבים אחרים בממשק המשתמש.
אחת הדוגמאות לכך היא נגן מוזיקה שצורך קבצים גדולים. המשתמש מודע לעלות הנתונים המשויכת, אבל יכול להיות שהוא גם ירצה להשתמש בנגן במצב אופליין. כדי להוריד מוזיקה לשימוש מאוחר יותר, המשתמשים צריכים לתכנן מראש, אז כדאי להדריך אותם בתהליך ההצטרפות.
מתן הסבר על התכונות שזמינות אופליין
חשוב לתאר באופן ברור את האפשרויות שהעסק מציע. יכול להיות שתצטרכו להציג כרטיסייה או הגדרה עבור 'ספרייה אופליין' או אינדקס תוכן כדי לאפשר למשתמשים לראות מה הם אחסנו במכשיר ומה צריך לשמור. ודאו שההגדרות תמציתיות, ומציינים איפה הנתונים מאוחסנים ולמי יש גישה אליהם.
הצגת העלות בפועל של פעולה
משתמשים רבים משווים בין יכולת אופליין לבין 'הורדה'. משתמשים במדינות שבהן חיבורי רשת נכשלים באופן קבוע או שאינם זמינים משתפים תוכן לעתים קרובות עם משתמשים אחרים, או שומרים תוכן לשימוש במצב אופליין כשיש להם קישוריות.
לפעמים משתמשים בתוכניות נתונים נמנעים מהורדה של קבצים גדולים בגלל חשש לעלות, ולכן כדאי להציג גם עלות משויכת כדי שהמשתמשים יוכלו לבצע השוואה פעילה בין קובץ ספציפי או משימה ספציפית. לדוגמה, אפליקציית המוזיקה שהוזכרה למעלה יכולה לזהות אם המשתמש משתתף בתוכנית נתונים ולהציג את גודל הקובץ כדי לאפשר למשתמש לראות את העלות של קובץ.
מניעת חוויות של פריצה
לעיתים קרובות משתמשים לפרוץ לחוויה מסוימת בלי להיות מודעים לכך שהם עושים אותה. לדוגמה, לפני שהיו קיימות אפליקציות אינטרנט מבוססות-ענן לשיתוף קבצים, משתמשים נהגו לשמור קבצים גדולים ולצרף אותם לאימיילים, כדי שיוכלו להמשיך לערוך אותם ממכשיר אחר. ממשק משתמש טוב פותר את הבעיה שמשתמשים מנסים לפתור בלי להיחשף לחוויית הפריצה. לדוגמה, ניתן לשתף קבצים גדולים בין מכשירים במקום לצרף קבצים גדולים לאימיילים, כדי שיהיה ידידותי יותר למשתמש.
איך להעביר את החוויות בין מכשירים
כשאתם עובדים עם רשתות רעות, נסו לסנכרן ברגע שהחיבור ישתפר כדי שניתן יהיה להעביר את החוויה. לדוגמה, נניח שאפליקציית נסיעות מאבדת את החיבור לרשת באמצע ביצוע ההזמנה. כשהחיבור יחודש, האפליקציה תסתנכרן עם החשבון של המשתמש. כך המשתמש יוכל להמשיך את ההזמנה במחשב וכך לתת למשתמשים חוויה חלקה.
צריך ליידע את המשתמש באיזה מצב הנתונים שלו נמצאים. לדוגמה, אפשר להראות אם האפליקציה הסתנכרנה. למדו אותם במידת האפשר, אך השתדלו לא להציף אותם ביותר מדי מסרים.
יוצרים חוויות עיצוב שמעודדות את קבלת האחר
כשאתם מתכננים את חוויית המשתמש, חשוב לכלול את התוכן שלכם בצורה שמעודדת את קבלת האחר, ולהציג מכשירים בעלי משמעות, שפה פשוטה, איקונוגרפיה סטנדרטית ותמונות משמעותיות, שינחו את המשתמשים להשלים את הפעולה או המשימה בלי להפריע.
להשתמש בשפה פשוטה וברורה
חוויית משתמש טובה היא לא רק עיצוב הממשק. הרשימה כוללת את הנתיב שהמשתמשים עוברים באפליקציה שלכם, וכל מה שהוא נתקל בו לאורך הדרך, כולל השפה שבה האפליקציה משתמשת כדי לתאר את התהליך. בהסבר על רכיבי ממשק המשתמש או על מצב האפליקציה, חשוב להימנע מז'רגון טכנולוגי. לעתים קרובות, המילה 'אופליין' לא תמיד ברורה מספיק כדי ליידע את המשתמש מה האפליקציה עושה.
![סמל של קובץ שירות (service worker) הוא דוגמה לא טובה.](https://web.dev/static/articles/offline-ux-design-guidelines/image/a-service-worker-icon-is-9ab93716e75ef.png?authuser=5&hl=he)
![דוגמה טובה לכך היא סמל ההורדה.](https://web.dev/static/articles/offline-ux-design-guidelines/image/a-download-icon-is-good-53eec1dd7a257.png?authuser=5&hl=he)
שימוש במכשירים מרובים ליצירת חוויות משתמש נגישות
שימוש בשפה, בצבע וברכיבים חזותיים כדי להראות סטטוס או שינוי מצב. למשתמשים עם מוגבלויות ראייה קשה להבחין בשימוש רק בצבע בלבד, או אפילו לא נגיש בכלל. בנוסף, מכיוון שעיצוב אתרים נוטה להשתמש באפור לאלמנטים מושבתים, שימוש בממשק משתמש אפור שמראה שהאפליקציה במצב אופליין עלול לגרום לבלבול לגבי הפעולות שהאפליקציה יכולה לעשות במצב אופליין, במיוחד אם משתמשים רק בצבע כדי להציג את המצב.
כדי למנוע אי-הבנות, אפשר להביע למשתמש את מצב האפליקציה במספר דרכים, למשל באמצעות צבע, תוויות ורכיבים בממשק המשתמש.
![דוגמה טובה שמשתמשת בצבע ובטקסט כדי להציג שגיאה.](https://web.dev/static/articles/offline-ux-design-guidelines/image/a-example-uses-color-t-d090f90d2476a.png?authuser=5&hl=he)
![דוגמה לא טובה שמשתמשת בצבע בלבד.](https://web.dev/static/articles/offline-ux-design-guidelines/image/a-bad-example-using-colo-8e9dd82778ffc.png?authuser=5&hl=he)
שימוש בסמלים שמעבירים משמעות
הקפידו להשתמש בתוויות טקסט בעלות משמעות לצד הסמלים. סמלים בלבד יכולים לבלבל, במיוחד כי המושג 'אופליין' באינטרנט הוא חדש יחסית. מקרים אחרים של סמלים מבלבלים כוללים שימוש בדיסק און קי כדי לייצג את ערך השמירה, שיכול להיות חסר משמעות למשתמשים צעירים שלא ראו דיסקטונים, וכן בסמל התפריט 'המבורגר'.
כשמשיקים סמל אופליין, חשוב להקפיד על עקביות ברכיבים החזותיים המקובלים בתחום, ולהוסיף תווית טקסט ותיאור. לדוגמה, אפשר להשתמש בסמל הורדה כדי לבצע שמירה למצב אופליין, סמל סנכרון לפעולה שכוללת סנכרון. חשוב להיזהר כשמשתמשים בסמלים כדי להדגים סטטוס שעשוי להתפרש כפעולת שמירה או הורדה.
![דוגמאות שונות לסמלים שמעבירים למצב אופליין](https://web.dev/static/articles/offline-ux-design-guidelines/image/various-icon-examples-co-a2e7adbcf4246.png?authuser=5&hl=he)
לקבלת השראה נוספת, כדאי לעיין בערכת הסמלים של Material Design.
שימוש בפריסות שלד ובמנגנוני משוב אחרים
בזמן שהאפליקציה טוענת תוכן, הראו לו שהיא נטענת כדי שלא יחשבו שהיא שבורה. אחת הדרכים לעשות זאת היא באמצעות פריסת שלד, גרסת Wireframe של האפליקציה שמוצגת בזמן טעינת התוכן. כדאי גם להשתמש בממשק משתמש של טעינה מראש עם תווית טקסט שמודיעה למשתמש שהאפליקציה נטענת, או באנימציה מהבהבת עדינה של ה-wireframe כדי לתת תחושה שהיא חיה ונטענת. כך המשתמשים יכולים להיות בטוחים שמשהו קורה, ולמנוע שליחה חוזרת או רענון מיותרים.
![דוגמה לפריסת שלד.](https://web.dev/static/articles/offline-ux-design-guidelines/image/a-skeleton-layout-example-be82e48f16f75.png?authuser=5&hl=he)
![דוגמה לכתבה שנטענה.](https://web.dev/static/articles/offline-ux-design-guidelines/image/a-loaded-article-example-daa80c34d8194.png?authuser=5&hl=he)
שליחת משוב כדי להראות את המצב של הפעולה. לדוגמה, אם משתמש עורך מסמך אופליין, כדאי לשנות את עיצוב המשוב כדי שניתן יהיה לראות אותו כשהוא מחובר לאינטרנט, אבל עדיין יראה שהקובץ שלו "נשמר" ויסונכרן כשיהיה חיבור לרשת. כך המשתמשים יכולים לדעת איך האפליקציה פועלת ולוודא שהמשימה או הפעולה שלהם נשמרו, מה שיכול להגביר את הביטחון שלהם בשימוש באפליקציה.
לא לחסום תוכן
בחלק מהאפליקציות, המשתמש עשוי להפעיל פעולה כמו יצירת מסמך חדש. אפליקציות מסוימות מנסות להתחבר לשרת כדי לסנכרן את המסמך החדש ולהדגים זאת, הן מציגות תיבת דו-שיח מודאלית שמקדמת את כל המסך. האפשרות הזו יכולה לפעול אם למשתמש יש חיבור יציב לרשת, אבל אם הרשת לא יציבה, הוא לא יוכל לברוח מהפעולה הזו, ולכן ממשק המשתמש לא מאפשר לו לבצע פעולות אחרות.
נמנעים מבקשות מהרשת שחוסמות תוכן. המשתמש יכול להמשיך לעיין במשימות של האפליקציה והתור, שיבוצעו ויסונכרנו כשהחיבור ישתפר.
עיצוב שמותאם למיליארד הבא
באזורים רבים מכשירים פשוטים הם נפוצים, הקישוריות לא אמינה ולמשתמשים רבים הנתונים יקרים במיוחד. כדי לזכות באמון המשתמשים, מומלץ להיות שקופים וחסכוניים בנתונים. נסו לחשוב על דרכים שיעזרו למשתמשים עם חיבורים גרועים והממשק שלהם יהיה פשוט יותר, כדי לזרז את המשימות. תמיד נסו לשאול את המשתמשים לפני שהם מורידים תוכן עתיר נתונים.
להציע אפשרויות של רוחב פס נמוך למשתמשים בחיבורים בעלי עיכוב. ניתן לספק נכסים קטנים יותר בחיבורי רשת איטיים יותר, או להציע אפשרות לבחור נכסים באיכות גבוהה או באיכות נמוכה.
סיכום
השכלה היא מרכיב חשוב בחוויית המשתמש אופליין כי המשתמשים לא מכירים אותה. כדי לעזור להם ללמוד, כדאי לנסות ליצור שיוכים למושגים מוכרים, למשל להסביר שהורדה לשימוש במועד מאוחר יותר זהה להורדה של נתונים למצב אופליין.
כשמתכננים חיבורי רשת לא יציבים, חשוב לזכור את ההנחיות הבאות:
- עיצוב שיבטיח הצלחה, כישלון וחוסר יציבות בחיבור לרשת.
- נתונים יכולים להיות יקרים, לכן צריך להתחשב במשתמשים.
- עבור רוב המשתמשים ברחבי העולם, הסביבה הטכנית היא כמעט בלעדית לנייד.
- מכשירים פשוטים הם דבר נפוץ, עם נפח אחסון, זיכרון ועיבוד מוגבלים, מסכים קטנים ואיכות מסך מגע נמוכה יותר. ודאו שהביצועים הם חלק מתהליך העיצוב שלכם.
- אפשר למשתמשים לדפדף באפליקציה כשהם במצב אופליין.
- צריך ליידע את המשתמשים לגבי המצב הנוכחי שלהם ולגבי שינויים במצבים.
- אם האפליקציה לא צריכה נתונים רבים, כדאי לנסות לספק נתונים במצב אופליין כברירת מחדל.
- אם האפליקציה עמוסה בנתונים, נסביר למשתמשים איך הם יכולים להוריד אותם כדי להשתמש בהם במצב אופליין.
- חשוב לאפשר למשתמשים להעביר את החוויות בין מכשירים.
- השתמשו בשפה, בסמלים, בתמונות, בטיפוגרפיה ובצבע יחד כדי לבטא רעיונות למשתמשים.
- לספק תחושת ביטחון ומשוב כדי לעזור למשתמש.