FoodX - Project Proposal

The Problem

• The fridge often contains expired food, which can smell bad and worse, can cause health problems.
• We buy food, but we have no good method to track its expiration date.

Our User

• Our primary user is the person that does grocery shopping in the household. Generally, we expect our primary users to be mothers.
• Secondary users are other people in the household: spouse, children, etc

Our Persona - Julie

Scenario

Julie is a mother of two children. She wants a way to track the expiry date of the items she purchases at the grocery store to prevent her children from getting food poisoning. She uses FoodX to automatically input expiration dates for the items she purchases at a grocery store. When any of the items expire, she is notified, so she can throw them out.

Existing Solutions
1. Expiry Tracker

• The items on screen look cluttered.
• The UI makes the process of entering an item look a chore

2. ExpireTrack

• We expect our user to use the app while in the kitchen, hence an online solution is not optimal
• The interface is not mobile friendly

3. FridgePolice

• This is by far the best existing solution
• However, as seen from the reviews, the users are not quite happy with the UI

FoodX

FoodX is a mobile app that allows the users to easily input and track the expiration date of their grocery items.

Features of FoodX

• Product recognition via barcode scan
• Automatic reminders before expiry date
• Items can be tagged with photos
• Automatic food categorization and built in food expiry information
• Search through existing items
• Sort by expiry date and item type

Use Cases of FoodX

• Scanning an item to automatically retrieve item type and expiration date
• Manually inputting item
• Manually inputting expiration date
• Taking a picture of the item
• Viewing expiration dates of existing items
• Manually deleting items
• Searching for items
• Searching items by expiry date
• Sorting items by item type

Prototype Wireframes: Design 1

Prototype Wireframes: Design 2

The Team

• Kwa Jun Yong - Experience with Web Design and Coding.Enjoys UI
• Aaaron Wong Jun Weng - Experience with Web Design
• Sreshta Vijayaraghavan - Experience with game development and automation testing
• Aravindh Dilli Dorai - Experience with creating wireframes and managing projects

Challenges

• Creating a UI that is fun and friendly for mothers, yet functionally powerful.
• Deciding between design prototypes
• Steep learning curve for Flash5 and HTML (The team is not familiar with these technologies)

But we are excited to create an amazing app that lets mothers track the expiry dates of their foods!

Error Message Design

As everyday computer users, I'm sure each of us have received error messages at least once, if not a couple of times already. An error message is essentially used to alert the user that a problem has occurred. A warning on the other hand will alert the user of a problem that is most likely to occur in the near future.Error messages are often displayed using modal dialog boxes, in-place messages, notifications, or balloons. A good error message should entail the following:

• Inform the user that a problem has occurred
• Briefly describe the problem using terms understandable even to the IT noob
• Provide the user with a solution 

Apart from the information presented, how we present it also plays a very important role. We may be presenting the user with all the useful information, but just the way we present it might not be user-friendly and could lead to discomfort and dissatisfaction. The 10 Golden rules certainly have to be adhered to:

• Visibility
• Consistency
• Familiarity
• Affordability
• Constraints
• Navigation
• Feedback
• Recovery
• Flexibility
• Style

This aside, the following are the basic guidelines to follow. Examples have been provided wherever necessary. 

• Avoid error messages if possible - Introduce constraints wherever possible thereby reducing the chances of going wrong. If the error can be automatically rectified, refrain from involving or interrupting the user. Also consider if the problem is relevant to what the user is currently working on.

• Explicit indication that something has gone wrong - Do not use misguiding icons. For instance, dont use the warning icon to display an error. It may water down the severity of the presentation, but the user might be left confused. Also do not just tell the user that there is an error. Should try as much as possible to be specific even if we're unsure of the error.

Compare the above unknown error dialogue to the one below. Clearly goes to show that even if the problem is unknown, try to point the user to other sources which may be of help.

• Human-readable language - We need to keep in mind the fact that non-IT professionals use the system as well. When we try to explain the reason behind an error, we need to be as non-technical as possible. For experts within the field, they may be given the option to view such details. But on the outset, it's best we dont baffle the user.

• Polite phrasing- without blaming the user or imply that user is stupid or is doing something wrong

Do not blame the user as above. Use passive voice instead. Compare with below.

• Precise descriptions of exact problems. Do not over communicate to the user. It would result in nothing more than confusion.

The above error message is good. But it tries to provide the user with all the information at one go. Compare this with the one below which essentially tries to solve the same problem.

• Constructive advice on how to fix the problem. It's not enough to only highlight the problem. A workable solution is to be provided as well.

We've encountered this problem innumerable times! Sending or not sending an error report makes no difference. It closes the application anyway and sometimes results in the system hanging. When the suggestion is of no use, might as well not provide it.

• Visible and highly noticeable - both in terms of message itself and how it indicates which dialogue element users must repair
• Reduce the work of correcting the error (e.g. list of possibilities)
• Hypertext links may be used to connect a concise error message to a page with additional background information or explanation of the problem.

• Avoid Sound alerts - It's best not to have jarring sounds accompanying the dialogue boxes. Again, this depends on the environment in which the user is working. In an already chaotic environment, this feature would be of no use. Only when the error is extremely critical and needs immediate user attention we may employ this feature.

References:

1. Ten Usability Heuristics by Jacob Neilson

2. Wikipedia - Error message

3. Cornell University Ergonomics Web

4. MSDN - Error Messages