Streamlined Workflow – Adding a ton of customization and interactivity
Written by: TheDevBird
In Airwave, the two most-import elements (aside from the radar) are the stripboard and the frequency selector. It is imperative that both elements help streamline a controller's workflow, rather than hinder it. There were two major issues with both: The worst out of the two was the stripboard, being fully automatic with no user involvement. Secondly, the frequency selector was badly designed, frequently resetting standby frequency or not working at all.
Having kept these “legacy” components the same despite rapid growth in other sectors of Airwave, we wanted to dive deep into the interface so they could better match the depth of the game itself.
Real Stripboards
In the real world, stripboards are vertical columns with plastic strip holders. These strip holders hold paper flight strips denoting the callsign, departure and arrival, and other key details of a flight. Within a stripboard, header strips are commonly used to separate the strips in a column. For example, for an approach controller, they might have headers for the active runways and place flight strips under the designated header for the runway that they were cleared to land on.
But it is up to the controller how they manage their strips. Real-world boards are fully customizable, from the header positions, content, and where the strips fall within those headers.
The New Stripboard
Before this change, the stripboard in Airwave was organized automatically. All strips and headers were fixed, sorted by internal logic such as distance and status. We were pretty happy with the auto-stripboard as it took away an extra loop we needed to consider. Keeping things sorted automatically meant that we could use the stripboard as a status panel rather than a method of custom organization.
The Auto Stripboard:
We wanted more.
Funny enough, the first iteration of the stripboard, way back in the first month of developing Airwave, was draggable. You could move strips within the board, under any header you choose. We ended up moving away from that as the complexity of Airwave grew, forcing us to focus on other parts of the game rather than investing more into the customization and workflow of the stripboard.
The OG Stripboard:
But now it's back! The newest iteration of the stripboard is fully customizable and organizable. Here is a list of the new features:
- Drag to move strips and headers wherever you'd like
- Edit the title of headers, allowing you to change “Landing” to “Landing 23R” or even use one as a reminder, such as “Approach is 123.4”
- Add and remove header strips
- Remove or clear flight strips that are no longer your responsibility
- Control what segments of flight the stripboard will create flight strips (e.g.: just Approach and Departure)
Drag 'n' Drop!
Making the stripboard closer to the behavior its real-world counterpart started with adding the ability to reorder strips as one pleases. Our first part of this change came with refactoring the existing code to add a unified strip component to display headers and flight strips in the same flat list.
Next, we had to reimplement the drag-and-drop logic from the manual stripboard we had in the early days. SolidJS, the framework we use for the Airwave client, has very specific rules for editing a list of data to ensure that it reacts to changes properly in the rendering step. So after adding interactivity to the order of the strips, we had to find an elegant solution to keep track of the state and also persist it across sessions.
A Mini-Problem
While rewriting the stripboard from being automatic to a manual system, we noticed one glaring issue: How will the stripboard know when to create strips?
With the automatic design, strips would be placed in their designated sections. Though the sections would be the same for all players, they could be collapsed to hide flights you don't need to keep watch over. But in a manual design, we had to account for the logic behind categorizing strips.
How would the stripboard know if you're a single player who needs to know about both air and ground strips, or a player of many who only cares about ground strips? Our first idea was to implement this as a multi-select dropdown where the user could select what kind of controller they were. This would work well, though it would abstract away the underlying logic: how we determine if a flight should be a strip or not.
So, we went with a similar solution: Show a multi-select list of statuses such as approach, landing, taxiing, etc (we call them “segments of flight”). With our recent addition of a segmentation system to interpret which segment of flight an aircraft is in, we could simply use those same segments in the stripboard to assert the category of a strip. A controller could select just “Approach” and “Departure” in the create options of the stripboard, where strips would be created for all aircraft in the approach or departure phase for the controller's airport/airspace.
Note: This is a barebones UI that will be polished later on as we finalize the design of the stripboard.
Tons of Customization
Now, with the new stripboard, one could be a single player controlling all of their airport and airspace, or just an approach controller in a multiplayer session, and still use the same underlying framework.
With the ability to customize headers, move strips, and adjust strip creation options, the new stripboard should work with every kind of player and controller. Of course, if it doesn't, please let us know (join our Discord)!
Honorable Mention
Oh, and we shouldn't forget about the new frequency selector panel! We have also fully redesigned it to fit all use cases. Instead of swapping between a hot and standby frequency, you can now access up to ten total channels. But, if you don't need all of those channels, you can set the number of channels you'd like to see, even though they're still accessible with shortcuts. This new design allows you to limit the panel to just one slot, for casual gameplay, or add many more slots to suit a fast-paced workflow.
Though we don't expect you to use all ten channels, they're there if you need them (and because the number row on your keyboard has ten total keys)!
Scalability
Scalability is a core design goal of Airwave. Whether it's a single person managing a casual session, or many players in a multi-airport scenario, we want to support it all! I hope you join us in our journey to create an air traffic control simulation game that's built for the casual player to the seasoned controller.
We'll see you in the next blog post!
Also, we have a Discord server now. Feel free to pop in and say hello!
Airwave is open-source and available on GitHub.
For questions or feedback, feel free to reach out on Bluesky, on our Discord server, or via email: [email protected].