-
Notifications
You must be signed in to change notification settings - Fork 28.5k
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
Introduce a "home" command center view #158638
Comments
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 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
|
Thanks for the feedback!
Ideally, yes. We could do both—I'll try that.
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. |
How about "Choose a mode" or "Pick a mode"? |
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
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 quick open is a bit special in that it actually also contains recently opened editors until you start typing, in a nutshell:
|
Oh right, good point. I'll think about some other options for this.
Explored something similar to this in an older exploration pass. Still open to this:
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. |
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 Here's how this would look: CleanShot.2022-09-06.at.14.28.25.mp4Open questions:
|
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. |
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 |
Here's the latest thinking:
CleanShot.2022-09-13.at.11.47.06.mp4 |
Love it! |
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? |
@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. |
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. |
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:
Here's how this would look: CleanShot.2022-09-22.at.16.14.12.mp4Does this make sense given the constraints we're working around? |
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
?
to view allThe text was updated successfully, but these errors were encountered: