We really need to rethink this. Having the ability to switch between "basic" and "advanced" search modes in the app menu is just silly, given that it affects a sidebar panel. If the user has the search sidebar panel off, he'll have no clue what the submenu is for. I don't understand why we don't just have the ability to switch modes in the actual panel itself, where it belongs.
over to UI design. personally, I think it probably doesn't belong in the menu like Blake says, but it is nice advertisement for the feature.
Reassigning to German for comment.
Yes it is silly, but as I recall it was some sort of compromise. I never thought it was a good idea. Assinging this to JohnG for full explanation...:-), cc'ing dp, rjc.
amen. If you want to provide two different modes of search, a much better model was suggested: a twisty that expanded the region containing the menulist and placed the search panel in advanced mode, e.g.: Search: [ Ford Explorer..... ] > More... +------------------------+ | << results >> | Search: [ Ford Explorer..... ] v Less [ The Web ^ ] +-----------------------+ | [x] Raging.com | | [x] Google |
Isn't the ideal place for this the following? My Sidebar:Tabs:Customize Sidebar:Select Search Listbox Item:Customize Panel If not, what is Customize Panel for? Customize Panel should be Customize Tab but consistencies were handled in another bug.
*** Bug 47809 has been marked as a duplicate of this bug. ***
*** Bug 47602 has been marked as a duplicate of this bug. ***
There is universal agreement, me included, that the current menu selection is silly. I like Ben's solution. I'm working with Search folks (cc'ing myron) over here to see if they are willing to reopen or rethink the current solution.
nominating this to nsbeta3,ue1
Also as a side comment if we have settings/prefs: While we should not control any (removable) sidebar panel from a non-sidebar area (like prefs or menu) at all, at the very least the two current control option (basic/advanced and auto open) should be grouped together in the same place.
Remember that even without the search sidebar panel, there is still search functionality in the product... notice the "Search" button next to the location bar. And yes, it does have preference(s) associated with it.
We need a UI/UE decision on this immediately if we plan to get any kind of restructuring implemented for 6.0.
Recommend nsbeta3+ -- search is one of the major features in the product (you said so yourself), and the current UI makes it unusable and confusing. John, any word on this?
So here's my three cents: I agree with the common sentiment that the control of advanced v. basic modes should be integrated into the panel (not located under the Search menu). If you need a business owner to give you the go ahead to make this change ... here I am ... go ahead and make it. I also agree that Ben's suggestion of using a control that expands or collapses more/less search engines is a good one. (Ultimately, I'll leave it to the UI folks to determine how to expose or hide the additional search engines ... but the control should be with the panel).
Myron, Ben, RFC and others are right. Bad news, nsbeta3- due to pointy headed meetings and tight schedule. Good news, we have agreement to fix this after rtm.
firstname.lastname@example.org wrote: (begin quote) >over to UI design. personally, I think it probably doesn't belong >in the menu like Blake says, but it is nice advertisement for the >feature. (end quote) Actually, I think it's a really poor way to advertise the feature. Until I came across this bug report, I didn't even know that the feature existed (and was rather disappointed with the lack of features in the Search function.)
let's address this in the next point release.
*** Bug 60477 has been marked as a duplicate of this bug. ***
johng, are you going to fix this? If not, please reassign to someone who can.
See also bug 67414, "[rfe] remove the Search menu".
added Paul to cc list
No response from bug owner in four months; kicking him off, reassigning to owner of Search component. Not like that's going to achieve anything, but I'm sick of this bug lying around. Help wanted.
nav pretriage: matt's not going to get to this for a while. setting to Future.
Usability data shows that users are complaining about the complexity of the search UI, so we future the bugs to fix it. Ah yes, it all makes sense to me now. -> me
While Ben G.'s suggestion of the More/less button is a direct manipulation interface (which is generally good), I don't like the suggestion, because it clutters the UI IMO. I always want to see the search engines drop-down, so why should I have to see the "Less" button all the time? I'm never going to use it. It feels a bit like a tax that I have to pay for novice users using the same product as I do, while ideally, I should have the feelingas if the product were made for me, after configuration. (Actually, same applies to almost all "More/Less" buttons.) So, I favor a "preference" checkbox in the Customize Panels dialog (as suggested by <email@example.com>), lacking a better idea.
samir, this bug would be the bug we were talking about earlier
I think it should be taken out because how many times will you actually change that setting? Probably once or twice. Plus it's already in Preferences. Menuitems that aren't going to used often should just go in Preferences. I also think that the Search Sidebar should always be like Advanced.
Fixed by Ben in bug 85386.