FinalPrototype-Group:team Moo Moo

From Cs160-sp08

Jump to: navigation, search


Group Members and Roles

Benjamin Lau

  • Code:
    • Wrote PreferencesView
    • Implemented a "favorites" category with Bruno
    • Miscellaneous small changes (adding of "saved" toasts, proper graph scaling, color coded progress values, etc)
    • Modified HistoryView graph to use real data and not random data
    • Fixed various focus bugs in SearchView
    • Modified SearchView to use right arrow key as users expect
  • Writeup:
    • Final Report (this document)
    • Presentation Slides

Brandon Lewis

  • Code:
    • Added button so user can go from MealView back to CreateMeal screen and re-edit meal
    • Some cosmetic changes to food cart in CreateMeal screen (eg bolded the title)
  • Poster

Bruno Mehech

  • Code:
    • Implemented a "favorites" category with Ben
    • Got rid of instructions textview in SearchView, put instructions as "hint" in autocomplete
    • Added ability to view exercise history (previously completely nonexistent)
    • Added ability to view meal history (previously completely nonexistent)
    • Modified MainView to allow for tabs to switch between progress bars and exercises+meals
    • Modified "back" button to skip outdated screens
    • Modified menu behavior to not create multiple MainViews but reuse old instance (efficiency)
    • Fixed life cycle methods of some classes

Fan Yang

  • Code:
    • Made an icon for the application
    • Show how many calories burned for each type of exercise
  • Poster

Problem and Solution Overview

Many people find maintaining a healthy lifestyle to be very challenging. Our goal is to ease the burden by providing a mobile system for tracking diet and exercise. Broadly speaking, our approach is to allow people to focus primarily on what they have eaten (or are about to eat), rather than having to memorize arcane lists of nutritional information. This allows users to be more flexible in their approach to dieting-- rather than developing a rigorous plan and then following it, they use our application to make informed meal-time decisions.

Our strategy is to provide mobile access to a large database of nutritional information. Users can either type in search terms (into an auto-completed form) or browse a hierarchical list of food items. This interface is used to support both inquiries relating to specific foods and the composition of meals. The meals are recorded in a local database, and history functions assist the user in assessing their dietary "performance" over time.

Because nutritional requirements are dependent on the nature of a person's lifestyle, our application also provides modest support for recording exercise habits so that they can be accounted for when making dietary choices.

Target User Group

Our application targets the health conscious lay person who is interested in making reasonable decisions but doesn't have a convenient, accessible way to get the information necessary for doing so. Our application makes few assumptions about the user's knowledge of nutrition. Some users may be very knowledgeable about nutrition, keeping their diets in tune with the latest trends. Others may only remember the four food groups of yesteryear, and may be in need of some serious guidance. Users with very strict needs (perhaps to due an illness or condition) are not within our target group, and would likely be using more specialized software. Athletes and others who exercise regularly will find the support for exercise records useful, but we are not specifically targeting them.



The exercise screen is very simple and straightforward and so it belongs in the Easy Task. The nutritional graph in the HistoryView is a bit confusing, since we utilize a date (day) picker dialog but the thing being graphed is a week. Also, we suspect the labeling of the buttons might not be too clear. So that belongs in Medium Task. The Hard Task features the SearchView, which has given us the most trouble recently. The PreferencesView is new and we've included it in the Hard task because it ties in with the CreateMeal screen better. We omitted the "look up food" task we've had in most of our previous tasks because it's just too similar to the "create a meal" task and altogether less complicated. A summary of the 3 tasks appears below.

Easy Task

  • Context:
You decided that summer's getting close and you'd like to cool off. And what better way to do that than by swimming 20 yards in Strawberry Creek?
  • Sequence
  1. Record your 20 yard swim in the application

Medium Task

  • Context:
You realized you've been gaining weight recently and wonder how this happened. You think it might have to do with that series of Christmas dinners the week before.
  • Sequence
  1. See the graph of your nutritional history for the previous week
  2. Figure out exactly what foods you ate in the previous week

Hard Task

  • Context:
Not having learned from your perilous ways, you now engage in further obscene acts of gluttony. You consume 9 ounces of orange juice and 10 ounces of blueberry pie for breakfast. You feel sated and realize you've done it again. You check your current daily value (DV) for calories. Then you realized, thank goodness, that you have the ability to set your preferences. You set your calorie threshold to 3000 and now life is good again.
  • Sequence
  1. Create a meal with 9 oz orange juice and 10 oz blueberry pie.
  2. Check how close you are now to exceeding your calorie DV
  3. Set your calorie DV threshold to 3000.
  4. Now check again how close you are to exceeding your calorie DV.

Design Evolution

Major UI Changes

Only major views are documented, there are many minor ones (eg FoodView and MealView) that haven't really changed nor received much thought throughout the design cycle. They will be discussed briefly along with the associated views that call them.

Main View

Initial Project Proposal

The MainView has changed significantly throughout the design cycle. The nutrition tracker was originally an idea generated during an individual project proposal, which depicted the MainView as thus:


Aside from the concept of a running daily total, the initial proposal has had little impact on later design and so it will not be discussed any further.

Group Brainstorm

After the adoption of the nutrition tracker idea during the Group Brainstorm assignment, we settled upon a somewhat cleaner, simpler design with less features (read: less clutter). We also no longer displayed the consumed foods of the current day on the MainView, based on the assumption that the user was likely to have a fairly reasonable recollection of what he ate on the current day, and in the unlikely situation that he did not, that he should access this information on a secondary screen. We also shied away from purely iconic button representations (as depicted in the initial project proposal above) because they would be completely mysterious to new users.


Contextual Inquiry

As you can see, we neglected a few things by accident in the Group Brainstorm assignment. In particular you'll notice that for instance there's no button for reaching the HistoryView. This was rectified later in the Contextual Inquiry mockup, which incidentally also revealed a strong preference for visual elements (eg graphs, progress bars, etc), versus text and numbers. It was during this phase that we switched from purely numeric output to displaying a set of progress bars (below). To access the remaining views, the user can "slide" between the two different faces of the Main View.


Lo-Fi Prototype

Up to the Contextual Inquiry, all our design decisions were made without exposure to Android and the restrictions that mobile platforms impose on the interface. These were taken into account later, after the individual programming assignment involving Flickr. Many changes followed. For example, there is no longer a set of horizontally laid out buttons for accessing the other views since they take up too much space and can be easily hidden in the Android Options Menu until necessary. Instead, the MainView became pretty much just the set of progress bars and nothing else. It was a design choice that was aesthetically pleasing, simple, and sensible given that the (presumed) most common operation should be the fastest.


Interactive Prototype

Besides the conversion to high fidelity, nothing fundamental changed when we took the MainView to the next phase. We did find though that apparently Android doesn't support different colors for progress bars. Thus, we are unable to set the progress bar to red when the user is at 200% of a daily value. Only the numeric percent changes. In the progress bar, there's no visual difference from 100%.


Usability Study

Lastly, prior to the usability study, in a coincidental blast from the past, we changed the MainView to allow for "sliding" once again. This was so that the user could learn what foods he had eaten that day. We did not implement this feature in the first Interactive Prototype because it was not high priority given that the user is likely to recall his meals of the current day.


Final Presentation

After the usability study, we decided that it wasn't obvious enough that you could "slide" between the different views. The widget on the right is also not exactly the most aesthetically pleasing thing in the world. So we switched to a version with tabs that's more intuitive and better looking. We also finally implemented exercise history, and display exercise and meal history side by side for comparison. Furthermore, there is now a visual difference (color) between 100% and higher values indicating excess of a nutrient. The severity of the excess is color coded.

Image:tmmmain4.png Image:tmmmain2.png

Add Exercise View

Our Nutrition Tracker application focuses on nutrition and so the Add Exercise View, while always on our agenda after the Group Brainstorm, was never really fleshed out in any detail until the Lo-Fi prototype.

Lo-Fi Prototype

The overall design for the AddExerciseView is very simple. There is a pulldown menu for selecting the type of exercises, a simple numeric form for recording the distance, and a set of buttons for adding the information to the database. We did not put significant effort into this view because our application is meant to mainly track nutrition, and we only record exercise habits in so far as the consolidation of meal and exercise history would be beneficial in making dietary choices. (A trivial example might be that a person who works out on Thursday and Friday could get away with higher consumption of fats and protein on those days.)


Interactive Prototype

Nothing really changed in the interactive prototype, aside from switching the pulldown menu to a spinner. We did add support for iterative exercises but the change is cosmetic for the most part, meaning that instead of describing an exercise in miles or yards or some other unit of distance, it'd be described in terms of iterations (eg reps).


Usability Study

Again, little change for the Usability Study. We did add a "Saved" toast, a good idea we 'plagiarized' from another group during the Interactive Prototype presentation. Cues like this are necessary because we clear all the fields once the user clicks the "Add More" button. Without any feedback, they could think that the application hadn't responded to their request.


Final Presentation

We later got rid of the "Done" button. Users were confused on what the difference between "Add More" and "Done" were. (For the record, "Done" added the exercise and then exited. Removing the "Done" button is fine because they can switch to the MainView with the Options Menu anyway.) Removing the "Done" button also freed us to include a raw calorie estimate of the effect of the workout routine, at the bottom right. This feature will help bridge the gap between the nutrition and exercise portions of the application. The reader may also notice that "Add More" was changed to "Add Exercise." The reason is because "Add More" implies that something was already added. A user who first enters the screen would likely get confused.


History View

The exact nature of the HistoryView was not determined until the Contextual Inquiry phase, during which we determined that some kind of information visualization (eg a graph) was probably ideal. The HistoryView changed tremendously throughout the design cycle, and was simplified as time passed, partly due to the later realization that some of what we had aimed for was not supported on Android, and partly due to the realization that the massive number of options was apparently confusing even to ourselves, let alone the users.

Contextual Inquiry

This is the initial mockup we came up for the HistoryView. Originally, it was designed to allow for graphing nutritional history on several different scales, eg by month or by week. It was also supposed to allow the user to realize on what days he exceeded his DVs. There would be a list of nutrients and the user could choose which one to graph. We also toyed around with the idea of allowing the graph to be interactive, so that users could select and 'click' different points on the graph.

The HistoryView was supposed to allow for "sliding." The 2nd screen would give users access to a calendar with various colored coded days indicating days of excess (red) or malnutrition (blue) etc. If a day was selected, it would lead the user to yet another screen so that they could see what meals they had consumed on that day.


Lo-Fi Prototype

We went with this same basic design in the Lo-Fi paper prototype as well. We wouldn't know until during the end of the prototype tests and while coding that the HistoryView would have to be changed very much.


Interactive Prototype

The first thing we realized when we were coding the project was that apparently Android did not have a native calendar class that we could extend and customize. Instead, there was just a GregorianCalendar class that could be used to manage dates and a rigid DatePicker dialog for selecting dates, but not color coding them or other advanced features. If we wanted more, we'd have to write an entire calendar from scratch. This was not possible under our time constraints. Instead, we focused on simplifying our design so that the DatePicker class could be used. So color coding ended up being cut as a result.

We also noticed a great deal of confusion during the lo-fi prototype. We intended for the graph to be redrawn as the selector on the list of nutrients moved, but people insisted on clicking the list, thinking that this would cause a redraw. Actually there was no functionality mapped to clicking. So instead we added toasts that would display a short summary about the nutrient in question. Users were also confused by some other things, such as the color coding (what did the blue mean, etc) but that idea was scrapped coincidentally during the implementation phase anyway.

The resulting HistoryView is shown below. For the most part it is self explanatory. Note that the PickTime button will display the DatePicker dialog.


Usability Study

Based on feedback from the interactive prototype presentation, we changed the "Pick date" button in the HistoryView to "Select Week to Graph." Previously it was not clear why the user was selecting a date. This was especially the case because it isn't the date itself being graphed but the week the day belongs in. Alas the Android UI does not have a "Week Picker" dialog of some sort. We also added a new button to see previous meals consumed on a date in a view similar to the MainView, but for a different day.


Final Presentation

For the final presentation, we changed the graph to display real user data rather than random data (but it looked so much prettier that way!). We also upgraded the graph a bit. It now scales properly to depict excess nutrition, and sets a marker showing where the recommended DV lies.


Search View

"SearchView" refers to the general search interface used by both the CreateMeal screen and the LookupFood screen. Because so much of the same functionality is shared between these two screens, we will discuss them in concert.

Contextual Inquiry

The LookupFood screen (below) is pretty straightforward for the most part and hasn't really changed too much in the design cycle. If a more detailed discussion is desired, the storyboard description can be found in the Contextual Inquiry assignment.

The CreateMeal screen (below) is more interesting. As you can see from the bottom-rightmost picture, we distinguish between meal times. We were going to have a pulldown menu with options for Breakfast, Lunch, and Dinner. We later dumped this because it was decided that categorization of meals into these 3 was somewhat arbitrary. (What about brunch? Late midnight snacks? Etc.) We would later end up using general timestamps instead. We also had a button for sharing meals between different users (scrapped later as more of a "because we can" feature).

Lo-Fi Prototype

Depicted below is the lo-fi prototype for the SearchView. Yellow boxes have been added to the picture to highlight one possible path through the category hierarchy. During the prototype tests, we used a transparent sheet of blue plastic to highlight the currently selected category or food. Note that during the lo-fi phase we moved the autocomplete form to above the hierarchical browsing. The reason for this is because if the autocomplete form is below the categorical search, anytime we try to switch between the two we'll have to traverse the entire list of top level categories before focus transfer. That'd be kind of a pain for the user. Also, we thought that the autocomplete form would be more visible to users at the top, but we never actually tested to see if this was true.


Interactive Prototype

So actually this is very close to what we had envisioned. There are several details missing, but they were oversights rather than design decisions. For example, we don't label the food cart on the CreateMeal screen (Figure 1), but we fixed this later. It's confusing the way it is because the food cart looks no different from any other column in the hierarchical search. Compare for example the CreateMeal screen (Figure 1) with the LookupFood screen (Figure 2). The rightmost column in Figure 1 is a food cart. It's not immediately clear. We later fixed this. An example of the autocomplete is in Figure 3 and this worked out pretty well the very first time, and so it never changed significantly after this phase.

Image:search_screen_hi_fi2.png Image:search_screen_hi_fi3.png Image:search_screen_hi_fi1.png

Usability Study

We modified the SearchView (which can be used to lookup foods or create meals), so that the instructions for the autocomplete form are now provided as a "hint" and aren't on a separate TextView to the side. Compare before (left) and after (right). Because we use a "hint" and don't actually set the text inside the autocomplete, once the user starts typing, the instructions disappear. They don't need to be deleted. Also, we now have more space for giving instructions.

Image:moo_hi_fi_auto.jpg Image:moo_my_search.jpg

Final Presentation

We now make proper and good use of the "right" arrow key. Previously it was used mainly to transfer focus between the different widgets. Now, it does what a person intuitively expects it to do-- expand the currently selected category. (Previously, the "D-Pad center" button alone did this. This is because of the underlying ListView implementation.) Adding this did come at a minor sacrifice. We had to move the foodcart to a more unconventional location-- to the left. The reason is to disambiguate the "right" arrow key. If we had left the foodcart where it was, there would be only 2 ways of reaching the foodcart, as far as we can tell.

The first way would be to force the user to go deep in the category hierarchy until he finally reaches a leaf node (aka a food) and then let the "right" arrow key mean to transfer focus to the food cart. The second way would be to make it so that going "down" from the autocomplete selects the foodcart if it has anything, and allow people who want to go from the autocomplete to the category hierarchy to have to go "left" from the foodcart after going "down" from the autocomplete. Both ways seem contrived and unintuitive. Thus we have moved the food cart to the left, because we prize clarity over convention for the sake of convention.

Last but not least, the MealView screen that the CreateMeal screen directs the user to now allows for retroactive editing of meals. It didn't make sense the way it was before because the user would only know the nutritional contents after the meal had been saved to the database. Now, they can change their mind.

Image:tmmcreate3.png Image:tmmcreate4.png

Preferences View

Group Brainstorm

The PreferencesView was consistently simplified in each phase. Our original intention was much more ambitious. We were going to take into account religious and medical dietary restrictions. For instance, Muslims are traditionally not allowed to eat pork, and diabetics generally avoid sugar. We were also going to allow for automated daily value regulation due to age, sex, weight, and other parameters. A nutritional guideline system, for example the USDA system, could be selected as well.


Lo-Fi Prototype

Our PreferencesView didn't make it into any of the tasks in the Lo-Fi prototype and so we didn't really discuss it or sketch it out in any further detail. Instead we created a simple version for the demo task so that the users could get the basic idea of how the "computer" was going to work. The version created during the lo-fi prototype is depicted below; note that it wasn't meant to be a serious reflection of our design given that it was not one of the three real tasks.


Interactive Prototype

We didn't get to implement the PreferencesView in time for the Interactive Prototype, instead we came up with a hypothetical sketch of how it might look like in our previous report. This is reproduced below. By now we had abandoned dietary restrictions, considering them too complicated to implement, as well as likely requiring another database to scan for medical and religious restrictions, and logic to block or report consumption of inappropriate foods. In the hypothetical sketch there is also an option for changing between metric systems (due to distance being logged by the AddExerciseView).


Usability Study

We shaved off most of our remaining ambitions by the time of the Usability Study. We removed age, sex, and weight as parameters. The original idea was that these would be used to configure a personalized set of daily values. However, during the Contextual Inquiry with the nutritional scientist (Interviewee 1), we learned that actually daily values don't work the way we thought. We thought that a DV represented the amount the average person in the population would have to consume in order to stay healthy. The nutritional scientist however pointed out that this wasn't the case, and that if it was, if everyone followed their DVs rigorously, 50% of the population would die.

Instead, the way DVs actually work is that they are set about 2 standard deviations above average, so that the vast majority of the population will meet their DVs. In other words, the DVs were probably fine the way they were. Given that this wasn't a problem, it made more sense to allow people to manually tune the DVs that they actually cared about rather than leaving it up to the application based solely on the parameters. We could imagine for instance an athlete relatively low in weight but who needed a very high calorie diet. Someone who was on crew (the rowing sport) for example, as one of our group members is. Individual circumstances need to be taken into account. This is what we eventually did.

The ability to choose a dietary guideline system was also removed. There's no particular rational justification for this other than we don't have the time and that it requires more domain-specific knowledge in nutrition science than we have. We would likely need to bring in an expert and spend a week or two learning the details of the systems out there.


Final Presentation

Not very much changed in this view for the final presentation. It was pointed out during the Pilot Usability Study that it was inconvenient to have to select a nutrient in order to see the threshold-- what if the user wasn't interested in changing anything, but just reading the defaults. The current scheme would waste a lot of keystrokes and cause needless aggravation. As a result we added the current threshold values to the text on the list entries. A user can now quickly skim the values and select only the ones he's unsatisfied with.


Preferred Evaluation Technique

Advantages of Lo-Fi

We thought the Lo-Fi test was the most useful. It was the first phase to force us to specify in concrete terms what our expected functionality was for all parts of the interface. It was also the first time where we got direct, always relevant feedback from the users, instead of general advice (eg as in during the Contextual Inquiry). The Lo-Fi prototype allowed us to identify which screens were the most confusing (turned out to be the CreateMeal and History screens) and gave us a better sense of what part of our UI needed the most improvement.

Another advantage of the lo-fi prototype, though it is a bit incidental to the structure of the assignment, was that we were all able to gather data together as a group rather than individually (eg during the Pilot Usability Study). Things that we might not have paid attention to or that would normally have gone unnoticed were much more likely to be pointed out and critiqued in detail. Further to this, when we assigned "Severity Ratings" to each critical incident during discussion, it forced us to come to a consensus on what constituted a design flaw in our interface. The lo-fi phase consequently brought us all onto the same page.


That's not to say there weren't problems with the Lo-Fi tests. In particular, we feel that they were too rigid. The partitioning of the interface into 3 tasks-- easy, medium, and hard, while conducive to storyboarding and establishing scenarios with real context, caused us to miss some very serious UI problems that could've been avoided if we had allowed the user to simply run wild and try out various things.

A key thing to realize here is that the effectiveness of the lo-fi tests depends a lot on how the instructions are worded and how the screens are divided among the tasks. For example, it has been pointed out that the average user might not know how much an "ounce" of orange juice really is. And he could also possibly confuse this with "floz," fluid ounce, which is an altogether separate thing. We didn't realize how tricky this was because our tasks were always laid out like such:

*Create a meal with 9 oz orange juice and 5 oz blueberry pie.

With something like this, the user knows how much to input into the CreateMeal screen. But what if it were something like this?:

*Create a meal with 1 glass of orange juice and 1 slice of blueberry pie.

The user would likely experience some confusion upon realization that the UI did not support some type of default value based on intention rather than rigorous, objective amounts in terms of mass.

Final Interface


Image:tmmmain3.png Image:tmmmain4.png

Image:tmmmain2.png Image:tmmmain1.png


The MainView allows the user to quickly access all the most pertinent nutritional information of the current day-- what has been eaten, when, and how it all affected his progress or lack thereof towards his daily values.

User Interface

The MainView has 2 tabs, the 1st one is the Summary Screen which displays a set of progress bars, one for each nutrient type. If the bar isn't full, it means the user has not yet met his daily value. In the case that he has exceeded his requirement, and may thus be on the road to injuring his health, the application warns him by changing the color of the DV % text.

The 2nd screen is a list of meals and exercises for the current day. We leave this as a secondary screen that requires switching tabs because in our estimation it's likely the user will have a better idea of what he's eaten or what exercises he's done on the current day than what the effects were. Selecting a meal on the 2nd screen's list will bring up all the data on that meal using the MealView.




The AddExerciseView allows the user to record his exercises and store them in the database. It also tells him approximately how many calories he's burning due to the workout.

User Interface

The interface is fairly simple. A spinner allows him to choose a particular exercise and there is a numeric form to enter the number of miles, reps, or whatever unit the exercise is typically measured in. To the bottom right, a raw estimate is given for how many calories the workout will burn. At the bottom left is a button that'll save the exercise.

SearchView:Create Meal

Image:tmmcreate1.png Image:tmmcreate2.png

Image:tmmcreate3.png Image:tmmcreate4.png


The CreateMeal screen allows the user to search for the foods that compose his meal. Once he's created the meal, it will be saved to the database, and a MealView will pop up that allows him to retroactively edit the saved meal or instead exit and return to the MainView.

User Interface

The CreateMeal screen allows the user to use either an autocomplete form or a category hierarchy to search for the foods in his meal. When a food has been chosen, it will be added to the food cart to the left, labeled "Meal Contents." If the user wants to change the quantity or entirely remove the food from his meal, he only needs to select the food in the cart and change the quantity (0 to remove). (This is not depicted above but was shown in the Interactive Prototype. Works the exact same as before.) Once the user has found all the foods he's interested in, he can click the "Done" button and the MealView will pop up, telling him the nutritional contents and allowing him to change the meal with this new information now in mind. If he is satisfied, the user can exit using the "Done" button. Clicking the "Edit" button will return him to the CreateMeal screen.

SearchView:Lookup Food

Image:tmmlookup.png Image:tmmlookup2.png


The LookupFood screen can be used to search for a food. When one has been chosen, the nutritional contents are displayed via a FoodView.

User Interface

The user interface is pretty much the same as the CreateMeal screen, with the exception that there is no foodcart (so up to 3 category columns can be on the screen at once) and that upon selection of a food, the user is whisked away immediately to a FoodView rather than creating a meal. Depicted above is the autocomplete form and the "favorites" category which contains foods which the user is particularly fond of. The more meals the user creates with a certain food, the higher its favoritism score (recorded in the database). The "favorites" category is also present in the CreateMeal screen and intended as a quick access cache for creating meals.


Image:tmmhistory1.png Image:tmmhistory4.png


The HistoryView allows the user to access all the meal and exercise information from previous days. In addition, the user can analyze the nutritional trend of his diet by choosing among 2 parameters to graph-- a certain week and a certain nutrient.

User Interface

The week can be selected using the "Select Week to Graph" button. The nutrient can be selected in the list to the top right. By default, the current week is graphed. If the user has ever exceeded his recommended DV, this is noted using a horizontal marker. If the user is interested in the exact food composition of his meals and what exercises he did on a previous day, he can use the "Select Day to View" button which will allow him to view his nutritional, meal, and exercise information in the same format as the MainView (shown earlier). Both buttons use date pickers. Note that the graph is updated automatically as the selector in the nutrient list moves. Clicking isn't necessary, though it will bring up a toast describing the nutrient in some detail.


Since this is a newer view, we will use more pictures to show it, although it's not really all that complicated. Below is a sample storyboard of sorts that shows the user changing his fat DV threshold so that he's not as horrified by the MainView.

Image:tmmmain4.png Image:tmmpref1.png Image:tmmpref2.png Image:tmmpref3.png Image:tmmpref4.png Image:tmmpref5.png


The PreferencesView allows the user to see at a glance the DV thresholds set for various nutrients. All DVs are set to commonly accepted standards by default. The user can change the values to suit their individual circumstances. They can also reset all the preferences to the old defaults.

User Interface

PreferencesView is simply a list of the nutrients and their current DV thresholds for the MainView and other visual trackers. Clicking on an element of the list will bring up a quantity dialog that will allow the person to change the value to something more appropriate. At the top, there is a button that resets all the preferences back to the default recommended DVs.

Implementation Details and Difficulties


The database ended up being a heftier component of our project than we realized. In retrospect, pretty much everything we do relies on the database in one way or another. It has grown to about 1500 lines of code and could easily grow much larger if we added more features. Because everything relies on the database in some form, it has always been the bottleneck of development. Luckily, most of our team is familiar with SQL and so this didn't end up being a serious issue.

What did end up becoming an issue though was all the domain knowledge that needed to be acquired and stored. It's one thing to create an application that can query a database of foods with autocomplete and hierarchical searching, it's a separate thing to actually populate that database. We found, much to our dismay, that virtually no online database supports a category level deeper than 3. That's because these databases were designed for being browsed from desktops, where screen space is not a resource that typically runs low. So if we wanted to populate the database, it would have to be done by hand. Consequently, we resorted to adding about 10 real foods, and randomly generating stats for the rest.

Other quirks soon became annoying obstacles as well. For example, vitamins are typically reported in DVs, but nutrients like protein and sugar are usually in both grams and their DV %'s. So we had to store type and conversion information since 1 form or the other was occasionally preferable.

The database tables themselves went through some change during the project. Initially we only had tables for the nutrition side of things, later we realized we'd have to have some form of storage for exercise data too. We ended up deprecating some table attributes when we realized they were more trouble than they were worth. We also added some new attributes late in development, eg "favoritism" so that the names of commonly consumed foods could be retrieved and cached in the hierarchy under the "favorites" category, per the suggestion of one of our users from the Pilot Study.

Note that not all data is stored in the database. Some information, for example preferences and unit conversions, are stored in other areas (a SharedPreferences object and statically initialized hashtables, respectively). The database is only used for storing potentially large, unbounded types of data.

As for the actual database tables themselves, it is probably beyond the scope of what is expected but a concise summary is below:

  • Exercises: Contains all information relating to exercises of the user
  • Categories: Contains all the information of what category is the parent of another category, if any (could be root)
  • Foods: Contains all the information specific to a food (eg stats) and related user specific information (eg favoritism)
  • Consumed: Contains information relating to which foods were consumed in what meal and how many

There are more tables but those are the 4 most important.


The MainView turned out to be quite complicated in the end. There are two separate screens, the summary screen, and the meal list screen. The summary screen queries the database for all foods consumed on the current day, totals their nutritional content, and then calculates the DV percentage of each nutrient based on user preference if one is set or a daily recommended value otherwise, and creates a progress bar for each of them.

The meal list screen queries the database for all meals and exercises and sorts both by time and puts it all in a list. If the user selects a meal they are taken to a MealView screen similar to the one shown when a meal is created. If they click on an exercise, nothing happens since there is nothing else to show for exercises. To switch between the two screens we used a simple tab implementation.

The most troublesome part of this view was getting it to update properly in accordance with the actions of the CreateMeal screen. We ran into all kinds of strange bugs, such as nutrients appearing twice on the Summary screen, meals being in the database but magically not appearing on the 2nd screen, and so on.


Originally when we were designing the HistoryView, we envisioned using a built-in Android library for creating and manipulating graphs. We found out however that Android doesn't have native support for this and so we had to find another way. Creating the graph ourselves was in theory an option, however it wasn't a good time investment given the other things we had to do. We ended up using the Google Charts online API. This works by creating a URL string containing graph labels and values. The server will return a PNG of the graph requested. This work around forces the user to have a reliable network connection. Basically this would be a concern in a commercial product but for the purposes of this class we believe it's fine.

Also, as we mentioned earlier, the Android native libraries do not have support for a visual, extensible calendar class. This required us to redesign our HistoryView since we were assuming that we would be able to highlight certain days. This is documented in more detail earlier, in the Major UI Changes section about the HistoryView.


The SearchView was rather tricky and throughout most of the semester was (and may still be) the buggiest portion of the application. The underlying implementation of the categorical search is basically a list of ListViews. Each ListView has an associated listener. Upon an element in the list being clicked, a new ListView is either shown, or created and then shown. The new ListView will then also have a listener set that, upon click, creates a new ListView. And so on. If the user goes back through the categories, the old ListViews are destroyed. In other words, our hierarchical search works by implementing a form of delayed recursion. There's more to it than that but it's what it basically boils down to. What this simplified description ignores is things like arbitrating transfer of focus among the different ListViews, getting rid of selector ghosts when appropriate, etc. It turned out to be kind of complicated, coming out to about 500+ lines of code.

The autocomplete form is simpler and works by performing a constraint-based search over the food names in the database. We basically check the current prefix in the autocomplete form and compare it to each food name and return an SQL cursor of the names and corresponding foodIDs that match.


Most of the rest of the code is fairly straight forward. The MealView and FoodView are simply TextViews that format and display data retrieved from the database using methods written in the NutriTrakDbAdapter class.

The AddExerciseView is also rather simple. There are no details of implementation that could not be surmised by a brief glance at the picture.

Unimplemented Portions

Insufficient time

As the point of this class is user interfaces, and not in developing a full blown commercial product, we did not place realistic database population particularly high on our priority list, and it ended up not getting done in time. We see our application as a fully working proof of concept. There are roughly 10 real foods in the database and the stats for the rest are randomly generated. Ideally all the stats would be real and instead of there being on the order of about 30 or so total foods, we'd have several thousand or more. However, given the time constraints, we did not think this was a good investment of our time.

Further to that, if we wanted to populate the database, much of it would have to involve tedious manual processing. That's because no online database we've found was deeper than 2 or 3 categories. In order to fit in a large number of foods, we'd have to recategorize each one by hand. It's not that this is difficult per se, it's just time consuming, and there's nothing to gain from it as students.

We also only support about 7 nutrients at this point. However, the choices are not hardcoded and we could easily extend the system, if the database itself could be filled in the future with the appropriate information.

We ran out of time but we'd like to have tried to create our own week picker dialog. It's very confusing, in our opinion, how the HistoryView's "Select Week to Graph" brings up a DatePicker dialog, that selects specific days.

For the AddExerciseView, we currently display how many calories a particular exercise burns. However, while this is a good start, we were planning on integrating nutrition and exercise more tightly, eg by subtracting off calories from the MainView due to exercise.

Most crucially, in our opinion, we never had the time to add in support for default food quantities. Currently the only unit supported is "oz." However the user would likely much prefer to use "glass" or "slice" or some other more natural if subjective unit. This is regrettable. If we had more time this would likely be the feature we'd add next. We'd probably also include an image to give a visual idea of how much our "glass" or "slice" really was relative to the user's notion.

Lastly, we didn't finish the life cycle methods for all our classes. It's not difficult per se but it's time consuming and requires careful consideration and isn't really something we were so worried about given that, worst case, the person could just disable the "1 app" at a time option in the emulator and everything would be fine.


There were many things which we wanted to do but were unable to accomplish despite a very hard look at the libraries provided with Android. Our conclusion is that these things are impossible. It is possible we have overlooked something but we doubt it. We welcome corrections of the below statements.

Progress Bar Color Coding

We went with changing the color of the progress % text because it was the only thing that we could apparently change. It appears that the color for progress bars in Android is hardcoded to be yellow. We have not found any methods or XML attributes which allow us to change the color of the progress bar and so while we would like to implement this, it doesn't seem possible.


As a user pointed out during the pilot study, toasts, while useful and usually unobtrusive, can occasionally outlast their stay. The user suggested allowing center clicks to kill the toasts. We looked into this and there does not appear to be a way to do this. Toasts disappear after a set duration, and their exit does not appear to be customizable.

Wizard of Oz

There is nothing that is "Wizard of Oz"-ed in our application. That is all.



Our application is designed to be run from the MainView. Running it from other views will probably cause problems because the database is created and initialized in the MainView. The MainView is where it all begins-- the user can see his nutritional stats for the current day by examining the progress bars there. The other views can be accessed via the Menu button on the Android emulator.

Make sure you have a working network connection before starting the emulator. We have tested the system on Windows XP but it should also work on others due to the (general) portability of Java.

One problem in functionality is that we did not have the time to override all the life cycle methods. Instances of some classes can be frozen and restored without issue, but others can't.

We recommend that if you have run our application before that you wipe the data on your emulator before running the newest version. The database tables, among many other things, have changed significantly, and it is likely you will experience problems if the application attempts to open and use an old version of the database.

As before, not all the foods are real. We recommend you stick to the following foods: "orange juice", "blueberry pie", "Coke", "Burger King Bacon Cheeseburger", "boston cream pie." There are other real foods but this should be a sufficient sample.

Another thing is that we assume no touch screen for our application. If the user navigates the screen using touch screen, some of our UI elements may be uninitialized and throw exceptions.


[add comment]
Personal tools