Web UI: Publishing state needs clarification

[NickAraujo]

There is room for confusion in the current Web UI as to whether or not an experiment is published and who can join it.

Evidence: A researcher mentioned that they lost a day of data because they pasted the published audience into the text field but did not toggle the Experiment Status toggle. Additionally, at least 1 new Paco user expressed confusion as to when an experiment was published during a recent talk.

The problem is that 3 publishing/access states:

• Private (joinable by admins only)
• Invitation only (joinable by admins and the following invited participants)
• Public (joinable by all Paco users)

...but these are represented by 2 separate binary variables:

• Experiment Status toggle (published | unpublished)
• Published Audience field (filled | empty)

I recommend revising the Admin tab to better reflect possible publishing/access states. Sharing options on Google Apps provides a useful model:

Also worth considering:

• Likely still need a confirmation action before changing state (e.g., "Save")
• What are the side-effects from changing state during an experiment? How do we educate users about these side-effects? (e.g., context-specific dialog box)

[BobEvans]

Agreed there is some confusion that never occurred in the old ui which was used by many more people.
The new UX even tripped me up once during our recent workshop.

Backstory on the two variables, this design is due to the way researchers design their experiments and then subsequently launch them at some later time. They almost always know who the audience will be and want to configure it before they actually make it available to them (publishing). So, being able to enter the audience ahead of time without publishing is necessary.

Two other issues around this confusion also come to mind.

1. The location of the publish switch should be somewhere else - possibly by or in combination with the Save button or down by the audience field. In our V4 mocks, we specified a publish button at the right end of the tabs, but that had other problems. Still, the idea of a Publish button triggered as a separate action that combines setting the published state and saving the experiment would definitely get rid of any confusion. Then the audience field just becomes audience, empty or specified. We should appropriately enable/disable the Save button upon not only field’s being dirtied but also upon publishing so that the user has another clear signal that they do not need to save.

2. If we did Import Paco sources from Google Code #1, then this issue is moot. If we just move the publish button then it still stands. The Fuscia color change when the publish button is pushed to the on state suggests to me that Publishing has truly happened and there would be no need to save in addition. If we want to keep it such that publishing is a toggle and a save is still required then this button should lose the powerful coloring so as not to seem more important than it is.

To your last question about side-effects. If they change state from published to unpublished during an experiment, then no one else can join. The others have already joined so their experiment will still work as long as originally configured. There is a fair amount of complexity in such a situation and as far as I know no one has ever done this. Generally, it would probably be a bad idea. We could perhaps detect the state and warn them prior to effecting a Save or unpublish action (#1 above), but, we would probably want to detect if the experiment had actually been fielded prior to warning them, or, just risk annoying them with an extraneous message if they had not fielded it.

On Nov 18, 2015, at 1:10 PM, NickAraujo notifications@github.com wrote:

There is room for confusion in the current Web UI as to whether or not an experiment is published and who can join it.

Evidence: A researcher mentioned that they lost a day of data because they pasted the published audience into the text field but did not toggle the Experiment Status toggle. Additionally, at least 1 new Paco user expressed confusion as to when an experiment was published during a recent talk.

The problem is that 3 publishing/access states:

• Private (joinable by admins only)
• Invitation only (joinable by admins and the following invited participants)
• Public (joinable by all Paco users)
...but these are represented by 2 separate binary variables:

• Experiment Status toggle (published | unpublished)
• Published Audience field (filled | empty)
I recommend revising the Admin tab to better reflect possible publishing/access states. Sharing options on Google Apps provides a useful model:

Also worth considering:

• Likely still need a confirmation action before changing state (e.g., "Save")
• What are the side-effects from changing state during an experiment? How do we educate users about these side-effects? (e.g., context-specific dialog box)
—
Reply to this email directly or view it on GitHub.