Description
In order for MPIC to manage both instrument and experiment configuration, the references to instrument should be updated to a more generic term (inclusive of experiments). We will still keep the basic functionality of the instrument form (which will retain the references to instrument) but in all the other user interfaces where we reference EITHER instrument or experiment, a new name/phrase will be needed.
Copy proposal
Only the text elements that still need to be adjusted in the context of the combined application are included in this table and illustrated in the screenshot below:
| ID | Element | Current copy | Proposal | Observations |
| 1 | Tool's name (header) | "Metrics Platform Instrument Configuration" | "Metrics Platform Experimentation Lab" | Temporary until the team resumes naming activities |
| 2 | Main page's title | "Experimentation dashboard" | "Experimentation directory" | Following the feedback that the term "Dashboard" has connotations of data visualization. "Directory" is suggested instead of "Registry" for being a slightly more common term in digital contexts |
| 3 | Main page's description | "Configure and manage your data collection instruments and A/B experiments" | "Review and manage your data collection instruments and A/B tests" | This reduces the amount of mentions we do to "experiment" or "experimentation" on the UI. "Configure" is replaced by "Review" because configuration rather takes place in the forms, not in the main page |
| 4 | Table action | "Turn Baseline instrument on/off", "Turn A/B test on/off" | "Turn on/off" | Using more generic copy makes the option clearer and more scalable. The context makes the action understandable |
| 5 | Table action | "Delete Baseline instrument", "Delete A/B test" | "Delete" | Using more generic copy makes the option clearer and more scalable. The context makes the action understandable |
| 6 | Detailed view's "Edit" action | "Edit Baseline instrument" , "Edit A/B test" | "Edit" | Using more generic copy makes the option more scalable. The context makes the action sufficiently understandable |
What doesn't need to change as part of the scope of this task:
- Status change/Deletion dialogs: e.g. "Are you sure you want to delete this Baseline instrument? This will permanently delete the Baseline instrument. You cannot undo this action". – Indicating the artifact type can bring clarity in this context, where the table's information is not available. For full clarity, it'd be a great idea to display the name of the artifact affected by the action. A new dialog copy proposal will be made in a separate task (TBD)
- Status change/Deletion confirmation message: e.g. "The Baseline instrument {name} has been successfully updated" – Like with dialogs, the artifact type can be considered more necessary information in this context, given that the message is not positioned within or next to the table (users cannot easily see what type of artifact they deleted)
Changes that are being evaluated:
- The use of the term "Baseline": During the ongoing usability testing round (T376120), at least 2 users (test outcomes are still being processed) expressed confusion around the term "baseline". They either mentioned that: 1. they weren't sure of the meaning of said term, or 2. that they didn't think it applied to all instrument use cases (i.e. instruments can be used to measure the outcome of making a change, which doesn't theoretically correspond to a baseline anymore on the user's opinion).
Observations
- An original design proposal mapped some of the places where this new name/copy will need to be updated.
Acceptance Criteria
- Design mocks are created/updated with new language/copy
- Update application according to the mocks regarding the new language
