Make required fields on inline formsets more obvious

[steven-cd]

This was brought up as part of #260, but it's really more general than that.

We use inline formsets in a number of places for adding relationships to an object, e.g. setting projects for new users, setting datasets for new work packages, setting work packages for new participants etc. For all these cases, we have:

• Asterisks next to each required field in the table header
• One blank row of values

However, this implies to the user that they must fill in some value, when they actually don't have to. If they leave the whole row blank, that's okay, it just doesn't add any relationships.

I don't know exactly what a good way to address this is, but I'm considering some of the following possibilities:

• Removing the asterisks from table inline formsets. We normally only have one or two columns, and I don't think we ever have any that aren't required, so they may not be adding much
• Removing the initial row. This might make it slightly more obvious that you don't have to enter something, but at the cost of extra click when you actually want to
• Replacing some of the tables with an alternative implementation, e.g. a set of checkboxes. I think this would actually be more usable in many ways for things like datasets, work packages etc. when there are typically a small number, although it wouldn't work for anything that actually needs multiple values, such as adding projects to new users.

[steven-cd]

I've been through all the formsets we have:

• In three places I've changed it to no longer use formsets, and they look clearer
• In three places, I've left them (mostly) as-is, as the formsets don't allow extra rows to be added, and the behaviour of required fields is obvious

There is only one remaining instance that I'm unsure what to do with, which is the one that started it all: creating and editing users. For this, we agreed I'd produce some mockups of different options:

• Current page
• Option 1 - No asterisks (not sure if this actually really helps)
• Option 2 - No initial row (I think this is clearer, but unfortunately I'm not sure it's actually possible due to how the django-formsets JS works)
• Option 3 - One row for each project (Also clear at the moment, will be less so when we have lots of projects)
• Option 4 - Some explanation (This is the best text I could come up with)
• Option 5 - No ability to add projects

Currently, we have the same mechanism for adding a user as editing them afterwards. We could decide to change this, e.g. use option 5 for creating users, but leave it as-is for editing users, as the same behaviour might be more obvious in the different context.

We could also choose to remove the ability to add projects at the same time as creating/editing, but add a new separate page ("Add User to Projects") that uses one of the above options.

Currently my inclination is to just go with Option 5 (or 4, if people agree with the text), as that is very little work and I actually think the use case of adding a new user to lots of projects is probably fairly limited (maybe just new Project Managers), and the use case of adding lots of new users to the same project (e.g. #216) will be more common. I'd certainly be happy to reconsider if anyone disagreed however.

@tomdoel @bw-faststream Any thoughts?

[bw-faststream]

Hey Stephen, thanks for going through all of this - I think 4 looks best, and like the text explanation included. It solves the problem quite nicely

[tomdoel]

I agree, explanatory text is fine in this particular case (add/edit user) since that page is only used by Programme and System Managers who will generally be Turing members with (hopefully) some familiarity with the system.

One thing that is possibly unclear when creating a user is that you can only add the user to existing projects. The "Add Project" button might be misinterpreted as creating a project. We could change the explanatory text to "You may add the user to one or more existing projects..." and possibly change the button to "Add user to more projects" unless you think that makes it more confusing.

[tomdoel]

I believe this is done in #277