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
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "chandler-dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/chandler-dev
