Browser navigation in SPA: Which changes to UI state should be preserved in URL for the purpose of URL state synchronization?

Question

URL state synchronization allows users to navigate to specific SPA page and see specific state. This is important when you share SPA page and you want the recipient to see exactly what you saw when you shared the page.

Question 1: Should all changes to UI be preserved?

Question 2: When is it ok to replace URL state synchronization by other method?

Example 1: Jira Roadmap

https://confluence.atlassian.com/jiraportfolioserver/what-is-a-plan-952623577.html

Re question 2 - None of the changes to this view are reflected in URL. However, there is a dedicated Share button that generates unique URL containing the state that can be shared.

Re question 1 - Changes to filters and fields will be reflected in the unique URL, but not field (column) ordering, width or visibility. If I share this to a colleague they will only partially see what I saw.

Example 2: Jira Dashboards

https://www.atlassian.com/software/jira/guides/reports-dashboards/overview#what-is-a-system-dashboard

RE question 1 - Jira Dashboards won't synchronize any of the states. Your colleague will literally have to tell you "go to this dashboard, select this team, this project and this issue type and then you will see what I mean".

RE question 2 - While none of the sate can be shared, it is at least synchronized between sessions. Refresh the page and all selections and filters will stay the same.

Example 3: Jira Find Issue

https://support.atlassian.com/jira-software-cloud/docs/find-specific-issues/

Aa much as I can tell every filter and every setting is reflected in the URL. Browser navigation button will take you through every change you made. This is how it used to be in the good old days.

Example 4: Google Spreadsheets

All change to the spreadsheet, including column width, row height, color and visibility are preserved. But the URL does not change and browser navigation buttons can't be used - instead there are dedicated undo/redo buttons.

Back to my questions:

Should every detail of the UI be preserved and synchronized? Including column widths? If not, where do I draw the line?

Should everything be synchronized in URL and work with browser navigation buttons? If not, where do I draw the line?

Answer 1

It all depends on context and user needs. As a rule of thumb I would stick with the intended use of urls, to locate and identify a resource. I added a little background info below.

For a SPA however, the question is, what is your current or main resource? In the Jira dashboard there are many components that are equally important. The url still has to point to a resource so that would be the dashboard itself, not the individual components. However there's nothing wrong with adding every detail for each component in the URL except from that it might make no sense to the user. In Google Spreadsheet, the spreadsheet itself is the current resource and everything that identifies this resource is present in the URL, including presentational details.

However there is no right or wrong as long as you are serving your users well. Maybe it is confusing for Jira users when they get a URL from a colleague that hides things, shows columns in an unreadable manner etc. What is useful for the colleague that shares the URL maybe is confusing for the receiving colleague. It is something Atlassian might have concluded from tests or user feedback. Or maybe they wanted to keep their URL's readable and manually maintainable for users but found out users still needed a way to share the exact state, so they added a button for that. Who knows?

Question 1: Should all changes to UI be preserved?

Only what makes sense for the user to share. Mostly this is what the main resource on the page should contain, not always how it looks.

Question 2: When is it ok to replace URL state synchronization by other method?

It's ok to have a backup method when the current state can cause confusion when shared, but there is still a need for sharing it in some occasions. For the current user it makes more sense to have the exact same view when doing a refresh, but that's what session storage can solve as Jira shows as well.

---

From RFC 3986:

§3.3 Path (the part of a URL between the host and and ? or #)

The path component contains data, usually organized in hierarchical form, that, along with data in the non-hierarchical query component (Section 3.4), serves to identify a resource within the scope of the URI's scheme and naming authority (if any).

Hierarchical form meaning:
/resource/child-resource or /products/product-type-x/product-id-xyz

§3.4 Query component (the part between ? and #)

The query component contains non-hierarchical data that, along with data in the path component (Section 3.3), serves to identify a resource within the scope of the URI's scheme and naming authority (if any).

Non-hierarchical form meaning:
/products/product-type-x/list-all?sort=date&order=desc giving the same "list-all" resource with different presentation aspects.

Answer 2

Should every detail of the UI be preserved and synchronized? Including column widths? If not, where do I draw the line?

Definitely no: Talking of column widths, they shouldn't, as the window width also shouldn't be preserved. If I have a smaller/larger screen than the person who created the link (maybe myself on another device), I want my current screen size to be used, and dependent dimensions (e.g., column width) be derived from that.

There's no easy answer about the line to draw. I'd say information should be preserved (selection in table, column sequence) while presentation (column widths, table scrolling) needs not be preserved. But that depends on what is considered important to share and thus is domain knowledge. Also, when adaptive design is used (different information shown depending on screen size), preserving all will be hard.

Should everything be synchronized in URL and work with browser navigation buttons? If not, where do I draw the line?

I'd classify this as an implementation decision. I recall times when we couldn't preserve all state information in URLs because there was a size limit.