Uploaded image for project: 'User Experience Design'
  1. User Experience Design
  2. UX-44

UX: Review Repeatable Address Fieldgroup and Provide Guidance



    • Template:
    • Epic Link:


      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:

      1. 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.
      2. 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.
      3. Is the grey "Add address" button the right color/right place?
      4. 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?
      5. 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
      6. Validation:
        1. How do we ensure that one and only one primary address is selected?
        2. How do we ensure that only one address exists for each address type?
        3. 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.

        TestRail: Results


            Issue Links



                kkester Kimie Kester
                cboerema Cate Boerema
                0 Vote for this issue
                2 Start watching this issue



                    TestRail: Runs

                      TestRail: Cases