# Responsive Design
Demystified

Created by Paul Balchin

`←` `→` `↑` `↓` navigate, `S` speaker's view and notes, `Esc` bird's eye view

[slide]

You can ask questions at any time

There's an entire group of front-end devs here to help me out

## This presentation
is about “Why?”

[slide]

We will start the discussion of “How?”
at the end of this presentation.

This presentation will be available for download on Confluence

### Game Development |  | ### Web Development

[slide]

Why are here? Because Fuel has a long and honourable history of game development. Fuel's experience makes for a well-oiled machine and every department (development, design, management, sales) now has a good idea of the complexity involved and the amount of time it will take to push out a game.

This experience does not apply to web development.

## Designers &
Developers

this presentation is about getting designers and developers on the same page.

we'll start with seeing the difference between developing games vs. web sites; further coding considerations; designing games vs. web sites; finally designing considerations for responsive web sites.

## Project's process

| Games (complexity: 3) | Web (complexity: 6)
--- | --- | ---
Design | (1) Layout and images | (1) Layout and images
Develop | (2) unity 3d | (2) Front-end Code (html, css, js, images, videos)
| (3) Back-end Code Language: C#? Java? PHP? Database: MSSQL? MySQL? NoSQL? Platform? None? CMS?
Compile | Compile for iOS, Android, Windows Mobile | Front-end Minification (css, js, images) Back-end Depends on back-end language
Test | (3) QA | (4) QA
Make Public | Upload to iTunes, Google Play, Windows Store | (5) Local and Web Hosting At Fuel? At Client? At Third Party: MS Azure? Amazon WS?
Documentation | N/A? | (6) Setup, maintenance, modification
Consume | Download from iTunes, Google Play, Windows Store | Load in web browser

[slide]

The next few slides will be outlining the general differences between game design and development vs. web and design development.

It's kinda boring. Please don't yawn in my face.

This slide is less about responsive design, and more about the increased level of complexity from game development to web development.

back end code: do we get to choose? does the client have requirements? does the build team have a say?

local and web hosting: every developer needs to be able to run the code on their own machine; and the code needs to run on Fuel's build servers; and the build servers need to replicate the final environment when the site goes live. Is it going to stay at Fuel? will it be passed on to the client's own environment? Will Fuel just hand over the keys to the third-party hosting service?

## Design considerations

| Games | Web
--- | --- | ---
Device | Screen size | Browser width
Screen orientation | Landscape only | Landscape and portrait
Resizing | Scaling | Responsive

## Development considerations

| Games | Web
--- | --- | ---
Device | Phones, tablets | Phones, tablets, laptops, desktops
Input | Touch only | Mouse, keyboard, touch
Screen size | Small-ish | Any
Screen orientation | Landscape only | Landscape and portrait
Resizing | Scaling | Responsive
Browser * | N/A | All
Older browsers * | N/A | Depends on browser **
Desktop OS * | N/A | All
Mobile OS * | iOS, Android (Mobile Windows?) | All
Data | User's device | Cookies, LocalStorage, Server-side

* Some combinations can cause strange behaviours.
Major offenders = Internet Explorer, Mobile Safari = massive time suck.

** ... or whatever browsers the layout framework will support, whichever is more restrictive.

[slide]

[hightlight "browser"]

we support "all browsers". however, we only test against the most popular browsers as promised to the client, but, technically, it should work on all modern browsers.

[hightlight "older browsers"]

"older browsers". internet explorer is definitely the black sheep here. when ie10 was the latest version, the math was to add 50% styling and javascript effort for each previous version. ie9 = 150% front-end time, ie8/9 = 200% front-end time

[hightlight "desktop os"]

"desktop os". shouldn't matter, except web form elements (buttons, check boxes, radio buttons, etc) are os-specific, not browser specific. (same form, same page, pc vs. mac = native form elements look like pc or mac, not "web")

layout frameworks help normalize the look and feel by trying to reset and restyle these elements where possible. I'll talk more about these frameworks later on in the presentation

## Front-end development

| CMS (e.g. Wordpress or Joomla) * | Fuel Internal
--- | --- | ---
Layout Framework | Already using Bootstrap or Foundation | Download Bootstrap or Foundation
HTML 4 or 5? | HTML 4 or 5 | HTML 5
Platforms | built, tested, and debugged by a large team of developers, across all platforms, under continuous improvement (i.e. full-time employees).
Third Party Libraries * | built, tested, and debugged by a small team or single developer, across some platforms, under sporadic improvement (i.e. volunteers).
Internal Coding * | built, tested, debugged by the project's developer and QA, across whatever devices are available in QA that day, under improvement only until pushed out the door.

* Content Management Systems (CMS) typically include their own ecosystem of plugins and, rarely, might not allow external libraries or code.

`<www/>` What is CMS?, Drupal, Joomla, Wordpress

[slide]

front-end developers will have even more restrictions.

will we be forced to use html 4, or can we use html 5? will we be using a content management system? will third-party javascript libraries work as expected? if not, do we find another or try and fix it?

and every restriction for front-end developers translates into restrictions for designers

## Today

General web development and responsive design

Common, accepted practices

[slide]

Today I'll be talking about general web development and responsive design, not about specialized web sites.

I'll also be talking about common and accepted practices, and staying away from experimental technology.

## Focus: HTML and CSS

HTML is content (plain text, ebooks)

CSS adds style and structure (glossy magazine layouts)

`<www/>` CSS Zen Garden

[slide]

let's see what we can do with just html and css

### CSS layout frameworks

`<www/>` Bootstrap, Foundation

[slide]

Front-end developers now use layout frameworks to kick start any project

A lot of online content management systems, like dnn and drupal, now use layout frameworks as their base code.

Layout frameworks are HTML, CSS, and JavaScript templates for quickly building responsive web sites.

Bootstrap and Foundation have about the same market share.

Responsive web design asks two simple questions:

What is the width of the browser's window
and how do we react to it?

Ask “What width?”

Not “What Browser?”

Ask “What width?”

Not “What Operating System?”

Ask “What width?”

Not “What Device?”

[slide]

Like all simple questions, the answer can be quiet complex.

## Web “pages”

Think “Word documents for the Internet”

### Basic elements

Text

Containers (e.g. paragraphs, tables)

Objects (e.g. images, videos)

### Basic layouts

One column

Multiple columns

Grids

Floating or fixed elements

## “Web” pages

Think “Word documents for the Internet”
+ Variable document size
+ Interactive
+ Animation

### Inheritance

`<html/>` Inheritance demo

### Repaint and reflow

Even a simple web page is a lot of work.

`<video/>` Gecko Reflow Visualization demo

## Responsive design

Requires constant, high-bandwidth communication
between designers and developers.

[slide]

every single page must accomodate everything from hand-held devices up to (recently) 4k monitors.

elements must line up side-by-side or on top of each other, be fixed in size or fluid, and can change state depending on the browser's width.

It's not magic.

It's a lot of planning.

It's a lot of communication.

It's a lot of work.

## The user experience

### Same user experience

Flash is not a web page, it's an object in a web page.

Looks and feels exactly the same across all browsers.

### Web layouts are imperfect

So close, yet so far.

### Different browsers

No two browsers will give you the exact same results.

### Same browser,
different version

Different versions of the same browser cannot guarantee the exact same results.

### Same browser,
different OS

The same browser on different operating systems will not give you the exact same results.

### “Pixel-perfection”
is inflexible

Exact layouts and element placement across all operating systems, devices, and browsers is impossible.

### We shoot for
a consistent user experience

Within the same browser or device

[slide]

we're dealing with users who will typically view the site on one or two devices, such as a mobile safari on the iphone and chome on a windows desktop.

part of the process will have to be communicating this kind of typical usage pattern to the client.

## Go with the “flow”

### Page layout

`<html/>` Fixed and fluid layout demo

[slide]

[demo]

browser width triggers media query rule, which affects the layout

### Responsiveness

The width of any container affects only the width of its child containers.

`<html/>` Responsive demo

[slide]

[demo]

browser width triggers media query rule, which affects the layout

layout defines width of containers

content determines the height of its container

### Adaptiveness

Many aspects of the page can change based on the browser's width.

`<html/>` Adaptive demo

[slide]

[demo]

browser width triggers media query rule, which affects the layout

layout defines width of containers and their placement

again, content determines the height of its container

### “Scaling” is not a “thing”

"Scaling" is a game design process.

We can set the width of any object, such as images and videos, as a percentage of its parent container.

We don't scale text; we change its size based on responsive rules.

### CSS scaling is still new

CSS Scaling is an advanced CSS3 method and supported only by the latest browsers.

CSS Scaling objects is not pretty; font smoothing is not guaranteed, images may not re-render properly.

CSS Scaling is limited to the "parent/child" relationship.

## Media queries

From phones to 4k monitors,
there are an infinite number of browser window widths.

We use media queries to keep it under control.

### What media queries look like

[slide]

Global styling and phone styling as default

Exception styling for each of the responsive layouts and styles in the specified media sections

## Some media query tests

Browser width and height

Is landscape or portrait? (hand-helds)

Is high resolution? (retina displays)

Is screen or print?

`<www/>` CSS Media Queries

### Adaptiveness

Big changes.

“When do we change the layout?”

`<html/>` Adaptive demo

### Responsiveness

Small changes.

“What do we do between layout changes?”

`<html/>` Responsive demo

## Developing
responsively

### “Mobile first”

It's easier to start small and add complexity,
than to start large and then try to simplify.

The layout framework developers have adapted "mobile first" as a best practice.

## “Make it beautiful”

HTML + CSS

[slide]

These are the minimum required. There's no such thing as a responsive web site without these two technologies.

## “Make it functional”

+ JavaScript

[slide]

js adds functionality such as drop down lists, modals, alerts, carousels, and tabbed ui's

## “Make it cool”

+ Animation

[slide]

Animation can be achieved with CSS and/or JavaScript, depending on the need and complexity

## Designing
responsively

### CSS before images

Rounded corners

Gradients

Drop shadows

[slide]

Can we replace images using css?

Saves bandwidth

Speeds up downloads

### Failing gracefully

Rounded corners not supported?
Allow for squared corners

Gradient not supported?
Pick a solid color (req'd)

Web font failed to load?
Create a font stack

[slide]

"Failing gracefully" is about falling back on a simpler alternative if the browser doesn't support an advanced feature.

A font stack is a list of fonts in order of importance. If the first font in the list is not available, then the browser will try the next in line.

### Font icons before images

Scalable vector art

`<www/>`Font Awesome

[slide]

Can we replace images using font icons?

Saves bandwidth

Speeds up downloads

### Images at actual size

Games: 200% of largest possible
and then scale down as needed.

Web: actual size, e.g. buttons and icons.

Web: responsive, e.g. background images.

Save on bandwidth: smaller images for smaller devices.

[slide]

There are few places in the world where user's are NOT paying for bandwidth by the megabyte

## Adaptive comps

Phones vertical and horizontal

Tablets vertical and horizontal

Laptops ("small" desktops)

Desktops ("large" desktops)

4k monitors?

### Three basic layout rules

#### Follow what the layout framework will allow

Otherwise, what's the point of using a framework?

#### Ignore the layout framework

Only if the framework doesn't meet a specific need.

#### Don't fear the first two points

Out of the box layout frameworks are amaze-balls.

## Style guides

[slide]

general layout guidelines

high fidelity examples of page sections such as header, footer, carousels, feeds, etc.

a couple of high fidelity, whole-page layout examples

[slide]

style guides: fonts, colours, individual elements, grouped elements (sample form), not focused, focused, unselected, selected/checked, on hover, on click, expanded, collapsed, an empty list, a partial list, pagination, and, so, on

## A poem

Before media queries

we laid out pages using tables

and nothing was responsive

and with every site

something beautiful died

## Where do we go from here?