[UXPROD-2191] Agree the correct behaviour for links and navigation between apps Created: 25/Nov/19 Updated: 08/Jan/20 |
|
| Status: | Draft |
| Project: | UX Product |
| Components: | None |
| Affects versions: | None |
| Fix versions: | None |
| Type: | Task | Priority: | TBD |
| Reporter: | Gill Osguthorpe | Assignee: | Unassigned |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | ux-todo | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original estimate: | Not Specified | ||
| Attachments: |
|
||||||||
| Issue links: |
|
||||||||
| Description |
|
Note: this is relevant for links between any apps, not just Agreements and should be aligned with any other work on cross-app navigation. In ERM linking between apps is very common. When previewing an agreement or a license the user is able to view records in other apps by selecting a hyperlink. The below screenshot shows two user cards displayed in the Agreement preview. Selecting one of the links (i.e. the user name) opens a preview of the user's details, in the Users app. There are issues with the way the movement between the apps via links is implemented currently. 1. Behaviour is inconsistent, as can be seen in the attached screencast. When selecting a link to a User the user's details are displayed in a full-width pane. When selecting links to other apps, the record's details are displayed in the search and sort UI with the preview pane opened on the right-hand side. Sometimes records are listed in the search results pane (either with or without the current record highlighted), sometimes there are no records listed in the search results pane. The latter approach always gives focus to the Search and FIlter pane - to meet accessibility requirements focus should be given to the record preview. Can this be changed? 2. Navigating back to the original Agreement record has some issues. Using the browser back button means that users loses his/her place in the agreement because all the accordions are collapsed. Selecting the Agreements app icon in the horizontal navigation menu has the same effect. How could we manage cross-linking better? Could we make it easier for the user to return to the original record? When returning to the original agreement record can we retain his/her place on screen/state of the preview? Should we open links to other apps in a new browser tab? Should there be a breadcrumb trail? |
| Comments |
| Comment by md331 (Inactive) [ 10/Dec/19 ] |
|
This is an issue that needs to be agreed upon Folio-wide before we go about doing stuff with this. |
| Comment by Gill Osguthorpe [ 13/Dec/19 ] |
|
Heya Filip Jakobsen if you could share the work you've done on cross-app navigation that would be great. Or, if there are other Jira issues covering this already we could maybe close this one down. |
| Comment by Filip Jakobsen [ 13/Dec/19 ] |
|
Thanks for the comment, Gill Osguthorpe! Back to previous app What to show when clicking on a link to another app |
| Comment by Gill Osguthorpe [ 16/Dec/19 ] |
|
1. What to display in the destination app:- full screen record (is in hand) |
| Comment by Filip Jakobsen [ 06/Jan/20 ] |
|
Gill Osguthorpe, for your question no. 3, I am not sure. It looks like in the current system the state of an app that is reopened in the same session as it has previously been opened, is controlled by the URL. The accordions are currently not related to the URL, and I know there has been talk for a long time in the project about routing refactoring. John Coburn, might you be able to weigh in on this question (i.e. whether it would be possible to open an app with the interface intact and the same accordions open, currently; and in the future, after routing refactoring)? |
| Comment by md331 (Inactive) [ 08/Jan/20 ] |
|
Filip Jakobsen, it's not supported currently to preserve things like accordion state. It's definitely possible though, with help from the browser. We could be storing this to the browser's local storage and just checking that storage to see if there's something there we should use when initially loading the Accordion. It'd require a bit of extra work in the Accordion components, but more annoying would be updating all the apps to take advantage of this functionality. We'd probably have to make it opt-in from the app's point of view because most apps use "uncontrolled" accordions, where the state of the accordion (open/closed) is contained in the app code, and not the accordion itself. We do have "controlled" accordion sets where the accordion state is stored in the accordion itself though, and that seems like the cleanest place to add support for preserving accordion state. So apps would need to switch from using uncontrolled accordions to controlled ones. I think most app developers would welcome the change since I personally hate having to manage my own accordions for my basic use cases. |