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