Has any work been done to standardise UX patterns for logging into Solid applications?

1

Amongst the Solid applications that I have used, there is some variation in what information the initial form for logging requires and how that information is described. I will briefly summarise a few approaches to illustrate what I’m talking about but I’d first like to state that these are all apps I love and IMO have driven Solid forward so this should not be read as criticism of any of the applications or even the Solid specifications, just a starting point for a conversation.

All of the following applications have a form with a single text field and a call-to-action (CTA) to submit it to begin the log in process. The variation I’m interested in here concerns the way that the text field and CTA are labelled (restricted to the English language versions) but most importantly what is expected in the text field.

  • Penny says “Connect your Pod at:”. The CTA label says “Connect” and the text field auto-suggests “https://solidcommunity.net”. If I enter my WebID, I get an error message saying “Could not find a Solid Pod at …” but entering the URL for the storage root or that for my identity provider work fine.
  • Media Kraken has no label for the text field which is pre-populated with “https:”. The CTA shows the Solid icon and is labelled “Log in with Solid”. I can successfully log in by entering either a WebID or my IDP (I tested with my inrupt.net Pod so NSS I think).
  • PodPro has a title saying “Log in to your Solid Pod”. The text field is labelled “Your ID provider” and has “https://broker.pod.inrupt.com” as an example entry. The CTA is labelled “Log in”. Despite the fact that the label asks for an IDP, entering the storage root for my Pod (again inrupt.net) is successful too.
  • Inrupt PodBrowser has a context-free “Sign in” button which I gather assumes https://broker.pod.inrupt.com as the IDP. The text field is hidden by default and the user has to click “Sign in with another provider” to reveal it. It is labelled “Where is your Pod hosted?” and has some well-known identity providers as auto suggestions. The CTA is labelled “Go”. Again I was able to log in by entering either my Pod storage root or IDP but not with my WebID.
  • SolidOS as hosted at https://nickform.inrupt.net has a modal with a text field labelled “Enter the URL of your identity provider:” and a CTA labelled “Go”. Below are a list of secondary CTAs labelled with some well-known identity providers. Again, logging in worked if I gave either my Pod storage root or IDP.

I was able to log in to all of these applications with only a few missteps but I did resort to using my browser’s development tools to understand what was going on and in general it seems to me that having this much variation from one application to the next is a major obstacle to large-scale adoption. We’re up against the straightforward processes of logging into Facebook, Google, Twitter. Solid has the conceptual overhead of understanding what the application is and what the Pod is (c.f. Facebook, Twitter where there is only one “thing”) and how they relate to one another. Introducing “identity provider” as something the user has to really be conscious of gets us to three concepts and already many combinations of these. This level of complexity will already disenfranchise huge categories of users. It’s also a burden to have to remember the URL of the identity provider that goes with each pod I own, especially when it is not just the apex domain of the pod (as is the case with broker.pod.inrupt.com). My preference would be that I can log into any application by giving my WebID as this is the identifier for me and presumably will be a valuable thing for me to memorise for use in other contexts. I understand though that there may be concerns that WebIDs are rather long for non touch-typists or, likely, many other considerations that matter to people.

So my question is: is anyone working on defining UX guidelines for Solid applications in general or in the specific field of the experience of logging in? What is considered best practice in this area and how confident can developers be that this best practice is stable from this point onwards?

Thanks for reading.

6 Likes
2

I’m not aware of any standarized best practices, but I’d certainly like to see them :).

As you mentioned, one issue is that users may not be familiar with Solid that much, so I’m hesitant in mentioning “issue provider” or even “webId” in the UI. That’s why I decided to just say “Log in with Solid” and I try to make that work with anything they type. Ideally, I’d just ask for the issue provider, because that’s what the authentication library needs. However, I think for users it’s easier to write their storage url or webId. So what I try to do is, with the url they type, search for a webId and if I find it, read the issue provider from there. If I don’t, I just pass whatever url they typed directly into the authentication library.

I’ve always thought the best UX would be to have a browser extension that users have to manage their Solid identities, and with that they won’t have to type anything. For example, many apps in the web3 space use MetaMask to log in with a single click.

3 Likes
3

The <http://www.w3.org/ns/solid/terms#oidcIssuer> property seems to be absent from my inrupt.net profile (NSS I believe) but present in my inrupt.com profile (ESS?) and in new profiles I create when running the CSS. Since the latter two are in some sense more modern I hope that this is evidence of a growing consistency in the direction of allowing the user to begin the process by giving their WebID. It’s a shame that the authentication library does not support this directly though. Which library does Media Kraken use for authentication? You’re right to be hesistant to mention new terms like WebID but I think it’s necessary for users to learn that concept (a URL for you!) to be able to use Solid well and, if we could make sure this is the way every login journey begins, it will reinforce the familiarity as users try different apps.

Going back to UX, does anyone know of any groups dedicated to developing UX standards for Solid? Is there anyone who is leading a collective effort in this area that might be able to contribute to this thread?

1 Like
4

A ux-research chat room coincidentally was recently started, that I think @KyraAssaad might be able to tell you more about. I agree with you that this would be a good thing to focus on.

I can give the reasoning behind the observations you made about Penny (since I’m its author). I use “connect” rather than “log in” because Solid’s permission model isn’t directly intuitive for people, and “log in”, I think, has connotations that do not necessarily apply to Solid. For example, signing in doesn’t always mean that you have full access to view and change everything in that Pod. Conversely, it can also give you access to things in other Pods. And finally, logging in is commonly associated with entering your credentials, which you don’t do in the app - I’m assuming this is also the reason why Facebook’s button is usually labelled “Connect” as well, which this is consistent with.

As for not supporting entering a WebID: I simply thought this wouldn’t be possible. I just logged an issue to add support for that, although I do agree that auth libraries would ideally support that natively (@zwifi - is there a reason it’s not, or would this make for a good feature request?). I did hope that suggesting https://solidcommunity.net would at least give some indication that the expected flow was by providing the OIDC provider.

Also note that it autosuggests other common OIDC providers, i.e. if you type inr it will suggest https://inrupt.net and https://broker.pod.inrupt.com. It’ll also remember the last identity provider that you successfully logged in with, and offer to correct likely mistakes (e.g. if you type https://pod.inrupt.com).

Other than that I mostly agree with Noel. I really don’t want to burden people with concepts like identity providers, the technical possibility that WebIDs can be separate from your Pod, or even the idea that there isn’t even such a thing as a Pod, but rather a WebID that might point to zero or more storage providers. A single concept like “WebID” I could probably live with (in addition to “Pods”), though I’m also a bit weary about the baggage that term has, and how searching for it will give you standards folks babbling about the minutiae of it - something like “Pod ID” or “Solid ID” might be more appropriate. But that’s definitely not a call I want to be making individually :slight_smile:

And yes, longer term I’d also envision a WebExtension that someone could install, and a way for Solid apps to indicate how the extension can tell them about the user’s identity provider and start the auth flow. The extension could then prompt the user to connect to an app using standardised verbiage, and hopefully without the user having to enter credentials and URLs every time.

3 Likes
5

Yeah this is something that is not standardized yet, so I only use it if it exists (otherwise, I fall back to the domain of the webId or the url they introduced). But this is being looked into, so it may become part of the spec eventually. If you want more info about it, check out this repo: solid/webid-profile.

It uses two libraries at the moment: @inrupt/solid-client-authn-browser (the default one) and solid-auth-client (legacy). The reason why I’m using two is that Inrupt’s library is not compatible with some old servers, so I’m keeping both for backwards compatibility.

However, all the logic about what url to use for log in is in a different package: @noeldemartin/solid-utils.

Yeah, I agree with that and I would prefer to follow a best practice if there was any. I do prefer “Log in with Solid” for my apps, but if as a community we settle on a best practice to say “Connect with Solid” or whatever, I wouldn’t mind changing my apps to conform.

Something I’m conflicted about though is suggesting any pod providers. One of the reasons why I like Solid is the decentralized aspect, so I don’t want to reinforce using any particular provider. At the same time, we know most people will use a handful of providers because these things follow a Power law distribution, so it would result in better UX.

Another huge issue is where to point users who don’t have an account. Right now I am pointing them to the get a POD page on solidproject.org, but there’s a lot of things I don’t like about it. Right now I’m not focusing my efforts on onboarding users who don’t have a POD already, but if I were there’s a lot of things I’d probably change. @jaxoncreed wrote a post a while ago that touches on the topic, and there were some nice ideas in there: The Full Complexity of On-boarding with Solid.

2 Likes
6

Hei there,
quite an intriguing thread. A lot of good points!
I like Noel’s suggestion about a ‘browser extension’
Good point about the difference between inrupt.net(NSS) and inrupt.com(ESS) and CSS.
In the SolidOS team, together with individuals from other teams, we are working on some underlying issues:

However all these tasks are going to take some time, I would argue it is part of maturing.
Nevertheless, we would welcome this work of ‘standardizing UX’ (which goes beyond the under the hood code) - develop some prototypes (wink: browser extension), mockups, Solid onboarding App. (there were some attempts before too: GitHub - solid-contrib/solid-signin-ui: Sign In application).

2 Likes
7

@NoelDeMartin oh! we’re not? I’d be interested in knowing more? (I’m on the Inrupt Developer Tools / SDK team)

You might like the new getProfileAll methods (since 1.16.0): https://github.com/inrupt/solid-client-js/blob/main/src/profile/webid.ts#L73-L91, which do some similar things.

8

We do actually have some tickets on our backlog to add methods to support fetching the oidcIssuer predicate value from a solid profile IRI/Dataset, and for validating an IRI as a Identity Provider (it’ll be roughly this code: pod-browser/validateProviderIri.js at main · inrupt/pod-browser · GitHub )

I’ve mentioned these to @nicolasmondada, so hopefully we can implement them soon.

Also, something people may not know: PodBrowser also supports pre-defining which IdP to login with: https://podbrowser.inrupt.com/login?idp=https%3A%2F%2Finrupt.net

Screenshot 2022-05-13 at 18.34.31
Screenshot 2022-05-13 at 18.34.311398×1478 136 KB

So if you run a pod server, and wish to link to PodBrowser, you can use that to help your users login; I’m not sure if @Vincent’s Penny supports similar. I’d also agree that “connect” is better than “sign in” (but that’s my personal opinion).

1 Like
10

oh! we’re not? I’d be interested in knowing more?

I’m not sure why, I think it has something to do with old servers not supporting DPoP authentication. But I don’t know much about the technical details.

When I say “old servers” I mean really old servers. I’m still using NSS v5.2.2, which was released in November 2019. To be clear, I don’t recommend anyone using old versions (they have security issues). I just don’t care much because I’m using a self-hosted POD and I’m the only user. The main reason I haven’t updated yet is that I still have to upgrade one of my apps; as soon as I do I’ll upgrade my POD as well.

Also, notice that this limitation is documented in the library’s README. Maybe you can update that note to give more details, in case others wonder.

Cool, I’ll take a look to see how you do it :). However, I don’t think I’ll use it because I’m trying to minimize external dependencies in my apps. I use authentication libraries because it’d be too much work to implement that myself; but other than that I pretty much implement everything Solid-related from scratch.

Although I’ve recently been working with some authorization stuff, and working with ACP seems like a hassle so maybe I’ll eventually use Inrupt’s solid-client for that. I like that it has a common API for both WAC and ACP.

1 Like
11

Yeah, Penny does actually support that! Try e.g. https://penny.vincenttunru.com/?solid_server=https%3A%2F%2Finrupt.net

12

Hi all,
I’m Tim, a PhD researcher at the University of Ghent/Imec.
I see many of you raise the question if any UX standardization has been done for Solid interfaces. As I’m currently conducting research on the UX and interfacing side for SolidLab Flanders I’m very interested in your concerns and needs. Currently, I’m conducting interviews with (UX-)designers/developers who work on Solid interfaces to see their specific needs and how our research could help them design better interfaces. Anyone who’s interested in participating and sharing interests may always contact me via e-mail (tim.theys@ugent.be), so we can orient our research toward the needs of the Solid community.

3 Likes
13

Thanks for contributing to this thread @Tim_Theys_UX!

The reason I started it is because it seems to me to be particularly important to the success of Solid that the experience of signing in to applications be both great and, crucially, consistent from one application to the next. Of course every designer wants their app to have its own personality but if the experience of “signing in”/“logging in”/“connecting to your pod” is not consistent then I fear that the majority of users will struggle to perceive Solid itself as something of value. I think something as recognisable as the Bluetooth icon or the “Download it on the App Store” branding is needed. As an aside, I think that if there were a standard UI component for logging into an application with Solid that could also double as the way for an app to advertise itself as Solid-compatible.

Signing in also seems like a step in the process of using a Solid application that is already comparatively stable. Whereas it could be hard to define common patterns for Solid user interaction within applications as there still aren’t that many (any?) in production, I feel like the time is right to start to tackle the thorny problem of how to log in. The problem of onboarding totally new users is obviously very closely related and equally thorny.

Unfortunately, I’m a only a lowly developer and lack the UX skills to contribute to the development of the UX patterns I’m looking for but I just wanted to draw on the knowledge of the community to find out about the relevant efforts that are already ongoing. From the responses, I think this would be a rich area for research.