פיתוח עיצוב רספונסיבי לאתר (מחשב, טאבלט, נייד)

עיצוב אדפטיבי: איפה הפריסה נשברת במכשירים אמיתיים

בדיקה קלאסית של עיצוב אדפטיבי — שלוש רוחביות: דסקטופ, טאבלט, טלפון. המציאות רחבה יותר: בין נקודות השבירה נשארות עשרות רוחבי מסך ביניים, שבהם הגריד כבר נבנה מחדש, אך התוכן לא נכנס לעמודה החדשה. דווקא שם מופיעים בלוקים שנפרדים, טקסט שעולה זה על זה וגלילה אופקית שלא הייתה במוקאפ.

צוואר בקבוק נפרד — גרסת הטאבלט של האתר. לעתים רחוקות מתכננים אותה כתרחיש עצמאי: לרוב זה מובייל מתוח או דסקטופ מכווץ. בעת סיבוב אפילו ב-iPad הרוחב והגובה מתחלפים, ובלוקים שמקובעים לגובה החלון מפסיקים להיכנס — המשתמש רואה טופס חתוך במקום כפתור שליחה.

מקור שלישי לנטישות — הטקסט עצמו. לוקליזציה ונתונים ממסד הנתונים מאריכים שורות ב-20-40%: כותרת בשתי שורות הופכת לארבע, כפתור יוצא מחוץ לכרטיס. פריסה שבירה לא תמיד נראית כתקלה ברורה — לפעמים זה בלוק שזז או דף שקופץ בזמן טעינה, אבל היא מערערת את האמון במוצר באותה מידה.

המחיר של חוסר יציבות כזה — לא רק מסך לא יפה. טופס שבו בטאבלט לא רואים את הכפתור מאבד פניות; גלילה אופקית בטלפון שוברת מחוות רגילות; קפיצות של הפריסה פוגעות במדדים שלפיהם מנועי החיפוש מעריכים את הדף. בהמשך נפרט איך זה נסגר בשלב הפיתוח, ולא אחרי ההשקה.

האפקט של עיצוב אדפטיבי: נטישות, עומק גלילה, עריכות

את האפקט של פריסה אדפטיבית רואים לא לפי «נהיה מסודר יותר», אלא לפי התנהגות לפי מכשירים. מפצלים את התעבורה ב-Google Analytics לסשנים של מחשב, טאבלט וסמארטפון ובודקים מדדים בנפרד לכל קבוצה: שיעור נטישות, עומק גלילה, שיעור מי שהגיעו לבלוק היעד.

נטישות במובייל גדלות לא בגלל גודל המסך, אלא בגלל הפריסה: גלילה אופקית, אזורי נגיעה קטנים, גריד שנפרד, תמונה כבדה במקום תמונה שמתאימה לרוחב.

אחרי מעבר לגריד אדפטיבי וליחידות יחסיות הסיבות האלה נעלמות — שיעור הנטישות בסשני סמארטפון יורד, ועומק הגלילה עולה: המבקר מגיע לטופס הפנייה, ולא סוגר את הלשונית במסך הראשון.

בסיס קוד אחד נותן תוצאה מדידה שנייה — מהירות עריכות התוכן. סט אחד של תבניות וטוקנים של טיפוגרפיה במקום גרסאות נפרדות למובייל ולמחשב: כותרת, מחיר או טקסט משתנים בנקודה אחת ומתפשטים לכל הרזולוציות.

בעבר עריכה כזו דרשה שינוי מסונכרן בכמה תבניות, עכשיו זו פעולה אחת — זמן ביצוע העריכות מצטמצם משעות לדקות, וחוסר הסנכרון בין הגרסאות נעלם כקטגוריה.

בהתחלה אנחנו קובעים ערכי בסיס לכל סוג מכשיר, אחרי השקה משווים באותם סגמנטים. לדוח נכנס לא מספר ממוצע לאתר, אלא הפער בין מכשירים: איפה בדיוק ההתנהגות הייתה שונה ומה השפיע על כך — הגריד, סדר הבלוקים, גודל האלמנטים האינטראקטיביים.

השוואת גישות: גריד גמיש וגרסת מובייל נפרדת

גישות לפריסה בוחרים לא לפי טעם, אלא לפי מספר הערוצים שצריך לתחזק. גריד גמיש בנקודות שבירה בונה מחדש את אותה סימון: עמודות מתקפלות, ניווט עובר לתפריט נסתר, תמונות נמסרות בגודל הנדרש. גרסת מובייל נפרדת — זה סט שני של תבניות ולעתים קרובות כתובת שנייה שמתנהלת לה בנפרד.

מה משתנה בתמיכה

עלות השינויים גדלה יחד עם מספר המימושים הבלתי תלויים. עריכה בגריד גמיש נעשית פעם אחת ומתפשטת לכל נקודות השבירה; בשתי תבניות אותה עבודה נעשית פעמיים ומשווים כדי שהבלוקים לא יתפצלו ויזואלית. גרסת מובייל נפרדת לרוב יוצרת פער בהתנהגות טפסים ומסננים — דווקא שם נשברת האנליטיקה ואובדות פניות.

אפליקציה נטיבית סוגרת את מה שאף גישת דפדפן לא נותנת, אבל אין לה סנכרון תוכן עם האתר כברירת מחדל. בפועל לוקחים גריד גמיש כבסיס, ואת האפליקציה מחברים כערוץ נפרד כשהתרחישים באמת נפרדו.

שלבי העבודה: אפיון מוקאפים, גריד, בדיקה במכשירים

עיצוב אדפטיבי הוא לא «כיווץ» של מוקאפ דסקטופ לטלפון, אלא מערכת חוקים: איפה הגריד נשבר, מה קורה לבלוקים בין נקודות השבירה ואיזה תוכן נשאר בעדיפות במסך צר. לכן העבודה נעשית ברצף — מאנליטיקה ומוקאפים ועד קבלה במכשירים אמיתיים, בלי תרחיש של «נתקן במקום» כבר בפריסה.

1. אפיון מוקאפים ואנליטיקה. משווים בין המוקאפים הנוכחיים לבין התפלגות אמיתית של רוחבי מסך בקרב המבקרים: רואים אילו טווחים בכלל צריך לתמוך ואילו בלוקים נשברים כבר בערכי ביניים.
2. תכנון הגריד. קובעים מספר עמודות, צעד ומרווחים לכל טווח, כדי שהבלוקים יזוזו לצדדים בצפוי, ולא «יצופו». צוות הפיתוח מקבל ערכים חד-משמעיים במקום ניחושים לפי תמונה.
3. חוקי התנהגות הבלוקים. לכל סקשן מתארים מה מתקפל, מה עובר למטה, מה מוסתר ומה נשאר ללא שינוי: טבלאות, כותרות ארוכות, טפסים, גלריות.
4. בדיקת מצבי ביניים. מסתכלים לא רק על טלפון ודסקטופ, אלא גם על רוחבים לא נוחים ביניהם, סיבוב מסך, גופן מערכת מוגדל — דווקא שם יוצאות גלישות וטקסט חתוך.
5. בדיקה במכשירים. מריצים תרחישי מפתח על דסקטופ, טאבלט וסמארטפון אמיתיים, ולא רק באמולטור: נגיעות, גלילה בתוך בלוקים, חלונות קופצים.
6. מסירה לפיתוח. מוסרים גריד, משתני מרווחים וטיפוגרפיה, מצבי אלמנטים וקריטריוני קבלה — הבנייה נעשית לפי מפרט, ולכן פערים נתפסים לפני השקה, ולא אחריה.

ערכת מסירה: מוקאפים, ספריית רכיבים, מפרטים

ערכת מסירה היא לא תיקייה עם תמונות, אלא תיעוד עבודה שלפיו הצוות בונה ממשק בלי ניחושים ובלי התכתבות «ואיך זה אמור להיראות בטאבלט». להלן מה נשאר אצל הלקוח ואיך כל ארטיפקט משמש בעבודה.

• מוקאפי דפים לפי טווחי מסך. פריסות נפרדות למסכים רחבים, טאבלטים וסמארטפונים: סידור מחדש של בלוקים, ולא קנה מידה של תמונה אחת. בנוסף מצבי ביניים של הגריד במקומות שבהם הבלוקים נבנים מחדש לא בו-זמנית.
• ספריית רכיבים. כפתורים, שדות, כרטיסים, ניווט, טבלאות — עם וריאציות ופרמטרים. רכיב אחד — מקור אמת אחד: עריכה בספרייה עוברת בירושה לכל המופעים, ולא נשארים פערים בין דפים.
• מצבי אלמנטים. ריחוף, לחיצה, פוקוס למקלדת, נבחר, לא פעיל, טעינה, שגיאה, תוצאה ריקה. דווקא השכבה הזו לרוב הולכת לאיבוד בין המוקאפ לקוד, לכן אנחנו מוסרים אותה כפרק נפרד.
• מפרטים לפיתוח. גריד ומרווחים, סולמות טיפוגרפיים, חוקי מעבר ושינוי גודל של כותרות ארוכות, עדיפות הסתרה של בלוקים משניים במסכים צרים. המפתח לא מנחש ערכים.
• אבות טיפוס של התנהגות. פתיחת תפריט, מסננים, שלבי טפסים, סיבוב מסך — המעברים מתוארים כדי שהלוגיקה תתאים בכל הטווחים.
• קבצי מקור וחוקים. קבצי מוקאפים וספרייה עם גישה, מוסכמות שמות שכבות וגרסאות, סדר ביצוע עריכות אחרי המסירה. הערכה נשארת חיה: דף חדש נבנה מרכיבים מוכנים.

סט כזה מסיר את הסיכון המרכזי במסירה — מצב שבו הממשק לכאורה בנוי, אבל סוטה מהרעיון בטאבלטים ובסמארטפונים. תארו את המשימה — נחזור עם הערכה ותוכנית, כולל הרכב הערכה לפרויקט שלכם.

מקרה בוחן: איך הסרנו כשלי פריסה בטאבלטים

הפרויקט — קטלוג עם אזור אישי והגשת פנייה. הפריסה החזיקה על שתי רוחביות בקרה, דסקטופ ומובייל, וכל מה שנפל ביניהן הוקצה לאחת מהקצוות.

בטאבלטים בתצוגה אנכית זה יצר עיוותים: גריד הכרטיסים התקפל לעמודה אחת, כפתורי המסנן עלו על הרשימה, טופס הפנייה יצא מחוץ לקצה הימני יחד עם כפתור השליחה.

מה היה לפני

תעבורת טאבלטים — כשליש מהביקורים, ודווקא ברוחבים האלה שיעור הנטישות נשאר גבוה באופן מורגש מאשר בדסקטופ: המשתמש הגיע לקטלוג, גלל ועזב בלי להגיע לפנייה. במקביל זרם מבול של פניות חוזרות לתמיכה — «הכפתור לא נלחץ», «לא רואים שדה», «הטבלה חתוכה». מדידות ב-Yandex.Metrica הראו נפילה בעומק הצפייה בדיוק ברוחבים הבינוניים.

מה עשינו

את הגריד בנינו מחדש לרוחבי בקרה ביניים, והרכיבים — כרטיסים, מסננים, טבלאות, טפסים — קיבלו חוקי בנייה מחדש משלהם: איפה שצריך, מידות נזילות במקום קבועות, ואיפה שצריך, מעבר לשתי עמודות במקום אחת.

טבלאות הועברו לגלילה אופקית במקום חיתוך, מידות אזורי הנגיעה הובאו לנוחות, והמרווחים נקשררו לרוחב הקונטיינר ולא למכשיר מסוים.

מה קרה בסוף

שיעור הנטישות ברוחבי טאבלט ירד כמעט פי שניים, עומק הצפייה עלה ביותר מדף. פניות חוזרות בנושא פריסה ירדו פי שלושה — התמיכה הפסיקה לטפל בתלונות חוזרות ועברה לשאלות על המוצר. שיעור המשתמשים שהגיעו לטופס הפנייה מטאבלט השווה לזה של הדסקטופ.

במה פריסה גמישה נבדלת מגרסת מובייל נפרדת

בסיס קוד אדפטיבי אחד וגרסת מובייל נפרדת פותרים אותה משימה, אבל בנויים אחרת: במקרה הראשון התבנית אחת, ואת הפריסה משנות נקודות שבירה ויחידות יחסיות; במקרה השני חי לצדו סט שני של דפים בכתובת נפרדת. ההבדל מתגלה באינדוקס, בכפילות דפים ובעלות התמיכה בפתרונות.

מנועי החיפוש בונים את תוצאות החיפוש לפי רינדור מובייל של הדף — Google מעריך בדיוק אותו. גרסת מובייל נפרדת דורשת חיבור: כתובות קנוניות, קישורים מצטלבים, זיהוי נכון של המכשיר.

טעות בה יוצרת כפילות דפים ומיקומים שנשחקו, שנראים רק אחרי שבועות; בבסיס אחד הכתובת אחת, וכפילויות לא נוצרות.

עלות התמיכה בפתרונות נקבעת לא לפי נפח הקוד, אלא לפי מספר מקומות העריכה. שני סטים של תבניות אומרים ששינוי מוכנס פעמיים, והגרסאות מתפצלות: בגרסת המובייל נשארת לוגיקה ישנה.

פריסה גמישה מקצרת את העריכה לשינוי אחד והרצת בדיקות אחת על שלושה מחלקות רוחב, אבל דורשת בדיקות לגלישות ולכותרות ארוכות.

גרסת מובייל נפרדת מוצדקת כשהתרחיש במובייל שונה מהותית או כשההעברה יקרה מתמיכה בחיבור. במעבר לפריסה גמישה אנחנו שומרים על הפניות וכתובות קנוניות כדי לא לאבד תעבורה שנצברה.

ספקות לפני התחלה: תמיכה, נגישות, דפדפנים ישנים

פריסה אדפטיבית חיה יותר זמן ממה שנדמה: המוקאפ מתעדכן, התוכן נערך, מופיעים מכשירים עם פרופורציות מסך חדשות. לכן את הגריד והמרווחים אנחנו מוציאים מיד למשתני עיצוב — עריכת רוחב עמודה או שדה נעשית במקום אחד, ולא בעשרות מדיה קווריז. בדיוק זה אומר תמיכה בפריסה: שינוי אורך דקות, ולא שחרור נפרד.

להלן ספקות טכניים שנשמעים לרוב לפני התחלה. אנחנו עונים על כל אחד באופן קונקרטי, כדי שניתן יהיה לבדוק את הפתרון על מערך המכשירים והדפדפנים שלכם, ולא לקבל אותו כאמונה.

איך בודקים רזולוציות לא סטנדרטיות?

הגריד נמתח לפי הקונטיינר, ולא לפי פיקסלים קבועים, לכן טאבלט לרוחב או יחס גובה-רוחב לא שגרתי לא שוברים את הפריסה. מקרי קצה אנחנו בודקים במכשירים אמיתיים, ולא באמולטור.

מה עם נגישות הממשק ומצב כהה?

סדר מעבר עם מקלדת, פוקוס גלוי ותוויות של אלמנטים נשלטים אנחנו מכניסים לתוך הרכיבים עצמם, ולא מוסיפים אחרי המסירה. מצב כהה נבנה על אותם משתני עיצוב ופועל לפי הגדרת המערכת; ניגודיות אנחנו בודקים בנפרד לשני המצבים.

מי עורך תוכן אחרי ההשקה?

בלוקים נבנים על רכיבים, לכן החלפת טקסט, תמונה או סדר סקשנים לא דורשת עריכות בסימון. שינויים קטנים מבצע עורך, ומפתח מתחבר כשמשתנה המבנה.

נדון במשימה: מה מבהירים בשיחה הראשונה

כדי לדון במשימת עיצוב אדפטיבי עניינית, ולא בסדרת מכתבי הבהרה, מספיקים כמה נתוני פתיחה. איתם אנחנו חוזרים עם הערכה ותוכנית: היקף העבודה, שלבים, מה אנחנו סוגרים בצד הפריסה ואיפה יידרשו החלטות מצדכם.

לא צריך מפרט טכני מוכן בשיחה הראשונה — צריך מסגרת. להלן מה שהכי מקצר את הדרך להערכה; את השאר נאסוף בעצמנו.

• משימה ותוצאה — מה צריך להשתנות: עלייה בהמרות בטלפונים, מעבר מגלילה אופקית, מראה אחיד בשלושה סוגי מכשירים.
• נתוני מקור — הפריסה והתבניות הנוכחיות, מוקאפים, גישות לשרת ולפאנל ניהול האתר, גופנים וגרפיקה.
• אנליטיקה נוכחית — שיעור תעבורת המובייל, עומק צפייה ונטישות לפי מכשירים, הדפים הנצפים ביותר.
• מגבלות הפרויקט — לוחות זמנים, בלוקים ושירותים חיצוניים שאסור לגעת בהם, דרישות לנגישות ולהדפסת דפים.
• מוקאפים ותוכן — האם יש עבודה לטאבלט ולטלפון או רק למסך רחב, מי מכין וחותך את התמונות.
• קריטריוני קבלה — סט מכשירים ודפדפנים לבדיקה ומי שמאשר סופית את התוצאה.

תארו את המשימה בצורה חופשית: זה יספיק כדי לחזור עם הערכה ותוכנית. אם אין נתונים לאחד הסעיפים — נגיד על כך מיד ונציע איך לסגור אותו.