Post on 16-Jul-2015
Fake it While We Make it
featuring rails-api and ember.js
“Can you make this?” Our manager slides over a screenshot from Tron/Oblivion/Any Sci-fi movie with a sticky note that says “our data here” and pitches us an idea.
We are stuck between a cool idea and tons of unknowns. We know that the availability, accuracy, and nature of our data will directly affect the quality and outcome of our project. So how do we begin developing? We fake it while we make it.
Designer, “No problem”— makes
prototype
We can too.
WHOAMIRyan LaBouve (@ryanlabouve)
HOLYARCHERS
Agenda: I. What & Why II. Our Toolbox III. Practical
What & WHYPart 1
a brief exploration of prototyping
“faking it while we make it”
=technical prototyping
Prototyping Defined
Prototype—Greek Derivative—
Primitive Form
Low-Fidelity = Primitive Form
We usually think of…
Old Version = Primitive Form
Smoke And Mirrors = Primitive Form
Effectively, Prototyping Can Be All Three
In the year 2000, Douglas Caldwell was successfully petitioned by his teenage son to see the film X-Men. Douglas wasn’t really a fan of sci-fi, but wanted to spend time with his son, so he agreed to go. Watching the film, he was amazed to see a solution to a 2,000-year-old problem that he dealt with every day.
As Cyclops describes the mission they are about to undertake, the map changes shape, as if it was made of hundreds of tiny pins, each rising and falling to form the topography needed (Figure 1.5).
Douglas was that he worked for the US Army Topographic Engineering Center. Part of his job was to create 3D maps and ship them to generals in the field, so they could study the theater of battle and consider tactics. These maps are called “sand tables” because they were originally created by generals thousands of years ago using actual trays of sand. Military leaders still do the same thing when they don’t have a better map on hand
DANGER ROOM
Old Product Lo-Fidelity Product
Reinventing Sandtables
Smoke & Mirrors
Reinventing Lightsabers
This only kind of relates…
The Nature of Prototyping
The Goal is not to be Vague
Prototype —> Product
It focuses on the core problem and gradually moves towards
an ideal solution
Specific Goals
Catch Obvious Mistakes Early
goal 1
quickly bridge imagination to potential solutions
(aka: cheap wins)
goal 2
Reimagine the OU Site (timeline: 1 night)
Modern/Traditional Sturdy and Approachable Techie and Scientific
Classic Rock. Magazine Ready. Honest and Trendy
Modern with Traditional Roots
Actually Harvard…
Sturdy and Approachable
Actually Bates University…
Techie and Scientific
Actually University of Michigan
Classic
Actually Cornell…
Rock. Magazine Ready.
This thing…
Honest and Trendy
Australian Catholic University
Avoid Late Blow-Back from MGMT
(aka. Swoop & Poop)
goal 3
Because, why spend 6 weeks getting an idea rejected
from stakeholders?Aka…
swoop and poop—Getting Agile With—
Explore weird solutions
goal 4
Because sometimes they are radically better
solutions.
“If I had asked my customers what they wanted they would have said a faster horse.”
— Probably Henry Ford
How this applies specifically to,
Application Development, API’s, and Data
Problems & Tools
Part 2
Data Tools Rails-API
activemodel adapter/serializer db seeds + faker ** (screen scraping)
(api scraping)
UI Tools Ember.js Fixtures
Interactions
Even though this is my toolbox, it’s often 1-to-1 to
switch it with others
Common Problems
Data Problems I. States II. Bootstrapping III. Realistic Data IV. Scale V. Relationship VI. Variance
Ember
States—vs—
TodoMVC
Flat mockup -> Interactive. 1 hour max?
Fixtures
Bootstrapping—vs—
Rails-API
Bootstrapping—vs—
Solving the Same Problem With Ember+Rails API
From `rails-api new` to running
Active Model Serializer
Active Model Serializer
Before Active Model Serializer
Add to gemfile (throwing faker in too)
Generate Serializer
(The Serializer)
Active Model Serializer
After Active Model Serializer
For the Ember Side
Proxy For Convenience
Swap Ember Adapter
Faker
Realistic Data—vs—
From Fake Company Stuff
Fake address information and more
The faker and ffaker APIs are mostly the same, although the API on ffaker keeps growing with its users additions. In general, the
only difference is that you need to
ffaker gem https://github.com/EmmanuelOga/ffaker
Add some todos to db/seeds.rb
Seed Database
Active Model Serializer
Fancy Latin Todos
Fancy Latin Todos (in the app)
Rails-API
Scale—via—
What if we do 2,000+ todos?
This will begin to change what we’re making
Impacts our Decisions Early On
Other APIs
Realistic Data—vs—
Latin Means Nothing (ad maiorem partem populi)
Instead, StackOverflow Articles Read vs. Unread
After adding HTTPart to gem file
AnswerMePlz (powered by stack overflow)
Edge Cases
Variance—and—
Exploring Edge Caseshttp://robots.thoughtbot.com/ember-for-designers-alternate-states
Has Many
Relationship—like—
PracticalPart 3
Scenario: You are a Pug Enthusiast
And you want to bootstrap an edgy startup…
It’s like tinder meets zazzle for pug-enthusiasts
mug-enthusiasts.
PUGMUG
Goals: Fresh Pug Pics General App Flow
rails-api new pugmug-api
cd pugmug-api/
rails-api g scaffold --help
rails-api g scaffold pug url:string \ title:string
rake db:migrate
New API
To Gemfile: gem 'active_model_serializers', '~> 0.8.1'
Then rails g serializer Pug url title
More Rails…
ember new pugmug-ember ember serve --proxy http://localhost:3000
ember g adapter application (switch adapter to ActiveModelAdapter)
ember g resource pugs ember g controller pugs
Ember
The End