אפליקציות Progressive Web App (PWA) מבוססות על ממשקי API מודרניים ומשופרים, כדי לספק יכולות משופרות, אמינות וקלות התקנה, תוך הגעה לכל אחד, בכל מקום ובכל מכשיר באמצעות בסיס קוד יחיד. כדי לעזור לכם ליצור את חוויית השימוש הכי טובה שאפשר, אנחנו ממליצים להשתמש ברשימות המשימות ובהמלצות העיקריות והאופטימליות.
רשימת משימות מרכזית ל-Progressive Web App
בצ'קליסט של Progressive Web App מפורטות הדרישות כדי שאפליקציה תהיה ניתנת להתקנה ושימוש על ידי כל המשתמשים, ללא קשר לגודל או לסוג הקלט.
הפעלה מהירה, מהירות קבועה
הביצועים ממלאים תפקיד חשוב בהצלחה של כל חוויה באינטרנט, כי אתרים עם ביצועים טובים יותר מושכים את המשתמשים ומעודדים אותם להישאר באתר יותר מאשר אתרים עם ביצועים גרועים. חשוב להתמקד באופטימיזציה של מדדי ביצועים שמתמקדים במשתמשים.
סיבה
המהירות היא קריטית כדי לגרום למשתמשים להשתמש באפליקציה שלכם. למעשה, ככל שזמן הטעינה של הדף מתארך משנייה אחת ל-10 שניות, ההסתברות שמשתמש יעזוב את הדף הראשון עולה ב-123%. גם הביצועים לא מסתיימים באירוע load. המשתמשים לא צריכים לתהות אם האינטראקציה שלהם, כמו
לחיצה על לחצן, נרשמה או לא. הגלילה והאנימציה צריכות להיות חלקות. הביצועים משפיעים על כל חוויית השימוש באפליקציה, גם על אופן הפעולה שלה וגם על התפיסה של המשתמשים לגביה.
לכל האפליקציות יש צרכים שונים, אבל ביקורות הביצועים ב-Lighthouse מבוססות על המדדים הבסיסיים של חוויית המשתמש (Core Web Vitals). אם תקבלו ציון גבוה בביקורות האלה, סביר יותר שהמשתמשים ייהנו מהחוויה. אפשר גם להשתמש ב-PageSpeed Insights או בדוח על חוויית המשתמש ב-Chrome כדי לקבל נתוני ביצועים בפועל של אפליקציית האינטרנט.
איך
כדי ללמוד איך לגרום לאפליקציית ה-PWA שלכם לפעול במהירות ולשמור על מהירות הפעולה, אתם יכולים לעיין במדריך שלנו בנושא זמני טעינה מהירים.
עובד בכל דפדפן
משתמשים יכולים להשתמש בכל דפדפן שיבחרו כדי לגשת לאפליקציית האינטרנט שלכם לפני שהיא מותקנת.
סיבה
אפליקציות Progressive Web App הן קודם כל אפליקציות אינטרנט, ולכן הן צריכות לפעול בדפדפנים שונים.
דרך יעילה לעשות את זה היא, לפי ג'רמי קית' בספר Resilient Web Design, לזהות את התכונות העיקריות, להפוך את התכונות האלה לזמינות באמצעות הטכנולוגיה הפשוטה ביותר שאפשר, ואז לשפר את החוויה איפה שאפשר. במקרים רבים, המשמעות היא להתחיל עם HTML בלבד כדי ליצור את תכונות הליבה, ולשפר את חוויית המשתמש באמצעות CSS ו-JavaScript כדי ליצור חוויה מעניינת יותר.
לדוגמה, שליחת טופס. הדרך הפשוטה ביותר להטמיע את זה היא באמצעות טופס HTML ששולח בקשת POST. אחרי שיוצרים את הטופס, אפשר לשפר את חוויית המשתמש באמצעות JavaScript כדי לבצע אימות של הטופס ולשלוח אותו באמצעות AJAX. כך משפרים את חוויית המשתמש עבור משתמשים שיכולים לתמוך בטכנולוגיה הזו.
המשתמשים שלכם נכנסים לאתר ממגוון מכשירים ודפדפנים. אי אפשר לטרגט רק את הקצה העליון של הספקטרום הזה. כדאי להשתמש בזיהוי תכונות כדי לספק חוויית שימוש טובה למגוון רחב ככל האפשר של משתמשים פוטנציאליים, כולל משתמשים בדפדפנים ובמכשירים שעדיין לא קיימים.
איך
הספר Resilient Web Design של ג'רמי קית' הוא מקור מידע מצוין שמסביר איך לחשוב על עיצוב אתרים בשיטה מתקדמת שמתאימה לכל הדפדפנים.
מקורות מידע נוספים
- המאמר Understanding Progressive Enhancement (הבנת שיפור מתקדם) של A List Apart הוא מבוא טוב לנושא.
- במאמר Progressive Enhancement: What It Is, And How To Use It? (שיפור הדרגתי: מה זה ואיך משתמשים בזה?) של Smashing Magazine יש מבוא מעשי וקישורים לנושאים מתקדמים יותר.
- במאמר Implementing feature detection (הטמעה של זיהוי תכונות) ב-MDN מוסבר איך לזהות תכונה באמצעות שאילתה ישירה.
רספונסיביות לכל גודל מסך
המשתמשים יכולים להשתמש ב-PWA בכל גודל מסך, וכל התוכן שלו זמין בכל גודל של אזור תצוגה.
סיבה
מכשירים מגיעים במגוון גדלים, והמשתמשים עשויים להשתמש באפליקציה שלכם במגוון גדלים, גם באותו מכשיר. לכן, חשוב לוודא שהתוכן מתאים לאזור התצוגה, ושאפשר להשתמש בכל התכונות והתוכן באתר בכל הגדלים של אזור התצוגה.
המשימות שהמשתמשים רוצים לבצע והתוכן שהם רוצים לגשת אליו לא משתנים בהתאם לגודל אזור התצוגה. אתם יכולים לשנות את הסידור של התוכן בהתאם לגודל אזור התצוגה, והוא אמור להופיע כולו, בדרך כזו או אחרת. למעשה, כמו שאפשר לקרוא בספר Mobile First של לוק ורובלבסקי, התחלה עם עיצוב קטן והתאמה שלו למסכים גדולים יותר יכולה לשפר את העיצוב של האתר:
"במכשירים ניידים, צוותי פיתוח תוכנה צריכים להתמקד רק בנתונים ובפעולות החשובים ביותר באפליקציה. פשוט אין מקום במסך בגודל 320 על 480 פיקסלים לרכיבים מיותרים. צריך לתת עדיפות."
איך
יש הרבה מקורות מידע על עיצוב רספונסיבי, כולל: המאמר המקורי של איתן מרקוט ואוסף של מושגים חשובים שקשורים אליו, וגם ספרים והרצאות.
כדי לצמצם את הדיון הזה להיבטים של תוכן בעיצוב רספונסיבי, אפשר לעיין במאמרים הבאים:
- עיצוב שמתחיל בתוכן
- פריסות רספונסיביות של תוכן.
- Seven Deadly Mobile Myths, which is just as relevant to small-sized views of responsive sites as all mobile.
הצגת דף אופליין מותאם אישית
כשמשתמשים נמצאים במצב אופליין, אם הם נשארים ב-PWA הם נהנים מחוויה חלקה יותר מאשר אם הם מועברים לדף ברירת המחדל של הדפדפן במצב אופליין.
סיבה
המשתמשים מצפים שהאפליקציות המותקנות יפעלו בלי קשר לסטטוס החיבור שלהם. אפליקציה ספציפית לפלטפורמה אף פעם לא מציגה דף ריק כשהיא במצב אופליין, ואפליקציית PWA אף פעם לא אמורה להציג את דף ברירת המחדל של הדפדפן במצב אופליין. כשמשתמש עובר לכתובת URL שלא נשמרה במטמון או מנסה להשתמש בתכונה שדורשת חיבור, חוויית השימוש באתר צריכה להרגיש כמו חלק מהמכשיר שבו הוא פועל. כדי להשיג את זה, צריך לספק חוויה מותאמת אישית במצב אופליין.
איך
במהלך אירוע install של Service Worker, אפשר להוסיף מראש למטמון דף אופליין מותאם אישית שיוצג כשהמשתמש עובר למצב אופליין. כאן אפשר לקרוא איך ליצור דף חלופי למצב אופליין. אם לא מספקים דף אופליין, Chrome ממשיך להציג דף אופליין בסיסי.
ניתן להתקין
משתמשים שמתקינים או מוסיפים אפליקציות למכשיר שלהם נוטים להשתמש באפליקציות האלה יותר.
סיבה
התקנה של Progressive Web App מאפשרת לו להיראות, להרגיש ולפעול כמו כל האפליקציות המותקנות האחרות. היא מופעלת מאותו מקום שבו המשתמשים מפעילים את האפליקציות האחרות שלהם. היא פועלת בחלון אפליקציה משלה, בנפרד מהדפדפן, והיא מופיעה ברשימת המשימות, בדיוק כמו אפליקציות אחרות.
בדומה לאפליקציות ספציפיות למכשירים, משתמשים שמתקינים את האפליקציות שלכם הם הקהל הכי פעיל שלכם, ולעתים קרובות יש להם מדדי פעילות שדומים לאלה של משתמשי אפליקציות במכשירים ניידים. המדדים האלה כוללים יותר ביקורים חוזרים, יותר זמן שהייה באתר ושיעורי המרה גבוהים יותר בהשוואה למבקרים רגילים.
איך
אפשר לעיין במדריך להתקנה.
רשימת משימות אופטימלית ל-Progressive Web App
כדי ליצור PWA מצוין, שמרגיש כמו אפליקציה מהשורה הראשונה, צריך יותר מסתם רשימת משימות בסיסית. הצ'קליסט האופטימלי של PWA נועד לוודא שאפליקציית ה-PWA תפעל כאילו היא חלק מהמכשיר שבו היא פועלת, תוך ניצול היתרונות של האינטרנט.
מספק חוויה אופליין
אם אין צורך בחיבור לאינטרנט, האפליקציה פועלת במצב אופליין בדיוק כמו במצב אונליין.
סיבה
בנוסף לדף אופליין מותאם אישית, המשתמשים מצפים שאפליקציות PWA יהיו שמישות גם אופליין. לדוגמה, באפליקציות של חברות תעופה וסוכנויות נסיעות צריך להיות אפשר לגשת בקלות לפרטי הנסיעה ולכרטיסי העלייה למטוס גם במצב אופליין. אפליקציות של מוזיקה, סרטונים ופודקאסטים צריכות לאפשר הפעלה אופליין. באפליקציות של רשתות חברתיות ובאפליקציות חדשותיות כדאי לשמור במטמון תוכן עדכני כדי שהמשתמשים יוכלו לקרוא אותו במצב אופליין. בנוסף, המשתמשים מצפים להישאר מאומתים גם במצב אופליין, לכן חשוב לתכנן אימות אופליין.
אפליקציית PWA אופליין מספקת למשתמשים חוויה שדומה מאוד לשימוש באפליקציה.
איך
אחרי שמחליטים אילו תכונות המשתמשים מצפים שיפעלו במצב אופליין, צריך לוודא שהתוכן זמין וניתן להתאמה להקשרים של מצב אופליין. אפשר להשתמש ב-IndexedDB, מערכת אחסון NoSQL בדפדפן, כדי לאחסן ולאחזר נתונים, ובסנכרון ברקע כדי לאפשר למשתמשים לבצע פעולות במצב אופליין ולדחות את התקשורת עם השרת עד שהמשתמש יתחבר שוב בצורה יציבה. אפשר להשתמש ב-Service Workers כדי לאחסן סוגים אחרים של תוכן, כמו תמונות, קובצי וידאו וקובצי אודיו, לשימוש אופליין, וכדי להטמיע סשנים מאובטחים לטווח ארוך כדי לשמור על אימות המשתמשים.
מבחינת חוויית המשתמש, אפשר להשתמש במסכי שלד שנותנים למשתמשים תחושה של מהירות ושל תוכן בזמן הטעינה, ואז לחזור לתוכן במטמון או להציג אינדיקטור לא מקוון לפי הצורך.
גישה מלאה
כל האינטראקציות של המשתמשים עומדות בתקן הבינלאומי העדכני ביותר של Web Content Accessibility Guidelines (WCAG) (הנחיות לנגישות בתוכן אינטרנטי).
סיבה
בשלב מסוים בחיים, רוב המשתמשים רוצים להשתמש ב-PWA שלכם באופן שעומד בדרישות של WCAG. היכולת של אנשים לתקשר עם אפליקציית ה-PWA שלכם ולהבין אותה משתנה, והצרכים יכולים להיות זמניים או קבועים. כשדואגים לנגישות של אפליקציית ה-PWA, היא הופכת לשימושית לכולם.
איך
המאמר 'מבוא לנגישות לאינטרנט' של W3C הוא מקום טוב להתחיל בו. רוב בדיקות הנגישות צריכות להתבצע באופן ידני. ביקורת נגישות ב-Lighthouse, ב-axe וב-Accessibility Insights יכולה לעזור לכם לבצע אוטומציה של חלק מבדיקות הנגישות. חשוב גם להשתמש ברכיבים סמנטיים נכונים במקום ליצור אותם בעצמכם, כמו הרכיבים <a> ו-<button>. כך תוכלו לוודא שכשיהיה צורך ליצור תכונות מתקדמות יותר, תעמדו בדרישות הנגישות, למשל מתי להשתמש בחצים ומתי בלחצני Tab.
ב-A11Y Nutrition Cards יש עצות מצוינות בנושא הזה לגבי כמה רכיבים נפוצים.
אפשר למצוא אותו בחיפוש
אפשר למצוא את ה-PWA בקלות באמצעות חיפוש.
סיבה
אחד היתרונות הגדולים של האינטרנט הוא האפשרות לגלות אתרים ואפליקציות באמצעות חיפוש. למעשה, יותר ממחצית מכלל התנועה באתר מגיעה מחיפוש אורגני. כדי שמשתמשים פוטנציאליים יוכלו למצוא את אפליקציית ה-PWA שלכם, חשוב לוודא שקיימות כתובות URL קנוניות לתוכן ו שמנועי חיפוש יכולים ליצור אינדקס של האתר שלכם. זה נכון במיוחד כשמשתמשים ברינדור בצד הלקוח.
איך
קודם כל, מוודאים שלכל כתובת URL יש כותרת ייחודית ותיאור מטא תיאורי. לאחר מכן תוכלו להשתמש ב-Google Search Console ובביקורות על אופטימיזציה למנועי חיפוש ב-Lighthouse כדי לנפות באגים ולפתור בעיות שקשורות ליכולת הגילוי של ה-PWA.
אפשר גם להשתמש בכלים לבעלי אתרים של Bing או של Yandex, ולשקול לכלול נתונים מובְנים באמצעות סכימות מ-Schema.org ב-PWA.
עובד עם כל סוג קלט
אפשר להשתמש ב-PWA גם עם עכבר, מקלדת, סטיילוס או מגע.
סיבה
מכשירים מציעים מגוון שיטות קלט, והמשתמשים צריכים להיות מסוגלים לעבור ביניהן בצורה חלקה בזמן השימוש באפליקציה. חשוב לא פחות ששיטות הקלט לא יהיו תלויות בגודל המסך. כלומר, אזורי תצוגה גדולים צריכים לתמוך במגע, ואזורי תצוגה קטנים צריכים לתמוך במקלדות ובעכברים. כדאי לוודא שהאפליקציה וכל התכונות שלה תומכות בשימוש בכל שיטת קלט שהמשתמש עשוי לבחור. במקרים המתאימים, משפרים את חוויית השימוש כדי לאפשר גם אמצעי בקרה ספציפיים לקלט (כמו משיכה לרענון).
איך
Pointer Events API מספק ממשק מאוחד לעבודה עם אפשרויות קלט שונות, והוא מתאים במיוחד להוספת תמיכה בעט. כדי לתמוך גם במגע וגם במקלדת, חשוב לוודא שאתם משתמשים באלמנטים הסמנטיים הנכונים (עוגנים, לחצנים, אמצעי בקרה של טפסים וכו') ולא בונים אותם מחדש באמצעות HTML לא סמנטי. כשכוללים אינטראקציות שמופעלות בהעברת העכבר מעל הרכיב, צריך לוודא שאפשר להפעיל אותן גם בלחיצה או בהקשה.
מספק הקשר לבקשות הרשאה
כשמבקשים הרשאה להשתמש בממשקי API מתקדמים, חשוב לספק הקשר ולבקש הרשאה רק כשצריך להשתמש בממשק ה-API.
סיבה
ממשקי API שמפעילים בקשה להרשאה, כמו התראות, מיקום גיאוגרפי ופרטי כניסה, מתוכננים בכוונה להפריע למשתמש, כי הם בדרך כלל קשורים לתכונות עוצמתיות שדורשות הסכמה. הצגת ההנחיות האלה ללא הקשר נוסף, למשל בזמן טעינת הדף, מקטינה את הסיכוי שהמשתמשים יאשרו את ההרשאות האלה, ומגדילה את הסיכוי שהם לא יסמכו עליהן בעתיד.
במקום זאת, כדאי להציג את ההנחיות האלה רק אחרי שמספקים למשתמש הסבר בהקשר למה נדרשת ההרשאה הזו.
איך
המאמר חוויית משתמש בנושא הרשאות והמאמר הדרכים הנכונות לבקש הרשאות מהמשתמשים של UX Planet הם מקורות מידע טובים להבנת האופן שבו מעצבים הנחיות לבקשת הרשאה. המאמרים מתמקדים בנייד, אבל הם רלוונטיים לכל אפליקציות ה-PWA.
פועל לפי השיטות המומלצות ליצירת קוד תקין
שמירה על בסיס קוד תקין מקלה על השגת היעדים ועל פיתוח תכונות חדשות.
סיבה
בניית אפליקציית אינטרנט מודרנית דורשת השקעה רבה. שמירה על עדכניות האפליקציה ועל תקינות בסיס הקוד מאפשרת לכם לספק תכונות חדשות שעומדות ביעדים האחרים שמפורטים ברשימת המשימות הזו.
איך
יש מספר בדיקות בעדיפות גבוהה שנועדו להבטיח בסיס קוד תקין:
- מומלץ להימנע משימוש בספריות עם פגיעויות ידועות.
- חשוב לוודא שאתם לא משתמשים בממשקי API שהוצאו משימוש.
- מסירים ממאגר הקוד שיטות קידוד לא בטוחות, כמו
document.write()או מאזינים לא פסיביים לאירועי גלילה. - אפשר אפילו לכתוב קוד הגנתי כדי לוודא שאפליקציית ה-PWA לא תיפגע אם ניתוח הנתונים או ספריות אחרות של צד שלישי לא ייטענו.
- מומלץ לדרוש ניתוח סטטי של קוד, כמו linting, וגם בדיקות אוטומטיות בכמה דפדפנים וערוצי הפצה. הטכניקות האלה יכולות לעזור לכם לזהות שגיאות לפני שהן מגיעות לסביבת הייצור.