June 5th - CAPSTONE Event

Team Members: All

And that was that! We are officially done!

We presented our project alongside all the others at the Capstone Event on the evening of June 5th. We talked to quite a few people, many of whom were very interested in our solution to a mundane problem. Michael had a really professional, honed pitch; Eric explained much of the technical aspects; Micheal charmed friends and strangers alike to check out our project; and I filled in all the gaps when people seemed out of breath or were otherwise absent. Overall, we made a really good case and walked away with a few impressed visitors!

The judges were much harsher critics; rightly so, but it still felt a bit stifling. One of the major concerns brought up was that we should be more entrepreneurial in our endeavors, that if we had made this on our own, we could differentiate ourselves in the market. I understand why it was asked, but I still feel it ignored the context of our project and its original intent, which is that it was made for Ombitron and will continue to be used by them.

At the end of the day, we have an awesome project that will serve as the basis for future products by Ombitron, which is a fantastic portfolio piece and something I think all of us can be proud of.

Our final CAPSTONE Poster

Thanks for keeping up with this blog and this project!

May 29th - Finalizing Presentation Script/Poster

Team members involved: Jonathan Wai and Micheal Seng

Currently, we are about 80% done on the poster. From the feedbacks that we got last week, a lot of people didn't understand what our project was about. They didn't know what problem we are trying to solve or which industry is Ombitron in. Therefore, we are focusing on cleaning our content to make sure people understand our project. Also, we were struggling with the problem statement for our poster between explaining Ombitron as a whole or just the dashboard. After today's meeting, all of us agreed to give readers the understanding of both Ombitron and our dashboard.

Here is a quick peek on our design:

This is the second draft of our poster - we realized this design is much cleaner and concise than our previous draft. This week we will polish both content and the architecture of it, before we print it out.

May 29th - Present Completed Project to Client for Final Review and Receive Final Feedback

Team members involved: All

Since our capstone project is pretty much completely finished, we had the honor of getting to go into Ombitron and presenting our product to them. We got to explain our process, design decisions, and how we worked as a team. This part of the milestone was very important for having us practice our presenting skills to an audience. From this presentation, we now have a clearer idea about how we want to present our project at the capstone event.

The second part of this deliverable had to do with receiving final feedback on our project based off of the user testing done by Ombitron since we make corrections based off of the last bit of user feedback we received. Unfortunately, Paul was very brief with us about giving meaningful feedback. Our team came up with a long list of questions to ask Paul, but his response only answered a few of the questions that he had. I can only imagine he already has a lot on his plate though being a CEO of the company. Regardless, Paul did let us know that he gave multiple demos of the dashboard to clients. They didn't have anything negative to say about the dashboard, and found it easy to use. They were able to tell what the graphs were and found the data valuable and easy to understand. Paul also agreed with us about changing the colors of one of the icons and gave us more information about how the hardware measures humidity.

This part of the deliverable helps us resolve any worries we had about making any last minute changes. Perhaps our process for obtaining information from Paul was flawed since we contacted him over email. we could have gotten more useful feedback if we chose a different way to contact him about feedback. Nevertheless, this part of the deliverable helps our team finalize our capstone project and allows us to solely focus on the poster from here on out.

Below is a screenshot of the email we sent Paul and the feedback we received.

May 24th (UNLISTED) - Success Definition and Operationalization

A few weeks ago, we were tasked with creating a document on "Success Definition and Operationalization;" basically, a list of goals that would define whether our project was a success or not. These will be listed below, along with our analysis of our success in those regards: successful goals will be defined by green text, and failed/uncertain goals in red.

-----------------------------------------

1.) Users can easily connect and organize devices within the dashboard

• Automated connectivity removes mundane tasks from user workload
• Device Groups in “folder system” allows easy management of devices
• Admin users can manage/group users to have specific permissions

This success definition primarily focused on the Dashboard's functionality, and whether users responded well to those specific features. This was indeed the case, as all of Ombitron's testers reportedly had no problems understanding their capabilities and completing the tasks given to them.

-----------------------------------------

2.) Users of all skill levels can monitor the status of all connected devices quickly and accurately

• Users will need only basic training to be acquainted with the system
• Users can scan the Detail View for metrics information and graph performance overviews
• Minimal effort to discover errors, measured by TLX Task Load for 50 connected devices
• System outperforms competition with direct visualization of device metrics vs. sole list view

Unfortunately, we were unable to obtain any further testing data or metrics from Ombitron aside from a few quotes, making it impossible to critically analyze the results of Ombitron's formal testing. We could do some testing of our own to make up for this, though our data will not be significantly useful; the target audience of company workers and businessmen will not be the ones we test with. That lack of context will hamper efforts as students and friends don't have the same mindset, nor interest, for such a product. On the other hand, if they can use it well, it speaks to the effectiveness and simplicity of the Dashboard for non-specialists, which might be good point to make. 
That... might not be a bad idea. We may or may not conduct a few more user testing sessions with our Dashboard. If we do, expect an extra blog post about that.

We do know that the visualization of the Folder View provided some users great clarity in testing, so that one goal was a success. Those who preferred the List View used that, but more casual users found the Folders more appealing and clear. Having both options allows the Dashboard to be more adaptable depending on the preference of the user.

In the meantime, we have requested any of the following information from our client:

• What confidentiality is in place that prevents us gaining the any of the information requested in these other questions?
• Who was tested: businessmen, stakeholders, random employees, target users, other? Not looking for names, just benign tester information. How many, and for how long?
• What were their tasks? How many tasks, and how complex?
• Which features would be used in these tests?
• How many testers passed all tasks? Were there any difficulties in any of them? Which task took the longest? The shortest?
• What questions were asked by testers?
• Did the facilitator provide any assistance during testing? If so, what?
• Were there any specific testing metrics used? SUS, TLX Task Load, custom forms, or other?
• Are there feedback sheets or transcripts we can get a look at?
• Which companies "demoed" the site? If that information is unavailable, at least what was their size (startup, corporation, multinational) or industry (tech, industrial, venue, etc)?

-----------------------------------------

3.) The results are used by Ombitron for current or future projects

• Web 10.0’s dashboard as the baseline for Ombitron’s other products and services
• High SUS reported when used by client companies (CenturyLink Arena, others)

The second bullet of this Success Definition falls under the same problems as the one above.

The first, however, is very, very much a success. Ombitron is using our design moving forward, and the demoed design has been ours from the beginning. We expect continuing development based on our ideas for this product and ones like it in the future!

-----------------------------------------

So hopefully that covers it. The lack of testing data is a setback, but hopefully our own testing sessions will give us the stats we need to provide context as to whether our goals have been achieved or not. 

May 20th - Post-CAPSTONE Submissions Update

Team Members Involved - ALL

So Capstone deadlines came and went! Well, with the exception of the student survey fiasco. But luckily we were prepared, so Web 10.0 is nearly ready to deploy for the event on June 5th!

But we never got a chance to share our final work. It's with great honor that I formally introduce our project!

"Is Your Refrigerator Running?" Device Monitoring System Dashboard

Abstract

CenturyLink Arena is responsible for maintaining over a hundred refrigerators to keep products fresh for their customers. Every broken fridge costs CenturyLink more than $1000 in replacement parts and product. Existing Device Monitoring Systems (DMSs) can be used to track fridge failures, but are difficult to navigate and require data analysis training to use. 

Web 10.0 has teamed with Seattle startup Ombitron Inc. to create a new platform-as-service DMS to solve these issues. Ombitron hardware detects a variety of critical metrics about a device, then Web 10.0’s Dashboard interface delivers this information to users in a streamlined and visually appealing style for at-a-glance notification. Detailed metrics and time graphs are also available for each device to track history and changes in performance. This Dashboard will be adapted to suit a wide range of devices, and is currently being considered for use by multiple companies.

___________________________________________________

See our product in action...

Watch our pitch video on YouTube

Or visit us live and in-person at the iSchool Capstone event!

iSchool Capstone

June 5th, 6-9pm

HUB Ballroom, University of Washington
___________________________________________________

Thanks for following us this far! Here's a sneak peek at our poster design!

May 8th - User Testing of Database and Advanced Features

Team Members Involved - Eric Oltean, Micheal Seng, Jonathan Wai

Unfortunately for us, Paul was out of the office for the last two weeks! However, Eric linked up with him this Friday and got the client feedback from Ombitron's testing sessions.

At least two companies tried out the prototype for general user testing and potential use. For security, we haven't been given the company names or their representatives. Here is a link to the demo they had access to: http://temphum.ombitron.net/

Pros: Most everyone liked the Dashboard! There was a lot of positive feedback, though none of it particularly specific. All clients were able to use the Dashboard effectively and complete testing tasks. Some of their comments:

• Interface was very "Usable," "visual" 
• Easy to navigate; no problems switching between tabs, views, or back out
• Clients liked the "two systems for viewing": some preferred the List View and found no use for the Folder View, while others loved the Folder View and its simplification of the List.
• "Simple overall," with no major problems of user experience

Cons: A few nitpicks here and there, but nothing major from a design standpoint. Instead, most were slight technical adjustments, a few content adjustments, and perhaps even some per-client customization based on their individual needs.

• Temperature graphs were noted to be in Celsius. Of course, since the product will primarily be launched in the US, all clients wanted this information in Fahrenheit 
• The refresh rate of information (rate of capture from device to dashboard) didn't need to be as frequent as the demo's setting of updating every 9 seconds. Suggested refresh rates by clients would be anywhere between 1-5 minute intervals, perhaps even up to 20 minute intervals.
• Client-specific request: On the Detail View, "Status and Location" is first thing seen on the page in the upper left. However, to this particular client, this information is not as important, since the user should know which fridge they're looking at. The Client has requested that graphs or specific information should be displayed first, then status and location if necessary (lower hierarchy)

So overall, things are looking very good! This weekend will hash out the Promotional Video and Abstract, along with these final tweaks, and then the poster. Getting close to the end!

May 8th - (UNLISTED) Ideation and CAPSTONE Progress

Team Members Involved - All

We spent the majority of our meeting today on the remaining Capstone requirements, namely the Abstract, Poster, and Video submissions.

In our discussions on how to proceed with those steps, we discovered a few points of information that were previously missing. We've added them below for reference.

• Get a list of other DMS-able devices (to show our Dashboard as a proof-of-concept)
• Highlight the fact that the Dashboard can be connected to devices via Ethernet connections and mobile internet
• Focus on the strengths of our dashboard; simplified measurements display, fast information gathering

Abstract

We're still working on it! It's difficult to come up with the right words and concise approach to introduce our project without putting too much focus on background information, while avoiding over-simplification. Michael and I will be working on getting the abstract concise and up to par with the rest of our project.

Poster

We've been working on the poster design, trying to take cues from our Dashboard as the placement. Unfortunately, there isn't enough room on this particular design for images, so this idea will have to be modified in order to adapt to the poster format. We'll try to be taking cues from last year's Capstone posters, in order to see what layouts were ideal for images and text in equal but minimal measure.

Video

A lot of groups are opting out of this assignment, so we're opting in! One of the major choices we must make for this video is whether to intice or inform. Which direction fits the video's purpose and content best? Every team member had a different idea, so we're each writing our own scripts and figuring out which direction works best. Scripts will be due by this Saturday, and filming will occur the next weekend.

Personally, I'm hoping we can put "Is your refrigerator running?" on the Poster at least, and perhaps in the video as well. It's such a great tagline!

May 1st - Begin Posterboard Design

Team Members Involved: Micheal Seng, Jonathan Wai

Today's work focused primarily on the Poster Design, since the groundwork for the Dashboard is mostly complete at this stage.

My idea was to model our poster after the Dashboard, to show viewers our project in an interesting way while maintaining "brand" recognition. We'd adapt some of the UI Elements to present different information. Color presented a bit of a challenge, since we wanted to represent the colors used in the Dashboard, but some of those colors didn't provide good enough text contrast and conflicted with the design. In addition, the layout needs some work, since we want to inform viewers about what our project is and how we solved the problem as quickly as possible, to save ourselves time and energy in explanations.

Our initial mockup design

One concern Micheal brought up was that we didn't know what information needed to be on the poster, as well as a lack of knowledge on fundamental poster design. We'll look into these topics and return when we've done our research. So far, however, progress looks good!

However, we are also concerning ourselves with the May 19th deadline on the Abstract and Video for the Capstone guests. We'll hopefully get some time to discuss this topic with the team.

May 1st - "List View" Interface Completed

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

This week the entire team sat down and worked on the List View interface. Based off of the feedback we received, we found that the Folder View isn't the only way that people want to be able to get a quick overview of the status of all devices. When looking for a quick overview, we found that some users don't want to have to look at each folder to find out if there's any devices with an error or warning status. Users also wanted a way to be able to sort through different types of information for the devices, which the Folder View isn't able to do. Thus, the List View has been created to solve these two problems: to be able to take a quick glance and recognize which devices are problematic, and to allow the user to sort through all devices.

The four of us sat down and discussed what the list view should be composed of. We made a few rough sketches of what we thought it should look like. We debated about what information should be shown and decided that we should allow them to sort by status, name, location, temperature, and humidity. After this was completed, After our meeting, Eric and I worked on developing the list view.

Completing this deliverable advances our project because now both ways of getting a quick overview of the devices are implemented. The main features of the monitoring system has been completed, and now we are going to focus on polishing and making small improvements next. Take a look at the screenshot of the implementation of the list view below.

April 24th - "Folder View" Interface Completed

Team members involved: Michael Del Fante, Eric Oltean

This week we focused on completing the "Folder View" interface. The Folder View was implemented to solve two problems: to be able to take a quick glance and recognize which locations have problematic devices, and how to organize devices by location. The Folder View allows the user to be able to add refrigerators to a particular refrigerator, which solves the organization problem. The Folder View also allows the user to be able to quickly glance at each folder and see if there are any devices that have warnings or errors. In addition, we added tabs at the top of the folder view to make it even easier for the user to scan and see if there's any problems, instead of having to look at each folder. We added this feature because we had received feedback that it would be time consuming to look at each folder if there's a lot of different folders.

Completing this milestone took a lot of re-working the way the back-end was implemented. Eric and I divided up the work by choosing distinct parts of the folder view to work on so each part doesn't conflict with each other. For example, Michael started working on the front-end, while Eric started re-organizing the back-end in Backbone. This way both of us were able to continue working independent of each other and doesn't have to wait to complete the next step. Using this strategy, we learned a better way to collaborate and work on development together, since earlier in capstone we would find that one of us would be stuck waiting for the other to complete their part of the project before continuing.

Completing this deliverable is a huge advancement in our overall project because it is one of the two different ways a user can get a quick overview to see if there's anything wrong with a device and which location the device is located. Our next steps is to complete the "List View" interface, which is going to be a different way for users to accomplish the same goals that the "Folder View" accomplishes.

Our screenshot currently has different icons because Ombitron wanted to see what it would look like if they were to customize their platform to devices other than refrigerators. Take a look at the folder view implementation below.

April 17th - Design Interfaces for Secondary Features

Team Members Involved: Micheal Seng and Jonathan Wai

The goal for this Milestone was to draft designs and concepts for some of the secondary features of the dashboard. Unfortunately, we got sidetracked by thinking deeply about many new assignments to come, namely the Poster Design, the rewriting of our Abstract, and potential video pitches. Because of this shifted focus, we weren't able to go over the designs in detail as originally planned.

However, we did make a list of improvements to make with our site's secondary features, such as:

• Making the ADD button larger and more prominent (a longstanding complaint of the system)
• Shifting around the layout of User Settings to facilitate better flow and grouping of options
• Potentially creating more intuitive ADD forms for Folders and Devices

As for our sidetrack goals, we got a good number of ideas on the table for the following:

• Poster Design: A Color Inventory was taken of our existing Dashboard design, and this color scheme will most likely be used in our poster design. Actual layout pending.
• Abstract: Given the feedback in lecture today, we took a new look at our abstract. We only got one coherent sentence down, but it's a much stronger pitch than our original abstract. The new first sentence is "Modern companies rely on an increasing number of devices that they cannot effectively manage." More tweaking is required to reduce vagueness, but it's a good start.
• Video Pitch: We wanted to make our excitement known about our product, and Michael (Del Fante) jokingly mentioned "Is your refrigerator running?" The idea of using a joke for lightheartedness, while being able to accurately answer the question, really resonated with me, and I would like to use it for our pitch moving forward.

So while this milestone didn't exactly get the stated goal completed, we got a few thoughts for moving forward with our project in other areas. Micheal (Seng) will update this entry later when he's sketched up some of his ideas for the secondary features.

Team Members Involved: Micheal Seng and Jonathan Wai.

Here are the design interfaces for secondary features.

3 options on the menu - Profile, Group Management, and User Management

Profile - landing page (possibly change in the future)

Profile - edit

Profile contains information pertaining to the user, which are name, email, phone number, and notifications settings (email and phone)


                           

Group Management

Group Management - add

User Management

User Management - Add

There are two types of actions that can be taken when user hover over specific group / user, either edit or delete. Currently, you can see there are two types of actions UI: only text mode or icon+text mode. I'm afraid the icon is not intuitively to all user and also the text edit and delete only shows up when user hover over it.

Currently, permission settings is sets by Ombitron. But, there are possibilities that this will be more flexible, where client could have the flexibility to name and set settings for each permission.

Under Permission Settings: Super Admin, Group Admin, Admin and Basic.

Super Admin: Delete groups, users, folders, and users. Add group, users, refrigerator, and folder.

Group Admin: Add+Delete group and user. Add refrigerator and folder.

Admin: Add+ user, refrigerator and folder. 

Basic: View folders and refrigerators

April 17th - Implement Secondary Features

Members involved: All

Based on Micheals new designs Michael and Eric have started to implement some more of the additional features. As of right now we only have one of the features fully implemented. User profile settings. This profile page is a page under user settings that allows the user to alter there profile information.

This was implemented using the flask security framework to edit the user and his settings and information. It is a single page that shows the users information and what they can edit. This taught Eric and Micheal how to better utilize the flask security framework.

This is a very important page to have in a user based system. As users often want to change there information and settings.

April 17th - Make Site Live for Testing

Team members involved: Michael Del Fante, Eric Oltean

This week, Eric and Michael worked with Ombtiron's employees to migrate our current implementation of the site from our local git repository to Ombitron's production servers. We also gave them a quick demo of the remote monitoring system.

By making the site live, Ombitron can now test out our application to ensure that it is working properly and performs the desired functions. They will then get back to us with any changes that they would like to see made to the monitoring system.

This was an important step in the process because this is the first time that Ombitron has full access to a working implementation. It brings us one step closer to having a product ready for them, and allows them to demo the software to their clients. Our deliverable for this milestone is the url to the live implementation. Feel free to take a look at the site for yourself below.

http://monitor.stg.ombitron.net/login?next=%2F

April 10th - Group System Interface Completed

Member's involved: Eric, Michael, Micheal, Jonathan

We Worked on setting up and completing a system for group creation and management. This system allows an admin user to create groups and users for a given group. This allows for better control of user permissions and what a user can see. It also allows one Admin user to manage multiple groups which could represent multiple companies or organizations ect.

Our team brainstormed the best way to manage group settings we also talked to our client Ombitron. we came up with a conceptual design and Eric and Micheal implemented it on the site

This adds a lot of value to the site it allows for more control of user privileges and makes for a more customizable user experience.

Picture of how you can add groups as an administrator

Picture of how you can add users to a given group

April 10th - Bugfixes, Tweaks, Demo Progress for Client

Team Members Involved: All

When the group returned from Spring Break, Eric had made some more adjustments to the Dashboard based on feedback from our client, Paul. He managed to find a meeting time a week or so before its actual due date, which puts us ahead in terms of this milestone. These changes were well thought out and designed as well. However, the rest of the team was unaware of these changes until after our first meeting. As a result, we had to readjust our expectations to the new layout, and the milestone order has been adjusted as well.

I've asked Eric to compile a list of all the feedback he received from Paul's testing session, and here is what Paul wants:

• Client wants a list view for an alternative way to view same information as the folder system interface
• Added a summary page of all devices
• Added group settings for better administration control
• Add a way to export data into Microsoft Excel

We will be using this feedback to move forward with our design. In addition, we held another show-and-tell where we got good feedback about our secondary features.

Notifications: "Fridge Failure at Pod 1." No numbers.

Uncertainties to clarify with Eric/Paul:

• Is each device given a pod, and that pod transmists? Or can multiple devices be connected to a single pod (like a Router)
• What was Paul's feedback?
• What other constraints about this project do we not understand yet?

March 13th - Detail View Interface Implementation (almost) Completed

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

Our overall goal for this quarter was to have the detail view completely implemented and fully functional. We are very close to completing the detail view, but there are still a few things to do. We split up working on this milestone in this manner: Eric and Michael would work on developing the detail view, then show a live demo to Jonathan and Micheal, who would then come up with a list of adjustments/improvements for us to make. This way, Michael and Eric could work in an agile environment where neither person was being hung up waiting to hear back from the design team because we could continue working and add any changes to the do to list as they come in. This milestone has been ongoing for many weeks at this point.

The first thing that you'll notice since the last time you looked at the detail view is that we have adopted the design from our wireframes. The sidebar now reflects the current overall status of that refrigerator. The add button to add a new refrigerator is now functional and appears in the top right just like the design. We also added a navigation tool at the top so that you can go back to the folder view easily. For the UI, we still need to update the system information to reflect the information in the wireframes, and update the graphs and sidebar to reflect the corresponding information as well. We also need to fix the sidebar because when the page enables scrolling to occur it no longer looks like a sidebar (doesn't go to bottom of page yet). As far as implementation goes, all of the features that are present are functional (the graphs work, add button adds a refrigerator, etc.).

Our next step after the detail view is completed is to continue implementing the overview page (aka folder view) so that it matches our wireframe designs, and implement the landing page for when a folder is clicked on but a refrigerator hasn't been selected. I have provided a screenshot of the current state of the detail view page below, and the wireframe of the detail view for comparison purposes.

March 13th - Implement login/logout system

Team members involved: Eric Oltean, Michael Del Fante

One requirement that our refrigerator monitoring dashboard needs to fulfill is to allow the users and administrators to log into the dashboard. Administrators will be able to create new folders and refrigerators, while other users will only be able to monitor the refrigerators. We implemented the login page using Flask Security, which is a Flask extension that adds security mechanisms to our application. Flask Security makes it easy to take care of salt-encrypting the passwords, storing sessions, and redirecting the user if he lands on a page that requires the user to be logged in. Flask integrates well with SQLAlchemy, the Flask database extension, so the username and passwords are stored securely in our SQLite database.

The login/logout page currently includes a brief introduction to Ombitron, but we are going to change it to include a brief introduction to the dashboard itself instead. Users have the option to either log in or register. After registering and/or logging in, the user is redirected to the folder overview page. The screenshot below shows what the login/logout page looks like.

March 6th - Stakesholder Meeting

Team member involved: Jonathan Wai and Micheal Seng

We finally met our client, Paul, to discuss the scenarios and personas for the Dashboard. This process is to ensure we are designing the correct product for Paul. What we originally thought of was not far from the correct personas and scenarios. From this, we made couple of improvements on our dashboard.

Personas

Mark - Manager of ArenaWorld

He is responsible for managing the entire arena, which includes making sure all refrigerators in the arena work perfectly. He usually checks in with his Assistant Managers, who report refrigerator status to him. Occasionally, he also looks into statistical data online to learn about different refrigerator brands, to see if better models are available.

Nancy – Assistant Manager

She is responsible for a few of refrigerators at a specific location within ArenaWorld. Nancy is one of Mark’s assistant managers, so she reports fridge statuses directly to him. She usually only looks at each refrigerator’s temperature dial and reports that, since she isn’t technically trained and cannot report any other information.

Joe – Maintenance

Joe is the the go-to-guy when any refrigerator is broken. Responsible for figuring out problems with refrigerators, he tries to gain insight as to why a fridge isn’t working. He wishes that he could have access to more detailed information, rather than just looking at it once it’s broken. Recently, more fridges are breaking, but it’s impossible to predict which ones.

Scenarios

Scenario 1

Mark is a busy person, but he still need to ensure the entire refrigerators that he is responsible functions correctly. There are many assistant managers work under him, who take care different locations. The number of refrigerators varies depending on the location. Occasionally, he wants to check whether all his assistant managers are working properly and make sure solve problems. Also, it is part of Mark’s job to find out and generate report on which brand of refrigerators are better for different cases or which one saves more energy.

Scenario 2

Nancy is responsible for Century Link’s beer refrigerator that Mark assigned her. Every month, she has to report to Mark regarding all refrigerators problem. Also, she has to make sure when there’s a broken refrigerator, it will be fixed as soon as possible. She usually walks around Century Link to check out all refrigerators and record all the internal and external temperature. Nancy feels that the information she collects is tedious and hope that there is a way to check all refrigerators online.

Scenario 3

Recently, more fridges are breaking and Joe goes around to check on the fridge one by one to figure out what is wrong with them. Not only it's time consuming, there are times when he couldn't understand the problem. He would just assumed the fridges are just old or the change in temperature of the fridge is too drastic. He would be glad if there are ways to constantly record the data, so when the fridge breaks down, he would be able to get a better insight.

March 6 - Setup Back-end In Flask

Team members involved: Michael Del Fante, Eric Oltean

Eric and Michael worked on getting the back end functional. This allowed us to send and process requests. Modifying and accessing the data stored in our database. We initially tested the back end with  a chrome plugin called postman rest client. This allowed us to test the back end before connecting it to our front end. This was a very important step in our project so we could connect our front end to the database and reflect the information stored there. 

Here are some of the tests we ran on the back end from Postman Rest:

March 6 - Front-end Usability Testing

Team Involved: Micheal Seng and Jonathan Wai

Today we did our second round of usability testing during our presentation for class today. We updated our wireframe based off of the feedback we received last time. Below are the updated designs that we came up with!

We simplified our dashboard by having just the three icons, in a case, where a company has a large number of refrigerators. Here, we have display two concepts: only show number of refrigerator under each status, and the other one is fraction over total number of refrigerator.

We change the flow of adding folder or refrigerator

User able to add refrigerator while creating folder

Adding new refrigerator

Detail View

We change the concept, where there are only 2 views instead of 3. Here, as you can see, user still able to quickly run through the entire refrigerators on the folder by going through the list on the left. All the refrigerators that throw some errors will go on top of the list.

When user clicked on folder, this is the landing page where user able to see summary and have click on link to the right fridge.

Looking at the detail on a specific refrigerator

Overall, the feedback we received was more positive than last time. People seemed to like the changes we made. The following describes the noteworthy feedback we did receive:

Top level view
First, we asked the class whether they preferred the total to be shown once or under each refrigerator status (as seen in the first screenshot). The class voted and 8 preferred the total being shown once, while 7 preferred the total to be underneath each overall status. There doesn't seem to be a clear favorite.

We also received this feedback:

1. A pie chart might be a better way to visualize how many refrigerators have a green, yellow, or red status.
2. Does the notification system notify you about activity changing on the top level and/or detail view?
3. What about colorblindness? The user would have no way of differentiating.
4. Screen size could be an issue
5. Are icons necessary? Maybe different icons for each status type.

Add folder window

1. Add button isn't easy to locate.
2. User should be able to add a refrigerator by clicking on the add button or by adding it directly to a specific folder
3. Folder isn't a descriptive term. Change to add group or add location.

Detail view

1. Some people thought the icons in the right column (summarizing the detail view) could be clickable when they're not
2. Left & right columns could be better integrated (a lot of space between)

Our next steps for the design team is to work on addressing the feedback we received, brainstorm solutions, and update the wireframes accordingly.

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