The application I'm working on has a number of cases where the simple and most common use-case involves configuring a single object, but in some cases requires breaking the base object into sub-objects and then configuring each sub-object.
A concrete case of this would be job scheduling. The simple case involves creating a list of jobs that need to be filled, with settings for each job. But some jobs are broken into multiple shifts, where each shift needs some configuration.
The naive approach is to just require all jobs to have shifts, where having 1 shift is a valid configuration.
For the user setting up the jobs and shifts, it is a pain to have to set up a shift for a job that only has one shift. They think of that as "just a job" the shift is seen as extraneous and unnecessary (and it is, in this case).
So, I want to make this better. I think the right conceptual solution is that you can create "jobs" and then if you need shifts you can add shifts too.
This feels like a "progressive disclosure" design solution. For example -- a click to "Add Shifts" which reveals a shift editing interface.
One key point is that there are some data elements of a Job that only apply if there are no shifts, otherwise that data is part of the Shift definition. In this case a user can earn some specified number of "points" for signing up for a job. But if shifts are defined, then it is the shifts that are worth points, not the job.
An example of Jobs and Shifts for a Bingo night might look something like this:
Job:Setup -- 2pts Job:Ticket Taker Shift:1st shift -- 4pts Shift:2nd shift -- 3pts Job:Bingo Announcer Shift:1st shift -- 5pts Shift:2nd shift -- 5pts Shift:Until end -- 6pts Job:Cleanup -- 3pts
The key points are that some jobs have shifts and some don't. Jobs that don't have shifts have a point value directly assigned to the job. Jobs that DO have shifts do NOT have a direct point value, but rather each shift has a point value (and the points can vary per shift).
I'm primarily concerned with the UI for the SETUP of the jobs and shifts -- for example an administrator user is able to define which jobs and shifts are needed for the event. (As opposed the to the UI to SIGN-UP for a job/shift).
One way to think of this is as if every job has a "built in" shift, the configuration of which is collapsed into the job configuration - until more shifts are defined for the job. This thinking would be revealed when someone clicks "Add Shifts" and the first (built-in) shift is already in the list.
The problem with this approach is what happens when the user tries to delete the only remaining shift? Does that revert back to a "no shifts" mode for the job? If so, what should the "points" value for the job be at that point?
This pattern of a simple object that can be a container for sub-objects in some circumstances has shown up multiple times in this app. The job/shift is just one example. Other examples would be groups/sub-groups, event/sessions, organization/divisions, product/size, etc.
It just feels like this has to be a solved problem.
Can you think of an example of a UI that does a really good job of progressively revealing this conditional hierarchical complexity?
Do you know a name for this pattern?
I've struggled to find the right words to describe the UX problem I'm trying to solve. If there is a name for this problem/solution, would love to learn some shorthand.