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'?
| 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.
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 ]|
+--------------------------------------------------------------------+
| 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.
| 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.
|...
| 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.)
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.
| 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'.
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.
|...
| 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.
| 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.
--
Matthew `mpt' Thomas, Mozilla UI Design component default assignee thing
<http://mozilla.org/>
