426099 - AwesomeBar / Location bar / URL bar UI suggestions for privacy concerns

Status: RESOLVED INVALID

(Firefox :: Address Bar, enhancement)

Description

[J. Kanowitz]

User-Agent:       Mozilla/5.0 (X11; U; DragonFly i386; en-US; rv:1.8.1.8) Gecko/20071218 BonEcho/2.0.0.8
Build Identifier: Mozilla Firefox 3.0b4, Copyright (c) 1998 - 2008 mozilla.org

I see a lot of criticism of the "AwesomeBar" floating around.  Despite some searching, I did not find a bug devoted to discussing or addressing these concerns.  I assume this is going to be a dupe, but at least it'll show up for others searching these keywords.

Let's say it:  For a lot of people, the AwesomeBar as implemented is the "Surprise! That'sALotOf____Bar!"  While this is certainly amusing, it should be possible to implement the feature in a more "sensitive" or "useful" manner.  Some suggestions, from a UI perspective, are offered below.

1:  Opt-in with a verb
Users are familiar with the old bar, and have come to terms with its tradeoffs.  (Note the number of users upset that familiar behavior -- such as 'g' for Google -- is no longer predictable.)  The "/" operator is already familiar to users of type-ahead find configured to require it, and in the common case could be satisfactory as a verb to activate the "awesome" search feature.  Unfortunately, it does conflict with the path character for UNIX users browsing to local files.

2:  Add a different verb
Since this is a significant new feature giving people headaches, CTRL-/ or ALT-/ (or Macintosh equivalents) could be used to open an "awesome" search pane or window.  This would have added efficiency in that the window could include tabs to narrow the search scope to [H]istory, [B]ookmarks, or Web [S]earch (Assuming [E]verything remains a default); if ALT were used as the modifier, a simple [ALT] [/] [H] [Release-ALT] sequence would function as a powerful verb.  Contrast this to the difficulty of adding scope verbs to the location bar without getting verbose or stomping on actual domain namespace.

3:  Opt-In at install time
Since the new behavior is surprising, it probably makes sense to prompt users as to whether they want their bookmarks and history searched, with appropriate preferences or flags thus set.  Since users should probably be informed of the new functionality, [History (N results found)] and [Bookmarks (N results found)] could then become monolithic items in the "awesome" dropdown, requiring action to expand.

4:  Opt-Out at runtime
Bookmarks probably deserve a field to prevent them from appearing in search results, or at least extended "awesome" search results; in turn, there should probably be a fast path to knock a visited domain out of the History without resorting to coarse-grained 'Clear Private Data' knobs.  See below for some thoughts on adding this to the UI in a constructive, rather than reactionary, way.

5:  Ignore common words
"Awesome" search could, via a preference, ignore matches for common words like 'the' until a larger phrase is matched.  This adds complexity, but would reduce the number of distracting results.

6:  Proactive privacy
Entering the realm of silliness, users could add hashes for terms or results they don't want matched, and substrings and result strings could be checked against those hashes.  This would probably be (extraordinarily) computationally expensive, but wouldn't expose the list directly.  This idea may have more utility in terms of obfuscating tags (half-baked) or obfuscating domains associated with metadata, which could have its own interesting applications.

7:  Reconsider Search
Some of the backlash against the "AwesomeBar" relates to the semantics of going somewhere known (conventional use of the location bar) versus searching for something unknown.  It's quite possible that the "awesomeness" should live in the Web Search bar/the CTRL-K Web Search feature instead, where the existing verb is appropriate and local results would save users a trip to the search engine.  The same idea about enhanced keyboard verbs probably applies here, where it could be made possible to define scope while the modifier is still pressed.

8:  Reconsider Bookmarks and History
Right now the bookmark feature spreads across two keyboard verbs (CTRL-B and CTRL-D), and the history pane lacks the ability to create bookmarks.  It would probably be plausible to make "Awesome" search accessible from any of these starting points, and tweak the CTRL-B bookmarks pane to allow both search and addition of bookmarks ("[CTRL] [B] [A] [Release-CTRL]" to add the current page?).  In fact, if those features lived as scope tabs of a generalized "Awesome" subsystem, all the management features, including enabling/disabling the proposed "Appear in Awesome Results" flag, could be unified, and the need to slosh the functionality into yet another place (the location bar) would be reduced.

9:  Reconsider the Location Bar
Following from the last idea, now we're back to square one:  Why can't the location bar have scope?  Instead of separating even "Web Search" into a separate feature, or performing "magic" with input (sometimes it's a URL, sometimes it's a local path, sometimes it's a keyword for a non-DNS namespace, sometimes it's a search term), why not scope it with either prefixed or postfixed verbs?  Mozilla and Firefox have had a history of this with CTRL-Enter, etc.  For mouse users, there's already a "Go" button; instead of the entirely separate 'Web Search' box, why not have a "Search" button to reveal the Awesome as well, and a "Search the Web" button?  In the case of "Search the Web," if the user hasn't modified the string in the location bar it could jump directly to the search engine's home page.


Hopefully there's at least one good idea buried in the above.

Reproducible: Always

Comment 1

[Robert Glover]

First, let me say that I agree with most of the above with the added thought that the AwesomeBar should be a plug-in, not part of the core.  And at this stage, my opinion of the "AwesomeBar" (plug-in or not) is that it's not ready for release.  It needs months and months of further shakedown before it should be included in a release version, but it's out there in RC1 right now.

* Please for the love of God, make it a plug-in instead.

The Awesome bar is the only Firefox annoyance that actually is making me consider another browser.  I hope it doesn't come to that though.

Oh, and it's always a good idea to vote for your own bug.

Comment 2

[cooolsterx-firefox]

While the parent is very detailed on some well justified privacy issues, most options above are likely to increase the complexity of the interface for novice and power users alike. Additionally, it would take a seasoned user comfortable with tweaking options or about:plugins to be able to utilize them correctly and efficiently. 

The biggest privacy concern IMHO is for novice users who have come to accept certain default behaviors from browsers. Consider this example that I previously posted for Bug 424557 (https://bugzilla.mozilla.org/show_bug.cgi?id=424557#c18) which I repost below:    

Say Bob has a default installation of FF3 on his HTPC. He has a cache of some
ummm... interesting bookmarks. Friends come over and would like to check
something online. They start typing in the awsomebar and the dropdown suddenly
shows up the most unexpected results on his high def 52" screen TV! 

And Bob doesn't even know what hit him for his bookmarks were last thing he
expected anyone to check and in any case, he had hidden them well in a deep
hierarchy of folders! And whats more, he had even cleaned up his browsing
history before the friends arrived!

So again, the issue is not merely having an option in options or about.config. It's about letting the user know prominently during installation, or immediately after creation of a new profile, that not only his/her browsing history (which is a default in most browsers including FF2, hence a generally expected behavior!) but also his bookmarks will start appearing in the awsomebar. More importantly, right there should be a single click opt-in/out for bookmarks!

Once the above is in place, the field is wide open for users desiring fine grained controls to use/implement Options/About:config/Add-Ons.

Comment 3

[morisdov]

As a technical person responsible also on the selection of base image applications in our many training rooms, in a very large multinational corporation - I have been instructed to revert to version 2 of Firefox, following numeruos complaints of users on the undesired functionality of the awesome bar in Firefox 3.
Apparently many users demand - on their daily machine - to remove the new version 3 and rollback to version 2 of Firefox, because of this annoyance.

As a general policy Firefox 3 was considered more secure and noticably faster than firefox 2 but our IT department stopped fighting end users requests and are reverting to version 2 without questioning and rolled back to version 2 on all new PC's.
I also seem to find the AwesomeBar an overfeatured unwanted exercise in trying to fix something that was just fine, surely not broken. The AwesomeBar is less functional and less productive. Its UI design and function design are counter productive.

Please provide an option to remove or disable the AwesomeBar to enable us the speed and security of Firefox 3 !

Comment 4

[Emerson Prado]

I back Comment #3. My suggestions:
1.To allow the user to select whether to show bookmarks or not, and whether to show history or not - they can be independent, as some will want everything, some nothing, etc.
2.Make it simple - inside Options, not hidden into about:config
3.Make the default consistent with previous versions - Yes to history and No to bookmarks
4.Let the user know of this new feature and how to activate it - maybe a tip during installation or prior to first use
I saw the bookmarks listing as an annoyance, rather than a feature, and many seem to agree. But many will disagree, so having the option seems the safest choice. But I emphasize the default should be the old behaviour, so we don't mess with users already used to it (like myself).
Thanks.

Comment 5

[David McRitchie]

From the standpoint of user control:

If you do go the option route.  
Make it optional to include or not include field search on each of -- 
name(/title), location(/url), keywords(/alias), tags, description  from history; and
name(/title), location(/url), keywords(/alias), tags, description  from bookmarks;
and as typed into location bar.

Comment 6

[Shawn Wilsher :sdwilsh]

This bug isn't valid.  Bugs aren't supposed to be used for "discussion" - that's what the newsgroups are for.  Additionally, a bug should only have one feature request in it, whereas this has multiple.

For what it's worth, Firefox 3.1 will have a number of additional options to better control the behavior of the location bar.