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
