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 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?