Hi:
I just checked in a first draft of search for Preview.
Unfortunately, given the schedule for Preview we don't have enough
time to completely implement the spec, nor do we have our usual
amount of time to iterate between design and implementation. So,
we're going to have to make some difficult choices for Preview.
I encourage everyone to try out search and share your feedback. Even
if we can't incorporate all the feedback for Preview, we can improve
search after Preview.
I'll start by giving you my first impression of search as a user of
Chandler.
The first time I typed something into the search field and pressed
enter, it seemed completely broken. Instead of returning my search
results it created a new item. I thought this was a bug, but later I
discovered that it was a feature. You have to type "/search" in front
of your search string. This seems to violate one of the most basic
rules of UI design: Never take a familiar widget and make it do
something unfamiliar.
By putting the quick entry functionality into the search box I think
we're making the same mistake we made with the sidebar icons: trying
to put too much UI into too few widgets. As a user, I'd prefer having
search work like search does in other applications and put the quick
entry functionality in a new widget, e.g. a floating palette that
comes up when you type somewhere besides a text box (or choose a menu
to bring it up). A palette could use the extra space to make it clear
that you type commands in the quick entry widget, it could show
command history, be resizable and not clutter the existing window,.
Other options include: putting quick entry in the status bar at the
bottom of the window, putting it where search is but making it not
look like search and putting find in a find panel.
I also think putting find functionality in a quick entry command
seems to violate another basic rule of UI design: Don't hide
important commands from your user. Nobody's going to figure out that
you need to type "/search" to do a search. Even with command type
ahead, nobody is going to discover it. As an aside, I spent over a
week trying to implement Darshana's command type ahead in the
toolbar, and got really close, but still have a difficult bug holding
it up on Mac. I'm not sure I'll succeed in finishing it for Preview.
At the very least I think we should make the Quick Entry box not look
like a search box, but I still don't know how hard that will be to do.
Other nice to have, but not currently implemented features include:
- Search results don't update as you type each character in the
QuickEntry field. You must type return to start the search
- Performance is too slow. It has a jerky feel and occasionally spins
the watch on a list of 3000 items.
- I'm using Darshana's Quick Entry code. It displays errors by adding
a ? to the text instead of displaying the error underneath the search
field. Also, when you type a search string that PyLucene interprets
as containing a syntax error you get an error dialog written for a
programmer not an end user.
Here's the main features in the spec which are still not implemented:
- I have not yet implemented the "as you start typing anywhere your
focus switches to the QuickEntry field"
- When no items are found we don't display text on the summary view
explaining that there were no items found.
- The Quick Entry field doesn't display command alternatives as you
type.
Finally I'll summarize with some more minor things I noticed after
using search for a longer time:
The spec didn't address how to sort the results. Since PyLucene
returns the results in relevance order, I tried adding a new rank
column in the search results like Apple Mail.
I kept wishing I could search for something then change the view to
see the results in Calendar view. To get an idea for how this might
work I checked in a simple proposal: replace the first 4 menu items
in the view menu (which currently do the same thing as the first 4
toolbar buttons), with 3 new commands that change the view to
Calendar, Dashboard and Table. It's also easy to add more view types
with new parcels.
After I cleared the search results I occasionally wished I could go
back to my search results. I played a few simple idea which you can
try out: when you click the delete box in the search field and there
is no search string it goes back to the search results. Another idea
I tried was allowing the results to be saved in a collection. To get
a feel for how this might work I added a save button (currently with
a place holder icon) next to the quick entry box that's only shown
when search results are displayed. Choosing it copies the search
results to a new collection in the sidebar. Instead of adding a
toolbar button, it's also easy to optionally add a menu item when
search results are available to save.
It's not unusual for the number of matches displayed in the sidebar
to get cut off because the sidebar isn't resizable. I wonder if it
might not be worth allowing the sidebar to be resizable and scaling
or tiling the mini calendar to fill the space
I have a hard to coming up with words to describe how ugly the
wxWidget's search widget looks like on windows (and I still haven't
seen it on Linux).
So give search a try. Let me know if you find any bugs, and we'll
work with Design to get the best search we can for Preview and a
clear set of tasks for after Preview.
John
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design
