אפליקציות מסוג Progressive Web Apps (PWA) נבנו ומשופרות יחד עם ממשקי API מודרניים כדי לספק יכולות מתקדמות, אמינות ויכולת התקנה ולהגיע לכל אחד, בכל מקום, מכל מכשיר עם בסיס קוד יחיד. כדי לספק לכם את חוויית השימוש הטובה ביותר, תוכלו להיעזר בהמלצות וברשימת המשימות הליבה והאופטימלית.
רשימת משימות ליבה לאפליקציות אינטרנט מסוג Progressive Web App
ברשימת המשימות ל-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 Enhancement של List Apart הוא מבוא טוב לנושא.
- Progressive Enhancement: What It Is and How To Use It של 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 App
כדי ליצור Progressive Web App מעולה, שנראה כמו אפליקציה הטובה ביותר בתחומן, צריך יותר מאשר רק רשימת המשימות העיקרית. רשימת המשימות האופטימלית לאפליקציות אינטרנט מסוג Progressive Web App היא לגרום ל-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 שהוצאו משימוש, הסרה של דפוסי מניעת גישה באינטרנט מ-codebase (למשל שימוש ב-document.write() או שימוש ברכיבי האזנה לאירועי גלילה לא פסיביים), ואפילו תכנות כדי להבטיח שה-PWA לא ייקטע במקרה של כשל בטעינת Analytics או בספריות צד שלישי אחרות. כדאי לשקול צורך בניתוח של קוד סטטי, כמו איתור שגיאות בקוד (linting) וגם בדיקה אוטומטית, במספר דפדפנים וערוצי הפצה. אפשר להשתמש בשיטות האלה כדי לזהות שגיאות לפני שהן עוברות תהליך ייצור.