On Feb 1, 2007, at 6:50 AM, Mimi Yin wrote:
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
As I mentioned in my earlier email I spent about a week trying to
implement the drop down in the toolbar and I'm currently stuck on a
crasher bug on Macintosh. So, it's not an issue with not wanting to
implement the feature, it's simply a matter of being stuck and having
limited time. So I'm not sure if I will solve the problem for
Preview. The next step is to come up with a list features/bugs and
prioritize them for Preview.
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.
I think a quick entry palette would scale with other commands as well
as or better than a single line search box field. Most programmers
use a shell for typing commands and they benefit from additional
space over a single line text box.
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
I read the link, but didn't understand the details of the design
you're proposing. The main thing I'm confused about is this passage:
1. An alternate layout for the mini-calendar so that it doesn't float
in the middle of a sidebar that is much wider than the mini-calendar
itself.
2. A custom splitter tha won't make the divider between the sidebar
and the summary pane take up more pixels. (see Apple Mail, iTunes and
iPhoto as examples).
3. The ability to 'snap back' to the original width.
Could we adjust the length of the Collection Name instead to make
sure the (#) fits?
We could take a name like "Search Results (10)" and shorten it to
"Search R... (10)", if that's what you are suggesting.
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.
I'm happy with calling it a "Sectioned Table" or "Triage Table" and
getting rid of the Use sections menu Item. I need to double check
with Bryan Stearns to make sure that turning off sections is the same
as Table view.
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.
I don't think split panes or even new windows are too difficult to
implement, but it might have to wait until after Preview.
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?
Almost all search in the world today sorts results by relevance (e.g.
Google), so I suspect people will be familiar with the concept. Of
course that doesn't mean the relevance is very meaningful.
If we don't sort the results by PyLucene relevance, what do we sort
them by? The obvious options include one of our columns in the table
or some new column. Which would you choose?
Finally, if it just a matter of relevance taking too much space we
could easily replace the graph with a number.
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
Thanks for the bug reports
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.
This was checked in last night.
2. User types in a search term and hits ENTER.
Currently we use PyLucene search command syntax, not just a search
term. It includes a list of terms in the simple case but has a lot
more features, including boolean search, etc. You might want to
follow up with Andi on the syntax of a search command.
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
Thanks for the clarification. This was not clear from my reading of
the spec.
Finally, what did you think about letting the user save the search
results in a collection?
John
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design
