Hi John,
I've had a chance to play around with the new search functionality
while trying to digest the list comments. What a relief to not have
to look for the search results in a collection :o)
Apologies also for the sparse spec. I believe we were all on the same
page 6 months ago when we initially reviewed the spec, but it's been
a long time since then! In the future, we should be sure to have a
spec Re-Review when we're actually ready to embark on
implementation. :o) Meanwhile, I can certainly see how the
description of the filtering behavior is vague sp I will attempt to
clarify it below (see #7).
1) For Preview, what is likely to be a more common user action,
creating new items or searching? Our current supposition is 'Create
new items', however we are prepared to change that based on dogfood
feedback.
2) We acknowledge there will be some confusion about double meaning
of the text field. A drop-down displaying all the command options
when the user types '/' is the part of the design intended to address
this issue. Are we still planning on implementing that? We would also
like to have a tooltip on the text field that says: Type '/' to show
commands. (See http://bugzilla.osafoundation.org/show_bug.cgi?id=7425)
Assuming we are, we could be on the lookout for that from users, and
discuss other solutions after preview. One possibility is certainly
to have either Search or New item creation in a separate 'palettel'.
However, we would need to consider how our 'Command line' designs
scale with respect to point #3 below.
3) Post-preview, how do we incorporate additional commands into the
UI? e.g. Labeling items. Are there other commands that might be useful?
4) As for the sidebar, we discussed this issue on the list over the
summer and agreed that coming up with a good design to deal with an
adjustable sidebar was beyond the scope of Preview. See discussion
here: http://wiki.osafoundation.org/Journal/
WhyTheSidebarIsFixedWidthForNow
Could we adjust the length of the Collection Name instead to make
sure the (#) fits?
5) View selector in the menu. This is certainly a cheap way to add
this feature into the UI! I'm wondering if the user is going to
understand the fine distinctions between a Dashboard and a Table,
especially because there is a collection called Dashboard. Table and
Sectioned Table or Triage Table? might make more sense? However,
there's a 'Use sections' menu item in the View menu which confuses
things. Perhaps we should get rid of that if we have these View menu
options at the top.
Also, in switching from table to calendar view, I found it hard to
navigate the search results. I think to fully meet this use case of
viewing search results on the calendar we would need a split-pane
view similar to Apple iCal.
6) After playing around with it, I wonder about the value of the
Relevance column. Personally I rarely use it in Apple Mail. Does
anybody else use it in their email program? And it takes up quite a
lot of space because of the length of the column title. Jeffrey also
tried it out and felt that it wasn't quite accurate, Jeffrey?
I think it's a nice idea, but we should iterate on the design a
little bit more before putting it into the UI. For example, we should
have an 'inverted state' for when an item is selected. However,
that's just a cosmetic change. I think we need to think more about
cognitive issues. What kind of 'ranking of search results' actually
makes sense to people?
Hmm, I now seem to be unable to get the Relevance column or the
search result numbers to come up when searching: https://
bugzilla.osafoundation.org/show_bug.cgi?id=7978
I've also logged a couple of bugs:
1. Switching collections and app areas in the sidebar should filter
down the search results set. bug: https://bugzilla.osafoundation.org/
show_bug.cgi?id=7969
2. Overlays should grey out in the Calendar app when summary pane is
displaying search results: https://bugzilla.osafoundation.org/
show_bug.cgi?id=7971
3. Traceback popped up when I tried to switch the search results view
to Dashboard view: https://bugzilla.osafoundation.org/show_bug.cgi?
id=7972
7) Search workflow clarification:
1. User enters 'Find mode' in the toolbar text field either by typing
'/Find' or Cmd/Ctrl-F or whatever other mechanism we dream up.
2. User types in a search term and hits ENTER.
3. View switches to Table view and search results appear FOR THE
SELECTED COLLECTION AND APP AREA. Meanwhile, the collections in the
sidebar display the # of search results per collection.
4. The user can 'navigate around' switching collections and app areas
to 'filter' the search results in various ways.
5. User exist search mode if they a) delete the text in the toolbar
text field; OR b) click on the cancel button.
Am I missing anything? I have also updated the bug with these
details: https://bugzilla.osafoundation.org/show_bug.cgi?id=7969
Mimi
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design
