Should be able to navigate to specific panes
Opened this issue · 4 comments
The ability to link to specific panes for specific resources would give new possibilities to improve the user experience. For example, sharing panes could link to a specific pane for the profile document to allow users to manage trusted applications.
Unlike many routing systems we cannot use the fragment-part (#) of the URI for this, as that would collide with referencing to specific parts of the resource. We would probably solve this by using a query-parameter instead, e.g. ?pane=trustedApp, which reads as "if the trustedApp pane is available, open the resource with it".
By appending this to the URLs when exploring various panes we also allow for better support with browser navigation buttons.
Just challenging one assumption here: how often are multiple panes relevant for a single resource?
In other words: perhaps we should consider just loading a single pane for every resource. In this example, if a sharing pane wants to link to trustedApp, could it not link directly to a URI representing the user's app permissions list, which would then automatically open the trustedApp pane?
The data/source/rdf/etc panes could simply become functionality of the global data browser rather than of a pane.
Just challenging one assumption here: how often are multiple panes relevant for a single resource?
A single resource might represent information about a lot of various types of data, e.g. a document can be a chat resource, a calendar resource, and a blog post resource all at the same time.
We also are going to almost always have multiple panes for a single resource - there will probably always be a default pane, showing general information if no other panes is better suited. But you will also have panes with metadata, such as the sharing pane.
I think what this comes down to is how we understand a URI and what it represents in the context of Solid (or what it represents when a resource is served from a Solid server). Lets continue that discussion over at #90.
As concluded in "How should the data browser treat query values in URIs?" we cannot make any assumption about query values in URIs. But I do think there are value in storing certain states in the URI for the data browser. I've used this issue as an example, but I imagine there might be other states pertaining to the data browser we might want to convey via the URI (e.g. to allow people to refresh and still get somewhat the same view they had before refreshing).
I'm wondering if it's ok to use the hash for this? Something like #me!foo=bar that conveys the property foo with the value bar, and that the data browser strips everything before the bang sign so that it still knows to refer to {uri}#me as the subject of the data browser. I'll do some more research to see if there are better characters to use for this, something that maybe escapes the hash part so that window.location.hash still refers to a fragment in and of itself (and we have to manually parse the URI state variables, but that we have to do anyway).
Just to note, I assume we should use safe characters to convey this in the URIs (these characters are well explained here, and can be derived from Fragment section in RFC 3986).
I've done a bit of experimentation, and haven't found any escaping characters to the hash (and I need to address other issues), so I will assume that if we go for this approach there is going to be a bit of work to parse and build URIs...