webclient: green background color in copy editor shouldn't display for pre-populated fields
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Evergreen |
Confirmed
|
Undecided
|
Unassigned |
Bug Description
In the existing client, the green background colors applied to fields is a nice visual cue for catalogers to see which values have been updated.
A green background color is used similarly in the web client, but the background color appears as soon as you retrieve the copy editor for many fields. It appears as if it is used for any fields that either have a pre-populated default value or, in the cases of editing existing copies, already have a value stored.
The value of the background color, therefore, is reduced because the cataloger has no way of knowing which fields are green because they have a pre-stored value and which were actually changed since retrieving the editor.
The preferred behavior is to use these background colors only when a value is changed in the copy editor.
Changed in evergreen: | |
status: | New → Confirmed |
tags: | added: usability |
tags: |
added: cataloging removed: webstaffclient |
tags: | added: accessibility |
tags: | added: ux-form-validation |
duplicate of bug 1761142?
the green background comes from the class "bg-success" which is usually applied if the field has a value. for example: "{'bg-success' : working.floating !== undefined }
ng-class=
if this background isn't useful, it could be removed and the branch for 1761142 could use a background instead of a border.