UI for creating new user

[joohwankimNV]

A relatively minor request.

The steps for creating a new user is,

1. Open the dialog box (by pressing esc)
2. Type in new user name
3. Press the '+' sign next to it

Step 2 was not clear, even though there was an 'Empty!' notification message when I clicked on '+' without typing in the user name. Feels like it can be improved, although it's completely operational so not urgent at all.

[bboudaoud-nv]

The way we are currently doing this, though clever, is a bit hacky. We can probably promote the requirement for new user creation to a 1st class citizen in FPSci w/o compromising the current behavior.

I think we may want to consider adding a requireNewUser field to the experiment/user status configuration that indicates a new user must be provided (or an existing user can be selected if one exists). This gets more complicated if we want to add logic beyond what is currently present (i.e. requiring a new user to be entered only when certain conditions are met).

[jspjutNV]

Thinking about scenarios here. There's probably at least the following situations people might want to be able to express:

1. We know all users ahead of time, so we can pre-populate the list and we don't need an "add user" at all for an experiment.
2. We know some set of users ahead of time, but want to be able to add some users later.
3. We don't know any of the users ahead of time, and want to require new users be added every time. This is particularly useful when sending the executable for people to run at home without bogging them down in all of the other users.
4. (alternate of 3) A pre-populated list could be provided, but restrict the startup to only one user so specialized versions can be sent to each user. Probably not ideal or really necessary.

[bboudaoud-nv]

@jspjutNV this is a good starting place for discussion, here are some thoughts on your numbered list:

1. This is the behavior specified by the allowUserAdd parameter (already in FPSci)
2. This may be the most challenging case (more below)
3. The challenge here is really in the statement "new users must be added every time". Does every time mean every run of FPSci? To (2) above should a user be able to relaunch FPSci and select themselves again vs create a new user?
4. I think this could be accomplished w/ individualized user status files and allowUserAdd = false in the config

Of all of this I think the biggest challenge is in understanding how we want to manage "requiring adding a new user". Specifically how we want to handle the dynamic between requiring people to add new users vs preselecting the last user to have run the application.

One option I'm considering is the idea of "temporary users". These would be users who are (required to be) created when the application runs, but are not added to the user status file. Instead their status/session order only ever sits in memory. Results would of course still be logged for these users but session progress would not be tracked (i.e. they need to complete an experiment in a single run of FPSci).

A final challenge to consider in implementing this is how we manage possible filename conflicts (since currently unified experiment results files rely on the user name and/or experiment config to be unique). We could simply allow conflicts, but we may want to revert to doing something like timestamped results files if we implement the "temporary user" model above.

[jspjutNV]

Just to add to the connection trail, this issue is related to #365