There are a few features that need to be redesigned to properly adapt to growing needs. Most are modelling issues that are limiting the team’s ability to extend existing functionality.

Scheduler IN PROGRESS

Currently the draft schedule is a self-contained entity that makes it difficult for associations to schedule games across multiple schedules, as they’re required to go into each individual draft to make changes.

A redesigned draft scheduler introduces a new DraftGame entity that’s similar to Game, which draft games far more flexible than the current implementation. This also necessitates changes around team ordering and game number sequencing as these were handled within the draft which would no longer exist.

Infractions IN PROGRESS

Originally infractions were actually hardcoded in the app, and every change to infractions required code changes. When ball hockey was introduced, the “rulebook” was created to unhardcode the penalties, but it basically moved the structure that was in the code into the database and retained a limitation that each infraction did not have an ID since existing penalties didn’t have this.

While this generally works, it’s realistically a really hacky solution as references to any infraction require the rulebook (which can technically vary by office) to be able to resolve details like the name and severity, instead of just referencing by an infraction ID.

There are also potential issues such as a branch extending the infractions to specify their own code would override the default code which may not be desirable in reporting, and linking penalties (5+GM) is not as efficient as it could be. Further, creating rules for each suspension is significantly more ineffective.

A more appropriate solution is to normalize the relations so that penalties are linked to infraction IDs, then it’s much simpler to extend infractions if necessary while retaining reporting flexibility, link related penalties together and create suspension rules based on infractions.

Suspensions NEXT

Once infractions are implemented, we can start to implement automatic suspensions for hockey. While soccer and baseball infractions are very simple which made it easy to implement existing suspensions, hockey has a much more complex structure of infractions and suspensions.

This involves defining a list of sanctions related to infractions which will be flagged as suspensions.

Assigning rules NEEDS ANALYSIS

Rules were designed from a complex standpoint that different assigners have very different and complex needs, with the intent of getting to a more simplified point, but this has proven impossible.

While the rule system has generally achieved it’s goal of handling it’s complex use cases, basic configuration is a very difficult point of entry for new assigners.

Categories

Redesigned assigning rules should focus more on creating settings by category, as this is the context that assigners primarily think of. By being able to show a list of categories and their configured settings (system, fee, etc), this would drastically simplify how assigners manage their settings as assigners.

We still need to solve how to handle conditional settings such as time of day (pay primarily varies on this), but the variances pattern from rulebooks could still be feasible here.

We may also want a way to vary the assigning settings based on the league.

Assigner determination

There are two problems here because we combine assigner determination with settings determination.

First, if an assigner onboards after games have already been scheduled, currently they won’t see any games because they have no assign system rules. Rather than defaulting to no officials, we default to assigning disabled (no game assign settings produced). To correct this, they have to create rules, then reapply assigning settings.

However, reapplying assigning settings is based on the league since it includes assigner determination. Assigner determination doesn’t really change often, so this should be based on the assigner’s games, except none exist since we don’t produce the game settings without a system.

It’s a chicken-and-egg problem that’s simply resolved by separating assigner and settings determination, allowing settings to exist without a systemId, then changing the reapply rules to be based on the assigner instead of the league and creating a separate flow for redetermining the assigner if necessary.

Most importantly, assigners need to be able to easily change and reapply their settings.

Since we’ve introduced tournament and cup offices, we can reliably move assigner determination to be a office or schedule setting instead of being an assigning rule, as the rules were primarily based on the schedule type.

Assignment settings NEEDS ANALYSIS

There are some new feature requests that require a rethink of how we define settings at the office and assignment levels.

A lot of the feedback we’ve received works well together if we move from game assign settings to per-official settings.

Custom official positions

The hardcoded enums are insufficient for more advanced assigners who want to be able to create ordered positions (Referee 1, Referee 2), more descriptive positions (Scorekeeeper Supervisor) or just entirely custom positions (Video Official).

Since we have qualification categories, this doesn’t create a problem to match eligible officials, but we will need to rethink other settings are implemented, such as the minimum levels and pay structures, which rely on the enum positions.

Delegation

This was a last-minute high-urgency request that was implemented without sufficient design consideration. It has a number of ugly limitations because it’s implemented directly on the official, which means it’s limited by the scoresheet, which is something the game assign settings are not limited by.

Delegation necessitates a much greater change to the game assign settings because we can no longer make the assumption that the game is assigned by a single assigner, but each position has it’s own assigner now.

Note that in some cases, there still continues to be a primary assigner that is responsible for payment. They’ll retain the ability to re-delegate to another assigner if they choose and oversee the status of the delegated assignment.

Assigners also need the ability to specify criteria to delegate positions automatically that they would otherwise be responsible for.

Custom systems

The idea in delegation that each position should have it’s own settings is related to another piece of feedback we’ve received which is that the current “assign systems” are too limiting. Assigners want the freedom to be able to add/remove positions as they please.

If we’re to move game assign settings to become per-official settings, the system ends up being the odd property out because it doesn’t relate to any one official while the others do (office, min level/grade/age, fee and status).

Assign fees

Currently changing pay structures mid-season is a pain because the relation already exists between games. We limit changing pay structures in this case and force creation of a new pay structure instead.

A more optional solution would be that the fee is defined in the category settings and a relation isn’t necessary. When editing game settings, we could be smart about recommending a value if they make changes instead.

Categories NEEDS ANALYSIS

Categories were originally modelled after HCR 2.0 categories, which had a division, gender and category separately. Spordle ID (HCR 3.0) introduced a more normalized category model, which Play has been gradually migrating, however this requires a three-phase approach:

1. Convert from enums to a category model (completed)

2. Add category hierarchy to allow branches to extend their own categories

3. Add externalIds to properly link 1:1 with ID

The conversion from enums to the model was relatively straightforward, but the biggest challenge to resolve is the category hierarchy. Once the hierarchy in place, we’ll finally be able to have a true 1:1 sync with SID.

Contexts

In Spordle ID, using the application requires you to set a context of what you’re working as so the role and office you’re working as is clear, but also you don’t really run into data from other offices unless you’re in that context.

Conversely in Play, if you have roles in multiple offices, you’ll see data from all offices at once. Even if you’re only responsible for a single office, there’s a high probability you’ll see data from other offices because you can schedule teams from anywhere.

This becomes a problem for categories when an administrator has access to multiple branches. For example, district administrators are often granted team-only access to other provinces (or USA Hockey) that aren’t synced with Play so they can create teams competing in tournaments.

Note that for officials, it doesn’t necessarily make sense to limit an official to a single association at time. Other applications do this since each association runs as a separate tenant/client of the application, so officials that live in an area with multiple small associations need to switch around to be able to find games to request. The fact that they can see all games they’re able to request at once should be seen as an advantage. Also keep in mind that a user could be an official and coach or assigner at the same time.

UX

In a form, we would be able to enforce selection of an office so we can infer the applicable categories, but the actual challenge is filtering on a main list (games or teams page). There’s no office context applicable so results for “U13 A” may should duplicates from different branches.

This would cause a poor experience so we need a good way to only show the expected branch’s categories (short of reading the user’s mind) and also implement equivalence so that filtering by “U13 A” (BC) would still show visiting “U13 A” (AB) teams as they are technically different categories, so a strict categoryId filter isn’t effective.

Branch category equivalence would need to be based on the common parent category. This works up until USA Hockey is involved, in which case they’re a separate office tree (living in the same tenant), so they would not have common categories. It’s also not feasible to maintain a list of equivalences.