I would like the ability to save my current screen as a bookmark in my browser (with filters/combined filtering e.t.c. just the current state). So i can revert back to that page. Not by “deeplinking”, but the behaviour that web Outlook 365 has when you switch between folders. This means i could also use my back and forward buttons in the browser.
For example i would like to see this happening when switching to a different document:
When i switch back to “applicaties” i would like it to see it like this:
I think this would improve the usability on the interface.
Some research has already been performed for the Universal to incorporate routing / hashtag navigation via the URL. The Universal GUI forecast topic mentions History browsing on the backlog and some ongoing effort has gone into Technical research history browsing.
The most challenging aspect is to reconcile the multi-document interface with the single-page navigation behavior.
To illustrate, a number of functional challenges arise which need to be addressed:
Document uniqueness
A document can be opened more than once. Via detail tiles, process flows or when holding the Control-key while opening a menu item. This means we need to differentiate between these documents in the URL to allow them to participate in history navigation. However, this would make bookmarking a bit odd as you probably don’t want to bookmark this specific document, but the current state of the document.
Document-navigation or in-document navigation
To what extent do we store screen information as history in the URL? The active document is indeed a no-brainer, but when we include the (recursive) active detail tab page? Or the active row? Including this in the history browsing would cause a whole different browser back-and-forward experience. Furthermore, the rows may no longer be available or context logic may prevent access to certain details.
Document initialization
We need to allow the user using a bookmark to initialize a new document. However, when you've closed a document, will the ‘back’ button re-initialize this document? Documents can be initialized through process flows that cannot be reached normally. In these situations, it might be undesirable to allow the user to re-open this document. Alternatively, closing a document could cause it to remove itself from the history browsing entirely but this may not be what an end user expects.
Process flows
In all these history navigation actions, will activate-document or open-document process flows be started?
These examples are not exhaustive, but do illustrate some of the the challenges. We’ll work towards an MVP of history browsing first that supports the most basic situations and iterate on this further to address challenges as described above.
We’d love to hear your views and input on reconciling the multi-document interface with single-page application navigation.
Great explanation Anne!
This 'wish’ is really a hot topic for our clients as well. They want to be able to send a link to eachother to open the exact document / task that was requested.
In my opinion:
You'll want to have a combination of url and query parameters in order to fully support multiple open documents. Where the basic url is the current active document.
Process flows - (and popups) should not be part of the history. This can only lead to errors.
A very nice first step would already be that the current active screen is bookmarkable.
I see that this has been in the Universal release@Mark Jongeling known as history browsing.
Since the last Universal version we have https://url/#application=28/subject= etc in the browser bar. This is really awesome and makes the application better bookmarkable/linkable. Really like the
I was just wondering why did you use the application id over the alias? Since with every deployment the id changes.
I've already run into the ‘application unavailable’ message. This does not have to happen. Users tend not to understand this.
By using the number instead of the alias it is not bookmarkable or usable in mail, because after a deployment it has changed.
Is this something that will get updated/still work in progress?
Thanks@Sebastiaan Meijerink I think that the alias maybe must become a mandatory parameter for applications. For example also third party applications that call the api need that, and if you don't set an alias this also fails every deployment.