איך יוצרים אפליקציה מוצלחת מסוג Progressive Web App?

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

סיבה

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

כל אפליקציה דורשת צרכים שונים, אבל ביקורות הביצועים ב-Lighthouse מבוססות על דוח ה-Web Vitals הבסיסיים, וציונים גבוהים בביקורות האלה יגדילו את הסיכוי שהמשתמשים ייהנו מחוויית שימוש טובה. אפשר גם להשתמש ב-PageSpeed Insights או בדוח חוויית המשתמש ב-Chrome כדי לקבל נתוני ביצועים בפועל של אפליקציית האינטרנט.

איך

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

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

סיבה

אפליקציות Progressive Web App הן קודם כול אפליקציות אינטרנט, ולכן הן צריכות לפעול בכל הדפדפנים.

דרך יעילה לעשות זאת היא, לדברי ג'רמי קית' (Jeremy Keith) במאמר עיצוב אינטרנט עמיד, לזהות את התכונות המרכזיות, להפוך אותן לזמינות באמצעות הטכנולוגיה הפשוטה ביותר, ולאחר מכן לשפר את החוויה במידת האפשר. במקרים רבים, המשמעות היא להתחיל רק עם HTML כדי ליצור את התכונות המרכזיות, ולשפר את חוויית המשתמש באמצעות CSS ו-JavaScript כדי ליצור חוויה מרתקת יותר.

ניקח לדוגמה שליחת טופס. הדרך הפשוטה ביותר להטמיע את זה היא באמצעות טופס HTML ששולח בקשת POST. אחרי שתיצרו את הטופס, תוכלו לשפר את חוויית השימוש באמצעות JavaScript כדי לבצע אימות של הטופס ולשלוח אותו באמצעות AJAX, וכך לשפר את חוויית השימוש למשתמשים שיכולים לתמוך בכך.

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

איך

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

מקורות מידע נוספים

• המאמר Understanding Progressive Enhancement באתר A List Apart הוא מבוא טוב לנושא.
• שיפור הדרגתי: מה זה ואיך משתמשים בו? נותן מבוא מעשי וקישורים לנושאים מתקדמים יותר.
• במאמר הטמעת זיהוי תכונות ב-MDN מוסבר איך לזהות תכונה על ידי שליחת שאילתות ישירות אליה.

המשתמשים יכולים להשתמש באפליקציית ה-PWA בכל גודל מסך, וכל התוכן שלה זמין בכל גודל שדה צפייה.

סיבה

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

המשימות שהמשתמשים רוצים להשלים והתוכן שהם רוצים לגשת אליו לא משתנים בהתאם לגודל אזור התצוגה. אתם יכולים לסדר מחדש את התוכן בהתאם לגדלים שונים של אזור התצוגה, והוא אמור להופיע בכל מקרה. למעשה, כפי שציין Luke Wroblewski בספר שלו Mobile First, אפשר לשפר את העיצוב של האתר אם מתחילים בקטן ומתאימים את העיצוב למסכים גדולים יותר:

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

איך

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

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

סיבה

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

איך

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

משתמשים שמתקינים או מוסיפים אפליקציות למכשיר שלהם נוטים ליצור אינטראקציה עם האפליקציות האלה יותר.

סיבה

התקנה של אפליקציית Progressive Web App מאפשרת לה להיראות, להרגיש ולהתנהג כמו כל האפליקציות האחרות שמותקנות. היא מופעלת מאותו מקום שבו המשתמשים פותחים את האפליקציות האחרות שלהם. היא פועלת בחלון אפליקציה נפרד מהדפדפן, ומופיעה ברשימת המשימות כמו אפליקציות אחרות.

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

איך

במדריך הזה מוסבר איך להפוך את אפליקציית ה-PWA לניתנת להתקנה.

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

סיבה

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

איך

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

כל האינטראקציות של המשתמשים עומדות בדרישות הנגישות של WCAG 2.0.

סיבה

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

איך

מבוא לנגישות באינטרנט של W3C הוא מקום טוב להתחיל בו. רוב בדיקות הנגישות צריכות להתבצע באופן ידני. כלים כמו הבדיקות של נגישות ב-Lighthouse,‏ axe ו-Accessibility Insights יכולים לעזור לכם לבצע אוטומציה של חלק מבדיקות הנגישות. חשוב גם להשתמש ברכיבים נכונים מבחינה סמנטית במקום ליצור מחדש את הרכיבים האלה בעצמכם, למשל רכיבי a ו-button. כך תוכלו לוודא שבמקרים שבהם תצטרכו לפתח תכונות מתקדמות יותר, הן יעמדו בדרישות הנגישות (למשל, מתי להשתמש בחצים ומתי בכרטיסיות). בכרטיסי התזונה של A11Y יש עצות מצוינות בנושא הזה לגבי כמה רכיבים נפוצים.

אפשר לגלות את האפליקציה לנייד באינטרנט בקלות.

סיבה

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

איך

קודם כול, חשוב לוודא שלכל כתובת URL יש שם תיאורי ייחודי ותיאור מטא. לאחר מכן תוכלו להשתמש ב-Google Search Console ובבדיקות האופטימיזציה למנועי חיפוש ב-Lighthouse כדי לנפות באגים ולפתור בעיות של ניראות ב-PWA. אפשר גם להשתמש בכלים של בעלי האתרים ב-Bing או ב-Yandex, ולשקול לכלול ב-PWA נתונים מובְנים באמצעות סכימות מ-Schema.org.

אפשר להשתמש באפליקציית ה-PWA בעזרת עכבר, מקלדת, סטיילוס או מסך מגע.

סיבה

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

איך

Pointer Events API מספק ממשק מאוחד לעבודה עם אפשרויות קלט שונות, והוא מתאים במיוחד להוספת תמיכה בעט. כדי לתמוך גם במגע וגם במקלדת, חשוב להשתמש באלמנטים הסמנטיים הנכונים (עוגנים, לחצנים, פקדי טפסים וכו') ולא ליצור אותם מחדש באמצעות HTML לא סמנטי. כשאתם מוסיפים אינטראקציות שמופעלות במעבר עם העכבר, חשוב לוודא שהן יכולות לפעול גם בלחיצה או בהקשה.

כשמבקשים הרשאה להשתמש בממשקי API מתקדמים, צריך לספק הקשר ולבקש רק כשיש צורך ב-API.

סיבה

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

איך

המאמר חוויית משתמש של בקשות הרשאה והמאמר הדרכים הנכונות לבקש מהמשתמשים הרשאות ב-UX Planet הם מקורות מידע טובים שיעזרו לכם להבין איך לעצב בקשות הרשאה שמתמקדות בניידים, אבל רלוונטיות לכל אפליקציות ה-PWA.

שמירה על קוד תקין תעזור לכם להשיג את היעדים שלכם ולהוסיף תכונות חדשות.

סיבה

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

איך

יש כמה בדיקות בעדיפות גבוהה שמטרתן לוודא שקוד הבסיס תקין:

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