UX: Provide UX Pattern for Simple Settings Pages
Description
Environment
Potential Workaround
Attachments
- 16 Nov 2017, 08:13 PM
- 16 Nov 2017, 08:13 PM
- 16 Nov 2017, 08:13 PM
- 16 Nov 2017, 07:39 PM
- 16 Nov 2017, 07:39 PM
- 16 Nov 2017, 07:37 PM
- 16 Nov 2017, 07:37 PM
- 16 Nov 2017, 07:37 PM
- 16 Nov 2017, 07:37 PM
- 16 Nov 2017, 07:37 PM
- 16 Nov 2017, 07:37 PM
- 16 Nov 2017, 07:37 PM
relates to
Checklist
hideTestRail: Results
Activity
Cate Boerema December 4, 2017 at 2:17 PM
Okay, I touched base with and he liked this simple solution for now. We've got inline editing coming along at some point later so we needn't overthink this. He did suggest that the save button be greyed out if you haven't made any changes which seems logical. I will close this issue. Thanks all!
Cate Boerema November 20, 2017 at 9:38 AM
Actually, I like this simple solution, .
I suppose it could be argued that cancel buttons are useful on really long forms (so, if you go in and make a ton of edits and then change your mind, you can easily revert them all). But these forms are really small (just one or two fields) so you'll likely remember what changes you made. Plus, we have the unsaved changes modal. So, if you really go "crap - I don't want to do this!" you can click anywhere within FOLIO to generate the unsaved changes modal which gives you the option to discard changes.
Kimie Kester November 17, 2017 at 8:31 PM
Hey and . I just ran across this article about killing cancel buttons:
http://uxmovement.com/forms/killing-the-cancel-button-on-forms-for-good/
It made me wonder if in this instance, could we simply add a "Save" button in the upper right for the "explicit save" need, and ask Dev to include a confirmation success message? Would that be enough to cover this area?
Darcy Branchini November 16, 2017 at 8:15 PMEdited
Lastly, loan policies as an example for list of items created by the user - each with several fields.
There are two ways to view the item - the ... icon and the title of the loan policy. On that page, I image it goes to the full/partial page view with an "Edit" button at the top where the "Save" button is for the edit view.
Darcy Branchini November 16, 2017 at 8:13 PM
This shows a list of items (with 1-2 fields each) created by the user with inline field editing.
Details
Details
Assignee
Darcy BranchiniReporter
Cate BoeremaLabels
Priority
P2
Purpose: We decided in Montreal that all FOLIO pages and changes will require explicit save. The purpose of this story is to get UX guidance on how the simple Settings pages should be modified to include an explicit save.
Context:
Log into folio-testing as diku-admin
Go to Settings and then, for example, to Organization
The settings pages in Organization are simple pages that offer an edit mode (there is no view-only mode)
Some auto-save (e.g. Preferred plugins, Language and localization) while others require explicit save (SSO settings "apply changes" button)
Guidance Requested:
How should these pages be modified to include explicit save?
Where should save button live?
Other UX thoughts and feedback
Out of Scope:
Out of scope for this story is the UI pattern for Permission Set CRUD and Loan Policy CRUD. We discussed those in Montreal and I have already created stories for the changes required there (see linked issues). If you have additional thoughts on how those pages should work, please add them to those issues.
Also out of scope is controlled vocabulary CRUD pages such as Patron Group, Loan Type etc. These settings pages already require an explicit save so I think they are okay. Also, we recently received a refined UX design for these pages which seems to do what we need: https://www.dropbox.com/sh/x4n6mezyf5z8h2d/AACaw1DWjmIPMkoxb-yel8GHa?dl=0