Resilent Front Ends


How the user feels


Progressive Enhancement

Three stages of loading:

  1. Content (after this, all content can be shown)
  2. Enhancement (js, like carousel, etc)
  3. 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


  • email
  • 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