On Jan 31, 2007, at 2:17 PM, Dan Steinicke wrote:
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.
Yes, agreed. There are still a couple of features to implement to
help users discover the commands we have available. One is to display
a drop down of command options when users type '/'. Another would be
to implement the tooltip you suggested on bug: http://
bugzilla.osafoundation.org/show_bug.cgi?id=7425
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?
Can you elaborate on what you were trying to look for? The intent
behind that design is to allow users to essentially initiate searches
from anywhere and then use the Collections in the sidebar as a way
for them to narrow down search results. Not sure if users will adapt
to this because we're all so used to first pinpointing which folder
to search in and then conducting a search. I'd like to keep this the
way it is for Preview to get feedback. I think so long as you
eventually figure out the 'x' button, you're not 'trapped' in the
search results view forever :o)
Mimi
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
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design
