[Chandler-dev] Suggestions on Quick Item Entry in the Search bar

[Philippe Bossut]

John Anderson wrote:
> Searching and text entry are completely unrelated so using the same 
> widget doesn't seem very natural. Adding drop downs in the search box 
> which create new events instead of searching will add further 
> confusion. Without a dropdown or some other discoverable UI most users 
> will never learn about the feature.
We certainly need to add a drop down or something to guide the user but 
I don't see why that would add confusion. Such fields already have 
multiple use today. We're just extending this to the kind of action 
rather than limiting it to search.
> I think it makes more sense to add new UI for this feature. Perhaps, a 
> toggle to open and close a new text area, or maybe a floating panel 
> with some buttons (maybe with command keys) that would pre-populate 
> the field with /mail, /task, etc.
A toggle won't be more discoverable than a drop down and certainly not 
less confusing IMHO.

I can see that having 2 fields will disambiguate (less confusion) the 
text entered in one or the other field, however, it will clutter the UI 
quite a bit and hiding it by default will certainly discourage even the 
power user. Also, if we add a text field widget to create an item, we 
will have to create one for any other functionalities we'd like to 
surface with a text interface (sort for instance, or some level of Don's 
CPIA script). This will clutter the UI even more or, more likely, we'll 
simply renounce to add them (or add them as optional tools, a venue that 
MS Office took and which lead to horribly overloaded barely usable UI).

I general, I prefer to have less but more powerful widgets than a huge 
collection of widgets with limited functionalities.

I think it's better to have *one* text field in the toolbar that can be 
used in multiple ways. Think about search as the default "verb" 
(/search) in a collection of "verbs" (/event, /task, /sort, etc...) that 
we can add to this field. The icon is simply the default verb (used if 
you're not starting the string with "/"). Changing the verbs with a drop 
down will be the easy way for most users to use the field. Typing 
"/action" will be the power user way. We also won't have to add new 
widgets for every action we decide to implement in the future. Using NLP 
for parsing as suggested by Darshana will give users some level of 
"scripting" capabilities without having to learn a scripting language. 
That's a great feature.

I know it's unusual but there's nothing wrong with innovating (I hope). 
Also, it's not really that new: for instance, the address bar in your 
browser can be used to enter script (e.g. try javascript:alert("Hello")  
in your address bar, or, more useful, 
javascript:alert(navigator.userAgent) to get the user agent string of 
your browser). So, here you go, it's not even that new to use a field 
for multiple purposes.

So +1 to Darshana's suggestion

Cheers,
- Philippe