DRAFT
Design patterns
Search and retrieval pattern, with potential to lead on to a task
Single item
Search & filter > View results > Select an Item >
Edit an item
Perform another action on an item
Bulk actions
Search & filter > View results > Select multiple items > Perform a bulk action on selected items
Delete
Add agencies to a group
Including Bulk action confirmation modal UX pattern
Create new record
Including
Confirmation modal UX pattern
Unsaved changes modal UX pattern
Edit record
Possibly combine with “create new record”.
Duplicate record
Delete/archive record
Hiding vs. disabling interactive elements
Switch to full view
Displaying content based on user’s role
Information and feedback to user
Text
Lists
Informative message
Successful action
Unsuccessful action
Warning
Error
Components to use for presenting feedback
...
Badge component
...
Alert component
...
Message banner component
Modal component
Modal component
All modals should have:
A header containing
...
Modals should be movable, allowing the user to reposition them.
Language rules
General …
...
Error message
Error text should be succinct and unambiguous. The nature of the error should be described first, followed by additional information such as the rule which has not been met or the reason for the error, then lastly the recommended action for the user:
...
a-file-name.pdf is in an unsupported format. Valid formats are CSV and TSV. Please select a file in a valid format
Informative message
Warning message
Validation message
Layout and presentation
Template
Navigation
Pane headers
Search, filter and results
Record view
Modal
Data grid
Forms
Interaction
Hover
Focus
Active
Drag and drop
Components
Material components will be used as standard.
Accessibility
Enlarge/ decrease screen content.
Alternative themes. Minimum: dark.
AXE testing.
Manual checks, including keyboard only use.
Branding
Colour - include guidelines about branding etc? Is the intention for this UI kit to be reusable?
For integrating.
Form fields
I'd like form labels to be more prominent. Ideally labels should sit above the fields, in bold. FOLIO users prefer labels to stand out more than the field content. This will be important for larger forms. This isn't MUI out of the box so will need to check what is possible technically.
Mandatory fields
Indicate a field is mandatory using a red asterisk next to the label.
Display a validation message in red underneath the Host LMS field when "Import file" is selected and no Host LMS is present. And apply error styling applied to the field.
Progress bar
The aim is for the progress bar to incorporate the uploaded file, file size and an option to remove the file, as described in DCB-399: Admin UI - progress bar component for file upload
CLOSED
Effectively the bar becomes the uploaded file, which the user can then choose to remove. Some options:
Support removal/replacement of the file by allowing another to be uploaded via the target. I.e. select another file to replace the existing one. However, if we ever need to support multiple file uploads then this approach will not work.
Display the uploaded file within the target area. This makes sense to the user. However, if multiple uploads are ever needed the target area could grow quite large. Plus currently only one click action is supported within the area.
Have a separate component for the uploaded file which is displayed below the target area.
Make the progress bar work as described in DCB-399.
We can't assume that the progress bar will never be invoked, e.g. on a slow connection, however I absolutely agree that most of the time the “progress” indicator” won’t be needed.
Drag and drop/target area
The Arrow symbol should be replaced with a "page/file" symbol, colour: #dddddd.
The style of the "active" blue border of the target area should match that of the border applied to the active Host LMS field - same colour at least. The aim is for all form elements to have the same "active" style when the user tabs through.
Add a backgound colour of #f7f7f7 and curved corners to the target area.
On drag change the target background colour to #??[TBD], display the blue outline and change the document colour to #??[TBD].
On drop, if the file upload is successful we should disable the target area and indicate this via styling. This is dependent on being able to display the uploaded file component.
The whole of the target is clickable rather than just the link "select a file". I'm not 100% sure about this approach. Is it definitely accessible? It limits us to one link/click action within the target. This might be ok though.
On successful upload any error alerts should be removed, they currently persist.
Text in target area
Links should have a soft underline (for accessibility).
Change .tsv and .csv to CSV and TSV. When referring to a file type use caps and no dot :- ".csv" etc can be used when referring to file extensions.
As a general guideline, text displayed to the user should be copied directly from the Jira tickets and used as is.
The target area seems to be using a different font family to the rest of the app. "-apple-system,system-ui,BlinkMacSystemFont..." instead of "__Roboto_25fc88, __Roboto_Fallback_25fc88". This might not be an issue now as we haven't yet touched on theming but when we come do, we need to make sure that the styles are easy to change throughout, and hence avoid having to go through all the components to make changes.
Closing the modal and selecting "Import" re displays the modal with the uploaded file and messages. It should be reset to a clean form.
Alerts
In the invalid format error message, change .csv and .tsv to CSV and TSV.
Can the filename and filetypes be presented in bold as per the wireframes?