SpaceX Dashboard | SpaceX REST API, dc.js, crossfilter, Google Maps JS API
This project aims to display data from the SpaceX API in an accessible, informative and interactive format.
Site Objectives:
User Needs:
The target audience is SpaceX and space enthusiasts. Users should be able to:
The following Opportunities/Problems table was used to determine which strategic priorities the UX efforts should address (in this order):
| Opportunity/Problem | Importance | Viability/Feasibility |
|---|---|---|
| A. Display launch and payload data to the user | 5 | 5 |
| B. Allow interactive filtering of data | 5 | 5 |
| C. Display underlying filtered data in a table | 4 | 5 |
| D. Promote interest in SpaceX’s future activities | 3 | 3 |
In considering the functional specifications, I researched existing graphical implementations of the SpaceX API. There is a vast array of data available from SpaceX (13 different endpoints), so it was important to scope in only the most engaging and interesting insights, while at the same time ensuring the data was also accessible to users with only minimal knowledge of SpaceX. Dashboards by their nature can (if implemented poorly) cognitively overload the user, making the functional scope a key consideration.
Feature Set:
In order to provide the value of the above features, the following content is required:
The strategic goals of the site rests largely on the user’s willingness to interact with the charts and data table. The advantage of a dashboard is being able to view many different dimensions or views of a dataset at the same time. To this end, a single-page structure was selected as most appropriate. For example, on desktop screen sizes, this structure allows all four charts in the Launch Explorer section to be viewed at once. The user is able to see the effects their filtering has to all four charts at once. For mobile and tablet screens, the navigation bar collapses into a toggler to allow jumping to each section. A ‘Reset’ button is provided which allows a convenient way to reset filters on all charts.
Consistency & Predictability:
Icons were used to give visual cues as to what the section was about:
Launch Explorer - rocket flying icon, Next Launch - rocket on launch pad icon, Payload Analysis - satellite icon.
Feedback:
Given the many possible interactions available to the user on the site, the following feedback mechanisms were employed to encourage as much interaction as possible:
The organising principle and order of the content is structured to ensure the user understands and engages with each chart and section.
The easiest chart to understand - ‘Launches by Rocket’ - is located at the top left of the page where the eye will naturally land first. The next chart - ‘Launch Success’ features simple, intuitive two bar chart - green: success, red: failure. Once this foundational understanding is achieved, the user can see that the colours representing the rocket names are synchronised across the next 2 charts - ‘Launches by Year’ and ‘Launches by Site’.
Similarly, in the Payload Analysis dashboard, the most basic chart ‘Payloads by Type’ is presented first, followed by ‘Payloads by Orbit’, then ‘Payloads by Manufacturer’.
Two sets of wireframes were created in the early development stage to help set out the content and layout in differing device sizes.
Colours: A dark colour theme was employed to give the user a sense of outer space.
Fonts: A futuristic typeface was employed consistently for all text to convey a futuristic, exciting nature of spaceflight.
User stories:
How the needs are met:
Potential Feature 1 - A section called Landing Explorer which uses the Landings API endpoint (https://api.spacexdata.com/v3/landpads). This would be a stacked bar chart showing the success/failure of landing attempts for each landing pad
Potential Feature 2 - A link in data table to show a gallery of pictures from each launch (source image links available in the Launches API)
Extensive manual testing was conducted to ensure the site functions and looks well on all major browsers (Chrome, Firefox, Safari, Edge) and device sizes.
The following manual tests passed:
| Test No. | Test Name | Result |
|---|---|---|
| 1 | Launch and payload dashboard can be filtered and unfiltered on graph segment click | PASS |
| 2 | Any filter applied within a dashboard group updates all other graphs in that dashboard group (ie in Launches or Payloads groups) | PASS |
| 3 | Reset buttons reset filters of all graphs in dashboard | PASS |
| 4 | All charts are appropriately sized for each device (Mobile, Desktop) | PASS |
| 5 | All navigation links smooth scroll to correct section | PASS |
| 6 | All text is readable and appropriate size | PASS |
| 7 | All external links work and open in new window (target=”_blank”) | PASS |
| 8 | ‘Add Launch to Calendar’ button fires with correct parameters | PASS |
| 9 | Forward and Back browser buttons aren’t required, but if used don’t cause breaks | PASS |
| 10 | Page and graphs do not take excessive time to load and render | PASS |
The following tests failed:
| Issue No. | Test Name | Result | Issue | Resolution |
|---|---|---|---|---|
| 1 | Data table readable on all devices | FAIL | On mobile devices, data table text was too large, causing table to extend horizontally beyond the viewport. | Font-size was decreased and table element was wrapped in a Bootstrap class ‘table-responsive’ which allows horizontal scrolling |
| 2 | Charts appropriately sized for each device (Tablet) | FAIL | Payload graphs were taking up too much vertical space on a tablet. This was bad UX because the user couldn’t see the effect filtering one chart had on the others | This was corrected by using bootstrap responsive column sizing combined with column offsets. |
| 3 | No excessive amounts of text | FAIL | Next mission detail text was too long, hindering the key takeaway from the section. | This text was collapsed behind a ‘Show Details’ link, which can be expanded if the user wants to see this detail. |
Code Validation
| Code | Result |
|---|---|
CSS (W3C)|PASS|
HTML (W3C)|PASS|
JavaScript with no major errors (jshint)|PASS|
The site was deployed on GitHub Pages, by following the below steps:
The underlying data for all charts is sourced from the SpaceX API, using the following endpoints:
The ‘Add to Calendar’ functionality in the ‘Next Launch’ section was sourced from: https://www.addevent.com/add-to-calendar-button
The JavaScript controlling the Countdown to Next Launch was sourced from: https://www.w3schools.com/howto/tryit.asp?filename=tryhow_js_countdown
The pagination of the data table in the ‘Launch Explorer’ section was sourced from: https://github.com/dc-js/dc.js/blob/master/web/examples/table-pagination.html
Favicon rocket icon source: http://www.iconarchive.com/show/captiva-icons-by-bokehlicia/rocket-icon.html
The ‘Print Filter’ function was used extensively in ensuring correct dc.js dimensions and groups were achieved from the Crossfilter: https://gist.github.com/xhinking/9341806
Images of the mission patches, launches and the Tesla Roadster were sourced from the SpaceX API.
Thanks to my mentor, Brian M, for his helpful feedback. And thanks to family and friends for helping with UX testing.