Open Energy Dashboard

_____________________________________________

Authors:

Fernando Arozqueta, Jerridan Bonbright,

Andrew Bundy, Delaney Nikoofekr, Austin Stewart,

Katherine Vickstrom, Thomas Wooten

______________________________________________

California State University of Monterey Bay

CST 499 - Computer Science Capstone

Summer B 2022

______________________________________________

Client: Steven Huss-Lederman

Faculty Advisor: Bude Su

 2

Executive Summary

The purpose of this project is to provide an open-source, browser-based energy dashboard

for monitoring various types of metering devices. The Open Energy Dashboard (OED) provides

a tool for users of any skill level to access and display current and historical data from their

metering system or related equipment. A primary goal of the project is to produce a dashboard

that is simple to use, reduces implementation complexities, and lowers the overall cost of

operating and maintaining a metering system. OED aims to accomplish its goals by

implementing a simple and intuitive dashboard that interfaces effortlessly with equipment and is

easily configurable, yet remains portable and implementable across many organizations. OED

was designed with reliable open-source software that is constantly maintained, ensuring the

dashboard will have a long life and be competitive with the latest technologies.

We live in a time where reducing energy usage, no matter the amount, is more important

than ever. Having an easy and cost-free way to monitor energy usage data encourages more

organizations to take advantage of it and reduce their energy outputs. Be it environmentalist

efforts or businesses looking to raise their bottom line by cutting costs, the end result is a lower

carbon footprint. While it is likely that organizations with large utility costs will comprise the

majority of interest in this project, anyone can take advantage of the project’s functionality.

OED, with its low cost and easy implementation, has the potential to benefit not only large

swaths of society, but the planet as a whole. Being more aware of one’s energy usage allows

businesses, communities, and individuals to be more environmentally responsible and contribute

to the global need to reduce our collective carbon footprint.

 3

Table of Contents

Page

Introduction......................................................................................................................................4

Product Description.............................................................................................................4

End Users.............................................................................................................................4

Feasibility Discussion......................................................................................................................5

Ethical Concerns..................................................................................................................5

Legal Concerns....................................................................................................................6

Product Life Span................................................................................................................6

Platform...........................................................................................................................................8

Major Functions..............................................................................................................................8

Units....................................................................................................................................9

Usability Test Plan.........................................................................................................................11

Usability Testing/Evaluation..........................................................................................................12

Timeline/Budget….........................................................................................................................13

Final Implementation.....................................................................................................................16

Discussion......................................................................................................................................18

References......................................................................................................................................21

Appendix A....................................................................................................................................22

Appendix B....................................................................................................................................28

Appendix C....................................................................................................................................31
 4

Part I

Introduction

I. Product Description

Open Energy Dashboard (OED) is a web-based application that allows users to create,

link, and monitor their energy consumption. Currently, those who wish to use such a system have

to pay a company that then creates an application for them—such as Wattics, Datapine, and

Automated Logic. While this approach gives the consumer what they want, affordability, ease of

access, and modifiability are sacrificed to achieve this. OED aims to resolve these issues.

As utility costs rise and become more of a financial burden on businesses and

communities, access to information about how we use our resources becomes increasingly

important to consumers. The ability to understand, visualize, and evaluate how and when we use

resources is crucial. Monitoring resource usage is important not only for saving money, but for

preserving the limited resources we have available. With OED, any organization that monitors

energy usage can have a reliable means of displaying and manipulating this data in order to cut

down on cost and optimize resource utilization. Crucially, OED will be available in multiple

languages and metric systems, greatly increasing its reach to organizations and communities

around the world, rather than limiting its use to English-speaking regions. Open Energy

Dashboard is an open-source project that will continue to evolve as more contributors join the

cause.

II. End Users

OED is an application that can be used by anyone who wants to monitor their energy

consumption. This is achieved by having each user connect to the application through a web
 5

browser. This makes any device capable of connecting to the internet a valuable tool for

consumers. Furthermore, this application provides numerous metrics for monitoring various

types of consumption as well.

Feasibility Discussion

Although OED is the first of its kind to be free to use, it is not the first energy monitoring

dashboard. There are several companies offering paid services and products that allow their users

to monitor their energy usage. These companies may perform better at certain tasks than OED.

One such task is tailoring the application to customers’ needs and standards. However, while

these companies excel in one area, they lack in others—for example, their status as paid

applications and subscriptions rather than a free resource. Our project aims to outperform paid

resources through addressing the affordability, portability, and modifiability of our product.

I. Ethical Concerns

Not only are these three topics the main concern for consumers, but they are what OED

was founded on. Currently, other companies offering energy dashboards require their customers

to pay a large fee for their services. OED remedies this dilemma by being an open-source

project. This means our dashboard is free to use, offering savings to our users who would

otherwise be forced to pay for this service.

Another issue with current paid energy dashboards is their poor performance with regards

to portability. Typically, these companies create a downloadable application of the dashboard, for

either a custom-made system or for a desktop computer. This is problematic for those without

access to specialized systems or a desktop, as smart devices are replacing desktops as users’
 6

preferred way to access the internet and applications. OED fixes this issue by being a web

browser-based application. This means the only thing a consumer needs is a device capable of

connecting to the internet which all smartphones can already do.

Finally, companies that provide energy dashboards rarely provide updates to the

applications they create. Everything is built to suit the needs of their customers then and there,

rather than focus on users’ changing needs and requirements. Any such updates usually require

customers to pay more for a service they’ve already purchased. This is not the case with OED.

Since it is web based and open source, updates can easily be applied to our users' dashboard

without the need for additional fees to implement those updates. OED tackles the issues with

other energy dashboards and provides consumers with a free, easy-to-use product.

II. Legal Concerns

As an open-source project, the OED team is minimally concerned with potential legal

issues. One precaution this project uses is the OED’s Contributor’s License Agreement (CLA),

which states that the product will remain free to use, and that contributors are not expected to be

paid, nor expected to provide support, for their work. However, if they decide to provide support,

they do so either for free or for a fee if they so choose. OED is also operating under the Mozilla

Public License 2.0, which gives it permissions for commercial, private, and patent use, as well as

enabling distribution of the project.

III. Product Life Span

As both an open-sourced project and a web-based application, OED’s room to grow is

boundless. There is no expected end date for this product—it plans to update accordingly to
 7

accommodate changes to energy-monitoring information and technologies. In the near future,

there are many planned changes in the pipeline, some of which are requests from the community.

One such change is updating the energy-consumption graph to make it less linear in its display in

order to more accurately show consumption rates.

The Open Energy Dashboard has a bright future ahead as an application made by the

community for the community.

 8

Part II

Platform

Every project has its own coding environment/platform that its developers work on, and

in some cases there could be multiple platforms. OED chose to exclusively use Visual Studio

Code (VSC).

VSC proved an optimal choice for the OED team, as it offers a variety of features that

allow it to implement multiple functions in a single platform. One important feature is the

implementation of Docker, which allows the construction of containers to run the application in a

web browser, such as Chrome or Firefox, for the purposes of testing and debugging. VSC also

features GitHub integration. By implementing this, developers are able to view all currently open

pull requests that exist within the GitHub repository and the current status and progress of those

requests. It also tracks changes between versions by highlighting lines of code that were either

changed, added, or deleted. Lastly, VSC has a built-in feature that allows developers to search

across all project files for a given string. This allows developers to quickly locate code, which

streamlines the development process.

Although VSC offers additional features, those listed above have been the most beneficial

to the OED team. VSC has proven an effective platform for our work and will continue to be so

as the project progresses.

Major Functions

Because OED already existed prior to our team’s involvement in the project, we had no

hand in dictating its original design. OED has a wide array of functionality spanning many

different use cases, although its primary function is the tracking and graphing of data pertaining
 9

to energy usage and converting it into a human-readable format. Our main goal as a team is to

design a template for displaying data from key database tables and to allow for create, read, and

update—though not delete—functionality on those tables. From this template, our goal is to

create two additional pages with similar design and functionality. One page is for Units,

demonstrated below. The other is for Conversions, which is still in the development stage and

not yet ready for demonstration.

I. Units

Main Page:

Figure 1
Units Page

Note: This is a screenshot of the units page we created in OED.

Each line, including the title, represents a mutable database column that can be edited by

administrators. We have strived to use modal elements as a tool for ease-of-use in our page
 10

design. Here, they are used to clearly separate database rows and are also used as pop-ups for the

create and edit buttons.

Figure 2
Unit Create/Edit Modals:

Note: These are the modals we created to edit and create units on the units page.

Our goal was to create and utilize consistent design and functionality of the pop-up

modals. Modals are treated as pop-ups so as to make them stand out so it is clear to the user what

process they are implementing.

All database data lives in the Redux store as a cache that wraps the entire application.

Each page subscribes to the piece of the store that it wishes to track. In this example we are
 11

tracking the Units data state. Successful updates to units, or creation of new ones, will

immediately update the store and trigger a re-render, yielding a dynamic, yet quick, web page.

We ensure this store remains consistent with our database data and that it is properly updated on

successful backend calls so what the user sees is an accurate representation of the database.

Usability Test Plan

Open Energy Dashboard is in a unique position when it comes to testing the usability of

the service. Being open source means that any contributor, with access to GitHub, is able to help

test the product. As a result, there is no need for focus groups or test subjects in this matter. The

features we are working on will be tested primarily within our group. The company lead and

other individuals will also perform tests as well, once changes are committed to the appropriate

GitHub branch.

Our testing process will primarily consist of developers using the product as is. This

process will have them implement and test changes manually. This approach helps with

identifying and fixing most of the smaller issues that appear after large changes are made to the

code. This typically happens when a merge occurs from the development branch to the live

service branch.

Another testing method, which is more standardized, is the use of test data. This is

implemented by having developers run scripts through the command line. These scripts are

located within a “package.json” file and cover various areas within the application. For example,

there are scripts which inject unit conversion and special meter data into the testing environment

for the application. This allows for quick and easy automated testing and ensures that every new

feature runs without a hitch.

 12

Usability Testing/Evaluation

OED is unique in that all testing is done through the developer’s coding environment

instead of with focus groups or application users—although all user feedback is recorded for

future development and testing. The process of evaluating and testing the application is a

straightforward procedure.

First, a developer will need to have their coding environment set up appropriately. This is

done by cloning the repository to be tested and ensuring that the correct branch is active. All of

this is done through VSC, with the use of additional extensions for remote development, Docker,

and GitHub.

Second, the testing data will need to be loaded. With the help of the Docker extension,

this step is simple. All one needs to do is attach a shell to the appropriate container and it will

then open up a command line terminal. From there, a developer is able to populate the

application with test data. This process can be done either manually or automatically. To do this,

one simply needs to pick a test script from the “package.json” file and enter in the command line

“npm run” followed by the name of that script.

Once the testing data has been inserted, the only remaining step is to run the application.

In order to do that, a developer needs to open up a browser of their choosing. Next, they will

enter “localhost:3000” into the URL. This will open up the application on its home page, with

the test data populating the dashboard. Once this has been done, the tester is able to test and

evaluate the application at their leisure.

 13

Part III

Timeline/Budget

Timeline

In the preliminary stage of the project, we established numerous milestones and a

timeline that we could follow to reach them. Major milestones included reviewing the code in

OED, setting up our coding environment, documenting code, and key development tasks.

However, we utilized many smaller milestones to help break up the larger ones. We managed to

accomplish an overwhelming majority of these milestones, but due to some unforeseen setbacks

we were unable to meet every one.

Our first major accomplishment was updating and finalizing the units page in OED,

which had not been completed by the previous team. This consisted of updating the use of React

and Redux to the newer usage, fixing an array of leftover bugs, adding missing functionality,

cleaning up the visuals, and streamlining existing code. The completion of the units page fell

outside our initial timeline estimate, but proved itself to be a useful template that greatly

expedited the development of the conversion and meters pages. Furthermore, it allowed us to

complete the optional milestone of updating the select dropdown menus and adding a new one

for rate of time for graphing on the main page.

The next major milestone was the refactoring/rebuilding of the meters page.

Unfortunately the meters page was not completed and is still in production. There were many

unforeseen issues with communication between the frontend and the database, as well as new

additional functionalities requested by our client as we continued to develop the page. Also, the

page’s development started later than desired, which played a part in its lack of completion.

Much time was lost due to various bugs and errors when implementing key features into the
 14

page—for example, the GPS component.

Our last major milestone was the refactoring/rebuilding of the conversion page. Although

development of the conversions page, like the meters page, started later than planned, its

development progressed faster and more smoothly than the meters page and was completed in

time. Not only were we able to complete the originally requested page, but our team managed to

ship both the originally requested page and the additional features requested by the client during

development.

As discussed earlier, we were unable to complete every milestone our team laid out.

These consisted largely of smaller items such as documentation and code reviews. In addition,

we were unable to complete work on the meters page due to the development process getting

slowed by bugs. Although these milestones do not impact the features provided by OED, they

are vital to the longevity of the application.

Overall, the majority of milestones, including those added during the work on the project,

were successfully completed. The units page and dropdown select changes were merged into the

resource generalization branch, which will remain in development until the resource

generalization issues are complete, and the conversions page is currently situated in a pull

request ready to merge into the resource generalization branch pending review. The remaining

small changes required to push the meters page are planned to be completed by our successors.

Our contributions to the project will be merged into the development, and eventually main,

branch. The project is still on track for a 1.0 release in the second half of 2022.
 15

Figure 3
Expected Timeline/Milestone:

Note: This was our expected timeline, but due to certain circumstances, we were unable
to achieve all of it.

Budget

This project had no budget, it’s a free and open source software which is maintained by

volunteers and students who take no compensation for the work. The code is hosted for free on

GitHub; end users can install the software on their own computer so the project doesn’t need to

be deployed and hosted anywhere. We did not run into any budget issues since all the technology
 16

we used is free and the labor was volunteer work.

Final Implementation

After two months of working on OED, the final product’s looks and functions have been

significantly improved from the original code. The units, meters, and conversions pages now use

modals, which are edited individually, rather than the original grid format that had to

simultaneously handle changes for every datapoint—including unedited ones—increasing

efficiency. Units and meters can now be edited, and new ones added. Conversions can be added,

edited, and also deleted. Whenever changes are made, the page reflects these changes without

requiring a refresh. These features are the result of proper communication between our Postgres

database, route APIs, and React/Redux.

React allowed us to create functional components that managed their own state in order

to implement more complex user interfaces. State is an important concept in React and routing

and managing state can get very complicated as the size of the application scales upwards. Redux

helped us handle these complexities by allowing the entire state of the application to exist in a

centralized place that wraps the application itself. This made accessing and altering any state

from any component simple, the code more legible, and sped up the development process.
 17

Figure 4
Redux example:

Note: Example of Redux reducer and actions for our unit component.

With units and meters completed, we were then able to work on the graphing element on

the home page. There are dropdown menus to select different items which impact the graph:

Graph Type, Groups, Meters, Units, and Rate. The graph type is simple, the user selects the type

of graph they want, such as a line or bar graph. Meters and groups cannot be graphed without a

unit so meters and groups have a default unit associated with them that auto populates the unit

dropdown when selected. However, they are free to select another unit in the dropdown if

desired, so long as that unit is compatible. As an example, it is possible to graph how much

money (a unit) they are spending on electricity (a meter) over a period of time. The rate

dropdown allows users to measure this by seconds, hours, days, etc. Groups can be created in the
 18

groups page. An example group could be one that combines the electricity and natural gas

meters. Back on the home page, a user can select this group and simultaneously graph how much

money is being spent on both of these two meter types.

Discussion

Throughout the two months of project development, our team encountered numerous

issues. The first major challenge was learning and implementing a React/Redux framework,

which our client wanted to use for OED. Our team implemented Redux with hooks in various

parts of the application—such as units, meters, and conversions—while refactoring its UI. The

client described this as a major change to OED that would consist of many changes to the

development branch of OED’s repository. Our team was able to deliver the majority of the

requested changes to the client’s satisfaction.

Two related challenges that persisted throughout the development process were the

longevity of the original code and the amount of non-functioning or incomplete code left within

the previous team’s branches of OED repositories. At the beginning of our team’s involvement, a

majority of our time was devoted to understanding how OED worked, which was made difficult

by earlier teams’ incomplete and bug-filled code. For some of our team, the original code

hindered their ability to consistently set up the development environment. While we resolved a

portion of the development environment issues, constant adjustments had to be made due to

hard-to-find bugs and general inefficiency when testing changes. These challenges became

increasingly obvious when our team tried to collaborate and coordinate changes using tools like

Git.

OED presented a number of software engineering and development challenges to the

 19

CSUMB capstone team. Overcoming those challenges was possible due to each team member's

ability to coordinate, communicate, adapt to changing environments, and respecting each other's

team member's approach and abilities.

While our team completed the majority of the client’s goals, the overall application is not

yet ready for end users. However, the client was pleased with our progress and the Open Energy

Dashboard 1.0 is scheduled to be released by the end of 2022, on target for the client’s

expectations.

Throughout the project, our team gained valuable experience and insights into the

development of a web application. Our understanding was helped by working from previous

code, rather than creating the app from the ground up, and also through the efforts and assistance

of our client. Each team member was assigned several tasks and performed many duties

throughout the project. This allowed each of us to experience different aspects of app

development, which was far more beneficial than if we had been assigned static roles from

beginning to end. We are all proud of the work we accomplished and look forward to OED’s

release in the near future.

When OED is released sometime this year, we foresee it having major benefits to society,

especially as more users join over time. While we do not expect overnight success or even

necessarily a fast uptake, the ability of users to view their energy usage using a menagerie of

measurements, time-scales, and conversions will allow them to gain more awareness of their

energy footprint. In doing so, OED hopes its users will decide to take steps to decrease their

consumption.

OED will always be free to use, which will likely increase its user base, and thus its

societal impact. That it is also a browser application will make it more accessible, especially for
 20

those with less technological access. Ultimately, OED will not only help users save money, but

help decrease their ecological impact.

Our team is proud to have done our part helping others—and the planet.
 21

References

An introduction to Wattics & popular features. (n.d.) Wattics.

https://www.wattics.com/dashboard/

Dashboards. (n.d.) eSight Energy. https://www.esightenergy.com/dashboards/

Energy Dashboard. (n.d.) Dribbble. https://dribbble.com/tags/energy_dashboard

Energy Dashboard Examples. (n.d.) Datapine.

https://www.datapine.com/dashboard-examples-and-templates/energy

Energy Dashboards. (n.d.) Automated Logic.

https://www.automatedlogic.com/en/products/energy-reports-platform/energy-dashboards

Morgan, J. (2020, October 20). How To Manage State in React with Redux. DigitalOcean.

https://www.digitalocean.com/community/tutorials/how-to-manage-state-in-react-with-re

dux

Open Energy Dashboard. (n.d.) Open Energy Dashboard. https://openenergydashboard.github.io

 22

Appendix A

Usability & Evaluation Test Plan

Introduction:

1. What is your target audience? (age, occupation, interests, comfort level with

technology, etc.)

a. The targeted audience for those using Open Energy Dashboard (OED) are those

who have a familiarity with the tools of the trade. For example, understanding

what metrics/units to track a specific type of energy-related consumption. Also,

the application and user interface is made for easy usage, allowing for non-highly

skilled personnel to take advantage of the services it provides.

2. Who will be testing your project? If you have a focus group, please state

everyone's names (first names okay) and describe how they fit your target

audience demographics. Otherwise, just do this part for your client.

a. The pilot for testing the application will be our client, whom we have worked

with since the beginning of this project.

3. What are the main tasks you would like your client/group to be able to complete

while testing? Your tasks should be specific and measurable (i.e. Can they sign

up and log in? Can they navigate to one specific part of the site? Are they able to

play through the first level of the game?). To get good feedback, you should have

3-5 tasks to test them on.

a. Listed below are the tasks our client will be testing:

 23

i. The user is able to create a new unit and have the page automatically

update after saving.

ii. The user is able to update an existing unit and have the page automatically

update after saving the changes.

iii. The user is able to graph a group or meter without selecting a unit (the

default unit will auto-populate).

iv. The user is able to see incompatible dropdown items properly get disabled

when selecting a group, meter, or unit.

v. Groups/meters/units items in dropdowns are properly displayed based on

the type of user logged in (or not logged in).

vi. The user can switch between units when graphing without deselecting the

unit, provided the unit being switched to is compatible with the currently

selected graphs/meters.

4. Observe and take notes while your tester tries out your product. Testing is best

done face-to-face. It also helps if your testers speak out loud so you can hear

their thought process as they attempt your tasks. That way, if they get stuck or

aren't able to complete a task, you have an idea of why and it will be easier for

you to fix.

a. Notes based on the tests our client ran above:

i. The client was able to successfully create a new unit and the page

automatically updated alphabetically after saving it.

1. Side note: All input fields worked correctly along with those that

allowed for the expansion of an input box.

 24

ii. The client was able to successfully edit an existing unit card and all of the

input fields within it.

1. Side note: If the name of the unit card was changed, the page

would be automatically updated alphabetically after saving it.

Also, the resizing/expansion of an input box worked correctly as

well.

iii. The client was able to successfully create/generate a graph by only

selecting either a meter or a group.

1. Side note: Previously, this feature did not exist and the user had to

manually input the unit, which the meter and group needed to be

based on.

iv. When viewing either group, meter, or unit, the client is able to

differentiate between valid inputs and invalid inputs.

1. Side note: All valid inputs appear as normal black text entries that

can be selected. On the other hand, invalid inputs are grayed out

and cannot be selected.

v. Based on what type of user is logged in, either normal or admin, they are

able to view group, meter, and unit items that are available to them.

1. Side note: The admin is able to view exclusive group, meter, and

unit items. This is primarily for testing purposes. Those exclusive

options will become available after further testing is done.

vi. The client is able to successfully switch between other valid unit types

based on the meter or group that has been selected. The graph is also
 25

automatically updated to display the correct information without having to

refresh the page.

1. Side note: The client is also able to reset the group, meter, unit, and

graph by deselecting the unit to be graphed on.

For client-based testing:

1. Set up a meeting with your client to go over your work. This should ideally be

face-to-face so you can get their initial reactions and see how they navigate your

product in real time. If they test on your device, you may also be able to record

your screen and audio to capture their test to review later (with their

permission). Other good alternatives would be to have them share their screens

over Hangouts, Zoom, etc. while testing or have them record themselves using

the product and narrating what they're doing.

a. The testing will be held over a Zoom call on Sunday, July 24th, 2022. Our client

will be running and reviewing the product on their own device.

2. Share your tasks with the client. Encourage them to share their thought process

aloud so you have an idea of how your project will be used. If they get stuck,

resist the urge to give them help or hints. Encourage them to find the solution

on their own, and if they can't, remind them that your project is still a work in

progress, it's not their fault that they are not able to complete the task, and then

move on to the next one.

a. Prior to the meeting day for testing, we sent a message to our client detailing our

situation, along with the list of our test cases. This was to help familiarize

themselves with what is to happen on the day of the meeting. Also, by sending
 26

that message we have received feedback about certain test cases and have altered

them as a result. This made the testing process easier for the client.

3. Report on their feedback. Were they able to complete all of the tasks? Did they

get stuck along the way? What will you do to improve your project in the short

term before the festival? In the long term?

a. Based on the feedback from our client, every test case ran successfully.

i. There were certain areas in the project that the client got stuck on for a

brief moment.

1. The first instance was when the client resized the unit page

containing all of the unit cards. Some of the unit cards weren’t

being displayed on smaller screens, or were sometimes cut off.

2. The second instance was when the client was trying to find specific

entries either within the meter or group section of the graph. This

was just a matter of navigation rather than an error with the code.

ii. Unfortunately, for the issues that the client came across, they don’t fall

within our jurisdiction as a team. However, this will not stop us from

improving other smaller issues within our sections of the code. Some of

these sections include text sizing, color of borders, appropriate drop-down

menus of certain inputs, and much more.

iii. As for the long term, there isn’t much to improve upon. One improvement

would be ensuring all pages like Unit, Meter, and Conversion all follow

the same coding conventions. Another improvement would be adding

 27

appropriate comments to code along with comments to pull requests on

Github.
 28

Appendix B

Team Member Roles and Responsibilities

Many tasks in this project were assigned to teams of two to three team members. These

teams changed throughout the project as progress was made in certain areas. Some portions of

the project were worked on by all members, while other, smaller tasks were assigned to an

individual who could implement a solution quickly. This non-concrete division of labor allowed

the allocation of resources to remain flexible, as the team could reconfigure in order to give more

attention to areas that needed it.

Major functionality was broken up into several groups: Units, Meters, and Conversions.

Once smaller tasks throughout the project had been completed to the client’s satisfaction, teams

were divided up into these groups to continue work.

Details on each team member’s contributions are outlined below:

Fernando Arozqueta: Performed minor change to the “sec in rate” input field in create

unit page. Performed code reviews and project testing. Assisted with the preparation of

the Capstone Report.

Jerridan Bonbright: Implementation of database update for conversion array,

troubleshooting of state handling for GPS, minor GUI changes.

Andrew Bundy: Team lead for Conversions page. Added and implemented most

conversions functionality: conversions state, conversions page, conversions UI,

 29

conversion routes, conversion API, creating/editing conversions, displaying conversions,

conversion database table interactions, and conversions translations. Also performed

general troubleshooting, code review, QA, project testing, and bug hunting/fixing.

Delaney Nikoofekr: Refactoring, update, bug fixing, feature addition, finalization of

units page. Bug fixing, update, feature addition of select dropdowns. Adding of rates

menu for graphing. Bug fixing, feature addition, finalization of conversions page. Bug

fixing, feature addition of meters page. Refactoring and bug fixing of various key parts of

application. Creation and management of all pull requests.

Austin Stewart: Reviewed and tested code to find bugs. Added pop-up help text for

creating and editing units within the unit page. Coordinated with the capstone advisor and

company lead to organize our group along with upcoming capstone tasks. Kept the team

on track and up to date with various capstone assignments. Worked with the client to help

improve the installation process of the coding environment for Windows users.

Katherine Vickstrom: Edited unit components to reduce the redundant code by creating

functions to handle certain types (eg. string, boolean, integer) instead of a function for

each input field. Implemented the meters pages incorporating the same changes from unit

components in meter components, which had an extra layer of difficulty to deal with GPS

and time zone types, as well as other special circumstances. Created the route to add a

meter for the meter API. Added translations for messages to properly translate on the

page. Debugging and troubleshooting the changes in units and meters.

 30

Thomas Wooten:

Unit components styling resolved following issues for template implementation:

1. The modal pages have the items only span a limited amount of the width of the

popup and punch list items.

2. src/client/app/components/unit/UnitModalEditComponent.tsx edit page should

have the name of the unit at top and can be edited.

3. The edit page does not have a resizable note as is done on the create page

4. The preferred display is true/false on the overview card but yes/no on the

create/edit modal. I think we should just use true/false since this is an admin page.

5. One of the other new modal pages (conversion?) color codes the true/false with

green/red. I think we should do that here.

Created pull request for meter modal work, Implemented the meters pages incorporating the

same changes from unit components in meter components, which had an extra layer of difficulty

to deal with—GPS and time zone types, as well as other special circumstances. Reviewed and

tested code to find bugs.

 31

Appendix C

Schematics & Drawings

Figure 1. Units Page

 32

Figure 2. Unit Create/Edit Modals

 33

Figure 3. Expected Timeline/Milestone

 34

Figure 4. Redux example