Scheduling Wizard & Schedule Board: Modernizing Aptora’s Dispatch UI

Starting Point: A Monolithic Schedule Board

The existing schedule board was feature-rich but difficult to evolve. Most of the UI and logic lived in a single, oversized WPF window with heavy code-behind:

• One large XAML file controlling a complex grid of technicians, time slots, and work orders.
• Business logic, view logic, and UI behavior intertwined in event handlers spread throughout the code-behind.
• Slow design-time performance—just opening the file in Visual Studio could take close to a minute.

Changes required a lot of care and context. Adding new behavior meant navigating a large, shared file and reasoning about many interactions at once. It needed a more modular, testable architecture to support future growth.

Scheduling Wizard: Guided, Skill- and ETA-Aware Dispatch

The new Scheduling Wizard sits alongside the Schedule Board and walks dispatchers through a step-by-step process to create work orders and assign one or more technicians. Each step validates input and only enables the "Next" button when the required data is present.

Dispatchers can use the wizard to either schedule multiple unscheduled work orders in batch or create and schedule a new work order from scratch—without leaving the board.

Scheduling Algorithm: Skills, Distance, and Constraints

Under the hood, I designed the wizard's selection and ranking logic so it could recommend technicians the way an experienced dispatcher would think—just faster and more consistently. The algorithm considers:

• Required skills on the work order vs. the technician's skill set.
• Existing schedule and availability windows for each tech.
• Travel time / ETA based on the technician's current location and the job address (using GPS and mapping data when available).
• Job priority and any company-specific rules around who should handle which customers or job types.

The wizard surfaces a ranked list of candidates, making it easy to see not just who can take the job, but who best fits the constraints. Dispatchers still make the final call—but they're supported by a consistent, explainable recommendation engine instead of a manual cross-check of multiple screens.

Refactoring to MVVM: From One Window to Components

Under the hood, the biggest change wasn't visual—it was architectural. I broke the legacy schedule board apart and rebuilt it around a proper MVVM pattern:

• Split the large XAML into reusable UserControls for the board, columns, work-order tiles, dockable panels, and sidebars.
• Introduced ViewModels for the schedule board, work orders, technicians, and wizard steps.
• Replaced event-heavy code-behind with commands, bindings, and observable collections.
• Encapsulated business logic (eligibility, filtering, ETA calculations) away from the views so it could be tested and reused.

The result was a much faster, more maintainable codebase that made it significantly easier to add new scheduling features and variations in the future.

Performance: Paging the Board Instead of Loading the World

When I first picked up the schedule board, it tended to load far more data than it needed: large ranges of time, many technicians, and their related work orders were pulled into memory at once. That made the board feel heavy, especially for larger companies.

I reworked the data layer so the board used server-side paging:

• Limited queries to the visible date range and visible technicians.
• Used SQL-style skip/take semantics to page results instead of loading entire lists into memory.
• Reduced the amount of work orders and history hydrated at once, while still keeping the UI responsive as users scrolled or navigated.

Those changes significantly improved load times and memory usage for the schedule board, especially in large databases with years of work order history.

Dockable Layouts: A Board that Adapts to the Dispatcher

I also updated the Schedule Board to use a dockable interface, so dispatchers could arrange the UI around how they work instead of being locked into a single layout.

• Panels (unscheduled list, technician list, map, details, etc.) could be docked, floated, resized, or rearranged.
• Preferred layouts could be saved and restored so users didn't have to redo their setup every day.
• Different roles could maintain different board configurations —for example, one person focusing on unscheduled backlog, and another on live dispatch.

The goal was to make the board feel like a workspace, not a static screen—something dispatchers could shape around their own habits.

Developer Experience: Making It Possible to Evolve

A side effect of this work was dramatically better DX for anyone touching the schedule board going forward:

• The main window became lighter, and Visual Studio no longer struggled just to open it.
• Features were isolated in their own components and ViewModels, making it clearer where to plug in new ideas.
• The MVVM structure made it feasible to unit test scheduling rules without spinning up the entire UI.

For a mature line-of-business product, that kind of refactor isn't just "nicer code"—it's what makes ongoing innovation economically possible.

What This Project Represents

This work sits at the intersection of UX design, real-world operations, legacy modernization, and performance engineering. It taught me how to:

• Translate dispatcher workflows into guided, error-resistant UI flows.
• Take a large, complex WPF feature and refactor it into a clean MVVM architecture.
• Make meaningful performance gains with better data access patterns and UI virtualization.
• Design flexible, dockable interfaces that adapt to different users instead of forcing one layout on everyone.

For many field service companies, the schedule board is the heartbeat of the business. Being able to improve that experience—both for dispatchers and for the engineers who maintain it—was a big deal for me.