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

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

סיבה

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

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

איך

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

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

סיבה

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

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

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

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

איך

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

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

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

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

סיבה

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

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

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

איך

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

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

סיבה

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

איך

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

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

סיבה

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

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

איך

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

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

סיבה

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

איך

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

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

סיבה

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

איך

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

אפשר לגלות את ה-PWA בקלות באמצעות החיפוש.

סיבה

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

איך

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

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

סיבה

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

איך

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

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

סיבה

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

איך

המאמר Permission UX ו-TheRight Ways to Ask Users for Permissions של UX Planet הם מקורות מידע טובים שיעזרו לכם להבין כיצד לעצב בקשות הרשאה, שמתייחסות לניידים, חלות על כל אפליקציות ה-PWA.

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

סיבה

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

איך

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