Sous Chef App - Prototyping for Research

Design Challenge:

For our final prototyping assignment of the quarter, we were asked to use at least two prototyping techniques to find the answer to research questions for a project of your choice. 

The experience design question that I set out to explore was, “How can we make cooking with multiple recipes easier?”

I had some assumption about how to tackle this question. However, I first needed to further understand how people organize and manage preparing a meal using various recipes. So, I developed a number of prototypes to test in order to get more clarity on the following research questions:

  • What types of information do people need while planning and cooking a meal using multiple recipes?
  • How do people come up with a game plan for tackling multiple recipes?
  • What is the best way to organize the information they need on a tablet sized interface?

Prototype:

Along with the paper prototype, I developed a three-part evaluation that included:

  1. A card sort exercise to understand how users might bucket, or chunk, different types of activities involved with planning and preparing a meal.
  2. An organization activity asking users to talk through and create their own master timeline to simulate how users might approach the task of cooking four recipes for a meal, and to help identify important qualities of a recipe that might inform the order in which the steps in a recipe might be tackled.
  3. User evaluation of a paper prototype to understand the interactions on a tablet that make the most sense to users.

For these tests, I selected four recipes that were likely to be chosen for a Sunday brunch. Next, I developed a number of scenarios to walk through with users, and finally created a paper prototype to test the interactions. To help document my findings and implement changes to my initial paper prototype to use in further testing, I developed a low-fidelity tablet wireframe using Balsamiq Mockups. 

What I learned:

Here is what I found from my evaluations with users:

From the card sort exercise, a key insight was that users go through the process of taking an inventory of what they have on hand before creating a shopping list. In users eyes, this step between planning and shopping was identified as a separate part of their process. Because of this, I added a way for users to be able to keep track of not only the ingredients they need, but also what they currently have, and what they need to buy.

From the organization exercise, I found very quickly that there is no single right way to arrange the steps in the recipes. Each user had a very personal way of thinking about how to plan and organize a large meal. There were some characteristics of the recipes that users did consider, which included: make ahead options, things that could sit verses things that needed to be served hot, cooking times and temperature in the oven. While some weighted baking time, oven space, or difficulty to assemble more heavily in their considerations for how to arrange steps, others focused on whether or not a dish could be prepped beforehand or sit a while before serving as starting points for arranging the steps.

Knowing these qualities will be extremely helpful in identifying the qualities of recipes that should inform how a system might suggest the order of steps for a master timeline.

It would be interesting to get more input from more experienced home cooks and also get advice from professional chefs to see whether further patterns emerge in terms of best practices for tackling multiple recipes at the same time. Research and testing with cooking professionals, both trained chefs, line cooks, and experienced home chefs as “expert” users may help to further inform the way recipes are arranged in a master cooking timeline.

What I found from the paper prototype evaluation was also extremely informative. In all cases, users preferred a vertical scrolling timeline because it allowed them to see what steps were coming next. They felt that the horizontal scrolling version, which only showed one step previous and the next step didn’t provide enough “look ahead” options. Since, users’ preference for the vertical timeline was so strong, I didn’t bother to create this interaction on my mobile prototype.

From the paper prototype, I also noticed that users struggled a bit with understanding what “Meals” meant in the menu bar. For the mobile prototype, I changed “Meals” to “Menus”. Hopefully, this will make it more clear where users can find their recipe collections for various events.

Another important feature of the app was the count down timers. When testing users with the paper prototype, I wanted to understand how they might expect to pause or continue when the recommended times from the recipes didn’t match their actual cooking times. In both, cases users knew they could tap on the time to pause and restart, but they also wanted a way to add time or re-adjust the timer themselves if they needed to.

Overall, the feedback for the application was extremely positive. Both users I tested mentioned that they would definitely use an app like this and had particular interest in a synthesized or aggregated cooking timeline. 

 

Egg Cup & Soldiers Holder: Physical Prototyping with Rhino & Makerbot

Design Challenge:

For our final prototype exploration, we had the opportunity to design whatever we wanted (within reason, of course) using Rhino to model and MakerBot to print a 3D object that used all the basic functionality such as revolving, extruding, and boolean operations we learned in our Friday studio workshop.

Screen Shot 2014-03-06 at 2.54.11 PM.png
Studio workshop on 3D printing hosted by Keren

Studio workshop on 3D printing hosted by Keren

Prototype:

To gather inspiration on what to print, I decided to look through my Pinterest board of all the cute little knick knacks I've collected over time. I settled on trying to recreated this horse and castle eggs and soldiers set. 

Screen Shot 2014-03-06 at 1.48.09 PM.png

Then, I got to sketching to build a strategy on how to construct these items in Rhino. For both the workshop and experimenting on my own, I soon realized that thinking in 3D is an interesting task. Learning to break down complex shapes into more simple forms and understanding how shapes, curves, surfaces and solids intersect was new to me and required me to pause often to think about how things could be built. I've concluded that there aren't necessarily any wrong answers or ways to arrive at a solution when building things using 3D modeling software, but there are definitely better and/or easier ways to do so. 

To create the castle structure, I started with two circles, a smaller one for the top and a larger one for the base of the castle. A surface was created between these two circles using the sweep function to form a tapered cylinder. In retrospect, I could have also revolved a slightly slanted line to create the same shape. Next, I offset the surface inward to create the thickness of the castle wall. To create the cutouts on the top of the castle wall, I extruded a small rectangle to create a cube and then multiplied the single cube spaced equally around the castle wall using the polar array function, which evenly distributes a shape around a center point. These cubes were subtracted from the castle structure using the boolean difference. The castle door was created by creating an arch, extruding it and subtracting it from the castle, again using the boolean difference function.

The horse was a bit more difficult to construct because of its more organic shape. I started by free hand drawing the horse shape using a combination of straight and curved lines in the front view. Once I was happy with the overall shape, I extruded it to give the horse its width. To create the hole for the toast soldiers, I extruded a rectangle through the horse’s back and subtracted the shape using the boolean difference. I used the same boolean difference technique to create the eyes using small spheres that were subtracted from the horses face. To reduce the boxiness of the object and give the horse a more organic feel, I used the sweep function to create a curved surface on the horses front and hind legs. This was done by creating a new curved base at the front and rear of the horse and connecting these curves to the neck and butt. This became the new edge and the previous back and front edges were deleted before patching up the bottom of the horse to ensure that it would remain a solid.

What I learned:

Although I don't expect to be hired as an industrial designer any time soon, I do feel that learning some basics about 3D modeling and printing were extremely valuable in learning how to think in 3D and how to communicate with designers that may be using such software. It was also helpful in getting me to think about how products might be manufactured. 

I also found it extremely helpful to watch and learn from those with more experience to get tips on how they would approach each task and uncovered buried functionality in the software.

Failures and mistakes can be beautiful, especially when you learn from them. 

makerbot oops.jpg

Pros and cons of 3D modeling and printing:

Pros:

  • 3D printing is a fairly cheap way of creating small objects with great detail that are higher in fidelity if you have access to a printer and don't have to front the cost of a printer yourself.
  • 3D printed objects can be used as props or stand-ins when pitching an idea to get funding or buy in from stakeholders, even if the details of the technical capabilities of a product aren't finalized. 
  • Creating something physical for people to touch and experience makes your ideas tangible and helps people envision the possibilities of your design ideas.
  • Using different filament for printing provides an easy way to explore different types of materials. 

Cons:

  • It takes time to learn and perfect using 3D modeling software. In most future cases, I'll likely leave this to the experts. 
  • Depending on what you want to create, the print space might be considered small.
  • Not everyone has access to a 3D printer. However, as the technology becomes cheaper and more available, this will be less of an issue.

I believe we've just begun to touch the surface of 3D printing capabilities. Just as the tools for desktop publishing has become widely available and the tools supporting it have become easier to use, 3D printing will likely evolve in a similar way. 

Pedestrian Crosswalk Button: Electronic Prototype

Design Challenge:

For this week’s assignment we had the chance to explore different aspects of physical computing and visualization using Arduino and Processing. Because there was such limited time for this assignment (the usual one week turn around), those with little to no prior experience in programming in a high level language, like myself, got the opportunity to build their skills by following and building tutorials or example Arduino projects available online.

I started with walking through some of the basic tutorials on Arduino’s own site. When, I felt more confident that I could do something more challenging, I began to look for additional projects online.

Working on some tutorials

Working on some tutorials

Since I learned how to create a working button for input and how to blink various LED lights on the Arduino, I decided it might be fun to simulate a traffic light using three LEDs. I found a tutorial for just that on http://www.makeuseof.com/pages/getting-started-with-arduino-a-beginners-guide. To take it a step further, I added a button and additional indicator LED to simulate a pedestrian crossing button that would initiate a change in the lighting sequence.

Prototype:

Photo description from left to right: Attempting to connect my Arduino prototype to an actual traffic signal light, Circuit setup, Green light on and button pressed, Clicking the button turns blue indicator light on and changes the light to yellow, after 2 seconds the light changes to red, When green light turns back on the blue light indicator goes off to indicate that it’s no longer “safe to walk”.

Although I didn’t design the circuits or write the code myself, I found that wiring up the circuits and making the code myself was challenging, frustrating, exciting, and valuable for learning how to break things down step by step, visually chart out things out, and think through a process. It was also nice to think tangibly and use my hands.

Classmates, Aniket and Tarhata, helping me debug the code.

Classmates, Aniket and Tarhata, helping me debug the code.

Code:

 

// I used a blue led as a visual marker that the switch was activated. Just replace it with the extra red led you have in the arduino kit.

int green = 13;

int yellow = 12;

int red = 11;

int blue = 8;

int button = 2;     // button connected to pin 2

int reading;        // current reading from button

int previous = LOW; // previous reading from button

int state = HIGH;    // changelights function initially off


// the following variables are long's because the time, measured in miliseconds, will quickly become a bigger number than can be stored in an int.

long time = 0;         // the last time the output pin was toggled

long debounce = 200;   // the debounce time, increase if the output flickers

void setup(){

pinMode(green,OUTPUT);

pinMode(yellow,OUTPUT);

pinMode(red,OUTPUT);

pinMode(blue, OUTPUT);

pinMode(button, INPUT);


digitalWrite(green, HIGH);

digitalWrite(blue, LOW);

}


void changeLights(){

// green off, yellow for 3 seconds

digitalWrite(green,LOW);

digitalWrite(yellow,HIGH);

delay(3000);


// turn off yellow, then turn red on for 5 seconds

digitalWrite(yellow,LOW);

digitalWrite(red,HIGH);

delay(5000);


// turn off red and yellow, then turn on green

//digitalWrite(yellow,LOW);

digitalWrite(red,LOW);

digitalWrite(green,HIGH);

delay(500);

digitalWrite(blue,LOW);

}


void loop(){

// read the value of the switch

reading = digitalRead(button);

  // if the input just went from LOW and HIGH and we've waited long enough

  // to ignore any noise on the circuit, toggle the output pin and remember

  // the time

  if (reading == HIGH && previous == LOW && millis() - time > debounce) {

      digitalWrite(blue, HIGH);

      changeLights();

    time = millis(); }

  previous = reading;

}

What I learned:

As physical products become increasing embedded with digital technology, I definitely see an advantage of being able to prototype quickly and relatively cheaply (<$50 to get started) using Arduino.

Pros & cons of electronics prototyping using Arduino:

  • Electronics prototyping isn’t easy. It takes a lot of patience to troubleshoot both software and hardware. Sometimes, just one miss pin or damaged resistor can prevent the whole thing from functioning. However, mapping things out on paper helps a lot for documenting and double-checking your work when you need to troubleshoot.
  • When working with hardware stability matters. Our basic Arduino starter kits were considered low stability since wires were sometimes uneven, easily displaced, and or accidentally disconnected, etc. Simply transporting the prototype from one location to another felt risky at times because small, unnoticed changes could break the prototype and require additional troubleshooting. Higher stability hardware prototypes might involve more work such as soddering wires together to prevent loose connections from falling out, so depending on how stable a prototype you’d require the investment might be worthwhile.
  • Tools that have great online resources and active communities help. It’s really amazing what you are able to prototype using the Arduino and having a vibrant community online that is generous with sharing tips, tutorials, advice, and ideas is crucial because you can easily find the support you need. There is also a cross-pollination affect that allows people in the community to mutually build off of each other’s ideas. This is the beauty of open source. However, on the flip side, I did learn that not all information and tutorials are created equal. The extremely open nature pretty much allows anyone to post anything, and there are definitely some posts and tutorials that are better or less error prone than others.

While I felt I learned a lot in the process of building my own prototype, I learned the most during the show and tell session during our in class critique. I was blown away by everyone’s creative use of different sensors and actuators. I hope my classmates learned something from me and my project as well.

These two weeks have also been an excellent exercise in understanding what I’m good at and passionate about, and when to reach out to collaborators and teammates for help. I learned that even though I don’t consider myself a programmer, or find joy in troubleshooting and coding, there are others that actually do! And they are willing to teach you in areas that you are not as well versed in. My idea might not have been executed if not for the help I received online and from my classmates. The best ideas come to life when people are connected to the others with skill sets that compliment their own.

 

Exercise 7 - Physical Computing: Electronics Prototyping with Arduino

We are now into the seventh week of the quarter and continuing to explore new prototyping techniques. This week, it's all about getting our hands dirty with Arduino, an open-source electronics prototyping platform based on flexible, easy to use hardware and software. 

Breadboard.jpg

The goal of our in-class exercise was to build an LED thermometer using the Arduino hardware and software to display temperature levels between 75 - 90 degrees.

After a rapid fire overview of Arduino and a crash course in very basic electronics, we were let loose to figure out how to blink one LED light and then to create a thermometer using 5 LED lights as temperature gauges.

First, we had to place our temperature sensor in our breadboard without accidentally frying it by putting it in the wrong direction. Then, we had to figure out how to place our LEDs in a row while making sure each LED was connected to the ground. 

With the help of my classmate, Chase, I was able to customize the code we were given to light up each LED at the appropriate temperature. I set the LED at the bottom of my breadboard to light up when the temperature was greater than 70. I set each additional LED's threshold to light up at intervals of 5 degrees, so that the second LED would turn on when the temperature reached > 75, the next at > 80, and so on and so forth, with the final LED lighting up at 90 degrees. 

Check out my excitement below, when I got the first light to blink and when I had a working prototype for a thermometer. Who knew electronics and programing could be so fun?!

meChase.jpg
carolynChase.jpg
meChaseThumbs.jpg

What I learned from the process:

  • It's very helpful to have an accurate conceptual model of how the system works before you dive in. 
  • Electricity is a closed loop system. Since, electricity has a current, it must flow somewhere and return to ground. 
  • Sketching out what you want to do before you actually put in the pins and write the program is helpful for organizing your thoughts and having something to reference.

Pros & Cons of electronic prototyping with Arduino:

Pros:

  • Arduino provides access for non-programers to tools for prototyping that relatively inexpensive and easy to learn (though one week, is pretty short time frame)
  • Encourages engaging tangible exploration
  • There is a large community of users that love to share their expertise and experiences

Cons:

  • Less stable than wire connections can prevent easy transporting of prototype
  • Physical sensors, wire connections, buttons, etc, used on the Arduino more space
  • Learning curve for programming requires more time than a week

We'll see in the next week, as I continue to explore more Arduino tutorials if I can unlock the potential of my Arduino kit.  

Tweak the Tweet: Mobile Prototype

Design Challenge:

This week our design challenge involved developing a medium to high fidelity prototype of a mobile application for an existing design spec for an application called a Tweak the Tweet (TtT). 

TtT is a system designed to allow digital volunteers to provide information in a form that is more easily and reliably processed and analyzed. It uses Twitter, in a form of “digital volunteerism,” to gather and direct information during crises to people who can act on it to the benefit of affected people and communities, and is part of HCDE Professor Kate Starbird’s work in crisis research.

Full assignment details can be found here.

We were strongly encouraged to explore using App Inventor to expand our prototyping tool kit, rather than using more familiar tools such as Axure or Balsamic.

Process:

We began this assignment as an individual project, but quickly realized that creating a functional prototype using App Inventor, would require a team effort, especially with a one week turn around time. We pulled together a team that each focused on researching and implementing a certain part of the apps functionality or design. We had one member working on the apps integration with Twitter, one working on integration of Google Maps and location, and another one working on getting a real time character count going. I focused on the design and content strategy.

We began by reviewing the design specs and quickly noticed a couple of major usability issues. First, that there were a number of screens that could be combined to streamline the process. Second, the visual design assets we were given didn’t quite match the seriousness and utility of the app. The target users, those reporting on the ground in a crisis situation, would likely care less about the “cuteness” of the app, and be more focused on getting the most accurate information sent out as quickly as possible with as few screens and as little typing as possible.

While we wanted to stay true the the design spec that we were given, we also felt it was important to take the liberty to address the usability issue that may have been overlooked by those that created the design spec.

Once we revised the specs to capture the intent of the original specs, while streamlining the user flow, we began working on our respective parts - location integration, twitter integration, visual design, etc, testing the functionality of the application on one another along the way.

What I learned:

Surprisingly, what I learned most about this week was regarding teamwork and collaboration. It was particularly challenging for me to use App Inventor because it requires a decent understanding on programming fundamentals, which I had not been exposed to prior to this. Even though it uses drag and drop blocks to “code” the application, which in theory should allow non-programmers to use, the blocks are written using programming vocabulary and required a deeper understanding of programing logic for more complicated functionality. Because of this, I had to rely heavily on my team to figure out the more technical functionality. However, I was able to contribute in areas that fit my strengths, such as the visual design and content strategy as well as to be a positive motivating factor, when we were losing steam.

I also learned that App Inventor may not be the best tool for prototyping linear flows as there are many other web and mobile prototyping tools out there that require less time and effort.

Pros & Cons of Mobile Prototyping with App Inventor

Pros:

  • Ability to create a high fidelity fully functional prototype for Android devices
  • Allows you to learn about programming logic in a less intimidating environment
  • Takes away the need for perfect syntax and troubleshooting for missing curly braces, colons, and semicolons.

Cons:

  • Working with emulators or connected devices for viewing updates can be time consuming, especially with inconsistent reliability. App Inventor’s emulator crashed often and it was difficult sometimes to determine if things weren’t working because of the code or because the emulator wasn’t working properly.
  • A limitation of using a visual interface (dragging and dropping code blocks) resulted in having to do many repetitive tasks.
  • App Inventor is more of an individual tool. The current version doesn’t provide a good way for sharing or saving various iterations, or working in conjunction with others.

Post Critique Reflections:

In most cases, you wouldn't be given a design spec with little or no access to the team members who created the spec. I imagine, if we had access to the team, we'd be able to further iterate on the design of TtT.

It was reinforced again that there are always tradeoffs in choosing tools for prototyping. You must be clear on what you are testing App Inventor, in my opinion, doesn't seem quite as valuable as a prototyping tool as it seems to fall right in between levels you might want to test with users. For simple and common interactions, you can create prototypes of equal or higher fidelity using other more intuitive prototyping tools to get the same time of information from users. When it's time to start investing in creating more complex functionality, it might be worthwhile bypassing App Inventor since it has limited functionality and requires repetitive actions for implementing simple things across pages. Although I'm happy that I have been exposed to the tool, I probably won't choose to use it again.