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

[John Anderson]

If we add the ability to type commands that don't have anything to do 
with search in the search box, I think we shouldn't  call it a search 
box. It's more like a command line, so maybe a "command box". Also, 
since it's like a command line, it would be handy if there were some way 
to search for "/mail", so maybe we should invoke all the usual command 
line quoting options.

Finally, while I think this may be a good "expert:" option, I suspect 
for most users it will cause more confusion than benefit. For my 
sensibility it violates the "simple things should be simple" rule by 
overloading searching (a simple idea) with complicated idea (the command 
line).

John

Philippe Bossut wrote:
> 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