I've tried the new search (and filed a few bugs).
I agree that there is a lot of room for improvement on how to make the
search and quick entry intuitive and easily discoverable by the casual
user, but I think I can live with something close to the current
implementation for preview.
My other comment is that I didn't immediately clue into the necessity of
clicking the [X] in the search field to switch back to a normal view. I
first tried clicking on other collections and appbar view buttons and
was a little surprised and distressed when nothing seemed to happen.
Maybe we should make the search results go away when these types to
things are clicked on?
Dan
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
