UI work on the web is incredibly important
- Our customers do not relish our architecture or any of the constructs
that we use to build our artifacts.
- They give us money in exchange for great experiences in the tangible parts
of our product(s).
- Beautiful, transformative, high-performance experiences can be built on the web.
Building Better UIs
Five Weird Tricks To Improve UI Build Quality
Noah Chase (@nchase), 2015
1. Code Review: Dive Deeper Than Syntax-Scanning
- Fiscal 2015's Prevailing UI change review process:
- Scan code
- look for syntax err;ors,
- look for places to reduce duplication duplication
- look for Inconsistencies with prevailing Style
-
How can we improve this?
- Reviewing code? Run the code on your machine
- Play with the UI element(s) indicated in the story/changeset
- Open Developer Tools, see how the browser renders it/them
- Open {Photoshop} and compare the dev work to the comp
Note:
- Maybe you're not as good at reviewing design as Justin,
but you're probably better than QBurst (unless we're talking about Lovely)
- There are many ways to do this, but semi-transparent screenshot overlay helps quite a bit.
2. Challenge The Definition of 'Done'
- Fiscal 2015: "Done" == "similar to the comp"
- Sometimes means "if I showed a designer, they might be unhappy"
- Often considered done upon the first iteration that achieves "similar to the comp"
- Would we settle for this elsewhere?
- Probably not. Let's step up our game
First working attempts can often be achieved more simply on second pass
- Use the most recent known-good pass as your guide to inform subsequent passes
- Browser tabs. Use them!
Reflection Questions:
- Is the code overly clever?
- Is the code grueling to read?
- Is there vestigial CSS that-maybe-never-even-worked-to-begin-with?
- "Performance is a feature."
- CSS selectors are evaluated right-to-left. Avoid multi-level nesting.
- Steve Souders: "High Performance Websites (2005)"
Note:
- Steve Souders literally wrote the book on performance.
Has worked at Google and Yahoo as head of performance engineering.
- If possible, be mindful of how a page feels before and after a change is introduced.
If you have a weird feeling, open developer tools's Network or Profiling panels
Measurement
- Always, always, always open in Photoshop and measure. Get good at measurement.
- Practice measurement.
- 2px is slightly meaningful on a 960px wide element - if I show it to you in isolation, you might not notice, but you'll notice 958px alongside 960px elements.
- 2px is enormously meaningful on a 10px wide element.
Note:
- On pixels: our smallest elements are sometimes in the 20s of pixels. If you're off by 2 pixels, you're off by 10%.
If it feels like there's a lot of code, often times, yeah, there's just too much code.
3. Building Something Challenging? Reduce Your UI
- Exercise: try building in a "clean" environment [just the styles you need.]
- Remove ornamentation during reduction exercises.
- Make everything ugly and obvious. Use
outline.
- Draw it out. If you struggle to draw the UI based on the rules of CSS,
you need to strengthen your mental model.
Note:
- Mention Pesticide alongside ugly + obvious + outline
4. Understand Your Code
- If you don't understand the code, you should be wary of writing it.
- In fact, maybe, probably, definitely come to a better understanding of it first.
- If you don't get it, ask your neighbor.
- If neither of you know: that's fine, there's a lot in the spec,
no one knows everything about anything. (But find an answer!)
The CSS Layout Engine
- CSS Layout Engine, Version Post-2.1, many more specs to come, [not CSS4]
- Shapes
- New Selectors
- Variables
- Color Modification
Note:
- The fact that there's no CSS3 or CSS4 is much like ECMAScript 2015, 2016, etc.
People in the World are 'Down' on CSS.
- CSS can be challenging: old browsers, vendor prefixes, etc
- But CSS is here and we have it now.
- We build user interfaces on the web for web browsers, primarily. CSS is the option.
- All of the things that you want to use to build UIs for you are compiled to CSS, regardless of whether or not they're written in it
We can build beautiful, transformative, high-performance experiences on the web.
We can build slow, middling experiences on web, native, or anywhere else.
How can we improve?
Read the Spec [HTML, CSS]
- OK, read parts of the spec that are relevant to your problem
- OK, now that you have been building UIs on the web for a while,
try reading the spec thoroughly
- CSS 2.1 specification is key. Do I have time for excerpts? W3C CSS 2.1 Link Codepen Instapaper
- HTML understanding ties directly to CSS, deeply complementary
- Aural Style Sheets specification
5. Practice & Build, Get Regular Healthy 'Exercise'
- Piecemeal CSS work from JIRA will rarely and inconsistently get you past a skill plateau.
- Play on the side, make things
- If you learn something cool at work, build something that really leverages CSS nicely, etc, consider re-building it a few times.
- Not necessary, but it will help enormously.
- User stories are usually broken down into pieces, which is good for getting things done, but it makes overall understanding a challenge. Practice allows for 'Big Picture' level thinking and experiential knowledge gains
If you really like this stuff, read + explore more widely!
e.g. print design principles (The Elements of Typographic Style), web design principles (Don't Make Me Think), The Design of Everyday Things, past/present trends, philosophy, etc
And if you don't like this stuff, the next slide is for you!
The Sidestep
- My Assertion: Disavowal Isn't Unreasonable.
- Questioning the "anyone should pick up any story" assumptions
Fair reasons to go disavowal route:
- Not satisfied by the work
- Find CSS revolting, a waste of time, intractable garbage
- Don't ever imagine yourself doing UI work on the web
Parents mugged and killed by CSS selectors during childhood
If you find it interesting, but intolerably tedious, try editor modification.
Resources
Resources