[Design] Search - Separate CLI palette

[Mimi Yin]

I can certainly see a design where the search field is in the toolbar  
and then at the bottom of the UI there is a separate text-box that is  
used for creating new items, labeling items, chat and all kinds of  
commands. I could also easily imagine that users easily acclimate to  
a single widget for both search and other commands.

We still have to do a fair amount of research into the command-line- 
for-end-users idea to figure out how to optimize for common  
workflows. For example, it may be useful to introduce a notion of  
'command sequences' to help users zip through commands they often  
invoke in quick succession.

Perhaps it's really just an issue of comfort. I'm okay with what we  
have for Preview. I think it meets the Plausible Promise bar. Also,  
on the off-chance that users DO turn out to be comfortable with a  
single 'command-line' widget, it would save a lot of screen real  
estate in the UI to *not* have a dedicated search widget. I'd like to  
try this out and see how far we can push people before giving in to  
more widgets in the UI.

Mimi

On Feb 2, 2007, at 11:41 AM, D John Anderson wrote:

>>>
>>> So the issue isn't about multiple commands in the palette, it's  
>>> about not confusing the meaning of a search box by requiring that  
>>> you type "/search". I hoped to avoid this confusion by putting  
>>> quick entry in a different widget, one that worked even better  
>>> for quick entry than the search box, leaving search to be the  
>>> familiar search we all know and love.
>>
>> I think this is the crux of the confusion. Ii don't think of the  
>> field in the toolbar as a search field. I think of it as a  
>> 'command-line' text field where search is one of the command  
>> options. Is it the rounded ends that are confusing the issue? We  
>> can change it to be a square field on Mac. I don't think there's a  
>> difference really for windows and linux.
>
> I think a more precise explanation of the "crux of the confusion"  
> is that I think it's better to feature search in it's own widget,  
> in a familiar form that people already understand, and feature  
> quick entry in in a separate widget that's optimized for its features.
>
> Putting both functions in a single widget, even if it doesn't look  
> like a search widget, just doesn't seem as nice to me.
>
> John