Log in and registration flows

[tkrieck]

Jira for this discussion: Loading...

Hello everyone, here is the login and registration flow for Cristal.

Accessing
To access this area, we will incorporate a single button positioned beside the main logo, typically located where the user’s photo appears once logged in. The proposed button will be labeled “Sign-in.” Upon selecting this button, users will be directed to a new screen where they can choose between logging in or creating a new account.

To accommodate this new button, the help icon has been relocated to the bottom of the sidebar. In compensation for its decreased visibility, we have included a label “Help Center” alongside it.

The label is just a proposal, what do you think of it?

The help link will mirror that of XS, directing users to the Cristal equivalent of https://www.xwiki.org/xwiki/bin/view/Help/.

In context:

Making it fullscreen
The intention of making the login/register flow “fullscreen”, is to streamline the user experience, ensuring that users are fully engaged in the registration and login processes. As such, these tasks will occupy the entire screen space, removing users from the wiki context and immersing them in the login/register flow.

To return to the main wiki, a button labeled “Back to site” featuring an arrow will be prominently placed at the top of each screen, effectively terminating the current flow.

For users who wish to navigate back one step only, they can use the default browser back button. While we could provide an additional back button within the interface, doing so may unnecessarily clutter the user interface without offering significant benefits.

Individual steps

The individual steps were taken from XS. Some may require adjustments as we progress further into development, but these will suffice for the current stage. Please note that the wireframes provided below represent the content area for each step, which will be centered on the user’s screen. This formatting is optimized for viewing within this forum.

Registering

After clicking in sign-in the user is directed to the start of the flow (the login page) where the “Create Account” button is available.

Logging in and forgot user/password

So that’s it for today, people. I hope you have enjoyed the reading and please, tell me what do you think of these ideas.

Thank you all for reading, see you soon!

[mleduc]

Thanks a lot for working on this.

What’s missing for me is the situation where Cristal is served from a different server than the backend (or locally, accessing a remote backend).
In this case, we might want to redirect the user to the authentication page of the backend, and retrieve an authentication token that we can store and user.
The goal is to avoid providing credentials in Cristal, which can be considered as untrusted third-party.
(Note: I might not know enough about web authentication process and be overcomplicating things).

Also, do we need something specific when trying to access a page that is not accessible to guest users?
Do we redirect straight away to the login page, or do you think it’s better to have an intermediate screen informing that the current resource is not viewable without authentication?

[vmassol]

Globally looks good to me.

As Manuel mentioned, we do need to handle the case where Cristal is not connected to a remote backend (ie connected to the local backend). I think we still need to be logged in, for consistency in the UI and to be able to configure parameters for the user (and possibly to allow several users to use the same computer).

@tkrieck

To accommodate this new button, the help icon has been relocated to the bottom of the sidebar. In compensation for its decreased visibility, we have included a label “Help Center” alongside it.

The label is just a proposal, what do you think of it?

The help link will mirror that of XS, directing users to the Cristal equivalent of https://www.xwiki.org/xwiki/bin/view/Help/ .

The left panel is not constrained in vertical space used. Imagine if there are, say 10 panels in the left sidebar, or some panel that take lots of vertical space (like expanding the nav panel), then the help button will be less visible.

IMO that’s acceptable, but I wanted to raise the fact that you’re “in context” view is a bit misleading in the case of a “busy” let sidebar.

Thanks

[tkrieck]

@mleduc

What’s missing for me is the situation where Cristal is served from a different server than the backend (or locally, accessing a remote backend).

Got it, I will try to mock something up for these situations.

@mleduc

Do we redirect straight away to the login page, or do you think it’s better to have an intermediate screen informing that the current resource is not viewable without authentication?

IMO, an intermediate screen telling the user that the resource is behind authentication is the best method. Going straight to the login page might be confusing, it works but not ideal in my opinion.

@vmassol

The left panel is not constrained in vertical space used. Imagine if there are, say 10 panels in the left sidebar, or some panel that take lots of vertical space (like expanding the nav panel), then the help button will be less visible.

Thank you, I will keep this in mind. Initially I was thinking of making it always visible on the sidebar, but upon further thought it might be too obtrusive.

[tkrieck]

@tkrieck

IMO, an intermediate screen telling the user that the resource is behind authentication is the best method. Going straight to the login page might be confusing, it works but not ideal in my opinion.

I’ve updated the design page with this intermediate screen.

I am closing now this topic, since it’s been open for some time now without new interactions. I’ll open it again if needed.

Thank you all for participating

[amilica]

Hello! As part of my review of all Cristal proposals, I’ve look into this one and everything is really nice, but I have a few small suggestions for improving this both on the UX side and the UI side (maybe a bit more towards this one).

---

UI side

I would’ve like to see a bit more “drama“ or “spectacle“ in the desktop UI of Cristal login.

Something easily customizable by any company. These days it seems popular to have a split screen design for auth screens: one side the actual login and one side an image or a Welcome back message. Example:

• the client logo would be taken from the logo of the wiki as a default
• the image can be configured in General Admin

On the UX side

Placeholder text

Every input in Cristal should have a placeholder text with a smaller contrast against the background. See example in previous design.

Hide/view password

The password should have an hide/view toggle (eye icon). See example in previous design.

Officialism of integration

For registration in another backend, that backend’s logo should be on the button or somewhere to reinforce the officialism of the relation/interaction between Cristal and that backend.

Bigger change

Never thought to ask until now so it may be a bit late…

But why did we keep logging in with usernames and not using emails like any other product? Is it a technical limitation?

I know XWiki currently does this, but can’t we move away from this as every xwiki account has an email address (so it’s not like we’d miss the link between them)?

WDYT?

[vmassol]

Thanks Adina!

@amilica

I would’ve like to see a bit more “drama“ or “spectacle“ in the desktop UI of Cristal login.

YMMV. A bit too much drama to my taste Looks like some marketing web site to me. How do you scale it for different screen sizes, including mobile?

I’m not convinced it brings added value. I find it distracting for no reason. I mean what does the image adds as value?

Also note that this will be for XS too since Cristal = XS in the future.

@amilica

These days it seems popular to have a split screen design for auth screens: one side the actual login and one side an image or a Welcome back message.

Note: If it’s the first time you log in, I’m not sure “Welcome back” is appropriate.

@amilica

the client logo would be taken from the logo of the wiki as a default

What is a “client logo”? Why is there a need rather than replace the default XWiki logo. IMO companies using XWiki and wanting their brand will prefer replacing the XWiki logo and don’t necessarily want their users to see the XWiki brand.

Also, for XS it would mean the same logo on the left than on the right, correct?

@amilica

On the UX side

Placeholder text

Every input in Cristal should have a placeholder text with a smaller contrast against the background. See example in previous design.

Hide/view password

The password should have an hide/view toggle (eye icon). See example in previous design.

Officialism of integration

For registration in another backend, that backend’s logo should be on the button or somewhere to reinforce the officialism of the relation/interaction between Cristal and that backend.

Good ideas.

@amilica

But why did we keep logging in with usernames and not using emails like any other product? Is it a technical limitation?

I know XWiki currently does this, but can’t we move away from this as every xwiki account has an email address (so it’s not like we’d miss the link between them)?

Yes it’s historical. Historically wikis had wiki names for users.

Right now there’s a direct relationship between the user name and the user profile page. However we could concatenate the first name with the last name to compute a user profile page name.

It would need to be designed and evaluated for cost, and we would need to support backward compatibility, and refactor hardcoded places in the code.

I agree that it would feel more modern. The only pro I see for what we have now is that you don’t need to give your email address if you don’t want to.

[tkrieck]

Hey Adina o/

@amilica

I would’ve like to see a bit more “drama“ or “spectacle“ in the desktop UI of Cristal login.

IMO, as a default, we should aim for a more low-key, neutral presentation. However, we can give users the flexibility to personalize the interface if they want something with more character, as customization options:

• Welcome message (on/off; message string)
• Instance logo (on/off)
• Background image (on/off; image file)

The question for me is more if we provide these customizations as easy to make configurations (in a Look and Feel admin page for example) OR if we restrict those to only CSS and templates customizations (way more technical).

@amilica

Placeholder text

Every input in Cristal should have a placeholder text with a smaller contrast against the background. See example in previous design.

Hide/view password

The password should have an hide/view toggle (eye icon). See example in previous design.

Officialism of integration

For registration in another backend, that backend’s logo should be on the button or somewhere to reinforce the officialism of the relation/interaction between Cristal and that backend.

Nice ones.

Thanks for the feedback!