February 27th - Revise Wireframe Design

Team Members Involved: Michael Del Fante, Micheal Seng, Jonathan Wai

Last week, I messaged our client, Paul, on potentially contacting their client for some interviews, but they have decided to keep communications closed for the time being. Until Ombitron is ready to open that door for us, we will work on the only assumption we have: that the current fridge monitoring system is a manual, visual task, and any design would be an improvement.

Eric wasn't able to attend today's meeting, but we needed to parse through the feedback from the previous week and create a revised design that addressed the concerns mentioned in that presentation. 

One of the biggest contentions we had was of Eric's submission of altering the folder display in the home screen, which sparked three design choices from the various team members:

• Keep all three status categories and count shown
• Show only Yellow/Red Status if even 1 is in either category, removes green
• Show only Status Categories that have 1+ fridges within, remove all categories with 0 fridges

We decided to experiment with each of these, and will present the altered scheme in our next Show and Tell!

Our new design has removed the "Secondary View," combining it with the Detail View. The sidebar in the Detail View will take advantage of side-mounted color bars to indicate status. For example, the following:

   Fridge 6
   Fridge 9

   Fridge 3
   Fridge 4
   Fridge 10

   Fridge 1
   Fridge 2
   Fridge 5
   Fridge 7
   Fridge 8

Fridges are ordered by Category first (Red = Critical, Yellow = Caution, Green = Operational), then by name/date (or perhaps another metric?). This utilizes the "List" variation that the class lauded in our presentation, in removal of the "tiles" secondary view that was panned. The original Folder System will stay, with alterations.

User Testing will occur more formally during and after our Presentation next week.

February 27th - Flask API Development and Design

Team members involved: Michael Del Fante, Eric Oltean

One part of our project includes writing up our own api documentation for Ombitron so that they will know how to use the methods that we create for the dashboard. This week, Eric and I focused on writing api documentation for the software that we have written so far, and will continue to update the api documentation as we continue developing. Unfortunately, we signed an NDA with Ombitron so we cannot show you the content that has been written since it has to do with the source code, but we can show you a screenshot of the files that are involved with creating the api documentation.

February 20th - Front-end Development and Implementation

Team members involved: Michael Del Fante, Eric Oltean

While the design team is working towards a finalized design, the development team has begun implementing a front-end for the detail view of the dashboard. The detail view is currently showing information about the overall status of a refrigerator, system up time, location, and graphs that records the change in temperature (both external & internal) and door status (open vs. closed) over time. The graphs are included to show the user if changes being made to the refrigerator status affects its overall status. The left sidebar will show all refrigerators in a particular location, and will allow you to add a new refrigerator. The top right corner includes login account information, connection information, and the overall status.

This is our first attempt to creating a front-end that will receive data from the back-end. The front-end will eventually look like our finalized wireframes, once they are finalized. The front-end was created with HTML/CSS/JavaScript, using Bootstrap and Jinja2, a template engine that is a part of the Flask package. See below to take a look at the detail view.

February 20th - Project Review and Feedback

Team members involved: Michael Del Fante, Eric Oltean, Micheal Seng, Jonathan Wai

Show and Tell time!

Today was our first presentation for our Capstone class, where we presented our progress to the other groups. We showed off our prototypes, and it got bashed, criticized, and inspected on every level. It was a huge success!

The point of this exercise was not just to show off, but to garner immense feedback on what didn't work, and to make those changes and create a better product.

I attended a workshop on "Customer Development" the night before this presentation, so I used some of that experience into the presentation by conducting a basic exercise in gathering Customer Assumptions. I asked the class what they imagined they'd do as Refrigerator Monitors at CenturyLink Arena, and their responses (as well as the positive/negatives they gave) matched some of my initial insights, and added a few additional aspects I didn't consider.

The feedback we received on our prototypes was valuable as well, and with after confirming or denying the assumptions above through future interviews with CenturyLink Employees, we will be set on creating a better interface. Here is a list of the feedback we received:

• There's an upper limit on the number of devices visible within a folder
• What if all fridges were red? 
• Perhaps combining them somehow would work? "Stacks?"
• # of fridges in trouble next to # of fridges in folder? 
• "Mouse over"
• Provide a list, sort by temperature and other metrics
• Add Folder button is too small, and doesn't know exactly what's being added
• Map Mode
• Non-symmetrical design (breadcrumbs)
• Add folder with immediate fridge input as well
• Settings per fridge
• "Classes" of fridges
• Fridge type/brand
• Export data to excel
• More advanced notifications
• More grouped errors, but how to group them exactly?
• Tags
• Grid system should show fridge location
• Additional layout?
• List view
• Table view
• Track failure-to-repair time for marketing
• Security issues?

These suggestions will definitely be considered as we move forward with development, but my next step, personally, is to figure out what kinds of things the CenturyLink Employees want. While these design and technical choices are all great critiques, this product is for a non-designer, and will be the best reference to base all design choices on.

February 13th - Back-end Development Updates

Back end Development was started by Eric and Michael. With the database setup we began to develop the back end of the site to communicate with the database that we had already setup. This was done in Flask using the Sql Alchemy framework and restful Framework. This allowed us to easily connect to our sqlLite database and begin testing on our database structure and design. We have just initially created endpoints for requests to be sent to delete Refrigerators and create them. We also added the endpoints to get information about the added refrigerators. The development is still in a very early phase and may be subject to change.

This Milestone is very important for our team it helped Eric and Michael get better acquainted with a practical use of Flask and its popular Frameworks. It also allowed us to test the structure of our database. This will be a stepping stone for future development on both the back end and further front end development.

February 13th - Complete Preliminary Dashboard Design

Team Involved: Micheal Seng and Jonathan Wai

Here, we have a complete first draft of our concept's wireframes. In this mockups, you will be able to see all the drop-down menus and a much clearer idea on our three level view concept. The idea was to have three level view for different roles purposes. Currently, we have not have a full understanding on our personas and scenarios. This is all based on our own perception on how the dashboard would looked like and information that was shared with us from Eric.

Landing page of Ombitron's Dashboard

User clicks add button.
Currently, from our understanding, we are only focusing on refrigerator, but over time, the device can be installed on other machines.

New folder popup

New Refrigerator popup.
We are still unclear about the information required to connect the device to the dashboard.

User settings
We are in the process of acquiring more information regarding what user can and can't do.

Notification
User would be able received notification, when someone added refrigerator or rise above the maximum internal temperature.

Second level view of dashboard
This includes more detailed than the previous level view. From here, user able to click on an individual refrigerator to see more details.

Last level view of dashboard
This view has all the pertaining information on the refrigerator. Left panels indicates all the other refrigerator on the same folder, in case if user wants to view other refrigerator.

February 6th - Prototyping Wireframes

Team members involved: Jonathan Wai and Micheal Seng

This time, I'm showing the concept of a possible different role that wants to view different amount of information pertaining to them. The first level would only show an overall status of refrigerator through an icon of refrigerator. The second level would have the overall status icon and other informations (voltage, internal and external temperature, and uptime). The last level will show all the information pertains to the refrigerator; graphs of voltage usage, uptime, internal temperature, and external temperature.

1st Level View of Dashboard 2nd Level View of Dashboard The Last Level of Dashboard

February 6th - Technical Adjustments

Team members involved: Michael Del Fante, Eric Oltean, Jonathan Wai, Micheal Seng

After we compared our sketch mock ups, it became apparent to us that we didn't know exactly what types of data the refrigerator hardware could detect. We all had different ideas about what features we could include in the final design (such as monitoring efficiency, voltage, etc.), but we didn't know if the hardware would limit these features from being possibilities. Through Eric, we asked Paul what data the hardware could and could not detect. Paul explained to us that at this time the hardware could only monitor the internal temperature, external temperature, and whether the door was opened or not. Now that we knew the hardware limitations, we compiled a list of features that we want to implement for the detail view of the dashboard. These features are described below:

1. Overall status - Shows the current overall state of the refrigerator (on a green, yellow, red scale)
2. Current internal temperature
3. Current external temperature
4. Door opened/closed
5. Graph of temperatures over time - For observing trends
6. Graph of how long door is opened/closed - For observing trends
7. Phone/email notifications - Notifies whoever is responsible for that refrigerator if status changes to red
8. Emergency contact - Each refrigerator has some kind of information about who to contact if they notice anything strange happening
9. Notification bar - If there's something wrong with a refrigerator, a notification bar will appear at the top to display the problem

At this time, we do not know all of the details about how we want to implement these features. But this exercise was necessary for this project because it was very helpful for narrowing down both what capabilities the hardware has and what features are in the scope of this project.