Pattern for multiple roles that have access to different parts of the same view?

Question

Imagine I have two roles:

Administrator
Teacher

Imagine a view Class

Administrator has a subset of the functions allowed in the class view:

1. Create a new class
2. Name the class
3. Add/remove students in the class
4. Add/remove the teacher of the class
5. View students and their parents, and view their class registration information

Once an administrator has added a teacher to the class, the teacher may do the following (also a subset, but a different subset):

1. Add/remove assistant teachers
2. Add/remove volunteers
3. Send class emails
4. Schedule class calendar events
5. View students and their parents, and view their class registration information

So there is some overlap, and some functions that are different.

The administrator will have a list of classes to choose from for their functions. The teacher will just have one class and will get to the view from their menu directly (vs. the teacher who will get to a view of classes first).

Should the administrator and teacher have different screens? Or should it be the same screen with different functions enabled/visible? How should the teacher and the administrator get to the view for editing?

Are there any established patterns for this type of scenario?

Answer 1

This is a very common pattern in enterprise apps.

You have different role- or policy- driven views into a common application and model.

• You can either use separate layouts, or the same layout. Both can be successful.
• For these user interfaces, templating and widget re-use is very important, because you can assemble layouts very quickly by dropping in widgets.
• I would suggest modeling out the components associated with each of the tasks, and writing templates to assemble the components into a view for each role. Generally each role will have a separate template, but most of the content will be reusable. This allows you to quickly compose views that have overlapping functions (like teacher <-> administrator).

It looks like your top-level model object is a class, so a layout like this may work (widgets will be present or not depending on role):