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: