Building a maps platform for the public service

Adam Shubat
Ontario Digital Service
5 min readSep 21, 2017

We know that, when you’re looking for information about government services, a map is often the best way to find the information you need. When it comes to searching for employment and training services, FEATS is one of the maps that people turn to.

Until its recent re-launch a few weeks ago, the Finding Employment and Training Services (FEATS) map was a Java-based, API driven tool for finding employment and training services on a map near you. Users entered location data into fields, clicked search, and then were presented with a map based on the criteria entered into the form.

Screenshot of the previous FEATS tool.

Until recently, the FEATS tool did the job well, but had a few issues:

  1. You always had to go back to the search form, fill out fields and click the search button every time you wanted to tweak your query, making it a bit cumbersome to our users.
  2. Operational costs were getting to be more expensive.
  3. It was hosted with a third-party vendor, meaning we didn’t have complete autonomy over the updates.

When we were given an opportunity to work with the Ministry of Advanced Education and Skills Development (MAESD) on re-thinking FEATS, we also noticed one other area for improvement that had resonance across everything we do on Ontario.ca: the FEATS map was a product, not a platform.

As the technical team in the Ontario Digital Service worked with the MAESD team, we noticed that the FEATS tool could only do one thing: it only served maps related to employment and training services. We know that programs across the government need to use maps to better convey information to Ontarians — a one-off product approach didn’t seem effective.

When mapping needs arise, we should be capable of delivering solutions quickly because the work in advance has already been done. We can’t accomplish this with a one-time product; we needed a platform that was capable of showing maps with any kind of information, not just employment and training services. The team at MAESD was enthusiastic about this approach, so we began the research to find out how to make this happen.

Enter Drupal 8

As we were searching for a capable platform, we were looking for two things:

  1. We needed a content management system to manage our location data, user accounts, roles and permissions, reports, and configurations.
  2. We needed a system that had an API to be able to talk to other systems.

We found what we were looking for in Drupal 8, an API-first content management system.

What it meant to be API-first was that anything that can be done in Drupal can be performed by other systems with its Representational State Transfer (REST) API. Everything, from creating user accounts to viewing the error log or tweaking configurations, can all be done with the API.

We’ve been using Drupal for a while, but hadn’t explored this use of it before.

This has made implementing the solution to this project incredibly easy. The basic gist of creating the platform and setting up FEATS was:

  1. Download and install Drupal 8.
  2. Download and install the JSON API module.
  3. Create a content type called “FEATS” that matches all the fields of their data.

It was that easy! Whenever a new piece of FEATS content is created, the JSON API module automatically has an endpoint for it that looks like this:

Whenever a new piece of FEATS content is created, the JSON API module automatically has an endpoint for it that looks like this.

Now that any internet-connected device or system could communicate with our new platform, we used Ontario.ca’s front-end (built in Angular) to connect to it and render this data as maps on web pages. (Huge kudos to our front-end developers, Taylor Najjar and Andrew Wang, for building the FEATS front-end.)

With the new setup, users are immediately presented with a map and can optionally share their location to automatically center the map to where they are. Adjustments to queries are done on the fly, making the overall experience of finding what the user needs much smoother, and gets the right information to Ontarians faster and easier.

Down the road, when other government program areas need to create their own maps to serve, we will be ready. We no longer have to create custom, one-off maps that can be difficult to maintain. We now have a platform that can easily manage location data in a consistent way.

Screenshot from the new FEATS map and service.

Translating business needs into technical requirements

In the past, it wouldn’t be surprising if a project like the FEATS map refresh would come to the technology team in the form of a (sometimes-vague) ticket in our ticket-tracking system. This could often mean that the team would have to make assumptions on the requirements, and this would make it hard to project timelines as requirements could often shift during the project.

For the FEATS project, we had the chance to work with the great team at MAESD and do things a little differently. Early in the process, our release manager, Ian Ferguson, held a project kick-off meeting with everyone involved in the project. We worked with the team at MAESD to understand their business needs, and translated each one of them to individual tickets under the new project. We then assigned a complexity score to each ticket; if a ticket had too high of a complexity score, we broke it down into smaller tickets. Each ticket was tagged (e.g.: “front-end,” “back-end,” “security,” “content”) which helped us quickly assess what resources would be required. Once everything was ticketed, we prioritized the work and organized it all into weekly sprints.

Very quickly, we had a pretty good idea of what it would take and how long it would take to build the new platform. As the project progressed, we saw issues early and were able to address them, within our team and with the team at MAESD, before they became larger problems. Morale and velocity were high — and we knew that this was a way we’d like to work on future projects as well.

Learning as we build

The FEATS project taught us — or, at least, reminded us of — two important things:

  • Sometimes, doing the work in advance to build a platform, something that can be used and re-used, will save us time and effort in the future and make things better for all our Ministry partners as well as Ontarians looking for government information.
  • We should look to see if others around us are doing similar things, and work together to consolidate our efforts to make the work better. If we dedicate resources toward a common goal in a truly agile fashion, we are not only rewarded with stable and robust platforms, but a better work environment as well.

You can visit the new FEATS map and service here. Huge thanks to the team at MAESD for joining us on this journey. Let us know what you think!

Adam Shubat is a developer with the Ontario Digital Service.

--

--