Upload
fitc
View
112
Download
1
Embed Size (px)
Citation preview
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.
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.
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 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.
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.
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)