-Joey
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
> 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
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
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.
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?
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
> 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.
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
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
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
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
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
>
>> 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
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
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
> 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
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
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
Why not? They often do in Thunderbird. It could even be
greyed-out/disabled.
Dan
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.
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.
--
'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