2. 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
3. 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
4. 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
5. 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
6. The role of marketing is increasingly
important with more original content
7. Going Mobile
• More external & non-technical
users
• Celeb tweets
• Talent uses to view set photos
• Public share links
9. 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.
10. 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');
}
});
11. 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
12. 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
13. 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
14. 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
15. 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.
16. 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');
17. 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
18. 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}}
19. 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}}
20. 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
21. Next Project
• Mobile First design
• Separate templates via flexi layouts
• Start with optimized CSS
• USE FLEXI
23. 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;
}
24. 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
