Calendar subscriptions tree proposal
Joey Minta
calendar subscriptions in both Sunbird and Lightning, which I'd love to
get some feedback on. The proposal can be found here:
http://wiki.mozilla.org/Calendars_Tree
-Joey
Michiel van Leeuwen
My first reaction: Which problem are you trying to solve? What's wrong
with what we have now?
Second reaction: I'd rather have native checkboxes. More familiar and
thus more discoverable that you can actually click on them.
Michiel
Joey Minta
> My first reaction: Which problem are you trying to solve? What's wrong
> with what we have now?
published calendars do become more popular, then organization is going
to become important, as a flat list will be difficult to use (especially
if we can't reorder the calendars). My goal was to try to encourage
better organization of data for users that have to deal with many calendars.
> Second reaction: I'd rather have native checkboxes. More familiar and
> thus more discoverable that you can actually click on them.
lilmatt expressed the same thought. I was working off of the suggestion
made by beltzner when this question came up for Lightning originally.
https://bugzilla.mozilla.org/show_bug.cgi?id=298360#c5
-Joey
Clint Talbert
I like the tree view idea. I think it's great. I like the checkboxes
too, but it seems that it would be better if the checkbox could be
closer to the text, and not so far out to the left.
Clint
lilmatt
I don't like the in place rename, as I often find myself invoking
rename when I was simply trying to select something (at least in the
Mac Finder), but I could live with it. I'm sure some people would like
to be able to rename without popping up a dialog.
>> Second reaction: I'd rather have native checkboxes. More familiar and
>> thus more discoverable that you can actually click on them.
>
> lilmatt expressed the same thought.
After reading the bug, I looked at iCal.app because I couldn't fathom
Apple committing such a HIG faux pas. To my surprise, they did. The
check boxes are coloured.
Personally, I remain behind my original comment that native widgets are
best. I hate the non-native checkbox in the task box, and I wouldn't
like to see one here either. If we do this, please make it a non-hidden
pref, and keep it off by default.
Joey Minta
> Personally, I remain behind my original comment that native widgets are
> best. I hate the non-native checkbox in the task box, and I wouldn't
> like to see one here either. If we do this, please make it a non-hidden
> pref, and keep it off by default.
>
the behavior will be. At one point I put together several other
options, because I wasn't yet confident in the ability to use canvas
here. They're shown in
https://bugzilla.mozilla.org/attachment.cgi?id=204237 or are people
happy with the current model?
Gary van der Merwe
How would one specify which grouping a calendar is in? Through the
create/edit calendar dialogs? Would we allow drag and drop?
>Should we allow calendars to not be in a group?
Yes. And I think this should happen by default. For someone like
Grandma who has one calendar - groupings adds confusion, and she does
not need it.
This is why I asked about how the groupings are set. How do we create
an interface to set the groupings, that does not confuse someone who
does not need it?
Joey Minta
currently do. Within 'Preferences', the groupings can be
added/edited/removed. Within the Create Calendar wizard and the Edit
Calendar dialog, groupings can be assigned. Drag and Drop is also
supported.
My concern with allowing some calendars to not be in a group is that it
becomes difficult for the user to distinguish between a (empty) grouping
and a calendar in the list, since they're all just text. If, on the
other hand, all calendars simply ended up in 'My Calendars' by default,
do you really think Grandma would find it that confusing? That would
probably end up being her only group.
-Joey
Gary van der Merwe
> My concern with allowing some calendars to not be in a group is that it
> becomes difficult for the user to distinguish between a (empty) grouping
> and a calendar in the list, since they're all just text.
We could have an icon next to each item. For groups the icon could be a
folder, and for a calendar, the icon could be a square that is the
color for the calendar.
Michiel van Leeuwen
> Personally, I remain behind my original comment that native widgets are
> best. I hate the non-native checkbox in the task box, and I wouldn't
> like to see one here either. If we do this, please make it a non-hidden
> pref, and keep it off by default.
Not a pref, please. Just decide what works best, and stick with it.
Don't move that choice to the users. We should spend some time on it
once, instead of asking all our users to spend that time.
Michiel
Michiel van Leeuwen
> here. They're shown in
> https://bugzilla.mozilla.org/attachment.cgi?id=204237 or are people
> happy with the current model?
Option 1 is what is used in
http://wiki.mozilla.org/Calendar:Calendar_View, and i think that looks
pretty nice. Maybe you just need to make the colored box smaller then
what you have now in option 1. Just a bit more subtle.
Michiel
Dan Mosedale
I kind of like Option 4, because it shows more closely what the events
will actually look like in the views, including both text and background.
Dan
Dan Mosedale
I'd be interested to hear any thoughts from Rod Whiteley on this, since
he's presumably gotten a certain amount of user feedback from CalFolders.
Dan
Dan Mosedale
>
> My concern with allowing some calendars to not be in a group is that it
> becomes difficult for the user to distinguish between a (empty) grouping
> and a calendar in the list, since they're all just text.
Well, one would have a twisty in front of it and the other wouldn't, right?
> If, on the other hand, all calendars simply ended up in 'My Calendars' by default,
> do you really think Grandma would find it that confusing? That would
> probably end up being her only group.
I don't see what's confusing about that. At some level, groupings may
well just be a more advanced user thing.
Dan
Joey Minta
> Joey Minta wrote:
>>
>> My concern with allowing some calendars to not be in a group is that
>> it becomes difficult for the user to distinguish between a (empty)
>> grouping and a calendar in the list, since they're all just text.
>
> Well, one would have a twisty in front of it and the other wouldn't, right?
containers special styling though which would help to differentiate.
I'm still struggling with implemeting this in anonymous nodes, since
traditional code uses column ids.
>
>> If, on the other hand, all calendars simply ended up in 'My Calendars'
>> by default, do you really think Grandma would find it that confusing?
>> That would probably end up being her only group.
>
> I don't see what's confusing about that. At some level, groupings may
> well just be a more advanced user thing.
The way I see things, we have 3 options, in order of increasing complexity
1.) No grouping
2.) Everything grouped
3.) Some grouped, some un-grouped.
The problem is that in order to allow Grandma to jump back down to (1),
we have to have some people deal with (3). I was arguing for (2) as
sort of a middle-ground, since I don't see a great difference in
complexity between
[ cal1 ] and [- My Cals]
[ cal2 ] [ cal1 ]
[ cal2 ]
If Grandma ends up with the option on the right, I think that may be OK
to avoid (3), but I'm not entirely convinced of that, hence the 'Issue'
label in the wiki.
-Joey
Andrew N Dowden
> [ cal1 ] and [- My Cals]
> [ cal2 ] [ cal1 ]
> [ cal2 ]
>
> If Grandma ends up with the option on the right, I think that may be
> OK to avoid (3), but I'm not entirely convinced of that, hence the
> 'Issue' label in the wiki.
issue I have been working on, as a future RFE proposal.
Try the following example: (renamed hopefully generic terms)
[ -Business ]
[ projects ]
[ training ]
[ financial / filings ]
[ NZ Calendar ] // all anniversaries, events
[ NZ Holidays ] // all business-closed days
[ -US Supplier ]
[ company close-downs ]
[ US Calendar ] // all anniversaries, events
[ US Holidays ] // all business-closed days
[ -Personal ]
[ holidays / travel ]
[ Soccer Club ] // tournaments, opening day, away games, meetings
[ school ] // school term, concerts / recitals, away events
[ payments ] // mortgage, salary, tax, GST
[ NZ Holidays ]
[ NZ Calendar ]
The 2 further issues I have been considering are:
(a.) that the 'groupings' exist totally separate, and ONLY show events
from their included calendars
(b.) that 'business closed' days are shown as whole-day colour (not
just event title). This could either a special 'X-label' category, OR a
special type of calendar (within group), so that a iCal file could be
loaded to it (although iCal does not support this concept).
I have also been considering the issue of the home time-zone for
calendars (groups), so that in New Zealand, a portion of the calendar
(ie. a group) could replicate the US (as shown above).
Sorry, some of these ideas are still being developed. But you directly
hit on the one issue that they require: namely, a tree structure and
grouping.
I concur on your option 2. (everything grouped), but based on my
suggested further requirements.
--
_______________________________________________
SoftDesign Group
Dowden Software Associates
P O Box 31 132, Lower Hutt 6315, NEW ZEALAND
Christian Jansen
sorry for my late response.
I personally like the approach of having a simple (tree) list of local &
subscribed Calendars.
I'm not sure if it makes sense to have a set of groups predefined.
Just because the UI (displayed after first start) gets more cluttered
than needed. Another reason is that users might not know how to remove a
group in which they don't fit.
I strongly recommend to use native widgets for the check box. It make
life easier for users, because they don't have to relearn things the
already know.
I've also started thinking about the subscription tree. Please find my
thoughts here:
The "proposal" covers also features which are needed to publish calendars.
http://wiki.mozilla.org/Calendar:Calendar_View#Calendar_Subscription_Pane
Thanks,
Christian
Joey Minta
than that feels much too complex to manage for most people.
> The 2 further issues I have been considering are:
> (a.) that the 'groupings' exist totally separate, and ONLY show events
> from their included calendars
I think this is an unnecessary restriction on the user. Right now, an
arbitrary combination of calendars to display is possible. Enforcing
this reduces this and forces users to think too hard about which
calendar belongs in which group.
> (b.) that 'business closed' days are shown as whole-day colour (not
> just event title). This could either a special 'X-label' category, OR a
> special type of calendar (within group), so that a iCal file could be
> loaded to it (although iCal does not support this concept).
Not relevant to this discussion at this time, in my opinion.
>
> I have also been considering the issue of the home time-zone for
> calendars (groups), so that in New Zealand, a portion of the calendar
> (ie. a group) could replicate the US (as shown above).
I think the grouping here is most useful from an organizational
standpoint. I'm reluctant to start adding additional meta-data to these
groups. Timezones per-calendar have been requested, and I think keeping
that data tied to a specific calendar is best.
In general, I'd like to keep these groups more flexible than what you're
proposing.
-Joey
Dan Mosedale
> Hi Joey,
> sorry for my late response.
>
> I personally like the approach of having a simple (tree) list of local &
> subscribed Calendars.
>
> I'm not sure if it makes sense to have a set of groups predefined.
It seems to me that this decision depends in large part of the default
set of calendars that we want to ship with, as well as how easy of an
experience it is to search and find a non-trivial number of other useful
calendars in 1.0. Google Calendar, for example, has two groups by
default, but it also has a large enough embedded user base that it's
reasonably likely there will be another calendar there you want to look at.
> Just because the UI (displayed after first start) gets more cluttered
> than needed. Another reason is that users might not know how to remove a
> group in which they don't fit.
So I guess I tend to agree that we might do well to just have a list by
default, and allow people who use the calendar enough to want groups
discover that feature themselves from the pref dialog or some other way.
We could certainly revisit the decision down the road once we have a
better feel for our default calendar & search plans.
My current thinking on the default calendars is that might make sense to
want to default to "My Calendar" and a "Holiday Calendar" associated
with the locale or timezone.
> I strongly recommend to use native widgets for the check box. It make
> life easier for users, because they don't have to relearn things the
> already know.
Yeah, in the Bad Old Days before nsITheme, we got complaints about the
non-native widgets in the suite constantly.
> I've also started thinking about the subscription tree. Please find my
> thoughts here:
>
> The "proposal" covers also features which are needed to publish calendars.
>
> http://wiki.mozilla.org/Calendar:Calendar_View#Calendar_Subscription_Pane
Most of that stuff looks pretty reasonable to me. What does "Publish
Additional Subscriptions" mean, exactly? Another feature that might or
might not want to live in the subscription pane is "search" or "discover"...
Dan
Dan Mosedale
> Andrew N Dowden wrote:
>> Try the following example: (renamed hopefully generic terms)
>>
>> [ -Business ]
>> [ projects ]
>> [ training ]
>> [ financial / filings ]
>> [ NZ Calendar ] // all anniversaries, events
>> [ NZ Holidays ] // all business-closed days
>> [ -US Supplier ]
>> [ company close-downs ]
>> [ US Calendar ] // all anniversaries, events
>> [ US Holidays ] // all business-closed days
>> [ -Personal ]
>> [ holidays / travel ]
>> [ Soccer Club ] // tournaments, opening day, away games, meetings
>> [ school ] // school term, concerts / recitals, away events
>> [ payments ] // mortgage, salary, tax, GST
>> [ NZ Holidays ]
>> [ NZ Calendar ]
>>
> Note that I only intended to have 1 level of nesting. Anything more
> than that feels much too complex to manage for most people.
>
As I read it, the above proposal only includes one level of nesting. Am
I misunderstanding?
That said, I can't imagine defaulting to or encouraging more than one
level of nesting, but I don't see why it's worth going out of our way to
prevent people creating more, if they really want to do that.
Dan
Dan Mosedale
> Dan Mosedale wrote:
>> Joey Minta wrote:
>>>
>>> My concern with allowing some calendars to not be in a group is that
>>> it becomes difficult for the user to distinguish between a (empty)
>>> grouping and a calendar in the list, since they're all just text.
>>
>> Well, one would have a twisty in front of it and the other wouldn't,
>> right?
> Empty container would not have a twisty.
Why not? They often do in Thunderbird. It could even be
greyed-out/disabled.
Dan
Andrew N Dowden
> Joey Minta wrote:
>> than that feels much too complex to manage for most people.
> As I read it, the above proposal only includes one level of nesting.
> Am I misunderstanding?
each containing calendars.
My other issue, was to clarify that a group (with it various calendars
ticked or not) does 'show' visually any other calendars from other
groups (for clarity), and that is why you would have groups in the first
place.
Andrew N Dowden
> Joey Minta wrote:
>> than that feels much too complex to manage for most people.
> As I read it, the above proposal only includes one level of nesting.
> Am I misunderstanding?
each containing calendars.
My other issue, was to clarify that a group (with it various calendars
ticked or not) does NOT 'show' visually any other calendars from other
groups (for clarity), and that is why you would have groups in the first
place.
--
Michiel van Leeuwen
> If we're going to try to encourage more sharing of calendars, or if
> published calendars do become more popular, then organization is going
> to become important, as a flat list will be difficult to use (especially
> if we can't reorder the calendars). My goal was to try to encourage
> better organization of data for users that have to deal with many
> calendars.
'normal' users don't think in trees. Most users i know have problems
using directories to store their documents in: it's one long list of
documents.
So I doubt that using trees is going to solve the problem.
Michiel