UX: Review Repeatable Address Fieldgroup and Provide Guidance
Description
Environment
Potential Workaround
Attachments
blocks
relates to
Checklist
hideTestRail: Results
Activity
Kimie Kester October 24, 2017 at 3:10 PMEdited
Hi . and I have been thinking about moving the mocks to google drive. here is the most recent called user-details-4.png
https://drive.google.com/drive/folders/0B18Bhhmr94zaSWdHckJ2WDExUUE
Cate Boerema September 12, 2017 at 11:08 AM
Thanks, ! I think we can mark this story complete.
Kimie Kester September 8, 2017 at 9:34 PMEdited
When the user is in Edit mode and adds an "Address 2", they may then select "Set as primary" to make that their Primary Address.
When they do, that address then shifts to the top of the list and becomes "Address 1 (Primary)".
The address that had been primary moves down and in this instance would be listed as "Address 2 (Set as primary).
In these examples the user has swapped their home address from primary to their office address which is now primary.
Kimie Kester September 8, 2017 at 9:04 PMEdited
If the user tries to select an address type that has already been used, they currently receive a message telling them that the "Address type is already taken"
If Dev can check which address types have already been selected after a user decides to add a new address, and only display the available types, that would be ideal.
Kimie Kester September 8, 2017 at 8:57 PM
https://www.dropbox.com/home/FOLIO%20UX%20Designs/Users/Address%20Component
Screens at Dropbox show the View mode for User Information with the repeatable address field expanded to show all addresses
Fields in Edit mode match the View mode as the SIG had suggested
The Active heading under Users has been changed to Status and checkmarks have been removed in favor of spelling out Active and Inactive
"Record last updated" has been added to the top with ability to expand and see Source and Open date.
since the screens are very long to scroll I suggest using the "View Actual Size" option instead of "Fullscreen" option so that you can scroll the page
Details
Details
Assignee
Kimie KesterReporter
Cate BoeremaPriority
P2
Purpose: Get UX review of the current state of repeatable address fieldgroup. It is working but the UX doesn't feel great. New designs may be needed. Written suggestions also okay.
Background: A bit of background on this feature since I believe we'll have new UX designers collaborating on this.
We have already implemented a feature for adding addresses in FOLIO. You can see it both in the view and edit mode of any user record.
FOLIO users can have 0 to many addresses
For example, they may have a home address, a campus address and an office address
Each library will configure a set of custom Address types (e.g. Home, Campus and Office)
There won't likely be more than 5 of these Address types
Every address must have an associated Address type
There should only be one address of each type allowed (this is a change of requirements coming from the SIGs)
There must be a way to select one and only one "primary address" which the system can use for mailings
Most addresses, like most other user data, is not entered manually in FOLIO. In general, they will be coming in from the user import feed.
That said, there does need to be a way to add addresses manually in FOLIO and we are working on making sure that the user import feed will not clear out addresses (or other data entered manually) in FOLIO
The fields currently include in the Repeatable address fieldgroup component is correct, but if you need more details, the user metadata spreadsheet includes specifics on all the data elements specified for the user record: https://docs.google.com/spreadsheets/d/121RpsJNaewhQEKb7k58eNVIhZ7N9oSWowNRJGYjPJ2M/edit?usp=drive_web
Some things to look at in particular when evaluating this feature:
When a user has multiple addresses, should the "primary" address be the one that displays in the view mode/preview pane for the user record? Right now, the first address added is the one that displays by default even if it's not the primary one.
Are you tempted to click the "Remove address" buttons on the edit page to save them (or even to save the page as a whole)? I find them really tempting and have nearly deleted addresses accidentally on several occasions. Also, Kimie has drafted some Proxy designs that make use of a trash can icon for delete. Let's decide if it's okay to use that icon instead and then use it in both places.
Is the grey "Add address" button the right color/right place?
I am thinking about asking the devs to disable/comment out the ability to edit addresses from the User details preview page for now. It's really the only user information that is editable from that page (since we haven't yet implemented inline editing) and it feels out of place and inconsistent. It's also one more piece of functionality it'd be better not to have to maintain unless we need to. Thoughts?
There are some completed proxy assignment designs that have a bit of conceptual overlap with this feature. Let's make sure we look at those when revising this. https://www.dropbox.com/home/FOLIO%20UX%20Designs/Users/User%20Proxy
Validation:
How do we ensure that one and only one primary address is selected?
How do we ensure that only one address exists for each address type?
Other than that, there really is not validation needed - we are intentionally keeping the data validation very light for user records in FOLIO. Most of this data is coming from the user import feed and will have been validated in the source system before it made its way into FOLIO.