Search | My Sidebar Search Panel is silly

VERIFIED FIXED in mozilla0.9.2

Status

SeaMonkey
Search
P2
normal
VERIFIED FIXED
18 years ago
9 years ago

People

(Reporter: Blake Ross, Assigned: Blake Ross)

Tracking

({helpwanted})

Trunk
mozilla0.9.2
helpwanted
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Assignee)

Description

18 years ago
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.

Comment 1

18 years ago
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.
Assignee: matt → bdonohoe
Component: Search → User Interface: Design Feedback
QA Contact: claudius → mpt

Comment 2

18 years ago
Reassigning to German for comment.
Assignee: bdonohoe → german

Comment 3

18 years ago
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.
Assignee: german → johng
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            |

Comment 5

18 years ago
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.
(Assignee)

Comment 6

18 years ago
*** Bug 47809 has been marked as a duplicate of this bug. ***

Comment 7

18 years ago
*** Bug 47602 has been marked as a duplicate of this bug. ***

Comment 8

17 years ago
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.

Comment 9

17 years ago
nominating this to nsbeta3,ue1
Keywords: nsbeta3, UE1

Comment 10

17 years ago
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.
(Assignee)

Comment 12

17 years ago
We need a UI/UE decision on this immediately if we plan to get any kind of 
restructuring implemented for 6.0.
(Assignee)

Comment 13

17 years ago
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?

Comment 14

17 years ago
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).

Comment 15

17 years ago
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.
Whiteboard: [nsbeta3-]

Updated

17 years ago
Whiteboard: [nsbeta3-] → [nsbeta3-][cut 0922]

Comment 16

17 years ago
claudius@netscape.com 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.)
(Assignee)

Comment 17

17 years ago
let's address this in the next point release.
Keywords: ns601
Keywords: ns601 → mozilla0.9

Comment 18

17 years ago
*** Bug 60477 has been marked as a duplicate of this bug. ***

Comment 19

17 years ago
johng, are you going to fix this? If not, please reassign to someone who can.
(Assignee)

Comment 20

17 years ago
*cough*

Comment 21

17 years ago
See also bug 67414, "[rfe] remove the Search menu".

Updated

17 years ago
Blocks: 67414

Comment 22

17 years ago
added Paul to cc list

Comment 23

17 years ago
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.
Assignee: johng → matt
Component: User Interface: Design Feedback → Search
Keywords: helpwanted
QA Contact: mpt → claudius
nav pretriage: matt's not going to get to this for a while. setting to Future. 
(Assignee)

Comment 25

17 years ago
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
Assignee: matt → blakeross
Keywords: mozilla0.9, nsbeta3, UE1
Whiteboard: [nsbeta3-][cut 0922]
(Assignee)

Updated

17 years ago
Priority: P3 → P2
Target Milestone: --- → mozilla0.9.2

Comment 26

17 years ago
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 <jamacht@pobox.com>), lacking a better idea.

Comment 27

17 years ago
samir, this bug would be the bug we were talking about earlier

Comment 28

17 years ago
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.

Comment 29

17 years ago
Fixed by Ben in bug 85386.
Status: NEW → RESOLVED
Last Resolved: 17 years ago
Depends on: 85386
Resolution: --- → FIXED

Comment 30

17 years ago
VERIFIED Fixed
Status: RESOLVED → VERIFIED
Product: Core → SeaMonkey
You need to log in before you can comment on or make changes to this bug.