Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Corrected links that should have been relative instead of absolute.

...

All code we wrote is public on GitHub: https://github.com/benweissmann/vegitude.

Evaluation

We conducted our user tests on one person from three different segments three people, each from a different segment of the targeted population: . Categories in our target user group are vegans, vegetarians, and non-restricted persons who cook for friends with restrictive dietary needs. We briefed each individual with a general description of the problem that Vegitude is trying to solve and the manner in which it solves it. Following that, we gave each individual three or four tasks based on a scenario centered around the segment of the user population that they are in. Each task touched on a different capability of the website, making sure that each user could successfully learn how to utilize all of Vegitude’s capabilities naturally, without being told or shown how to do so. Here is the link to the user briefing and tasks.

After conducting these user tests, we have discovered a couple of interesting usability problems for us to tackle:

  • Tooltips use ambiguous at first sitesight
  • Minor severity

The tooltips that accompany substitutions (on the left of them) can be pretty ambiguous at first sight. One of our users did not naturally think of checking the tooltip next to vegetable oil (a substitution for butter) in order to find alternative substitution for butter. One way to solve this problem might be to add in some natural instruction to the page to explain that more information on the substitutions and the ingredients they substitute might be found through the tooltips.

  • The search seems fairly slow
  • Minor severity

One of our users mentioned that the search seems fairly slow and, although we have a search page animation, it runs for such a long time on most searches that it can be tiring. One idea we had to solve this issue is to actually use a dedicated searching library, such as Lucene, in order to find our information, instead of the mySQL search that we currently use.

  • Substitutions based on usage is hard is hard 
  • Major severity; luckily, this isn't a class on backend, so it is actually more of a minor severity for our purposes

It turns out that actually finding appropriate substitutions for particular ingredients in certain recipes can be difficult, as their use in a recipe can vary. One of our users pointed this out and it is a reasonable worry. We have looked into this and figured that, unless we can find a better ingredient substitute database, we will probably have to create an algorithm or go through by hand and specify the type of substitutions for particular ingredients in different kinds of recipes.

Reflection

Reflecting on the past project, I think that our organization during this project went was pretty well. swell; We all contributed very heavily to the project and came out with a very nicely designed product that both has a reasonable use, as well as an easy-to-learn interface.

We learned a lot throughout this project, from using Bootstrap to create appealing layouts, to creating a database to store structured recipe data, to using python to crawl recipe websites and extract structured data from free-form text.

We used our prototyping stages effectively. While the overall design is similar to the original paper prototype, we fine-tuned colors and sizes and added additional features (such as the mini-search on the results page) based on the feedback we received from our heuristic evaluations.

If we were to do anything differently, it would have probably been early but consistently-updated documentation in order to make it more easy to do group work separate from the groupto create documentation at an earlier stage, and to update this documentation so we could use it as a tool for collaboration and coordination.