Data-Visualisation tool for FDM
As part of an 8 man team, I was tasked with creating a web-based data visualisation solution for the IT services provider FDM. The requirements given to the group were: the data used within the tool had to be anonymized, the tool must be optimised for mobile and tablet, and the deliverable must generate reports that would help FDM make better business decisions in future.The project brief was supported by a discussion by two employees of FDM, who helped to clarify what their individual preferences would be for the final product. The project was broken down into its various elements, and each member was given a portion to complete individually. As we were a multidisciplinary team, we aimed to play off of each members strengths. We had multiple members who had experience with web development, so we decided that creating a web API would be best. Also, creating a website would allow us to easily optimise the tool to work on mobile and tablet.
My roles for the project are as follows:
-Interface Designer
-Prototype Designer
-Programmer
-Tester
Interface Designer
At the beginning of the project, after the breakdown of roles within the group, the lead programmer and I discussed what we thought would be best for the layout and design of the website, as well as the features we think should be included. We came to the conclusion that there would need to be a page for the visualisation tool itself, a help page so the user could learn how to use the tool if they were not able to do so intuitively, and a welcome page. In order to keep in line with the FDM house style, I used the FDM website as references. The main points of focus are; the black header and footer, block colour pattern, FDM logo, and bold fonts. The initial interface and structure sketches are shown below.
For the visualisations, the planned process was that the user would select the attributes they wished to visualise and the type of chart, and then the chart would be generated. The charts would pull data from the database created by the database designers, and would display the charts next to the data selection form. I consulted the rest of the team members about the proposed design, to ensure that everyone was happy with the direction we were taking. The team expressed that they liked the design and that they were happy to continue with the layout design. I then went on to create a digital prototype of the website.
Prototype Designer
After the design of the website had been established, I went on to create an interactive digital prototype using the UX design and wire framing tool UXpin (www.uxpin.com). The prototype is shown below. The prototype enabled us to fully understand the architecture of the system before we started implementing it, and prevent rework later on in development. During a meeting with two employees of FDM, they expressed that they liked the look of the prototype, and the planned functionality for the visualisations. One suggestion they gave was that the FDM ‘three coloured dots’ should be included. This was noted, and was incorporated into the final product.
From the prototype, we then moved forward to create the actual website. For the programming of the website, we used the online IDE c9 (c9.io). We chose to use this as all of the members of our team had experience with using, and the IDE allows for collaborative working, meaning that all member of the team could view the code at any time, and make alterations as they see fit. There is also a feature to look back at the revision history of each file, allowing us to see when and where the file was altered, and if necessary, we could revert back to the previous version.
Programmer
Using Chartist.js, a library for chart creation in JavaScript, I created some sample charts that could be used for the visualisations. I selected to use this library over others, because it was easy to integrate animation into the charts; something I felt that would make the visualisation more aesthetically pleasing for the user. I created three charts; bar chart, line chart, and a pie chart. The charts created did not pull from the actual database created for our final website, so only included manually inputted data.
Line chart
The line chart was the first one created, and is shown below. I initially had difficulty in getting the animation to work with the chart, which led to it not being created at all. After looking at online guides and forums, I eventually managed to get the animation working. The animation for this chart is each layer appearing one by one, giving a ‘fade in’ effect. After the animation is completed, the chart remains static, giving the user time to read the information.
Pie Chart
The pie chart was the second chart I created, and is shown below. The problem I encountered when creating the pie chart was trying to adjust the animation for the labels. The animation for the pie chart is that each segment is loaded one by one, until the entire chart is created. However, the labels are static; I was unable to get them to work in with the animation. By setting the background to white, it appears as if the labels are appearing with the associated segment. If the background was a different colour however, it would expose the labels, as shown below.
Bar Chart
The final chart created was the bar chart, shown below The bar chart was the simplest chart to create, as the animation was simple; the bars simply stretch and return to their original size. The bar chart I created allows for comparison of two different values. Given extra time on the implementation, I would have liked to have made the addition of a key, which would allow the user to differentiate between the two bars.
Although the charts I created were aesthetically suitable for the website, there were problems with connecting it to the SQL database the database designers had created. It was for this reason that we decided as a group to use another charting library called CanvasJS (canvasjs.com), which is a charting library that allows for creation of responsive charts, written in JavaScript. The lead programmer created the new charts, and connected them to our database.
Tester
During the development of the website, I created a test plan for each element of functionality on the website. Once that feature was completed, I carried out the test previously defined in the test plan. The results were then put into a table. If the test was passed, then no alterations were made. If the test failed, then the code was examined to find out what the error was. To test, I used the idea of black box testing; where the functionality of the software is tested, as opposed to checking the validity of the code (white box testing). A sample test from the test plan is shown in the tables below.
Overall, I feel that we worked successfully as a team in order to create our final product. Each member’s strengths and abilities were considered when the workload was distributed. As the team consists of members from different courses, the tasks allocated to them utilised their skillsets, to ensure that every member was comfortable with their tasks, and that they would be able to manage their workload better. The team worked very well together, and each member did well with their individual components.