Hi @kostajh - I'm the main person on design who worked on the unregistered flow so can hope provide some answers:

1. We display prominently "You are using a temporary account". But right next to that, we have a button that says "Create account". I think this ("you are using a temporary account" and "create account" mentioned in the same line) is going to be confusing for people who don't already know the distinction between temporary and named accounts.
Suggestion: Change "Create account" to "Register"
This helps avoid the existing ambiguity of "temporary account"/"account" while also hopefully providing a meaningful entrypoint to users who want a permanent, named account.

It is important to keep the consistency in the CTA for temp account as it is for a non-logged in person, hence keeping Create account and Log in.

screenshot showing the same CTA text for someone not logged in

The reason for this sentence "You are using a temporary account" is to clearly identify this is a different, "not permanent or real" account to one they can create, as from testing (when we added the grey banner text and the new name format, testers were helped in their understanding that temp accounts are different.

2. "You are using a temporary account:" takes up a lot of space, spreading the banner to multiple rows on smaller viewports
Suggestion: Remove the text entirely, so everything fits in one row. The "info" button is still there to provide contextual info to those who need it.

Per above, having the sentence adds clarity and prominent to the fact that the person is a temp account so would suggest keeping as is, especially as the banner is not sticky, so does scroll off the screen and not impede reading experience. Another consideration is keeping to the "i" info icon only for mobile.

3. The "Log in" button is confusing--from the temporary account user perspective, we are telling them they are using a temporary account, so why would they need to log in?
If a user with a named account accidentally edits while logged out, then a prominent "Exit session" or "Logout" button would help these users find their way back to their named accounts.
For almost all other users (first time anonymous editors who are given a temporary account), the "Log in" button leads to a flow that will likely lead to abandonment.

There were two main cases which were considered for including the log in button:
(a) A person with an account makes a edit without logging in and doesn't realise they weren't logged in until they hit publish. IIRC part of not ending completely is to open the possibility of enabling carry-over of temp account edits to their real account one day (this was a requested feature during design).
(b) Shared device situations - eg person A makes a temp account edit on the library computer, person B comes around and wants to make an edit on their own account.

from a temporary account perspective:
How many temporary account users will mistakenly enter their temp account name (e.g. ~2024-38487) and a new password here, thinking that they are creating an account?
How many temporary account users will not find the "Don't have an account?" prompt at the very bottom?
How many temporary account users will be confused by the "Join {SITENAME}" call to action button, when they already are logged in as a temporary account?

The usability testing did indicate folks understand the difference betwee temp accounts, so expectation would be this is a low number who incorrectly click through to Log in.
I think for those who do, when they fail to create their account/login with a temp account ~2024-# name the expectation is error messaging and help text, as well as the Create an account CTA at the bottom of the screen will allow them to correct course.

Suggestions:
Do not bring temporary account users to Special:UserLogin, for reasons given above.
Replace "Log in" with "Logout" or "Exit session" (currently labeled as "Exit session" in the user menu on Minerva and Vector 2022). We could optionally require a confirmation step to exit the session (this is the case on Minerva; on Vector, you're logged out immediately)

The reason for keeping Login and Create account together is consistency with the logged out user CTAs. I think replacing "Log in" with "End session" is a good idea, though part of the reason for having "Exit session" in the user menu was concerns that having "Exit session" too prominent would make it easier to abuse, which is the reason for the confirmation step -- if Desktop doesn't have this it should be filed as a bug and the confirmation should be there as well.
I would suggest keeping Log in for the initial pilots to monitor how many people arrive here and bounce vs actually logging in. If there is a high bounce rate then we can remove the "Log in" button from the banner as a first step, and potentially elevate "Exit session" to the banner again pending info from piloting as to whether good faith users are having issues knowing how to exit the temp session.

Existing call-to-action buttons don't have progressive/primary colors

Suggestion: Set "destructive" on the "Logout" button (if we implement that from suggestion above) and set primary/progressive for the "Register" button (if we implement that)

In both cases these should remain neutral button buttons since "Exit session" should not be seen as a negative / destructive / alarming action to take, since it is exiting from this transitory state, and also where the person might actually want to leave because the temp account was from someone else. Similarly I think it is too prominent to make "Create an account" a primary action on a Wikipedia article page as it confers the intention this is the main thing they should do on the site, especially when this CTA less prominent on non-logged in Desktop and mobile. The fact that "Log in" and "Create account" are buttons instead of links is already more prominent styling choice (since really these should be links to pages to take the actions)

Thanks very much for the explanations and comments, @RHo. I'm going to step away from this task and will leave it with @KColeman-WMF and @Niharika to see about proposing any changes based on the task + comments.

The reason for keeping Login and Create account together is consistency with the logged out user CTAs. I think replacing "Log in" with "End session" is a good idea, though part of the reason for having "Exit session" in the user menu was concerns that having "Exit session" too prominent would make it easier to abuse, which is the reason for the confirmation step -- if Desktop doesn't have this it should be filed as a bug and the confirmation should be there as well.
I would suggest keeping Log in for the initial pilots to monitor how many people arrive here and bounce vs actually logging in. If there is a high bounce rate then we can remove the "Log in" button from the banner as a first step, and potentially elevate "Exit session" to the banner again pending info from piloting as to whether good faith users are having issues knowing how to exit the temp session.

@RHo Can you confirm if the Web team is instrumenting the bounce rate from the Login page and the use of exit session? We are not instrumenting them on our end as of yet.

In T375712#10227589, @Niharika wrote:

The reason for keeping Login and Create account together is consistency with the logged out user CTAs. I think replacing "Log in" with "End session" is a good idea, though part of the reason for having "Exit session" in the user menu was concerns that having "Exit session" too prominent would make it easier to abuse, which is the reason for the confirmation step -- if Desktop doesn't have this it should be filed as a bug and the confirmation should be there as well.
I would suggest keeping Log in for the initial pilots to monitor how many people arrive here and bounce vs actually logging in. If there is a high bounce rate then we can remove the "Log in" button from the banner as a first step, and potentially elevate "Exit session" to the banner again pending info from piloting as to whether good faith users are having issues knowing how to exit the temp session.

@RHo Can you confirm if the Web team is instrumenting the bounce rate from the Login page and the use of exit session? We are not instrumenting them on our end as of yet.

Tapping in @ovasileva and @Jdlrobson since I cannot find it under T335440: [EPIC] Web team support for IP masking. Can Web team please confirm if (a) there has been instrumentation on the "exit session" action for temp accounts, and (b) advise if a task needs to be added to add the same confirmation dialog on Desktop as is currently in place on Minerva?

Can Web team please confirm if (a) there has been instrumentation on the "exit session" action for temp accounts

The links in the banner (information icon, log in and create account)

Exit session is instrumented identically to logout and will appear in the mediawiki.web_ui_actions schema under "pt-logout" for desktop and "menu.logout" for mobile.

However, the schema currently makes no distinction between logged in and temporary users. Only an isAnon field is logged but that will be true for both. So I think if you need this information, we'll need to create a ticket for MediaWiki-extensions-WikimediaEvents "Update mediawiki.web_ui_actions schema to distinguish events from temporary users" using this form

(b) advise if a task needs to be added to add the same confirmation dialog on Desktop as is currently in place on Minerva?

I think there is a bug here in the implementation. Just to clarify you are saying that mobile or desktop has the right behaviour/

Desktop currently has the chosen behaviour here - it has code that automatically logs out the user via JavaScrip. This was intentionally added by @Dreamy_Jazz in ab89fff6338 as part of T374519. There is no confirmation step - I just get logged out automatically without confirmation? Is that the desired behaviour?

That code is meant to also apply to mobile, but is broken because #pt-logout a[data-mw="interface"] doesn't . We should have a fix for that in next train.

In T375712#10235069, @Jdlrobson wrote:

(b) advise if a task needs to be added to add the same confirmation dialog on Desktop as is currently in place on Minerva?

I think there is a bug here in the implementation. Just to clarify you are saying that mobile or desktop has the right behaviour/

Desktop currently has the chosen behaviour here - it has code that automatically logs out the user via JavaScrip. This was intentionally added by @Dreamy_Jazz in ab89fff6338 as part of T374519. There is no confirmation step - I just get logged out automatically without confirmation? Is that the desired behaviour?
That code is meant to also apply to mobile, but is broken because #pt-logout a[data-mw="interface"] doesn't . We should have a fix for that in next train.

Hiya yes, it is expected that there is a confirmation dialog to friction and require more intentional effort for someone to clear the cookie and exit out of the temp account.
While I do see the expected confirmation step on Minerva - I do think this makes more sense as a dialog instead of a page, and would add a cancel button as well:

Incidentially, as I was testing the exit flow, I noticed the page post-exit would benefit from some content improvements. Most notably removing the last paragraph of text "Logging you out from other wikis of the Wikimedia Foundation:" as well as the favicons; and would also consider removing/ updating the heading "Exit session" since they have already logged out.

Post-exit page for temp accounts	Mobile	Desktop
Post-log out page	Mobile	Desktop

cc @KColeman-WMF and @JScherer-WMF so they can better coordinate and prioritise the tasks to fix as needed.

@RHo the mobile site behaves exactly like desktop (there was a bug) - please make sure when testing the workflow you are looking at https://en.m.wikipedia.beta.wmflabs.org/ which reflects the current state of code.

In T375712#10239815, @Jdlrobson wrote:

@RHo the mobile site behaves exactly like desktop (there was a bug) - please make sure when testing the workflow you are looking at https://en.m.wikipedia.beta.wmflabs.org/ which reflects the current state of code.

Oops, thanks. I retested and the copy issues are gone but [[ T375712#10237111 | the main point of my earlier comment stands ]] in that the expected behaviour is that both desktop and mobile *should* have the confirmation step.
For ref here's the actual behaviour on beta right now where indeed both desktop and mobile are missing the confirmation step (amongst a couple other issues with toast text colors being off and lag):

In T375712#10234942, @Jdlrobson wrote:

Can Web team please confirm if (a) there has been instrumentation on the "exit session" action for temp accounts

The links in the banner (information icon, log in and create account)

are currently not instrumented. Since these are links we can add instrumentation relatively easily if needed by adding data-event-name attributes to them.

Exit session is instrumented identically to logout and will appear in the mediawiki.web_ui_actions schema under "pt-logout" for desktop and "menu.logout" for mobile.

However, the schema currently makes no distinction between logged in and temporary users. Only an isAnon field is logged but that will be true for both. So I think if you need this information, we'll need to create a ticket for MediaWiki-extensions-WikimediaEvents "Update mediawiki.web_ui_actions schema to distinguish events from temporary users" using this form

bumping this to confirm this would be for @Niharika or @kostajh to complete?

In T375712#10240244, @RHo wrote:

bumping this to confirm this would be for @Niharika or @kostajh to complete?

@RHo per the temporary accounts pilot wiki readiness agreement, we asked each team to indicate that their instrumentation code and schemas are ready for temporary accounts. @Jdlrobson as this isn't yet done for mediawiki.web_ui_actions, I would ask that you please create a subtask of T374942: [Epic] Update schemas and instrumentation code for temporary accounts and prioritize updating the schema and instrumentation code to avoid erroneous data once temporary accounts is deployed to pilot wikis at the end of October.

We have T376480 in our current sprint to evaluate whether it is blocking. Let's continue instrumentation conversations on T374942.

I've created a separate task for adding the confirmation dialog to Exit session flow: T378806: Add confirmation step to exit session flow for temp accounts Myself and @JScherer-WMF will be the design point of contact going forward.

My understanding is that this is less urgent than the instrumentation task, and that it's a Major Pilot wiki deployment blocker. Please can you confirm if this is the case @Niharika?

In T375712#10283912, @KColeman-WMF wrote:

I've created a separate task for adding the confirmation dialog to Exit session flow: T378806: Add confirmation step to exit session flow for temp accounts Myself and @JScherer-WMF will be the design point of contact going forward.

My understanding is that this is less urgent than the instrumentation task, and that it's a Major Pilot wiki deployment blocker. Please can you confirm if this is the case @Niharika?

Yes, I agree with this. Exit session instrumentation is more important.

The biggest current problem is that the temporary account bar is much, much, much more prominent than frankly more important new talk message notice:

This was supposed to be fixed in T341305: Talk page notification alert bar: revised styling to meet WCAG color contrast AA requirements but then it was untagged from your workboard entirely. I feel like, if the temporary account bar will be deployed in the current design, new talk message notice should be updated to match it. Currently it is a very small bar that does not pass WCAG requirements and can’t be noticed by many new editors, especially IP editors. Its design is also not uniform across platforms. It is a frequent community request that something will be done to fix this and make it more noticeable.

In T375712#10369090, @stjn wrote:

The biggest current problem is that the temporary account bar is much, much, much more prominent than frankly more important new talk message notice:

This was supposed to be fixed in T341305: Talk page notification alert bar: revised styling to meet WCAG color contrast AA requirements but then it was untagged from your workboard entirely. I feel like, if the temporary account bar will be deployed in the current design, new talk message notice should be updated to match it. Currently it is a very small bar that does not pass WCAG requirements and can’t be noticed by many new editors, especially IP editors. Its design is also not uniform across platforms. It is a frequent community request that something will be done to fix this and make it more noticeable.

@KColeman-WMF @RHo @Niharika do you have thoughts on this point, or on T341305: Talk page notification alert bar: revised styling to meet WCAG color contrast AA requirements? Perhaps the gray status bar for temp accounts could include some prominent visual indicator that the user has a talk page message?

In T375712#10369775, @kostajh wrote:

In T375712#10369090, @stjn wrote:

The biggest current problem is that the temporary account bar is much, much, much more prominent than frankly more important new talk message notice:

This was supposed to be fixed in T341305: Talk page notification alert bar: revised styling to meet WCAG color contrast AA requirements but then it was untagged from your workboard entirely. I feel like, if the temporary account bar will be deployed in the current design, new talk message notice should be updated to match it. Currently it is a very small bar that does not pass WCAG requirements and can’t be noticed by many new editors, especially IP editors. Its design is also not uniform across platforms. It is a frequent community request that something will be done to fix this and make it more noticeable.

@KColeman-WMF @RHo @Niharika do you have thoughts on this point, or on T341305: Talk page notification alert bar: revised styling to meet WCAG color contrast AA requirements? Perhaps the gray status bar for temp accounts could include some prominent visual indicator that the user has a talk page message?

hi @kostajh and @stjn - this is something that should be fixed on the T341305. I would suggest the priority on T341305 can be bumped higher for the Growth-Team given that also impacts temp account users now and is a long-standing issue. cc @KStoller-WMF