-
Notifications
You must be signed in to change notification settings - Fork 92
Web Site Redesign Use Cases: Easier Experiment Participation Monitoring
(Subpage of Web Site Redesign Use Cases )
Right now, the View Data command in the web app shows either one user's data (Joined view) or all users' data (Admin view). We should have an option to drill down to see just the data for one user in the Admin view.
Right now on the Stats report, we show the participation rate for Today and for the cumulative days of the experiment. Researchers would like to view the stats for a participant by each day of the study. This might need to be a drill down view to accommodate experiments with an Ongoing Duration. This should also list all published users, even if they have not yet joined or responded yet. This should also show the joined date/stopped date for the participant (maybe near their name). It might be nice to show the current state (joined/stopped) some way on the user as well (maybe color coded or with an icon).
Right now, there is a meta-equiv=refresh page that users get for the status of their reports (View Data, Stats, CSV). This page could be cleaner and flow better.
When generating a CSV export, the user should get an intermediate step that lets them configure some parameters.
- File name for export, default to experimentname_timestamp.csv
- Checkbox to expand list choices into individual columns in csv output
- Checkbox to anonymize user ids with hashes (replace the Anoncsv output button)
- Option to just generate anonymous_hash<->user_email mapping csv file instead of a data csv file.
Moved this functionality into the CSV export functions
The View Data html report is useful to show the researcher a quick html view of the data collected in an experiment, which is particularly nice for seeing the pictures inline with the other responses at a given sample event. Sometimes researchers want to download this page with the photos inline, other times they are just browsing, so we need an option to paginate results into 100 at a time or load the whole page at once. Maybe adjustable page size settings would accommodate this.
Also, currently the set of columns that are shown should be cleaned up. Having the experiment version, respondent id (maybe anonymizable), scheduledTime, responseTime, and each of the response variable columns.
It would be nice to have a header that shows the title and tells how many results in total their are as well as when the report was generated and for whom it was generated.
Right now we are accumulating a ton of commands for experiments, at least for administrators. This could be grouped or cleaned up in some way. Really we have reporting/monitoring, exporting, editing, deleting, and hiding. We need to add archiving as well. Purge and Hide need to be clarified. Purge is a hard db delete. Hide just makes it invisible to users so that they can't join it. The reason we have these is because a researcher might decide to fully delete the experiment from the datastore. Any user's data will still exist but have no experiment definition to show the question text or experiment title. If the researcher has let it out in the wild and does not want to create this situation, they can just hide it instead.
Need another command that allows a researcher to flush the data for a user in the experiment. Same for all users. This last might be a purge and delete data function similar to the current purge function. The problematic question is, "when should a researcher be able to delete a user's data?"