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.

2 Answers 2


The real problem your facing is trying to remove shifts, where there are only one shift available. By shift you mean working hours, which makes it easier to consume, since the default shift isn't a scheduled working shift per se. The default shift is (most likely) a daytime schedule just as much as Dolly Partons Nine to Five.

The user of the system need to realize that there is a daytime shift also which couldn't be deleted. This is probably best done by having the default daytime shift on every job users add, even if noone works on that shift if every worker on the Bingo Night have a different shift. Bu sure to make these default-non-deleteable-working-hours differ from user added shift.

enter image description here

If I completely misunderstood your intentions, please advice me in a comment and I'll try my very best to help you in this important architectural problem.

  • Thanks for the reply and I apologize for the delayed reply. I'm a newbie to UX Exchange and didn't see any notification of a reply. Just browsing months later I noticed someone actually answered by question. Thanks! In any case, your suggestion of building in a 'default' shift that is ever-present and can't be deleted is noted, but does not feel ideal. For some jobs 9-to-5 (to use your example) is not a valid option, and thus should not be available.
    – mhale
    Commented Jan 11, 2014 at 19:14

I think the word folding might apply. The concept is similar to a feature in text editors that allow the programmer to fold (or collapse) function bodies or conditional statements, thereby revealing only the outer level. Folded levels can be nested within other folded levels.

  • Thanks the nomenclature folding is useful. And the metaphor of collapsing blocks of code also feels on the right track. The thing I struggle with is the nature of the parent (job) changes if it has child nodes (shifts) -- thus switching back and forth between having and not having child nodes becomes messy.
    – mhale
    Commented Jan 11, 2014 at 19:20

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.