work term report
TRANSCRIPT
Report on the Remodeling of The CIS Product Dashboard
by Merek Orlowski
January 16, 2017
Table of Contents
Cover Letter……………………………………………………………………………
ABSTRACT…………………………………………………………………………….
INTRODUCTION……………………………………………………………………...
1. UPDATING THE FRAMEWORK…………………………………………….
1.1. Problems with Angular 2.0…………………………………………...
1.1.1. Slow Loading Times…………………………………………..
1.1.2. Complex Binding Syntax……………………………………..
1.1.2. Configurations………………………………………………....
2. REPLACING HTML5 CANVAS……………………………………………...
2.1. Code Complexity……………………………………………………...
2.2. Unresponsiveness…………………………………………………….
2.2.1. Registering Click Events……………………………………..
2.2.2. Unable to Display Scrollbar………………………………….
2.3. Custom Elements and CSS………………………………………….
2.3.1. Code Simplicity………………………………………………..
2.3.2. Responsiveness……………………………………………….
3. IMPROVING USER INTERFACE…………………………………………...
3.1. User Feedback………………………………………………………...
3.1.1. Messages……………………………………………………....
3.1.2. Spinning Loading Icon………………………………………..
3.2. Simplifying Frequent Tasks…………………………………………..
3.2.1. Table Filtering and Sorting…………………………………...
3.2.2. Duplicating Table Rows and Grouping Products…………..
3.3. Improving the Design………………………………………………....
3.3.1. Icons…………………………………………………………….
3.3.2. Tables…………………………………………………………..
3.3.3. General Style…………………………………………………..
Page
-
-
1
3
3
4
4
5
5
6
7
7
7
8
8
8
9
9
9
10
10
10
11
11
12
12
13
CONCLUSION………………………………………………………………………...
REFERENCES………………………………………………………………………...
APPENDIX……………………………………………………………………………..
13
14
15
List of Figures
Figure 1. Screenshot of a success message……………………………………....
Figure 2. Screenshot of an error message………………………………………....
Figure 3. Screenshot of a spinning loading icon…………………………………...
Figure 4. Screenshot of the icons used for the Dashboard toolbar……………...
Figure 5. Screenshot of a scrollable table body and a fixed header…………….
Figure 6. Screenshot of the Work Schedule page…………………………………
Figure 7. Screenshot of the Products And Deadlines page……………………....
Figure 8. Screenshot of the Messages page……………………………………….
Figure 9. Screenshot of the Forecaster Statistics page…………………………..
Figure 10. Screenshot of the Product Statistics page……………………………..
Figure 11. Screenshot of the Late Product Statistics page……………………….
Page
9
9
10
12
12
17
17
17
18
18
18
List of Tables
Table 1. JavaScript Framework Size Comparison………………………………...
Table 2. Binding Syntax Comparison……………………………………………….
Page
4
4
ABSTRACT
The Canadian Ice Service (CIS) uses a Product Dashboard application to remain
on schedule for submitting products on the Web. The dashboard displays the deadlines
of all the products to be sent for the current day. Depending on the current time, their
deadline and their current location (in the queue, in PDS or on the Web), the products
are displayed in different colours. This application had several problems which were
fixed by developing a new version using AngularJs for the client side, Node.js and
Express.js for the server side and MongoDB for the database. The main page of the
application, the Dashboard, displays the products in the style of a timeline and was
implemented using HTML5 Canvas. The Canvas implementation had problems such as
code complexity and unresponsiveness to page events. The Admin section is used for
assigning products to forecasters and for adding, editing and removing products. This
section lacks validation when saving new changes and feedback when performing
actions. Both the Admin and the Statistics sections lack sorting by column and do not
provide feedback when loading data. The application was improved by updating the
client side framework to Aurelia.js as the previous one did not support the new Web
standards, by replacing HTML5 Canvas with custom elements and CSS to reduce code
complexity and improve page responsiveness and by improving the user interface by
adding feedback to users and by improving the style of the application.
Keywords
AngularJS, Aurelia.js, Node.js, Express.js, MongoDB, HTML5 Canvas, DOM
1
INTRODUCTION
The Canadian Ice Service (CIS) provides analysis on the ice in Canada’s
navigable waters. These analyses are converted to products, mainly geographical maps
(charts) and text bulletins (ice and iceberg forecasts) that show and describe the
amount of ice (concentration) and their thicknesses (stage of development) in various
Canadian regions. The forecasters use a Product Dashboard application to help them
remain on schedule for producing and submitting these products to the Web. The
Dashboard displays the deadlines and the delivery statuses of all the products to be
sent for the current day. Depending on the current time, their deadline and their current
location (in the queue, in the Product Delivery System (PDS) or on the Web), the
products are displayed in different colours. For example, a yellow product would
indicate that the product has not yet been sent and the deadline is within thirty minutes
from the current time.
The original application has several problems including manual scrolling to view
relevant data at certain times of the day, the rows are not sorted by time, Sigrid
products are not monitored, there is no French version of the application, it did not
provide statistics on the products or on the forecasters and there is little documentation
for maintenance.
The first solution to these problems was to develop a new version of the Product
Dashboard in the form of a Web application. This version was developed using
AngularJs for the client side, Node.js and Express.js for the server side and MongoDB
for the database. The application consists of three main sections, the Dashboard, the
2
Admin and the Statistics. The main page of the application, the Dashboard, displays all
the products to be delivered for the current day in the style of a timeline. The timeline
was originally developed using HTML5 Canvas in order to draw custom elements on the
page. A concept of primary and secondary products was used to display only one
product per region. The secondary products could also be displayed, however due to
the large amount, the products had to be recursively redrawn and scaled down each
time they reached the bottom of the timeline visible display area. This made the product
names too small, difficult to read and drastically slowed down the page refresh. The
admin section consisted of a Work Schedule page and a Products And Deadlines page.
The Work Schedule is used for assigning products to forecasters for the current day and
the Products And Deadlines page is used for editing, adding and removing products.
These two pages lacked validation when editing fields and feedback when performing
actions. The statistics section consisted of a Forecaster Statistics page and a Product
Statistics page. The Forecaster Statistics page is used for determining the percentage
of products that a forecaster sends on time. The Product Statistics page is used for
determining the percentage that each product arrives at its destination on time. Both the
statistics and the admin sections did not allow for sorting by column and did not provide
feedback when loading data.
In order to fix these problems, several objectives were established. Firstly, the
framework was to be updated as AngularJs does not support the new Web standards.
Secondly, HTML5 canvas was to be replaced with custom elements and CSS to reduce
code complexity and improve page responsiveness. Lastly, the user interface was to be
3
improved by adding feedback to users and by improving the coding style of the
application.
1. UPDATING THE FRAMEWORK
The Product Dashboard Web application was originally developed using the
AngularJs framework. Since then, a new version of Angular was released which used
an entirely different methodology than the previous version. It was therefore decided to
remodel the client side using Angular 2.0, which implements the new design standard in
Web development: Components [1]. During the remodeling of the application, there
were several concerns revealed about the complexity and speed of Angular 2.0. Finally,
a decision was made to convert the Angular 2.0 version into an Aurelia.js application,
which offered faster loading times as well as more maintainable and reusable code that
was much easier to learn.
1.1. Problems with Angular 2.0
Although Angular 2.0 is an improvement of the previous version, it also comes
with several drawbacks. Firstly, the framework can cause, at times, slow loading times
due to its size. Secondly, the data binding syntax is not very intuitive and can be difficult
to understand for developers new to the framework. Thirdly, it required constant
configuration changes when adding new features to the project.
4
1.1.1. Slow Loading Times
The speed of a framework is largely dependent on its codebase size. Here is a
comparison of the three frameworks used in the development process of the Dashboard
application [2].
Table 1. JavaScript Framework Size Comparison
Framework Angular 1.4.5 Angular 2.0 Aurelia.js
Size 143K 766K 350K
It is clear that the Angular 2.0 framework is much larger than its predecessor and the
Aurelia.js framework. However even with such a large framework, the core functionality
is no more superior than that of the Aurelia.js framework, which is less than half of its
size.
1.1.2. Complex Binding Syntax
The binding syntax in Angular 2.0 is case sensitive, unlike native HTML
attributes, and therefore requires a custom HTML parser. This syntax also contains
several special characters, making it difficult for developers to learn [3]. On the other
hand, Aurelia’s binding syntax uses HTML5 standards by simply extending already
established attributes [4], making it much more clear for developers new to the project.
Here is a comparison of commonly used attributes in both frameworks.
Table 2. Binding Syntax Comparison
Angular 2.0 Aurelia.js
● *ngIf=”isTrue” ● if.bind=”isTrue”
5
● *ngFor=”let item of items” ● (click)=”action()” ● [value]=”value” ● [(ngModel)]=”model”
● repeat.for=”item of items” ● click.trigger=”action()” ● value.bind=”value”
1.1.3. Configurations
One of the main issues with Angular 2.0 is the constant need for configurations.
Each time a new component is added to a project, it must be imported into the
application module and imported into the route. In order to add a service to a
component, it must be imported into the module, imported into the component, added to
the component’s array of providers and declared in the component’s constructor. In
Aurelia, all components, models and services are written in pure ES6 classes. In order
to use a service in a component, it only needs to be injected using the framework’s
@inject decorator. Refer to section 3 of the appendix for a comparison of a simple
component in both frameworks.
2. REPLACING HTML5 CANVAS
The main page of the Product Dashboard, the dashboard itself, was originally
designed using HTML5 Canvas in order to display a custom timeline. The two main
issues with this method were code complexity and unresponsiveness to page events.
For these reasons, a decision was made to replace the canvas with custom HTML
elements and CSS.
6
2.1. Code complexity
HTML5 Canvas is used for displaying custom elements on the page. This is done
by drawing each element using a JavaScript context object. The code complexity can
be portrayed with the following example. Here is the code required to draw a simple
rounded rectangle [5]:
ctx.beginPath(); ctx.moveTo(x + radius, y); ctx.arcTo(x + width, y, x + width, y + radius, radius); ctx.arcTo(x + width, y + height, x + width - radius, y + height, radius); ctx.lineTo(x, y + height); ctx.arcTo(x, y, x + radius, y, radius); ctx.stroke(); ctx.fill(); ctx.closePath();
In the case of the Dashboard, if a product is due at the same time as another, it must be
displayed underneath the previous one. However, in canvas, it will simply be drawn over
the previous product. It was then necessary to loop through the position of each product
and increase its vertical placement if an overlap were to occur. Another issue occurred
on the Dashboard when there was a large number of products being displayed at once.
In order to display all of the products, it was necessary to use recursion to redraw the
canvas with smaller products each time they reached the bottom of the timeline area.
Here is a simple code example for clarification:
if (products[i].y >= maxHeight) { width -= 10; height -= 5; draw(); }
This method drastically reduced page performance due to the amount of recursion
needed.
7
2.2. Unresponsiveness
Another problem with using Canvas for this application is that it does not respond
to changes or events in the Document Object Model (DOM). This becomes an issue
when attempting to click specific elements on the canvas and when attempting to
display a large amount of products at once.
2.2.1. Registering Click Events
Each product group has a button used for displaying/hiding its products and each
product has a button for displaying/hiding its delivery statuses. In order to handle a click
event for one of these buttons, the mouse coordinates must match a predefined product
position, which requires looping through every product each time there is a click event
on the canvas, even if the click isn’t over a button. This method required complex and
time consuming code which is why it was later replaced by HTML button tags.
2.2.2. Unable to Display Scrollbar
As previously stated, the products must be scaled down whenever there are too
many of them being displayed at once. An intuitive solution would be to use a scrollbar
whenever this occurs. However, the products being drawn onto the canvas are not a
part of the DOM, meaning that the page will not respond when they reach the bottom of
the timeline, making it impossible to use a scrollbar.
8
2.3. Custom Elements and CSS
In order to make the code more readable and maintainable, the canvas was
replaced with custom elements and CSS. This method simplifies the code and the
Dashboard’s responsiveness.
2.3.1. Code Simplicity
Custom elements allow for modularizing the code into separate components. For
example, a product group icon is designed with its own HTML, JavaScript and CSS files
[6]. Another benefit to this method is that CSS is a more standard way of styling custom
elements on the page. This method improves the code’s readability and learnability.
2.3.2. Responsiveness
The page responsiveness is improved by using custom elements because they
are placed in the DOM using pure HTML and CSS. Instead of defining a coordinate on
the canvas for a button click, a simple button tag can be used. Also, if there are too
many products being displayed at once, a scroll bar appears by using pure CSS. This
avoids the need to scale down the products each time there are too many in the view,
increasing the performance of the Dashboard.
9
3. IMPROVING THE USER INTERFACE
The user interface of the previous Dashboard version had problems including the
lack of feedback when performing actions, repetitive and time consuming actions, and
the general styling of the application wasn’t very appealing.
3.1. User Feedback
User feedback is essential for informing users that an action is being or has been
processed. In order to improve the user feedback of the application, a custom message
element was implemented for informing users when their actions have been completed
and a spinning loading icon was designed for informing them that data is being loaded.
3.1.1. Messages
In order to inform users that an action has successfully been completed, custom
messages are displayed on the top right of the page. These messages also inform
users if a problem has occurred on the server or if they have entered an invalid field
when adding or editing a product group.
Figure 1. Screenshot of a success message.
Figure 2. Screenshot of an error message.
10
3.1.2. Spinning Loading Icon
Another method of feedback added was a spinning loading icon for displaying
when data is being requested from the server. This feature is useful when loading large
amounts of data, e.g. Product Statistics. These actions may take a few seconds to be
completed and it is essential that the users are aware that their action is being
processed.
Figure 3. Screenshot of a spinning loading icon. 3.2. Simplifying Frequent Tasks
In the admin section of the application, there are several time consuming tasks.
These include finding specific products in the table as well as editing and adding
products. In order to simplify these tasks, certain features were added to the tables.
Firstly, filtering results and column sorting were added to simplify finding products.
Secondly, a button for duplicating rows was included and the products were placed into
groups to simplify the task of adding new products.
3.2.1. Table Filtering and Sorting
The table filtering feature allows users to display only the products matching their
search request. This feature simplifies looking for multiple products with similar
attributes. For example, the results can be filtered by a specific issue time, type, day of
the week, etc. The sorting feature displays the products in either ascending or
descending order depending on the selected attribute. The products could be sorted by
11
their active status, meaning that either all active or inactive products would be displayed
first.
3.2.2. Duplicating Rows and Grouping Products
The duplicating rows button allows users to add a copy of a product to the table,
simplifying the task of adding multiple products with similar attributes. The products
were eventually grouped by region, further improving the simplicity of adding new
products. When adding a new region, the user simply adds a new group containing all
the relevant fields and the list of products for that group. This feature was implemented
by reformatting the database into groups containing arrays of products. View a
comparison between the product schema and the group schema in section 2 of the
appendix.
3.3. Improving the Design
The final improvement to the user interface of the application was to redesign the
look and feel of the application. Firstly, standard icons were added for buttons to avoid
taking up too much space on the page. Secondly, scrollable table bodies were
implemented in the admin and statistics pages. Thirdly, the general style of the
application was improved to make the application more appealing.
12
3.3.1. Icons
The icons are primarily used in the toolbar of the Dashboard and in the tables of
the admin pages. By replacing text in buttons with standard icons, it is possible to
display many buttons without taking up too much space.
Figure 4. Screenshot of the icons used for the Dashboard toolbar. The icons used were provided by Google’s Material Icons set [7], making them standard
and easily recognizable. However, in the case that a user does not recognize an icon, a
hover title is included to clarify the action of the button.
3.3.2. Tables
The tables in the admin and statistics pages were improved by using a scrollable
body with a fixed header instead of using pagination. The scrollable body simplifies
looking through all of the table rows and the fixed header clarifies which field the table
cell belongs to.
Figure 5. Screenshot of a scrollable table body and a fixed header.
13
3.3.3. General Style
The general style of the application was improved by using a fixed colour
scheme, shadows and border radiuses. These styles make the application more clear
and appealing for users. The style changes can be viewed in section 3 of the appendix.
CONCLUSION
The previous Python version of the Dashboard had several problems including
manual scrolling throughout the day to see new data, the rows were not sorted by time,
Sigrid products were not monitored, there was no French version of the application and
there was little documentation for maintenance. The new web version fixed several of
the problems but also had its own drawbacks such as AngularJs which did not support
the new Web standard of Components, HTML5 canvas which made the code complex
and the page unresponsive, and the user interface which lacked user feedback and
appealing styles.
In order to solve these problems, a new version of the application was developed
by replacing the framework with Aurelia.js, by replacing HTML5 canvas with custom
elements and CSS and by improving the user interface. Firstly, the Aurelia.js framework
offers faster loading times, a more intuitive model data binding syntax and less complex
configurations. Secondly, using custom elements and CSS for displaying a custom
timeline reduces code complexity and improves page responsiveness. Thirdly, the user
interface now provides sufficient feedback when performing actions and has more
appealing styles.
14
REFERENCES
1. “QUICKSTART Typescript” Retrieved January 2, 2016, from
https://angular.io/docs/ts/latest/quickstart.html.
2. “Sizes of JS frameworks, just minified + minified and gzipped, (React, Angular 2,
Vue, Ember)”, Retrieved January 2, 2016, from
https://gist.github.com/Restuta/cda69e50a853aa64912d.
3. “TEMPLATE SYNTAX” Retrieved January 2, 2016, from
https://angular.io/docs/ts/latest/guide/template-syntax.html.
4. Danyow, J. “Binding: Basics” Retrieved January 2, 2016, from
http://aurelia.io/hub.html#/doc/article/aurelia/binding/latest/binding-basics.
5. “HTML5 Canvas Rounded Corners Tutorial” Retrieved January 2, 2016, from
http://www.html5canvastutorials.com/tutorials/html5-canvas-rounded-corners/.
6. Grant, A. “Templating: Custom Elements Basics” Retrieved January 2, 2016,
from
http://aurelia.io/hub.html#/doc/article/aurelia/templating/latest/templating-custom-
elements.
7. “Material Icons” Retrieved January 2, 2016, from https://material.io/icons/.
15
APPENDIX
1. Component Configuration Comparison
1.1. Angular 2.0
my-component.ts import {Component, NgInit} from ‘@angular/core’; import {MyService} from ‘./my-service’; @Component({ selector: ‘my-component’, templateUrl: ‘./my-component.html’, styleUrls: [‘./styles.css’], providers: [MyService] }) export class MyComponent implements OnInit { constructor(private myService: MyService) { } ngOnInit() { This.message = this.myService.message; } } my-component.html <h1>{{message}}</h1>
1.2. Aurelia.js
my-component.js import {inject} from ‘aurelia-framework’; import {MyService} from ‘./my-service’; @inject(MyService) export class MyComponent { constructor(myService) { this.myService = myService; this.message = this.myService.message; } } my-component.html <template> <h1>{{message}}</h1> </template>
16
2. Product and Group Schema Comparison
2.1. Product Schema
{ _id: ‘MetArea_2016-12-03T15:00’, prodid: ‘FI01IS_1500’, product: ‘FI01IS’, group_en: ‘MetArea’, group_fr: ‘MetArea’, type: ‘Bulletin’, set_deadline: ‘14:50’, set_issueTime: ‘15:00’, set_validTime: ‘15:00’, loc_Queue: ‘14:32:50Z’, loc_PDS: ‘14:45:55Z, loc_Web: ‘’, timezone: ‘UTC’, destination: ‘PDS’, days: ‘Daily’, active: true }
2.2. Group Schema
{ _id: ‘MetArea_2016-12-03T15:00’, name_en: ‘MetArea’, name_fr: ‘MetArea’, type: ‘Bulletin’, set_deadline: ‘14:50’, set_issueTime: ‘15:00’, set_validTime: ‘15:00’, timezone: ‘UTC’, destination: ‘PDS’, days: ‘Daily’, active: true, products: [ { _id: ‘FI01IS_1500’, name: ‘FI01IS’, loc_Queue: ‘14:32:50Z’, loc_PDS: ‘14:45:55Z, loc_Web: ‘’ }, ... ] }
17
3. Page screenshots 3.1. Admin pages
Figure 6. Screenshot of the Work Schedule page.
Figure 7. Screenshot of the Products And Deadlines page.
Figure 8. Screenshot of the Messages page.
18
3.2. Statistics Pages
Figure 9. Screenshot of the Forecaster Statistics page.
Figure 10. Screenshot of the Product Statistics page.
Figure 11. Screenshot of the Late Product Statistics page.