Catalogues

A small part of a larger system for managing operator data

Catalogues is the absolute core of the operator management system (OMS) we designed and developed at ACT. But it had been neglected for a few years due to a series of reasons and was in need of a lot of love and attention. Working closely with the PM and a developer, I set about understanding what catalogues does, who uses it and what we can do to fix it.

Due to the reputation catalogues had gained amongst the dev team, a dark box whispered about in hushed tones for only a few knew the inner workings, I started on this project with very little knowledge and understanding of how it functioned and how it needed to. Through several conversations with the PM it quickly became clear that this would be a longer process than I had initially thought, which both excited and terrified me but mainly got me thinking.

We started by working out what the sections would need to be and how they would link together. We also wanted it to require as little developer help as possible when setting up a scheme. The flow diagram for this shows a simple version on the complexity of the system.

Designs for creating a bus service.

Transport Locations

The first step to design became Transport Locations, this section is where operators could manage the stops in their scheme. This could include adding new stops, changing locations of stops due to road works and removing older stops.

Initial designs meant a user had to upload the stops they wanted in their scheme, which was pointed out would be unmanageable. Think about a city, doesn’t need to be a big one, but any city will do. Now think about how many times a single bus stops when you are on it. Starting to see the issue? A City will have thousands if not tens of thousands of stops and that number grows the more modes of transport you add. So we went back to the drawing board and did some more research, in which we discovered we could get access to every stops location in the country from a government service.

This service meant we could keep a ‘global’ copy of stops and update it for all schemes regularly. But we would need to keep the add, edit and delete features to ensure the users could manage stops before the government service (which takes time to get updated). With the PM’s approval and support from the developer, we were ready to move on to the next section.
Series of images detailing different stages of setting up transport locations.

Location Groups

Location Groups started life as Zones, but we needed to expand the functionality to cover different kind of location grouping, such as stations and fare stages. As with Transport Locations we needed this section to be as straight forward as possible, so that almost anyone could use it. To this end we decided to put all the different kinds of groups in one place.

Using a fairly simple form to set the type of group, name, start/end dates and then a slightly more interactive design to add the stops in the group. Given the high number of stops available, the first thing to do was include a search option from which they could find the individual stops they wanted to include in the group. Depending on the type of group the order can be important, for which we have an option for reordering. Much of the system is tables and data display so filtering, sorting and searching are important elements we have tried to include on every large data set.
Series of screens detailing steps for creating a Location Group.

Services

This is where things start to come together into an actual bus service, a culmination of all the other sections to form the behind the scenes data for a bus. In the exact same way the other sections handle it, we wanted to give the users an explanation of what this is and how it works. It was also important to allow users to upload a file of their services to speed up the process.

The core features for this section were set before we even began looking but how we handled getting to them. The first draft had all of the features in one continuous list, this was quickly discarded as it became unmanageable. The next option was to split the features up into tabs, this allowed for much more focused data input and allowed up to design it to be modular. The other advantage of this style is that, a user can save the data, leave and then come back at a later point to finish.

The primary challenge on this section was working out how to display fares, there are many different types of fares and fare pricing. Flat fares, point to point and zonal tickets are just a small number of them and each require a slightly different way to input the prices. To handle this it was decided we should split ticket pricing up to be across two areas, location based fares would be handled on the Services section and others such as flat fare would be handled on the Ticket section. While it was not the most ideal or elegant solution it did enable to design ‘global’ fares that can be set up in one place and applied to multiple services.
Designs for creating a bus service.

Tickets

The last section but one of the most important, after all you can’t travel if you don’t have a ticket, the ‘No ticket’ scene in Indiana Jones comes to mind. But this section needed to be capable of dealing with a large number of ticket types. Like the rest of this project we were under prepared for how many different tickets there can be. So we began this part by pulling all the different tickets we currently had in the system and filtering them down to the most basic components. From these components we began to design a form that would adapt and change depending on the type of ticket the user was trying to make.

As I said in the previous section we needed it to be able to do ‘global’ tickets that can applied to multiple services and service specific tickets. To achieve this we created ticket groups which a user could add specific tickets to, name and manage. The thought was this would make it easier to manage the tickets, for example if you needed to change some details to all Adult tickets; whether it the price or end dates, groups would allow a quicker way to manage them.

A key requirement for this section was the creation of concession or discounted tickets and fares such as student or age related discounts. We quickly realised we should avoid having to create whole discount tickets (as in the old system) and instead should have variants on individual tickets, which then reduce the price of the original fare by a set amount. To do this we added an extra part to the bottom for adding discounts as needed. This part would offer a dropdown for how the discount would be calculated, for example a percentage of the fare or a flat reduction.
Designs for creating a bus service.

Next Steps

The last section but one of the most important, after all you can’t travel if you don’t have a ticket, the ‘No ticket’ scene in Indiana Jones comes to mind. But this section needed to be capable of dealing with a large number of ticket types. Like the rest of this project we were under prepared for how many different tickets there can be. So we began this part by pulling all the different tickets we currently had in the system and filtering them down to the most basic components. From these components we began to design a form that would adapt and change depending on the type of ticket the user was trying to make.

As I said in the previous section we needed it to be able to do ‘global’ tickets that can applied to multiple services and service specific tickets. To achieve this we created ticket groups which a user could add specific tickets to, name and manage. The thought was this would make it easier to manage the tickets, for example if you needed to change some details to all Adult tickets; whether it the price or end dates, groups would allow a quicker way to manage them.

A key requirement for this section was the creation of concession or discounted tickets and fares such as student or age related discounts. We quickly realised we should avoid having to create whole discount tickets (as in the old system) and instead should have variants on individual tickets, which then reduce the price of the original fare by a set amount. To do this we added an extra part to the bottom for adding discounts as needed. This part would offer a dropdown for how the discount would be calculated, for example a percentage of the fare or a flat reduction.