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

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

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

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

09:05 Smashing Special

הראשון שדיבר היה  Seb Lee-Delisle (@seb_ly) והראה דברים מדהימים שאפשר לעשות עם קוד. הוא קורא לעצמו אמן דיגיטלי (digital artist). ההרצאה שלו היתה איך הוא יצר לייזר תוך שימוש ב-C++ ועוד ספריה. הוא היה צריך להשתמש בהרבה מתמטיקה, להשתמש בהרבה פרמטרים כי הלייזר הוא תלת מימדי וזז, אז כל האלמנטים צריכים להשאר הגיוניים גם בזמן התזוזה. כל הקוד שלו קורה בזמן אמיתי. בשלב הסופי הוא הראה תכנות של JS בקנווס. זה היה מעניין, ונראה פשוט מאד, כי הוא התחיל ממשהו פשוט – ריבוע צבעוני מסתובב סביב עצמו, ואחרי זה הוא הוסיף כמה פקודות, והפך את זה לריבועים צבעוניים רבים מסתובבים סביב מרכז המסך. עוד דבר שסב אוהב זה קטעי JS מתוחכמים, ויש לו אתר שבו הוא אוסף קטעים כאלה מכל רחבי הרשת.
יש לו מין גישה כזאת בהרצאה, לדבר כאילו שהוא לא יודע כלום, כאילו שהוא לא זוכר איך לתכנת (“כל החודש האחרון תכנתתי C++, אני לא זוכר כלום מ-JavaScript”) או לא זוכר איפה הוא שם את הקוד שלו. זה משעשע בהתחלה אבל מייגע אחרי זמן קצר…
הוא סיים את ההרצאה שלו בתצוגת לייזר מתוכנתת.

Componentize The Web! – Addy Osmani

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

הבא אחריו, בשעה 9:55, היה אדי אוסמאני, והוא דיבר על יצירת אלמנטי HTML מותאמים אישית. אדי תיאר עולם דמיוני שבו כל אחד יכול ליצור אלמנטי HTML שהוא צריך, או למשל מישהו יכול היה ליצור תגית HTML, ומישהו אחר יכול היה להשתמש בזה ולהרחיב אותם. או למשל להרחיב את תגית קיימת, כמו למשל תגית הוידיאו, כדי ליצור פקד וידיאו משלו. הוא הראה איך כבר היום יש אלמנטי HTML שעושים המון, בלי שאנחנו אפילו שמים לב: למשל בכמה שורות קוד אני מקבלת פקד קומבו בוקס. וזה פקד שבקלות אפשר לשנות לו את התפקוד כבר כיום: מוסיפים מאפיין multiple ואז – זבנג! -אפשר לבחור כמה אופציות בבת אחת. או, אם מוסיפים עוד תגית פנימית, מקבלים תתי קבוצות בקומבו. הדברים הקטנים האלה משנים משמעתית את הפנוקציונליות של הקומבו.
אם מסתכלים על מימוש טאב – פעם זה היה הרבה HTML ומעט JS, והיום, רוב הפונקציונליות של טאבים עברה ל-JS, וה-HTML הפך להיות בלתי מובן (כמו בג’ימייל. התסכלתם פעם על קוד של ג’ימייל?).
אדי טוען שהעולם הדמיוני הזה יכול להיות קיים כבר כיום, תוך שימוש ב-JS. ב-JS הדרך ליצר אלמנט היא document.registerElement(‘my-element’); כמה קל היה אילו אפשר היה לרשת מפקדי HTML קיימים, וגם ליצור סטיילים דיפולטיים של הדפדפן בשבילו? אז מתברר שאפשר, באמצעות ספריה בשם פולימר, של גוגל ,שמתבססת על קונספט ה-component של ה-W3C. המטרה שלה היא להקל על ייצור אלמנטים. אילו כל דבר בפלטפורמת הדפדפן היה אלמנט. אילו למשל היה אלמנט לאקורדיון. או לקלפים – במיוחד בטלפונים חכמים. חברות היו יכולות ליצור קטלוגים של אלמנטים. או אם local storage היה תגית. בד”כ צריך להשתמש ב-API-ים שלו, אבל איזה כיף היה אילו אפשר היה להשתמש במאפייני HTML, בלי שום אינטראקציה עם JS. או אפילו אם AJAX היה תגית. אנחנו בד”כ שולחים בקשה עם פרמטרים, ואז רוצים להגיב לפי התגובה שמקבלים מהשרת. ומה אם היתה תגית בשם responsive-layout המקבלת מאפיין reponsive, או תגית בשם polymer-media-query.
כשמשתשמים ב-polymer, אפשר ליצור ארועים לקומפוננטות שאנו בונים, ואמנם את הארועים עושים באמצעות Intrusive, כלומר באמצעות מאפיין בתגית ה-HTML (כמו OnClick למשל), אבל נותנים למאפיין הזה ערך של פרמטר שמוגדר בצורה מונחית עצמים.
גם הנושא של נגישות לא נשכח – למשל tab index, ויש accesibility developer tools שעוזרים לבדוק אם אלמנט שלכם הוא נגיש. הקומפוננטות הן גם ידידותיות ל-SEO. כרגע זה עובד רק בכרום, אבל יש פוליפילים לדפדפנים נוספים. מקווים שעם הזמן הדפדפנים יתמכו יותר בזה, ולא נצטרך פוליפילים. יש כבר אתר עם אלמנטים שכבר נוצרו, וניתנים לשימוש חוזר.
אבל, אדי אוסמאני  סיים את המצגת שלו עם animated gif שחזר על עצמו, ובזאת הוא רשמית הרס לעצמו את המוניטין שלו מבחינתי 🙂 .

The Chroma Zone: Engineering Color on the Web – Lea Verou

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

ב-11:15 התחילה ההרצאה של לאה ורו, על מה שנמצא מאחורי הצבעים.

איך רואים צבעים? כל פיקסל שמנראה על המסך בעצם מורכב מתתי חלקיקים שמיוצגים על ידי 3 צבעים מרכזיים – אדום כחול וירוק. הצבע של הפיקסל נקבע על יחד החשכה והבהרה של חלקיקי הצבעים (לכל צבע יש 255 חלקיקים – ובפיקסל אחד יש סב-חלקיקים בסך של 255 כפול 3 ).
כאשר מתקרבים מאוד לאוביקט שהוא לא ישר על הפיקסל ויש לו קצוות מעוגלים – כמו עיגול למשל או עיקולים של טקסט רואים שהקצוות הם לא אחידים אלא בעלי גוונים שונים. זה נובע מהשוני בהארה והחשכה של חלקיקי הפיקסל. כך למשל יראה טקסט אחרי הגדלה:

אופן הגדרת הצבעים:
ב HTML3 היו כינויים של שמות צבעים שהיו הצבעים מהפלטה של חלונות וכן שימוש בהקסה (#ffffff) כאשר 2 הספרות הראשונות מייצגות את הצבע האדום, השתיים הבאות הן ירוק וה 2 האחרונות כחול. המחשבה של שילוש של 6 ספרות שיוצרות צבע אחד מלא היא מאוד לא אינטואטיבית וקשה לחשוב ככה על צבעים.
באינטרנט, בד”כ בוחרי צבעים (color pickers) משנים קודם את אחד הצבעים, ורק אח”כ את כולם. פעם אפשר היה לכתוב צבעים רק ב-RGB. אבל זה לא אינטואיטיבי – אף אחד לא חושב על צבעים במספרי hex. ולכן אנחנו רק מעתיקים ומדביקים מ-color picker, וכשמנסים להכהות או להבהיר באמצעות שינוי של אחד מערכי ה-R,G או B, בסוף משנים את הצבע בכלל… אז RGB הוא לא דרך נוחה לחשוב על צבעים.
אחרי זה CSS2.1 נתן לנו את הפונקציה rgb שאפשר היה להעביר אליה מספרים דצימליים או אחוזים (אבל זה לא תפס), את #rgb (האפשרות להגדיר צבע באמצעות 3 אותיות, כשהדפדפן יודע לגרום לכל אות לחזור על עצמה ובכך ליצור צבע עם 6 אותיות), ואת הצבע orange (בדיוק מה שהיה חסר לנו…).
אחרי זה היה CSS רמה 3. [בשלב הזה היא יצרה מחלקה ב-JS שמתארת צבע ]. זה הביא לנו את HSL, שהוא קרוב יותר לאיך שאנחנו מתארים צבעים. אנחנו בוחרים גוון (Hue), קרבה לאפור (Saturation), ושקיפות (Lightness). הפרמטר הראשון הוא זוית. צריך רק לזכור שצהוב הוא 60, ירוק הוא 120, טורקיז הוא 240, והזויות חוזרות על עצמן החל מ-360 ומעלה. הבהירות (lightness) כאשר 50% הוא הכי בהיר, גבוה יותר הוא נוטה ללבן. כשה-l הוא 0, לא משנה מה ה-H או ה-S – בכל מקרה מקבלים שחור.
בעוד ש-RGB דומה לקוביה, הרי HSL דומה לחרוט הפוך.
hsl טוב גם לפילטרים. למשל filter: hue-rotate(240deg). sepia עושה את התמונה קצת יותר צהובה, ואפשר גם להשתמש ב-grayscale, ו-saturate(). כרום תומך בפילטר, אבל פיירפוקס צריך svg filter.
היתרון של HSL הוא שימוש פשוט בפילטרים על תמונה (עדיין בגרסת בטא אבל בקרוב יכנס לספק של CSS ויהיה נתמך יותר. כרגע עובד בכרום ובשאר מצריך SVG בשביל יצירת הפילטר).
אבל גם ב-filter לא הכל אינטואיטיבי. למשל, כשכחול מקבל L של 50%, זה לא אותו דבר כמו צהוב שמקבל L של 50%. עדיין נצטרך לכתוב בשחור על הצהוב ובלבן על הכחול. כי hsl הוא לא preceptual uniformity. דרך טובה יותר לחשב את זה היא relative luminance. זה נותן תוצאה הרבה יותר אינטואיטיבית. היא כתבה פונקציה ב-JS שעושה את החישוב הזה, והאלגוריתם שלה נלקח מהחישוב של נגישות של צבעים. קיבלנו גם אפשרות לשקיפות, עם rgba ו-hsla.
איך שקיפות מוצגת בדפדפן? הרי במסך אין פיקסלים חצי שקופים (אחרת מה, היינו רואים את החוטים שבמסך?), אלא הכל מתרנדר לפיקסל אוטם, באופן שנקרא alpha blending. אפקט מעניין נראה כשמשתמשים ה-Linear-gradient. למשל, כשעוברים מלבן לשקוף, מקבלים אפור באמצע כי שקוף זה בעצם rgba(0,0,0,0). רק בדפדפן כרום אין את המעבר לאפור אלא המעבר לשקיפות היא ללבן.
עוד דבר שקיבלנו ב-CSS3 זה עוד שמות צבעים.
ב-CSS, אם לא מגדירים ספציפית, אז הגבול והצל מקבלים את הצבע של הטקסט (כלומר, אם כותבים רק border: 1px solid בלי להוסיף את שם הצבע, אז הגבול יקבל את הצבע של הטקסט). אבל אפשר גם להשתמש במילה השמורה currentColor. אפשר גם להעביר אותו כפרמטר ל-linear-gradient. זה נתמך אפילו ב-IE9. זה מקל על תחזוקה של הקוד.
מה מקבלים ב-CSS רמת-צבע 4? את הפונקציה gray() שמקבלת אחוזים; צבעי הקסה יהיו בעלי 8 ספרות בשביל שקיפות. יש גם פונקציה color() שמערבבת צבעים. למשל color(pink blend(yellow 10%)). עוד מתאמים של color: tint() shade(). מה שבפוטושופ קוראים hsb ייקרא hwb. נקבל named hues. אפשר להשתמש בפוליפיל בשם myth.io עבוד דפדנים שלא יתמכו / תומכים בפורמטים שונים של צבע. אפשר גם לפרסר צבעי RGB עם JS. מלבד RGB יש גם מתכונת שנקראת CMYK.
ניתן לעקוב אחרי השינויים פה.

Psychology and The Perfect Design – Joe Leech

ב-12:05 ג’ו ליץ’ דיבר על פסיכולוגיה בעיצוב. הוא כתב את הספר פסיכולוגיה בשביל מעצבים – איך לרתום את הפסיכולוגיה ליצירת עיצוב מושלם. ג’ו מעצב דברים מאד פופולריים, שיוצרים הרבה כסף, ולכן כל טעות עולה הרבה מאד כסף.
בהרצאה שלו הוא דיבר על שלושה חלקים של המוח האנושי שצריך להתייחס אליהם כשבאים לעצב ממשק משתמש:

 

1. חשיבה
   הוא התחיל במתן דוגמה לחלק הראשון: בארגנטינה, כשמוציאים כסף בכספומט, קודם מקבלים את הכסף, ורק אח”כ המכשיר מחזיר את הכרטיס. זה שונה ממה שקורה בכל כספומט בכל מקום אחר בעולם (שם קודם מקבלים את הכרטיס ורק אחרי זה מקבלים את הכסף. אמנם בארה”ב וביפן חלק מהסדר שונה, אבל בשניהם קבלת הכסף היא השלב האחרון.), מה שגרם למכונה לבלוע את הכרטיס של ג’ו (פעמיים!), כי אחרי שהוא קיבל את הכסף הוא התחיל ללכת, ואז נזכר שהוא לא קיבל את הכרטיס שלו בחזרה, אבל עד שהוא חזר למכונה – היא כבר בלעה את הכרטיס… אז המודל המנטלי שונה.
   ג’ו גם סיפר על אתר של הזמנת שיט לגיל השלישי. הם עשו מספר דברים כדי לגלות מהו המודל המנטלי של המשתמשים: ראיינו אנשים; האזינו לשיחות טלפון מאנשים שעשו הזמנות שיט (בעקבות מחקר שהראה שנמכרו יותר קרוזים בטלפון מאשר באתר), וגם ישבו ליד אנשים שגלשו באינטרנט, וצפו בפעולות שלהם – בלי לשאול שאלות או לתת הנחיות. זה היה מאד מעניין בשבילו. אחרי זה הם חילקו את לנושאים את הפעולות שאנשים ביצעו. הם גילו שהאתר היה מאד מבלבל, ולכן חילקו את זה לשלבים פשוטים. שינוי של במבנה של האתר לעזור לתפקודיות שלו. אחרי השינוי של האתר אנשים קנו הרבה יותר מאשר מה שהיה קודם. צריך למפות את הדרך שבה אנשים עובדים ולתת להם את מה שהם צריכים ורוצים וזה כבר הדרך לשפר את האתר. צריך מודל מנטלי לשימוש באתר.
   אז זה החלק הראשון במוח שצריך להתייחס אליו: הקוגניציה – מחשבה (נמצא בקורטקס, במקום די עליון ומתקדם). כולנו עצלנים, לא אוהבים לחשוב (חשיבה מבזבזת 20% מהאנרגיה של הגוף). מאחר שאנשים לא חושבים, העיצוב שלך חייב לאפשר לאנשים לא לחשוב. הדבר הטוב ביותר שצריך לעשות היא לחשוב מה המידע שהמשתמש צריך בכל שלב – ולתת לו אותו.
2. רגש
   הדבר השני הוא מאמר שפורסם ב-2000, שנקרא What is beautiful is usable. יופי מעורר תחושה. למשל האתר של מלון ריץ – כולו מינימליסטי, מלבד תמונה מ-ה-מ-מ-ת של המלון. וזה נוגע לחלק השני במוח – ההרגשה  (נמצא במקום קצת יותר פרימיטיבי). מלים מעוררות תחושה. יופי יוצר סרוטונין ודופמין. דברים יפים קלים לנו לשימוש. שילוב של מלל ותמונה מעורר רגש. אז צריך לעורר הרגשה עם העיצוב. אפשר גם לעורר תחושה שלילית, אבל עדיף ליצור תחושה חיובית 🙂 .
3. אינסטינקט
   החלק השלישי הוא החלק שעוסק באינסטינקט (נמצא המקום הכי פרימיטיבי). החלק הזה בא לידי ביטוי בהרבה דברים שאנחנו עושים. שינה, אכילה, פחד. אצל פושעים החלק של הפחד די קטן. אם אפשר להתחבר לאינסטינקט הפחד או רגשות אחרים אפשר לשפר את ההמרה של האתר. אז מה זה אומר? אנחנו לא רוצים להפחיד אנשים. החלק של האינסטינקט קרוב לחלק של המוח שמזהה פנים (fusiform gyrus). שזה אומר שזיהוי פנים קשור לאינסטינקטים. יש מחקר שאומר למה אנשים נמשכים כשהם מחפשים גירוי. נראה שפנים יפים עובדים, אז כדאי איכשהו להכניס את זה לעיצוב.

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

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

Real-Life Responsive Web Design: Lessons Learned – Dave Rupert

ב-13:50 חזרנו מהפסקת הצהריים להרצאה של דייב. דייב הוא שותף בפרויקט http://shoptalkshow.com ועובד בסטודיו http://paravelinc.com.
בהרצאה שלו הוא התמקד באתגרים שצריך לקחת בחשבון כשמפתחים באופן ריספונסיבי:
דפדפנים עויינים: IE8, opera mini. הרבה מהגולשים משתמשים באופרה מיני, ואין מה לעשות נגד זה זה מבאס כשאתה מתכנת, אבל כשאתה משתמש – אתה נעלב שמי שבנה את האתר לא מתחשב במה שאתה גולש, והאמת היא שלא לכל הגולשים יש בחירה באיזה דפדפן להשתמש (למשל הדפדפן של האפליקציות).
tiny screens – הרבה אנשים משתמשים במגוון רחב של מסכים לצפייה באתרים במשך היום, ולכן מסכים קטנים צריכים להיות הדיפולט כשאנחנו מתכננים. יש ירידה של 10% בשימוש של דפדפני דסקטופ. 10% נשמע לא הרבה, אבל אילו היו לוקחים מאיתנו 10% מהכסף שלנו, זה היה נשמע משמעותי. ו-90% מהגולשים משתמשים בכמה מסכים במשימות יומיומיות. יותר קל להסתכל על פיקסלים כהרחבה (enhancement): יש דפדפנים שיש להם את זה, ויש שאין.
slow connections – ההמתנה מתסכלת אותנו. כשהוא היה צעיר הוא עבד במקדולנדס, והיה להם כלל שצריך להוציא את אוכל ללקוח עד שתי דקות. אחרי זה הלקוח נהיה בלתי הגיוני. יש מקומות שהם לא אשמתך אבל צריך לקחת אותם בחשבון – טיסה, כנס, מקום רחוק בבית. ויש דברים שהם כן באשמתך – תמונות רבות מדי, פונטים רבים מדי, יותר מדי JS, דברים לא מכווצים, בקשות לא מכווצות. ללכת לפי ההנחיות של performance budgets.
touch inputs – השינויי בצריכה שלנו ובשימוש שלנו מאוד משתנה בשנים האחרונות. בימינו, גודל שונה מ-touch – אי אפשר לזהות מסך מגע ע”י קוד ולכן כשמעצבים הכל צריך להיות מוכן לאפשרות של מסך מגע. הכי טוב לבחון את האתר על מכשיר מגע.
תהליך הריספונסיב – צריך לשחוט את הפרות הקדושות. אם אתה רואה מישהו שחושב שפיצח את תהליך הריספונסיב – הרוג אותו. [במאמר מוסגר ומשעשע, דיויד אומר ש-80% מפיתוח אתר רספונסיבי הוא דיון אילו קישורים נשארים בניווט…] ברוב החברות יש תהליך של מפל: קודם התכנון, אח”כ העיצוב, ובסוף הביצוע. לדעתם התהליך הזה הוא די עוין, כי כמעט אין קשר בין כל התפקידים האלה. לדעתו צריך שכל האנשים האלה ישבו יחד. אפשר להשאיר את התהליך הזה, אבל בגלל התקשורת זה מקל על העניין. לא להפיל PSD על השולחן של המתכנת. יש דברים שאפשר לעשות כדי להקל על התקשורת בין מעצבים למתכנתים:
להשיג למעצב גישה לסביבת פיתוח. זה כדי להראות להם את כיוון ההתקדמות, אבל להזהיר שלא יעירו על כל דבר, רק אם יש משהו שהוא דגל אדום. למעצבים: צריך ללמוד web inspector, כדי שהוא יוכל לדבר בקוד. הוא הכי ממליץ על הכלים של כרום. יש הרבה מאמרים על זה – יש לאדי אוסמאני, ולפול אייריש.
responsive deliverables – tiny bootstraps. לחלק את הדף לקומפוננטות – לבנות קטעים מודולריים של CSS ו-HTML שאפשר להרחיב ולהשתמש בכל מקום. מאפשר ללקוח גמישות. הם עשו כזה דבר למייקרוסופט, ובכך אפשרו להם להמשיך לפתח דברים גם אחרי סיום הפרוייקט.
בשורה התחתונה: 1. הלקוח לא רגיל לריספונסיב, וגם המפתחים לא רגילים לזה. 2. למצוא מישהו בתוך הלקוח שמבין עניין ויש לו השפעה. 3. תנו ל-wookie לנצח: החיים שלך, השפיות שלך, לא שווים להקריב בגלל לקוח. לא לקחת את זה ללב. לבחור את הקרבות. 4. אם אתה אוהב משהו – שחרר אותו. לתת ללקוח גמישות.

Putting Your Images on a Diet – Guy Podjarny

מצגת

סרטון ההרצאה

ב-14:40 קיבלננו הרצאה של גיא פודג’רני. ההרצאה שלו עברה על סוגי התמונות הקיימים באינטרנט, ההיסטוריה של כל אחד מהם, אפשרויות הכיווץ שלו ומה כל אפשרות בעצם עושה, והמלצה במה להשתמש. ההרצאה שלו היתה מאד מפורטת וירדה לפרטים קטנים, ועם זאת היא היתה מאד מעניינת ומעשירה.
הוא פתח בכך שתמונות נחשבו פעם דבר פשוט ולא מזיק, אבל היום אנחנו רואים לאט לאט הן משתלטות על העולם. בשנים האחרונות הרבה מזמן ההמתנה לאתר שיעלה הוא בגלל תמונות, וזה לא רק בגלל ריבוי תמונות, אלא כי יש גידול במשקל התמונות. בהרצאה הוא יתמקד בכיווץ תמונות, ולא ידבר על העלאת תמונות עצלנית, או הורדת תמונה אחרת למסך קטן יותר, למרות שאלה נושאים ראויים ומעניינים מצד עצמם.
הפורמט העתיק ביותר הוא GIF – הוא בן 27 שנה, יש בו 256 צבעים. נתמך בכל מקום בגלל ותיקותו. יש בו שקיפות פשוטה. הוציאו עליו פטנט.
PNG – בן 18 שנה. יותר מתוחכם, תומך ב-8 עד 32 ביטים של פלטות (GIF הוא 8). תומך בשקיפות חלקית. כיום יש תמיכה כמעט מלאה, מה שלא היה מההתחלה. איננו פטנט. יש בו תמיכה באינמציה, אבל אף דפדפן לא תומך בזה.
שיטת השמירה של PNG היא תוך שימוש ב-delta-filter encoding: הוא מגדיר את עצמו כדלתא הפיקסל לידו: הוא מזהה פיקסלים שדומים ומוריש להם את הצבע מפיקסל אחד והופך את הפיקסל הקיים ל 0. ככל שיש יותר אפסים המשקל נמוך יותר. אפשרות אחרת היא אם יש חלק בתמונה שחזור על עצמו, אז הוא לא חוזר עיל המידע, אלא נותן אפסים כדי להראות שזה בעצם אותו דבר. או שהוא משתמש בכיווץ הפמן (Huffman) בזה שהוא מזהה חלקים שחוזרים על עצמם ולכן אפשר לקודד חלקים פופולריים עם פחות בייטים. אפשר גם להמיר מ-PNG 24 ל-PNG 8. צריך לוודא שאם לא צריך שקיפות אלפא, לא להשתמש בה כי היא מכבידה.
JPEG – בן 22 שנה. תומך בפלטה של 24 בייטים. לא תומך בשקיפות. אין תמיכה באנימציה. זה פורמט Lossy -הוא הפורמט בעל המשקל הכי נמוך כי אפשר לכווץ אותו מאוד, אבל ככל שמורדים את המשקל גם איכות התמונה יורדת משמועותית. הוא הכי פופולרי מכל הפורמטים.
כלי כיווץ מומלץ – image magic .
יש ל-JPEG עוד מידע –איפה זה צולם, למי יש זכויות יוצרים על התמונה. אפשר להשמיט את המידע הזה וזה מכווץ את המשקל.
תמונות JPEG לא נראות טוב במסכי רטינה. יש לשקול שימוש בהעלאה של תמונה גדולה פי שתיים ממה שצריך אבל ברזולציה מאוד נמוכה בשביל שתראה טוב גם במסכי רטינה וגםבאתר הרגיל.
יש ל-JPEG שתי אפשרויות רינדור: Base line – טעינה של התמונה לאט לאט מלמעלה; ו-progressive – טעינה של כל התמונה באיכות ירודה ואז חידוד שלה. אמנם אפשר להגדיר את זה בתמונה עצמה, אבל בסופו של דבר כל דפדפן בוחר באיזו אפשרות להשתמש, כך שליוצר התמונה אין כמעט שליטה על זה. השיטה הראשונה היא המומלצת יותר לקיצור זמן טעינת העמוד אבל בגלל שחלק מהדפדפנים לא מרנדרים נכון את ה progressive ובמקום טוענים את כל התמונה באיכות מקסימאלית שלה בבת אחת, עדיין השימוש ב base-line נפוץ יותר.
אחרי זה הוא דיבר על פורמטי תמונות עתידיים: WEBP, JPEG2000. אפשר לראות את השקפים במצגת.
במהלך ההרצאה הוא גם המליץ על כלי כיווץ לכל פורמט, המליץ להשתמש ב-JPG אם אין שקיפות ואנימציה, ב-PNG בכל שאר המקרים (כי הוא כמעט תמיד יותר קטן מ-GIF), ולהשתמש ב-GIF רק לצרכי אנימציה.
עצה שהוא נתן כדי לדעת כמה התמונות מכבידות על עליית האתר: השיטה הכי יעילה היא למדוד את זמן עליית הדף בלי תמונות ואז שוב ולבדוק אחרי עליית האתר עם הוספת תמונות חדשות. ניתן לבקש גם ממנהל האתר שיעשה את הבדיקה כדי שיראה את החשיבות של העלאת תמונות בגודל נכון ומכווצות ככל שאפשר.

Hard-Won Lessons in Responsive Email Design – Fabio Carneiro

סרטון ההרצאה

ההרצאה הזאת היתה שונה במהות שלה מכל האחרות, בזה שכל שאר ההרצאות דיברו על תכנות אידיאלי, על best practices וכד’, ואילו את ההרצאה הזאת אפשר לסכם כך: עושים מה שעובד, ואלגנטיות היא ממש לא שיקול.
פביו עובד ב-Mailchimp, החברה הידועה לשרותי ניוזלטרים בדואל. הוא מפתח יחיד שעובד על תבניות דואל, והוא גם המעצב. כך שאין מי שיגיד לו מה לעשות :). במסגרת עבודתו הוא בונה תבניות דואל, קבלות, הודעות כרטיסי אשראי. יש להם יותר מ-4 מליון משתמשים. פיתוח לדואל הוא לא דבר כיפי, כיוון שזה עדיין אמנות אפילה. אין סטנדרטים כמו שיש לדפדפנים – בעוד שרוב הבעיות הגדולות בין הדפדפנים נפתרו, זה לא קרה בדואל. אחת הדרכים להתמודד עם זה היא neopolitan (?) – תבנית. בימים אלה MailChimp נפטרים מהתבניות שאינן ריספונסיב (למורת רוחם של מחלק מהמשתמשים, שרגילים לתבניות שכבר יש), כי ממחקרים מתברר שהדבר שאנשים הכי עושים בנייד זה לבדוק אימיילים… מי שמשתמש בתבנית לא צריך לדעת HTML ולא ריספונסיב.
בהרצאתו, הוא מדבר על כמה כללים מנחים בפיתוח לדואל:
כלל ראשון: צריך לעצב במסגרת המגבלות. למשל, אי אפשר להשתמש במרג’ין (יש שרותי דואל שלא מכירים את המאפיין הזה…). או לדוגמה, תגית P היא בעיה. CSS3 נתמך מעט מאד. רק עכשיו ה-W3C מדבר על סטנדרט לדואל. מצד שני, בגלל שאין סטנדרטים, עובדים כמו בשנות ה-90 – פשוט עושים מה שעובד. הקוד מבחיל, אבל פביו דווקא נהנה מזה 🙂
רוב המשתמשים אוהבים gmail, אבל זה דואל די מפגר – למשל, הוא מכריח את ה-CSS להיות inline, הוא לא תומך ב-media query. אאוטלוק למשל עבר ממנוע של IE6 למנוע של וורד. במקרה כזה, IE6 הוא חלום ורוד היות ו-word לא תומכת בהרבה מאפייני CSS בסייסים מאוד. לכן כל המטרה היא פשוט לגרום לדואלים לעבוד!
כלל שני: לעצב עבור אנשים. הדואל צריך להיות שמישותי עם אישון אחד, אגודל אחד, ובמרחק זרוע. אישון אחד: צריך לאפשר לאדם לבדוק את הדואל תוך כדי עשיית דברים אחרים. אגודל אחד: אסור שזה יפריע לך לעשות דברים אחרים. במרחק זרוע: הדואל צריך להיות קריא בלי לקרב אותו לקצה האף.
כלל שלישי: לעצב עם מטרה. סוג ראשון של דואל הוא “קנה אותי” -מבוסס על תמונות וקריאה לפעולה ברורה לקניה. המטרה היא לגרום לאדם להוציא כסף. הסוג השני הוא: “הצטרף אלי” -הזמנות לפעולה או לרישום. מסתמכים על קופי פשוט אבל תוכן ממוקד. צריך מלל מאד ברור, וקריאה ברורה לפעולה. הסוג השלישי הוא “קרא אותי”: ניוזלטר. צריך טיפוגרפיה טובה וקופירייט טוב. אלה יכולים לפצות על אורך הודאל. סוג רביעי הוא תגובה לטרנזאקציה (למשל הודעת דחיה מכרטיס אשראי). במקרה כזה יש מסר מאד ברור שצריך לעבור, וכל מה שמסביב לא מעניין. המסר צריך להיות פרקטי, ספרטני, עם מתווה פעולה ברור ואפשרות להדפיס אותו.
כלל רביעי: לעצב עבור דואל. יש הבדל מאד גדול בין עיצוב לאתר לעיצוב לדואל. מעצבים רבים נופלים בזה. דואל שמוכר לא צריך ניווט, ולא צריך קישורים למקומות אחרים, כי זה גורם לך לעזוב את הודעת הדואל, בעוד שהמטרה של הדואל היא שתישאר בהודעה והם יקבלו ממך כסף (דוגמה לזה הוא למשל הניוזלטר של zappos). לעומת זאת יש לו דוגמה של דואל שמותאם בדיוק למשהו שהוא רצה, ויש רק מה שקשור לזה.יש גם סוג דואל שמופנה לאדם, עם קופירייט שמושך תשומת לב – למשל, הצעה להראות את הפרוייקט שלו (הניוזלטר של פול בואג). עוד טעות היא שאין צורך בפוטר – במיוחד כשהלינקים שמופעים בו מאוד קטנים ולא רלוונטיים במובייל.
פעם בשבועיים MailChimp שולחים ניוזלטר עם מאמר על UX, והוא כולל בין השאר מאמר ארוך. בניגוד לאינטואיציה זה דווקא עובד, כי זה נושא שמעניין את האנשים, ואנשים רגילים לקרוא הרבה מידע בטלפון. בדואל יש כמות אינהרנטית של אמון. מי ששולח יודע מה שהנשלח אוהב, במה הוא מתעניין, אז הם לא פוחדים לשלוח דואל ארוך. הם שומרים על האמון ע”י זה ששולחים רק פעם בשבועיים. לאנשים נמאס מדואל, יש את תנועת ה-0 דואלים. עוד דבר: צריך שתהיה התאמה בין מה ששולחים לבין האתר ששולחים אליו. אם הדואל רספונסיבי, אז גם האתר שמקשרים אליו, והטופס שמקשרים אליו – צריכים להיות רספונסיביים.
הוא המשיך ונתן כמה טכניקות ליצירת דואלים מוצלחים.
טיפ ראשון: modular pattern-based email. כל היבט של הדואל הוא די fluid. מחלקים את זה לקומפוננטות: תמונות עם caption, כותרת, ניווט תחתון. מכיון שכך, הדבר היחיד שמשתנה בריספונסיב הוא הקונטיינר החיצוני.
טיפ שני: מתחילים עם desktop first. כי לא כל לקוחות הדואל תומכים בכל מה שקשור לריספונסיב. לדוגמה, sunbtraction.com. או למשל, לאאוטלוק יש בעיות עם max-width ולא תומך ב-media query. כל הקוד של דואל הוא מבוסס טבלאות. יש קונטיינר אחד ששולט על הרוחב. כדי להתמודד עם אאוטלוק עוטפים חלק מה-HTML ב-conditional comments. זה מתבסס על זה שכל חלק מהודאל הוא די גמיש ואפשר לשים אותו איפה שרוצים ולהשתמש בזה איפה שרוצים.
טיפ שלישי: שינוי מיקום לפי טבלאות. במקרה של מובייל, אי אפשר להשתמש ב-float או position. במקום זה מבצעים media query שגורם ל-TD להיות block. אפשרות אחרת היא להתשמש במאפיין ה-align של הטבלה, כדי למקם את התוכן בימין או בשמאל. כמו”כ צריך להוסיף גם את ה-block וגם width:100% כי לא כל לקוח דואל מבין block.
טיפ רביעי: המלצה באופן כללי לגבי דואל – הרבה משתמשים / ספקי דואל חוסמים את הנראות של התמונות ולכן רצוי לא להחליף כותרות עם תמונות וגם לא לשלוח תמונה אחת גדולה שהיא כל המייל.
לסיום ההרצאה הציג פאביו כמה המלצות לפני שיוצאים לדרך בעיצוב newsletter:
הוא הכין אתר בשם email template reference עם כל התובנות והטיפים שיש ל בנושא דואל. זו בעצם סוג של מתנה ממיילצ’ימפ לעיצוב דואלים.
אפשר להרשם לניוז של מייל צ’ימפ, שם יש מידע על עיצוב תבניות דואל.
לבדיקות הם משתמשים ב-litmus, ויש להם גם קהילה שעוזרת זה לזה.

Digital Adaptation — Time To Untie Your Hands – Paul Boag

ב-16:50 פול בואג עלה על הבמה, וסיפר שהמארגנים חשבו שזה יהיה משעשע לתת לו להציג את עצמו. אזה וא פשוט התחמק מזה, והתחיל את ההרצאה:
האינטרנט שינה דברים. זה שינה את הסוציולוגיה, כי אנשים כבר לא מתקשרים עם מי שקרוב להם גאוגרפית, אלא מי שקרוב לדעות שלהם. גם מבחינה פוליטית דברים משתנים: דיקטטורות מתקשות לשמור על השליטה שלהן. זה משנה את התקשורת: כל אחד עם טלפון ורשת יכול להיות עיתונאי. גם העסקים משתנים: פעם כדי להקים חברה צריך היה ללכת לבנק. היום אפשר להשתמש ב-crwod sourcing. יש גם שינויים במקום העבודה. הדבר הראשון שעושים בבוקר הוא לבדוק את הטלפון. אנחנו עושים דברים שקשורים לעבודה גם מחוץ לעבודה, יש טשטוש בין מקום העבודה לבית.
אבל את מה שאנחנו רואים כעת, ראינו בעבר, זה כבר קרה פעם: המהפכה התעשייתית. היא התחילה בעקבות הקיטור. לפני המהפכה, מפעלים היו צריכים להיות ליד מים. ואז הגיע חשמל ושינה את חוקי המשחק. אבל אפילו עשור לאחר שארגונים התחילו להשתמש בחשמל, מפעלים רבים המשיכו להיבנות ליד המים. הם לא עשו את השינוי המנטלי. זה קורה גם היום. אנחנו באופן מטאפורי עדיין בונים מפעלים ליד המים. הבוסים שלנו והלקוחות שלנו עדיין לא הפנימו את השינוי. הם שמו את הדיגיטציה בקופסה: פעם חשבו שהאינטרנט הוא בעיית IT. אחרי זה הבינו שזה כלי שיווקי, אז דחפו את זה לקופסת השיווק. אבל מעולם לא נתנו לזה להשפיע באמת. טיפוסים בירוקרטיים התעצבו ע”י העבר וכמעט אף פעם לא מצליחים להתאים את עצמם לעתיד. זה גורם לכשלונות גדולים: למשל department of industry. כל ביקור באתר שלהם עולה למשלם המסים 11.78 פאונד (אז עדיף לא להכנס לאתר). boo.com ששרפו 135 מליון פאונד ב-18 חודשים. ויש כמובן את healthcare.gov שבזבזו 319 מליון דולר. כל זה בגלל שלקחו את המודל העסקי של התעשיה הישנה.
מי ישנה את זה? אתם! רק לנו יש הבנה עד כמה הדיגיטזציה משנה את העולם. פול אומר: אתם בודאי חושבים: זה לא התפקיד שלנו! אבל כפי שמישהו פעם אמר: אם לא אתה, אז מי? זה חייב להיות grassroot, לבוא מהשטח. זה לא יהיה המנהלים, ולא הלקוחות. אם אנחנו לא נעשה את זה, נישאר מתוסכלים. אם הארגון לא עובד, זה לא יעזור כל מה שנעשה – עיצובים טובים, קוד מוצלח. ואם נגיד: אין לי השפעה, אני רק מזיז פיקסלים או קוף-קידוד (code monkey) –אנחנו צריכיםלגעת: מנהיגים אינם נבחרים, הם נעמדים בעצמם. זה הזמן שלנו לעמוד ולעשות דברים בארגון שלנו!
יש שלושה אזורים שבהם אפשר להתחיל: ניהול, אסטרטגיה ותרבות.
יצירת אסטרטגיה דיגיטלית: רבים חושבים שלא צריך אסטרטגיה נפרדת לדיגיטציה. פול מסכים עם זה, אבל יש עם זה שתי בעיות: 1. אילו כתבנו אסטרטגיה עסקית, היו מטילים ספק בהתאמה שלנו לכתוב כזה דבר. אבל בדיגיטציה לא ירימו גבה. 2. אנחנו בתקופת מעבר. הלקוחות אינם שם עדיין. בזמנו, מינו מנהלי חשמל, כי היו צריכים מישהו מיוחד שיעסוק בזה. אבל כפי שרואים היום, זה תפקיד שלא החזיק מעמד. אז גם היום, בתקופת המעבר, צריך מישהו מיוחד אחראי על אסטרטגיה דיגיטלית, עד שכולם יגיעו לאותה הבנה דיגיטלית. כדי לעשות זאת צריך להתמקד בשאלה איזו בעיה אנחנו מנסים לפתור. צריך לוודא שאנחנו פתורים בעיות ספציפיות, שנוצרו ע”י דיגיטציה, או פתרונות שרק דיגטציה יכולה לתת. הדבר הבא הוא ליצור עקרונות מנחים. אם יש משאבים מוגבלים לעבוד על משהו, אז משתמשים בעקרונות. למשל, לא ליצור דברים שכבר קיימים, או לעשות בדיקות במקום לדון דיונים. והדבר האחרון הוא, שצריך פעילויות קונקרטיות. למשל לשפר קריאה לפעולה – זה יגדיל את מספר הקונים את המוצר, או הרשומים לניוזלטר שלנו. צריך כמה פעולות מעטות, שתגרומנה להרבה תוצאות טובות.
שינוי חוקי הניהול: אנחנו בבעיה גדולה: אנחנו מנהלים כאילו שאנחנו עדיין במהפכה התעשייתית. בזמנו, העובדים היו נמוכי כשרון, נמוכי משכורת ונמוכי מוטיבציה. לכן הם היו צריכים ניהול. היום כל הדברים האלה הם גבוהים, ולכן אנשים כבר לא צריכים ניהול. אנחנו לא צריכים מנהלים, אלא מנהיגים – אנשים שמעוררים מוטיבציה. בחברה שלנו אלה שמפתחים ומעצבים יודעים הרבה יותר טוב מהמנהל, ולכן הגישה כלפיהם צריכה להיות שונה: צריך לתת להם חופש – על מה הם עובדים, איפה הם עובדים, חופש מפגישות. מדובר לא רק על מקום העבודה שלנו, אלא גם על מקום העבודה של הלקוחות שלנו. אנחנו צריכים לתמוך, להוות השראה, להיות תיבת תהודה. צריך להנהיג אותם ולא לנהל אותם. צריך לרגש ולכלול אותם, לא לנהל אותם. וצריך לבטל וועדות. כי כל מיני אנשים חסרי ידע מביעים דעה על דברים שאין להם שום מושג בהם. יש לזה פתרון: responsibilty assignment matrix. המטריצה הזו בנויה כך: יש עמודה של אנשים שעושים את העבודה. אחרי זה עמודה של מי אחראי (זה צריך להיות אדם אחד בלבד). עמודה של מי שאפשר להתיעץ איתו – אנשים שדעתם חשובה בנושא הזה. ולבסוף עמודת פעולה. וצריך לשבור את מנטליות הפרוייקטים. נוח לנהל פרוייקטים סופיים. העובדה שבד”כ זה לא עובד וחורג מהמשאבים, לא משנה. האם יש איזושהי משמעות לגאנט? כל הזמן מעדכנים אותו כי שום דבר אף פעם לא עובד לפי התכנון. סת’ גודין אומר שאנשים חושבים על אתר כמו בנין: מתכננים אותו, בונים אותו, ואז יש קצת תחזוקה. בפועל אתר הוא כמו גינה: הוא צריך nutrturing, השקעה, אהבה. אותו דבר לגבי הצוות.
האמת היא שהקהל (אנחנו) הוא לא הקהל הנכון, כי בנו מישהו כןמשקיע (עובדה ששלחו אותנו לכנס). אבל בהרבה מקומות לא משקיעים בעובדים. אנחנו עובדי ידע, ובזה צריך להשקיע – גם כנסים, אבל גם זמן ללמוד ולהתנסות.
להפוך את התרבות הארגונית על פניה: הלקוחות והבוסים חושבים שהם משלמים על אתר, אבל למעשה הם צריכים הרבה יותר: הם צריכים מישהו שיוביל אותם, שיתן להם אתר מוצלח, וכדי לעשות זאת, צריך לשנות את העסק שלהם. אם העסק שלהם לא ישתנה ויתאים את עצמו, האתר לא יעבוד. שינוי של הצוות שלנו לא מספיק. צריך לעבור למנטליות של חיי כשלון. זה משהו שנותר מהמפכה התעשייתית – פעם טעות עלתה הרבה. אם פרסמת ברושור עם המחיר הלא נכון, זה עלה המון. אבל בימינו אפשר להכשל מהר ולהתאושש מזה. צריך להתממשק עם חלקים אחרים של החברה. אי אפשר להתבחא. צריך להפגש הרבה עם הקולגות, עם הלקוחות, כי רק כך נוכל לחנך אותם. צריך לחפש באופן פרואקטיבי בעיות ולתת להם פתרונות דיגטליים, כי הרבה פעמים אנשים לא חושבים שיש פתרון דיגיטליים. והכי חשוב: עלינו להיות מחנכים. אנחנו צריכים לשנות את התפיסה של הבוסים והלקוחות שלנו, לא רק לבנות אתרים. אנחנו צריכים לראות כל הזמן את היתרונות והפתרונות של הדיגיטל. אנחנו צריכים לחנך אחרים לגבי האינטרנט והמשתמשים. צריכים להפוך את החברה שלנו לממוקדת מוצר ומשתמש. רבים מאיתנו תקועים בחשיבה פנימית. צריך כל הזמן לעשות סשנים של שמישות, כדי לראות מה הגולשים עושים, עד כמה הם מתוסכלים. צריך לדבר בשפה שלהם כדי ליצור שינוי. ROI. פתרונות לבעיות שהם מתמודדים איתם. רק אז נוכל להשפיע.
נכון שזה מחוץ ל-comfort zone שלנו, ושניתקל בהתנגדות, ונעשה טעויות. אבל אם לא נעשה את זה, אנחנו לנצח נתלונן על הבוסים והלקוחות שלנו. success is going from failure to failure without losing enthusiasm.

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

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

Mind the Gap: Designing in the Space Between Devices – Josh Clark

מצגת

ההרצאה האחרונה ליום זה, בשעה 18:00 היתה על מעבר בין מכשירים.
אנחנו די מוצלחים בתכנון לכל מיני התקנים, אבל לא בממשק בין ההתקנים. מחקר הראה שמבוגר אנגלי מחליף התקנים 21 פעמים ביום, אפילו תוך כדי עבודה על משימה אחת. 67% מתחילים קניות על התקן אחד ומסיימים באחר. איך עוברים ממכשיר למכשיר? דרך אחת היא ע”י שעושים חיפוש בגוגל בהתקן השני. הדרך השניה היא לשלוח לעצמנו דואל. יש גם דברים סימולטניים.
The behavior gap – עם התאמת האתרים למובייל התוכן נראה טוב בכל האתרים אבל הם נשארים יחידניים ולא מדברים אחד עם השני. האתגר שלנו הוא ליצור אינטרקציה שמגשרת על פעולות והתנהגות. עדיין לא נמצא הפתרון המחשבתי לגשר על הפער בין המכשירים במעבר בין פעולות. ג’וש טוען שהתטכנולוגיה למעבר קיימת אבל צריך להעביר אותה לפתרון מחשבתי שיתאם את התנהגות המשתמשים. זו למעשה התחנה הראשונה שבה אנו פוגשים את הפער הפיזי בין ההתקנים. עוד לא עלינו על ממשק אלגנטי להחליף בין התקנים למרות שזה פער פיזי קטן – ההתקנים מאד קרובים גאוגרפית אחד לשני.
שלושה פתרנות: דבר דומה היא המצאת השלט הרחוק, שליחת דואלים וסמסים, וסנכרון תוכן (למשל דרופבוקס). סנכרון הוא מובן מאליו – מתחילים לקרוא או לראות סרט בהתקן אחד, וממשיכים מאותו מקום בהתקן אחר. זה סנכרון נתונים, אבל איך מסנכרנים פעולות, כמו קניה?
יש לנו פער התנהגותי. הצלחנו לגרום לתכון שלנו להראות טוב בכל ההתקנים, אבל האתגר הוא לסנכרן התנהגות ופעילות. יש שני סוגי פעילות: טורית, וסימולטנית. דוגמה לסוג הראשון: לגוגל יש אפשרות שאתה מצלם בטלפון מפה מהמחשב שלך, והיא הופכת להיות אינטראקטיבית בטלפון. דוגמה לסוג הסימולטני: racer של כרום. זה משחק שרץ בדפדפן, עם כמה אנשים יחד. החוויה מבוזרת בין התקנים. מה שמאפשר את זה הוא  websockets עם שרת אחד שמרכז את כל המידע מההתקנים של כולם. אבל לא חייבים שרת, אפשר peer to peer. יש בשביל זה web rtc שמאפשר לעשות צ’אט עם JS שמאפשר דיבור בין דפדפן לדפדפן. כל עוד הם על אותה רשת, לא צריך שרת. שימוש בשתי הטכנולוגיות האלה לא משתפים רק תוכן, אלא חוויות. יש גם טכנולוגית bluetooth LE. אלה טכנולוגיות חשובות לשיתופי פעולה.
sonicnet.js מאפשר למחשבים לדבר ביניהם (צריך שמחשבים יידעו לדבר ביניהם כמו שפעם היה, כמו פקס). אמנם זה עושה רעש, אבל אפשר להשתמש בתדירות גבוהה יותר – אולטרהסאונד – שרק המחשב והכלב יכולים לשמוע… יש גם web audio api.
הדוגמאות האלה לא אידיאליות, כי הם משתמשות במסכים. ג’וש מזהיר אותנו מלהכנע לזה. המסכים הם מכשול. פעם המעבד היה הבעיה. אבל היום המעבדים קטנטנים, והמסך הוא ההכבדה (burden). המסכים מבודדים אותנו מסביבה, אז כדאי למצוא טכנולוגיות שלא מסתמכות על מסכים. אנחנו מנסים לעצב לאנשים, לא למסכים. פעם מסכים היתה הדרך להגיע לאנשים, אבל היום כבר לא בטוח שזו הדרך. אם שמים שני מכשירים של אפל זה ליד זה – הם מתעלמים אחד מהשני… זה אמור להיות לנו מוזר – הרי הם מאותה משפחה! צריך אינטקראקציה יותר חברתית. למשל drumpants.
איך ניצור קשר בין מכשיר למכשיר? misfit shine: סנסור שמודד את הצעדים ואת הפעילות שלך, ויש לו אפשרות להתממשק עם הטלפון שלך כך: מניחים את ה-shine על הטלפון, והנתונים עוברים. זה נראה כאילו זה דרך המסך, אבל זה רק כדי ליצור מוטיבציה לשים את שני המכשירים זה ליד זה כדי שה-bluetooth יעבוד. דוגמה נוספת: אב-טיפוס שג’וש עבד עליו עם חבר שלו, happy togehter app – יוצר קשר בין טלפון למחשב. רק נגיעה קלה בין הטלפון למחשב הנייד, ויש תגובה בין שניהם. העברת נתונים. עוד דוגמה:  grab magic – עשה אפליקציה שמאפשרת לקחת משהו שראית בטלויזיה ולשים בטלפון. כל זה לא משתמש בטכנולוגיה חדשה, אלא משתמש ביצירתיות. הטכנולוגיה כבר קיימת, וצריך רק דמיון כדי להשתמש בזה. גם קול הוא משהו שמקבל תאוצה, וגם תנועות: תנועות טבעיות נהיות mature. קול ותנועה – יוצרים קסמים. יש קסם בפערים בין המכשירים. הוא מאמין שהטכנולוגיה כבר קיימת, ואנחנו לא משתמשים בה.
never ever ever try to outmouse the mouse. צריך להשתמש בו למשהו חדש. מה הדבר החדש שאפשר להשתמש בו?  apratment finder. במקום להצביע על מחשב, מצביעים על משהו אחר. צריך סנסורים. digital becomes physical. ו-physical becomes digital? אפשר לשים סנסור על כל דבר. למשל, לשים מוניטור על תינוק כדי למדוד חום, נשימה וכד’. או מודד מספר ביצים במקרר כדי לדעת – כשאתה בחנות – אם צריך לקנות עוד ביצים.
anything that can be conmnected will be connected. הג’יני כבר יצא מהבקבוק. everyday objects are digital gadgets. לדברים פיזיים יש ייצוג דיגיטלי. לדברי ם פיזיים יש מאפיינים ותכונות, שאפשר לפעול עליהם תכנותית. זה כאילו שלדברים שלנו יש ייצוג חברתי. אם המכונית שלך היא חברה שלך בפייסבוק, או שאתה עוקב אחרי הבית שלך בטוויטר. או ה-toymail שהופך את המשפחה שלך לאוואטאר.
software makes the hardware scale. התוכנה עזרה לחפצים להיות אווטארים. היא הפכה אותם למכונות חברתיות. התוכנה תגרום לחומרה להתעדכן. homechat. מנהלים שיחות עם המוצרים בבית.
אבל הדברים לא תמיד בהכרח יאמרו דברים נחמדים. הם עלולים להעביר מסרים ספאמיים. כל דבר שיכול להפרץ – ייפרץ. צריך להמשיך לשמור על בטיחות ופרטיות.עיצוב לחיישנים ולא רק למסכים.
זו לא בעיה טכנולוגית. אנחנו מוצפים בטכנולוגיות. זה אתגר לדמיון. אנחנו זוכים לעבוד בעבודה הכי מעניינת בתולדות הטכנולוגיה, אז בוא מדי פעם נישען אחורה ונחשוב איזה דבר מדהים אנחנו יכולים לעשות 🙂

סיימנו את ההרצאות ב-19:00, והיינו כל-כך נפעמות מההרצאה של פול, שנכנענו לתחינות הבלתי פוסקות שלו במהלך היום, וקנינו את ספרו (!).

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

[הערה לגבי התמונות: לכנס הוזמנה אשה שציירה רישומים על כל הרצאה. צירפתי אותם כאן אחרי כל סיכום.]