Community
Participate
Working Groups
Selecting object types from the "Search For" combo box is considered hard and alternative should be considered. Dani proposed to introduce tabs. I tend to agree that this might be a good idea since this approach would remove the necessity of dynamically displayed "Advanced" parameters section
The issue with tabs may be that you end up with just as confusing a UI as the existing Search dialog (Search->Search...). It sounds like what you're proposing is a view that looks much like the current Search dialog, with the parameters & results sections duplicated on each, correct?
(In reply to comment #1) > The issue with tabs may be that you end up with just as confusing a UI as the > existing Search dialog (Search->Search...). Mmh, I've never heard that over the past 10 years ;-). Can you point me to a corresponding bug? > It sounds like what you're > proposing is a view that looks much like the current Search dialog, with the > parameters & results sections duplicated on each, correct? I proposed is to use tabs to choose the search instead of a combo. See all my comments in bug 331581 comment 9.
It may just be my own particular bias against multiple tabs. :) As additional providers start extending the new framework and adding more search options over time, my concern with the tabbed dialog approach is going to get out of hand even more quickly. There are already 7 tabs in the search dialog and 8 different search types in the Search Console's "Search for" combo. I know of two other search types already in the works from Danail and company, so that could bring it to ten tabs... Where does it end? That said... Now that I'm on the prototype branch and seeing this work with some of the older search types (file, java, etc.) I have additional questions to clarify some design goals for this component. 1) Without resizing the view in a horizontal fashion (or even making it vertical) it's obvious that some of the search types (Task Search, Remote Search, Git Search, etc) are not only too long to fit in the initial size (even with a workbench expanded to fill the whole screen), but too wide as well cutting off button labels, fields, etc. 2) Even breaking this view down and moving search criteria of different types into separate tabs won't fully address the resize issues currently in play. Is a horizontal or vertical view with integrated results really what we're looking for here? Or are we looking to have one view that offers the search criteria and another view that shows the results? If the goal is to eventually replace the existing Search dialog/Search results view, would it be better to go with the existing look and feel with a Search dialog of multiple tabs contributed by the new framework?
I agree that with the current state, real estate might become a problem. One will might have to show/hide the search area all the time. I also agree that with many searches, the tabs become less appealing, but keep in mind that products might ship with just a few of them. Also, in the current search dialog, the user can hide unwanted pages/tabs.
I'm good with hiding/showing tabs in the preferences. That's easy enough. My issue is with the integrated approach to showing not only the search criteria but the results in a single view. Hiding and unhiding that half a pane is (pardon the pun) going to be a pain. :) That said, switching to/from one view to the other will also be a pain. The logical solution (IMHO) is to move back to the search dialog + a search results view and divide it into two discrete steps instead of trying to combine everything in one.
> The logical solution (IMHO) is to move back to the search dialog + a search > results view and divide it into two discrete steps instead of trying to combine > everything in one. The appealing part for the SDK, is to have a replacement for the modal search dialog.
Hi Dani, Brian, The search console is meant to provide simplicity when searching and consuming the artifacts found. The analogy with Google: Google: - a keyword field and a "search" button - for those who think a keyword is not enough, there is "Advanced" search (http://www.google.com/advanced_search). But, how often do you use Google's advanced search!? Search console: - what to search for, where to search (if applicable), a keyword field and a "search" button - for those who think a keyword is not enough, they could make use of the custom search parameters UI shown in an advanced section, as defined in the org.eclipse.platform.discovery.ui.advancedsearchparams extension point IMO, tabs bring additional complexity. They neither save screen space, nor make switching easier. Introducing tabs would align all search providers to the existing search user interface. Effectively this means that searches would not be able to share the "keyword" text control. Thus, when I put the keyword in the wrong tab I have to enter it in the correct one as well. Using the wrong tab actually occurs pretty often to me since the UI in different tabs looks very similar. Having a combobox to select the things to search for would not solve this issue in existing eclipse searches unless they change their coding. However, search implementations contributed "natively" to the search console would be able to share common parameters user interface thus making switching between searches more convenient >As additional providers start extending the new framework and adding more >search options over time, my concern with the tabbed dialog approach is going >to get out of hand even more quickly. There are already 7 tabs in the search >dialog and 8 different search types in the Search Console's "Search for" combo. >I know of two other search types already in the works from Danail and company, >so that could bring it to ten tabs... Where does it end? Bug https://bugs.eclipse.org/bugs/show_bug.cgi?id=366308 targets this matter. A preference setting can limit the items in the combo to a set applicable to the concrete user needs >1) Without resizing the view in a horizontal fashion (or even making it >vertical) it's obvious that some of the search types (Task Search, Remote >Search, Git Search, etc) are not only too long to fit in the initial size (even >with a workbench expanded to fill the whole screen), but too wide as well >cutting off button labels, fields, etc. This has been addressed in https://bugs.eclipse.org/bugs/show_bug.cgi?id=366301 >The logical solution (IMHO) is to move back to the search dialog + a search >results view and divide it into two discrete steps instead of trying to combine >everything in one. The purpose of having parameters and results in a single view is to provide the user with "browsing" experience. Having two independent steps (e.g. a parameters view and a results view) might make the user loose the logical connection between the search criteria entered and the artifacts found. Regards, Danail
> IMO, tabs bring additional complexity. You mean to your code? > They neither save screen space, nor make switching easier. I disagree. If you have tab 'A', 'B', 'C' and 'D' the user can instantly make the decision without any interaction. That's not possible with a combo.
>> IMO, tabs bring additional complexity. >You mean to your code? Let's leave code complexity aside; in fact, having tabs would make the code less complex The complexity I am talking about is brought by the fact that there is no shared parameters UI where user's input is preserved. Referencing Google again - switching between the things to search for preserves user's input accross searches (maps, images, science, translation) so that the user does not have to perform the manual task of entering the keyword over and over again. Eclipse searches define their own user interface and neglect the possibility that the user pressed "Ctrl-H", simply typed the keyword without paying much attention to what the current tab is and then (usually after performing a search with irrelevant results) realizing that the keyword is entered in the wrong place. I don't know how you guys use eclipse search, but I cannot remember the last time I specified something other than a simple keyword as search criteria. That is why I consider "search by a keyword" to be the 90% search scenario and therefore we should target to making this scenario as simple as possible
(In reply to comment #9) > >> IMO, tabs bring additional complexity. > >You mean to your code? > Let's leave code complexity aside; in fact, having tabs would make the code > less complex > The complexity I am talking about is brought by the fact that there is no > shared parameters UI where user's input is preserved. Referencing Google again > - switching between the things to search for preserves user's input accross > searches (maps, images, science, translation) so that the user does not have to > perform the manual task of entering the keyword over and over again. Eclipse > searches define their own user interface and neglect the possibility that the > user pressed "Ctrl-H", simply typed the keyword without paying much attention > to what the current tab is and then (usually after performing a search with > irrelevant results) realizing that the keyword is entered in the wrong place. > > I don't know how you guys use eclipse search, but I cannot remember the last > time I specified something other than a simple keyword as search criteria. Eclipse search tries to bring the relevant page to front. Hence I can't remember that got results for the wrong search type/page. I never use the dialog for simple (keyword) searches. For that I use direct shortcuts, e.g. Ctrl+Alt+G. > That > is why I consider "search by a keyword" to be the 90% search scenario and > therefore we should target to making this scenario as simple as possible How do you want to make this work for the existing search contributions? Do you call all of them when I enter a keyword? With what options?
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it and remove the stalebug whiteboard tag. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. --
