כנס סמשינג – היום השני של הכנס

הגענו לכנס ב-8:30 כדי לתפוס את אותם מקומות שהיינו בהם אתמול, כי זה היה ממש בלב המאפליה, ונהנינו להתחכך עם כל המי ומי. פול בואג המשיך להנחות את הארוע באופן מאד משעשע. הוא פצח בסדרת התנצלויות על דברים שהוא אמר אתמול: הוא התנצל על שהוא כל הזמן קרא לג’וש ג’ון, על זה שהוא קרא ל-Booking.com בטעות Blogger.com, ועל זה שהוא קידם את הספר שלו בלי הכרה. ואז הוא הוריד את הז’קט וראינו את החולצה שלו. היה כתוב עליה Buy My Book…

And So The Mystery Begins… –The Mystery Speaker

מצגת (עם הערות של כל שקופית)

פוסט שהוא כתב על הנושא

המרצה המסתורי הוא Jon Hicks. ג’ון מעצב לוגואים וסטים של אייקונים וכתב את הספר The icon handbook
הוא דיבר על יצירת סטים של אייקונים. בשנתיים האחרונות הדרך בה מכניסים אייקונים לאתר מאוד השתנתה. עם השימוש באייקוון פונט. ביצירת אייקוןנים יש 3 שלבים:

• השלב הראשון של יצירת אייקונים, הוא שלב המחקר. בד”כ כשחברה מבקשת ממנו ליצור אייקונים, השלב הראשון הוא שהם נותנים לו טבלה עם כל האייקונים שהם משתמשים בהם. זה עוזר להם לראות איפה הם משתמשים באייקונים באופן לא עקבי, ואילו אייקונים אין להם והם צריכים.בתוך זה יש את שלב הגילוי: רוב המשקלים של אייקונים הם 16, 32, 48 פיקסלים. אבל כשיוצרים אייקונים צריך לשים לב לכל פיקסל ולוודא שהאייקון יגדל ויקטן כראוי. אפשר, כשמגדילים את הפונט, להוסיף פרטים לאייקון (עמ’ 17 במצגת).
• השלב הבא הוא שלב הציור:
  • החלק הראשון הוא השלב המטאפורי. זה השלב שבו בוחרים איך לייצג את הדבר: או שהוא אייקוני, או שהוא סימבולי. אייקוני הוא מוכר (ציור של בית לחזרה ל HOME), סימבולי הוא נלמד(גלגל שיניים להגדרות). בבדיקה שעשו גילו שאייקוניים מטאפוריים מוכרים יותר לאנשים והמזוהים יותר. כמו”כ יש עניין של עיצוב: מלא או חלול. ג’ון חשב שהמלא קל יותר לזיהוי מהחלול, אבל מתברר שחלול או מלא הוא לא קריטריון להבנה. איך מגיעים ממילה (למשל view), לאייקון? הדרך היא קודם כל לחפש. יש the noun project שמביא לך אייקונים לפי המילה שאתה מחפש. הדרך הבאה היא להשתמש ה-mindmap ולחשוב על מלים נרדפות ובכלל אסוציאציות למילה. אחרי זה מגיע שלב המטאפורה. תת-השלב הבא היא ידע מקומי: צריך לוודא שהאייקון שאתה רוצה להשתמש בו מובן באותו אופן במקום שבו אתה רוצה להשתמש בו (למשל חזיר, או ינשוף). זה המקום שבו הלקוח יודע יותר מיוצר האייקון.תת השלב הבא הוא סגנון: אם בחרת למשל משקפת בתור view , יש הרבה דרכים לצייר משקפת – מעוגל, מרובע, מצועצע, וכן הלאה (עמ’ 28). דבר נוסף הוא לשמור על פשטות, כדי לא לבלבל את המשתמש. אבל אם עושים פשוט מדי, מאבדים פרטים שעשויים דווקא לעזור לגולש (עמ’ 31-32).כלים: אילוסטרייטור, סקץ’, פוטושופ. מה שלא משתמשים – צריך להחליט על גודל האייקון והסגנון; לייצא את הפורמט הסופי בתור SVG; ולא ליצור בצורה טורית – כלומר ליצור אייקון, לסגור אותו, ולעבור לאייקון הבא – אלא להשאיר את כל האייקונים פתוחים כדי להשוות ביניהם ולראות איך הם עובדים אחד עם השני. זה כדי ליצור איזון – balance. לא כל האייקונים יהיו בהכרח באותו גודל, בגלל שלפעמים יש אייקונים שמכבידים מדי, והם יהיו חייבים להיות קטנים יותר כדי להיות מאוזנים עם חבריהם לסט (עמ’ 40). לפעמים גם מרכוז הוא משהו יחסי, ולא אבסולטי, כי לפעמים המשקל הויזואלי נמצא לא במרכז, ואז צריך להזיז את האייקון קצת כדי לאזן את המשקל (עמ’ 41-44). עוד דבר שאפשר לעשות זה ליצור רווחים בתוך האייקון, כדי ליצור עיצוב פחות מכביד ויותר מרומז (עמ’ 45).
    בתהליך הייצור, נוצרים כל מיני נקודות של מידע על התמונה, וחלק מהן מיותרות ומכבידות על משקל האייקון (שהוא בתכלס קובץ טקסט), וזה הזמן למחוק אותן. אחרי זה, מכווצים את הקובץ. הוא משתמש בכלי svgo-gui.
  • השלב האחרון הוא שלב ה-deployment.
    עד לפני כמה שנים הם היו יוצרים ספרייט ב-PNG, אבל כמובן שזה היה די מעצבן, במיוחד כשהיה צורך לענות למסכים רווי פיקסלים, ואז את כל האייקונים היה צריך ליצור במשקלים גבוהים יותר.
    אחרי זה השתמשו ב-iconFont, ויש לזה כמה יתרונות: זה קובץ קטן משקל, קל לעשות ב-CSS, הוא קל מאוד ונוח לתחזוקה – קל לשלוט על הגודל שלו וכן על שינוי בצבע שלו, והוא נתמך בכל הדפדפנים, אפילו בגרסאות ישנות של אקספלורר. אבל יש לזה כמה חסרונות: זה תהליך של עבודת נמלים; אין להם משמעות; הם מונוכרומטיים; אין תמיכה בדפדפני מובייל; אם זה לא עולה אז לא רואים כלום; הבדלי רינדור בין הדפדפנים. ניתן ליצור אייקונים דרך אייקו מון. אפשר להתמודד עם כמה מהבעיות: אפשר לכתוב את המלים האמיתיות, ולהשתמש באלגוריתם שמזהה מלים מסויימות ומחליף אותן באייקון. בעיית הצבע היחיד: אפשר לחלק אייקון לכמה אייקונים, ואז להוסיף אותם בכמה שכבות, ולתת לכל שכבה צבע משלה.
  • אבל אי אפשר היה להתגבר על בעיית התמיכה בדפדפני מובייל, ולכן עברו היום ל-SVG, שיש לו היתרונות הבאים: יצירה שלו כרוכה בהרבה פחות טרחה מאשר פונט אייקון, יש תמיכה טובה של דפדפנים, לא צריך ספרייט, יש תמיכה מאוד טובה בשכבות כדי ליצור צבעים שונים וגם תמיכה לאנימציה ב JS. משתמשים ב-Grumpicon. (משתמשים בזה למשל ב-lonely planet). מקבלים SVG, ואם אין תמיכה, מקבלים PNG. אפשר ליצור אותו באמצעות iconizr. זה משהו חדש, לא בהכרח מוכן לפרודקשן, אבל מעניין. חסרונות: המשקל יותר גדול, ויש טעינה של JS .

Scott Kellum Art Directing Posts, Sustainably

מצגת

ההרצאה הזו היתה בעיקר עיצובית ותוכנית ופחות תכנותית. סקוט דיבר על איך להנחות את העלאת התוכן עיצובית:
פעם מתכנתים היו מעלים תוכן, ומעצבים אותו בצורה מזעזעת. בימינו בכל אתר אפשר להשתמש במערכת ניהול תוכן, שניהול התוכן שלהם מתבצע ע”י עורך טקסט ולא מצריך ידע בתכנות.
הבעיה היא שמערכות כאלה יוצרות פוסטים שנראים אותו דבר באותו אתר (בד”כ זה תמונה מנחה טקסט ואיזה שהוא ליד לתוכן). זה אמנם שומר על שפה עיצובית, אבל גורם לזה שכל הפוסטים נראים אותו דבר, ואי אפשר לדעת על מה הפוסט מדבר רק מתוך הסתכלות על העיצוב שלו.
מה שסקוט רוצה לדבר עליו זה על מתן תשומת לב גדולה יותר לכל פוסט – פוסטים שמקבלים עיצוב מיווחד מותאים לצורך שלו ולייחד אותו לעומת פוסטים אחרים ולייצג נכון יותר את התוכן: תמונות משעשות או קלילות (עמ’ 20), עיצוב מיושן לפוסט על נוסטלגיה (עמ’ 21). יש להם מערכת שנקראת verge, והוא יספר לנו איך עושים את זה שם. הככלל המנחה הוא: amazing writing, beautiful images.
כשהם התחילו, לא היו מעצבים ייעודיים לפוסטים. מה שהם מציעים זה כמה תבניות לכל פוסט, שמזין התוכן יכול לבחור אחת מהן, לפי הצורך. התבנית מכניסה טקסט לדוגמה ועיצוב לתוך עורך הטקסט, ומזין התוכן רק משנה את התוכן עצמו, ואת התמונות.
בשלב הזה הם החליטו להשתפר, והם הוסיפו מעצב לעבוד על ה-verge. באותו זמן, סקוט עבר לעבוד על sb nation ושם היתה בעיה דומה. הם התגברו עליה ע”י שימוש ב-body class כדי ליצור layout שונה לפוסט (עמ’ 49). גם כאן הם השתמשו בתבניות, אלא שבכל תבנית יש חלוקה לקומפוננטות, והיתרון הוא שהחלוקה הזאת מקלה על עיצוב רספונסיבי. באותו זמן הגיע פרוייקט ploygon. זה היה קצת קשה, והם קצת חתכו בפיצ’רים, אבל עשו דברים דומים. דבר נוסף – ודי מסוכן – שהם עשו, זה לתת לעורך לערוך SASS בנוסף לעורך CSS. זה נועד לתת לעורך להשתמש ב- mixin-ים בלי שהוא צריך לחפור בקוד כדי לעשות תיקונים ושינויים קטנים של צבע לפוסט (עמ’ 55).
עכשיו הם מריצים אפליקציה בשם Chorus (עמ’ 57). משתמשים ב-middleman ויצרו קישור בינו לבין chorus. הבעיה עם MM הוא העלאת תוכן ולכן הם משתמשים בגוגל דוקס כדי ליצור תוכן שיכול לעלות לאתר סטטי. בימינו הם נותנים לבחור כמה קומפוננטות לכל פוסט, במקום תבנית אחת לפוסט כולו.

Leveling Up With Flexbox – Zoe Mickley Gillenwate

מצגת, סיכום וקישורים

סרטון ההרצאה

זאת, מבחינתנו, היתה ה-הרצאה של היום, בהא הידיעה. היא היתה ההרצאה היחידה עם קוד, ויצאנו ממנה עם כלים ברורים וממשיים.
ה-flexbox הוא מאפיין CSS שנועד במהותו לסדר פריסה (layout). זואי מספרת שפעם היא היתה נושאת הרצאות בנסיון לשכנע לפתח אתרים באופן פלואידי (fluid). אחרי זה שהתקופה ההיא עברה, היא רק היתה צריכה להסביר איך. אותו דבר עכשיו עם ה-flexbox – ההרצאות שלה נועדו לשכנע אותנו להתחיל להשתמש בזה למרות שזה עדיין לא נתמך בכל הדפדפנים.
פלקסבוקס בימינו הוא די נתמך, אולם מאחר שהוא לא נתמך באופן גורף, זואי מציעה פתרון ביניים: אפשר להשתמש בו על חלק מהמרכיבים של הדף, בתור progressive enhancement, גם אם עדיין אי אפשר להשתמש בו על הדף כולו (פן האתר ייראה לא טוב בדפדפנים שאינם תומכים). אמנם פעם חשבו שצריך תמיד להתאים לאקספלורר ושהאתר צריך להראות בדיוק אותו דבר בכל הדפדפנים, אולם היום מבינים שזה בסדר אם יש דברים שנראים אחרת באקספלורר (התהליך מתואר יפה בשקופית 5), ולכן אפשר להשתמש בפלקבוקס עבור דברים קטנים, שלא נורא אם לא ייראו אחרת בלי הפלקסבוקס.
איך להשתמש:
צריך לדעת שהתחביר (syntax) של פלקסבוקס עבר כמה תהפוכות, ויש דפדפנים שעדיין תומכים רק בקוד הישן. יש כל מיני כלים שעוזרים למפתחים לכתוב את הקוד כך שיעבוד גם לפי התחביר הישן וגם לפי החדש (שקופית 9).
הדבר הראשון שצריך להגדיר זה ב-disply: flex. את זה מגדירים על האלמנט שמכיל אלמנטים שאותם נרצה לפרוס בצורה פלקסית. זה הופך את כל האלמנטים שהוא מכיל ל-flex-items.
בשלב הבא, אחרי זה צריך להחליט אם רוצים שהתוכן יוצג לאורך או לרוחב, ולשם כך משתמשים ב-flex-dierection. יש flex-wrap  שנועד להחליט האם ובאיזה כיוון האלמנטים יתנהגו אם אין מספיקמקום בשורה, אבל הוא כמעט לא נתמך. ויש flex-flow שאיו קובעים את שני המאפיינים שהזכרנו, בבת אחת.
זואי יצרה אתר שבו היא מראה את כל השימושים שהיא מדגימה בהרצאה שלה היום.
הדוגמה הראשונה שהיא נותנת לשימוש בפלקסבוקס היא ניווט העליון מוצג לרוחב (בשקופית 14 היא מראה איך אפשר לעשות את זה ללא פלקס): כדי ליצור ניווט, ניתן ל-ul הצגה של פלקס. כדי להגדיר שכל הפריטים הם בעלי רוחב שווה ומוצמדים לצדדים, נותנים לרשימה:justify-content: space-between. זה יעבוד גם אם התצוגה היא לאורך. זה מסדר אותם לאורך הציר המרכזי. (align-items: stretch מסדר אותם לאורך הציר הנגדי). אפשר לשלב את זה עם display: inline-block בתור גיבוי עבור דפדפנים לא-תומכים. אמנם הגיבוי הזה ייצור הבדל קל בתצוגה, אבל זה עדיין ייראה טוב.
וריאציה על זה היא דפדפוף (שקופית 23), ו-וריאציה אחרת היא אייקונים מוצגים לאורך (שקופית 24). בשקופית 26 היא מראה את כל התצוגות האפשריות של display-items. את הוריאצי ההזאת אפשר לשלב עם גיבוי של table-cell, או עם גיבוי של float. אם משתמשים ב-float צריך לדעת שיש איזה באג שגורם למשהו שיש לו float ו-flex ביחד להעלם, והפתרון הוא לתת poistion: relative. עם זאת, יש גיבויים שלא משתלבים טוב עם פלקס, ואז הפתרון הוא לתת CSS שונה לדפדפנים שלא תומכים. אחת הדרכים לעשות זאת היא להשתמש ב-modernizr, שנותן class-ים לפי יכולות תמיכה.
לסיכום, כך יצרנו רשימה לאורך או לרוחב עם רווחים שווים.
הדוגמה הבאה היא הצמדת אלמנט לתחתית האלמנט המכיל. למשל, פוטר שנצמד לתחתית הדף (שקופית 34). לשם כך משתמשים במאפיין ה-flex, שתפקידו הוא לאפשר ל-flex-items לשנות את הרוחב (או הגובה, תלוי מי הציר המרכזי) שלהם. אני לא אכנס פה להסבר התחבירי, יש את זה בשקופיות 37-40.בשקופיות 41-45 היא מספרת על ההבנה השגויה שלה לגבי הערכים שהמאפיין flex מקבל, מה היתה התוצאה של הבנה זו, ואיך היא תיקנה את זה.
היתרונות של פלקס (שקופיות 46-54): אפשר לגרום לדברים להיות רספונסיביים בלי להצטרך breakpoints, אלא הדפדפן מחשב מתי יש מקום ומתי צריך להפיל דברים; flex מטפל גם ב-margin” מה ש-box-sizing לא עושה; הוא משתנה בהתאם לכמות הפריטים; הוא יכול לאחד בתוכו כמה סוגי יחידות (פיקסלים, em-ים, אחוזים); הוא מאפשר חלוקה פרופורציונלית בלי צורך לחשב (אבל צריך לשים לב שהחלוקה הזאת עובדת קצת שונה כשלחלקים השונים מוגדר רוחב…).
בחזרה לדוגמית שלנו על הצמדת אלמנט לקצה של אלמנט מכיל: הפלקס נותן התנהגות חדשה ל-margin: auto (שקופיות 55-63, כולל הצעות ללגיבוי עבור דפדפנים לא-תומכים).
אחרי זה היא עברה לוריאציות: חלוקה של של סרגל ניווט לשני חלקים, אחד מוצמד לימין ואחד לשמאל; הרחבה של אחד האלמנטים בשורה כך שימלא את המקום הנותר (בשקופית 74 היא מראה את ההבדלים בתוצאה בין שימוש בפלקסבוקס לבין אי-שימוש בו. למרות שאין זהות בין שתי התוצאות, בשני המקרים זה נראה טוב);
והנושא האחרון שהיא דיברה עליו הוא סידור מחדש ויזואלי של פריטים (שקופיות 78-הסוף).
ואידך זיל גמור.

Connecting Content, Layout, and Device Through Fluid Grids – Nathan Ford

סרטון ההרצאה

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

מתודולוגיית עבודה – המפל הוא לא מוצלח בכלל אבל אג’ייל הוא לא תמיד נוח בתכנון של עיצוב כי עיצוב מצריך זמן. ולכן תהליך העבודה שלהם מורכב מחלק מהיסודות של אג’ייל. שיטת העבודה שהם מצאו שמתאימה להם היא EATT – everythinng all the time. גם בשיטה זו, יש שני אתגרים בעיצוב של ריספונסיב: תהליך עבודה, ובדיקות. בתהליך העבודה, לא ברור מי אחראי על מה. מה בא ראשון העיצוב או התכנות. זה מצריך קשר בין מעצב מתכנת. הבדיקות הן מאתגרות כי יש אין סוף פלטפורמות.

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

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

1. עיצוב צריך להתחיל בתוכן.
2. לתכנן את המבנה מהתוכן והחוצה
3. להתאים את התוכן למכשיר

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

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

The Component Approach – Wilson Page

מצגת (ניווט באמצעות חיצי המקלדת)

אחת הדרכים להתייחס לדף HTML היא לחלק אותו לנתחים, כאשר כל חלק הוא קומפוננטה. ההרצאה מדברת על יצירת קומפוננטות בדף HTML. הוא מגדיר קומפוננטה כחלק שיחד עם אחרים יוצר משהו גדול יותר. הכוונה היא פשוט שימוש באלמנטים קיימים, ויצירת אובייקט עם מאפיינים מתוכו. למשל, תגית הוידיאו: יש לו API ציבורי, ארועים, אלמנט HTML-י, עיצוב CSS-י והתנהגות JS-ית. לא צריך ספריה כדי ליצור קומפוננטה – שקופית 17 מראה קוד JS שבעזרתו אפשר ליצור קומפוננטה לבד. ספריה נותנת להם מספר יתרונות: קוד עקבי, יכולת פעולה הדדית (interoperability) והפשטה של חזרתיות. הם כתוב ספריה בשם fruitmachine כי הם היו צריכים כמה מאפיינים שלהם (שקופיות 23-31).
הקומפוננטה צריכה להיות כמוסה. אסור לה להסתמך על אלמנטים אחרים, אלא על פרמטרים שמועברים לה. כך קל להשתמש בה שימוש חוזר. כמו-כן, כשקומפוננטה היא כמוסה, אפשר לעבוד עליה בנפרד משאר האתר, ומי שעובד עליה מגדיל את תחושת האחריות שלו, כי היא יכולה להנתן לפיתוח למישהו אחד, והוא ה”אבא” שלה. גם כשקורים לה ארועים, היא לא אמורה להחליט מה קורה בארוע, אלא רק להודיע שהארוע קרה, ואפליקציה תחליט למה לקשר את הארוע הזה (שקופית 50) . הם משתמשים ב-bubbling בספריית fruitmachine כך שאלמנט מקונן יכול להודיע לאלמנט ההורה שקרה לו ארוע.
המרצה המשיל את זה לעץ (שקופית 56) – הגזע הוא נקודת הכניסה לקוד. ומתפשט לענפים שונים.הנקודה הבאה שהמרצה דיבר עליה היא performance. צריך לשים לב ל-DOM ולהתייחס אליו יפה. ה-layout הוא הפעולה של ציור הדף ע”י הדפדפן. פעולת ה-layout היא יקרה, לכן צריך למעט בה ככל האפשר. למשל, אם אנחנו כותבים ל-DOM ואח”כ רוצים לקרוא מאפיין מתוך ה-DOM, זה גורם לדפדפן לצייר את הדף מההתחלה, ואז גורם לדף לעלות לאט. פתרון לכך הוא ספריה שהמרצה כתב, FastDOM, שמאחדת את כל הכתיבות והקריאת בבת אחת, כך שה-layout קורה רק פעם אחת בכל עליה של דף. אפשר גם לצמצם את הרינדור רק לאלמנט מסוים כדי להגביל layout bounderies.
עיצוב של קומפוננטה: הדרך הכי נוחה היא ליצור קובץ CSS לכל קומפוננטה. אמנם זה יוצר הרבה קבצים, אבל זה עוזר למקד את העבודה של כל קומפוננטה. כדי להמנע מזליגה פנימה והחוצה, לא מספיק לתת שם מיוחד לאלמנט החיצוני ולתת שמות רגילים לאלמנטים הפנימיים, אלא כדאי לתת תחילית מיוחדת לכל class של אלמנט פנימי.
התנהגות רספונסיבית (שקופית 87-): באפליקציה ריספונסיבית קומפוננטות צריכות לשנות את המראה שלהן. ומה עם התנהגות? התוצאה היא אותו markup, התנהגויות שונות ועיצובים שונים. הדרך להתמודד עם זה היא ליצור מאפיינים לקומפוננטה: small, medium ו-large. לכל מאפיין נותנים את ההתנהגות המיוחדת. אבל איך כל מאפיין יודע באיזו רזולציה לעבוד? שמים media query שנותן ב-after מאפיין content מתאים, ואז ב-JS מזהים מה יש ב-content של ה-after ולי זה מפעילים את המאפיין הנכון (שקופית 97).
ב-JS כדאי להשתמש ב-matchMedia במקום getLayout/width/getComputedStyle. זה מקשיב לרוחב, ולא עושה בעיות performance.
לסיכום (שקופית 109) הדרך הכי טובה לבנות אפליקציה גדולה היא לא לכתוב אפליקציה גדולה, אלא לפרק אותה לקומפוננטות קטנות.

Responsive Web Typography – Marko Dugonjic

מצגת

ההרצאה הזו היתה לא-מן-המניין, כי המרצה המקורי חלה. מרקו דיבר על טיפוגרפיה רספונסיבית.
למה קורה שאתרים שנראים ומעוצבים מעולה בדסקטופ נראה לא טוב בצורה הרספונבסבית שלו? זה קורה כי הם התחילו בגרסת דסק טופ. מה צריל לעשות כי שתהיה חוויית קריאה טובה בכל הרזולוציות? להשתמש ב-media query, להשתמש בפריסות (layouts) גמישות, ולהשתמש בתמונות גמישות.
מרקו נותן רשימה של משתנים שמשפיעים על חוויית קריאה רספונסיבית:
מרחק קריאה: כרגע אפשר לשער את מרחק הצפייה של המשתמש מהמסך לפי הרזולוציה של המסך אבל זה לא מדוייק. בעתיד יהיה אפשר לזהות את הפנים שלהמשתמש ולחשב את המרחק של הקורא ולפי זה להציג לו גודל פונט מותאם.
טיפ:  אם קובעים את המרג’ין התחתון על קטעי הקריאה כמו גובה השורה, שומרים על רצף קריאה נעים. line-height: 1.5; margin-bottom: 1.5em;
רוחב המסך (viewport width): כמות התווים בשורה צריכה להיות בין 45 ל-75 תוים. במסכים קטנים נכנסים פחות מ-40 תוים. ככל שהשורה ארוכה יותר, גובה השורה צריך להיות גבוה יותר, ולהפך. הדרך לבדוק את הגובה היא לשים שורה של אותיות ארוכות כלפי מטה מעל שורה של אותיות ארוכות כלפי מעלה (למשל באנגלית, לכתוב שורה של q מעל שורה של d). דרך אחרת היא לצייר שורות בטקסט (פעם היה צריך ליצור תמונה, היום אפשר להשתמש ב-background-image שבתוכו linear-gradient ולשלוט בגובה). צריך להבין שיש 3 ריווחים שונים בטקסט, תלויים זה בזה: רווח בין אותיות, רווח בין מלים, וגובה שורה.
היררכיית תוכן: גודל הכותרת תלוי באורכה ובכמות הכותרות הפנימיות שיש במאמר. דרך אחת ליצור היררכיה היא ע”י הקטנת הגופן ככל שיורדים בהיררכיה. יש סולם טיפוגרפי קבוע (מה שיש בפוטושופ) אפשר לבצע הגדלה של 16 במחשב 18 בטאבלט ובנייד 21. דרך אחרת היא לשנות עיצוב. למשל צבע, משפחה ומשקל שונה.
עובי מידע: בעיה ידועה באתרי חדשות. כשיש הרבה מקום, נכנסים באנרים, ואז המלל צריך להיות יותר מושך מהבאנר. כשיש פחות מידע אפשר לתת עיצובים שונים למלל, קטעים מוזחים וריווח. שיש הרבה מידע צריך להשתמש בהפחתה שלגודל פונט.
רוויית פיקסלים: ישנם יצרני פונטים שלוקחים בחשבון רוויית פיקסלים, והפונט עובד גם במשקלים נמוכים. כיום יש פונטים שמעוצבים במיוחד למסך ויכולים להיות קטנים מאוד ועדיין להיות קריאים. יש משפחות פונטים שמעבירות משקלים שונים לרזולוציות שונות, ועושים זאת ע”י שב-media queries מגדירים URL שונה של פונטים לאותה משפחה.
אוררינטציית מסך: אותו גודל פונט לא עובד גם לאורך וגם לרוחב – חייבים לשנות גודל פונט. חשוב שהכותרות תתפוסנה את כל רוחב המסך. אפשר גם לשנות ריווח בין אותיות ולהשאיר את אותו גודל (מכניסים ל-media-query את התנאי orientation:portrait או orientation:landscape). זה לא פשוט לעשות את זה בכל הרזולוציות, אבל אפשר להשתמש בפלגאין של jQuery בשם FitText.  אין הרבה פונטים שמתאימים לתצוגה אופקית של מסכי טאבלט.

Hardware is Hard, so Is Software: Product Development in Bits and Atoms – Tyler Mincey

סרטון ההרצאה

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

A Modern Designer’s Canvas – Andrew Clarke

על אנדרו קראתי לפני שבאתי לכנס, מפני שנרשמתי לסדנה שלו ביום חמישי. קראתי על ההחלטה שלו להחליף את השם שלו מאנדי לאנדרו (סיפור די נוגע ללב, למען האמת), והאזנתי לפודקאסט מאד מעניין שלו עם ג’פרי זלדמן, ושם גם שמעתי ממנו על השיטה החדשה שלו להרצות – בלי מצגת.
למרבה השמחה, סמשינג פרסמו את תמליל ההרצאה שלו, כך שאפשר לדעת בדיוק מה הוא אמר, אפילו בלי להיות שם :). אמנם בכל זאת הבאתי פה את הסיכום של רחלי ושלי (מאחר שלא ידענו שהוא יפרסם את ההרצאה שלו), אבל אני מאד ממליצה ללכת לקרוא את המקור.
ההרצאה שלו היא תובנות וסיכום של שני הימים האחרונים. אנדרו מדבר על ארבעה לקחים שיעזרו לנו לעבוד טוב יותר:
1. מצא מדיום שמבטא את תחומי העניין והכשרונות שלך
2. אל תשתכר מתהליך ואל תתאהב בכלים
3. הטל ספק במה שנאמר לך, גם בדברים ששמעת בכנסים או קראת במאמרים
4. סלול את הנתיב שלך ואל תלך בנתיבים של אחרים
מדיום שמבטא את תחומי העניין והכשרונות שלך
אנדרו הלך לבי”ס לאמנות, ששם הוא קיבל בטחון לעשות דברים: לאמץ סטדרטים, לעשות ריספונסיב. לפני שבהוא הלך למוד אמנות, אנדרו חשב שהוא מאד מוצלח באמנות, אבל כשהוא הגיע לאוניברסיטה הוא הרגיש שכולם שם יותר חכמים ממנו. גם אנחנו מרגישים כך: בעבודה אנחנו מומחים, אבל כשמגיעים לכנס מרגישים שכולם יודעים יותר מאיתנו.
הטכנולוגיה אמורה להקל על חיינו, אבל קשה לחשוב על תעשיה אחרת בה דברים משתנים כ”כ מהר. יש לחץ להיות מומחים בכל דבר, וזה מתעצם כשמרגישים שכל אחד יודע משהו שאנחנו לא. עכשיו שהדפדפנים מתנהגים יפה, אין הרבה צורך במפתחי אינטרנט. בימינו בודקים אם מפתח פרונט-אנד יודע backbone ,angular, node וכד’. אבל האם כל מפתח כזה צריך לדעת את אלה? יש כאלה שטובים בבניית אתרים יפים, ולפעמים הם מרגישים “פחותים” כי הם לא “טכנולוגיים”. אבל זכרו: כדי ליצור משהו יפה צריך ידע ונסיון. זה לא משהו שטחי, אלא כשרון שעלינו להתגאות בו! איננו צריכים ללמוד הכל, אבל עלינו ללמוד דברים שיעזרו לנו לעשות את מה שאנחנו עושים הכי טוב. לכו אחרי מה שאתם אוהבים, אבל זה לא תמיד יהיה מה שחשבתם. למשל, אנדרו מספר שכשהוא היה מצייר, הוא היה מתמקד בחלק מסוים של התמונה עד שהוא היה מושלם. אבל הוא לא קיבל את המראה הכללי של הציור, ודברים לא נראו טוב ביחד. התברר לו שהוא לא טוב בציור, והוא עבר לאמנות אחרת. בסופו של דבר הוא עשה את מה שהוא אהב, אבל זה לא היה מה שהוא חשב שזה יהיה.
אל תשתכר מתהליך ואל תתאהב בכלים
אחת הסיבות שבגללן אנחנו מגיעים לכנסים היא כדי ללמוד איך עושים דברים נכון. אבל מה אם אין דרך אחת נכונה, מה אם חלק מהדברים שלימדו אותנו בכנס מתאימים רק בחלק מהמקרים? זה יכול ליצור ציפיות לא נכונות. PSD נהיו המטבע של האינטרנט. אנחנו  שולחים אותם ללקוח תמורת אישור, ולאחר מכן תמורת כסף. אבל בעצם הם ממש לא מתאימים לתפקיד שלהם – זה כמו להביא סכין לקרב אקדחים – הם מביאים רק ויזואליה סטטית. אבל אנחנו רגילים לכלים שיוצרים אותם. במקום להשתמש בהם כעזרים לתקשורת, אנחנו נותנים להם לדבר במקומנו. אנחנו משאירים המון מקום לאי הבנות: הפונט לא יהיה אותו דבר בכל המסכים. הפריסה לא תהיה אותו דבר בכל מכשיר. אנחנו מחפשים אישור, שמישהו יחתום על העיצוב, כדי לסיים את העסקה, או להעביר אותה לשלב הבא. אבל בעצם אנחנו מבקשים ממישהו להסתכל על התמונה ולהסיק איך ייראה האתר. אבל כדי שהשיפוט שלהם תהיה משמעותי, הויזואלים שלנו צריכים להיות הרבה יותר קרובים למה שהאתר באמת יהיה. כשאנחנו שולחים את הסקיצה, אנחנו מתחייבים שהאתר ייראה בול כמו הסקיצה. ובגל זה רוב העיצובים שלנו הם בעלי רוחב קבוע וממורכזים. מה שחשוב בד”כ הוא לא איך מעצבים, אלא איך מתקשרים את העיצוב. לכן הפתרון שלו הוא להראות עיצוב של קומפוננטות שונות, בלי שום התחייבות איך תיראנה הקומפוננטות האלה במסכים שונים. צריך להפריד בין הפריסה של הקומפוננטות על האתר – שבודאי תהיה שונה במסכים שונים – לבין האטמוספירה של העיצוב, המתעוררת באמצעות צבע, מרקם וטיפוגרפיה. אבל עם כל זה שיש הגיון בשיטה הזאת, אנדרו נמנע מלכנות אותה תהליך. הוא יודע שהתהליך הזה לא עובד תמיד, והוא לא נכון לכולם, וחשוב לו מאד שאנשים לא ישתכרו מתהליכים  ויתאהבו בכלים כל-כך עד שישכחו מה בעצם הם מנסים לעשות.
הטל ספק במה שנאמר לך, גם בדברים ששמעת בכנסים או קראת במאמרים
נדבר על הטלת ספק ברעיונות. חשוב להקצות זמן להיות יותר יצירתיים, להפחית חזרתיות. לעצב מערכות במקום לעצוב דפים. בראד פרוסט דיבר על עיצוב אטומי ומולקולרי, בהתבסס על טבלת היסודות של כימיה. מצד שני יש לגישה הזאת מתנגדים: זה מאוד מדכא את היצירתיות. לא בטוח שהדרךהזאת נכונה ליצירה ולעיצוב: זה לא תהליך של עיצוב אלא מכונת ייצור עיצוב. יצירתיות לא יכולה ולא צריכה להיות צפויה כמו ייצור המוני. לא טוב לרתום את העיצוב לתהליך קבוע. לכן המסקנה היא להטיל ספק במה שלמדתם בכנס, ולשאול את עצמך האם אתה יכול לעשות את זה יותר טוב. לפעמים ספרי/סרטי המשך הם טובים יותר מהספר הראשון. המסקנה היא שאין שום דבר שאיננו יכולים לשפר. יש לנו מזל בתעשיה, שאנחנו יכולים לקחת משהו שמישהו עשה, ולשפר את זה. בלוגים, RSS וטוויטר פירושם הוא שאנחנו יכולים לשמוע על דברים כמה דקות אחרי שנוצרו. CodePen ו-Github מאפשרים לפצל את הקוד ולשפר אותו. לחלוק קוד עוזר לשפר אותו. לפתח רעיון – לוקח זמן וסבלנות. לאתגר את החשיבה שלנו במיוחד אם יש עוד אנשים שיש להם עניין בתוצאה שלכם. לאתגר קונבנציות. יותר מדי פעמים אנחנו ממעיטים בחשיבות של רעיון כי אנחנו מפחדים מהתוצאה או מהכישלון. צריך לשאול שאלות. זה לא מזלזל במי שהגה אותם, אלא מכבד אותו, מעצים את התהליך. כשאתה רואה שמתייחסים לרעיון שהגית, משפרים אותו, שהוא מקבל חיים משל עצמו, זו תחושה נפלאה. לפעמים אנחנו חושבים שאנחנו לא ראויים לשפר רעיון, כימי שהגה אותו הוא כל-כך הרבה יותר מוכשר/חכם/מנוסה מאיתנו, אבל עלינו לזכור שכל אחד מביא נקודת מבט חדשה לרעיון, ונקודת המבט הזו היא שווה כמו כל נקודת מבט אחרת. שאילת שאלות מעוררת רעיונות חדשים ויצירתיות. יצירה של משהו מיוחד.
סלול את הנתיב שלך ואל תלך בנתיבים של אחרים
הרבה פעמים אנחנו מרגישים בודדים, לא מצליחים לזרום עם רעיונות חדשים, גם כשאנחנו עובדים עם אחרים, כי מצמצמים אותנו להגדרת תפקיד מסויימת (מעצב, מפתח, מומחה ממשק משתמש). במקרה הטוב זה מגביל את מה שאנחנו יכולים לעשות, ובמקרה הגרוע זה מגביל את מה שאנחנו שואפים אליו. להכנס לנעליים של משהו אחר יכול לעורר את המחשבה שלנו עליו ועל היצירה שלנו.  ומלבד שאלת למה, צריך לשאול “מה אם”?
לסיכום
הלימודים בביה”ס לאמנות לימוד את אנדרו הרבה דברים, על עבודה ועל עצמו יותר מאשר על אמנות. הוא לימד אותו שהדבר הכי חשוב בחיים הוא להיות סתגלן (adaptable). הוא נמצא היום במקום שהוא לא דמיין לעצמו, וגם אנחנו עוד 10 שנים נהיה במקום שאיננו יכולים לדמיין כעת. הוא גם למד שקל מדי להתאהב בתהליכים או בכלים, אבל אם משתמשים בהם בלי מחשבה, הכלים והתהליכים עלולים להוות הסחה.
תחלקו מה שלמדתם, מה שעשיתם, כדי שאחרים יוכלו ללמוד מהם. ההחלטה להיות נדיב היא הבסיס של התחום שלנו להתקדם.

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

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