Crescendo
Problem
Our Solution
Crescendo
Analysis
We have focused our time and efforts into breaking down the components and simplifying data, making it readable and understandable on both stand-alone pages and as a part of an overview element. Our analysis showed that users do not like it when all things are too plain nor too eye-catching. In both cases, it is uncertain which thing is more important than the other.
During our analysis, a new problem surfaced. We wanted to plan for possible new features and create guidelines for the new element to follow the set structure and assure the ease of development. However, we've already had a couple of projects where we had to tackle similar issues. Essentially, we had to go back to the basics, define the essentials and then start building each element to create and maintain the standard of the project.
Intervention
As a solution to the data separation issue, we created pages with relevant data and used boxed elements. Encapsulating each element allowed us to show only relevant data for a specific data point. This helped improve readability and set a good base for user experience improvement. Once we had the elements defined we started using colors to stress the importance of presented information. With this, we achieved an interesting effect. Despite the simple look, complex data is easily readable.
To build a good basis for later improvements, we created standardized elements used as wrappers for each block. That way, in the future, each segment can follow the same principles and easily fit into the design.
Even though most of the code had to be restructured, it was well worth it as the overall performance of the application has improved. We managed to reduce the number of requests, shorten code execution and boost performance on the end-user’s side.
We did it RESPONSIVE!
Though it’s not a standard practice to use dashboard or management tools on portable devices, we have made it possible for this project! As we are relying on the basic needs of the client-side, the number of problems that might happen is almost zero. The responsive is possible because the complete front side of the application is built with a code that does not require any special libraries or extensions. Even though it was more work, the gain was far greater. With this solution, we made sure that users can use the product anywhere and anytime on the device of their choice.
Technologies
Taking on the project, we had to work with the not-so-well documented legacy code that had too many things that should've been removed a long time ago. As the whole communication with the API Engine was already done in the project, we decided to stick with the C# as back-end language and make the necessary improvements and code restructuring. For the front-end code, we had a different approach. We removed all of the existing elements and extensions, and start the development from scratch.
A great programming language that provided us with much-needed flexibility and a powerful rendering engine that we needed for this project. It is a robust tool that we required to handle all of the data calculations on this project.
To give dynamic to the page, and move away from a block of text, we used JavaScript and jQuery library to make DOM traversing easier. The only additional extension is amCharts plugin, used for graphical data presentation. This gave us the flexibility and optimized performance.
All HTML code is verified and valid by HTML5 standards. To shorten the development time, we used Bootstrap 4 as framework and packed up all of HTML on the server using C# Razor for data insertions. This way, once a request is made, all of the content is batched at once.
To reduce server requests and make things easier to manage in the future, all of the styles are written in SCSS and compiled to a single CSS file. The styles used are following CSS3 standard and support CSS2 standard - which makes the product accessible on older browsers as well.