Adaptive + EmberTaking an ambitious app mobile

Who Am I?• Former working artist & web dev

bootcamp instructor @featherart

• First awful web page: 1995

• Currently working on an internal app for Marketing

• Using Ember for ~ 1 year

• At Netflix for nearly 2 years, still only Feather

What is VanDAM?• ‘Digital Asset Manager’ = DAM

• Storage facility for all Marketing assets

• Place where Marketing can chat about, share & create groupings of assets

• Replaced several spreadsheets and a few clunky pieces of software

History• Two years ago: 1 engineer,

deployed on Heroku

• Rails SPA with lots of embedded JQuery

• Basically a repo for assets

• App could go down for deploys

Today• Rails API, ElasticSearch

• Ember CLI app for front end

• Repo for assets, but also chat with WYSIWYG editor, @mentions, folders, …

• 5 full time engineers, 2 PM’s, 2 designers

• No downtime

• Growing external use

The role of marketing is increasingly important with more original content

Going Mobile

• More external & non-technical users

• Celeb tweets

• Talent uses to view set photos

• Public share links

Demo time

Adaptive vs. Responsive• First mobile site, designed for art

festivals

• Designed like coffee table book - everyone sees same content but may navigate differently

• VanDAM - magic Hogwarts book! Endless personalized content, buttons, labyrinth of permissions, favorites, chats, etc.

Responsive• Same content rendered everywhere, mobile breakpoints in CSS

to style for smaller screens

• display: none or visibility: hidden to remove objects from DOM, most screens will ignore hidden DOM elements

• May use touch events to add specific CSS for mobile

$(function(){ // True if this is a touch device if ('ontouchstart' in window) { $('body').removeClass('no-touch').addClass('touch'); }});

Adaptive• Adaptive app will have different,

usually more limited, content for mobile

• Ember app full of computed properties (but not observers, we hope!)

• Don’t want those to compute, unless you are rendering content they are computing for

Approach• Separate templates for mobile and desktop (esp. green fielding) to

occlude content on mobile devices

• Optimized CSS: ‘The fewer rules required to check for a given element, the faster style resolution will be’

• class selectors rather than universal selectors, scoped stylesheets, judicial use of absolute positioning + fixed widths

• display: flex: ‘The defining aspect of the flex layout is the ability to alter its items' width and/or height to best fill the available space on any display device. A flex container expands items to fill available free space, or shrinks them to prevent overflow.’

• Ember components specifically for mobile widgets

Flexbox then…

the best way to center a div

within a circular div

OR

the only way to write the

magic 8-ball app of your

dreams

Our Approach• Taking application mobile in piecemeal fashion - small

changes to prevent downtime and disruption

• Same templates, with if/else and unless statements to occlude desktop-only content

• Pared down functionality for mobile

• Flexbox, scoped stylesheets, class selectors

• Creation of mobile specific components that replace desktop equivalents, passing data down

Wait a minute, ‘occlude’?!occlude:

verb past tense: occluded; past participle: occluded

1. Stop, close up, or obstruct (an opening, orifice, or passage).

“a blood clot has occluded the coronary artery”

origin: late 16th century: from Latin occludere ‘shut up.’

basically, prevent content from rendering.

More specifically…• Service provided by ember-screen to listen for

screen size and/or device

• Inject screen into component

isMobileSM: breakpoint('(max-width: 600px)'), isPhablet: breakpoint('(max-width: 750px)'), …, isMobile: /iPad|Android/i.test(navigator.userAgent),

var screen: Ember.inject.service(‘screen');

screen.js

• breakpoint variable is given to you by the screen service

• by default only listens to screen size, won’t actually make distinction between device types

• isMobile & isTablet added, so functionality can be divided down to phone vs/tablet

Use screen variables in templates to occlude

like you’ve never occluded before

{{#unless session.isAuthenticated}}{{!—- ember truth helpers helping here —-}}{{#if (and screen.isMobile (not screen.isTablet))}} a.mobile-login {click=‘logInMobile’} Login

{{#else }}{{!—- desktop & tablet login —-}}

{{/if}}{{/unless}}

Mobile Components• Handy for putting mobile styling in a scoped stylesheet & assigning

actions specific to mobile

• Have own templates already, so fewer if/else in already crowded template

• Data already in template, can just pass it down

• Assign a CSS class for positioning within page - much more efficient than a universal selector

{{#if screen.isMobile}} {{ metadata-mobile model=model class=“mobile-metadata” click=“open” }}{{#else}}

{{ metadata model=model }}{{/if}}

more about flexi“With flexi, you can separate your markup into separate layout files for each breakpoint size as needed.”

- gives layout specific templates for routes and components

- no need for mobile components or if/else branching in templates

- also has layout service you can inject, similar to ember-screen

- built-in grid system, flexbox layout components so you can position elements declaratively

Next Project

• Mobile First design

• Separate templates via flexi layouts

• Start with optimized CSS

• USE FLEXI

Questions? Answers?

Tools Used• ember-screen and ember-hammertime add-ons

• flexbox to give items flexible arrangement on page

• Chrome & Safari dev tools for debugging

• CSS to make Safari think outside the button tag, in application.css

[data-ember-action], a, button, input, .link { cursor: pointer;}

Perhaps Useful Links• Flexbox documentation on MDN

• Flexbox specification

• Efficient CSS documentation on MDN

• EmberHammertime by Chris Thoburn

• EmberScreen add-on by Mitch Lloyd

• Flexi, by Chris Thoburn

• Smoke and Mirrors, by Chris Thoburn

• EmberGestures, also by Chris Thoburn

• Ember Truth Helpers, by James Murphy

• Magic 8-ball