UX follow-up to multiple-codename generation case

[eloquence]

#5075 provides a first resolution to an error when the /generate page is visited in more than one tab. To give the user a better understanding of what happened and generally reduce risks around codename usage, two follow-up tweaks are currently under consideration:

1. Move the "Remember, your codename is" widget to the top of the page, aligned with the login button;

2. Tweak the text of the message for clarity.

A proposed pass at this can be found in this design by @ninavizz:

This needs a bit more discussion before this issue is ready for development.

[eloquence]

As far as I can tell, moving the "show codename" widget should have no significant implications for other flows in the application. The user is reminded after their first submission to check their codename, and this reminder links back to the widget, but it doesn't use language like "below".

I don't think we should use the text (or sticky pin) "Reminder" in this message, since this is a special case, not a general reminder. Instead I think the message should be more actionable and specific, e.g.:

Please double-check your codename

You are already logged in with the codename above. Please verify that it matches the one you have written down or memorized.

Note: We cannot assume that the user currently has another tab open, or that they did indeed use a separate tab and not a separate window, which is why I think it's best to keep the message minimal.

[ninavizz]

Pin icon is here, at 4x the size it's used at in the mockup (to avoid showing as fuzzy):

[ninavizz]

UPDATED: Moved this comment to a new issue in the SD-UX repo. :)

scope creep alert So... the intended visual maturation of the Submit screen following the Codename Widget being moved to the top, has factored-in removal of the full-screen container outline—and moving it to just the replies box, with an additional line of text and the H2 there, edited.

Such a change would not introduce any UX regressions for other pages in the experience, or other states of this page—less the state of the page with replies on it, which also needed improvement.

The full team is VERY busy right now, in the thick of Workstation tasks... so I'm not advocating we drop everything to push these into production, but I did want these intended maturations considered, should there be any volunteer interest in implemention in time for the next release—should the core team agree with their direction.

[eloquence]

That's definitely out of scope for this issue @ninavizz :) We can track separately.

[ninavizz]

Yeah, it's not a priority from my POV against other Source UI UX needs—so I've been hesitant to create a new issue for it. Only wanted those things included in this issue as "Stretch Options," in case whomever tackles this issue felt strongly about wanting to tackle them, too. ¯_(ツ)_/¯

[ninavizz]

Addendum

In consideration of the need to keep the scope of this issue small, I'm adding to it 2 small updates to the Reply area—to give it an un-mistakably clear "Empty" state. Without these updates, is shown on the left of the included mockup—and with them, to the right.

FYI @DrGFreeman, in case you've picked this issue up and are give it some luv.

1. The pale grey rectangle below the Read Replies H2
2. Update the text to the much simpler — No Messages — so it's more easily recognizable as an empty-state.
3. Not in regards to the "Reply" area, but with the codename widget moving—pls to mind the whitespace at the top of the page between the new placement of the codename widget, and the Submit Files or Messages H2.

Rationale

Moving the codename widget to the top of the screen does introduce a UX regression to this page—in that it further obfuscates the already unclear empty "Replies" area... which Sources need to see, to cognitively register that there's something there for them to check back later.

No, users do not copiously read UI and documentation texts, to learn such things where we'd like them to. They need to see them in an "empty" state, to put 2:2 together that there's more for them to see in a return visit.

[DrGFreeman]

Hello @ninavizz, your three points above are clear. I will start working on this and use the right mockup above as reference. I'm far from a pro in HTML/CSS but I should be able to go a long way. I'll reach out if I get stuck somewhere.