search

element-hq / riot-meta

A place to experiment with tracking features at a higher level than Riot web/iOS/Android.
25 stars 6 forks source link

Onboarding: Improve Landing as Guest in Riot Web #59

Open lampholder opened 7 years ago

lampholder commented 7 years ago

Github Project Design Document

We want to make some changes to how Guest Access works in Riot Web, to make the experience smoother and less confusing. Specifically we want to provide a more complete Riot experience more quickly, and to avoid the awkward transition from guest account to full user.

This change does not impact the Matrix spec.

Riot Web will replace the current guest access with two categories of user:

Known Caveats

PWLUs will be in a risky position until they've completed registration - the mxid they've chosen will be lost forever if they don't complete registration by providing a password.

Tasks to support PWLUs

User Flow

Unregistered user clicks a permalink

  1. Assuming room permissions allow, the user is shown the full contents of the room as a Read-Only User
  2. User can scroll backwards and forwards through history
  3. If the user attempts any other interactive action, they are directed to transition to PWLU N.B. This will be implemented using the existing Guest access experience, so anything that works there currently (do RMs work?, etc.) should continue to work.

Unregistered user clicks link invitation to room

  1. User is presented with a MXID picker: "Welcome to Riot - please choose a username"
  2. User chooses a new username
  3. Displayname defaults to username for now
  4. User enters the invited room and can participate as a full user, albeit with a nag bar at the top letting them know they need to complete registration to use this username again in future

Unregistered user navigates to https://riot.im/app

Same as when clicking a link invitation to a room, but user experiences the standard app welcome

Unregistered user tries to perform an action

Same as when clicking a link invitation to a room, but user is returned to the room they were reading before

PWLU loves Riot and clicks the link in the nag bar to complete registration

  1. User is presented with the mechanism to complete their registration
  2. User completes registration and is returned to wherever they were before they clicked the registration link

PWLU loves Riot but forgets to complete registration

  1. User picks a new username and mourns the permanent loss of the old one :( There is no way we would ever be able to recover or recycle the old MXID.
freelock commented 7 years ago

Hi,

Just reading up on the plans here... question: what if we have registration turned off on our homeserver?

We're starting to use guest accounts to invite clients to chat. The idea of a password-less user to get them started sounds great -- but we don't want to allow anyone to register on our server, without someone on our side taking action.

I was thinking of hooking up our own authentication system -- we would love to do something along the lines of what's being discussed in https://github.com/matrix-org/matrix-react-sdk/pull/796, to automatically log in users based on being logged into another system.

For "anonymous" users, though, the PWLU approach sounds great -- if there's some admin user story for promoting the account to a full user. Perhaps the ability for an admin to either register the PWLU directly in Synapse and send a password, or the ability to "claim" the PWLU from an account generated by a 3rd party system that provides an integrated login. In our case, a PWLU would not be able to register on our server, though we could send them off to matrix.org or elsewhere...

tessgadwa commented 7 years ago

This is very well written and documented in detail. With that said, it may be a moot point but I do not see the utility of a PWLU. Why not simply have a prompt requesting the user set a password at the time they comment or otherwise interact with content? Also, it seems like permitting lots of temporary accounts could lead to problems with spam and abuse.

lampholder commented 7 years ago

@tessgadwa We have considered prompting for a password at this stage, but our focus is on reducing the barrier to new users' usefully engaging through the app as much as possible (whilst balancing against exposing ourselves to abuse, hence the captcha).

It might be that requesting a password at the same time as requesting a username has no impact on conversion, and that might be something we experiment with in the future, but for now we've decided to leave supplying a password to a subsequent step :)

tessgadwa commented 7 years ago

Totally cool. I'm just glad you're taking as much time as you are to think through these process flows.

lampholder commented 7 years ago

@freelock I need to think about this usecase some more :) (We are thinking about it - not ignoring you 😄 )

lampholder commented 7 years ago

@freelock how far off would I be characterising your usecase as:

We are Examplecorp and we want our clients to visit our own Riot instance at riot.examplecorp.com to chat with us on our Riot instance's default homeserver matrix.examplecorp.com.

We don't want our clients necessarily using matrix.examplecorp.com as their homeserver generally, though, since it:

  • implies an 'internal' relationship between that client and Examplecorp through the :examplecorp.com domain part of their mxid
  • incurs an ongoing maintenance/support burden

If the above is along the right lines, what are your thoughts on your clients' being registered with matrix.org instead of examplecorp.com? If the default homeserver for your riot instance were set to matrix.org (or indeed any homeserver accepting registrations) then your clients could have the user experience described here.

Of course if we just reconfigure the default homeserver on your riot instance then you and your colleagues would have to change the homeserver from the default every time you logged in (you could patch your login page to fix this, or we could find another solution).

What are your thoughts?

@ara4n @AmandineLP it think it's worth your having a look at this too :)

jcgruenhage commented 7 years ago

Just to be sure, loosing the MXID requires the browser to loose it's local storage, or the user to intentionally log out, right? The session should be kept open even if the user closed the tab, right?

Also, isn't it possible to create a dialog when a user closes a tab? Loosing MXIDs like that seems rather avoidable in the most cases.

mxnemu commented 5 years ago

Hello, I wanted to use riot as an iframed chat for a video streaming site and noticed the following landing related problems riot still has.

  1. The site is unreadable in narrow views. https://github.com/vector-im/riot-web/issues/4729
  2. ROUs don't receive new events.
  3. After becoming a PWLU in a channel you are redirected to the startpage instead of staying in the same room.

here is an example of the use of riot I had in mind: 2018-07-03-005236_1919x1003_scrot

poVoq commented 5 years ago

This got actually remarkably worse with the recent redesign of riot.im :( Any chance there is a way to re-enable the previous portal welcome page with easy access to channels open to read only guests?

jryans commented 5 years ago

Any chance there is a way to re-enable the previous portal welcome page with easy access to channels open to read only guests?

Please file a new issue describing your use case so we can better understand the issue. This particular issue is more of a task list for an old project.