Deciding what to prototype? (~15 minutes)
Knowing what to prototype is almost as important as knowing how to prototype. We will go through some rules for prototyping and some examples of how to choose how to prototype.
This talk walked through some examples of prototypes and a framework for deciding what to prototype.
The examples in this talk were good, but overall the talk was weaker than it should have been. A lot of the points are a little half-baked.
Build a Prototype (~75 minutes)
Individually or with someone else, build something! Below are a few examples of what you might build:
- Build a one screen view of who is going to which talk for this conference. Have the ability to list which session you will attend
- Make a table listing the courses in Olin's course catalog. Make it so that when you expand a row, you get the course description. It took a bit of trickery to scrape that data, so feel free to try to grab it using Kimono and ScreenScraper or just download it as json or as csv
- Prototype that lets you see what students are signed up for what class. Hint: you can find students at the directory and classes at the Olin website. Or download the course listing as json or as csv Initially, you might want to just hardcode a few classes in. As a stretch goal, you might add the ability to drag students to a course.
- Take the search results from foursquare and replace the map with the actual detail view of the restaurant you select. This could be considered a better user experience because it would let you browse many restaurants quickly. Hint: The best way to handle this might be to replace the map section with an iframe and run a script in the console that hijacks the click events for the a tags in the search results. If you wanted to make this more robust, you might make it a chrome extension.
Different students got to different stages of a functional prototype. In some cases, students got to the point where they could click on some content and show other content. Some got to the point there was content on the screen. Others did really participate. Building anything in 1 hour and 15 minutes is a tall order, especially when you aren't familiar with the tools.
I think this exercise was pretty bad. There was too much freedom/flexibility in too short of a time period. Either, this should have been something taking place over several weeks or it should have been something that was a bit more constrained. Providing links to precreated datasets was a great idea because it helped to limit the scope. I should have provided real examples of what the prototype would have done. Perhaps I should have also written up a more explicit process that I go through in prototyping (i.e. gather data, sketch out a design/functionality, batch generate content in InDesign, prototype) There were lots of things students were tackling for the first time in a short time period (i.e. Mustache templates, CSS, javascript, designing a screen). It might have made sense to further constrain this activity by providing prerendered images to use as content.