Improve layout in horizontal search view

[isidorn]

Now that search view can be moved to the panel area we need to improve the layout to take advantage of the additional horizontal space.

• Change the font to be like the one in the editor so the whole view has more of a editor like feel.
• Labels and input fields should go on a single line
• x should be on the left to not be so disconnected (same as open editors)
• Twistie should get proper color

[bpasero]

@isidorn another thing to discuss in UX is discoverability of search when it moves to be a panel where there is no visible action in the UI to trigger it.

[isidorn]

Another thing is how to discover the settings and how to move it. One idea is for the activity bar context menu actions to aslo have "move to panel / move to sidebar" which would just write the setting. An alternative is to allow drag and drop but only for search - I think this is less discoverable and has the downside of us not allowing it for other viewlets.

Anyways we can discuss in ux meeting

[isidorn]

Also what you mention seems to be a general issue with the panels and not search specific.

[bpasero]

@isidorn true

[roblourens]

Is it strange if the layout is very different when the view is in a sidebar vs a panel? If I move the view from one place on the screen to another, I wouldn't expect it to totally rearrange itself.

On the other hand, it seems like one should be organized to conserve horizontal space, and the other should conserve vertical space.

Labels and input fields should go on a single line

I like the way that the input boxes line up with the text results below on the left edge. Since the labels are not the same length, we would either left-justify the labels and have the text inputs not line up, or align the text boxes but lose the common baseline on the left. Example, sublime has the second approach:

Radical idea, we could merge the include/exclude boxes and use ! to indicate exclude patterns. More like sublime and atom.

x should be on the left to not be so disconnected (same as open editors)

Should all of those row decorations (x, count, and replace button) be on the left? How does that fit in with the indentation and the twistie on the file?

Change the font to be like the one in the editor so the whole view has more of a editor like feel.

Should we also do this for the code in 'find all references'? I think that's been discussed.

[isidorn]

I think it is fine if the layout changes in a non dramatic way.
Also I think there are things which we can change that can benefit both horizontal and vertical layout.

I like the sublime approach of aligning to the right.

I am always open for radical ideas, but not sure what we save on that. Since we have enough horizontal space to put two of those boxes on the same line. And changing something that the users are used to is always problematic.

Yes, clickable actions should go to the right (count should stay where it is since it is not so important imho). I think we can still align them nicely wrt the twisite - there is enough space. Checkout how open editors pushes the x to the left.

Find all references should also do it, but I think we tried it out and people hated it for some reason. Let's first see how it looks in the search view before we make any big plans.

[roblourens]

Since we have enough horizontal space to put two of those boxes on the same line

I'm not sure if I like that. I think at least we would have to keep the labels above the input box. Two labels and two input boxes inline would take up too much horizontal space. Especially in German :P

but not sure what we save on that

I think that packing input boxes into a small space could make it look more complicated than it is. Like a bad web signup form.

Otherwise, for changes like that, we could just go with a responsive design where it reflows when the view is narrow enough. Instead of making assumptions about how much space we have based on where the search view is.

Putting the x on the left is consistent with tabs and Open Editors, for the File row, it would be sticking into the margin unless we move it over. Might want a designer's feedback.

[isidorn]

Responsive design would definetly be the best and most general solution.

@roblourens maybe you talk to some designer in Redmond to sketch up something?

@stevencl do we have some designer available for tasks like this?

[pavelloz]

I think it should expand the bar if there is not enough horizontal space to fit options opened.

scrollbar would not be a good solution IMO, some kind of min-height + auto-expand would be nice.

Example use case where content is cut off:

Before expanding replace:

After:

[GammaGames]

Just some fan input:
For the search result items you could keep the file on the left, show the result's line number in the middle, and show the matching content for the rest of the line.

This would get rid of a little vertical space if you match a lot of files, and would add the line number into the search (something people have wanted #39219). You'd have to be more precise to fold a file since you couldn't click the entire line anymore, and pressing "enter" with the folder highlighted would select the first open file instead of doing nothing (like it currently does), but other than that I don't see too much of an issue with the difference in navigation.

EDIT:
I agree with @roblourens on combining the include/exclude boxes. There's two variations, one where the "files to include/exclude" are on the top line, and one where the "Replace" input is on the top line. Vertical space is really important, and I think some rearranging and combination would help a bit

[evelant]

The horizontal layout is a great opportunity for including #16488 -- multiple searches could be shown as sub-tabs as they are in other editors such as webstorm.

[garygreen]

It would be great if you could also include:

• Ability to close search panel by pressing ESC (same as Atom)
• New config option to automatically open search panel in "maximise panel size" mode, maybe search.maximise
• Collapse All / Expand All buttons
• Line numbers next to each matching bit, so you know roughly how far the matching text is in each file

[roblourens]

Thanks for the suggestions. @GammaGames showing the first result on the same line as the file name is an interesting idea and could save some space. But unless we put the whole thing in a grid-like view, the text results would not be nicely aligned on the left side anymore because the alignment would depend on the length of the file name, and thinking about how to show it with long file names could get complicated.

I was also thinking about how to get something on the same line as the search query box, but I don't want the replace or include/exclude boxes to be visible all the time, and showing/hiding those inline would be unusual.

@garygreen

1. You can create a keybinding for this yourself, but it doesn't match the way many of us use the panel so I wouldn't set that by default
2. See the "Toggle maximized panel" command, not exactly what you ask for but it should help
3. We have Collapse All, but not Expand All
4. I would like to revisit line numbers at some point

What do people think about scrolling the view container all together, instead of just the search results? I think this would make browsing results easier when the vertical space is constrained.

Another idea, when the view is wide, switch to text-based buttons. We don't have to use these tiny icons to save space in a very wide panel view, and text labels will be less ambiguous.

[GammaGames]

unless we put the whole thing in a grid-like view, the text results would not be nicely aligned on the left side anymore because the alignment would depend on the length of the file name, and thinking about how to show it with long file names could get complicated

If more info is going to be shown horizontally (line numbers, etc) it would make sense to move to a more grid-like pattern anyway. Komodo just truncates the filenames and paths, which seems to work.

showing/hiding those inline would be unusual.

I thought that too, maybe an option to hide the inputs other than the main "Search" input on showing results would be better? Hiding everything in options can be a nightmare though, so automatically hiding them on tabbed search results (similar to Komodo) would be a better solution, at least for me.

I think scrolling the view container would certainly be better than the current panel, right now it's difficult to see results without resizing the it!

As to the buttons, the icons (especially ) did take a minute to learn, and having labeled works might fix that, but I do like the icons now that I know them. But I like icons more than text for interfaces, so I'm biased.

[JAStanton]

Two things I love about Sublime Text search:

1. Ability to provide search context. By default it shows 2 lines before and after. (Am I missing an option for this in VS code?)
2. The results are in a text buffer and I can search my search results. It would be akin to grep "foo" -C2 -r ./dir/* | grep "bar".

Combined these two features are very powerful

[roblourens]

I am a fan of a tree view over a grid view, and I don't have a good tree-grid control right now.

Tried some things around this point:

x should be on the left to not be so disconnected (same as open editors)

Also ignore the fact that these mockups show the activity bar, I was just testing them in different contexts... this is either with search in the panel specifically in mind, or for both.

A) Mockup of current view with Xs on left

I have a negative reaction to this right away. I don't like that the X feels like it's getting in the way of the file collapse twistie. When a user is clicking around to collapse several file results, it's dangerous to put the delete button right there.

Maybe it would be better to put the X inside the twistie but I don't want to shift the file name over when hovering that row, which we would have to do to make room.

B) We could also put them on the right, but just at the end of the text. Then we also have room for the replace button.

Downside is that they aren't lined up vertically so it's hard to remove several in a row quickly.

Some prior art for this, in the problems view, each file row has its count at the end of the row. And a location, which we should also copy for search!

C) I am also interested in text-label buttons like this mockup. Possibly expanding them from the icon buttons when we have extra room. I think they look more natural than the icons in a wide view, but we don't have any UI element like this in VS Code and it looks un-vscodey.

D) Maybe it would look ok on the right side if there's something else that pulls it together. I kind of like the look of a border on each file name row

E) Or just leave it as is

[pltrant]

I agree with @JAStanton on the useful features from Sublime search that can hopefully be reproduced here. The other benefit of it being a text buffer (or document) is that you can then save the results. I also think it would be useful to have before/after context lines as an option, which you could also apply syntax highlighting to based upon the file type (i.e. if the search result shows up in a javascript file, apply javascript highlighting).

Also, I would prefer not to lose the Search icon from the Activity Bar, regardless of where the search is positioned. It makes it easier to access as a shortcut.

[GammaGames]

Maybe it would be better to put the X inside the twistie but I don't want to shift the file name over when hovering that row

The editors have extra whitespace for the X when it's not showing, so the X for the search result could also just have empty space so that the X appears without shifting the text? (Hopefully I read that sentence right).
Alternatively, I did notice that the number of matches per file on the right is replaced with the X when you hover over it. Maybe if moving the number of matches to the left of each folder, adding the line number in front of each result, and replacing the numbers with the X icon it might work

I kind of like the look of a border on each file name row

I really like that! It makes it easier to differentiate between files.

Also, I would prefer not to lose the Search icon from the Activity Bar

That's one thing I miss, I'm learning the shortcuts but I thought it was nice to have that button on the left. I know this is off topic, but adding optional buttons for togging the other panels into the activity bar might be a nice feature, since I normally have the panels hidden until I want them.

[isidorn]

Nice work with the mockups. Some feedback:

• I would also try one where X is left aligned for all the items - so all the way to the left. We can also move the twistie a couple of px to the right for better separation. Keep in mind that if X moves to the left so should the replace button, so I would also leave space for that which would in the most common case create a separation between twistie and X
• I dislike the labels, they feel out of place
• I like the include / exclude merge
• I feel like the files to include/exclude is now the only title in that area and feels out of place. I would also experiment with removing it and enriching the placholder text
• I am not sold on moving the x to the left but would experiment with it a bit more.
• I do not like borders but that is a personal preference since I like minimalistic design
• Placeholder text should be more transparent, currently it looks like input in the include / exclude box. It should not be so strong.

Just my 2 cents

[roblourens]

I don't like the way that the results tree isn't nicely left-aligned with the search inputs anymore. It feels like it's floating in space.

When replace is not active

Maybe a little nicer if we make room for the query controls on the left. Then things can line up.

I still wonder whether these less-often-used buttons with side effects (X and replace) are too close to a very often used button (twistie)

[roblourens]

Placeholder text should be more transparent, currently it looks like input in the include / exclude box. It should not be so strong.

This is true in your theme, but it looks nicer in Monokai and Dark+. It's up to the theme.

[GammaGames]

Maybe a little nicer if we make room for the query controls on the left. Then things can line up.

It's definitely more satisfying to look at, but there's so much empty space it kinda bothers me. And I like the "File Patterns" text more, maybe put the full text (with examples) in a tooltip? The normal search and replace have tooltips, though they're useless.
The "Search" input has the dedicated space with the twistie to the left side, how would the ... menu look to the right of the search/replace inputs?

[benomatis]

Any reason search results could not be shown in an editor instead? If nothing else, it could be an option, because I, for one, think it'd be much easier to see than having to scroll down and through it, or having to click on Maximise Panel Size (having it open automatically, as suggested by @garygreen, wouldn't help much as clicking the result would show the file in a tiny space above, so one would have to click Restore Panel Size again in order to see the file content). I believe Sublime Text and Atom do a great job in doing this, and it's the only thing (better search experience) that I'm missing form vscode.

[isidorn]

@roblourens

1. I am using the default light theme, in the default themes the color should be nice. I have created Search: placeholder color too strong in default light theme #45841 so we fix this (this is basically unrelated to the horizontal search discussion)
2. We shuold transition the previous include and exclude to the combined input Search: transition include and exclude patterns to new combined input #45844
3. To save space instead of examples you could use e.g. or just put it in brackets which I think could work. File Patterns (src, !*.ts...
4. Nice mockups, moving all the actions to the left makes sense for horizontal however it would piss off people when in viewlet area. I would not be so brave to change this.
5. The elipses makes me wanna keep the 'files to include / exclude' title so they are aligned, but let's experiment with the elipses position a bit more

Just my thoughts, let's present in the ux meeting today to get more feedback.

For people asking about search results in the editor. You can write an extension for that, and if we fail in making the horizontal search satisfy the needs of customers asking for results in the editor then vscode team could invest in that extension to make it nice and polished.

[stevencl]

It would be worth considering a different layout when in the horizontal panel. For example, we could put the results to the right of the controls, allowing more room for the list of results than in the current horizontal implementation but still allowing more vertical room for each individual result:

[isidorn]

@stevencl if we decide that we want a brand new layout for the horizontal search then we can do special things (something like you proposed). But in a perfect world we would first improve the layout such that both sidebar and panel benefit, and hopefully the layout is dynamic in a way that it moves when there is more space available. Anyways let's discuss in the ux meeting in greater detail.

[roblourens]

moving all the actions to the left makes sense for horizontal however it would piss off people when in viewlet area

My thinking is that moving actions to the left would only apply when the view is wide enough. It would make no sense in the normal narrow viewlet view.

@stevencl I actually really like that idea. It solves the problem of the header generally taking up lots of space, and of the results seeming too stretched out. It would also be easy to make the search view reflow like that when there's enough space.

@isidorn

and hopefully the layout is dynamic in a way that it moves when there is more space available

I see @stevencl's design as fitting into that category

[rickvanprim]

I kind of like the search fields on the left image. What if the fields stayed in the left panel, similar to Explorer/Debug/Extensions, and results stay on the bottom? That would be somewhat similar to Visual Studio proper where the search is a pop up, and the results go in the panel.

[roblourens]

Our viewlets and panel views are all self-contained things, I think it would be unexpected to have two of them working together like that. Would much rather find a solution that works well in just one.

Discussing this with people today, we couldn't come to a conclusion. We mainly looked at my mockup that puts all the controls on the left, and @stevencl's. I can't get excited about either one. We think that the large left margin on the first design looks out of place with other panels and feels off. No other panels have any sort of margin like that. I like @stevencl's but I don't think it will look natural when all the search fields are collapsed. We talked about using the extra empty space in that design for other features, like storing multiple searches, so we could revisit it later if we do that.

We discussed making it simpler by moving over just the X button or just the replace, and leaving the other on the right. I'm still not a fan of putting these right next to the file twistie on the left. I think the twisties are clicked 100s of times more often than the other buttons so I shouldn't have to aim carefully.

So eventually we came around to the idea that we could just leave those action items on the right side for now, with a few things to improve the experience:

• Move the item count from the right to sit just after the file label. This would match the problems view and be a big improvement.
• Add a context menu that includes the remove and replace actions. This will help their discoverability (some on my team didn't know about them anyway) when they are on the far right side. Also helps when horizontal scrolling is enabled and the action items are not accessible in the viewlet.
  • A context menu is also helpful for a bunch of other features, "copy path", "copy all matches" etc
• Change the "remove" keyboard shortcut from "cmd+delete", which I failed to guess, to just "delete".
  • Maybe allow "undo"
• Use a consistent shortcut for "replace" on a match and on a file. Right now they are different shortcuts for some reason and "replace" on a folder doesn't have a shortcut
• Fix a bug that in Monokai, the row highlight on hover is missing when the search view is in the panel

And we can also continue investigating

• Expand 'replace' box into the same line as the 'search' box when the view is wide. I think it's possible to have a good experience there.
• Try label-based buttons for "regex", "whole word", "case-sensitive" switches, as people lose track of which is which and that could be a better experience when we have room for them.

[isidorn]

@roblourens agree with the conclussion, those are small changes which would help with the experience.
I am not sure why you think the twisite is clicked much more than the other buttons. I personally never click it and always click on X. If I want to expand an item I just click on the whole item. So IMHO the twisties is not as importatn as you think. It is a visual indication, but not an important action.

As for the remove, just use the keybingind as everywhere else (breakpoints for example). Delete on windows and linux, cmd + back on mac. From the implementation perspective, make sure to use commands. Here's an example

Apart from those changes I would be interested in experimenting with a different font. To make it look more like an editor.

Let's try to get those changes in and then we can sync start of next week after we try this out for a day.

[mike-robertson]

Is there an option to make the base "in file search" use the new panel feature as well? I think that would be a good idea as well (for those of us used to the atom layout). Great job with this feature!

[GammaGames]

I am not sure why you think the twisite is clicked much more than the other buttons

Just me, but I don't ever use the X button. I only ever use the twisties because clicking the entire row collapses the file. Which made me think, moving the X wouldn't cause issues for me since I don't have to click precisely for the twistie anyway.
Allowing undo on clicking the X would be handy though, whether things are moved or not.

[mbenkmann]

I would like to have some integration between "Find All References" and the new search panel. I really miss the way that Eclipse allowed me to find all references across the whole project and display the file occurrences in an extra window like this new Search panel.
Let me know if I should open a new issue for this feature.

[andy-block]

I would also dearly love to see some way to make "Find all references" use the search panel as mbenkmann commented - in fact that is my biggest gripe with VS Code at the moment, and very nearly stopped me from using it at all when I first tried it (actually it did at first, but I gave it a second shot after a recommendation from a colleague). That would have been a shame, as I otherwise love it...

[roblourens]

Word-based buttons for search options:

Inline replace input:

Would want it to be resizeable

[roblourens]

All planned work here is done.

[ghost]

@roblourens I don't saw the news about search.location in https://github.com/Microsoft/vscode-docs/blob/vnext/release-notes/v1_22.md. It's still in preview or it's already done?

[marcusmalmberg]

@bsvipas it was in 1.21 https://github.com/Microsoft/vscode-docs/blob/vnext/release-notes/v1_21.md#horizontal-search

[ghost]

@marcusmalmberg Yes, but when you open settings you will see:

// Preview: controls if the search will be shown as a view in the sidebar or as a panel in the panel area for more horizontal space. Next release search in panel will have improved horizontal layout and this will no longer be a preview.
"search.location": "sidebar",

As you can see it says Preview. So I'm wondering if it's still done because I don't saw any notes in 1.22.0.

[roblourens]

We'll remove the "preview" tag for 1.23 :) @isidorn