...
Our design was a combination of all three designs we came up with during the design phase , and a simplified version of our paper prototype model. The design is based on the input of two users; parent , a caregiver and child. The parent caregiver has to be able to quickly and easily choose a meal to cook for their kids, and the kids have to be able to give feedback on the meal they just ate. We didn’t want the application to interfere or be a burden to the parentscaregivers/children, so we worked to make it as simple as possible. Our design has four main pages: the home page, results page, and recipe page (for parentscaregivers), and the feedback page (for children).
Home page (for
...
caregivers)
The home page is where parents caregivers can search for meals by ingredient or by what a certain child likes.
...
- Typing in an ingredient and selecting it from the list populates the search bar with an icon.
- Hovering over a tile changes the color of the tile (feedback), and clicking on a tile populates the search bar and colors the tile green (more feedback).
- There is internal consistency for search items: every time something populates the search bar it is put in a little grey 'tile', so the user can assume know it’s a valid search parameter.
- The tiles are meant to have the affordances of large buttons, shown by rounded corners and shading.
- The search and clear buttons have the affordances of buttons, and are also colored based on their function (i.e. “clear” is red). However, they They also have multiple visual to indicate their function -- both – color, text, and icons.
Efficiency
- Instead of trying to remember what their kid likes, a user caregiver can click on the tile and the program will search based on all of the ingredients that the kid has previously voted on already.
- The “clear” 'clear' button lets the user clear the search field in one sweep, without having to remove instead of removing ingredients individually.
Safety
- Users can remove out of ingredients/clear the search bar if they don’t actually want to search for something.
- Users can easily return to this page if they want to modify their search.
...
- What should we include on the home page?
- We ultimately decided to include just the search bar and the children tiles as the main componentsin this page. Based on user tests, we found that including too much on the page confused the users and took away from the purpose of the search bar, namely searching. The user feedback and the heuristic evaluations also caused us to de-emphasize the listed ingredients in child tiles.
- Should the users be able to search for anything or just prescribed words?
- In order to make our implementation easier, and because Since we had a relatively limited database of recipes, we decided to limit the possible search words to ingredients in our database. When the user types anything (or just clicks) in the search bar, the list of allowed words appears and has autocomplete functionality.
Results page (for
...
caregivers)
The user arrives at the results page after searching for something on the home page.
This The results page allows the user to easily return to the search page by clicking on the “Back to Search” button, and lets the user know what they had just searched for. Additionally, it displays an ordered list of results. Each result includes a picture of the dish, the title of the dish, a taste score, the significant ingredients, and which child (, if any) , it is recommended for. The taste score and and recommendations comes from the childrens’ feedback.
This The purpose of the page is intended to give a helpful overview of the different recipes that match the search criteria, such that the parent caregiver won’t need any additional information to decide on a recipe. When the user hovers over one of the tiles, it changes color, and clicking on any part of the tile brings the user to the recipe page.
...
- The tiles change color when the user hovers over them (feedback).
- The search parameters are listed at the top of the page so the user knows that what they searched for has been taken into account (feedback).
- The taste score is made very prominent to allow the user an easy metric for choosing recipes.
- The image also stands out, which is intended to make it even easier for the user to choose between recipes.
- The boxes around the tiles and the arrow button is are intended to provide button affordances for selecting the recipe.
...
- The taste score lets the user choose a recipe quickly -- – it only takes one click to choose a recipe, and the parent caregiver can assume that it fits their criteria
...
- What should we include in the recipe tiles?
- We decided to include a bit of information in the results tiles so that the user would be able to make a decision without having to make any more clicks. However, we wanted to make the information within the tile easy to read, which is why we made the title large and highlighted the taste score. This lets the parent caregiver make a quick decision based on taste score.
- Do we need an explicit button to return back to the search page?
- We decided that we needed the button to allow users to return to the search page and have their previous query still present in the search bar.
Recipe page (for
...
caregivers)
The recipe page allows the parents caregivers to do a few key things.
First, this page allows parents caregivers to navigate back to the results page and begin a new search with a single click. Additionally, it lets them go to the feedback page, where their children can give feedback. The recipe page also displays the title and , a picture of the dish, as well as a shopping list and list of steps in the recipe. The page also lets the user print out the recipe/ingredients or share the information with someone, such as a partner that is going to the grocery store for them.
Based on heuristic evaluations and user tests, we felt that it was best to combine the shopping list and recipe into a single page. Additionally, our user test made it seem like people appreciated tests showed people liked being able to check off the ingredients they already had. Checking the box next to an ingredient crosses out the ingredient and indicates to the user that they already have the ingredient.
...
- The navigation bar highlights the current page in blue to show active state and make it clear the what page the user is on.
- The recipe and shopping list are presented together to make it easier for a user to see the ingredients while they are making the recipe.
...
- Previous query still populates the search bar/results page when the user returns to them from the navigation bar.
- Users can easily return to search results after selecting a recipe.
- Ingredients can be checked and unchecked (so the user doesn’t get stuck in one state).
- There is error checking in the “share” modal, to ensure that the recipe will be sent correctly.
Design decisions
- Should the recipe and shopping list be on the same page?
- We ultimately decided to put the recipe and shopping list on the same page, as they are in classic recipe books (natural mapping). During our user tests, we found that people had forgotten the ingredient amounts when they went to the recipe page, and we felt it was safer to include them together. This also made it easier for users to share/print the two sets of information.
- Should checking the checkbox indicate that the user already has the ingredient?
- Users viewed the shopping list like one they would have on paper, so when they had bought an ingredient, they wanted to cross it out. Therefore, we felt having the checkbox function as a crossing out mechanism made the most sense.
- What should we put in the navigation bar?
- Although we wanted to make the navigation bar simple, we found that users thought it was valuable to have a button for returning to search and results.
...
The feedback page is meant for the children to rate what they thought of the meal, and help parents caregivers make meals in the future. First, they are presented with a modal window where the child or parent caregiver can click on the current child giving feedback.
...
The smiley face changes based on where it is on the sliding bar, and moves the ingredient yes/no choice based on if the smiley face is on the “happy” side or the “sad” side. If the smiley is dragged toward the left, the ingredient preferences automatically toggle to ‘no.’
However, once Once the toggles are changed manually, however, they are no longer tied to the slider. After the child has moved the slider accordingly and toggled the ingredients based on their preferences, they click submit and are prompted with another modal window. The idea is that once one kid finishes, they will pass the app off to another kidchild, who will complete their feedback – continuing until all kids have given feedbackrated the meal.
The modal window that appears after one kid has given feedback has grayed out the picture of any child who previously submitted, and provides an alert saying that the feedback has been sent to the parentscaregivers.
Learnability
- This page maintains the same navigation bar as before, so the user can easily go back to any of the other pages, especially if the child is not yet ready to give feedback (internal consistency).
- The smiley face gives visual feedback as it is moved around (turns brighter green/becomes more smiley if moved to the right).
- Picture stays the same from the recipe page to give the child a visual cue as to the meal they just ate (useful, especially if they can’t read).
- The page greets the child by name, which also provides providing visual feedback.
- There is a diameter margin around the slider bar, so the user doesn’t have to be exactly on the line to drag the smiley (steering law).
- After submitting, the modal window has a grayed out picture of the kid who just submitted and an alert to provide feedback.
...
- Although there is no way to change feedback once it is submitted, if the parent caregiver returns to the recipe, the child can go back and alter their feedback.
- If feedback is not submitted, the user can still choose that child in the modal window to give feedback.
- Once the user changes the ingredient yes/no choices manually, they remain the same despite where the smiley is (so moving the smiley doesn’t change their choices).
- In the modal window, there is a button to return to the recipe so the user is not stuck there if they don’t actually want to give feedback at that time.
- After submitting, the modal grays out the kid who just submitted so you can’t easily give feedback multiple times for the same kid.
...
- How much should we ask from the children?
- We had a few designs early on where kids could drag and drop ingredients into preference buckets. However, based Based on user tests, however, we decided to make the feedback page as simple as possible since people were worried about what their kids could handle. We ended up with a slider decided on the slider, which was fun for kids to move around, and combined with the simple toggles underneath the significant ingredients.
- How can we cycle through all of the kids efficiently?
- We decided to use a modal window to select the kid, and cycle through these immediately after submitting one. This way, the kids are not on an entirely separate interface. This could have been confusing, especially to parents caregivers trying to teach their kids how to use the interface. In addition parents , caregivers can can easily pass the app around after dinner allowing children to rate the meal.
...
Taste Twister is built using Django, a Python web framework, and is hosted on Heroku. Our project depends heavily on the templating and url routing features of feature of the framework. Our backend generates all the HTML for our pages. On the frontend, Taste Twister replies relies on the jQuery library and canvas element for user interactions. We used Twitter Bootstrap for scaffolding and plugins like modals. While Bootstrap was an important tool for us, we tried to avoid using to many visual elements from it and opted to style things with custom CSS.
Data was collected through web scraping. Currently, all of our data is in local text files that we read and write and read tofrom. This made it quick to develop and modify data, but causes a few usability problems. For example, there is a slight delay when searching for several ingredients. Because of the lack of a database our search functionality does no not perform as well as it could.
...
We conducted our user tests in person. For the first parent caregiver and two child tests, we went to their residence, which was the same environment they would be in if they were actually going to use the application. The second two parent caregiver user tests were conducted in 34-101, which was done out of necessity, and could simulate what it would be like to use the application on the go.
We had the parents caregivers perform tasks related to the first three pages, : the home page, results page, and recipe pagepages. The children performed tasks related to the feedback page. One of our group members helped the children go through the tasks on the feedback page, to simulate what it would be like if a parent caregiver was there teaching them how to use the application. We would have the kids first pick a dish that they had heard of, so they could imagine having just eaten it.
Our users
We had three parents caregivers and two children test out our application. The parents caregivers had children in our target demographic (5-10 years old), and the children themselves were also between the ages of 5 and 10. One was a 5 years year old boy and the other was an 8 year old girl, so they represent representing both ends of the spectrum. We tested two fathers and one mother.
Briefing and tasks
The parents caregivers were given the briefing and tasks in the form of an online document, which they read before beginning the tasks.
The children were given their briefing in an informal manner before completing their task. We did not expect them to remember everything we read to them, and made sure to ask if they had any questions before proceeding.
Briefings For
...
caregivers
Hello, you are testing Taste Twister, a web application designed to help parents caregivers plan meals for their kids.
As kids, we know we made our parents caregivers suffer as they tried to plan meals for us and our siblings. Kids can be picky eaters, and siblings often don’t agree on foods. Parents caregivers have a difficult time remembering what their kids like, and end up cooking the same dishes over and over. We want to make it easier for parents caregivers to find new meals to cook that their kids will actually like. Taste Twister makes the entire process of choosing meals based on what kids like fun and interactive for parents caregivers and kids.
You’ll greatly help us if you talk through your thought process as you complete the tasks and let us know if you have any additional feedback.
Your role:
Imagine you are a parent of caregiver for four kids: Max, Josh, Tal, and Sarah. Your kids have very different food preferences, which you have trouble keeping track of. You’ve been cycling through the same meals for the past few weeks, and really want to try something new. After hearing about Taste Twister from one of your friends, you visit the mobile site and put in all of your kids’ information. You are about to head out of work and want to pick a dish for tonight before you head to the grocery store.
Task 1:
Find the ingredients you need to cook a meal with pasta that you think your kids will like.
Task 2:
Cook a meal that Max and Sarah are sure to like.
Briefing for kids
Your role:
You are a Tal, a 6-year-old child. You’re a pretty picky eater, and generally don’t like things that are green. You are interested in trying new foods, but only within reason. Your mom just made pesto pasta, and since pesto is green, you were skeptical about eating it. After dinner, your mom hands you her phone and asks you to rate the dinner.
Task 1:
Provide feedback on the meal you just ate.
Usability problems
Catastrophic
- The younger child could not read very well, and the only visual cue for the ingredients was the name of the ingredient. This would cause the parents caregivers to also have to be present when the children were giving feedback.
Solution: Include pictures with the icon as well as the name of the icon, and change the “yes/no” to happy face/sad face icons.
Major
- The older child found the toggle buttons difficult to use -- – they thought they could be dragged.
Solution: Make the toggle buttons look more like toggles and less like draggable buttons. Also, make them larger as the children seemed to have trouble guiding the mouse around. - Parents Caregivers didn’t always realize that the search bar was not universal (queries were limited).
Solution: Either make the search bar universal or don’t display the search button until they type in a valid ingredient. - Some parents caregivers did not realize that the kid tiles were buttons at first.
Solution: Make the tiles have more affordances to make them look like buttons or include a textual cue.
Minor
- Users could figure out what the checkboxes meant, but a few found them counterintuitive. They felt that checking the box should mean that they need to buy something, instead of meaning they already had the ingredient.
Solution: Create separate sections for the ingredients-- when a user checks on off, it moves it to the “have” list, instead of the “need” list. - Parents Caregivers didn’t always understand what the taste score was exactly, and it took some prompting to get them to notice/use it.
Solution: Make the taste score more prominent (change the color/make it the largest element of the results tile). - Some parents caregivers did not realize that they could search for multiple ingredients
Solution: Make the searched ingredients look more like discrete tiles, or include an example set of tiles in the search bar when they arrive at the site so they have an idea of what to search for.
Cosmetic
- Pressing enter on an ingredient in the search bar list only puts the ingredient in the search bar, and many users expected it to also search for that item
Solution: Make the search button more prominent. - Taste score doesn’t have to be from 100 to 0, because parents caregivers only really care about whether their kids will love it, won’t eat it, or don’t really care.
Solution: Use faces instead of numbers to communicate the taste score.
Reflection
Over the course of the iterative design process, we learned that our initial conceptions on what users will find easy/difficult is often very different from the reality. Before doing the paper prototype, we thought we had a good design, and then after doing the computer prototype, we thought we had a great design. However, there were still multiple usability problems. In fact, even after our final iteration we still have a long way to go.
...
If we were to do it again, we would like to do more testing early on of users in our ideal demographic. Additionally, it would have been nice to test multiple designs, as there were many elements that we left out of our paper prototypes that may have been useful later on. We played it a bit safe with our design, and we’re proud of our final product. However, it It would have been a good exercise to perhaps try more things at the paper prototype phase.