הבעיות שיש לי עם תכנות ריספונסיבי

הקדמה

אנחנו חיים בעולם שיש בו המון מילות באזז, כדוגמת big data, responsive design, cloud computing, סייבר וכיוב' …
כל המילים האלו מגיעות מעולם השיווק, אבל לאדם טכני לא באמת אומרות הרבה.

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

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

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

מונחי יסוד

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

CSS – הם קבוצה של חוקים אשר יכולים לכסות אחד את השני (מכאן השם: Cascading Style Sheet) בצורה שתספק עיצוב למסמך.

הסבר

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

בטח תשאלו מה ההבדל בין הדברים.
ובכן, כאשר מדברים על עיצוב, אנחנו מדברים על איך המראה יהיה תחת רזולוציות שונות, אבל למשל תקשורת סלולרית (HSPA) כדוגמת 3G, 4G, LTE וכיוב', אינן נלקחות בחשבון, היות והן מדברות על תעבורה, לא על מראה.

העניין הוא, שהתעבורה של המידע צריכה להילקח בחשבון גם כאשר מספקים מערכת למכשירים שונים.
יותר מזה, אנחנו צריכים לקחת בחשבון את הזיכרון שיש למכשיר, מעבד, גודל אחסון של מידע וכיוב' כאשר אנחנו מתכננים סביבה שהיא "תכנון ריספונסיבי", אבל אלו מעולם לא היו חלק מהיכולת של HTML או CSS. כלומר מסמך HTML אינו מודע לכל זה.

כך שאולי יש מסמך איכותי עם המון מידע, שמעוצב מדהים ויודע להיות מוצג בהרבה רזולוציות, אבל האם הוא באמת יודע להגיב כמו שצריך למגבלות המכשיר אשר המסמך מוצג בו?

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

כאשר יש הבנה לדברים האלו, ולוקחים אותם בחשבון, לרוב מוצאים כי יש שניים או יותר אתרים בשביל להתמודד עם זה:

  • אתר לסביבת "שולחן עבודה".
  • אתר לסביבת "mobile".

ואם רואים שזה לא מספיק:

  • גרסה "טבעית" למכשיר מסויים (app).

any device

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

  • הבנה של מה יטען לפי סוג של מכשיר (כלומר סלולרי, שולחן עבודה, טאבלט, אינטרנט של דברים כדוגמת שעונים וכיוב' …)
  • היכולת להסביר לדפדפן (כדוגמת כרום ופיירפוקס) מה נדרש לכל הדף מול מה שנדרש לפי סוג המכשיר ו/או הרזולוציה. בנוסף גם להסביר איך להתנהג לפי יכולות המכשיר עצמו (כדוגמת מקום באחסון, גודל זיכרון וכיוב').
  • להסביר כיצד יש להתמודד עם המידע שלי מבחינת "מטמון" לפי תכונות המכשיר.

אז מה בעצם הכוונה שלי בנקודות?

סוג המכשיר

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

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

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

אבל נכון לזמן כתיבת פוסט זה, אנחנו מנחשים זאת על ידי ניתוח של "user agent" (שם הדפדפן כפי שנשלח אלינו), אך איננו מקבלים באמת את תכונות המכשיר או סוג התקשורת.
בעוד שצד ה"לקוח" (דפדפן) יודע מה הרזולוציה, אבל לא מה סוג התעבורה שבשימוש.

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

many devices

תיאור צורת הטעינה לדפדפנים

אז לרגע, בואו נגיד שיש לנו ידע על רזולוצית מסך, סוג תקשרות וכיוב'…
עכשיו, עבור רזולוציה של 300×400, אין לנו רצון להציג דו"ח עם 20 שדות, אבל על רזולוציה של 1600×900, דווקא זה די הגיוני להציג מידע שכזה (אני צוחק, 20 שדות זה נורא לא משנה בכמות הפיקסלים שבשימוש).

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

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

אמנם ניתן לבצע זאת ב Javascript, אבל אני מדבר על תאור חלק דווקא ברמה של HTML.
ובטח יהיו כמה אנשים אשר ישאלו כיצד ניתן לבצע זאת.

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

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

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

what direction to take?

אופטימיזציה

אז הזכרתי אופטימיזציה כבר למעלה. בואו ניקח לדוגמא את Bootstrap 3.3.4.
נכון לכתיבת פוסט זה, ניתן להשתמש בטעינה מאתר חיצוני (כדוגמת CDN) או מקומי של המערכת שאנו יצרנו.

אבל מה אם היה ניתן להסביר לדפדפן שאני משתמש במשהו שנקרא Bootsrap ושהוא צריך להיות בגרסה 3.3.4, ושהוא יטען אותו מקומית רק כאשר אין לו את זה ב cache ורק כאשר ה CDN לא נגיש?

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

העניין הוא שכיום לא ניתן לבצע בצורה נכונה עדכון גרסאות. למשל איך ניתן לא לבצע cache של מידע שיכול להשתנות כל הזמן?
הדרך היחידה שאני מכיר כיום, היא או לספק נתיב שונה לפי גרסה, או לספק שם שונה לקובץ (אפשר לעשות זאת גם עם פרמטרים של GET ), אבל מה אם הייתי יכול להסביר את זה לדפדפן מראש עוד בצד ה HTML?

וכאילו שהרעיון עוד לא מספק (כי יש עוד המון מה להוסיף), הנה עוד שימוש לאופטימיזציה – נניח ויש לי תמונה, והיא כרגע משמשת כ Avatar למשתמש שלי.
אם התמונה הזו לא הצליחה להיטען (לא חשובה הסיבה), הדפדפן השקיע המון אנרגיה להבין שזה המצב עד שהוא נכשל, אבל בשורה התחתונה המשתמש קיבל עכשיו חוויה גרועה, בה אין תמונה ולקח הרבה זמן לדברים להיטען (ולהגיב). אך מה אם הייתי יכול להגיד לדפדפן להחזיק בתמונת ברירת מחדל שתשמש כ placeholder שרק ובמידה והתמונה המותאמת אישית נמצאה, התמונה תתחלף באחרת?

סיכום

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

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

מה אתם חושבים?

target

9 מחשבות על “הבעיות שיש לי עם תכנות ריספונסיבי

  1. Ynon Perek

    הי,
    לא הבנתי מה חסר לך בכלים שיש היום:
    srcset לתמונות כבר מאפשר להגדיר לדפדפן להוריד את התמונה המתאימה ביותר מתוך סט תמונות אפשרי
    require.js כבר מאפשר להגדיר fallbacks לטעינת משאבים (קח מה CDN ואם לא זמין אז מהשרת שלי)
    מידע ברירת מחדל אפשר להגדיר עם Offline Application Cache

    ברור שהפתרונות שיש אינם מושלמים אבל לא הייתי אומר שיש פה בעייה ב Responsive Design. אלה דברים שנמצאים בתהליך ומשתפרים כל הזמן ואלה בדיוק הרעיונות של Responsive Design…

    1. ik_5 מאת

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

  2. Dror

    אוי ווי… כמה בלבול.

    נתחיל מההתחלה: אני מסכים איתך שהרבה מונחים מושכים דווקא מבחינה שיווקית ולאו דווקא תכנותית, אבל להגיד את זה על הדוגמאות שנתת יהיה לא מדויק בלשון המעטה. הייתי משייך את המונח Web 2.0 למונחים שיווקיים ריקים מתוכן, שלא אומרים הרבה למתכנתים. אבל responsive web design? אם זה לא אומר לך משהו מעשי מבחינת מקצועית – נראה לי שאתה בבעיה 🙂

    הלאה: "אנו מדברים על כך שעיצוב המראה עבור המערכת שלנו יתאים להרבה מאוד מסכים בגדלים שונים, אבל אנחנו צריכים לחשוב בתפיסה לגמרי שונה – איך המערכת תתנהג בכל סוג של מכשיר" (התיקון שלי). זה לא מדויק. הרעיון הוא לא להתאים את "שבירות העיצוב" (aka – media queries) במערכת שלך לכל מסך שהוא (יש הרי עשרות רבות אם לא מאות של מכשירים ברזולוציות שונות), אלא שאותן media queries יהיו לפי העיצוב שלך.

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

    מה אם בעתיד תהיה שיטת חיבור נוספת (שאינה אחת מהשיטות שציינת בפוסט: WiFi, Ethernet, GSM)? מה הם יקבלו?

    מה בנוגע לבעיית הקאשינג בשיטת ה"קבל קבצי HTML/CSS/JS מותאמים ליכולת גלישה שלך כרגע"?

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

    1. ik_5 מאת

      אוי יש לך הרבה בלבול באמת.

      סתם שאלה, מכיר את הדבר הבא?

      הרי כאן אני אומר לדפדפן מתי יש להשתמש ב css הזה – בזמן הדפסה.
      בדיוק על דברים כאלו אני מדבר.

      אני *מתאר* את השימוש בתוכן, וזה בדיוק כפי שאמרת שאני צודק בו, התפקיד של HTML, לא?!

  3. עומר - מתכנת PHP

    היי ,
    אתה קצת מאבד פה את המטרה של HTML והופך אותה למעין מוטציה של חצי שפת תכנות וחצי שפת קידוד שאמורה רק להצהיר על אובייקטים על המסך.
    התפקיד של JS ושל CSS הוא להפיח חיים באובייקטים האלו אז מדוע שלHTML תהיה סיבה לעשות את העבודות האלו בעוד שיש לה את שפת הסקריפט JS? או בעוד CSS אחראית לGriding או כל מה שקשור בעיצוב של הדף?

    1. ik_5 מאת

      ממש לא. אתה מכיר את זה שב אתה *מתאר* שבמידה ואין תמונה, שהוא יציג טקסט?
      או שאתה מתאר ב את סוג המדיה שלך?
      או שיש לך meta שמסביר האם אפשר לעשות zoom למידע שלך, וכיוב'?

      כל אלו הם *תאורים* לדפדפן, לא קוד שאתה כותב עבור הדפדפן. זו המשמעות של HTML.
      ועל זה אני מדבר.

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

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

  4. פינגבק: חשיבה מופשטת | לראות שונה

כתיבת תגובה

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

הלוגו של WordPress.com

אתה מגיב באמצעות חשבון WordPress.com שלך. לצאת מהמערכת / לשנות )

תמונת Twitter

אתה מגיב באמצעות חשבון Twitter שלך. לצאת מהמערכת / לשנות )

תמונת Facebook

אתה מגיב באמצעות חשבון Facebook שלך. לצאת מהמערכת / לשנות )

תמונת גוגל פלוס

אתה מגיב באמצעות חשבון Google+ שלך. לצאת מהמערכת / לשנות )

מתחבר ל-%s