John,
Thanks for writing this up. I am going to download the latest build
and try it out - then I can respond to the email in more detail.
In the meantime, I just wanted to let you know that Reid just checked
in some changes to make the Quick Entry box look less like a search
box (since you mentioned this specifically) https://
bugzilla.osafoundation.org/show_bug.cgi?id=7648.
Cheers,
Sheila
On Jan 30, 2007, at 12:00 PM, D John Anderson wrote:
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
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design
