Autocomplete in event dialog - opinions wanted

[Philipp Kewisch]

Hello Community!

This discussion originates from bug https://bugzilla.mozilla.org/show_bug.cgi?id=181249
where the event dialog should get some autocomplete functions (i.e
location field)

I would be interested to know where you think autocomplete should take
its values from.
* From a certain set (possibly all) of calendars, from all location
fields.
* Only values entered into the location field in the current profile
* Somewhere else? A combo of both?

Regarding the certain set, some suggestions:
* All Calendars
* All local or cached calendars (i.e storage, or cached remote
calendars)
* A user-configurable set

Please tell us what you think!

[Pete]

Philipp Kewisch wrote:
> [...] where the event dialog should get some
> autocomplete functions [...]

The most important thing to me is that there's a way to completely
disable autocomplete in Lightning.

However, if I change my mind in the future, then:

1) Only calendars that are currently loaded in memory (regardless if
storage/local/remote and regardless if using the "experimental cache")

2) Only calendars that are enabled in their property dialogs, enabled in
the calendar list (i.e. part of the composite view), and that are not
marked as readonly.

p.s. Thanks for asking for opinions!

[Pete]

Also, when a match is found in the Title field and the user presses the
Tab key or whatever, then everything could be copied from the found
event to the fields in the dialog (location, category, calendar,
attendees, repeat, reminder, description, privacy, transparency, etc.).
This would be quite powerful and might resolve some other enhancement
requests in Bugzilla. Well, you'd probably need to change the start/end
dates.

However, you probably still want to also have autocomplete in the
Location field (that only affects the Location field).

[Simon Paquet]

Philipp Kewisch wrote on 29. Jun 2008:

> This discussion originates from bug
> https://bugzilla.mozilla.org/show_bug.cgi?id=181249
> where the event dialog should get some autocomplete functions (i.e
> location field)

> I would be interested to know where you think autocomplete should take
> its values from.
> * From a certain set (possibly all) of calendars, from all location
> fields.
> * Only values entered into the location field in the current profile
> * Somewhere else? A combo of both?

In my opinion this is a less a question of what we should do from a
feature point, but what we should do from a user experience point. And
that is where performance comes in.

If we can do option 1 with adequate performance, then this should be
the route to go. If not, we need to scale down, e.g just query the
cached copy of the current activated calendar.

Simon

--
Calendar l10n coordinator
Calendar Website Maintainer: http://www.mozilla.org/projects/calendar
Calendar developer blog: http://weblogs.mozillazine.org/calendar

[ovidiu]

For lightning, of course, some interaction with TB data would be marvelous:
-TB AB for attendees does it now, what about Location? hmm.. Should we
propose momo the other way around too? [taking locations from Lt in AB
or other db even if not associated with a contact ..]
-titles from threads titles? (hard one if no TB db already indexing that
etc) Like "bugday" or "f2f meeting" etc

Others:
-should be an option, generally
-should be an option if to take values "from all" or "only current"
calendar Or even better, a list to check .. This goes like:
*if one cal =work, one cal = home I don't need them to interact much as text
*if 1cal=work/me, 1cal work=colleagueA, 1cal work=colleagueB, 1 cal=home:
all those with work I should check to extract info from all work, home
is separated
-maybe even separating options for location and title ..

Maybe this is too much ..

Anyway, remote or local, readonly or not is not common user criteria. I
may wanna draw info from a remote readonly colleague's cal but not from
the local "home" one or a hollyday one. Let them check it, a pattern is
hard to achieve and having a rigid thing/limited options will probably
lead to switch off.

I wonder now what will be the default proposal and the way people will
be able to tell that this is an option ..Maybe placing a small button
aside the field ..

[Mike]

I would prefer a user-configurable set based on the currently active
(writable) calendar.

[Michiel van Leeuwen]

Philipp Kewisch wrote:
> Hello Community!
>
> This discussion originates from bug https://bugzilla.mozilla.org/show_bug.cgi?id=181249
> where the event dialog should get some autocomplete functions (i.e
> location field)

I would start by getting the values only from whatever was typed before.
There is a problem with subscribed calendars. If they are public (for
example a holiday calendar or the schedule of your local movie theater),
it's not very likely that you want to autocomplete based on those. But I
don't know of a good algorithm to detect those. Autocomplete based on
previously entered values does work though.

Michiel

[Simon Paquet]

Mike wrote on 30. Jun 2008:

> I would prefer a user-configurable set based on the currently active
> (writable) calendar.

I don't think that this should be user-configurable in any way. It
should
just work and not get into the way, like the autocomplete in form or
search fields in Firefox.

[Philipp Kewisch]

On Jun 30, 10:38 am, Pete <temp2...@fastmail.fm> wrote:
> Also, when a match is found in the Title field and the user presses the
> Tab key or whatever, then everything could be copied from the found
> event to the fields in the dialog

I think this is too much to do from autocompletion. This is template
management and should be done separately, i.e a templates sidebar.
This could also easily be done in an extension.

I agree that we need ways to turn this off and that it should not get
into the users way by default. If this feature is going to tear down
performance of the event dialog, then we need to radically cut down
the number of queries, or change things to only use previously entered
values.

Good tip with the disabled calendars, I almost forgot about that.

> For lightning, of course, some interaction with TB data would be marvelous:
> -TB AB for attendees does it now, what about Location? hmm.. Should we
> propose momo the other way around too? [taking locations from Lt in AB
> or other db even if not associated with a contact ..]
> -titles from threads titles? (hard one if no TB db already indexing that
> etc) Like "bugday" or "f2f meeting" etc

I think this is something to be done in a different step. Although I
generally like the integration to be able to pick the location from an
addressbook entry, we will need more advanced UI for that. Unless we
already have one, could someone file a bug on that (add keyword mail-
integration).

Philipp

[Daniel Boelzle]

Michiel van Leeuwen wrote:
> Philipp Kewisch wrote:
>> Hello Community!
>>
>> This discussion originates from bug https://bugzilla.mozilla.org/show_bug.cgi?id=181249
>> where the event dialog should get some autocomplete functions (i.e
>> location field)
>
> I would start by getting the values only from whatever was typed before.

...

+1 -- to me this sounds like what most people are used to in web forms.
Maybe it makes sense to scope those those to particular calendars, e.g.
I get my only my "private" completions when editing my private calendar.

Daniel

>
>
> Michiel
> _______________________________________________
> dev-apps-calendar mailing list
> dev-apps...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-apps-calendar