New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Console] Editor Onboarding #85
Comments
Sounds like a good idea. I can see users being confused if they triggered the Editor mode by mistake or out of idle curiosity. And even if they wanted the Editor in the first place, spelling out how the keyboard shortcuts work would help! I can probably make a mockup in a couple days. Do we also have shortcuts for the history navigation? |
Thanks a lot @fvsch !
Not yet. I think it would be nice to have some, but it's also tricky to pick good ones |
@violasong maybe a good MVP for pointing the feature out is the fox-themed tooltip we used previously. What are your thoughts? |
The user should definitely get a hint after switching to the editor mode. A tooltip might help, not sure how the "fox-themed" would look like. I just want note that the text might get a little longer when there should also be the info on how to get back to single-line mode. Sebastian |
If the line gets too long, maybe just link to an MDN page for further information on how to use the Editor Mode. The message would then look something like this: "Editor Mode enabled, press [ |-] to return to Single-line Mode. Learn more" Sebastian |
Here's the fox recommender we've used before :D The tooltip style would be for calling out the editor button, but that would probably be tricky with that button moving unpredictably as more logs come in. An alternative for calling out the editor button would be using a blue "New" dot indicator. If we want a message within the editor itself, we can use an inline banner style, which we've used for Grid Inspector. |
Maybe this can spawn some mockups or further ideas: Editor feature hint: Nicolas had a good idea to just animate the icon when the user starts writing multiple lines (or pasts in a longer snippet). A quick "jump" with fade to blue might be enough to get the users attention. Onboarding: The inline banner style is probably best for this sidebar-styled. Positioning it below the toolbar would bring it in the right context. Word-smithing drafts:
|
@nchevobbe just wanted to check if I captured your idea correctly and if you got anything to add? |
no, it does look great 👍. |
@violasong , is the background color in a variable somewhere? If not, what should we use in dark mode? Thanks! |
Suggestion for the copy: Iterate on your code faster with the new multiline editor mode. Use Enter to add new lines and execute with Cmd-Enter. The run button looks a tiny bit confusing (ok, this is starting to go off into general polish) - one thing we could try is add a "play" icon (from netmonitor) to the button. It also needs a bit less top/bottom padding (can match console clear button's hit area) and a bit more left/right padding. Also more left margin. Sorry if this is confusing :). Basically I think it doesn't need to line up with the picker icon - it would be easier to understand if it popped out a little more. |
(Also, I can actually do a figma mockup if that would help :)) |
Nit: since the message has 2 sentences, I feel that both should end with a period.
Agreed, I think Nicolas said the Editor mode's toolbar needs a UI review and polish pass. |
A mockup would be great :) |
I tweaked the padding and margin, and added the netmonitor play button before the "Run" text. The icon feels a bit weird to me in regards to other icons. I guess we should have a stroke-only shape, like the debugger "Resume" button? Small question: the
|
We're planning to change the debugger's Resume icon, and unify all the "Play" icons (in Inspector>Animations, here maybe, in Netmonitor and Debugger). Not sure if we're going with a 2px stroke and no fill or some other style. |
Nice! I spent more time on this and tweaked some things. Here's the figma file (if you're signed in, you can access code mode to inspect. You can also fork it and paste a 50%-transparent screenshot for double-checking).
For future reference, here's one place where "Got It" is currently in Firefox. |
Thanks @violasong . Looks great together, love the polish! I noticed that the history and close button hover states are still taller; I guess they should also be aligned? |
This ties in nicely with the questions in #89. :) I think the 20px height may be a tad short for icon buttons. We use 16px icons and the buttons tend to have a 26px width, so 26x20 can look a bit pill-shaped. In our older 24px toolbars, those icon buttons are 26x22. In the newer 28px toolbars, button height is all over the place (20px, 26px…), depending on what we did with Flexbox (stretch or center). |
Yep, but we can land it in a second step. This is covered by #49 I believe. Jason was looking into this issue these days because he's doing some polish work on Web Replay. |
Awesome, these new screenshots look perfect!! Re: button alignment: I can see why you suggest this, but I think that extra margin is needed since the button does have a background. Unfortunate that the dark mode button color is so invisible - ideally all dark mode buttons with background colors should get updated, maybe to match the much brighter #38383D used for various things in Fonts. |
One tiny thing - in the tooltip, I think it would be better to say "inline" without the hyphen, since it's more commonly used that way in software. |
Thanks a lot @violasong and @fvsch ! I proceed with the current design and the patch is now in review. |
(Edited by digitarald)
This onboarding should probably split into 2 separate designs, that can be discussed together here for the sake of a holistic end to end experience.
In-context editor hint for awareness, tell users that they could switch to editor for a better multiline editing experience:
Onboarding should be contextual and only trigger when users paste (or type) snippets with multiple lines into the input.
Onboarding must not steal focus or hide big parts of the UI
Showing onboarding should not change the layout drastically, moving critical elements around
Constrains for feature onboarding:
Should highlight a few editor differences from the inline input, in context of user benefits
Kicking off brainstorming: "Editor mode gives you more space to write code snippets and run them repeatedly (
Ctrl+Enter
)"The Editor mode is almost complete \o/
(We're missing a proper way of opening it, and probably a UI review on the Editor toolbar)
What I wanted to discuss here is if we should have something to guide users through this new feature, and the differences with the in-line input.
My reasoning is that users might be confused when switching to editor mode for the first time?
The editor can be enabled with a keyboard shortcut, so some users might enable it without wanting it and find it weird. So maybe that could be mitigated with a piece of UI that says "hey, that's the new editor feature, you can use Enter as you want, Ctrl+Enter evaluates the input and does not clear it"
What do you think folks?
The text was updated successfully, but these errors were encountered: