הפונקציונליות שמתאימה למודול על פי דרישה היא כזו שרוב המשתמשים לא צריכים בזמן ההתקנה. הנה כמה דוגמאות לתכונות באפליקציה שמתאימות למודולים על פי דרישה:
- עריכה והעלאה של סרטון באפליקציה שבה רוב המשתמשים רק צופים בסרטונים
- הוספת מתכון באפליקציה שבה רוב המשתמשים רק מעיינים במתכונים של אחרים ועוקבים אחריהם
- פונקציונליות של עזרה ותמיכה כשרוב המשתמשים לא מחפשים עזרה, או לא מחפשים אותה בתוך האפליקציה
- ספריות גדולות לפונקציונליות פחות נפוצה, כמו תיעוד ודיווח מפורטים על באגים
- יכולות ספציפיות של תשלום או קופה
- חוויות מדיה ברזולוציה גבוהה מאוד או תכונות של מציאות מדומה (VR) או מציאות רבודה (AR)
במקרים הרגילים שבהם המודולים האלה קטנים יחסית (פחות מ-10MB), ואין כשלים ברשת או כשלים אחרים, המשתמשים יכולים להוריד מודול על פי דרישה ולהשתמש בו במהירות רבה. כלומר, בדרך כלל חוויית השימוש לא שונה מאשר אם המודול היה קיים בזמן התקנת האפליקציה.
בדף הזה מפורטות שיטות מומלצות שיעזרו לכם:
- חשוב לוודא שהמשתמשים מודעים להורדות של מודולים גדולים יחסית שלא נטענים באופן מיידי, או לשגיאות בהתקנת מודולים, ושהם מרגישים שהם שולטים בתהליך.
- לשפר עוד יותר את חוויית ההעברה של המודולים, במיוחד במצבים שבהם אתם יכולים לצפות שהמשתמש יצטרך מודול מסוים.
אחרי שתקראו את המדריך הזה, תוכלו לראות את השיטות המומלצות האלה בפעולה על ידי ניסיון של האפליקציה לדוגמה של Play Core API.
עדכון המשתמשים
צריך להודיע למשתמשים אם תכונה מסוימת לא זמינה באופן מיידי. אם המשתמש מחליט להוריד את התכונה מ-Google Play, צריך להציג את התקדמות ההורדה.
אתם יכולים לעקוב אחרי מצב הבקשה כדי להציג את התקדמות ההורדה ואת מצב ההתקנה. עם זאת, סוג ממשק המשתמש שרוצים להציג עשוי להיות תלוי בגודל ההורדה:
- במודולים קטנים יותר (כ-10MB או פחות) שאפשר להתקין במהירות, כדאי להשתמש באינדיקטורים כמו ספינרים או הודעה קצרה כמו "התוכן בהורדה".
- במודולים גדולים יותר, שההורדה וההתקנה שלהם יכולות להימשך כמה שניות או יותר, כדאי להציג סרגל התקדמות של ההורדה וההתקנה, כמו זה שמוצג באיור 1.
איור 1. הצגת הודעה וסרגל התקדמות בזמן הורדה והתקנה של תכונה על פי דרישה
הודעות ברורות על עיכובים וכשלים בהתקנה
אם ההורדה נכשלת או מתקדמת לאט מהצפוי, צריך להסביר למשתמש בצורה ברורה ושקופה מה קורה ומה הוא יכול לעשות, אם בכלל, כמו שמוצג באיורים 2 ו-3. לדוגמה, אם אתם עוקבים אחרי הסטטוס של בקשת ההורדה והאפליקציה מקבלת שגיאה מסוג API_NOT_AVAILABLE, צריך להודיע למשתמש שהמכשיר שלו לא תומך בהורדות על פי דרישה.
איור 2. Let the user know why a feature cannot be installed at this time
איור 3. הסבר למשתמש למה יכול להיות שהורדת התכונה נמשכת יותר זמן מהצפוי
הצגת הערך לפני שמוצגת בקשה לאישור הורדות גדולות
אם מודול לפי דרישה הוא גדול (יותר מ-150MB), Google Play דורש שהמשתמש יאשר את ההורדה לפני שהיא מתחילה.
לפני שאתם מבקשים את המודול, הסבירו למשתמשים מה הערך של המודול. חשוב להסביר למשתמשים למה אתם מבקשים מהם את המידע הזה, בדיוק כמו שאתם מסבירים להם כשאתם מבקשים מהם הרשאות שניתנות לאפליקציה. תקשורת פתוחה עם המשתמשים מגדילה את הסיכוי שהם יאשרו את ההורדה.
לדוגמה, נניח שאתם מפתחים אפליקציית מסחר אלקטרוני, ואחת מהתכונות מאפשרת למשתמשים להציב רהיטים ישירות בדירה שלהם באמצעות מציאות רבודה (AR). אפשר לכלול הודעה כמו "רוצה לראות איך הספה החדשה תיראה ב-Living Room שלך? כדאי להתקין את מציג המציאות הרבודה עכשיו."
הורדה והתקנה ברקע
ההורדה וההתקנה של המודול צריכות תמיד להתבצע ברקע. כלומר, בזמן שהמשתמש ממתין שהתכונה תהיה זמינה, צריך לאפשר לו להמשיך להשתמש בחלקים אחרים של האפליקציה. כשהתכונה זמינה, צריך להציג התראה שמאפשרת למשתמש לעבור להשתמש בתכונה הזו לפי שיקול דעתו.
כפי שמוצג באיור 5, המשתמש ממשיך להשתמש באפליקציה ומקבל התראה כשההתקנה של התכונה על פי דרישה מסתיימת.
איור 5. במקום לשנות את ההקשר של המשתמש באופן פתאומי כשהתקנת המודול מסתיימת, כדאי להודיע למשתמש שהתכונה המבוקשת מוכנה לשימוש.
כשהמודול מוכן לשימוש, מודיעים למשתמש ונותנים לו לבחור אם להפעיל את התכונה. התבנית הזו מספקת למשתמשים הקשר ושליטה על חוויית השימוש שלהם.
במקרים מסוימים, אפשר להשיק את התכונה ברגע שהיא מוכנה. עם זאת, מכיוון שהפעולה הזו עלולה להפריע לחוויית המשתמש, חשוב לשקול היטב אם ההתנהגות הזו צפויה ומתאימה.
פינוי נפח אחסון במכשיר כשמודול מסוים כבר לא נחוץ
אחת היכולות השימושיות של כל המודולים של התכונות היא האפשרות להסיר אותם בנפרד. אם מודול של תכונות כבר לא בשימוש, אתם יכולים להקטין את גודל האפליקציה במכשיר של המשתמש על ידי שליחת בקשה ל-Google Play להסיר את המודול הזה.
לדוגמה, יכול להיות שבאפליקציה יש תהליך מורכב של הצטרפות, אולי עם מדיה עשירה. אחרי שהמשתמש משלים את תהליך ההצטרפות, או אחרי שהוא משתמש פעיל במשך פרק זמן מסוים, אתם יכולים להשתמש ב-API של הפצת פיצ'רים ב-Play כדי לבקש מ-Google Play להסיר רק את הרכיב הזה של האפליקציה.
טיפים מתקדמים
בדרך כלל, צריך לטפל במצבים שבהם המשתמש מציין במפורש שהוא רוצה להשתמש בפונקציונליות של המודולים של התכונות לפי דרישה.
עם זאת, יכול להיות שתרצו לחזות מתי סביר שמשתמש יתעניין בתכונה מסוימת לפני שהוא יאותת לכם שהוא רוצה להשתמש בה. כדי להמחיש איך אפשר לשפר את חוויית ההורדה של המודולים על ידי חיזוי הצרכים של המשתמשים, נשתמש בדוגמה של אפליקציה שמאפשרת להוריד וליצור מתכונים:
לצפות את הצורך של המשתמש בתכונה מסוימת בסשן הנוכחי. לדוגמה, אם המשתמשים צריכים ליצור חשבון באפליקציית המתכונים רק כשהם רוצים ליצור ולשתף מתכונים משלהם עם הקהילה. אתם יכולים להשתמש ביצירת החשבון כאות לכך שהמשתמש כנראה ירצה להוסיף מתכון משלו, ולהתחיל להוריד את מודול התכונות עוד לפני שהמשתמש מקיש על "הוספת מתכון". אפשר ליישם את הגישה הזו גם בתהליכים אחרים שהמשתמשים עוברים באפליקציה, כדי שתהליך ההורדה של התכונה יהיה חלק יותר.
לצפות את הצורך של המשתמש בתכונה בסשן הקרוב. אם אתם לא צריכים שהאפליקציה תוריד ותתקין מיד מודול על פי דרישה, אתם יכולים לדחות את ההתקנה למועד שבו האפליקציה תפעל ברקע, ו-Google Play תטפל בהורדה ובהתקנה בשבילכם. לדוגמה, נניח שאתם רוצים להוסיף לאפליקציית הבישול מתכונים עונתיים חדשים, אבל הם לא בעדיפות גבוהה בסשן הנוכחי של המשתמש. אתם יכולים לבקש מ-Play להוריד ולהתקין את המתכונים האלה כשהאפליקציה פועלת ברקע. האפשרות הזו שימושית במיוחד לתכונות גדולות יותר (>10MB) שלא נדרשות באופן מיידי, אבל סביר להניח שיהיה בהן צורך בעתיד.
לצפות את הצורך של המשתמש בתכונה מסוימת לפני התקנת האפליקציה. כדאי להוסיף תמיכה בהעברה מותנית כדי לכלול את התכונה בזמן ההתקנה, על סמך המדינה של המשתמש, יכולות החומרה של המכשיר ורמת ה-API. לדוגמה, יכול להיות שתרצו לכלול מתכונים עם בשר חזיר במודולים מותנים, ולהשמיט את המודול הזה מהתקנת האפליקציה באזורים שבהם רוב האנשים נמנעים מאכילת בשר חזיר.