Prototyping with Front End Frameworks

@alexblom

alex@isleofcode.com

Isle of Code• Toronto based development;

• Focused on:

• Prototyping;

• Single sourcing mobile /w Ember.js & Phonegap;

• Using Canvas /w Ember; and

• A lot of beacon work lately.

Agenda• A little on prototyping;

• Iters 1-5 of a prototype we built;

Why

Test & iterate on product ideas cheaply

Align teams around simple ideas

Tour new product ideas to stakeholders and potential clients

Expose product weaknesses before starting a long build

Learnings from iterations often lead to small but critical changes in design and feature set

Expose budget issues early

Speed final development

Common Problems

Proposed product does not work as theorized

Stakeholders do not have the interest perceived in the proposed product

The technology solution is harder to achieve than theorized

Not enough data for valid testing of use case / product idea

Technology is slower than imagination

Customers / Users like the product, but do not value it enough to change their habits or buying behaviour

Frameworks• Our goal is to mock the core ideas of an app, and not to be distracted with utility and

hygiene functions (e.g. user registration and login);

• Some characteristics we look for:• Distinction between back-end and front-end concerns;• Ability to mock API responses, preferably without even having a backend (Fixtures);

• Avoid considering utility as long as possible. Ember Data uses RESTful conventions & has Fixtures;

• Components - we’ll be throwing things around;• As few dependencies as possible (moving fast); • As multi platform as possible;• Simply having a framework matters, because convention matters.

3 Main Steps1. Ideation2. Low-fidelity Wireframes3. Software Prototype Iterations

Iterating from here• Two types of products:

• idea and use case is very well known upfront (e.g. specific internal tool);

• idea has no product/market fit.

• When the idea is known, we generally prefer to spend longer coming up with high fidelity wireframes before programming.

• When the idea is less known, we find it easier to sketch with technology. Good tech evolves from many iterations, and longer windows of poking it with a stick.

• e.g. the first iteration of Unread was actually for desktop, before we realized this was a bad idea.

unread

unread thesis• An app which parsed our email activity, and reminded us

of:

• People we forgot to respond to in the past week, or who forgot to respond to us; and

• People we had not spoken to for > 3 months.

• We thought this would be a good idea.

• We’d already built email parsers before, so we had no concerns about whether the backend was possible/feasible.

Low Fi Frames●  Ensure global product understanding;

●  Provide developers with a simple representation of the product and its goals, without conflicting statements

●  An early attempt to expose any critical weaknesses

Iter 1 (1-2 days)• Main init (routes, Contact model, Fixtures);

• We were imagining a drag and drop interface, so decided to focus here;

• We realized there were 3 main actions (vs. 2 - we added hide);

• Not worried about too much else.

The very first version

Iter 2 - real data!• Iter 1 was not pretty but mostly worked. We dropped

drag and drop in favour of the fast contact buttons;

• In Iter 2, we could have started making the app look better, but is this even a good idea?

• Live data is good to expose common ui/ux issues;

• Fake data lets you keep cheating;

• Showing fake data today for privacy.

Iter 3• With new animations, unread was closer to what we wanted, so:

• Add multiple email accounts;

• Fix nav bar;

• Add actual user accounts!

• We discovered contacts.index was a better way to view, especially once many email accounts were involved.

• And on the back end, tried out graph databases / optimized SQL

Iter 4: Improve Index• Focusing on contacts.index was the right idea;

• Everything works and is stable. Make it look like a ‘mostly finished prototype’;

• Add shortcut actions to the index with gestures, e.g. swipe left and right;

• Pay back technical debt, e.g.

• ListView

• Bounce Scroll

• Cut a release.

Iter 5: Drag was slow• Choppy and deal breaking. This is common when

working with DOM;

• Need to move to Canvas;

• ~16ms target for animations, DOM can’t do this;

• Conceptually unread was stable, so invest the extra time.

Iter 6: Add Paint

After 6 iterations• What is left?

• Finish app/buttons

• Production-ize backend

• Actual designer

Building better products by forcing evolution on iterations, vs. detached documents

Many initial assumptions were wrong (e.g. Tinder style vs. index)

A lot of hurdles discovered and cleared up front (e.g. multi email scenarios)

We gradually built more performant technology as needed (e.g. Swipe), and didn’t need to throw much out (e.g. optimizing drag and drop)

@alexblom

alex@isleofcode.com