Fronteers 2016: Day Two
My notes for the 2nd day of Fronteers 2016.
Jason Grigsby: Adapting to Input
In the beginning
- Web was formless
- Forms only added when web became commercial
- Web was 640x480> 800x600 > 1024x768 etc.
- Consensual hallucination: instead of us having somebody trick us, we trick ourselves. Makes our lives easier.
- The web never had a fixed canvas.
- Desktop = keyboard, Mobile = touch.
Time to break free from these assumptions
- Input is exploding
- Focus on broad adaption
- Using Apple as a lens
- 1874: First keyboard
- 1984: Mouse, tracksballs, joysticks
- 1996: Mouse with scrollwheel
- 2005: Cameras in phones/computers
- 2007: iPhone
- 2008: MacBook Air - trackpad/gestures
- 2009+: Gyroscopes, multi-touch trackpad, Siri, Bluetooth LE, fingerprint sensor, NFC, Barometer, 3D Touch
- Every single year new sensors, capabilities, etc.
- We can no longer make assumptions about input based on screensize.
Input is undetectable
- ” I got this. I detect touch.”
- Not that easy/possible to accurately detect touch.
- Chrome thinking about enabling touch by default
- Cannot detect mouse, keyboard etc.
- This saves us from ourselves.
- Input is much like Schrodinger’s Cat: we don’t know what type of input user will use, until they do so: too late for our UI
- a continuum
- transient (can change very quickyl)
- The larger a target is, the easier it is to select it.
- Every desktop UI should be designed for touch now
Design for modes of interaction instead of input
- Display density settings in GMail
- Designing for user need, not form factor/input
Make things accessible
- TV browsers that support d-pad, send arrow key events
- If remote control, support arrow keys = Wrong. Just support arrow keys.
Design for multiple concurrent inputs
- Examples of Google Maps using touchpad and touch at the same time.
- Don’t assume users will only have/use one form of input
Abstract baseline input
- Don’t think of mobile/tablet/desktop ==> small/medium/large
- Need to do something similar to input ==> point, select instead of mousemove, click, touchstart, …
Progressively enhance input
- Opportunity is knocking
- We’re pretty good at using Geolocation
- Other inputs barely used: compass, gyroscope etc.
- Scan creditcards on iOS
- Remember to support auto-fill (use autocomplete attribute)
- Payment Request API
Make input part of test plans
- Need to add new ways of input to device lab (Apple Pencil, stylus, …)
- Design for the largest target by default
- Design for modes of interaction instead of input
- Make things accessible
- Design for multiple conccurrent inputs
- Abstract baseline input
- Progressive Enhance input
- Make input part of testplans
Barbara Bermes: Cheatsheet to a Lean Website
- Works at Firefox
Why should you care about performance
- People don’t like to wait
- 79% of shoppers will not return after disappointing experience/performance
- 1 second dlay: 11% fewer page views, 7% loss in conversion, 16% decrease in customer satisfaction, $1.6 billion loss (Amazon)
Shape a performance culture
- Make everbody aware/care, it’s everybody’s business
- Say “No” to marketing/… when things will make performance bad
- Celebrate success
- Be transparent of results
Performance = perception and respect
- Older people will have more patience
- Show respect to users: fast websites make users feel good
- Treat speed as a feature, not a nice to have
- Optimize from a user’s perspective
Measurable performance modules
- Low impact: small images, static conctent
Measure first, then optimize
- Performance budget
- Speed index: how fast components load (the lower the better)
- Page Speed: 0-100, 85 is recommended.
Determine critical path
- Clean HTML
- Remove unused DOM
- Correct order
- No third-party features
- Critical CSS
- Use async/defer for
- Minifiy HTML/CSS/JS
- Optimize images
- Avoid Web Fonts (or use a web font loader)
- Use GZip techniques
Reduce HTTP Requests
- Concatenate where applicable
- Don’t blindly use frameworks
- Use image sprites
- Data URI for small images
- Time it takes for content to be requested and shown
- Reduce HTTP requesst
- Reduce amount of polling
- Critical CSS
- Remove redirects
- Offline storage
Make friends with the server
- GZip assets
- Solid cache policy
Automate perforamnce routines
- Task runners Grunt/Gulp/Maven/Ant
- Include in continuous integration system
Zell Liew: Building Responsive CSS Components
- Standardized units for easy construction
- Atomic Design/BEM/Namespacing/OOCSS/SMACSS
- Communicate with your team
- To adjust in amount according to a fixed scale or proportion
- How much do we need to scale?
- Principle of repetition = familarity.
- Shift focus away from design to actual content.
- Limit sizes/scaling.
- Consistent whitespace.
- Different behaviour of component based on location
Modularity when scaling
- Element Queries
Scott Helme: CPS STS PKP SRI ETC OMG WTF BBQ
- No more image sprites
- No more concatinating
- No more domain sharding
- GeoLocation API only over HTTPS
- getUserMedia() only over HTTPS
- AppCacnhe only over HTTPS
- Brotli Compression, better than GZip
- SEO Boost
- Subresource Integrity
Content Security Policy
- Local, what MY site allows to load
- Stop content injection (XSX)
- Whitelist which servers content is allowed from
- Upgrade insecure requests: Change http to https
- Without HSTS: Redirect http to https. Costs time.
- With HSTS: Browser goes to https by default, overrides user.
Due to the extension cords being removed at around 1PM I was unable to take notes for the rest of the conference.