1. MSc Computer Science
COMPGC02 - Apps Design, January 2016
Team 18 - Client: Microsoft UK
Marco Greselin, Chantal Marin, Lukmaan Kolia
The Band to the Pole
Technical Report
2. ABSTRACT
In March 2016, a team of two explorers will be trekking to the North Pole in an effort to raise money for
charity. The expedition is also taking place to gather physiological data in extreme conditions. Initially,
the project consisted of one key requirement directly related to this: to build a mobile application which
uses the Microsoft Band to capture, record and upload the data which will be used for post-expedition
analysis. Employing a user-focused approach, the team identified an additional previously unidentified
stakeholder in the project, the potential donors.
After evaluation what is currently available, it was found that Microsoft Health is already capable of
capturing sufficient data required by the explorers. In correspondence with the client, the requirements of
the project evolved to address two end-users. These are the explorers and the potential donors.
The deliverable, targeting the potential donors, is an online dashboard/website which would update and
display the progress of the explorers during the expedition. The displayed metrics include a map with
current progress, heart rate and calories burned by the explorers. The data to populate the charts is
pulled via API requests to Microsoft Health. The key motivation behind this was to engage the donor with
the expedition and make them feel a part of the journey. It is anticipated that this will help the explorers
raise more money for charity.
The website is built using a customized version of Bootstrap inspired by Metro design concepts. The
backend is built on Node.js, a lightweight yet powerful web server with improved performance compared
to traditional PHP due to its single-threaded non-blocking event loop, and this was taken advantage of in
our application.
The live demo for this app is available here:
Link: http://bandtothepoledemo.azurewebsites.net/
User Name / Password: pole
In this report we will use the version with two explorers as reference. We also
developed a version for one explorer due to a last-minute change of requirements.
2
3. Part One: Introduction
The Challenge
Paul Thomas and Michael Vermeersch are two Microsoft Enterprise Architects at Microsoft UK. Their
initial requirement to our team was to use the Microsoft Band - a wearable that measures a series of
biometric data - to empower a team of two explorers, James Redden and Anita Buckley, going to the
North Pole to raise funds for charity. While we knew what device would have been used for this
exercise, we were given freedom to develop our own solution for this challenge.
Before brainstorming around what app we would build, we wanted to foster a deep understanding of
who our final client was and how could we make them happy.
The second challenge was addressing our limited coding knowledge, and how we could manage our
time between identifying the necessary technology and learning them to produce a solution. We wanted
to propose a reasonable deliverable that we could meet, an app that could be effectively used by our
final client and help them achieve their goals.
Microsoft Band and Health Cloud API
Microsoft Band was first launched in November 2014. It is mainly advertised as a health and fitness
wearable, residing in a slightly different market compared to smartwatches such as Android and the
Apple Watch.
Like most wearables, applications run on the phone the user pairs to, and communication streams are
established with the device for both displaying information on the device screen and receive data.
Microsoft Health is the app needed for the band to work. It is available on Windows Phone, Android and
iPhone.
Three SDKs have been introduced by Microsoft to enable third-party developers to use the Band data:
● Band SDK: Third party applications can use the Microsoft Band API to receive sensors data
directly. This allows mobile applications to communicate directly with the band as needed.
3
4. ● Web Tile: Developers can create new Tiles (i.e. menus on the Band screen) through a web
interface provided by Microsoft. Data can be hosted on any website and pushed to the band via
the MS Health app.
● Health Cloud API: This API allows download of data stored in Microsoft Health. The data is
collected by the MS Health app. This includes selected metrics in the form of hourly or daily
summary (data collected in the background) as well as a comprehensive list of sensors data
including GPS collected during activities.
The Team
The team was randomly formed at the beginning of the module. This is mainly due to the fact we did
not know each other previously. We tried to assign roles at the beginning of the project as we value
sense of ownership which makes the development process more streamlined.
While these roles gave us a general area of responsibility, they do not constraint us from working on
different parts of the project at the same time.
Marco holds a BSc in
Economics.
Lukmaan holds an MEng in
Biochemical Engineering
Chantal holds a dual BS in
Industrial/Telecom Eng. and is
an Architect.
Roles:
● Team Lead
● Requirements Lead
● Documentation Lead
Roles:
● Lead Systems Analyst
● Lead Architect
● Lead Programmer
Roles:
● Lead User Interface
Designer
● Lead Tester
The Client
This project was a consulting service carried out for Microsoft UK. The Microsoft team was composed
of Michael Vermeersch and Paul Thomas, with our interaction with one of the explorers, James
Redden, primarily through here. Michael is an Enterprise Architect at Microsoft in charge of Strategic
Consulting and IT/Business alignment and Paul is also an Enterprise Architect at Microsoft leasing the
Microsoft Enterprise Strategy engagement at Kent County Council.
Michael and Paul provided insight into our roadmap and our product. Michael was our project
coordinator making sure that the following status table was updated and outstanding actions were
taken care of.
4
5. Paul was in charge of making sure the necessary resources were allocated to the project. Final delivery
of the product will be to James Redden.
We first met Michael and James at the beginning of the first semester to set the expectations and
define the project scope. We had several calls with the Paul and Michael (Bi-weekly reports) to make
sure the project was going in the right direction, as well as updates with James to make sure the
project was also complying with his expectations.
The Deliverable
The project had a high level of flexibility as the only requirement from the client was to make use of the
Microsoft Band during the charity trek to the North Pole in order to capture physiological data for
post-expedition analysis. The freedom to develop our own solution made this an iterative process,
where the first proposed solution was to develop a third-party mobile application which would make
use of the Band SDK.
Working through what the Band SDK had to offer, the team realised that many of the sensors available
such as the altimeter, barometer and ambient light sensor were not relevant to this particular
application. Gathering data from such sensors would be trivial, as values would remain either relatively
constant throughout the period, or were not practical. An example of this would be the ambient light
sensor, as the Band must be worn beneath several layers of clothing due to external temperatures
averaging -40 o
C, with the Band ceasing to function past -10 o
C.
The only four sensors which would produce meaningful data were for heart rate, calories burned,
distance travelled and skin temperature. From these, the Microsoft Health mobile app already
measured the first three, with skin temperature being the only piece of data not accounted for. This
gave the team two options:
1. Produce a mobile application which included skin temperature and other sensors.
2. Use the already existing Microsoft Health app in conjunction with another solution the team
could develop.
5
6. Defining the solution in option 2 meant thoroughly understanding who our end client was. As the
expedition was for charity, the team identified the donor as a key stakeholder. The central motivation
for targeting this group was how best can they be engaged with and make them feel a part of the
journey. An online dashboard showing current progress and key physiological metrics (accessed with
Health Cloud API), whilst the expedition is taking place, makes the journey more accessible and
involving compared to pre and post-expedition commentaries. The team hopes that the increased
engagement with the donor will result in increased donations.
When presented to the client, option 2 was well received as it addressed the primary aim of the
expedition, which was raising funds for charity. However, a solution which gave the explorers access to
the data for analysis was still needed. For this, the team will provide the explorers the data in JSON
format.
Work Packages
We present here the work packages. They recall the Gantt Chart outline with some additional
breakdown. Only sections relevant from production stage onwards are listed.
Backend Owner
Set up of cloud solutions and general organisational tasks MG
Background research on web servers, including how they work, common
protocols (HTTP, TCP/IP) and common platforms.
LK
Create basic web server for serving static content on localhost. LK
Setup Microsoft Azure for website hosting. LK
Create web server using chosen backend platform (Node.js with Express
framework).
LK
Write algorithm responsible for daily API calls to MS Health. LK
Write algorithms in response to jQuery requests for manipulation and serving of
data. This data is then used in charts, heartbeat animation and the map.
LK
Frontend Owner
Prototype one, owner CM
Map: set-up, scrolling, Google Charts CM
Responsive design (choice of framework) CM
Final version, owner MG
Map: logics for markers and path, colors MG
Charts.js, data connections, jQuery animations MG
Responsive design (choice of framework and adjustments) MG
6
7. Project Management Owner
Client relationships, requirements, slides, bi-weekly reports, internal
communication
MG
Backend with frontend efforts coordination MG
Use Cases and the User Journey
The diagram below describes
the journey from data upload by
the explorer to content
consumption by the potential
donor.
The explorer is expected to
wear the Band throughout the
day and keep it connected to
his/her phone. However, there
is no data upload until the
explorer reaches a camp base
at night (usually after 9pm). At
this point, the Microsoft Health
App that stored locally the data during the day will upload it to the Health Cloud platform. We will make
one call to the Health Cloud API once a day and download a new JSON file with the data for the
explorer within the dates of the expedition. This JSON file is used to generate the charts on the website
that are accessed by potential donors. A converted visit to the website consists on a potential donor
clicking on the donate button which redirect to the JustGiving site.
Front End
As the online dashboard is primarily a visualisation tool, there are a limited number of use cases, all of
which consist of very simple workflows.
1. Clicking the Donate button will raise a modal dialog window with the three charities
represented by the explorers. Clicking on one of the donate buttons here will take the donor to
the respective charity JustGiving page in a new window.
2. All Twitter interactions can be found on the lower right side of the page.
Back End
There are no use cases for the back-end as there is no user interaction. However, some interaction is
required by the explorers for this platform to function properly, and this is described here.
The two explorers will each be equipped with a Microsoft Band for the entire trek. As there is little
connectivity in the North Pole, the explorer team will only have access to the internet whilst camped. It
7
8. is expected that the explorers will use this window to sync the data from the Band to Health’s cloud
storage, from which data can be accessed via API requests.
The explorers are also required to split the day’s data into two segments: one accounting for the bulk of
the day, with the other segment lasting only as long as it takes to attain a GPS signal. This is explored in
more detail in the Key Research: Existing APIs section, and is done entirely through the Microsoft
Health mobile app.
Client Pre-Production Feedback
In mid-November we met our client following our
initial discussions on the form of the deliverable.
We were given lots of freedom on what to build
which of course forced us to navigate uncertainty.
The requirement was just to use the Microsoft
Band and potentially the Health API.
Our client was very pleased by our solution. The
initial thought when we started the project was to
focus on the explorer and build an app for the
phone or a new tile to add to his band. However,
we quickly realised that the goal of this operation
wasn’t the explorer but rather the donor. Hence,
we wanted to help realise James's intent to
collect money for the charity.
At this stage we were considering building:
- An app for potential donors to follow the expedition for smartphones,
- A similar app for desktop devices,
- An uploader to allow James to push data to the cloud.
We quickly realised that the third point was not
necessary since MS Health was doing this well
already. We also though a web app with
responsive design could offer a more consistent
user experience than two separate solutions.
James was very satisfied of this concept since it
allowed him to achieve his end goal. It also met
the expectations of Paul and Michael since we were using Microsoft technologies targeting users.
8
10. In this section we will discuss the system design with a general overview of all
components. Particular focus will be put on the data flow. We will finally consider the
feedback from the client on these matters.
The Data Journey
Generating the Data
The data to be delivered to the end-user at home is first created by the Microsoft Band - worn by the
explorer - and stored locally on the Band. When the explorer has access to the internet, this data is
synced with Microsoft Health cloud storage via the Health mobile app.
Accessing the Data from Health
To access this data, an OAuth2 authentication process is required. The initial refresh token was
generated manually: first by providing a link to the explorers which redirected to a Microsoft account
login page. Logging in generates a URL, which was returned to the team. The URL contains a code,
which when coupled with the clientID and clientSecret (unique to this app), will generate the first set of
refresh and access tokens.
Access tokens expire in an hour, hence the need for refresh tokens. Refresh tokens allow creation of a
new set of refresh and access tokens. The lifespan of the refresh token is longer (several days), though
the duration is not clear. As a precaution, the newer refresh token is used every time and the old one
discarded.
Pulling the data
The access token is placed into a GET request header, along with the URL. This returns the explorer
data. Depending on the call type (Summary or Activity), there is a different limit on the number of
elements in the data array. Pagination is applied by Health if the requested data does not fit within the
array limit, with the nextPageproperty only present in the JSON object if additional data is yet to be
received. The nextPageproperty value is a URL where the additional data can be accessed. By
appending additional data to an object, a complete set of data can be saved to server file storage.
Making the Data Accessible to Client
Two options were considered on how to make the data accessible to the end user:
● Produce a request to Microsoft Health every time a user visits the website: the API call would
be fired by an incoming GET request to the web server.
● Periodically make API calls and store the data in a JSON file on the web server. AJAX calls
from the front-end point to this file.
The latter route was chosen, and this is explained in the System Behaviours: Daily API Call section
below.
10
11. Accessing Data from Client Side
To access the data required to populate the charts and produce markers on the map, a function from
the jQuery library (getJSON() request) is used. The request is made upon initial page load, with the logic
for isolating relevant data handled on the response from the request directly. The refined data is then
used in declaring dataset objects which can be used by the Chart.js and Google Maps APIs.
System Behaviours
Routing: Restricted Navigation
The server is configured to only allow the ‘/public’ directory to be accessible by the end user. The public
directory contains all static assets such as html, css, JavaScript, image and data files. Using the
express.static, an Express (Node.js framework) middleware, allows these files to be served directly i.e.
without needing to specify ‘/public’ in the URL. This also ensures end users cannot navigate outside of
the public folder.
Daily API Call
As the explorers are only able to sync the captured data from the MS Bands to MS Health once per day,
making an API request to Health with every end-user visit is inefficient. Rather, the data can simply be
saved to a JSON file on the web server, which is then accessed via AJAX calls made by the end-user.
The data is then fed into the charts and map on the homepage.
API pulls are made once a day, with the ‘startTime’ API parameter as the start time of the expedition.
The end time is not provided, returning all data up to current time. When saving, this overwrites the old
JSON file, ensuring a new ‘clean’ set of data. This reduces possible standard output errors when writing
to file. The logic for this operation is within the apiCalls.jsfile, which is called in the wwwfile. Further
explanation for this is given in the Key Research section.
The Donate Button
When the potential donor click on the
donate button, she will be presented with a
presentation of the three charities
supported by the program. We provide the
logo and a short description for each one
of them. The donor can choose which
charity to support by clicking on the donate
button in the popup window. This will
redirect to the JustGiving website where
she will be able to make the transaction.
The popup is based on the Modal plugin in
Bootstrap and it’s fully responsive.
11
12. The link to JustGiving contains a reference code so that we are able to track which donations come
from our website. We created the “Microsoft” reference. James will be able to see this information in
the analytics of his JustGiving account. Here is an example of link for the Diana Award.
https://www.justgiving.com/NorthPoleLastTwoDegreesDianaAward/4w350m3/donate/?refe
rence=MICROSOFT
Client Feedback Discussion
We presented the first iteration of the web app to Paul Thomas on December 22nd. The response was
very positive. The look and feel of the first version were similar but not identical to the final version. In
particular:
- The data was not connected to charts and map which were showing static arrays of data.
- The map visual elements were not customized.
- The lower sections were still under construction and displayed two explorers.
The feedback email from this first demo is included in the appendix. We received the comment on the
fact we used Google Maps and not Bing Maps API for the map. An explanation of the choice is also
included in the appendix emails section. Overall, Paul invited us to think about future collaboration after
the deadline of the 20th of January which shows his appreciation of our work.
A second presentation was performed for James at the beginning of January. This was effectively a
review of the final version of the website. In this presentation we received more questions about the
Health app and what he should have done to ensure data storage in his phone.
Michael also pointed out that the distance section in the dashboard did not clearly show the unit of
measurement. We hence included it (Km) and made sure the data shown was in kilometers (it is
returned in centimetres by the API).
12
13. Part Three: Key Research
This part will go deeper analysing the implementation of the front end and the back end. For each, we
will discuss choices made on the use of platforms and frameworks as well as key algorithms
implemented. We will then present the file structure of our directory and report the final feedback from
our client.
We also go through some advanced topics such as responsive design and analytics (in the front end
section) as well as design patterns.
The Back End
Hosting Platform: Microsoft Azure
Hosting platforms automates and reduces the overhead of managing a website. The first step was to
decide which hosting platform to use. Using Microsoft’s Azure cloud computing platform was a natural
choice, with the type of cloud service offering being the first point of decision.
Azure provides all three levels of cloud solution offerings: Infrastructure as a Service (IaaS), Platform as
a Service (PaaS) and Software as a Service (SaaS). IaaS consists of only hardware and networking
pieces provision, with all management of the server allocated to the developer. PaaS takes this a step
further, and also automates the management of the virtual machine (i.e. the underlying operating
system), with the software management left to the developer. SaaS takes this another step forward,
with the actual service to the end-user also managed by Azure (e.g Office 365).
For this project, PaaS was chosen as it made little sense to keep the overhead of managing a web
server (IaaS). Different configurations of a virtual host would have little impact on the end-user
experience, and so was left to Azure.
There was potential to choose SaaS, particularly with using Microsoft HealthVault as the software.
However, the level of flexibility decreases with increasing automation and several elements defined in
13
14. the HCI section were not available in HealthVault. These include a map of the daily progress of the
explorers, and the social media elements.
Web Server Language: Node.js vs PHP
Scripting languages on the back-end handle the business logic of the server and determine how the
server will respond to various client requests. There are several options available, though only two of
the most common languages of 2015 were considered, PHP and JavaScript.
PHP is a language primarily designed for server-side development. Though JavaScript was traditionally
used only in front-end development, this has changed in recent years. With the runtime environment
provided by Google’s V8 engine, JavaScript can now run on a machine as opposed to being confined to
the web browser. This opens a host of possibilities, as JavaScript is now capable of accessing files on
the system and listening to network traffic (including http requests). This allows web servers to be built
using only JavaScript.
There are several reasons for choosing Node.js (a JavaScript runtime environment). It is incredibly
lightweight and much faster compared to ‘traditional’ PHP[3]
. Node.js also makes use of a single
non-blocking event loop: requests are handled via callbacks, a feature borrowed from the functional
programming paradigm. This means threads do not wait for the request to be delivered before starting
work on the next process, and so can handle multiple processes at the same time. This feature was
crucial for our application as the server is required to automatically make API calls everyday. PHP
executes top-down, and implementing a function which executes at a specified interval means any
code which follows the interval loop is never executed. The solution here would be to use a scheduler
such as cron for Linux or the Task Scheduler service for Windows. However, this requires configuring
the underlying operating system of the server. Choosing JavaScript over PHP removes this additional
setup.
It was also advantageous to use the same language in the front and back end, particularly as the two
would be communicating data structures via JSON, and would work identically on both sides of the
equation. Using the Express framework simplified much of the web server setup. The default
framework was slightly modified, as no particular viewing engine was used, further stripping the web
server.
Framework: Express
Express is a lightweight Node.js framework used in web development. It provides a wide range of
features such as routing, middleware support, a viewing engine and more. Much of this is set up by a
default configuration. In this application, Express was primarily used for its middleware. The stack of
functions that sit in between the initial client request and the final response by the server is referred to
as the middleware. The middleware is declared in app.js. Express also configures routing by default,
which was used in restricting end-user access to only the /public directory.
Though Express supports a viewing engine, this was not used. Using EJS (a templating language)
would have made access to explorer data much easier. Rather than requesting JSON data with AJAX,
the JSON object could be stored in a global variable and easily accessed by simply calling the variable
in the EJS template page (EJS templates replace traditional HTML pages). However, this comes at a
performance cost as the viewing engine in Express does not support streaming (strongloop.com). The
entire HTML output needs to be constructed before the first byte is written to the HTTP response,
14
15. effectively making load times appear longer to the end-user. Using standard HTML allows the end-user
to download assets (such as CSS defined in the head tag) sooner.
RESTful API: Microsoft Health
An Application Programming Interface (API) allows different pieces of softwares to communicate with
each other. There are several types of APIs, though this project only makes use of Representational
State Transfer (REST) APIs. REST APIs function similarly to how websites work. A client makes a
request to a server, and receives a data response from the server, all via HTTP.
The Microsoft Health’s RESTful API gives two separate ways of accessing data captured by the Band:
Summary and Activity. Which method to use depends on how the data was captured and what data is
required.
When the Band is worn, it continuously captures data for distance travelled, heart rate and calories
burned. A Summary call returns this data for the specified period of time, arranged in the specified
time bucket (daily or hourly). Additional features such as GPS location and a minutely time bucket are
only available via an Activity call. However, this is only possible for the data that is part of an activity.
The Band offers several activities by default including Run, Bike, Sleep and Golf. Selecting one of the
activities starts data capture which includes the additional metrics (GPS, minute time bucket).
For this application, a simple Summary call was not enough as one of the elements on the website is a
map showing the daily progress of the explorers using GPS coordinates. Lack of minute-by-minute
granularity in the Summary call was also an issue to consider, as one of the requirements from the
client (explorers) was access to a full set of data for the entire expedition at a minute-level granularity.
This meant that the explorers must:
● Make two separate Run activities everyday.
● One Run activity would account for the bulk of the data. GPS disabled.
● The other Run activity would last only as long as it takes to attain a GPS signal. GPS enabled.
Ideally, one activity with GPS enabled would be sufficient. However, battery life of the Band is limited to
3-4 hours with GPS enabled.
For this application, a Summary call is used for charts data, and an Activity call for the map markers
showing explorer progress. Summary calls include any data captured whilst the Band is in Activity
mode.
15
16. Backend Algorithms: Daily API call
The above figure shows the steps taken in pulling data from Health. The first step involves generating a
new set of refresh and access tokens. This is done with the refreshingToken() function, which
consists of the existing refresh token, clientID and client secret (latter two are unique to each Microsoft
Developer accounts) in the URL. The returned access token is used to access the data, and is place in
the request header of the requestData() function.
The response data is in the form of a string, which after parsing into a JSON object, allows checking of
the object for a nextPage property. Its presence indicates pagination has been applied to the data, with
the value of the nextPage property consisting of the URL where the remaining data can be found. If
present, this URL is fed into the requestData() function and the response is appended to the initial data
response. The cycle continues until no more data is to be received, and then written to file, where it is
accessible with jQuery from the website.
16
17. The Front End
HTML5/CSS3/JavaScript
Hypertext Markup Language 5 (HTML5) is used in creating web pages and is the model in the
Model-View-Controller architectural pattern. As the model, the HTML page stores the result of any
business logic in the controller, and hence manipulated by the controller. As the website consists of
only one page, a single index.html file exists for this project.
Cascading Style Sheets (CSS) is the view in the MVC pattern, and is responsible for visually
manipulating elements defined in the HTML page.
JavaScript fills the controller role in the MVC pattern, and manipulates the model. JavaScript brings
several key functionality including interactable elements on the website and AJAX calls used in making
GET requests to the web server. To make use of JavaScript functionality, the files must be included in
<script>tags with a src attribute with the file URL. Only two script tags are included in the header, as
these JavaScript files are critical in order for the web page to load correctly. The remaining JavaScript
files which manipulate the HTML elements are included at the end of the body in order to ensure the
page has loaded correctly first. Defer tags are also used to ensure the JavaScript file which will be used
by the deferred file is preloaded.
Metro UI
“Perfection is achieved, not when there is nothing left to add,
but when there is nothing left to remove.”
Antoine de Saint-Exupéry
The Metro design language was introduced with the
commercialisation of Windows 8 and provided a new framework
for graphic design at Microsoft. The key font for this visual
language is Segoe UI family in particular the Light font which we
used throughout the web app. Metro takes concepts from the
Swiss Style, a set of concepts that were introduced in Switzerland
and adopted in various European countries in the 1920’s. The
strongest characteristics is the use of sans-Serif fonts (such as
Segoe UI or the more popular Helvetica font). The font becomes
an element that does not seek to be expressive, rather, like the
statement above recalls, unobtrusive and lacking of
ornamentation. These concepts are inspired by the De Stijl
movement which advocated for geometry purely as a vehicle for
transmitting messages rather than having an aesthetic element
attached to it.
The grid system was highly implemented as part of the Swiss
Style. However, Metro UI, like the Swiss Style, is about structured
information rather than pure grids. We implemented this in our
website for instance with subtitles or comments on data displayed in a few occurrences.
17
18. jQuery
The popular JavaScript library jQuery was used
throughout the dashboard for functionality
such as popup windows, animations and AJAX
calls.
As an example, we used jQuery for the
animation of the heart rate. jQuery changes
dynamically the CSS every N milliseconds
using the animate function. The animation is
based on two phases: stretching out and
squeezing both of the same length. The length
is based on the last measurement of the heart rate (see Front End Algorithm section for more on the
calculation). The general idea is that we change the padding and the opacity of the image (a normal
png). In the code (located in chartBuilder.js) we offer two versions of the animation based on the size
of the screen. It would not look good to have a big animation in small screens.
Other examples of use of jQuery include the bar with the length of the expedition. In that case we use
the variables set up during deployment that define start and end date of the expedition and we compare
with today’s date to show a comment and make relevant changes to the bar CSS.
Chart.js vs Google Charts
Version 1 with Google Charts
Version 2 with Chart.js
Chart.js is a JavaScript library which allows creation of simple yet
elegant charts using the HTML5 canvas element. The library is very
lightweight and dependency-free, making it easy to use within any
system. Creating charts only requires a JavaScript object
containing the necessary properties including arrays of datasets.
The library also aesthetically complemented the Metro UI
framework well, making this our chosen charts library.
In our initial iterations we used Google Charts for the graphs.
However we were not able to achieve the results we wanted in
terms of visual appearance. So we looked for other open source
frameworks and found Chart.js. This gave us a lot more freedom
for customisations and provided a much better UX. Also the
addData() makes parsing data very easy in loops. Chart.js is a
library and we located the source code of it in the js folder.
The Map
The two options considered in choosing a map API were Bing Maps and Google Maps. Both provide a
comprehensive set of tools which would satisfy our requirements. The only factor to consider was how
user friendly the documentation was. The Google Maps documentation greets the user with less jargon
and an easy to navigate menu, with a ‘Guides’ section which walks through common uses of the API. All
18
19. of the functionality to be implemented in this project could be found in the Guides section, making this
the chosen technology.
Though Google Maps APIs can be used without an API key, features such as populating the map with
markers and polylines requires a key. Keys can be generated with a Google account and is a short
guided process.
Once the key is generated, all of the API features are available. The API also provides a callback option
when loading on the HTML page, allowing asynchronous loading of the API. This is defined within the
URL in the script tag in the web page HTML file.
The map is set with height:100vhso that whatever the resolution of the browser accessing the page,
the map will take full height.
Responsive Design
As users access websites on a plethora of different devices, responsive design and the “mobile first”
principles, made it possible to develop native websites that offered a consistent user experience across
devices. The other main alternative is, in fact, the development of a second website that is only
accessible on mobile devices.
Mobile-first website have been possible by a number of innovations in CSS3 in particular media queries
that change CSS rules based on the resolution of the screen.
Frameworks like Bootstrap which we used make massive use of media queries in the CSS. We also
developed a number of classes and IDs in the CSS and further customized the basic Bootstrap CSS to
achieve the results we wanted in our website. Bootstrap in particular creates a grid of 12 columns.
These are dynamically repositioned as the user resizes the window. Here below a number of choices
made and a little discussion for each of them.
Repetition of modules
As a general rule, users do not enjoy having repeated elements in the page at close distance while
scrolling. So when we had to choose how to display the two twitter blocks, we made the choice of
keeping the two blocks in the same row as much as possible (up to ~600px in width). At that
breakpoint, we only display one Twitter block. We used the display:noneproperty to achieve this.
Mobile View Tablet View
19
20. The Heartbeat animation
We previously discussed the use of jQuery for the animation. However, it is important to point out how
we wrote two different animations depending on the width of the window. We first check the width and
then assign the animate()function. The following line is used:
if($(window).width()<=991){
//animationcode
}
We tried to use the jQuery resize()method instead of checking the size on load. It did not work
properly however making the animation look clunky probably due to too many listeners added for the
browser to manage them smoothly.
Frontend Algorithms
Pulling Data from Server
Though JavaScript executes in a synchronous fashion, the getJSON() function -
responsible for accessing data on the web server - is asynchronous. This
required a slight change in coding style, as subsequent actions to be performed
cannot simply be written in a linear fashion. This is because subsequent
actions require the result of the previous step.
Each block of instruction which involves any time-intensive operations such as
I/O or http requests must be wrapped in a function, which are then passed as
callbacks to the function one level higher in the callback pyramid. Doing this
imitates a synchronous workflow. The figure to the left shows the general
workflow for creating the charts, heartbeat animation and map. The exception
here is with the Google map as it is created before the getJSON request is
fired. The last step in this case would be the creation and return of map
elements such as markers and polylines, which are then added to the map.
Without function wrappers and callbacks, the three steps would fire
immediately and result in several ‘undefined’ objects.
Heartbeat Animation
The heartbeat animation requires a few additional step after getting the raw heart rate data in beats per
minute (bpm). Between steps two and three in the previous algorithm:
1. Convert heart rate from bpm to beats per millisecond.
2. Divide the resulting heart rate in beats/ms by 2.
The animation makes use of Microsoft’s Cortana logo, which accepts two parameters. These are the
time taken for expansion and contraction of the logo in milliseconds. By doing the above steps, one
20
21. cycle of expansion and contraction of the logo represents the time between one heartbeat starting and
the next heartbeat starting.
Packages Tree
The figure below shows the directory tree of the entire project, with directories in bold. The public
directory has been separated in the figure, and the node module contents omitted for readability.
.
├── IISNode.yml
├── app.js
├── bin
│ ├── apiCalls.js
│ └── www
├── node_modules
│ ├── async
│ ├── body-parser
│ ├── cookie-parser
│ ├── debug
│ ├── express
│ ├── morgan
│ ├── request
│ └── serve-favicon
├── package.json
├── public
│ ├── css
│ ├── data
│ ├── fonts
│ ├── img
│ ├── index.html
│ └── js
└── web.config
/public
├── index.html
├── css
│ ├── bootstrap-theme.css
│ ├── bootstrap-theme.css.map
│ ├── bootstrap-theme.min.css
│ ├── bootstrap-theme.min.css.map
│ ├── bootstrap.css
│ ├── bootstrap.css.map
│ ├── bootstrap.min.css
│ └── bootstrap.min.css.map
├── data
│ ├── expOneActivityData.json
│ ├── expOneSummaryData.json
│ └── expTwoSummaryData.json
├── fonts
│ ├──
glyphicons-halflings-regular.eot
│ ├──
glyphicons-halflings-regular.svg
│ ├──
glyphicons-halflings-regular.ttf
│ ├──
glyphicons-halflings-regular.woff
│ └──
glyphicons-halflings-regular.woff2
├── img
│ ├── cortana.png
│ ├── diana_award.png
│ ├── favicon.png
│ ├── first_explorer.jpg
│ ├── royal_signals.jpg
│ ├── second_explorer.jpg
│ ├── supported_charities.jpg
│ └── walking_wounded.jpg
└── js
├── bootstrap.js
├── bootstrap.min.js
├── chart.js
├── chartBuilder.js
├── map.js
└── npm.js
The /bin directory contains all executables that associated with the server. www is the script which
runs on initial startup of the server. www uses app.js, as app.js contains the middleware. As www
contains the core functionality of the server, such as normalising ports and setting up listeners for
HTTP server events, apiCalls.jsis imported here. The daily API calls are executed from here.
The public directory contains all the front-end files. As the website consists of only one page,
separating the assets based on file type was sufficient.
21
22. The package.json file specifies all module dependencies for this project, with the web.config file
specifying various parameters needed for hosting a Node.js server on a Microsoft IIS virtual machine.
IISNode.yml file is needed to enable logging of stdout and stderr streams.
Design Patterns
Singleton: Restricting the instantiation of a class to one object. This can be seen with www, where the
single entry-point to initialising the server is with the www script. Through www, app.js is
inherited, in which the middleware is defined. In the front-end, the single point of entry lies
with index.html, from which all other assets are called.
Strategy: Allowing algorithms to vary independently from clients that use it. This can be seen in
apiCalls.js. Though a simple algorithm which firsts generates a new set of tokens and
then requests data, the behaviour can be modified by specifying either a Summary or
Activity call. This is a change in behaviour at design-time by simply changing callType =
summaryCallor activityCall.
Scheduler: Explicitly control when a function is to be executed. In the back-end, this is apparent with
the daily Health API call as defined in www. In the front-end, defer attributes in script tags act
as mini schedulers. Defer was used in loading the Google Map, as the JavaScript file
responsible for this relied on another JavaScript which needed to be loaded first. ‘Defer’
ensured the depency loads first.
Proactor: A design pattern which represents an asynchronous model making use of event handlers.
This can be seen all over the web server as Node.js is entirely asynchronous. An example is
when calling Health APIs. When summary calls are made for two explorers, both are
executed at the same time. The server then writes the response to file for whichever
response arrives first, meaning the thread is not blocked and does not wait for the response
of the first API call. As the single thread is non-blocking, the server is free to carry out other
tasks while waiting for a response.
Composition over inheritance: Though not a design pattern, it is a principle which favors classes
being able to (composition) as opposed to having (inheritance). This
is seen in app.js, where all dependent node modules are ‘require’-ed,
enabling various additional behaviours in the middleware.
Data Format: JavaScript Object Notation (JSON)
This application uses only JSON as the data interchange format. JSON is easy to consume, and
integrates well with JavaScript. Though JavaScript objects and JSON syntax are almost the same,
JSON is slightly more strict. Properties must be enclosed in double quotes in JSON, as opposed to only
requiring quotes if the property contains special characters in JavaScript objects.
Consuming JSON only requires the JSON string to be parsed with JSON.parse(), which results in a
JavaScript object. JavaScript objects are useful as the object can now be used as boolean logic in loop
control flow (e.g. check if object contains certain properties).
As Microsoft Health APIs return data in JSON format, and this application server language chosen to
be JavaScript, JSON was chosen as the data transfer format.
22
23. Analytics
We have implemented three solutions to keep our system continuously monitored putting analytics at
the core of our processes.
- Google Analytics included to measure general user metrics.
- Azure analytics capabilities to track system performance.
- JustGiving API to flag donations coming from our website.
As we previously stated, the conversion rate in this project is conceived as being the number of donors
over the number visitors. We can measure the first with GA and the second with JG.
Google Analytics
We opened a Google Analytics account and included
the snippet of code above the closing headtag.This is
allowing us to receive general user data such as
location or OS. During our testing we noticed that
numerous robots tried to access our website from
various countries we are not located in. As a result, we
decided to password protect our demo site so that it
will not be indexed in any search engine.
Azure Metrics
Azure Web Apps have an integrated metrics platforms
that report on a plethora of different dimensions such
as Average Response Time, CPU Time or Errors. They
are all reported in Average, Minimum and Maximum
and we can choose the level of granularity up to hourly
granularity.
JustGiving
As we discussed previously, the links to the
JustGiving website contain a reference code which is
used in the reporting James will be able to retrieve at
the end of the campaign.
Client Feedback Discussion
Final feedback from demo
23
24. Part Four: Testing
The figure below shows the various activities undertaken when testing the application. Results from
these tests are discussed below.
Localhost Testing
Localhost testing involves testing the
application on a local machine for a
defined period of time to ensure behaviours
function as intended.
1/ GET requests: Checking the console
output whilst a request was made showed
that on a page visit, all GET requests were
pointing to correct file paths.
2/ API Calls testing: The daily RESTful call
to Microsoft Health was tested to verify the
calls were being made and the response
data correctly overwriting the old data.
3/ Browser/device testing: The website
was tested against several browsers
including Google Chrome, Mozilla Firefox
and Internet Explorer [Others?], and
smartphones and tablets. Results are
shown in the screenshots section in the
appendices.
24
25. Live Testing
After deploying via git, live testing can be carried out for the website.
Though git deployment was successful, the website did not function and produced a custom error.
After some research, it was found that servers built with Node.js running on a Microsoft IIS virtual
machine required a web.config with appropriate settings. Sample code was used for this, and this has
been referenced in the source code.
A further change was required to web.config. By default, the server could not handle GET requests for
JSON files. This meant that though the page loaded, charts, map and animation did not populate with
the necessary data. For this, an additional line of code which accounted for the JSON mime type was
added to web.config.
Azure Portal provides a selection of tools for performance monitoring. Of the tools available, one tool
enables live HTTP Traffic monitoring. Though only two metrics are provided (requests and errors), this
can help identify bad requests when used in conjunction with diagnostics logs, which are enabled by
including an IISNode.yml file with appropriate options in the root directory of the server. With this, the
three tests in the local testing phase could be carried out, and all showed expected results.
Test Expedition
As part of live testing, the final product will also be available for a test expedition taking place at the
end of January. One of the explorers will be trekking for three days in Norway and will be using the
Microsoft Band to gather preliminary data. As well as testing the hardware, this will be an opportunity to
see how the system functions in an environment almost identical to its intended application.
Mobile/Desktop Testing
We have tested the website in different browsers and in different
devices of different sizes in order to make sure that the user
experience was consistent on all devices. We used BrowserStack
for automated testing on various operating systems and browsers.
The experienced looked consistent throughout our testing (the
screenshots are provided in the appendix).
The only exception is for Windows PCs running IE 8 or
earlier (see screenshot on the left). In particular, both our
JavaScript objects (the map and the graphs), do not1
support these versions of IE. jQuery , used for the2
animation, does not either. However, the share of IE 8 and
earlier users is very low (<4% as of November 2015) . We3
can, therefore, state that we provide a consistent
cross-environment experience.
1
https://developers.google.com/maps/documentation/javascript/browsersupport?hl=en
2
https://jquery.com/browser-support/
3
http://www.sitepoint.com/browser-trends-january-2015-ie8-usage-triples/
25
26. Part Five: Readings and
References
Design Patterns
- DRY Programming Principle(Used in Chart JS for global configuration)
Frontend
UI Metro Framework
- Swiss Style:
www.smashingmagazine.com/2009/07/lessons-from-swiss-style-graphic-design/
#
- Metro UI CSS 3.0 https://metroui.org.ua/
- How to use the UI metro Framework
- https://www.youtube.com/watch?v=R5nb73GGIwk
- https://www.youtube.com/watch?v=4PeP_bZOSDw
- https://www.youtube.com/watch?v=0S7bEacE_rY
CSS3 and HTML5
- Lynda and code academy (links)
- Anchors/jump in page: https://www.youtube.com/watch?v=ATt70kSDrVc
- Button that links to a website
- Create a grid system https://www.youtube.com/watch?v=zln7HaX-NBw
- Putting images next to each other / side by side for the
teamhttp://stackoverflow.com/questions/16260485/how-to-put-an-image-next-to-
each-other/ http://techwelkin.com/how-to-arrange-three-or-many-divs-side-by-side
- Create extra space on the left for the charts
http://stackoverflow.com/questions/24377228/why-do-i-have-extra-white-space-o
n-the-left-side-of-my-page-below-the-logo
Google Maps API
26
27. - Google documentation
https://developers.google.com/maps/documentation/javascript/
StackOverflow
- Posted 5 questions
- Make the Google Map static
http://stackoverflow.com/questions/34275690/google-maps-api-v3-on-websi
te-zooms-in-the-map-when-i-scroll-down-instead-of-goi?noredirect=1#comme
nt56293804_34275690
- Markers and Polylines in Google maps
http://stackoverflow.com/questions/34202588/google-maps-v3-markers-and-
polylines-not-rendering-what-is-wrong-with-my-code
- Leaflet polyline
http://stackoverflow.com/questions/34181547/in-leaflet-how-to-draw-a-polyli
ne-between-several-points
- API key of Google Maps v3
http://stackoverflow.com/questions/34183754/google-map-api-v3-example-fr
om-their-site-doesnt-work-without-an-api-key-but-do
- How to add left padding to charts using ChartJS
http://stackoverflow.com/questions/34278347/how-to-add-left-padding-for-m
y-charts-done-in-chartjs-and-my-google-map-so-it-is
Charts
- Google Charts https://developers.google.com/chart/?hl=en
- Charts.js http://www.chartjs.org/
Javascript
- Code Academy course as well as Lynda.com with Ray VIllalobos (link)
- Eloquent JavaScriptby Marijn Haverbeke
- JavaScript Functions by Ray Villalobos (Lynda.com).
Backend
JSON and data communications:
- Lynda.com: JavaScript and JSON with Ray Villalobos
Node and Networking:
- Lynda.com: Node.js Essential Training with Alex Banks
- Understanding Express framework http://evanhahn.com/understandingexpress/
- https://www.safaribooksonline.com/blog/2014/03/10/expressjsmiddlewaredemystif
ied/
- PHP vs Node.js
http://www.hostingadvice.com/blog/comparingnodejsvsphpperformance/
- Node.js Documentation https://nodejs.org/api/
- Express Documentation http://expressjs.com/en/4x/api.html
- Express Viewing Engine Performance
https://strongloop.com/strongblog/bypassingexpressviewrenderingforspeedand
modularity/
Microsoft Azure and Cloud Computing:
- Azure, Node.js Development Center
- Lynda.com: Understanding Microsoft Azure Core Functionalities with David Elfasy
27
