אפליקציות Progressive Web Apps (PWA) נוצרות ומשופרות באמצעות ממשקי API מודרניים כדי לספק יכולות, אמינות ואפשרות התקנה משופרות, תוך הגעה לכולם, בכל מקום ובכל מכשיר באמצעות קוד בסיס יחיד. כדי לעזור לכם ליצור ולספק את החוויה הטובה ביותר, וגם המלצות.
רשימת משימות ל-Progressive Web App ליבה
ברשימת המשימות ל-Progressive Web App מוסבר מהם הקריטריונים שצריך לעמוד בהם כדי שכל המשתמשים יוכלו להתקין את האפליקציה ולהשתמש בה, ללא קשר לגודל או לסוג הקלט.
לביצועים יש תפקיד חשוב בהצלחת כל פלטפורמה מאחר שאתרים עם ביצועים גבוהים מעוררים עניין בקרב המשתמשים ושומרים עליהם יותר טוב מאשר אלה שמניבות ביצועים נמוכים. להתמקד באופטימיזציה לפי מדדי ביצועים שמתמקדים במשתמשים.
סיבה
מהירות היא גורם קריטי שמשפיע על היכולת של המשתמשים להשתמש באפליקציה. למעשה, ככל שזמן הטעינה של הדף מתארך משנייה אחת לעשר שניות, ההסתברות שהמשתמש יעזוב מהדף הראשון עולה ב-123%. הביצועים לא מפסיקים גם עם האירוע load. המשתמשים לא צריכים לתהות
אם האינטראקציה שלהם (לדוגמה לחיצה על לחצן) הייתה
רשום או לא. הגלילה והאנימציה צריכות להיות חלקות.
הביצועים משפיעים על כל חוויית השימוש, גם באופן שבו האפליקציה
מתנהגת ואיך המשתמשים תופסים אותו.
כל אפליקציה דורשת צרכים שונים, אבל ביקורות הביצועים ב-Lighthouse מבוססות על מדדי Web Vitals הבסיסיים. ציון גבוה בביקורות האלה יעלה את הסיכוי של המשתמשים ליהנות מחוויית שימוש טובה. אפשר גם להשתמש ב-PageSpeed Insights או בדוח חוויית המשתמש ב-Chrome כדי לקבל נתוני ביצועים בפועל של אפליקציית האינטרנט.
איך
צריך לפעול לפי המדריך לזמני טעינה מהירים כדי כאן תלמדו איך לגרום ל-PWA להתחיל במהירות ולהישאר במהירות.
המשתמשים יכולים להשתמש בכל דפדפן שהם בוחרים כדי לגשת לאפליקציית האינטרנט לפני שהוא מותקנת.
סיבה
Progressive Web Apps הן קודם אפליקציות אינטרנט, ולכן הן צריכות לפעול בדפדפנים שונים.
דרך יעילה לעשות זאת היא, לדברי ג'רמי קית' Resilient Web Design, לזיהוי התכונות העיקריות, והפיכת התכונות האלה לזמינות באמצעות הטכנולוגיה הפשוטה ביותר האפשרית, ואז משפרים את כשאפשר. במקרים רבים צריך להתחיל רק עם HTML כדי ליצור את התכונות העיקריות, ולשפר את חוויית המשתמש עם שירותי CSS ו-JavaScript יכולים לספק חוויה מעניינת יותר.
לדוגמה, אפשר לשלוח טופס. הדרך הפשוטה ביותר להטמיע אותה היא
טופס HTML ששולח בקשה מסוג POST. אחרי הבנייה
כדי לשפר את החוויה עם JavaScript כדי ליצור
אימות ושליחה של הטופס באמצעות AJAX, שיפור החוויה
למשתמשים שיכולים לתמוך בו.
המשתמשים חווים את האתר שלכם במגוון רחב של מכשירים בדפדפנים אחרים. אי אפשר להתמקד רק בקצה העליון של כל הספקטרום הזה. כדאי להשתמש בזיהוי תכונות כדי לספק חוויית שימוש נוחה למגוון רחב ככל האפשר של משתמשים פוטנציאליים, כולל משתמשים שמשתמשים בדפדפנים ובמכשירים שעדיין לא קיימים.
איך
Resilient Web Design של Jeremy קית' הוא מקור מידע מצוין שמתאר איך לחשוב על עיצוב אתרים את המתודולוגיה הזו, שפועלת בדפדפנים שונים.
מקורות מידע נוספים
- המאמר Understanding Progressive Enhancement באתר A List Apart הוא מבוא טוב לנושא.
- כתבי עת ל-Smashing שיפור הדרגתי: מה זה ואיך להשתמש בו? הקדמה מעשית וקישורים לנושאים מתקדמים יותר.
- במאמר הטמעת זיהוי תכונות ב-MDN מוסבר איך לזהות תכונה על ידי שליחת שאילתות ישירות אליה.
המשתמשים יכולים להשתמש באפליקציית ה-PWA בכל גודל מסך, וכל התוכן שלה זמין בכל גודל של אזור תצוגה.
סיבה
יש מכשירים בגדלים שונים, והמשתמשים יכולים להשתמש באפליקציה שלכם בגדלים שונים, גם באותו מכשיר. לכן חשוב מאוד לוודא שלא רק התוכן שלך מתאים לאזור התצוגה, אלא שכל ניתן להשתמש בתכונות ובתוכן של האתר שלך בכל הגדלים.
המשימות שהמשתמשים רוצים להשלים והתוכן שהם רוצים לגשת אליו לא משתנים בהתאם לגודל אזור התצוגה. אתם יכולים לסדר מחדש את התוכן בהתאם לגדלים שונים של אזור התצוגה, והוא אמור להופיע בכל מקרה. למעשה, כפי שלוק ורולבסקי אומר בספרו Mobile First, החל בקטן ושינוי העיצוב למסכים גדולים יותר יכול לשפר את עיצוב האתר:
מכשירים ניידים מחייבים את צוותי פיתוח התוכנה להתמקד רק את הפעולות והנתונים החשובים ביותר באפליקציה. יש פשוט אין מקום במסך של 320 על 480 פיקסלים מיותר רכיבים. צריך לתת להם עדיפות.
איך
יש משאבים רבים על עיצוב רספונסיבי, כולל מקורי מאמר מאת איתן מרקוט, שמבוסס על קונספטים חשובים שקשורים אליו, וגם ספרים ושפע שיחות. כדי לצמצם את הדיון הזה להיבטים של תוכן בעיצוב רספונסיבי, כדאי לעיין במאמרים עיצוב שמתמקד בתוכן ופריסות רספונסיביות שמתמקדות בתוכן. לבסוף, כשמתמקדים בנייד, השיעורים שבעה מיתוסים על ניידים קטלניים מאת ג'וש קלארק רלוונטיות לא פחות לתצוגות קטנות של אתרים, כפי שהם שמתאימים לניידים באופן כללי.
כשמשתמשים נמצאים במצב אופליין, כדאי להשאיר אותם באפליקציית ה-PWA כדי לספק להם חוויית משתמש חלקה יותר מאשר להחזיר אותם לדף ברירת המחדל של הדפדפן במצב אופליין.
סיבה
המשתמשים מצפים שהאפליקציות המותקנות יפעלו ללא קשר לסטטוס החיבור שלהם. אפליקציה ספציפית לפלטפורמה אף פעם לא מציגה דף ריק כשהיא אופליין, ואף פעם לא צריך להציג באפליקציית PWA את הדף שמוגדר כברירת מחדל בדפדפן במצב אופליין. מתן חוויה מותאמת אישית במצב אופליין, גם כשהמשתמש מנווט אל שלא נשמרה במטמון וכשמשתמש מנסה להשתמש בתכונה נדרש חיבור לאינטרנט, וחוויית השימוש באינטרנט תרגיש חלק המכשיר שבו היא פועלת.
איך
במהלך האירוע install של Service Worker, ניתן לשמור מראש במטמון
דף מותאם אישית במצב אופליין שיוצג כשמשתמש עובר למצב אופליין. במאמר יצירת דף חלופי אופליין מוסבר איך להטמיע את התכונה בעצמכם. חשוב לזכור ש-Chrome
מציגים דף בסיסי אופליין אם לא צוין דף כזה.
משתמשים שמתקינים או מוסיפים אפליקציות למכשיר נוטים לגלות מעורבות ועוד.
סיבה
התקנה של אפליקציית Progressive Web App מאפשרת לה להיראות, להרגיש ולהתנהג כמו כל האפליקציות האחרות שמותקנות. הוא הושק מאותו מקום שבו המשתמשים משיקים את האפליקציות האחרות שלהם. היא פועלת בחלון אפליקציה משלה, בנפרד והוא יופיע ברשימת המשימות, בדיוק כמו אפליקציות אחרות.
בדומה לאפליקציות ספציפיות למכשיר, המשתמשים שמתקינים את האפליקציות שלכם הם הקהל הכי מעורב, ולרוב מדדי ההתעניינות שלהם זהים לאלה של משתמשי האפליקציה במכשירים ניידים. המדדים האלה כוללים יותר ביקורים חוזרים, זמן שהייה ארוך יותר באתר ושיעורי המרה גבוהים יותר בהשוואה למבקרים רגילים.
איך
לפעול לפי המדריך להתקנה כדי ללמוד איך ליצור PWA להתקנה.
רשימת משימות לאופטימיזציה של Progressive Web App
כדי ליצור אפליקציית PWA מעולה באמת, כזו שתרגישו שהיא האפליקציה הטובה ביותר בתחומה, צריך יותר מאשר רק את רשימת המשימות הבסיסית. רשימת המשימות האופטימלית של PWA נועדה נראה שה-PWA היא חלק מהמכשיר שבו היא פועלת בזמן שמפעילים של מה שהופך את האינטרנט לעוצמתי.
במקרים שבהם אין צורך חיוני בחיבור, האפליקציה פועלת אופליין בדיוק כמו שהיא פועלת אונליין.
סיבה
בנוסף לספק דף אופליין מותאם אישית, המשתמשים מצפים שאפליקציות PWA יהיו שאפשר להשתמש בו במצב אופליין. לדוגמה, אפליקציות של נסיעות וטיסות צריכות לכלול נסיעות הפרטים וכרטיסי העלייה למטוס זמינים באופן מיידי כשהם במצב אופליין. מוזיקה, באפליקציות של סרטונים ופודקאסטים צריך לאפשר הפעלה במצב אופליין. רשתות חברתיות ו אפליקציות של חדשות צריכות לשמור תוכן אחרון במטמון כדי שמשתמשים יוכלו לקרוא אותו במצב אופליין. המשתמשים גם מצפים שהאימות יישאר בתוקף במצב אופליין, לכן כדאי לתכנן את המערכת כך שתאפשר אימות במצב אופליין. אפליקציית PWA אופליין מספקת למשתמשים חוויה אמיתית של אפליקציה.
איך
אחרי שתבחרו אילו תכונות המשתמשים מצפים שיפעלו במצב אופליין, תצטרכו להפוך את התוכן שלכם לזמין ולהתאים אותו להקשרים אופליין. אפשר להשתמש ב-IndexedDB, מערכת אחסון מסוג NoSQL בדפדפן, כדי לאחסן ולשלוף נתונים, ובסנכרון ברקע כדי לאפשר למשתמשים לבצע פעולות במצב אופליין ולדחות את התקשורת עם השרת עד שהמשתמש יקבל שוב חיבור יציב. אפשר גם להשתמש בשירות עובדים לאחסון סוגים אחרים של תוכן, כמו תמונות, קובצי וידאו וקובצי אודיו, לשימוש אופליין ולהטמעה סשנים בטוחים לטווח ארוך כדי לשמור על האימות של המשתמשים. מנקודת מבט של חוויית משתמש, אתה יכול להשתמש ב- מסכי שלד שמאפשרות למשתמשים להבין את המהירות ואת התוכן בזמן הטעינה, ואז חוזרים לתוכן שנשמר במטמון או לאינדיקטור של מצב אופליין, לפי הצורך.
כל האינטראקציות של המשתמשים עומדות בדרישות הנגישות של WCAG 2.0.
סיבה
רוב המשתמשים, בשלב כלשהו בחיים שלהם, רוצים להשתמש ב-PWA באופן כלשהו מכוסה במסגרת WCAG 2.0 דרישות בנושא נגישות. יכולת האינטראקציה של בני אדם עם אפליקציית ה-PWA שלכם וההבנה שלה משתנה, והצרכים יכולים להיות זמניים או קבועים. כשהופכים את PWA לנגישה, אפשר להשתמש בה לכולם.
איך
מבוא לנגישות באינטרנט של W3C הוא מקום טוב להתחיל בו. רוב בדיקות הנגישות צריכות להתבצע באופן ידני. כלים כמו הבדיקות של נגישות ב-Lighthouse, axe ו-Accessibility Insights יכולים לעזור לכם להפוך חלק מבדיקות הנגישות לאוטומטיות. חשוב גם להשתמש ברכיבים סמנטיים נכונים במקום ליצור אותם מחדש בעצמכם, למשל רכיבי a ו-button. כך מובטחות וכשתצטרכו ליצור אמצעים מתקדמים יותר
תכונות הנגישות, מתקיימות ציפיות הנגישות (למשל מתי להשתמש בחיצים
לעומת טאבים).
בכרטיסי התזונה של A11Y יש טיפים מעולים בנושא הזה לגבי כמה רכיבים נפוצים.
אפשר לגלות את האפליקציה ל-PWA בקלות בחיפוש.
סיבה
אחד מהיתרונות הגדולים ביותר של האינטרנט הוא היכולת לגלות אתרים ואפליקציות באמצעות חיפוש. למעשה, יותר ממחצית מכלל התנועה באתר מגיעה מחיפוש אורגני. מוודאים קיימות כתובות URL קנוניות עבור התוכן, ומנועי חיפוש יכולים להוסיף את הדפים האתר הוא קריטי כדי לאפשר למשתמשים פוטנציאליים למצוא את ה-PWA. זה נכון במיוחד כשעוברים לעיבוד מצד הלקוח.
איך
תחילה מוודאים שלכל כתובת URL יש כותרת תיאורית וייחודית מטא-תיאור. לאחר מכן תוכלו להשתמש ב-Google Search Console ובבדיקות האופטימיזציה למנועי חיפוש ב-Lighthouse כדי לנפות באגים ולפתור בעיות של ניראות ב-PWA. תוכלו גם להשתמש בכלים של בעלי האתרים ב-Bing או ב-Yandex, ולשקול לכלול ב-PWA נתונים מובְנים באמצעות סכימות מ-Schema.org.
אפשר להשתמש ב-PWA באופן שווה באמצעות עכבר, מקלדת, סטיילוס או מגע.
סיבה
מכשירים מציעים מגוון שיטות קלט, והמשתמשים אמורים להיות מסוגלים לעבור ביניהם בצורה חלקה במהלך השימוש באפליקציה. בדיוק כמו חשוב מאוד ששיטות הקלט לא יהיו תלויות בגודל המסך אזורי תצוגה גדולים חייבים לתמוך במגע, ואזורי תצוגה קטנים חייבים לתמוך מקלדות ועכברים. כמיטב יכולתך, עליך לוודא היישום וכל התכונות שלו תומכים בשימוש בכל שיטת קלט יכול להיות שהמשתמש יבחר. במקרים המתאימים, משפרים את החוויות כדי לאפשר גם פקדים ספציפיים לקלט (כמו משיכה לרענון).
איך
Pointer Events API מספק ממשק מאוחד לעבודה עם אפשרויות קלט שונות, והוא מתאים במיוחד להוספת תמיכה בעט. כדי לתמוך גם במגע וגם במקלדת, חשוב להשתמש באלמנטים הסמנטיים הנכונים (עוגנים, לחצנים, רכיבי בקרה בטופס וכו') ולא ליצור אותם מחדש באמצעות HTML לא סמנטי. כשכוללים אינטראקציות שמופעלות כשמעבירים את העכבר מעליהן, ודאו שהם יכולים לפעול גם בלחיצה או בהקשה.
כשמבקשים הרשאה לשימוש בממשקי API חזקים, צריך לספק הקשר ולבקש רק כשה-API נדרש.
סיבה
ממשקי API שמפעילים בקשה להרשאה, כמו התראות, מיקום גיאוגרפי ופרטי כניסה, תוכננו בכוונה כך שיפריעו למשתמש, כי הם בדרך כלל קשורים לתכונות חזקות שדורשות הסכמה מפורשת. הפעלת ההנחיות האלה ללא הקשר נוסף, כמו בזמן טעינת דף, מפחית את הסבירות שמשתמשים יאשרו את ההרשאות האלה, אפשר לסמוך עליהם בעתיד. במקום זאת, הפעילו את ההנחיות האלה רק אחרי הצגת נימוק בהקשר המתאים למשתמש לגבי הסיבה לכך הרשאה.
איך
ה-UX ו-UX Planet הדרכים הנכונות לבקש הרשאות ממשתמשים הם מקורות מידע טובים כדי להבין איך לעצב בקשות להרשאות, בזמן שמתמקד בנייד, להחיל את ההגדרה על כל אפליקציות ה-PWA.
שמירה על קוד תקין תעזור לכם להשיג את היעדים שלכם ולהוסיף תכונות חדשות.
סיבה
בניית אפליקציית אינטרנט מודרנית דורשת הרבה עבודה. שמירה שהאפליקציה שלכם מעודכנת ו-codebase תקין מקל על התפקוד שלה. כדי שתוכלו לספק תכונות חדשות שתואמות ליעדים האחרים שמפורטים את רשימת המשימות הזו.
איך
יש כמה בדיקות בעדיפות גבוהה שמטרתן לוודא שקוד הבסיס תקין:
- להימנע משימוש בספריות עם נקודות חולשה ידועות.
- חשוב לוודא שאתם לא משתמשים בממשקי API שהוצאו משימוש.
- מסירים שיטות תכנות לא בטוחות מ-codebase (כמו שימוש ב-codebase)
document.write()או אירוע של גלילה לא פסיבית מאזינים), - אפשר אפילו לכתוב קוד באופן הגנתי כדי לוודא שה-PWA לא יקרוס אם ניתוח הנתונים או ספריות אחרות של צד שלישי לא ייטענו.
- כדאי לדרוש ניתוח קוד סטטי, כמו איתור שגיאות בקוד, וגם בדיקה אוטומטית בכמה דפדפנים וערוצי הפצה. האלה יכולות לעזור לזהות שגיאות לפני שהן הופכות לייצור.