כשמפתחים תוכן למגוון משתמשים ומכשירים, חשוב לקחת בחשבון את התוכן, הפריסה והעיצוב הגרפי.
איך אנשים קוראים באינטרנט
במדריך הכתיבה של ממשלת ארה"ב יש סיכום של מה שאנשים רוצים לקרוא באינטרנט:
מחקרים מראים שאנשים לא קוראים דפי אינטרנט, הם סורקים אותם. בממוצע, אנשים קוראים רק 20-28% מהתוכן בדף אינטרנט. קריאה ממסכים איטית בהרבה מקריאה מנייר. אם המידע לא יהיה נגיש וברור, אנשים יתייאשו ויעזבו את האתר.
איך כותבים לנייד
התמקדו בנושא שעל הפרק וספרו את הסיפור כבר בהתחלה. כדי שהכתיבה תפעל במגוון מכשירים וחלונות תצוגה, חשוב להעביר את הנקודות העיקריות בהתחלה: ככלל, מומלץ בארבע הפסקאות הראשונות, בערך ב-70 מילים.
כדאי לשאול את עצמכם מה אנשים רוצים מהאתר שלכם. האם הם מנסים לגלות משהו? אם אנשים מבקרים באתר שלכם כדי לקבל מידע, ודאו שכל הטקסט באתר מכוון לעזור להם להשיג את המטרה שלהם. כתבו בקול פעיל, הציעו פעולות ופתרונות.
פרסמו רק את מה שהמבקרים רוצים, ולא יותר מזה.
מחקר של ממשלת בריטניה מראה גם את הנתונים הבאים:
במילים אחרות: השתמשו בשפה פשוטה, במילים קצרות ובמבני משפטים פשוטים – גם אם הקהל שלכם הוא קהל טכני שמבין את השפה. אלא אם יש סיבה טובה לא לעשות זאת, כדאי לשמור על טון דיבור שיחה. כלל ישן בעיתונאות הוא לכתוב כאילו מדברים עם ילד בן 11 חכם.
מיליארד המשתמשים הבאים
הגישה המצומצמת לכתיבה חשובה במיוחד לקוראים במכשירים ניידים, והיא חיונית כשיוצרים תוכן לטלפונים זולים עם חלונות תצוגה קטנים שדורשים גלילה רבה יותר, ועשויים להיות בעלי מסכים באיכות נמוכה יותר ומסכים פחות רספונסיביים.
לרוב המשתמשים הבאים שיצטרפו לאינטרנט יהיו מכשירים זולים. הם לא ירצו לבזבז את תקציב הנתונים שלהם על ניווט בתוכן ארוך ומייגע, ויכול להיות שהם לא קוראים בשפת האם שלהם. כדאי לקצר את הטקסט: להשתמש במשפטים קצרים, במינימום סימני פיסוק, בפסקאות של חמש שורות או פחות ובכותרות של שורה אחת. כדאי לשקול שימוש בטקסט רספונסיבי (לדוגמה, שימוש בכותרות קצרות יותר באזורי תצוגה קטנים יותר), אבל חשוב להיות מודעים לחסרונות.
גישה מינימליסטית לטקסט גם תקל על התאמת התוכן לשוק המקומי ועל התאמתו לשווקים בינלאומיים, וגם תגדיל את הסיכוי שהתוכן שלכם יצוטט ברשתות החברתיות.
השורה התחתונה:
- לשמור על פשטות
- הפחתת העומס
- התמקדו בנושא
הסרת תוכן מיותר
מבחינת גודל בבייטים, דפי אינטרנט הם גדולים והם הולכים וגדלים.
טכניקות של עיצוב רספונסיבי מאפשרות להציג תוכן שונה בחלונות תצוגה קטנים יותר, אבל תמיד כדאי להתחיל בייעול של טקסט, תמונות ותוכן אחר.
משתמשים באינטרנט הם לרוב בעלי אוריינטציה של פעולה, הם "מתקדמים" בחיפוש אחר תשובות לשאלה הנוכחית שלהם, במקום להישען לאחור כדי לקרוא ספר טוב.
Jackob Nielsen
כדאי לשאול את עצמכם: מה אנשים מנסים להשיג כשהם מבקרים באתר שלי?
האם כל רכיב בדף עוזר למשתמשים להשיג את המטרה שלהם?
הסרת רכיבים מיותרים בדף
לפי HTTP Archive, קובצי HTML מהווים כמעט 70 אלף ויותר מתשע בקשות לדף אינטרנט ממוצע.
בהרבה אתרים פופולריים נעשה שימוש בכמה אלפי רכיבי HTML לכל דף, ובכמה אלפי שורות קוד, גם בנייד. גודל קובץ HTML גדול מדי לא בהכרח יגרום לטעינת הדפים לאט יותר, אבל מטען ייעודי (payload) של HTML כבד יכול להיות סימן לניפוח תוכן: קובצי .html גדולים יותר מצביעים על יותר רכיבים, יותר תוכן טקסט או שניהם.
הפחתת המורכבות של קוד ה-HTML תפחית גם את משקל הדף, תעזור להפעיל לוקליזציה ובינלאומיות ותקל על התכנון והניפוי של עיצוב רספונסיבי. מידע על כתיבת HTML יעיל יותר זמין במאמר High performance HTML.
כל שלב שאתם דורשים מהמשתמשים לבצע לפני שהם מקבלים ערך מהאפליקציה שלכם יגרום לכם לאבד 20% מהמשתמשים
Gabor Cselle, Twitter
אותו הדבר נכון לגבי תוכן: כדאי לעזור למשתמשים להגיע למה שהם רוצים כמה שיותר מהר.
אל תסתירו תוכן ממשתמשי ניידים. כדאי לשאוף לשוויון בתוכן, כי ניסיון לנחש אילו תכונות לא יחסרו למשתמשים בנייד בטוח ייכשל עבור מישהו. אם יש לכם את המשאבים, כדאי ליצור גרסאות חלופיות של אותו תוכן לגדלים שונים של אזורי תצוגה – גם אם רק עבור רכיבי דף בעדיפות גבוהה.
כדאי לחשוב על ניהול התוכן וזרימת העבודה: האם מערכות מדור קודם יוצרות תוכן מדור קודם?
פישוט הטקסט
ככל שהאינטרנט עובר לנייד, צריך לשנות את אופן הכתיבה. ההסבר צריך להיות פשוט, תמציתי וללא פרטים מיותרים.
הסרת תמונות מיותרות
תמונות יכולות להיות יפות, מהנות ואינפורמטיביות – אבל הן גם תופסות מקום בדף, מוסיפות למשקל הדף ומגדילות את מספר בקשות הקבצים. זמן האחזור מתארך ככל שהקישוריות נחלשת, כלומר עודף בקשות לקובצי תמונות הוא בעיה גדלה ככל שהאינטרנט עובר לנייד.
גם תמונות צורכות חשמל. אחרי המסך, הרדיו הוא הגורם השני הכי משמעותי לריקון הסוללה. יותר בקשות לתמונות, יותר שימוש ברדיו, יותר סוללות ריקות. גם כדי לעבד תמונות צריך כוח עיבוד – והכמות שלו תלויה בגודל ובמספר התמונות. כדאי לעיין בדוח של סטנפורד Who Killed My Battery?
אם אפשר, כדאי להיפטר מהתמונות.
הנה כמה הצעות:
- כדאי לשקול עיצובים שלא כוללים תמונות בכלל, או עיצובים שכוללים תמונות במידה מועטה. גם טקסט בלבד יכול להיות יפה! תשאלו את עצמכם: "מה המבקרים באתר שלי מנסים להשיג? האם תמונות יכולות לעזור בתהליך הזה?"
- בעבר, היה נהוג לשמור כותרות וטקסט אחר כגרפיקה. הגישה הזו לא מגיבה טוב לשינויים בגודל אזור התצוגה, והיא מוסיפה למשקל הדף ולזמן האחזור. שימוש בטקסט כגרפיקה גם אומר שמנועי חיפוש לא יכולים למצוא את הטקסט, ושטכנולוגיות מסייעות כמו קוראי מסך לא יכולות לגשת אליו. כדאי להשתמש בטקסט 'אמיתי' איפה שאפשר – פונטים מסוג webfont ו-CSS יכולים ליצור טיפוגרפיה יפה.
- כדאי להשתמש ב-CSS במקום בתמונות כדי ליצור מעברי צבע, צללים, פינות מעוגלות ומרקמי רקע, שהם תכונות נתמכות בכל הדפדפנים המודרניים. עם זאת, חשוב לזכור ש-CSS עשוי להיות טוב יותר מתמונות, אבל עדיין יכול להיות קנס על עיבוד ורינדור, במיוחד בנייד.
- תמונות רקע בדרך כלל לא נראות טוב בנייד. אתם יכולים להשתמש בשאילתות מדיה כדי להימנע מתמונות רקע באזורי תצוגה קטנים.
- אל תשתמשו בתמונות של מסך פתיחה.
- שימוש ב-CSS לאנימציות בממשק המשתמש.
- כדאי להכיר את הגליפים; להשתמש בסמלים וסמלי Unicode במקום בתמונות, עם גופני אינטרנט אם צריך.
- כדאי להשתמש בגופני סמלים. אלה גרפיקות וקטוריות שאפשר לשנות את הגודל שלהן בלי הגבלה, ואפשר להוריד קבוצה שלמה של תמונות בגופן אחד. (עם זאת, חשוב לשים לב לבעיות האלה).
- אפשר להשתמש ברכיב
<canvas>כדי ליצור תמונות ב-JavaScript מקווים, מעקומות, מטקסט ומעוד תמונות. - הטבעה של תמונות בפורמט SVG או של מזהי URI של נתונים לא תקטין את משקל הדף, אבל היא יכולה להקטין את זמן האחזור כי היא מקטינה את מספר בקשות המשאבים. ל-SVG מוטבע יש תמיכה מצוינת בדפדפנים לנייד ולמחשב, וכלי אופטימיזציה יכולים לצמצם באופן משמעותי את הגודל של קובץ ה-SVG. באופן דומה, יש תמיכה טובה במזהי URI של נתונים. אפשר להשתמש בשניהם ב-CSS.
- מומלץ להשתמש ב-
<video>במקום באנימציות GIF. רכיב הווידאו נתמך בכל הדפדפנים בנייד (מלבד Opera Mini).
מידע נוסף זמין במאמרים בנושא אופטימיזציה של תמונות והסרה והחלפה של תמונות.
עיצוב תוכן שמתאים לגדלים שונים של אזורי תצוגה
"Create a product, don't re-imagine one for small screens. מוצרים מצוינים לנייד נוצרים, אף פעם לא מועברים".
Mobile Design and Development, Brian Fling
מעצבים טובים לא עושים "אופטימיזציה לנייד" – הם חושבים על עיצוב רספונסיבי כדי לבנות אתרים שפועלים במגוון מכשירים. מבנה הטקסט ותוכן אחר בדף חשובים מאוד להצלחה בשימוש במכשירים שונים.
רבים מהמשתמשים הבאים שיתחברו לאינטרנט משתמשים במכשירים זולים עם אזורי תצוגה קטנים. קשה לקרוא במסך ברזולוציה נמוכה בגודל 3.5 או 4 אינץ'.
הנה תמונה של שניהם ביחד:
במסך הגדול יותר, הטקסט קטן אבל אפשר לקרוא אותו.
במסך הקטן יותר, הדפדפן מעבד את הפריסה בצורה נכונה, אבל הטקסט לא קריא, גם כשמגדילים את התצוגה. התצוגה מטושטשת ויש בה 'השלכת צבע' – הלבן לא נראה לבן – מה שמקשה על קריאת התוכן.
עיצוב תוכן לנייד
כשמפתחים לאוסף של אזורי תצוגה, צריך להתייחס לתוכן, לפריסה ולעיצוב הגרפי. חשוב לעצב עם טקסט ותמונות אמיתיים, ולא עם תוכן placeholder.
"התוכן קודם לעיצוב. עיצוב ללא תוכן הוא לא עיצוב, אלא קישוט".
Jeffrey Zeldman
- כדאי למקם את התוכן החשוב ביותר בחלק העליון, כי המשתמשים נוטים לקרוא דפי אינטרנט בתבנית בצורת F.
- משתמשים נכנסים לאתר שלכם כדי להשיג מטרה מסוימת. שאלו את עצמכם מה הם צריכים כדי להשיג את המטרה הזו, והסירו את כל השאר. הקפידו על עיצובים חזותיים וטקסטואליים, תוכן מדור קודם, קישורים מוגזמים ועוד.
- צריך להיזהר עם סמלי שיתוף ברשתות חברתיות. הם עלולים ליצור עומס בפריסות, והקוד שלהם עלול להאט את טעינת הדף.
- עיצוב פריסות רספונסיביות לתוכן, ולא גדלים קבועים של מכשירים.
תוכן לבדיקה
- בודקים את קלות הקריאה בחלונות תצוגה קטנים יותר באמצעות כלי הפיתוח ל-Chrome וכלי הדמיה אחרים.
- בודקים את התוכן בתנאים של רוחב פס נמוך וזמן אחזור גבוה. כדאי לנסות את התוכן בתרחישים שונים של קישוריות.
- נסו לקרוא את התוכן ולקיים איתו אינטראקציה בטלפון לא יקר.
- כדאי לבקש מחברים ומקולגות לנסות את האפליקציה או האתר שלכם.
- איך יוצרים מעבדת בדיקה פשוטה למכשירים במאגר GitHub של מעבדת המכשירים הניידים המינימלית של Google יש הוראות להרכבת מעבדה משלכם. OpenSTF היא אפליקציית אינטרנט פשוטה לבדיקת אתרים במספר מכשירי Android.
כך נראה OpenSTF בפעולה:
אנשים משתמשים יותר ויותר במכשירים ניידים כדי לצרוך תוכן ולקבל מידע – לא רק כמכשירים לתקשורת, למשחקים ולמדיה.
לכן חשוב יותר ויותר לתכנן את התוכן כך שיוצג בצורה טובה במגוון אזורי תצוגה, ולתת עדיפות לתוכן כשמתכננים את הפריסה, הממשק והאינטראקציה במכשירים שונים.
הסבר על עלות הנתונים
דפי אינטרנט הולכים וגדלים.
לפי HTTP Archive, המשקל הממוצע של דף במיליון האתרים המובילים הוא עכשיו יותר מ-2MB.
המשתמשים נמנעים מאתרים או מאפליקציות שנתפסים כאיטיים או יקרים, ולכן חשוב להבין את העלות של טעינת רכיבי דף ואפליקציה.
הפחתת משקל הדף יכולה גם להיות רווחית. כריס זכריהס מ-YouTube גילה שכשהם הקטינו את הגודל של דף הצפייה מ-1.2MB ל-250KB:
במילים אחרות, צמצום משקל הדף יכול לפתוח שווקים חדשים לגמרי.
חישוב משקל הדף
יש מספר כלים לחישוב המשקל של דף. בחלונית 'רשת' בכלי הפיתוח ל-Chrome מוצג הגודל הכולל בבייט של כל המשאבים, ואפשר להשתמש בה כדי לקבוע את המשקלים של סוגי נכסים ספציפיים. אפשר גם לבדוק אילו פריטים אוחזרו ממטמון הדפדפן.
דפדפן Firefox ודפדפנים אחרים מציעים כלים דומים.
WebPagetest מאפשר לבדוק את הטעינה הראשונה של הדף ואת הטעינות הבאות. אפשר להשתמש בסקריפטים כדי להפוך את הבדיקות לאוטומטיות (לדוגמה, כדי להתחבר לאתר), או להשתמש בממשקי ה-API מסוג RESTful. בדוגמה הבאה (טעינת developers.google.com/web) אפשר לראות שהשמירה במטמון הצליחה, ושטעינות הדפים הבאות לא דרשו משאבים נוספים.
בנוסף, הכלי WebPagetest מספק פירוט של הגודל והבקשות לפי סוג MIME.
חישוב עלות הדף
אצל הרבה משתמשים, הנתונים לא רק עולים במונחים של בייט וביצועים – הם עולים כסף.
באתר What Does My Site Cost? אפשר להעריך את העלות הכספית בפועל של טעינת האתר. ההיסטוגרמה שלמטה מראה כמה עולה (באמצעות חבילת גלישה בתשלום מראש) לטעון את amazon.com.
חשוב לזכור שהמדד הזה לא מתייחס ליכולת ההשתכרות של האנשים. הנתונים מ-blog.jana.com מציגים את עלות הנתונים.
| עלות (USD) של חבילת גלישה של 500MB |
שכר מינימום לשעה (USD) |
שעות עבודה לתשלום על חבילת גלישה של 500MB |
|
| הודו | 3.38$ | 0.80 ש"ח | 17 שעות |
| אינדונזיה | 2.39$ | $0.43 | 6 שעות |
| ברזיל | $13.77 | 4.16 ש"ח | 13 שעות |
משקל הדף הוא לא בעיה רק בשווקים מתפתחים. במדינות רבות, אנשים משתמשים בחבילות גלישה לנייד עם נתונים מוגבלים, והם יימנעו מהאתר או מהאפליקציה שלכם אם הם יתפסו אותם ככבדים ויקרים. גם חבילות גלישה וחבילות Wi-Fi 'ללא הגבלה' בדרך כלל כוללות מגבלת נתונים, שאחריה החבילה נחסמת או שהמהירות שלה מוגבלת. לכן, מומלץ להיות שקופים ככל האפשר לגבי כמות הנתונים שהדף צורך. בפוסט הבא בבלוג מפורטות שיטות מומלצות ספציפיות: יצירת אמון באמצעות שקיפות בנוגע לעלויות
בשורה התחתונה: משקל הדף משפיע על הביצועים ועולה כסף. במאמר אופטימיזציה של יעילות התוכן מוסבר איך להפחית את העלות הזו.