Foodtracker, a CREU sponsored project blogs

Final Thoughts

cdoll — Wed, 22 May 2013 01:01:08 +0000

Now that schools out, finals over, and our project complete it's interesting to look back and see all that we have done. In less than a year a group of three undergraduates, a graduate student, and two University of Arizona faculty members were able to not only imagine but create an Android phone application. I walked into this project not knowing how it was going to turn out, but I have to say that I'm impressed by what we created! I hope that even if I'm no longer working on the project this application continues to evolve into something that the world can use.

Final Update

jbv — Thu, 16 May 2013 01:07:42 +0000

The application is finally done. We had a final meeting to share all results that we have accumulated. The nutritional team shared the information from the user surveys, and we discussed improvements to the application that could be considered for future works.

Overall, the application seems to have been well received. There are still a few bugs, but as it was a prototype, the users were comfortable with this.

As the semester is over and several of us are graduating, there is not time to make these improvements. However, this process has taught me a lot. I've been able to work with a mentor teaching how to research computer science subjects, and been able to interact with people that don't necessarily know computer science, which is new to me.

Attached is a sequence diagram of the application, so that others can understand how the application works.

http://www.cs.arizona.edu/~jbv/foodtracker_sequence.pdf

Updates (Part 4)

jbv — Tue, 23 Apr 2013 09:22:10 +0000

Since the previous wave of updates, updates have continued to be made for the app. Many of the categories generated by the automatic parser have been combined into more human-friendly categories. Using a web interface that I created, recommendations were input into the database by the nutritional team and show up in the application without actual updates to the application on the phone.

My advisor and I have also discussed scalability and performance issues that may occur with the current design, as well as possible solutions. For example, for reduced data use or (slightly) faster lookup times of previously viewed menus, most of the network calls that the app is making could be cached into local storage on the phone.

App Pictures

jbv — Tue, 23 Apr 2013 09:17:12 +0000

Here is a link to the promised application pictures!

http://www.cs.arizona.edu/~jbv/ftpics/

End of Semester User Testing

mkramer — Thu, 18 Apr 2013 17:16:28 +0000

As the semester is closing out, we have concluded our user testing and have some great feedback to work with!

Both Chelsea and I have interviewed five or more people and received their feedback about our application. Questions consisted of what do or don't you like about this app? What would you change about this app to make it easier to understand? Do you see yourself using this app in your daily life? And would you recommend this app to friends or family, why or why not?

For the most part, I received very positive feedback, people were very impressed with our progress and how sophisticated the app was for such a short amount of time working on it. Everyone said it was very easy to understand and was very straight-forward. They liked how clear it was to see which foods were good to eat and which were not so good to eat. However, there were also some things we need to work on. The critiques included comments such as adding more visual interest such as color or more features to the app. One person also mentioned adding a diary function to the app so users can keep track of what they're eating.

Since this app is geared toward younger children, we kept it very simple and basic. There are obviously tons of improvements we could make, but that would require much more time and money going into this project!

Overall, I'd say it was a success and I am personally so proud of both teams that put so much effort into this project!

Semester 2, Week 9

cdoll — Thu, 18 Apr 2013 06:06:10 +0000

User testing has ended and I now have some great feedback about our app!

Most of it was really positive with lots of people saying they'd love to use an app like this. Using green, yellow, and red as our colors to signify go, slow, and woah got a lot of positive reactions since there was almost no need to explain what the colors signified. The simple design and display of information was also well received. Everyone really liked that unless you wanted more information the app would only provide you with whether or not the food was healthy enough to eat. And having two different buttons, one for nutritional information and one for tips also got great comments as it gave the users more control of what they would like to see.

With the good, however, came the bad. Some people believed that our labels for foods didn't match their nutritional value. As mentioned in my last blog post one of the users felt that oatmeal being labeled as 'slow' was inaccurate and that it should be labeled 'go'. Others suggested that we should rethink our equation based on the category of food. Someone else mentioned that we should also consider the ingredients as this might change the go, slow, woah label of the menu item.

Another comment, neither good nor bad, was that some of the foods listed were unneeded and could be deleted from the app. Most of these foods were part of the 'sides' category. Also of the five restaurants that Jorge added to the application only a few were showing up. For example I was never able to find Subway!

All in all, I would say the app is a success and our idea is a hit! I wish I could work on it longer I feel like this has great potential to be an amazing, successful, and useful application.

Semester 2, Week 7

cdoll — Wed, 03 Apr 2013 15:07:20 +0000

It has been a while since I've updated this blog!

The Nutrition Team was on a bit of a hiatus as our Computer Science counter parts finished up to App so we could finally get some user feedback! I have to say I'm really pleased with what we have so far it looks amazing and runs how we imagined.

So far I've had a couple people look at our App and I've gotten really positive feedback. Most were saying how they'd love to use an app like this! The one suggestion I got was that sometimes things were considered 'slow' or even 'go' and they probably shouldn't be. We will definitely have to go back and reevaluate some of our equations and categorization.

One suggestion from a family member to help fix this was consider the individual categories and not just food as a whole. This came about when we were in the 'breakfast' tab and noticed that some foods seemed to be miss-labeled, oatmeal categorized as Slow even though we would consider it Go.

Overall, great feedback so far and I'm excited to see what others say!

Semester Progress (Part 3)

jbv — Mon, 01 Apr 2013 23:13:27 +0000

The application also had many usability tweaks as well. Any long operations were moved such that they work in the background while the user can navigate other portions of the application.

The layout for each page is now generated using the same methods for each screen, so that the layout is uniform between different screens. Uniform styles were also applied to each page of the application, to improve the appearance.

Minor tweaks were made as my understanding of Android increased -- layout optimizations that make the page load faster for the user were quite welcome.

The end result is a fairly user friendly application that should be ready for user testing. The results of our meetings up till now has been developing the app until this point, and now we are ready to test its usefulness to others. The rest of the team is giving me feedback on any remaining quirks or bugs in the app, and I am making the changes. Like it was mentioned in the database post, these changes can be made without physically updating the application on the device. I also created webpage forms for the other team members to use to update the database without me -- if, for example, they are struck by a sudden inspiration on health advice for a hamburger, they can navigate to a webpage and enter that in rather than open a terminal and be overwhelmed. I believe it is important that developer tools are developed alongside user programs, so that people other than computer scientists can be involved in development (or just so that development is quicker and easier).

The next post will have pictures of the application thus far, and will be posted when I have access to the necessary resources to take the screenshots.

Semester Progress (Part 2)

jbv — Mon, 01 Apr 2013 23:06:23 +0000

The structure of the application was also greatly retooled to allow for different use cases. Our team decided that in order to better accommodate different types of requests, we should allow for different entrypoints into a restaurant menu -- for example, if a user wants to find restaurants with hamburgers, he should be able to look that up rather than having to guess a restaurant name.

Since many of the network calls were tied directly to the which activity (which screen) was started in the app, this proved harder to finish than expected. The network calls needed to be completely abstracted out in order to allow a screen to be shown without being tied to network calls. In retrospect, this seems fairly obvious, but at the time, it didn't seem like something of great significance. This is a great lesson in how software extensibility should be taken into account at design time, so headaches can be avoided later.

My solution ended up being abstracting the methods of passing data around between different screens of the application. Because of this, the screen is able to display the data it receives, whether it came form a file, the network, another screen that has already done the work, or something else. This had the added effect of reducing the number of trivial network calls -- since the message passing framework was better, the amount of redundant work was vastly reduced.

Semester Progress (Part 1)

jbv — Mon, 01 Apr 2013 22:56:50 +0000

The blog may have been a little neglected these past few weeks, but great process has been made. I will split up the work into several topics which will be the subjects of the next few posts.

First, the database for the foods had to be updated with actual food information. To accomplish this, a parser was built that scrapes data from online restaurant databases in order to populate a database for our use. Although the parser needs to be tweaked and configured for each restaurant, this greatly simplifies the process of adding restaurants to the application. And since the restaurants exist on a server independent of the app, it enables restaurants to be added at any time without updates having to be made to the app. Among other things, this enables the user testing to get under way even without a completely populated database.

The database also handles a lot of calculations for us. For example, it takes care of classifying the foods into different nutritional categories, since it already has access to the nutritional information.

The database also allows for string searching of restaurants -- a function was added to the database that calculates the Levenshtein distance between two strings. Thus, when asking the database for a restaurant based on user input, we can also display restaurants that have a short Levenshtein distance from whatever the user typed in.

The database is not exposed to the public, as that is obviously a security risk. The only interface to the database are servlets of my creation that return predefined queries -- this way, there is no risk of the database being compromised.