Resilent Front Ends
How the user feels
Progressive Enhancement
Three stages of loading:
- Content (after this, all content can be shown)
- Enhancement (js, like carousel, etc)
- Leftovers (Analytics, Flashbanners, etc)
TTS as low as
possible
Who is holding us back?
- The network
- The Browser
- Scripts
- Fonts
- Blocking CSS
The Network
As few requests as possible
1. DNS lookup time
2. Connect time
3. Redirect time (Redirects let you go to the beginning again)
4. SSL handshake time
5. Time to first byte
Remember: about 15k is the first TCP frame
The Browser
-
fetching of remote scripts that need to be executed synchronously
-
inline script node that is waiting on relevant stylesheet fetch (except not matching media query)
- fetching stylesheets
Nonblocking scripts
Use async defer attribtes!
Promise to browser, saying it won't be changing the DOM tree
Blocking Webfonts
Most Browsers (except IE) don't show a thing unless font is loaded. Use js to load it!
h1 {
font-family: fallbackfont, serif;
}
.awesomefont-loaded h1 {
font-family: awesomefont, serif;
}
Blocking CSS
inline the core CSS (combined with HTML max 15kB)
Quasi ein Selbstläufer
Measurement wins
(Could be included in CI reports)
Build products people want
What is the job, people hire your product for.
Milkshake example
Philospohy
"People don't want to buy a quarter inch drill. They want a quater inch hole." - Theordore Levitt
Don't imagine Persons using the product, but scenarios in which it's used
Planning
No sprints, but episodes
efficiency / velocity <> benefit / thinking of the user
Start with announcements
User stories
Episodes > Announcements > User Stories > Job Stories
User stories == One benefit to the user
Job Stories == What will be coded
Offline first webapps
Goal
Background sync or pure offline application
Goal
Background sync or pure offline application
What apps currently do to offline users
- You are currently offline,
- you have to submit your message again
- you shall use non of my application
- you may use a part, but it errors out
- ....
- you suck!
What apps currently do to offline users
What apps currently do to offline users
Things we need from an backend
1. Sign up
2. Administration
3. Save & load data
4. send emails
5. pay
Hoodie strips away the boilerplate
Sign up
hoodie = new Hoodie(); hoodie.account.signUp(username, password);
Sign In
hoodie = new Hoodie(); hoodie.account.signIn('joe@example.com', 'secret');
Hoodie strips away the boilerplate
hoodie.store.add('task', {name: 'Learn hoodie', status: 'done'}).done(function (newObject) {}); hoodie.store.find(type, id).done(function (object) {});
Try it!!!!
Full Spectrum Testing
Why people (like you and I) don't test (frontend) code
- takes to long to set up
- missing expertise
Why should you test
-
verifies the system meets the requirement
-
improve code quality
-
helps not to deploy bugs
-
makes debugging much easier
Unit testing
-
mocking system dependencies
- Benefit: Reliable components & Safer refactoring
- Better code
- looser coupled elements
Karma
Testrunner which supports most browsers and executes your tests on spec / code change
Jasmine
describe('toggleButton', function() { var button, ButtonGenerator; .... .... it('should have a click handler', function() { expect(button.$element).toHandle('click'); }); it('should call the API on click and call the create action', function() { spyOn($, 'ajax'); button.$element.trigger('click'); expect($.ajax).toHaveBeenCalled(); expect($.ajax.mostRecentCall.args[0].url).toEqual('/object/42/action...'); }); });
Do not fear the tests
Supercharge your front-end with the UX best practices
Forms
Bring the user on your side by telling the user why you need this information
Form validation
- As much client side as possible
- Track form errors and success (to find dropoffs)
- Animate on error (jiggle)
- capture common mistakes in email fields
Use new input types
- url
- tel (also for ZIP)
Forms
-
naming the fields like usual to empower autocompletion
- autofocus is a nice feature when on only form page
- in-place editing like at twitter
readability matters
-
60 - 75 chars on large screens
-
45 - 50 chars on mobile
make it feel fast
- prefetch what's possible (carefully, measure first)
- add touch states to buttons
- avoid spinners when possible
- instead use animations when under 300ms (destracts user)
- smooth animations (at least 60fps)
- respond to user interactions in less than 100 ms (at least 1 s)
increasing conversions
- auto-fill whenever possible
- every extra field destroys conversion by 5 - 10%
- don't ever ask for the information you don't ever need
- 3 seconds attention span, focus on the important things
- Don't do the FC design
How Chrome keeps users happy
Don't be a jerk
- Users hate change (only do it for reasons)
- Users hate blocks of text
- Users hate to decide (should work out of box)
- Users love quirky things (T-Rex in Chrome)
- Users love neat things (noise icon)
Feedback can suck
- Feedback sucks, but still maybe relevant
- Feedback sucks, doesn't mean you suck
- YOU != YOUR PRODUCT
Feature Flags
They rock!
- helps when rolling out in incremential batches
- get early feedback on features
- easy undo (just a button click)
User Metrics
-
Feedback => What user think they do
-
Metrics => What users do
Other things
- Consistent UI == Best UI (every dialog the same)
- Don't inline things, build for internationalization
- App should be keyboard only usable
- Possible for assistive technologie (screen reader)
- aria roles
- Themes for low vision
- high contrast
- page zoom
- increase font-size
ES6 <3 Unicode
ES4 sucks, pile of poo counts as two characters
ES6 fixes this, yay!
Codefront.io
By Daniel Schmidt
Codefront.io
- 1,178