The work on the data browser has been quite technical minded for now, and based on the feedback that I’ve gotten from the UX-team I realized we need to find a better, common language to describe the various aspects of the Solid data browser. To that end I’ve started work on describing the current Solid data browser with the intent to make it easier for people to understand what it is currently doing. I’m trying to describe the conceptual model as well as the technical model, and hopefully we can find ways to talk about the data browser that reconciles with both of them.
The document is available as a simple HTML document. I wanted to enable dokieli for the HTML document so that people could annotate the document with their comments, but experienced a bug with the sharing pane (am researching this to create an issue so that we know how to fix it). If you have feedback on the document, please use this thread.
The document is still a work in progress, but I think it’s valuable in the current state to A) express how I understand the current data browser, and B) get the conversation started on how this mental model can be improved and shared better, so that we all share a common language for the data browser.
I will continue to work on this document, and update this thread when I update the content in the various resources.
Thank you for making this available, because this really helps to get to know the data browser and its possibilities better. Fwiw, these are just some notes I made.
“The reason we differ…” isn’t clear on who or what its different from
“This explanation leads some people into thinking that panes are simply another word for components, and although the composite pattern is a possible design pattern to use, we try to avoid it since panes technically can utilize other types of components.”. But components can use different types of components, so it still isn’t clear why panes can’t be (or at least aren’t yet) components.
“The reason for this big change is that the current resource that is loaded is not focused on the document that is located at https://megoth.solid.community/profile/card , but the subjecthttps://megoth.solid.community/profile/card#me that is located within this document.” If there is an easy way to switch back and forth between them, then that would be worth pointing out.
Arne recently mentioned the goals of the Data Browser, which really helped me in understanding why we’re working on it, which features might belong in there and, perhaps just as important, which do not.
So I thought it’d be good to share the notes I took on that.
1. Inspect data
It is useful for users to be able to see what data has been written to their Pod by the apps they use, and especially for developers to verify that the apps they’re working on do what they expect.
2. Set authorizations
Users should be able to inspect which third parties currently have access to their data, and to be able to revoke those permissions to prevent future access.
3. Link data to applications
If we know which app is most relevant to certain data, the Data Browser can be a good way of getting (back) to that app.
4. Expose related data
Arne did not know the specifics of this, so it’s a bit vague, but luckily it’s also the least important feature. There’s supposedly some predicate that indicates “related data”, so when you’re viewing a specific piece of data, the Data Browser could surface those relations.
Thank you for your notes. The last couple of days has been hectic, so excuse my late reply.
“The reason we differ…” isn’t clear on who or what its different from
Will try to make this clearer.
“This explanation leads some people into thinking that panes are simply another word for components, and although the composite pattern is a possible design pattern to use, we try to avoid it since panes technically can utilize other types of components.”. But components can use different types of components, so it still isn’t clear why panes can’t be (or at least aren’t yet) components.
There is a difference in the interface of these components, which I think makes it more troublesome to mix these types of components. I think this is what is meant with “The composite pattern describes a group of objects that is treated the same way as a single instance of the same type of object.” E.g. now that we will introduce React into the data browser, we can talk of React components and Data browser components. We can use components as an umbrella term for these types of components, but won’t it make it more confusing?
“The reason for this big change is that the current resource that is loaded is not focused on the document that is located at https://megoth.solid.community/profile/card , but the subjecthttps://megoth.solid.community/profile/card#me that is located within this document.” If there is an easy way to switch back and forth between them, then that would be worth pointing out.
Hmm, how easy it might be is in the eye of the beholder, but I can make a side note about making that aspect more intuitive.
Thanks for putting this together. I still find the data browser incredibly unintuitive to use, but at least I now understand a bit of the background to it and why it is as it is. I’m sure it’s nothing a good UX designer couldn’t sort out - or are there complications due to RDF etc?
There certainly are challenges Linked Data poses that makes developing apps for Solid a bit different from what’s the norm today, but nothing I think we can’t find some good solutions to
We have some highly skilled volunteers and UX designers working on this, so I expect some major improvements to the data browser coming months
@megoth it would be nice if we could have some mockups of the future browser… As developpers of front apps, it’s a little bit hard to convince our users to manage their data with the actual browser
