chris-huggins
commented
5 years ago Update
The goal of the updated input style is to reduce visual clutter caused by many strokes/non-filled inputs (the fill would likely make it easier to differentiate between inputs and space between them). The "hope" was that this would also enable us to easily allow staff to switch between a "reading prioritised" state and an editable state. This was raised when working on mock-ups containing only text input, but in Reviewer components are often more complex, and take up a lot more space (with more UI/visual clutter) than a text input. e.g. multi-select input, rich text editors, show/hide pattern and editor assignment.
Because we want to prioritise a readable representation of entered data for quick/easy checking, using these inputs without another way to switch between "read-only" and "editable" would result in unnecessary visual clutter/complexity. Therefore, the decision to update the input style should be separate from this issue. Updating the input style will also need to consider many component types, not just text input.
We should find a way to test the two styles to determine which is "best" for Reviewer users.
Details on the how to switch between "reading" and "editing" views problem still to resolve:
Reviewer requirements for the submission detail view (for staff):
- Prioritise the reading/scanning of data entered in the submission wizard by the author
- Enable editing when needed for small updates that don't require the author's input
(note: Authors will be able to edit inputs only when a comment is added by staff to request updates. They should not be able to edit data unless explicitly enabled/requested by staff).
Libero Producer's use case is slightly different. Staff often make significant edits to a large amount of data, and priority should be on speedy editing. Texture currently has a pattern for "show more/less" that toggles visibility of empty inputs. But whether showing more or less, the inputs visible are always editable for the sake of speed.
Designs for Libero Reviewer currently prioritise a streamlined/de-cluttered reading view. With ability to switch between "read-only" or "editable" modes. This could become awkward if having to repeat this action often, or requiring scrolling to get to the switch/button.
The frequency of edits made by staff should be explored to help refine the requirements around this. Testing will be potentially inaccurate if focusing on only a small prototype with mainly text input (e.g. co-author info), because there will be less "other UI clutter". A prototype with different options for editing (i.e. entire tab toggle, section toggle, per input toggle, always editable) that represent a full, complex submission would be ideal. But would take significant effort.
Decision needed: How to proceed to test method of editing submission data. Action: establish options or exemplars e.g.
- Toggle read-only/edit on entire submission basis
- Toggle read-only/edit on tab-by-tab basis
- Toggle read-only/edit on section basis within each tab
- Toggle read-only/edit on input/smaller component level basis
- Always editable, but design aims to enable easier scanning/reading
We need to strike a balance between a de-cluttered reading experience and easy/fast editing, without increasing or causing risk of accidental edits (e.g. if not clear when an editable input has focus etc.)
Following work on Texture by Nick it looks likely that we'll be updating the visuals for inputs in the submission wizard. We should look to do this before designing anything (or at least building) for full submission wizard. But ideally a.s.a.p. This is dependent on work by Nick and we need to ensure requirements for xPub/Reviewer are considered and a consistent solution is defined (e.g. text area and rich text editor for cover letters)