Scott McWhirter @konobi mentioned the possibility of creating a visual language for Solid and mentioned these to links as references for what he had in mind.
Saw @Frank’s introduction (welcome to Solid Frank!) mentioning the design background and thoughts about online interfaces. Would love to see these lines of thoughts come alive…
What visual elements do you think are needed for Solid design?
Is this not out of scope of Soild? Should applications not be designed in whatever way the developers seems fit, regardless of the fact that they work with Solid or not?
I’m not sure. On the one hand, you’re completely right, Solid is not the presentation layer, but the underlying protocol.
On the other hand, it is important that end users understand the behaviour of the underlying system even when they use it via a lot of different apps. And the more options this protocol gives, the more important is it that people can grasp it.
It probably boils down to strongly suggesting a shared nomenclature instead of specific visual design elements.
Could you elaborate on that? Do you mean that they need to understand Solid? Or the way that the app works with Solid?
Sure indeed, but that guidance is, in my opinion, unrelated to Solid. I would it find really confusing if Solid now suddenly gets an “UI spec”, next to the spec that we have now.
Let’s assume someone built a health-tracker on top of Solid - the kind of service where being assured that the data is stored on a personal pod instead of some unknown internet part is actually a big selling point.
I’m using that app and also use the same pod to store my jogging activity logs that I regularly share with my friends on social media for bragging rights (“look, I made this run under 50 minutes today!”).
When I next open the social media app and say “share something from my pod”, I need to understand which parts I’m gonna share, and with whom. If all apps use a different data browser with a different design language, I have to re-learn this part for every app, to be sure that I’m not accidentally sharing the wrong thing.
For comparison: Right now, sharing things or giving access to stuff on my computer means that I’m uploading it to each new platform. And the uploading function always gives me my local computers file dialog, so I can be pretty sure of what I’m sharing.
Is this necessary for the technical part of Solid to work? No, not at all. Would it help increase adoption if there is such a common visual language? Absolutely.
With the current state, where each app and service on the web has their own datastore, it is safe to assume that the data that the health tracker uses is completely separate from what the fitness app can see. That is actually a reassurance for people. “I know that the fitness app cannot see this, because it is on another system”
But as soon as I store both datasets on the same pod, some anxiety can creep in, and it becomes important to reassure people “yes, this is still being kept separate!” Hence the suggestion of a coherent visual language as one way to address this.
Which is where the “app” access control comes into play. Se Timbl’s explanation in this thread: Inter-app access control - #19 by timbl - short version is “no web-app can access any of your private data without granting explicit access to the web-app”. You have to, per webb-ap, grant it access to a specific part of your data.
Bonus: How many users will then say “uh… no idea, but I want this app to work, so… allow”? The problem with privacy is often enough that users find it tedious to defend their data in a finely grained manner and issue blanket permissions because they just want the thing to work. This is not a problem of the technical specification, this is a problem of the presentation layer.
To quote myself:
Snarkiness aside: Such access control is indeed vital and this isn’t about whether it is there or not. Of course it is there. I ask that we put in best practices on how to display this to the end users into the first few rounds of example apps, so that there is a baseline that users expect when handling Solid. So they won’t accept such blanket statements as above in future apps.
I think a component library like react-components is really important, but it should be able to accomodate different visual languages if possible. I’m not very familiar with the concept of visual languages but I’m assuming that refers to the things CSS can do.
Well, all of them - they won’t work without It is actually built into the Solid spec AND enforced by code on the server side.
Yeah, that is a problem.
Completely agree. Unfortunately no one has been able to show me how it is actually done. You are supposed to, manually, write some Turle statements in your access control files, but even as a programmer I find it very hard to figure out what to write.
So there is definitively room for some huge improvements here - what I have seen so far is completely obscure and unsuable (but hopefully someone can prove me wrong on this).
There’s also more to the project than just the code that constitutes the UI, there’s also the website, documentation, resources, articles to take into consideration as to what such a system could be applied to.
I don’t believe there’s anything inherent to a design system that would “enforce” it upon an app developer, but there’s a lot of value in having a sensible/reasonable default. There will be app developers who want to develop their entire UI/UX workflow for themselves, but many may prefer to use something akin to “native” for expediency. I can also see some apps wanting to be used as a way of extending other apps or allowing the user to enhance aspects of their UI/UX. Shared tooling can also be a big productivity win.
To me, the goal of a design system is establishing a way to ensure that everyone at least starts from the same page and can build their knowledge from there. That’s important for users of the system, but it’s also important for contributors to be able to get up to speed easily too. I think a design system is a reasonable method to incubate a compelling and approachable environment for new contributors/users.
First of all, we need to understand and define, Why, What, How and When, a Visual Language/System for Solid.
My background is building a Design System defined as “Design System” and large front-end ecosystem for the past 3 years now, attending seminar with Brad Frost (Mr Atomic Design) and organising powerlunch on this topic. Working with Front-end since 1998 more or or less, so I have a very “solid” experience in this subject, because a Design System + Component library + (…rest) has to take everything in consideration.
WHY
Any type of system today that has a UI and a core usage, for example with Solid and the data browser, to be able to scale and let 3rd parties enter the arena, you need to have a visual and also a technical guide line for how things should be done to be able to feel harmony in that ecosystem.
If I make something totally new for example a “Solid Quiz”, there should be very minimal effort in implementing a UI and Front-end if there is a good documented guideline of best practice, UI components etc… that I can use to implement my solution.
The Solid technology itself can be a big bottleneck for people to get started, so aiding with a good Design System, will for sure ease the pain.
WHAT
The best principle today according to me is Atomic Design as a base for your Design System.
Specially for Solid, I strongly recommend “Semantic validated” HTML references for components (atoms, organisms, etc…)
Let the community choose the flavours they like, for example Styled Components, React, Angular etc… So the UI should maybe have React/Angular examples, or select one for total implementation on a better Data Browser.
“separation of concerns” is most important, everything srehould be provided on their own repos, for example “solid-styles”, “solid-react-components”, “solid-html-templates” etc…
A thing that many people miss is the importance of “language”, so I strongly suggest to add a “solid-language” repo so the community can help out to translate words that are common for the Solid world.
The design and UX should be functional, focusing on readability.
HOW
The first release of Solid UI, should at-least deliver the Styling and HTML semantic snippets in their own repos, the “React/Angular” or what ever you choose for a component library is not that important.
The community will pick what they like the most anyways. If the first Solid UI is implemented on a better data browser, that would be AWESOME.
WHEN
The sooner the better. It is a bottle neck today for people that want to develop good UI on Solid technology, the lack of such UI.
I suggest that after the release of the Solid UI, that you start a thread here so we the community can start to give feedback and help out to improve it.
I meant to get back to this thread earlier, but have had an intense couple of weeks.
@eduardoinnorway I believe there’s a good line of reasoning here and deserves some attention.
My question would be, what is the next step in moving forward with this evaluation? What do you believe is needed to make forward progress on this?
Are there tangible resources required? A repository, some hosting, subscription to (pre-existing) design system management software?
Are there things that the community (as a whole) can do or provide to support? A sense of community consensus, explicit community assent or establishing an RFC process?
I’d have other questions for further along, but for now I’d be primarily concerned with finding what would make it easier for yourself and others to contribute in a way that you’d feel supported and that your contributions would effect the change you want to see.
Not sure what this all might be or what may be needed in the end, though I think getting out in the open as to what would make the process easier would be valuable in and of itself.
But in specifics, I meant this: