-
Notifications
You must be signed in to change notification settings - Fork 1
Home
The SDZWA Sensor Dashboard frontend was built by employing React-Bootstrap components and custom components and ran through a Next.js server. The frontend is connected to the backend using REST API calls such as POST and GET.
Overall system architecture resembles that of the diagram above. The front-end portion of this project involves the React (Web)App along with connecting to the back end using API calls for retrieving and updating user and sensor data.
Primary design choices for the React app are as follows:
-
Modularity
-
Customizability
-
Flexibility
We wanted our application to follow the design principle of modularity to aid in the implementation along with extensibility in the future. All of the pages in this repo can be thought of as separate system components, that can easily be extended or modified without impact on the remaining pages. The only dependency that exists between pages involves logging in to have a valid authentication token and connecting a sensor tile in the dashboard to a corresponding individual sensor page. The primary component of our react app, the dashboard tile page, easily allows for more components to be added as an extension or deletion of components (via the individual sensor page).
As for customizability, our application has been designed in a generalized manner, which allows for customization for current and future developers. We knew that there may be new sensors or connectors in the future, and did not want the overall system design to interfere with these future operations. All API calls are generalized to support a sensor data type, which with the assistance of the back-end team can be modified if need be. From the sensor data type, the react app can then render a different component based on the need.
Flexibility is the last of our primary design principles followed. Our web application has made use of CSS styling in a manner that supports an easy and responsive user experience, regardless of the platform. For this, we considered viewpoints of all types of devices, from handheld smartphones to full-screen desktops -- regardless the user experience will be seamless.
##Future Work Due to time constraints of the quarter, this is not a completely finished project, and there remains work to be done. Currently, our dashboard is utilizing data from sample data along with capabilities for an audio-player and video-player using different react player libraries.
From the front-end perspective, there remains work to be done with regard to adding more types of visualizations. We are currently using the visx library for our sample data, but there is room to add any other type of data visualization to this project. We simply import these visualizations as a component and place these in the dashboard, so adding new ones would be as simple as adding a new component.
There also remains work that was planned out for implementing a sensor health graph that would be placed on the individual sensor page. This graph may be implemented as a bar chart, with an hourly/daily/weekly report on whether the sensor is communicating/partially communicating/not communicating. To implement this chart, you would have to pull a bar chart from the visx or another library and transfer data from the back end into that chart. Currently, there is no backend support for this data, but that may be added very easily.
There will always be work to be done from a design and user experience perspective, but there are currently no plans for any changes in these regards.