Hi, please see comments in-line...
On Feb 1, 2007, at 10:54 AM, D John Anderson wrote:
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.
Okay. I think that's okay for Preview. What's important is that users
figure out how to create new items easily in that text field. Andi's
additions to make Search accessible through Cmd/Ctrl-F and the menu
should make search more discoverable as well.
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.
Well, one big difference between Chandler's pseudo CLI and real CLIs
is that we're not displaying the results of the command in the same
field as the command itself. We have the rest of the UI for that.
I'm not sure why it's okay to load multiple commands into the
palette, but it's not okay to include /Find in that list of commands.
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.
These are design issues that would need to be dealt with if we
introduced an adjustable width splitter between the sidebar and
summary pane. Could you elaborate on what in particular is confusing
for you?
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.
Yes.
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.
I will address the View selector in a separate email...
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.
Yes. I'm thinking out loud about how much we 'win' by allowing users
to switch from the search results list to a calendar view.
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.
It's not the graph, it's the word Relevance. I imagine the graph can
be shortened to whatever the width of the column, could we do Rank
instead? I can file a bug for this.
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.
Yes, I will do this post-preview :)
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?
I will address this in a separate email as well.
Thx, John
Mimi
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design
