המשתמש מקבל הודעה בטלפון: הדלת נפתחה, הסוללה חלשה, המסנן צריך החלפה. מבחוץ זה נראה מיידי ומובן מאליו, אבל התראות push ממוצר חכם הן בפועל שרשרת ארוכה שמתחילה בחיישן ומסתיימת במסך הנעול. כל חוליה בשרשרת יכולה לעכב, לשכפל או לאבד הודעה, ולכן שווה להבין מה קורה מאחורי הקלעים לפני שמבטיחים ללקוחות התראה בזמן אמת. אנחנו בפרוג'קטס האוס מתכננים את המסלול הזה כבר באפיון, כי הוא משפיע על צריכת הסוללה, על עלות הענן ועל חוויית המשתמש.
המסלול המלא של התראה אחת
ההודעה עוברת ארבע תחנות עיקריות. המוצר מזהה אירוע ומחליט שהוא ראוי להתראה. הענן מקבל את האירוע, מאמת אותו ומחליט למי לשלוח. שירות ההפצה של מערכת ההפעלה מעביר את ההודעה למכשיר. האפליקציה מציגה אותה ומטפלת בלחיצה. חשוב להבין נקודה מפתיעה: האפליקציה שלכם אינה זו ששולחת את ההתראה, אלא שירות ההפצה של יצרן מערכת ההפעלה, והוא זה שקובע עדיפויות והשהיות. מכאן שגם אם המוצר והענן עובדים בצורה מושלמת, זמן ההגעה בפועל אינו לגמרי בשליטתכם, ולכן חשוב להגדיר מראש ללקוח מה נחשב זמן תגובה סביר.
- זיהוי האירוע: קושחת המוצר מחליטה מה נחשב חריג, כדי שלא יישלחו עשרות הודעות על אותה תופעה.
- העברה לענן: אם המוצר מחובר ישירות לרשת, האירוע נשלח בפרוטוקול קל משקל. אם הוא מחובר רק לטלפון, ההודעה תלויה בכך שהאפליקציה פעילה.
- החלטת נמענים: לאותו מוצר יכולים להיות כמה משתמשים, כל אחד עם הרשאות והעדפות שונות.
- הצגה במכשיר: טקסט קצר, קטגוריה, צליל ופעולה מהירה כמו "השתקה" או "פתיחת המסך הרלוונטי".
למה התראות מאחרות או נעלמות
הסיבה השכיחה ביותר היא חיסכון בסוללה. מערכות הפעלה מודרניות מקבצות הודעות בעדיפות רגילה ומשחררות אותן בגלים, ואפליקציה שהמשתמש לא פתח שבועות עלולה לקבל יחס נחות. סיבה שנייה היא ארכיטקטורת החיבור: מוצר שמדבר עם הטלפון בלבד לא יכול להתריע כשהמשתמש בחוץ, ולכן חיבור בלוטות' ישיר מתאים לשליטה מקומית אך לא להתראות קריטיות. סיבה שלישית היא הרשאות: משתמש שסירב פעם אחת לא יקבל דבר, והאפליקציה חייבת לזהות זאת ולהסביר. סיבה רביעית, שקל לפספס, היא טוקן שהתיישן: התקנה מחדש של האפליקציה או שחזור מגיבוי מייצרים מזהה חדש, וההודעות ממשיכות להישלח לכתובת מתה עד שהשרת מנקה אותה. בשל כל אלה, התראות push ממוצר חכם אינן ערוץ שאפשר להסתמך עליו לבדו במקרי בטיחות, ולצדן נדרשת גם התראה מקומית במוצר עצמו, למשל זמזם או נורית, וכן סיכום שנשמר באפליקציה כדי שהמשתמש יראה מה קרה גם אם ההודעה לא הופיעה.
מה מתכננים בצד הענן
הענן הוא המקום שבו מוכרעת האמינות. הוא צריך לשמור טוקן לכל מכשיר, לנקות טוקנים שפגו, לנהל תור עם ניסיונות חוזרים ולתעד כל שליחה. בחירת הפרוטוקול בין המוצר לענן קובעת כמה מהר האירוע מגיע, ותכנון השרת והענן למוצר מחובר קובע האם המערכת תחזיק גם כשאלפי מוצרים מדווחים בו זמנית. כדאי לזכור שכל התראה נושאת עלות תפעולית קטנה, ועלות תשתית הענן החודשית גדלה עם מספר המכשירים ותדירות ההודעות. שני מנגנונים שחוסכים הרבה כאב ראש: הגבלת קצב לכל מכשיר, כדי שתקלה בחיישן לא תייצר מאות הודעות בשעה, ומנגנון דעיכה שמפסיק לנסות לשלוח למכשיר שלא הגיב לאורך זמן. גם ניהול אזורי זמן שייך לכאן, כי התראות push ממוצר חכם שנשלחות בשלוש לפנות בוקר בגלל חישוב שגוי הן דרך בטוחה לאבד משתמשים.
כללי אצבע לחוויית משתמש טובה
- לחלק התראות לקטגוריות ולתת למשתמש לכבות כל קטגוריה בנפרד.
- לאחד אירועים חוזרים להודעה אחת מסכמת במקום להציף.
- לכתוב טקסט שמסביר מה קרה ומה לעשות, לא קוד שגיאה.
- למדוד בפועל כמה התראות נשלחו וכמה נפתחו, דרך מדידה ואנליטיקה באפליקציה.
- לבדוק את ההתנהגות גם במצב חיסכון בסוללה, גם כשהאפליקציה סגורה לחלוטין וגם אחרי הפעלה מחדש של הטלפון, לפני העלאת האפליקציה לחנויות.
- לתכנן מראש מה קורה כשהמשתמש מוסר את המוצר לאדם אחר, כדי שההתראות יעברו לבעלים החדש ויפסיקו אצל הקודם.
מידע נוסף על מערכות נלוות למוצרי חומרה מרוכז בעמוד פיתוח אפליקציות. רוצים לתכנן נכון את מנגנון ההתראות של המוצר שלכם? קבעו פגישה ראשונית ונעבור יחד על הארכיטקטורה המתאימה.
רוצים להפוך רעיון למוצר? צרו קשר עם צוות פרוג'קטס האוס בע"מ – טלפון: 054-8936922 | דוא"ל: info@projects-house.com – ונשמח ללוות אתכם משלב הרעיון ועד המדף.
