High Fidelity Prototype
The High-Fidelity prototype was created as a parallel process to the Medium Fidelity Prototype. The main goal here was to implement and test the full functionality of the application, while the other prototype focused more on the aesthetics and the setup. The aim was to implement as much functionality as possible, but the social aspect that made the application unique; the tips section, was prioritized.
The functionality implemented is as follows. This also discusses the functionality not implemented.
- Login The login page has buttons to sign in with Facebook or Email, and un-styled input boxes to login with users from the database. The system has different users, and you can log in using for example username: admin and password: admin.
-
Inventory:
The inventory includes a list of all the grocery items the user has registered to have in their home. Within each item, you can see:
- Quantity, with the option to increase or decrease
- Expiration date. This is collected from the database, but is for now only placeholder data. In the future, this would be calculated based on when it is bought and expiry dates or quality on the time of purchase.
- Tips. This is the social aspect of the application, where the user can share tips, read tips and rate other comments. The rating is per today a thumbs up/thumbs down system and no restrictions are set per user. In the future, the list should update so that the best rated comments are at the top, to make it easier for the user to know what tips that works. A profile photo and the name is included in the comments section so that the users can feel more personally connected to the tips.
- Recipe. This is only a placeholder button, recipe information is not yet implemented. The user testing did however come with some suggestions on how this could be done.
- Throw or use. If the user is throwing out items or using them, they have the options to push these buttons. This will be stored with their profile page and they will be able to see statistics of this in their profile page. For now, when the user throws or uses an item, it is only counted as one item, and what type is not stored. For the future, the user should have the option to choose how much they are throwing out of their item (say you have three bananas and only wish to use one). In addition, the page includes categories and adding items:
- Category. The items are in the database categorized as Fridge, Freezer or Dry Pantry and the user has the option to see what they have in the different categories separately.
- Add item. When the user clicks the input field at the top of the page they are given the option to type in grocery items. This searches in the database for grocery items with the same name. When clicking an item, the user is prompted to select the quantity they wish to add.
- Scan: This is a placeholder button with no functionality yet. The idea is that users that do not wish to use the grocery list can scan their receipt to add items to their inventory.
- Select: This is a feature that lets you select the inventory items and either trow or use them in bulk, same way as the grocery list items described below. This is not yet implemented.
-
Grocery list:
The grocery list page includes a list of the items the user has stored in their grocery list. This is stored in the database just like the inventory.
- Select items. The checkboxes next to the items lets the user check the items they are buying. The field is greyed out when selected, making it easier to keep track of what is picked up and not when in the grocery shop.
- Purchase and delete. The user can select these after ticking off items. The selected items will then be either removed from the grocery list and added to inventory or deleted from the grocery list.
-
Profile:
- Statistics. This feature was not a focus of this implementation. The statistics shown are real statistics of how much the user has used or thrown in the inventory list, but a lot more information can be added to this in the future. For example could what type of items be very useful to know.
- Log out. This logs the user out of the application. The application is hosted on UQ’s servers, which has some issues with the CORS restrictions and will not allow us to refresh the page when in a sub-page. This makes it appear that this functionality is not working, but all you have to do is remove the /profile from the url. This works locally.
The prototype was created using React JS and the database used is Google Firebase. The UQ server is used as a hosting website. We started the project using Php as a backend script. As this requires a server to run, we uploaded the files to the UQ server to run the program. The issue with this was
- UQ servers had some technical issues where the server access was limited for some users at some times. This made development difficult as the server was necessary to run the project, but the developers was denied access to publish content on the servers at random times.
- React needs to be built to be able to run on a server. The project needed php to be able to run and php needs to be run on a server. This required us to, when making a change; save, build (takes up to a minute), upload the build to the server, save the php files and accept the change to the server and then refresh the web page. In addition, there was the CORS-redirect issue that didn’t allow us to refresh the page with a sub-page, requiring us to remove everything behind the slash before updating.
These things stole a lot of time from the project development. After the problem with the server occurred, we made an effort to change to a more reliable database. A lot of research and time went to this as well, and in the end Daniel (tutor) managed to help us connect to Firebase, which was a much better option. With this we were able to run the project locally while connected to the database and was not yet depending on the unreliable UQ server. However, Firebase is a NoSQL-based system, using JSON Trees instead of databases. Neither of the team members had worked with this before so it took some time to get used to this. We had some issues with indexing, as this was not a thing in the real time database, and tables being deleted when there was no content. As we focused on getting the functionality up, a lot of focus was not put on error handling.
Figures showing sections of the JSON Tree created in Firebase
The working prototype can be viewed at https://s4540545-ppg.uqcloud.net/.
As a side note, the testing session was a hard time for the application. Everything was working fine before this, but after users removed whole lists and tried different functions, things started having errors. This was an important lession for the coders for future work about error handling, but unfortunately there was no time to correct these errors. For example is the grocery list not displaying the items added anymore, and the inventory works at various times. We experienced Firebase to be a bit shaky, but not implementing error handling or take empty tables into considerations was definitely a part of the issue. We apologise for any inconvenience for this, but we were able to display a working prototype at the day of the showcase.
The design was heavily based on the design from the medium-fidelity prototype since this prototype would mainly display the functionality. Some changes were made, however, to better suit the functionality and to better present the social aspects of some of the pages.
On the front page, a new font was added to make the app name or logo stand out more. The font chosen for this purpose was Lobster because of its fun expression and its uniqueness compared to the other fonts used. On the grocery list page, it was made so that when an item was selected using the checkbox, that item was made transparent to highlight for the user that this item had been selected already. These were the only small changes that were made different from the previous prototype.
The tips page was redone with the addition of profile names and images to indicate who a specific comment was from and to bring the social aspect of the app more apparent. A tester indicated that it didn't feel social enough when no information regarding the poster was present, so this was of course changes accordingly. Also, to further enhance the social aspect we added a rating system with the use of thumps icons to either upvote or downvote a comment. The highest-rated comment will appear on the top of that specific item tips page. Further changes were the switch from a yellow background to a white on the comments itself since this helped bring the comments out from the background. In addition, the supplementary yellow was used to divide the comment from the rating and to show the item name underneath the title.
The other page that was redone for this prototype was the profile page. Here the profile page was added just beneath the title to indicate whos profile page this was. The graph was added with new colors that were chosen from the color scheme. Also, underneath the graph, the "used" and "thrown" numbers were displayed separately with a yellow border in between to separate them. Lastly, the boxes that contained the graph and the info was made white to bring them out from the background.
The icons used for this prototype was from fontawesome.com and was installed on the app using npm. The reason being that these icons were similar to the ones used in the medium-fidelity prototype and they were available with react JS. Also, the icons used in the other prototypes were from Figma itself and therefore difficult to incorporate in comparison.
https://github.com/FortAwesome/react-fontawesome
The graph used on the profile page was from react minimal pie chart which was a fast and easy way to integrate a graph. This addition was also installed using npm. https://www.npmjs.com/package/react-minimal-pie-chart
Lastly, the images used for the profile pictures were from pexels.com and can be found here:
https://www.pexels.com/photo/man-wearing-black-zip-up-jacket-near-beach-smiling-at-the-photo-736716/
https://www.pexels.com/photo/women-s-white-and-black-button-up-collared-shirt-774909/
https://www.pexels.com/photo/smiling-man-in-front-of-green-plants-2078265/
The aim of the prototype testing session was to test
- The learnablitiy
- The usablitiy
- General feedback on the design of a working prototype.
- Do you understand the purpose of our application?
- What do you think of the navigation?
- What do you think of the design? Do you have comments?
- Do you think using this application would help you reduce food waste? Why/Why not?
- Do you see yourself using it regularly? Why?/Why not?
- What else could motivate you to manage your food better?
- Any other comments?
The testing session for our high fidelity prototype was conducted differently than those for our low and medium fidelity prototypes. For the previous testing sessions, we had to create tasks for the user to complete in order to assess our app but the increased functionality offered by our high fidelity prototype allowed us to offer users free rein of the app. We observed their use of the app and answered their questions or doubts when necessary, it was like a teaching process which in itself indicates that we might need to include an overlay tutorial that informs them of what the app can do. As with the first two prototypes, the results of a post use interview are summarised below.
Grocery List
"Normally I would add what I bought from a paper list. But I think its very relevant in these times."
Questions about using the app were to explore how users would react to the features that were available to them. The Grocery list was included to make tracking the inventory easier for the user. Results from early user interviews told us that people were unwilling to spend time taking stock of what they had. This could easily be bypassed by giving them a function that would track what they were buying. It was important to understand the shopping behaviours of users. More than half of all users that we interacted with over the course of this project made grocery lists either on paper or the note app on their phone or a multitasking organisation app that they used to make list. It was interesting that none of them used a dedicated grocery list app but that they were willing to use technology to serve this purpose.
Additionally, we proposed a scanning function for the rest who impulse shopped frequently or just made mental notes of things to buy. This feature, when implemented would scan the users' receipts and populate their inventory still recording dates of purchase and corresponding expiry dates.
Recipes
"Recipes is quite important for me at least. If you create a recipe, do you have to find each and every ingredient, would it remove it from the inventory? That would be useful. "
"...you have the recipes and the tips that would be useful. Maybe like an expiry date like reminding you to eat it."
Users tied their food usage to recipes i.e. how they were using the food. This seems obvious but it was unexpected to learn that if not prompted be recipes by their everyday interactions, their motivation to use items drops.
Motivation
"If I’m planning to go out I’ll have an overview of what I have so that I know that I need to go home and cook."
"The problem is that is when I know it's gonna go bad I don’t feel motivated to use it."
"What about the expiry date? Are there any plans for this?"
"Maybe like an expiry date like reminding you to eat it. "
It was clear to us that different users responded to different stimulus. Individuals that were already motivated to prevent their food waste were happy to use the inventory function actively and inform their choices on eating. While others needed an extra push:
- a reminder notification that things were going bad.
- a suggestion of recipes they could use quickly that would prevent those items being thrown away.
Profile
"It would be useful on the flip side when you come in and see what’s thrown, that way you can know what to not buy"
"I would like to see the items I have used and thrown. If you want to look for a trend, that would be interesting to look at."
Users wanted access to specific items they had thrown away. They were either willing to identify trends themselves in their use and throw behaviours or wanted the app to do it for them. This made sense, once again the profile page was intended to draw criticism and comments of this nature so we would have a clearer idea of what to include here.
As expected, the profile page drew a lot of attention from users, particularly because it was not complete. This is because our goals specifically targeted the implementation of social technologies which lead to the persuasive aspect of this design to take a back seat; This did not mean we did not explore the possible features we could implement on the profile page to motivate regular and dedicated use.
Gamification
"On my watch there is achievements, gameifying it might be interesting to do the same on this app. You get badges in the app."
We received more recommendations to gameify our app as a motivating feature. We did not see this with our first iteration. It seems that the more we refine our concept, the more engaged users are in giving us feedback. Gamification, as explained previously, was not a front runner for this application but it looks like it will have to be in consideration for the next iteration of this app.
All users understood the purpose of Food Saver. It was particularly interesting to see that every user valued a different feature of the app while acknowledging that the other features were also needed. The design of the app was appreciated by all users of this testing session but several comments from the medium fidelity testing session indicated that the colours that were present may be overwhelming or too prominent in the app, something that will need to be addressed. As discussed in the medium fidelity test results, creating themes that users could choose from would be a good way to make the design more appealing to a wider audience, especially if the colour scheme will be a deal breaker that affects a user's ability to use the app.
We also received feedback on how displaying items in categories in the inventory might be worthwhile. Our limited database of items for this prototype lead us to not consider the possibilities of buying more than one kind of same item. For example, some cheeses last longer than others and each of them could be listed under an umbrella category of cheese. The individual cheeses that the user had could be made available to them when they wanted it. We can only cross this bridge with further development and it is expected that the application will also undergo design changes as these suggestions are implemented.
In conclusion, most user feedback has served to improve our understanding of the users and improved our implementation. We leave the unimplemented features for developers who may pick up this project in the future. Over the course of completing this project we have learnt more than we could have hoped for about this domain, user behaviour and related domains and practices that could vastly improve the applications we create.