How we made MOO

How we make MOO

What, moo?

(cc) http://www.flickr.com/photos/laughingsquid

more MOO

A brief history

• Founded April 2006

• Launched September 2006

• shipped to 87 countries in the first month

• Offices in London

• 30 people

• Partners: Flickr, Facebook, Etsy, Bebo, iStockPhoto, etc, and you

The MOO Philosophy

• Digital Print can be different, better (as well as) cheaper

• Make everyone a designer

• A consumer to{y,ol}, not a geeky machine

• Simplicity of experience trumps 'features'

• A global business from day 1

Challenges

• How do you sell a 2.01D object?

• MOO has few 'advanced' users

• Printing, compiling, distributing, returning, fixing

Coding

• Agile (-ish)

• weekly releases

• short projects (max 6-8 weeks)

• bugs can lead to physical costs

• Lots and lots of reporting and alerting, feedback.

Tech metrics

• All the usuals, re: uptime etc

• 5% feedback to order ratio, declining each year

• <1% reprint rate due to code errors, declining each year

Scaling Characteristics

• Growth slower than a pure online play

• Higher barrier to participation

• A data sink,

• Not a communication platform, either asynchronous, nor synchronous

• Hurrah, keeps costs low!

• Build for integrity, accuracy

Storage

• Store every image for reorders but must be accessible

• decrease in HD cost outstrips growth rate

• 6 months capacity max

• Why not S3, etc?

CPU, bandwidth scaling

• Users don't linger (hurrah!) - find, make, checkout (~15 pageviews)

• International responsiveness is very important

• but growth rates are relatively predictable

Opening global datacentres

• US is our biggest market, but

• US performance was lower

• US Googlejuice was way lower

• US conversion was lower

Solution

• virtually hosted squid caching proxies in NY

• 90% US traffic served from the US

• Googlejuice jump (but down slightly in UK!)

• model extends to other countries, flexes with demand

• <100 USD/month!

Scaling issues

That sounds easy?

Scaling issues

• Customer service (cost, quality)

• Distribution

• Physical production

• Quality control

Customer Service

• http://www.moo.com/service

• Actually feeds into Salesforce.com

• All other customer service tools are web-based and home grown

Salesforce.com

• 2 hours to implement (September 18th 2006)

• Cheap (a few hundred dollars/year)

• Reliable

• Ugly, clunky, web 0.5 interface

• Slows down CSRs, hinders their ability to serve excellently

Workerbee

Hidden Complexity

• At launch:

• 1 product, 1 price, 1 currency, 1 shipping method, 1 shipping rate

• Now:

• 23 products, 1 price, tiered multi-item discounts, 3 currencies, 2 shipping methods, variable discounted bulk shipping rates, 5 languages

• 495,038+ combinations

Distribution

• Global Airmail

• Vastly different local performance

• Weight/size limitations

• 2% of everything goes missing

• Returns

Finishing

• Used to outsource everything

• now we buy commodity printed sheets

• laminate, cut, pack, ship ourselves

• Why? QUALITY CONTROL, (cost), Turnaround time

• Every pack gets looked at by a human (not infallible, but...)

• One day, may insource printing

Manufacturing

• Conceived in London

• Designed in Oakland

• Made in China (via Hong Kong)

• lead time on proofs: weeks

• Quality control

QA

Quality Control

Graphs and monitoring

• Top level measures

• Nagios, MRTG

• Orders/hour graphs, alerts

• The Big Board

• Daily email, all employees

The Big Board

Bugs

• AJAX breaks ability to test

• Authenticated APIs break ability to test capacity/performance

• IE6 (2001) is *still* a bitch

Robot QA I

• Emails and Daily summaries of

• PHP errors

• PHP Fatal errors

• (inc any SQL errors)

• Apache errors

• always save URI, browser details, stacktrace for these

Robot QA II

• Automated testing, using WATIR (Web automation testing in Ruby)

• ~400 tests run for rollout

• Ajax vs Flash vs PDF

• key thing: User gets what they ordered

Physical QA

• Low cost product: error rate must be minimised

• A small % of CS queries can eat all your margin

• Want to deliver most sympathetic CS

Physical QA

• Calibration test sheets with every print run

• All orders, batches tracked by barcodes

• Error rates in Finishing closely monitored

• Rapid turnaround for reprints

QA Control

• Every product has a control card

• but we like to make them fun

APIs

• Pitfalls of using a lot of APIs

• Authentication, scaling, performance

• Who builds?

MOO API

money, atoms

(UN)DESIGN GOALS

1. write-only API is for MOO Pack creation

2. Allow 100% flexibility in text and image layout on a pack of cards (eventually)

3. But make simple templates the default (now)

4. Be as easy to use as the Flickr API (or nearly so)

5. Provide decent preview tools for developers

6. Share revenue with API keyholders (after 1.0)

HOW MOO WORKS

1.Register for an API key (http://www.moo.com/api)

2.POST XML document to moo.com/api/api.php

3.Redirect users to MOO for checkout

4. Can specify return_path to bring user back to your site at the end

STEP 2: Boilerplate crap

1 <?xml version="1.0" encoding="UTF-8"?> 2 <moo xsi:noNamespaceSchemaLocation="http://www.moo.com/xsd/api_0.6.xsd" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> 3 <request> <version>0.6</version> 4 <api_key> 88888888-4444-88888888-88888888-4444</api_key> 5 <call>build</call> 6 </request>

STEP 2: Payload

1 <?xml version="1.0" encoding="UTF-8"?> 2 <moo xsi:noNamespaceSchemaLocation="http://www.moo.com/xsd/api_0.6.xsd" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> 3 <request> <version>0.6</version> 4 <api_key> 88888888-4444-88888888-88888888-4444</api_key> 5 <call>build</call> 6 </request> 7 8 <payload> <chooser> 9 <product_type>minicard</product_type> 10 <images> 11 <url>http://whitelabel.org/barcamplondon5.png</url> 12 </images> 13 </chooser> </payload> </moo>

STEP 3: Redirect user to MOO checkout

Details: images

1.Simplest format: drop upto 200 images, user chooses from within those.

2. Preselected images

3. Preselected images with specified crop, zoom data

4. Variable text, text colours, bold, etc

Details: text

• can specify all text fields on all cards individually

• 3 fonts (serif, sans serif, fixed)

• bold

• alignment (depending on product)

• fully variable colour per text line

• 600 different colours in a 100 pack of minicards

• avoid pale colors for text lines, especially yellows

Examples: variable text

Development and Testing

• http://www.moo.com/api/validator.php

• validates XML document

• feedback

• generates pdf preview

http://dancoulter.com/projects/moo-builder/

• Dan Coulter’s MOO-Builder library for PHP

• http://dancoulter.com/projects/moo-builder/

• supports all features of the API

• totally easy to use.

http://dancoulter.com/projects/moo-builder/

http://dancoulter.com/projects/moo-builder/

COBOL coming soon

• Ruby: http://gems.github.com/list.html(James Darling)

• PERL: http://search.cpan.org/dist/Net-Moo/ (Aaron Straup)

• .NET: http://www.unfinitydesign.com/blog/2/ (Nathan Kleyn)

http://www.tagmore.com/moo/

Ten Word Review

http://www.moolulu.com

Coming soon

•15% Revenue Share to API key holders(we will pay retroactively!)

•Business cards

•Fully variable text and imaging positioning

In Summary

• Scaling, QA issues for a physical business are fundamentally different from a typical Web 2.0 business

• Must be tailored to maximising the customer experience whilst minimising costs

Questions?

Stefan Magdalinski, [email protected]

© Adam 'Apelad' Koford http://www.moo.com/designs/designers/adamkoford/