Search Sidebar Tab not opening when searching from URL bar

VERIFIED FIXED in mozilla0.9.6

Status

SeaMonkey
Search
P1
normal
VERIFIED FIXED
16 years ago
9 years ago

People

(Reporter: Todd Pringle, Assigned: Samir Gehani)

Tracking

Trunk
mozilla0.9.6
x86
Windows 98

Firefox Tracking Flags

(Not tracked)

Details

(URL)

(Reporter)

Description

16 years ago
Build ID:  2001091403

Steps to reproduce:

1) Launch Navigator
2) Make sure you do not have the search sidebar tab open
3) Type a search term in URL field, conduct search

Results:  Search Results appear in main window, Search Sidebar tab does not
open.  When Search sidebar tab is clicked on, there are the correct search
results in the tab.

Expected Result:  Search Sidebar tab should automatically open with correct
results when search is conducted.
(Reporter)

Comment 1

16 years ago
adding regression, nsbranch keywords.
Keywords: nsbranch, regression
(Assignee)

Updated

16 years ago
Status: NEW → ASSIGNED
Priority: -- → P1
Target Milestone: --- → mozilla0.9.6

Comment 2

16 years ago
If we move this to nsbranch+, please change the milestone to 095 as well.

Updated

16 years ago
Keywords: nsbranch → nsbranch+
Target Milestone: mozilla0.9.6 → mozilla0.9.5

Comment 3

16 years ago
nsbranch+/0.9.5, since it is a prominent regression.
(Assignee)

Comment 4

16 years ago
Claudius,
Can you help me out by isolating between which two builds this regression
occured.  (If sweetlou doesn't have enough builds then ftp.mozilla.org does
under the nightly directory.)  Thanks.

Comment 5

16 years ago
Bad news. Upon seeing this bug my first thought was "what the hell? I
specifically designed the browser search smoketest to secretly catch just such
an error!".
 
Upon checking the smoketest page and cvs blame I discovered that the smoketest
was changed way back on 8/17 to ignore this bug. I imagine tracy had some good
reason to believe that this was a desired change in functionality rather than a
bug since he "rewrote the testcase to match".

you can see the change at (or click the url field of this bug)
http://www.mozilla.org/webtools/bonsai/cvsview2.cgi?diff_mode=context&whitespace_mode=show&file=index.html&root=/cvsroot&subdir=mozilla-org/html/quality/smoketests&command=DIFF_FRAMESET&rev1=1.74&rev2=1.75

I'm just perplexed as to how that could be the case without me, todd, or
samir/matt being aware of it. Tracy, can you shed any light on this???

...

Regression information: <sigh> this is somewhat embarassing. I didn't catch this
cuz I don't test for it (i use the sidebar AND that's why i wrote the smoketest)
or maybe it was on the trunk when i was looking at a branch but anyway:

 the first build this bug manifests itself in on windows is buildID 2001081003
which is labeled as a 2001081010 build in the download directories.
It is working correctly in a windows build labeled with buildID 2001080904 which
is listed as a 2001080911 build in the directories.

Comment 6

16 years ago
some more research.
Bonsai says blake made the change. the checkin comment incorrectly refrences bug
56996 when the real culprit is actually bug 56969.

basically all that happened is blake set the pref to default the other way such
that the sidebar doesn't pop open at all sorts of unexpected times.

If you check any build where you see this 'bug' you'll see that your pref is
unchecked.

Comment 7

16 years ago
Right.  I talked this over with Matt and he thought this was the best thing to
do.    Do we want to change what this pref controls...?

Comment 8

16 years ago
German agrees in bug 56969 that the pref should default to off.  However you
raise a valid point here; if a user searches from the url bar, they may well
want the sidebar to open.  Here are the options I see, I hate all of them:

- close this bug; turn on the pref if you want the requested behavior.
- default the pref back to true; this is a horrible idea, since we made the
sidebar (and sidebar search) so intrusive in 6.x that we made many users hate
the feature.
- always open the sidebar when doing a chrome search, the pref only controls
sidebar opening for web searches; this is bad because it leaves no way to turn
off sidebar for chrome searches...
- add a new pref; one will control sidebar opening on chrome searches, and the
other on web searches.  New prefs are always a blast!
- get rid of the sidebar-opening-on-web-search 'feature' altogether; this has
been discussed at length in 56969.

Of these, it seems to me like the last one may be the best solution.  Do that
many users really love the sidebar popping open when they do a search on the
internet?  Wouldn't they just use the panel if they wanted that?  In 56969,
German said that the majority of users found this behavior intrusive, like popups.

Note that all of the above are easily and safely fixed, so we actually have the
luxury of choosing the one we think is right.
(Assignee)

Comment 9

16 years ago
Thanks for the investigation, Claudius and the options Blake.  My personal vote
would be to leave this off by default in Mozilla (we could mark this WFM adn
I've filed bugscape 9643 to override this in Netscape).  It is conceivable that
users who are acclimatized to this feature (of course, no real numbers to back
me up :o)) may not want it to be removed from under them.  Todd?

Comment 10

16 years ago
I am speaking directly from Netscape 6.x user feedback when I say that I don't
think the sidebar-opens-on-web-search behavior should be on by default, in
Mozilla or Netscape.  The response is overwhelmingly that people do not like it.
 They are confused that the sidebar pops up randomly, and can't figure out how
to close it.  We're trying to so hard to be convenient that we just end up
getting in their way.  Even German's usability data confirm that most people
just find it annoying.  Please, for the love of God, close that bugscape bug!

< deep breath >

There is another option that I think I favor: only show the results in the
sidebar panel (when searching on the web) if the user already has the Search
panel open, or if they already have the sidebar open.  This would be
considerably less intrusive.
(Reporter)

Comment 11

16 years ago
Samir, that sounds like a good plan.  This is a feature that we have marketed
and has been well received by the press, unfortunately we don't have a large
amount of user data about the behavior.  I think it is useful and can be made a
lot more useful with some of the improvements we've talked about, plus it gets
users more accustomed to using the Sidebar area more generally.  

Blake's points are good ones, I have read the feedback as well and I know that
there are a not insignificant number of users who really don't like the current
behavior.  I have, however, also noticed  a decline in the number of complaints
about Sidebar generally and a rise in the number of comments from people who
find it very useful since 6.0.  I've always believed this feature, and Sidebar
in general, is something that users will see the value of after getting more
familiar with it. 

I think it makes sense for Netscape to keep it on by default, though I think
Blake's suggestion about web searches is a good one too - i.e. for these types
of searches we should only present results if the sidebar is already open.  For
chrome searches (sidebar/url bar) we should display results in the sidebar
regardless (unless pref is deselected).  Is this something that we could do
easily though at this point?

I'd also like to hear some updated input from German on this subject.

Comment 12

16 years ago
Yep, that is something that we can do easily at this point, and the patch is
small. I will have it tomorrow.

Comment 13

16 years ago
the current proposal actually is the sol'n for the exact original reason bug
56969 was filed - no matter what it says now. It you read the summary and some
of the mpt vs. claudius back and forth the heart of the issue was the sidebar
opening on _web_ searches in addition to chrome searches. I think the current
proposal is an acceptable sol'n.

I will point out however that the one resounding result of seamonkey usability
studies from day one that we are all aware of and still holds true is Jane User
does not know the difference between chrome and content(where does the browser
end and the web begin) AND doesn't really care.

I'd close this as a dupe but that'll causee more trouble than it saves but when
this gets checked in I'd consider the previous bug closed as well.

Comment 14

16 years ago
I think this last proposal is inconsistent with the pref.  If the "Open the
search tab in the Sidebar when search results are available" pref is checked, it
seems the user would expect it to be opened, and not just displayed if already
open.  The consensus in bug 56969 seems to be that web search results should not
be shown in the sidebar, although I think that the pref wording would need to be
clarified if that was changed.  Perhaps we need a second pref for web searches,
one that hopefully would default to off?
<bluesky>I think it would be ideal if the program could somehow tell if the user
repeatedly slammed the sidebar shut without using it in this case, and offer to
disable the pref for them.</bluesky>
Blake Ross stated in bug 95092 that sidebar opening upon a search was no longer 
the desirable default behavior.  That is why I adjusted the smoketest.

Comment 16

16 years ago
I am worried as well about what samir said:
"...It is conceivable that users who are acclimatized to this feature [...] may
not want it to be removed from under them..."
2 points here:
- since we have in the past had opt-out rather then opt-in we do not how many
folks are implicitly relying on this to work. It would be evil to change this
behavior
- once discovered a lot of users like the side-by-side feature of being able to
access the most recent results even when navigating away from the page

Based on what we know now my recommendation is: do not change current behavior
for Netscape (not sure about Mozilla) and do not remove this feature all
together. Also I am not in favour of changing behavior based on whether chromne
based or web based search as I don't think this distinction is clear to most
users. And no please lets not add more hard to understand prefs.
I also like trudelle's idea or a UI that can be tought be repeated user behavior.

Comment 17

16 years ago
Okay, simple and easy is good. So just to be explicit, we'll continue to open
the sidebar and display search results there iff the pref is on, and the pref
will continue to apply to any search, whether in chrome or web page. 
(Reporter)

Comment 18

16 years ago
Just to be clear, this means the pref should be turned back on by default in
Netscape.  Works for me.
(Assignee)

Comment 19

16 years ago
OK, Blake and I discussed all the recommendations after Peter Trudelle's
2001-09-19 22:29 comments and this is what we came up with (and I know I'm
creating more work for myself but this work will hopefully put this issue to bed):

Concerns
========
(1) Sidebar panel popping open is annoying in general.  Blake gathered this info
from Netscape 6.x user feedback.  Mozillians have voiced this very concern.

(2) When users search from a webpage they don't expect their browser to pop open
the sidebar.

(3) Users may already expect their search panels to be populated if they were
used to the feature from a previous release.

(4) Related to (2) and (3): it is convenient for users to use the sidebar search
panel for results from a search initiated on a webpage as well.  Note, that
populating the search panel does not have anything to with opening it.

(5) Whatever we do make sure the label next to the pref really expresses the
behavior we implement.

(6) Users don't distinguish between chrome- and webpage-initiated searches so
let's make their behaviors the same w.r.t. the search sidebar panel.
Recommended solution
====================
(1) Change the pref wording (and functionality) to "Open the Search tab in My
Sidebar when search results are available and My Sidebar is already open."
                                          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

(2) If the pref is on, switch to the search panel iff the sidebar is already
open (do not pop open the sidebar ever).  (Blake's earlier suggestion.)

(3) Always populate the search panel with results: chrome- or webpage-initiated.
   That is, even when the sidebar is closed -or- the sidebar is open *and* the
search panel is closed *and* the pref to open the search panel is set to false.

Satisfying the concerns
=======================
The sidebar doesn't pop open so concerns (1) and (2) are satisfied.
The results will always be populated so concerns (3), (4) and (6) are satisfied.
The pref description will be honest so concern (5) is satisfied.
The search panel will open (when the pref is on) for both chrome- and
webpage-initiated searches (current behavior) so concern (6) is satisfied.

Unless I hear a convincing argument otherwise with an alternate recommendation
for me to implement I'm coming up with a patch.

Comment 20

16 years ago
Not that I have a say in it, but I just don't understand why this would be
wanted on by default in commercial builds.  We have proof that people find the
behavior annoying.  Where is the proof that this is a widely liked feature, that
people understand why their sidebar is constantly popping open (no, it doesn't
just open when you search, it opens when you go back and forward too), and that
it's obvious to them that they should go digging in the preferences panel to
turn it off?  German's cursory usability testing (bug 56969) reflect the
sentiment of the many posts in the beta feedback newsgroups:

"Cursory usability testing on NS6 betas with that behavior were inconclusive at
best. Some who like the sidebar search feature also liked being prompted to the
sidebar results by it auto-opening.
For a large number of users though this seemed intrusive similar to popups.
After having looked at this I'd rather err on the non-intrusive side and tend to
side with mpt in that auto-opening should not be the default behavior. This is
especially true since it is usually not the beginners that change their default
config ie by closing the sidebar, thus we should respect this as a deliberate
user decision."

Since nothing has changed with regard to the intrusiveness of this feature since
NS6 betas, I am curious as to what yielded the sudden change of mind.  All of
the press that mentions this that I've seen has lauded the idea of showing
results in the sidebar, not the aspect of it that causes the sidebar to force
itself open when there are web search results.  If there were new usability
studies that showed that a majority of those tested either enjoyed this feature
or understood how to turn it off then I'd love to see them, but none of have
been mentioned (but anyways, I don't see why the opinions of a group of 10
off-the-street people are more valuable than those of the users who submitted
all the feedback).

Users have enough trouble getting rid of the sidebar as it is.  We continue to
do more work in this area; I will be adding an X close button shortly, and have
fixed the automatic snapping open of the sidebar if resized too small. We have
worked hard (and continue to try to clarify) the distinction between collapsing
the sidebar via the grippy and *closing* the sidebar via View | My Sidebar or
the X.  Having this preference on by default blows that distinction out of the
water; as German noted earlier this year, it ignores a specific user-chosen
preference to have the sidebar closed.  Many here have commented that the
average user doesn't understand the difference between chrome searches and web
searches, and yet have suggested that the same user understands that

Grippy              --> collapses the sidebar temporarily but does not close it  
                        for easy reopening

View | My Sidebar/X --> closes the sidebar temporarily until a web search

Search pref         --> if off, View | My Sidebar/X are now permanent

Indeed, the pref makes the View | My Sidebar X a temporary setting.

I believe Samir's approach supersedes the need for a smart UI that requires the
user to say no multiple times for it to learn by making some valid assumptions
up front.  If the user has the sidebar open and the search tab on when they're
searching, it's not unreasonable to assume that they're interested in switching
to the tab to see the results.  The fact that the results will still appear in
the tab (but the tab just won't be switched to) if the sidebar is collapsed
satiates the desire to keep this feature, in my opinion.  For those concerned
about discoverability, we could consider modifying the approach to pop open the
sidebar if the user has it *collapsed* (an action which is understood to be
inherently temporary), but not closed.  The one thing in the plan Samir outlined
that I'm not sure I agree with is populating the tab with the results even if
the sidebar is closed, as we generally do not allow services to run in the
background like that.  (Samir, by 'closed' did you mean 'collapsed'? I don't
think it's even possible to put the results in a panel if the sidebar is closed,
since the panel doesn't exist...unless done upon reopening the panel).  Then
again, the current approach is just as much a privacy concern, but more
invasive: as far as the user is concerned, we're reading their search terms by
default even when they asked to turn off the sidebar.

I don't believe the current usefulness of the Search tab -- having a list of the
search result *titles* (not a description or anything else) -- outweighs the
evident cost -- an intrusive 'feature' that is unexpected, with no clear way how
to turn it off, and is obviously turning a number of users off to the browser
altogether. 




Comment 21

16 years ago
I think this is getting out of hand. There are many issues being raised here
that are morphing this bug way beyond the original report, but I don't think
this is a good medium in which to discuss them. Blake, if you could let me know
when you are available, I'd like to schedule a meeting.
(Assignee)

Comment 22

16 years ago
At the meeting we discussed reverting to turning the pref on accompanied by some
good UE measures to take care of the individual complaints users have about the
sidebar search feature.  To start, we will attack usability of the sidebar
grippy and the sidebar close (or 'x') button.  We will also address
communicating the notion of collapsed vs. closed to the user.  (Meta-issue: we
should revise our terminology, e.g. collapsed really means minimized which is a
concept users already understand.)
Keywords: nsbranch+

Comment 23

16 years ago
Chimming in a bit late but:
1.  Feedback in newgroups show that people are don't like the popup window but 
traffic data suggests that the sidebar search panel gets used more then both 
the search button and the search button on the personal toolbar. 
  A. On todds comment about data.  I filed bug 
http://bugzilla.mozilla.org/show_bug.cgi?id=100945 to get better feedback as to 
how people where using the sidebar search tab. We have no data indicating how 
much the results are used.

2.  In the past there was talk of having either a pop up on the first time the 
tab popped open asking if the user wants to disable this feature.  Or another 
idea was to make disabling the pref in the search tab.  This would make it more 
discoverable.  Most people in those complaints ask how to turn this feature off 
indicating that they can not discover the pref.

3.When i talked to blake about disabling this feature in mozilla I was going to 
enable it in the netscape version.

4. I agree with todd and german that we should continue to pop this open.  Data 
suggests that people do use the search tab.  This makes it much more 
discoverable.

Comment 24

16 years ago
The problem with offering to turn it off on the first open is that they haven't
had time to see any benefit from it, and then it is still not discoverable how
to turn it back on.  I think we just need to make it plain what (few) states the
sidebar can be in, how this affects its popping open, how to disable popping
open altogether, and then fix any individual cases where feedback indicates it
is popping open too aggressively.

Comment 25

16 years ago
This needs to be on the PDT radar screen.

Using 2001-09-27 commercial branch on WinNT, when I enter a search term in the
URL field, and then use the URL field drop down to initiate a "Netscape" search,
the search is conducted correctly. However, the Search sidebar tab is not
brought to the foreground. (Note that I do have My Sidebar open, with a
different tab in the foreground.)

This is a must fix.
Whiteboard: pdt
(Assignee)

Comment 26

16 years ago
sol, 
This has been addressed on the branch and I just need to checkin the fix for
bugscape 9643.  
(Assignee)

Comment 27

16 years ago
Old behavior restored on trunk.  (Branch checkin tracked by bugscape 9643.) 
Leaving bug open till we identify individual usability problems and have bugs on
all of them.

Comment 28

16 years ago
Thanks for clearing this up for me Samir.

Removing the PDT, since fix has been checked into the branch.
Whiteboard: pdt
(Assignee)

Comment 29

16 years ago
This has now morphed into a meta bug for the usability issues.
Keywords: regression → meta
Target Milestone: mozilla0.9.5 → mozilla0.9.6
(Assignee)

Comment 30

16 years ago
Sidebar usability review includes addressing the search popping the sidebar open
issue.  Issue being addressed therefore this bug can return to it's original
stature and QA can verify against it.
Status: ASSIGNED → RESOLVED
Last Resolved: 16 years ago
Keywords: meta
Resolution: --- → FIXED
this has been working (sidebar pops open on URL search) for many months now

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