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.
adding regression, nsbranch keywords.
If we move this to nsbranch+, please change the milestone to 095 as well.
nsbranch+/0.9.5, since it is a prominent regression.
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.
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.
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.
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...?
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.
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?
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.
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.
Yep, that is something that we can do easily at this point, and the patch is small. I will have it tomorrow.
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.
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.
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.
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.
Just to be clear, this means the pref should be turned back on by default in Netscape. Works for me.
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.
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.
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.
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.)
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.
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.
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.
sol, This has been addressed on the branch and I just need to checkin the fix for bugscape 9643.
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.
Thanks for clearing this up for me Samir. Removing the PDT, since fix has been checked into the branch.
This has now morphed into a meta bug for the usability issues.
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.
this has been working (sidebar pops open on URL search) for many months now marking verified