Creating a Responsive Website From Scratch

Creating a Responsive Website From Scratch

• Corky Brown – Application Architect; ~9 years at MeetMe.com; back- and front-end development

• Javier Barreto – Web developer; 8 years; mostly back-end, more recently front-end

• Bill Sykes – Web developer; new to MeetMe, 10 years experience back- and front-end

Creating a Responsive Website From Scratch

Something’s missing…• User has a smartphone

• First time visiting meetme.com

• Does not want the native app

• Cannot install the native app

Why?• Users get…

• Modern, native-ish experience • Feature parity with native apps

• MeetMe gets… • Better engagement • Better monetization • Feature parity with native apps • Single server-side API • Work off-loaded to the clients

Everybody wins!

What’s the catch?

“Responsive website”

Phoenix

“From scratch”

6 months later…

Why make it from scratch?

• Current website is years upon years of legacy code.

• Easier to work with new libraries and tools

• Great chance to reimagine our entire development process

• Development will be fasterPhoenix

Goals• One website to manage – mobile, desktop, in between

• Many servers -> one (redundant) server + CDN

• Use Mobile API

• Leverage open source community

• Support smartphone browser+OS+device combinations that use MeetMe

• Organize into releases Phoenix

Organize Into Releases

• Better tracking of bugs & features historically

• Keeps team focused

• Brings us in-line with the native mobile apps

• Use semantic versioning (semver.org)

Phoenix

Focuses

Focuses• Support as many users as quickly as possible

• Fast development

• Well-scoped code

• Documentation

• Standards

• Testing

• Automated builds

Support as many users as quickly as possible

• Focus on top browser & OS (Chrome on Android) first, ignore others.

• Gamble: one browser will give us a great foundation for the next and it should get easier as we go along (more on this later).

Fast Development

• Get end-to-end as soon as possible, optimize going forward

• Dev -> Staging -> Production

• As we optimize this workflow and add tests, we can push faster

Well-Scoped Code

• Let good code thrive

• Minimize scope of compromises

• Feature and bug detection, not browser detection

Documentation

• jsdoc

• auto-generate

• require in code review

Standards• Style

• Best practices

• Pick an existing standard

• jslint/jshint

• Google’s docs for style and annotation

Testing

• Unit tests (jasmine + karma)

• Behavior tests (cucumber + ruby or js)

• Builds auto-generated for QA at URL (with QR code from http://goqr.me/)

Automated Builds

• Continuous Integration

• Jenkins CI (jenkins-ci.org)

• Grunt.js (gruntjs.com)

Non-Focuses

Non-Focuses

• Clients that we don’t support

• Performance (to a degree)

• SEO

Performance• (to a degree)

• Trust that QA will report performance issues (and they did)

• Devices we are targeting can handle what we’re doing (nothing too intensive)

• Browsers and OSes dedicate a lot to JS and CSS processing

SEO

• Common problem for “single page dynamic websites”.

• Our current mobile site is crawled & “Mobile-friendly”, according to Google. We redirect supported clients from there to touch.meetme.com.

• We can skip and revisit later

Principles & Practices

Principles & Practices

• Well-scoped code

• Leverage third-party and open source libraries and tools (Bill)

• Tools for responsive and mobile web development (Javier)

Well-Scoped Coderequirejs or equivalent (browserify)

// js/lib/models/member/MemberPrivacyModel.js define([‘lodash', 'Backbone'], function(_, Backbone) { 'use strict’;

return function() { // };});

Well-Scoped CodeSay What You Do

(Not Why You Do It) (And Not How You Do It)

// js/lib/helpers/RequestHelper.js var errorsToHandle = { 'MemberException' : { 'code_1' : displayLoginModal }, // };

Well-Scoped CodeSay What You Do

(Not Why You Do It) (And Not How You Do It)

// js/lib/helpers/RequestHelper.js var errorsToHandle = { 'MemberException' : { 'code_1' : requestUserAuthentication }, // };

Well-Scoped CodeDo it the “right” way first (HTML5 and community accepted) Keep “fixes” in one function or variable and gracefully fall back

http://caniuse.com/#feat=flexbox

Well-Scoped CodeDo it the “right” way first (HTML5 and community accepted) Keep “fixes” in one function or variable and gracefully fall back

// less/mixins/flex.less .flex-display { display: -webkit-flex; display: -moz-flex; display: -ms-flex; display: -o-flex; display: flex;}

Well-Scoped CodeDo it the “right” way first (HTML5 and community accepted)Keep “fixes” in one function or variable and gracefully fall back

Detect bugs and features, not browsers and devices (modernizr.com)

When the browser or device manufacturer fixes the bug, your code should still work

Third-Party, Open Source• Bootstrap (getbootstrap.com) – responsive UI

• Backbone (backbonejs.org) – models, collections, views, router

• Lodash (lodash.com) – utility library

• Grunt (gruntjs.com) – task runner

• LESS (lesscss.org) – dynamic CSS

• Handlebars (handlebarsjs.com) – templating

• requirejs (requirejs.org) – module & scope management

Leverage third-party and open source libraries and

tools (Bill)

Tools for responsive and mobile web development

(Javier)

Lessons

Lessons

• Browsers: quirkier than we imagined

• Some bugs cannot be detected (or not easily). Treat as though you did detect it!

• Can’t reliably detect device

The Future• Revisit

• SEO

• Render on server first (Rendr, et al.)

• File size & number of requests

• Performance

• Improvements

• React

Questions?