Introduce a "home" command center view

[daviddossett]

Ref #155458

Opening the command center today opens the file search mode (cmd/ctrl + p). Users have to discover how to use prefixes to enter other modes.

Since we're looking at how to improve the discoverability of modes (>, @, etc.) and also possibly introducing an entry point for full text search in the CC, I think there's an opportunity to solve for both here. Some early ideas:

Demo

• Cmd/ctrl + K to open the command center
• Shows short list of most-used modes + ? to view all
• All other keybindings still work as before—experienced users wouldn't need to use this
• File search would need to start using a prefix
• Bonus: users learn shortcuts via this list

[hawkticehurst]

As we've discussed offline, I really like this current iteration of the explorations you've been doing.

I love the addition of a new command center entry point via cmd/ctrl + k (which matches up with the shortcut used in the vast majority of command palette UIs in other products).

I also love the idea of showing a small list of the most used modes and making this the default instead of file search. It feels like a perfect balance between giving people some high-level hints on what they can/should do via the command center while not burdening them with an unnecessary number of options.

Further thoughts/questions

• Will the pill UI still have a hover state like you've shown/discussed in previous iterations?
  • I know your prev iterations included a hover state to show the keyboard shortcut for whatever mode you're in but I wonder if it would be more intuitive for the pill to render an "X" on hover to remove the pill and bring you back to the blank/standard command center state if that makes sense?
• The placeholder text "Search modes" in the input box feels a bit off since the possible modes represent more than just search (i.e. run tasks or run commands)

[daviddossett]

Thanks for the feedback!

Will the pill UI still have a hover state like you've shown/discussed in previous iterations? ... I wonder if it would be more intuitive for the pill to render an "X" on hover

Ideally, yes. We could do both—I'll try that.

The placeholder text "Search modes" in the input box feels a bit off since the possible modes represent more than just search (i.e. run tasks or run commands)

This indeed confusing now that I see it again. What I meant was to give the placeholder text something similar to what we do elsewhere. It acts as a filter of the list of modes below, hence "Search modes" like we would have "Search files" or similar. But it sounds like there are various modes of searching to your point. Open to suggestions here.

[gjsjohnmurray]

... hence "Search modes" like we would have "Search files" or similar. But it sounds like there are various modes of searching to your point. Open to suggestions here.

How about "Choose a mode" or "Pick a mode"?

[bpasero]

Cmd/ctrl + K to open the command center

In general it will be very hard to find an available short keybinding for this, given most keybindings have been taken already. We cannot use Cmd/Ctrl+K because we use it for keyboard chords in all keybindings that are chords.

Shows short list of most-used modes + ? to view all

I think there is a chance to do more here than just showing the available modes. For example in slack you see that in 1 row but you also see previous searches which might be helpful to rerun a quick open search:

File search would need to start using a prefix

File quick open is a bit special in that it actually also contains recently opened editors until you start typing, in a nutshell:

• quick open without search shows "recently opened" editors (this may include non-file based editors)
• when you start typing, we resort to a file-based search where we show "recently opened" files first, and then all results from disk

[daviddossett]

We cannot use Cmd/Ctrl+K because we use it for keyboard chords in all keybindings that are chords.

Oh right, good point. I'll think about some other options for this.

I think there is a chance to do more here than just showing the available modes. For example in slack you see that in 1 row but you also see previous searches which might be helpful to rerun a quick open search

Explored something similar to this in an older exploration pass. Still open to this:

File quick open is a bit special in that it actually also contains recently opened editors until you start typing

IMO that would be a fine behavior to keep even with a prefix. I'd much prefer it to a full sorted list of all files as the default state.

[daviddossett]

Had a good brainstorm with @kieferrm last week where he suggested an idea to just use this "home" view of the command center to list all of the available modes in a friendly, human-readable way. This basically takes the existing ? menu and uses the friendly labels as the main text of each list item. The prefix hint is then added as the supporting label.

Here's how this would look:

CleanShot.2022-09-06.at.14.28.25.mp4

Open questions:

• What default keybinding to use to open the command center?
• What prefix to use for "Go to File" if it not longer uses the blank input field?

[eamodio]

While I like the idea overall, having to use a prefix for files feels like it will cause a lot of friction and break muscle memory. I often clear the > to start typing in a file. Even if typing a file name still worked there you'd still lose the recent files list.

[daviddossett]

Yeah after sleeping on this I think it wouldn't be wise to add the prefix given the muscle memory we have today. It's unfortunate since I feel like the blank input state should really serve as the home view of the command center.

I wonder if files list and some subset of the modes could be combined somehow. Another thing I wouldn't want to break is the ability to quickly arrow down to a file in the files list. For example, we could do something like this..

..but now you would have to arrow down a bunch of times to get to a file. So there would be a tradeoff there, not to mention the potential confusion of mixing modes and files in one list.

I'll think about other options here. It doesn't feel right to instead come up with a special prefix like home or something, but that's a possible workaround.

[daviddossett]

Here's the latest thinking:

• Use a grouped list of popular modes + recent files as the command center/home view
• Typing here shows file results—could show other things in the future
• Selecting a mode from here navigates to that mode and shows a title w/ back button only when arriving from the command center.
• Using shortcuts e.g. cmd+p to go directly to Go to File shows same UI as today—no header. We don't want to break the good UX we have today.

CleanShot.2022-09-13.at.11.47.06.mp4

cc @TylerLeonhardt @kieferrm

[TylerLeonhardt]

Love it!

[bpasero]

I think I somewhat preferred the solution that would show the current quick open mode (file, symbol, command) as a little prefix to the left of the input field over forcing a title to quick open that takes away real screen estate for showing results.

Don't forget that a lot of people will just use quick open with standard keybindings not going through command center, so would we then always force the quick open title to this?

[TylerLeonhardt]

@bpasero if I understand @daviddossett's mock up correctly, the title will only be showed if you entered via the Command Center. If you enter via the usual keybindings, you won't see the title.

[daviddossett]

@bpasero if I understand @daviddossett's mock up correctly, the title will only be showed if you entered via the Command Center. If you enter via the usual keybindings, you won't see the title.

That's correct. This also doesn't eliminate the pills idea—that's still very much something I want to do. This home state is to make the modes discoverable in the first place. The pills are a nice decoration that makes it more obvious what mode you're in while giving extra benefits like keybindings on hover/focus on the fill, etc.

[bpasero]

Yeah I get it, but I am not sure a different UI for quick open depending how you enter it is a good idea. Why would the UI be any different when going via command center if the experience is pretty much the same? With the keybindings you could argue I am just directly jumping into a specific mode of the command center.

[daviddossett]

Showed a handful of options at standup today, including some forward looking examples with a Slack-like button UI. 5 min Loom walkthrough here. Based on the feedback, I think we've landed at a few principles:

• The command center can be considered a "launcher", different and decoupled from those existing modes (go to file, cmd palette, etc.)
• If you've navigated to a mode with a prefix e.g. > from the command center, clearing the input takes you back to the command center. If you had opened the command palette via a keybinding (in other words, you know what you're doing and how to get there), clearing the input works as it does today. It goes to file search.

Here's how this would look:

CleanShot.2022-09-22.at.16.14.12.mp4

Does this make sense given the constraints we're working around?