Some great ideas here. :-) We had a meeting to discuss this potential feature
on 8/8/01. Meeting notes can be found at:
http://www.mozilla.org/mailnews/specs/meetings/NotesQkSearch.html
A lot of your suggestions and ideas are incorporated into the updated spec:
http://www.mozilla.org/mailnews/specs/qksearch/
Thanks for the feedback. More comments below.
Matthew Thomas wrote:
> Jennifer Glick wrote:
> >
> > A draft proposal spec for a Quick Search feature has been posted to
> > the Mozilla Mail/News spec page. Feedback wecome.
>
> <http://mozilla.org/mailnews/specs/qksearch/>:
> |
> | Open Issues
> |
> | 1. Name of toolbar? Quick Search is recommended.
>
> That sounds opposite to `Slow Search'. Users would begin thinking:
> `What's the catch? If it's so quick, is there a tradeoff in accuracy or
> something?' You might see this manifested in test users performing a
> particular search in the Quick Search Bar, not getting the results they
> wanted, then performing exactly the same search in the full search
> window to see if the results were better.
>
> How about just `Search Bar'?
Agree. Much better.
>
>
> | 2. If the account level is selected in the Folder Pane, can a Search
> | on the whole account be done? Or does the Search Toolbar become
> | disabled?
>
> Disabled toolbars, yum.
>
> The main search window assumes (but doesn't dictate) that the user will
> only want to search in a particular folder. (Otherwise `folder' `is/is
> not' {whatever} would be just another criterion for searching, rather
> than a popup menu of its own at the top.)
>
> So, I don't think it's too much of a stretch to make the Search Bar
> search only the selected folder. Which means it would logically appear
> at the top of the thread pane, rather than at the top of the window as a
> whole. When an account was selected, it would disappear along with the
> rest of the thread pane.
Agree. Search bar should appear above column headers. Disappears when Acct
Level selected. Seaches the folder selected in left pane.
>
>
> Of course, if you displayed a list of folders in the combined
> thread/message panes, rather than the `Account Central' thing, it would
> be obvious that performing a search with the account selected would
> search all folders in that account.
>
> | 3. Type of search? A - "contains" search on "subject", "sender" and
> | "body". B - "contains" search on "subject" and "sender" .
>
> +--------------------------------------------------------------------+
> | [ body :^] [ contains :^] [consistency ]|
> +--------------------------------------------------------------------+
To keep it simple, searching in main mail window will do a contains search on
Subject or Sender. It was felt that searching the body would greatly decrease
the speed. Looking for a particular subject or sender is prob the most common.
>
>
> | 4. Do we want to allow users to type in the +, -, or "" notations?
>
> Since the user's search string is unlikely to include these characters
> for any other reason, I don't see why not.
Since full Search dialog doesn't allow this, will not implement for now.
>
>
> | 5. Label text says "Search for:" or "Subject or Sender contains:"
> | "Depends on #3 sort of)?
>
> It also depends on whether you see this as a search or a filter -- of
> which more in a moment.
Will say "Subject or Sender contains:" by default. But allow users to change
the search to just "Subject contains:" or "Sender contains:" (probably in
prefs panel somewhere). Text in Search bar would reflect the user's pref.
>
>
> |...
> | Users who search a lot can leave this toolbar open if they prefer.
> | The default is closed. Mail should remember how the user last left
> | the toolbar (open vs. close vs. collapsed).
>
> FWIW, in Outlook Express for Mac OS this bar isn't optional, for the
> same reason that the category header in Mozilla's prefs dialog isn't
> optional: it's entirely possible for the currently selected folder to be
> scrolled or collapsed out of sight, so a title bar is needed for the
> message list (aka thread pane) to reassure the user about which folder
> they're in. The search widgets are just an accessory on this title bar,
> so they don't need a special name.
>
> |...
> | The user types the search criteria into the text field and clicks the
> | "Go" button or presses Enter/Return on the keyboard to begin the
> | search.
>
> There is no particular reason to make them click a `Go' button or press
> Enter/Return. Unless there are many thousands of messages in the folder,
> you should be able to search fast enough to filter as the user types.
> (Even if you can't, leaving non-result messages displayed for a fraction
> of a second after the user types a character doesn't matter too much.)
Agree. "Go" button removed. Search will filter as the user types.
>
>
> The usual problem with discoverability caused by the lack of a submit
> button (as found in Navigator's address bar, or in the login dialog in
> the recent GNOME usability study) does not apply here, because the
> thread pane obviously changes as soon as the user starts typing so it is
> clear what is happening.
Agree.
>
>
> | While the search is in progress, the "Go" button changes to "Stop".
>
> If that was a good idea, then the `Reload' and `Stop' buttons in
> Navigator would have been merged (or perhaps the `Go' and `Stop' buttons).
>
> The reason it isn't a good idea is twofold. Firstly it gives no
> indication, when a search hasn't started, that it can be stopped at all.
> This may make users unwilling to carry out a search in the first place,
> when they don't know if it will take seconds or hours and when there is
> no apparent way of stopping it once it has started.
>
> Secondly, it runs the very real risk of the user deciding to stop a
> search about 0.5 seconds before the search actually stops, such that
> they unwittingly start the search all over again by clicking the button
> a moment after it changes from `Stop' back to `Go'.
Agree. Remove the "Go/Stop" button completely.
>
>
> If this feature follows the character-by-character filter method I
> described above, then no `Go'/`Stop' button is needed at all. Failing
> that, however, it would be better to use the `Stop' button already on
> the Toolbar, rather than overloading the `Go' button as a second `Stop'
> button. (Shades of the `Search' vs. `Search' hilarity in Netscape builds
> of Navigator.)
>
> | The progress of the search is displayed in the status bar.
>
> Excellent! How about extending that method to showing the progress of
> sending a message in the composition window? :-)
>
> | If the
> | cursor is over the window, a busy cursor is displayed.
>
> I think `If the cursor is over the window' is supposed to read `If the
> window is focused'.
>
> | Clicking on the "Advanced..." button opens the full "Search Messages"
> | dialog.
>
> I don't think this is necessary. If a user is savvy enough to have
> turned this bar on in the first place, they'll already know the quicker
> ways of getting to the advanced search (via the menu bar, or
> Shift+Control+F).
>
> | Buttons:
> |...
> | * Clear - Only enabled once a search has completed. Used to clear the
> | search field and the search results from the Thread Pane. The Thread
> | Pane repopulates with the full contents of the folder or newsgroup
> | selected in the left Folder Pane. Note: Clicking on any folder,
> | newsgroup or account in the left Folder pane should also clear the
> | search field and the Thread Pane.
>
> If you do a character-by-character filter, instead of a momentous
> search, you don't need this button either. The user can just delete the
> text in the field in order to instantly restore the entire contents of
> the folder.
Agree. Remove "Clear" button.
>
>
> |...
> | Users are able to drag and drop results of the search to other
> | folders. Just like drag and drop in the Three Pane Mail, a Move is
> | preformed. Accelerator plus drag and drop is a copy. When drag and
> | dropping newsgroup messages, a copy is always performed.
>
> Again, if you do a character-by-character filter, instead of a search,
> there is no need to specify this behavior explicitly. The thread pane is
> still the thread pane, it is just showing some of the messages rather
> than all of them.
Agree.
>
>
> | No Results Found
> |
> | If no matching results were found, the text, "No matches found." is
> | displayed in the Thread Pane as well Status bar. The Message pane, if
> | open, is empty.
> |...
>
> What if a message is selected at the time the user does the search? The
> user might be doing a quick search to look for other messages by the
> same sender, for example. If they don't find any, it would be really
> annoying for the selected message to have disappeared from the message
> pane in the meantime.
What we were thinking was that once the user started to type in the search
field, nothing would be selected in the Thread Pane anymore.
>
>
> --
> Matthew `mpt' Thomas, Mozilla UI Design component default assignee thing
> <http://mozilla.org/>
