Web 2.0 Expo NYC and Ignite Wrap Up

Yair Flicker -

John and I went to the Web 2.0 Expo in New York City last week to learn about new trends in Web 2.0 and to try meet interesting people in the industry. We had fun, and I even won a Flip Ultra HD from the folks at a party hosted by Rackspace and Neustar. This post includes my notes from various sessions from the weekend.

Ignite NYC

Web 2.0 Expo kicked off with Ignite NYC on Monday (11/16) night. We're a big fan of Ignite talks (having created the websites for Ignites in Baltimore, DC, Annapolis and RailsConf) so it was exciting to check out Ignite in the Big Apple. The Ignite NYC website lists the speakers but doesn't mention what they spoke about (we'd be happy to host your website). Unfortunately I didn't take notes at this event and I'm not going to go through all the youtube videos right now, so I don't have much to share.

Web 2.0 Sessions

NoSQL: The Shift to a Non-relational World

This talk, given by Dwight Merriman, was about non-relational databases, which is a different paradigm from traditional databases like MySQL, Oracle, MS Access, MS SQL Server, etc. Non-relational databases are interesting to me as I think they might be applicable to some of our client projects. My notes:

  • No joins
  • Uses map reduce instead
  • When considering scaling out - think about "CAP" - you can pick any two of the following but you can never achieve 100% of all three:
    • C onsistency: ensuring that data on multiple database servers are consistent
    • A vailable: you want the database to be available when you need it
    • P artition-tolerant: partitioning the database to run across multiple servers
  • CAP constraints are most relevant when writing to the database. If you're only reading from the database, it's easy to have all three.

The Lean Startup: a Disciplined Approach to Imagining, Designing, and Building New Products

This talk was given by Eric Ries (@ericries), who blogs at Lessons Learned. He is someone with whom many tech entrepreneurs are smitten, and I must say I myself was impressed. My notes:

  • Continuous Deployment

    • Devs can check code in, gets deployed everywhere within 20 minutes
    • Cluster will detect bad changes to the code, revert them, email everyone
    • The example Eric gave was that if someone messes up the UI of the checkout
      screen, e.g. changes the "pay now" button such that users can't see it
      and this causes the company not to receive payments, the system will automatically
      revert itself after 20 minutes or so.

  • Lean Startups

    • Commodity Technology Stack
    • Customer Development
    • Agile Product Development

  • Agile Product Development

    • Principles from Lean Manufacturing, Agile, and TPS
    • Unit of Progress: A line of Working Code (as opposed to advancing the plan in waterfall).  Problem: known, Solution: unknown.

  • Product Development at Lean Startup

    • Unit or Progress: Validated Learning About Customers ($$$)
    • Problem, Solution: unknown.
    • Hypotheses, Experiments, Insights feed into XP, which feeds Data, Feedback, Insights back into Problem Definition / Customer Development cycle
    • Problem team: (formerly sales, marketing, product development) - cross functional team
    • Solution team: (formerly engineering, ops) - but should also include marketing - cross functional team

  • Pivot: one turn through this feedback loop

    • Ideas - build - code - measure - data - learn - back to ideas
    • Minimize total time through the loop

  • AAA's of metrics:

    • Actionable

    • Accessible - must make sense to anyone, and must be accessible by anybody in the company (everyone should be able to pull the report)

      • Most useful thing is to kill pet projects and help people see that pet projects are bad ideas.

    • Auditable - "metrics are people too" - reports come from tangibles

  • when someone sees a report, they must be believable and must stand up
    to any questions.  People must be able to audit them because initial
    human reaction is to doubt and deny, etc.

  • Measure the Macro

    • Always look at cohort-based metrics over time
    • Split-test the small, measure the large

  • Five Why's

    • A technique for continuous improvement of company process.
    • Theory: behind every technical problem is a human problem
    • Example: imagine a server crashes.  Why?  Code got deployed
      that used some obscure API that caused it to crash.  Why?  Person
      that wrote the code was a noob engineer and didn't know better and wasn't
      trained.  Why?  Manager
      doesn't believe in training.  Started with a server problem ended
      up with a management problem.
    • Ask "why" five times when something unexpected happens.
    • Make proportional investments in prevention at all
      five levels of the hierarchy.
    • Behind every supposed technical problem is usually a human problem.  Fix
      the cause, not just the symptom.
    • Helps us identify that we're too busy to find out why we're too busy
      or something
    • Acts as a natural speed regulator.  If we're spending too much time
      fire-fighting - we'll have to slow down to address problem, etc.  Regulates
      our speed.

  • Minimum Viable Product

    • What's the absolute least amount of product we can build to engage the
      visionaries?

    • Instead of asking customers what they want (which they don't usually
      know), we're going to take our theory, put it out there, and TEST.

    • Visionary customers can fill in the gaps on missing features - if the
      product solves a real problem.

    • Fears:

      • False negative: customers would have liked the full product, but the
        MVP sucks, so we abandoned the vision
      • Too busy to learn: it would be faster to just build it right, all this
        measuring distracts from delighting customers

    • Must have an agreement with the team to iterate - just because clients
      don't like the first version doesn't mean they're not going to continue
      to iterate.

Eric mentioned a book he's publishing: Startup Lessons Leaned (book) - still in "beta." He also recommended The Four Steps to Epiphany.

Sketchboards & Prototyping - Method for Rapid Design

This talk, given by Todd Zaki Warfel (@zakiwarfel), described a process his company uses for prototyping ideas for applications. It was my favorite talk from the conference. Todd's website is at http://zakiwarfel.com/. My notes:

  1. Prototyping is a process

  2. People often say "I think I get it but I'm gonna have to see it" -
    need to see prototypes

  3. Todd's company doesn't do wireframes.  Their wireframes are their
    prototypes.  Wireframes
    might be sketched out on paper.  Click-through wireframes are their
    prototypes (XHTML/CSS).  They do production-level prototypes, not recommended
    for anybody else.

  4. Two main reasons for sketching / prototyping in the process

  5. Sketches are a great communication tool - don't write notes - sketch
    them out

  6. Pics have less room for interpretation than text

  7. Lo-fi is cheaper, generally speaking, than doing AI, etc.

  8. No written requirements - just visual requirements

  9. "Agile Conference" - 1500 - 1600 people show up. Todd's group
    made some app in two days, for charity, and raised a few thousand bucks with
    the app.

  10. Design Studio Method

  11. Industrial design / architecture method

  12. A methodology where you build something, sketch something - create an
    idea - and then show it to people, let them critique it and tell you what's
    good and bad about it.  Then iterate.  Take an idea, put it out
    in front of people, rip it to shreds, etc.  But you get to do that
    to their designs as well.

  13. They'll do the Design Studio Method sessions with their clients and get
    paid for it.

  14. Write down a few keywords to describe the product today

  15. Write down a few keywords to describe the product 6-9 months from now

  • print this out, put it in big words in the room
  1. --> allows them to see their goals --> see what it is now, and
    what they're targetting
  2. Personas - people that are going to 
  3. Inspirational printouts - stuff that looks aesthetically good or stuff
    that has good interaction - stuff to aspire to include in the next version
    of the product
  4. Break into teams
1. One BA
2. One speaks to dev
3. One designer
4. One sales or marketing person
5. Represent all the different viewpoints
6. Give them a design challenge and have them sketch out - generate -

their ideas

  1. Building blocks of design: square, circle, triangle, line
  2. Generate ideas and pitch them: 3 minutes to present them, 2 minutes

to critique.  Say 2 things that are strong about the idea and 
7. Process:

  1. Sketch -\> present -\> critique
  2. -\> prototypes
  3. -\> and again: sketch -\> present -\> critique
  4. -\> validate
  5. -\> iterate
  1. Get started ASAP
  2. Messy is okay
  3. Quantity then quality --> generate lots of ideas and then refine
1. Peer review then pitch -\> critique process
  1. Templates that they use:
1. The 685 - an "8 up template" - can put 8 sketches in there.

  1. First round you do by yourself - then critique (use red and green

marker to denote what's good and what's not)
2. Second round your sketches are up on the wall
3. 5 minutes to draw 6-8 sketches
4. Can also be used as a storyboard
5. One or two rounds with 8 ups - sketching, critiquing, etc.
2. Then a 1 up
14. Three rules:

1. Know your audience and intent (are you going to give sketches to a

CEO?)
2. Plan a little.  Prototype the rest.  This guy does about
70% in sketches / planned out, then starts prototyping.
3. Set expectations - to combat questions like "why is this B&W" or "what
about the admin" etc.
15. Closing thoughts:

1. You can sketch.  No BS, anybody can sketch.  Anybody can

sketch, good enough to put their idea down on paper.
2. It's [sketches] not the mona lisa.  Just needs to be good enough.  Not
going to live forever in Moma or the Louvre, etc.
3. If you can't make it then fake it.  E.g. if you can't get it to
work in Javascript, use Keynote.
4. Prototype only what you need.  Prototype the unique parts, not
the entire system.
5. Reduce risk.  Prototype early and often.  Do about 2 weeks
of design studio sessions with their clients.  Then they jump right
into prototyping.  Then they do weekly releases.  Whole agile
argument - small and rapid iterations.

"You can fix it now on the drafting board with an eraser or you can fix
it later on the construction site with a sledge hammer." - Frank Lloyd
Wright

Todd was promoting his new book: Prototyping - A Practioner's Guide - by
Todd Zaki Warfel, which I've added to my wishlist at Amazon. He mentioned that it has 6 tutorial chapters, a bit on how to sell prototyping, and some other interesting stuff.

Freeing and Visualizing Financial Data

This talk was given by Toby Segaran (@kiwitobes) and Jesper Andersen (@jandersen). They put the slides from the presentation up on slideshare. My notes:

  1. Why visualize?

  2. To form a hypothesis

  3. To tell a story

  4. Single variable - shows you that a variable is moving but doesn't tell you why

  5. Data Sources

  6. XBRL - put forth by SEC - to put all corporate-filed reports into the open domain in an XML readable format

1. Capital IQ - data vendor
2. Requirement - in 3 years everything will have to be encoded in XML
  1. BSYM - Bloomberg Open Symbology
1. Unique keys of finance -\> links symbologies in finance.  Problem is that different data vendors have different keys and it's a mess.
2. Competing standard is CUSIP - very expensive - but they own the data standard
  1. Yahoo! Finance data - downloadable via CSV - data goes back
  2. Amazon Web Services -> Category: Economics -> lots of data feeds
  3. "Trader Work Station" - some Java thing
  4. Freerisk - site they created