A couple of thoughts on the current open questions:

• do we anticipate any additional items getting added to the site header area as part of this project?
  • I'd say this is a nice to have - definitely on the table in terms of conversations themselves, but we can consider it as separate work for right now
• logged-in users will likely be frustrated by the extra click. Could we give them a setting such that they can choose up to two additional links to show outside the menu? Could we make it so that if there's enough space items pop out of the menu automatically?
  • I thought we'd discussed that the menu should appear on-hover, thus removing the extra click. I don't know about the setting though - it seems like it could get quite complicated if we take that approach

A community liason /Kaldari/ growth team should be able to provide background but Eco has special handling for "you've got new messages" that in the past the community has figured important.
It looks a bit like this but traditionally has been orange and the code is still present. If we can drop that code.. awesome.

Right now that aside i'm just seeing technical challenges here. Right now all the items in that menu are considered as a single unit that cannot be easily rearranged so we'll no doubt need to make some technical changes to support whatever we come up with.

basic prototype here: https://di-community-round-2.web.app/Romania

logged-out	logged-in

to switch between logged-out and logged-in use the menu located under the gray arrow in the bottom-right corner

noticing that sometimes the icons for Alerts and Notices don't appear and instead there is text links. I assume this is a fallback option @Jdlrobson? Also assuming we want to continue to offer/support this, so we should be mindful in terms of spacing that this can happen.

I'm not sure why you are not seeing the user scripts, but my guess would be it's a gadget disabling them. Try ?safemode=1 on the URL to see if they return.

Change 656518 had a related patch set uploaded (by Jdlrobson; owner: Jdlrobson):
[mediawiki/skins/Vector@master] POC: Personal menu

https://gerrit.wikimedia.org/r/656518

@ovasileva @Jdlrobson @RHo @MMiller_WMF @Pginer-WMF (cc @iamjessklein @ppelberg)

Regarding the special alert that appears next to the bell icon when you have a new messages on your talk page, here are some rough options:

current state (old vector)		-
new vector, if we did nothing		con: it would be nice to reserve that space for more useful, common elements
make it a floating element		con: feels cluttered
change color scheme & reserve red for talk page alerts		con: maybe more involved of a change than we want to take on — not sure what the current color coding is
add a notification to the notification		con: seems a little silly

Note: there is a proposal for a more complete solution here T142981 — at this time we, the web team, are not ready to take on that amount of work.

I really like the floating element option

A technical detail that adds complications: the message bar is also used by 3rd parties without Echo installed which means we would likely need to support 2 versions of this if we tie the icon to the message bar.

The notifications bar is generated by core. The notifications icon is generated by Echo. For many of these designs to work, it assumes a lot of work in core to make sure the notification icon is always present (which is not necessarily a bad thing - and what we do in mobile).

Thanks for sharing initial designs @alexhollender - I agree with @ovasileva's preference for the floating option, with further exploration to simplify (perhaps not having the yellow dot, removing "segmenting" border for the "x") so that it helps make it feel less busy on top of the bell.

Another option might be worth mocking up is to replace the bell with a message icon when there is a new message?

I would recommend against the option presented for changing the colour scheme to reserve red for talk messages, firstly, for a11y reasons (not to only have colour signify difference). Secondly, I think per the specs here, the notification icon is red for all alerts (the bell) and blue for all notices (tray icon), so it doesn't feel right that talk messages should get the more "important" red colour over, for example, the Edit revert alert.

In T266511#6783949, @alexhollender wrote:

[...]

current state (old vector)		-
new vector, if we did nothing		con: it would be nice to reserve that space for more useful, common elements
make it a floating element		con: feels cluttered
change color scheme & reserve red for talk page alerts		con: maybe more involved of a change than we want to take on — not sure what the current color coding is
add a notification to the notification		con: seems a little silly

Note: there is a proposal for a more complete solution here T142981 — at this time we, the web team, are not ready to take on that amount of work.

The simplifications proposed by @RHo makes sense to me, although I can see the point of keeping some orange to help make the connection between the old and the new element.

Another alternative you can explore is to connect the signal to the user icon, given that we are trying to surface activity in the user talk page. That is, user with new activity in their talk page would see a user icon with a modifier to signal it (e.g., a dot to indicate activity). When they click on the user icon the menu is open as usual but a similar signal (the same dot or other indicator such as a counter or a "new" label...) is shown next to the talk option to indicate where the activity comes from.

(this comment has been migrated to a more specific task: T274296#6816414)

(This comment has been migrated to a more specific task: T274296#6816470)

(this comment has been migrated to a more specific task: T274296#6816472)

(this comment has been migrated to a more specific task: T274296#6816476)

Thanks for sharing all of these options, I don't really understand the need for the explanatory text (yellow/orange bar). This feels redundant as you already have the primary affordance of the bell and highlight. Have you tested to see if this is truly a use case for everyone or specifically for senior contributors? Based on my hunch, I'd be interested in seeing what this workflow could look like with that as a preference that would be by default turned off.

+1 to @Pginer-WMF approach of connecting it to the user profile icon.

In T266511#6795944, @Pginer-WMF wrote:

In T266511#6792389, @alexhollender wrote:

@Pginer-WMF interesting question. To clarify: confusing in the sense that someone who is usually logged-in (but is currently logged-out) might mistakenly think they are logged-in? Or confusing in the sense that a logged-out person might think they are logged-in?

I was thinking mostly in the former. On some editing features the need to indicate the logged-out status was surfaced by editors that published something not noticing their session already expired (revealing their IP, not linking it to their user to get notifications fro replies, etc.). This may be related to the fact that unlike other common online services where your session seems to live forever, here your session has a much shorter time.
More generally, the icon next to the button to log-in may be sending a contradicting signal of being logged out (as per the button) and logged in (as per the icon) at the same time. I don't know if thats enough to really get in the way of logging-in, but I think it is worth looking into.

Other questions that come to mind:

• is the userAnonymous icon unfamiliar and therefore distracting?
• might the userAnonymous icon suggest something like "incognito" or "private" mode (which has become more familiar via browsers)?

It is possible that the in-cognito meaning is getting in the way. This seems a fitting context for using the anonymous icon (if an icon is needed). So I'd consider that if the current version does not work, we may want to adjust the icon so that it can be more widely used.

Adding some comments from our discussion earlier this week @alexhollender, I agree that the confusion may partly be related to the userAnonymous icon which can be confused with (a) incognito mode which is not what an unlogged in person is, or possible (b) a specific avatar icon at glance if a normally logged in user gets logged out (Pau's initial point).
Regarding (a), I recall that when we redesigned the icon I had "incognito" in mind, which I realise now is a bit misleading, so would be open to revising (separate thread).

• would it make sense to clarify within the menu that they are not logged-in
  

As I mentioned below, the logged-out experience is sub-optimal (less features but also less private than using a pseudonym). So making users aware and suggesting to create an account can be always helpful.

+1 to having this message. Also adding @Prtksxna who may have more info on messaging and copy for IP editors.

• are these two different enough so as to not be confusing?
  

Note that users won't be seeing these experiences side by side. I think the most relevant analysis would be to pick each case and ask whether a user would figure out their status even if they assumed they are in the opposite case.

• what if we dropped the icon entirely? Looking at Pinterest, they use only a V. Another option might be ...
  

I think this is worth considering too. Talk pages for anonymous users are attached to an IP. There are many caveats and aspects to consider before using it as if this was a regular user account. So I think it makes sense to keep these options less prominent for anonymous users.

I think it would be a good education opportunity that talk and contributions exist for non-logged in users so prefer to have some icon instead of none. Potentially, instead of using an avatar, we could indicate the identity if by IP by using a devices or browser icon:

An iconified version of something like this from Commons

something like this existing browser icon from OOUI

additional context for the discussion about the special alert that appears next to the bell icon when you have a new messages on your talk page — here is currently how that looks for logged-out IP folks:

Hiya, per offline conversation with Alex, I still consider option #2 (with some exploration to simplify the visual design mentioned above) to be most optimal update, as it leaves the existing space for more common header elements.
I wonder though if we want to have the floating element "point" to the avatar icon where the Talk page menu item will be placed, as well as updating the copy to make it clear that this tapping the link takes the user to their talk page? It could help reduce potential confusion of the current design which is really a more prominent Talk page link masquerading as a notification element.

Change 656518 abandoned by Jdlrobson:
[mediawiki/skins/Vector@master] POC: Personal menu

Reason:
Associated with bug. POC no longer needed.

https://gerrit.wikimedia.org/r/656518