Open josephguillaume opened 3 weeks ago
A minimal implementation could provide an additional pane with links that open the resource in other apps.
The same pane could allow managing a set of external app registries to draw from, and managing preferred apps.
The pane would be visible for all resources. It would therefore be very prominent and may not provide the best user experience.
Looking forward to SAI support, the pane could also manage trusted application settings related to the specific resource, in the same way that if SolidOS ended up acting as an authorisation agent, it would grant access to each specific app prior to being able to open a link. The pane could therefore be seen as a resource-specific app management pane.
Here's a mock-up using ionic components:
I assume adding a dependency on ionic is not desirable, but if the general UI/UX is suitable as a pane, then the next step would be to make it operational, and then the CSS+interactions could be reimplemented later.
SolidOS using the data browser hack is in a privileged position where its registered panes are the default view when navigating to a resource. Even if dynamic panes become possible (https://github.com/SolidOS/pane-registry/issues/28), this provides an inward-focused experience rather than encouraging interaction with a broader ecosystem of specialised apps.
It turns out that in the context of SAI and the principle of least privilege, there is also the opportunity for SolidOS to act as a bridge to enable follow your nose between apps. https://github.com/solid/data-interoperability-panel/issues/325
I'm opening this issue to discuss what user interface SolidOS should provide to help the user open a resource in another app.
As test cases, one could consider offering to open: