Autodesk Dashboard Project
Requirements Specification of the Dashboard
The purpose of the Dashboard was to provide rich
infographics that enhances productivity of Engineering Operations Engineers,
compiled in a web dashboard compatible in most screens including PC monitors
and TV displays. The information to be included in this infographics includes a
summary of Service-Now tickets an even JIRA Sprint Burndown chart.
Features supported in this Operation Dashboard should not
overlap other existing Dashboard (e.g. dashboard.autodesk.com) that covers deep
technical and executive aspects of various applications used by the Engineering
Operations.
Operations Dashboard does not need to support mobile however
would be a good plus.
Operations Dashboard will support rotation of multiple
dashboards to avoid clutters.
Overview of Dashboard
Operations Dashboard consists of pages of individual
dashboards to avoid clutters in individual page. In general:
·
Main Dashboard - page where most of the features
will be displayed
·
Pictures Dashboard – page where PowerPoint
slides (exported as pictures) will be displayed along with [AN2]
·
Video Dashboard – page where highlight video
will be played with certain interval alternating with Main and Slides Dashboard
·
Admin Page – page where administrator is able to
configure each team dashboard, and provide announcements.
Main Dashboard
The main dashboard will consist of the following features:
·
Date, time and weather
·
Autodesk Stock Price
·
Team and organization upcoming event
·
Announcement and team reminders
·
Autodesk Service-Now Essentials and Statistics
·
Applications and servers reachability
Each feature will be described in the next section.
Picture and video dashboard
The picture and video dashboard will be of the same size as
the Main Dashboard. Its main purpose will be to display the pictures and video
highlight specified by the Dashboards Administrator. Operations Dashboard will
display any PowerPoint (exported as pictures) and video file from the
administrator with minimum supervision. Administrator will be able to set
interval where when dashboards will alternate.
Features
There are numbers of features that will be supported by
Operations Dashboard, with functionality and looks depends on the following
grounds:
1.
Operations Dashboard will support will support
different set of information for each team in Engineering Operations;
infographics for one team might not be relevant to other team, hence this
dashboard will be configurable depending on needs.
2.
Following (1), this dashboard will be displayed
on several TV displays across team seating areas.
3.
Following (2), this dashboard should be visible
and clear from the furthest member seat.
Common Features
Date, Time and Weather
·
Display
current day, date and time.
·
Display
current weather.
Autodesk Stock Price
·
Tile
1 – display current Autodesk Stock Price and the change.
·
Tile
2 – display Autodesk Stock Price graph changes, duration set to 1 month.
·
This
widget will alternate after certain duration.
Team/Organization Event
·
Display
Today’s event – only display hour, place and duration, without description. As description
could be lengthy, and available on Outlook for full description.
·
If no
event today, display upcoming events – only display day, date, time and
location. No duration and description, as these are lengthy and available on
Outlook.
·
This
widget will alternate if there is more than one upcoming events with similar
duration (week).
·
Events
to be added via admin console manually.
Announcement and Team Reminders
·
Announcement
will take priority for display. This info is provided by administrator. For
example: Network outage and maintenance, Autobucks winners.
·
If no
announcement is provided, team reminders will be displayed. For example:
service account password reset, Employee engagement survey, etc.
·
This
widget will alternate after certain period, with Announcement as the main
priority.
·
Important
announcements can be configured to have flashing background colors; especially
important for grabbing attention on key announcements like network outages.
Autodesk Service-Now Infographics
·
This
widget will rotates when no critical AR (both request and incident) is found.
If there is an outstanding critical AR, the widget stalls at critical section
and lights to give more focus.
·
There
are 2 5 information displayed in this widget:
·
Critical
requests and incidents,
·
Unassigned
requests and incidents,
·
This
is extendable to support JIRA/TFS task.
Applications and Servers
Reachability
·
This
widget provides information regarding reachability of applications and network
servers in terms of latency, depending on current team.
·
Tile
1 will include Applications, such as common electric commander, build forge,
subdoc server, and other tools.
o
Applications
Servers that runs applications as services should be displayed in two forms
(whenever applicable)
§ Server Reachability
§ Service Availability
·
Tile
2 will cover Network Servers, such as HERON, BOBCAT, PANDA, TAKIN, etc.
·
This
widget will alternate after certain period.
·
Unreachable
item will be displayed with no bar in the graph, to let it stand out.
·
Certain
key application or server stats may be displayed using one widget (instead of
combined)
Other Operational
Statistics
Enterprise Cloud
Services, information like
·
Current
VM and Storage Usage
Key Network Storage
Usage
Changes
in requirements
After further reviewing, instead of having only one
Operations Dashboard, we need to have multiple Operations Dashboard in which we
can configure different setting on what to show for each of the dashboards.
Each of these Operations Dashboard will be defined as a Dashboard Server. With
their own settings.
We also need to have an Admin website where we can:
·
Change the settings for each of these Dashboard
Servers.
·
Create or Delete a Dashboard Server as and when
we need to.
·
Start and Stop a Dashboard Server
·
Update a Dashboard Server from an updated
template.
Chapter Three – System
Structure of the System
As seen in Figure 1, the Admin Server will be controlling
multiple dashboards where it can, start/stop a Dashboard Server, create or
delete a dashboard server, change the files in the dashboards in each of the
Dashboard Servers and even change its configurations (e.g. source folder for
all the images). Each of these Dashboard Servers will be hosting their own
array of Dashboards where it will be displayed on the monitors. The Admin
Website will be hosted by the Admin Server to act as an interface to control
the different Dashboard Servers.
Dashboard Servers
Components
The Dashboard Servers is based on dashing.io and consists of
multiple Dashboards in which each dashboard will have their own sets of
dashboards. As stated in the requirements, the Dashboard Server consists of:
·
Assets – necessary web artifacts, such as fonts,
images, and front-end scripts
·
Dashboard – A single entity where it’s layout is
defined by an embedded ruby file and can contain multiple widgets
·
Jobs – Ruby based script to fetch data from
respective sources.
·
Lib – utility files and libraries based on Ruby
·
Public – standard pages for static information,
such as error messages
·
Widgets – web UI script for each dashboard
feature
Data flow – From sources to widget display
The structure of the Dashboard Server can be seen in Figure
2. The jobs are responsible for getting the data from their respective sources.
In this system, it will call a method in the admin server to store update the
database with its respective data. It will then fetch the data from the
database to be sent to different widgets. These data are tagged with data-ids
so as to ensure that only those widgets that needs these data will receive it.
These widgets will then display its respective data on the dashboard as seen in
Figure 3.
There are some data that requires constant update to loop
through different information. For example, the service now tickets contains
more than one ticket and we cannot display all of them at once. However, we
also do not one to keep fetching different data every three seconds. The jobs
will fetch all of the data and store them as a model objects first (as seen in
figure 2) and thus send different ticket data to the widget every ten seconds.
Certain data are not straight forward and requires
manipulation by the widget before it can be displayed. For example, the JIRA
Sprint Burndown Chart. There is no API that can help give the exact points on
the graph to be displayed, instead it gives us the changes made on different
dates. Thus, to get the points needed, we need to calculate from the data, the
exact points of the graph.
The media widget, was designed to display both images and
widgets and also resize the image to suit the size of the widget itself. Thus,
the jobs only need to send the location of the image or video to the widget.
Configurations and job attributes
The Dashboard Server configurations are stored in a text
file which hold its port number, id and name. It is important to have these
configurations as it needs to use this to be identified or identify a certain
database as we cannot hard code it into the codes as multiple dashboards will
be sharing the same codes for easy creation of newer Dashboard Servers.
For the jobs in the Dashboard Servers, each of them will
hold their own job attributes. This is to enable easy configuration of the data
to be displayed on the dashboard. For example, if we want to display the photos
from another folder, we would only need to change the source folder in this
file.
Active widget updates
The jobs their own requests which will automatically update
their data upon a call of these requests – push to update. When these requests
are called, they will pull their data from their respective sources and thus
update the data on the widgets or model data objects.
Admin
Server/Website
Starting and stopping a Dashboard Server
You are able to start or stop a dashboard folder through the
website itself. To start the server, we just call the command line to run the
Dashboard Servers ruby script called start.rb. Each of the Dashboard Severs have
their own ruby script to run to start the server.
When we click the start button, the website will send a
request to the server along with the dashboard server name to start a server.
Using the Dashboard Server Name, it locates the Dashboard Server Folder and
then runs start.rb.
Once started, the Dashboard Server will write down its
process id in the file called service.txt. When stopping the dashboard server,
the Admin Server will just look up this text file using the Dashboard Server
name to get the process id it is currently running on. It then kills the
process with the process id.
Creating, removing and updating a dashboard server
There will be a template dashboard server where it is used
to create a new Dashboard Server by simply copying and pasting it into the
Dashboard Servers Folder called the ‘Operations Dashboard’. The Dashboard
Server can also be removed by simply clicking the delete button. Where it will
execute a command to remove the entire folder.
Any changes made to the Template Dashboard Server can be
applied to an existing Dashboard Server by simply clicking on the update
button. The admin server will only replace the files that are critical such as
the widgets, jobs and CSS files. The database and layout remains untouched. You
could also set that dashboard itself as a template by clicking set template.
This will copy the entire folder and replace the contents of the Template
Dashboard Server.
Announcement Alert
The announcement alert is an alert that will display an
urgent announcement across all dashboards when the admin enters it in the
announcement alert panel as seen in Figure 4. Only one announcement can exist
at one time and the alert is displayed as seen in Figure 5.
As for now, this display works by constantly checking if an
announcement alert has been made. A push pull configuration is not possible due
to the Dashing.io configuration.
Manipulating Dashboard files
Using Nokogiri, a ruby library that enables manipulation of
html files including embedded ruby files, we can easily change the contents of
the file in whatever way we want. In the Dashboard files in particular, we can
extract the widgets that are included in the selected dashboard file and change
its contents at will. We can even add or delete a new widget to the Dashboard
file. Other uses include changing the duration of the Dashboard sequence before
rotating to the next Dashboard. All of the methods to manipulate a dashboard
file are included in the DashboardHtmlTools class. The methods include:
·
Get next Dashboard
·
Set next Dashboard
·
Get Widgets
·
Get number of Widgets
·
Edit Widget
·
Delete Widget
·
Add Widget
·
Create Dashboard file
Dashboard Maker
The dashboard maker is used to provide a rich UI to help the
user visualize and create, or edit a Dashboard in a Dashboard Server as seen in
Figure 6. You can add a widget by clicking the add widget button and give it a
data id - used to identify where the data is coming from, the widget view – the
widget which can be found in the widgets folder, and the colour of the widget
itself.
You can then drag and drop the widget to the desired position
you want it to be at and stretch it to the size you would like. Once finished,
the Dashboard will take the data of each of these widgets and the Dashboard
itself and send it as a JSON to the admin server. From there, the Admin Server
will use the DashboardHtmlTools class to automatically make the changes or
creation respectively.
0 comments:
Post a Comment