As mentioned in last week’s This Week in Solid the data browser team at inrupt are about to introduce a new feature into the Solid data browser that will affect the number of views that are presented by default.
We are introducing a feature we call User types. These are classes denoting some type of user that you can self-assign to help the data browser reason which views and functionality that is probably interesting to you. These settings is stored in your preferences, which are private by default, and we don’t assign any user types to anyone by default.
The reason for why we are doing this is ultimately to create a better onboarding experience. The current number of views and features that are available to users by default is very high - we have almost 40 views (aka panes) bundled with the data browser. Some of these are also difficult or confusing to use, so we want to hide them from new users and reintroduce them when we’ve made their functionality more accessible to non-technical users.
The user types that we are introducing are Developer and Power User. You can self-assign them via Preferences, which are or will become available through the Dashboard. You can test it on dev.inrupt.net, which sports the latest version of the data browser.
We also plan to push these updates to solid.community and inrupt.net as soon as we’ve been able to fix some smaller bugs.
Hi @megoth just a thought on User types and browser features; if you assume that a “Developer” type wanted to a build a little Solid website on his pod, if there was an “+” a webpage feature, you could create a simple webpage template that had an embedded ontology tool baked-in; maybe an inline popup that allowed the webpage creater to add/ bind linked data to specific elements within the site page; basically like you would if you were inline editing text in a page except you would be adding linked data which would be placed in your pod as rdf. I would think that such an inline LD editor might have various levels of complexity ranging from the very basic default mode where a very minimal or modest amount linked data is input, to the very complex, allowing for very complex ontology sets to be used and populated
Just to note: Have you tried using dokieli? It’s available as a view in the data browser, and also allow you to create dokieli-documents. Dokieli documents are simply HTML documents, but with the dokieli editor tools that allows you to insert RDFa and other LD-stuff to your HTML documents.
I’m not sure about types, they seem rigid and could discourage exploration and learning. How about tasks: Building website, document creation, analysing pod, managing pod structure. Just off the top of my head.
Within these you can have default and advanced features to give further control of complexity. I think this gives somebody access to the tools and features for the job in hand, while providing the opportunity to learn by branching out into a new activity - creating a gradual learning environment.
Since these ‘task modes’ can be combined, users can enable and disable sections of the UI and have everything available, or just the basic features for one task, or any combination in-between.
Going a little further, I’ve always liked designing UIs so that the feature you need is available just at the point you are thinking, “now I want to do X”. Not intrusively as in “would you like to do X”, from an assistant, but passively. For example, a section of the context menu that adapts to task and context.
I did look at it very briefly when i started looking into Solid but skipped over it because I didn’t really fully understand how to use it. I spent a few hours last night creating a single page in my pod and after reading the docs, I was still a bit lost; i’ve joined the gitter chat so i’ll read through all that from the beginning to learn a bit more.
Tasks is certainly another approach that gives some interesting possibilities. Let me just say this: User Types is not written in stone (tbh, I’m open for other names than User Types as well), it’s just one approach that we decided to go with this time around. I think either approach has some UX-challenges, and so for later iterations we will want to do more research into how this will be used and understood by users.
An intuitive design is one of our goals, but how to get there is rife with challenges. So all feedback are welcome
@megoth I just read https://megoth.inrupt.net/public/SolidDataBrowser//current.html#user-types---developer-and-power-user
It’s a good ‘update’ for those who, like me started discovering the databrowser some month ago
And asked myself if the UserTypes/ Roles are described somewhere in turtle format, so I could visualize it with my Spoggy app?
Something like :
_:FolderPane _:useClass _:Container.
…
_:AccessControlPane _:useClass _: Authorization.
…
_:MeetingPane _:usedBy :_PowerUser.
…
_:PowerUser rdf:type hola:Role.
_:Developper rdf:type hola:Role.
???
I’ve mentioned hola:Role because as I think a Pod is like an autonomous organization that can change during time, and that your Usertype is quit similar with the Role in Holacracy https://www.holacracy.org/constitution
