122646 - (cal-categories) Categories tracking bug (Calendar Requirements Document, section 4)

Status: VERIFIED INVALID

(Calendar :: General, defect)

Description

[Chris Charabaruk]

This is a tracking bug for Categories, section 3.0 of the Calendar Requirements 
Document.

Comment 1

[Chris Charabaruk]

Bugspam: Adding meta keyword to tracking bugs, something they should have had
from the start. :P

Comment 2

[Peter Lairo]

Could we have a link to the "Calendar Requirements Document" in each of these
META bugs for reference, please?

Comment 3

[Peter Lairo]

Attachment: Suggested UI for managing categories

Possible default categories could be:
- company
- computers
- work
- personal
- vacation
- Friend
- Doctor
- Restaurant

Icons (user selectable) for each category would be useful for visual
recognition and for use when space is limited (e.g., Calendar month view).

Comment 4

[Chris Charabaruk]

UI: Could we use an editable <menulist> like Livelizard has? Then all we need is
some way to track what categories exist, perhaps another file (since there
doesn't seem to be any way in rfc2445 to add custom properties to VCALENDAR).

Comment 5

[ajbu]

Problem with the suggested UI's is that these only allow selection of one 
category, while a Calendar event can have multiple categories. 
(Like 'personal' and 'friend').

Comment 6

[Mike Potter]

I wouldn't worry too much about multiple categories for now.
Let's get them in and then we can worry about them later.

Comment 7

[ajbu]

Attachment: Patch to add categories textbox to event-dialog

Patch to add a simple textbox input field for categories to the New Event
dialog, and hook it in. Note that current xpi binary uses gEvent.category
instead of gEvent.categories.

Comment 8

[Peter Lairo]

I cannot read your patch ('yo no programmah) so my comment may not apply:

Categories should be selectable via a dropdown list (multiple selections should
be possible). The user should not be able to enter categories by _typing_ them
in (at least it shouldn't *accept* any that are not *already* in the list). That
could lead to an unreasonably large number of categories, partially due to
miss-spelling.

Categories should be defined in a separate UI (screenshot to follow...).

Comment 9

[Peter Lairo]

oops, screenshot is already there: see "Suggested UI for managing categories"

Comment 10

[ajbu]

Attachment: Patch to add categories to eventdialog

Copied the categories field of the tododialog to the eventdialog.
Note that this patch uses the categories from the prefpanel attached to bug
156791.

Comment 11

[ajbu]

Thought, no patch available/didn't try if it works:
Categories might be added to the search to allow searching in categories:

The search in unifinder.js has:
      var FieldsToSearch = new Array( "title", "description", "location" );
      var FieldsToSearch = new Array
( "title", "description", "location", "categories" );

Comment 12

[Mike Potter]

Yes, that works.  I guess I'll add that in, there's no really good reason to
leave it out. It's an easy filter for searching based on categories.

Comment 13

[Mike Potter]

->meta

Comment 14

[gary.frederick]

reminder - the standard has multiple categories

Comment 15

[ajbu]

Note that the clients I tried, Outlook and Evolution, only use a single 
category. They 'emulate' multiple categories using a single category with 
commas, like 'part1, part2, part3'.

The difference is that this is serialized in the iCalendar as:
CATEGORIES:part\, part2\, part3
while multiple categories would end up as:
CATEGORIES:cat1,cat2,cat3

Comment 16

[Peter Lairo]

Attachment: Screenshot of how Categories Selection should work

Selecting Categories should be as easy and flexible as possible. 

- Suggest to make a dropdown list where user clicks on each category he wants 
  to select (selecting again unselects a category). The dropdown list collapses
by hitting TAB (or by clicking the down arrow).

- The selection(s) are then put (by Calendar) into a comma-separated list.

- Nifty: While the dropdownlist is visible, pressing a letter jumps to the
first Category starting with that letter (=faster navigation of Categories
list).

Comment 17

[Oliver Klee]

That screenshot looks like it is from Lotus Organizer, which uses drop-down
boxes in a non-standard way as it allows mutiple-selecting.

I propose using a listbox or a list of checkboxes (+ labels) for the category
chooser instead.

Comment 18

[Peter Lairo]

Please pardon my ignorance Oliver, but could you provide some ASCII art for
those suggestions?

BTW. "standard" or not, I think the dropdown list method is the most
space-saving and intuitive way to go.

Comment 19

[Oliver Klee]

Lotus Organizer doesn't use the standard widgets (most easy to see when looking
at the scroll bars in the calendar). So a drop-down-list with mutiple select
isn't really an option if we want to use standard XUL controls. (Correct me if
I'm wrong and XUL has a multiple-select drop-down-list.)

OK, about what is what:
* Drop-down-list (no multiple-select, implemented with a Menulist in XUL): e.g.
the Component chooser in Bugzilla
* listbox (with optional multiple-select): e.g. the cc: list in Bugzilla
* checkboxes + labels (multiple-select): e.g. Preferences->Navigator->"Select
the Buttons you want to see in the toolbar"

Comment 20

[Peter Lairo]

RE "standard" widgets: How anything is implemented must be based on these
factors, and in the _order_ given below:

1. is it ethical? (here is where Microsoft fails already)

2. Is it beneficial to the user?

3. Does it comply with standards?

So ... looking at your suggestions with these priorities in mind:

> Drop-down-list (no multiple-select, implemented with a Menulist in XUL)

No, because it *must* be possible to select _multiple_ categories.

> listbox (with optional multiple-select): e.g. the cc: list in Bugzilla

No, because to be usable, it would have to be at _least_ 5-10 lines tall, and
that would waste an enourmous amount of space.

> checkboxes + labels (multiple-select). (i.e., a checkbox for _each_ category)

No, because that would waste an unconscienable amount of space (I have 20+ Cats).

A dropdown list with multi-select takes up _only one line_ of space.
(see screenshot attachment from 2002-09-03)

Comment 21

[Oliver Klee]

With "standard widgets" I meant "widgets that come with the OS or with XUL". Any
other widgets have to be coded by hand.

Checkboxes + labels could be scrollable, thus only showing, say, 4 or 5 lines at
a time (like a scrollable drop-down list or a scrollable listbox).

I agree that a multiple-choice drop-down box is the most elegant solution. But
we just don't have that widget in XUL and thus are not able to use it within
Mozilla unless we extend XUL. Please correct me if I have missed anything.

Comment 22

[Peter Lairo]

You are correct. To get this "most elegant solution", we must "extend XUL" a bit.

Comment 23

[Brant Gurganus]

Default QA Contact for Calendar has changed.  If you wish to remain the QA
contact for this bug, feel free to change it back.

Comment 24

[Inczédy Márk]

Someone is working on this bug? If not, I created a solution for multiple
categories, witch works like the "Exception" part of the new event dialog. If
that can be a good way to resolve this, how can i submit the code? (I have no
cvs access)

Comment 25

[Mostafa Hosseini]

Attach your suggested fix as a patch to this bug.

Comment 26

[Inczédy Márk]

Attachment: Enables the selection of multiple event categories

Three files has been modified: in each the modified part is between a /* start:
IM */ and an /* end: IM */ sign. The code that was changed, follows behind,
commented with //.
I used it on windows, but becose it's only javascript, it should work on other
os's.

Comment 27

[Inczédy Márk]

Attachment: To enable multiple category support on events

The previous patch was a bad one. Sorry...

Comment 28

[Simon Paquet [:sipaq]]

Inczédy Márk, could you please attach your patch as a proper unified diff to
this bug, so that we can see which changes you made to the code. Thanks!

Comment 29

[Simon Paquet [:sipaq]]

*** Bug 259487 has been marked as a duplicate of this bug. ***

Comment 30

[Simon Paquet [:sipaq]]

We don't need this tracking bug, because the underlying requirement document is outdated and has therefore been removed.