Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Event/Task dialog

2 views
Skip to first unread message

Michael Büttner

unread,
Apr 26, 2006, 5:12:04 AM4/26/06
to
I would like to start a discussion about the proposal for the new event/task
dialog. Please find the appropriate wiki-pages at
http://wiki.mozilla.org/Calendar:Event_Dialog and
http://wiki.mozilla.org/Calendar:Task_Dialog. I've just uploaded some more
screenshots from the prototype implementation. I'd love to get some feedback
on this feature.

In light of the ongoing discussion about our intended target audience this
proposal hopefully helps us in finding a common sense since it's a good
example for how to offer a range of features to the user. those features are
ranging from basic stuff to more advanced features (recurrence, free/busy
handling, etc.) where someone could claim that those advanced features
distract the low-end user.

I believe that there's basically no difference between the low-end and
enterprise-user as both types of users will use the same set of features at
the end of the day. It's just a matter of how often a feature will be used
by which type of user. the gui should clearly not be cluttered by an
overwhelming set of features, but i think that the proposal of the new
dialog solves this issue by using tab pages where the different set of
features are clearly seperated from each other. if a user doesn't need e.g.
recurring events, she does not need to visit the page, but more advanced
users can easily find this feature if they need to.

mickey.


Joey Minta

unread,
Apr 26, 2006, 8:57:45 AM4/26/06
to
Michael Büttner wrote:
> I would like to start a discussion about the proposal for the new event/task
> dialog.
High Level concerns:
1.) I still feel this discussion is a bit premature. I agree with Dan's
expressed sentiment that coming to more concrete conclusions about our
overall target will help to frame this discussion in a better way. In
particular, the current dialog is 'light', the new dialog is 'heavy'.
If we are targeting end-users as our primary focus, then a 'heavy'
dialog is the wrong approach.

2.) Incremental changes. It's unclear to me the motivation behind some
of these changes. When you have a total-rewrite, the sheer number of
changes renders discussion difficult. If we could break this up into a
discussion on attendees, then a discussion on recurrence, etc, I feel
like everyone would benefit more.

Such a discussion would be possible if we were to take the current
dialog as a starting point. Why not add the attendees tab here as a
window reached from 'Edit Attendees', which already exists? Why not add
the preview-pane to the current recurrence dialog? Those seem to me to
be the two most substantive changes, and it seems to me that focused
discussion on each would be beneficial. More generally, what objections
do you have to the current dialog, other than that it doesn't have those
2 features (and timezones)?

I'll be posting a additional responses dealing with lower level
concerns, in an effort to keep the thread semi-sane. This goes back to
point (2) though, smaller, focused discussions would be better.

-Joey

Michael Büttner

unread,
Apr 26, 2006, 10:25:03 AM4/26/06
to
Joey Minta wrote:
> 1.) I still feel this discussion is a bit premature. I agree with Dan's
> expressed sentiment that coming to more concrete conclusions about our
> overall target will help to frame this discussion in a better way.

I don't think this discussion is premature since it could fit well into
what Stephan already suggested in the "imaginary users"-thread. We
should pick a requirement, propose an implementation and see if it
conflicts with the target groups. I fully support the suggestion to
stick to corporate users and end users as our target audience.

One day we'll agree on a set of user groups which we identify as our
target audience. I can't see a reason why we shouldn't use the dialog
proposal as an example to verify the list of features against what we
have identified? Even if we add more groups to our target audience, the
both extremes will still be corporate users and end users, no matter
which other groups we may add.

> In particular, the current dialog is 'light', the new dialog is 'heavy'. If
> we are targeting end-users as our primary focus, then a 'heavy' dialog
> is the wrong approach.

I can't resist the impression that the predominant opinion is that
everything a corporate user could find useful is generally heavyweight
and too complicated for the end user. maybe I'm missing something
obvious but the set of features we'll most likely offer in the dialog
will be used by all users, the more advanced features will just be used
less often. the trick is of course to make the most used features more
prominent than the more advanced ones. even if we agree that we'll focus
on end users primarily (which hopefully will never happen) the proposed
dialog is still a perfectly valid solution since it presents all
features in a tidy way, sorted from basic functionality towards more
advances features.

> 2.) Incremental changes. It's unclear to me the motivation behind some
> of these changes. When you have a total-rewrite, the sheer number of
> changes renders discussion difficult. If we could break this up into a
> discussion on attendees, then a discussion on recurrence, etc, I feel
> like everyone would benefit more.

I never had in mind to contribute one large patch with everything in it.
As soon as we agree on which features we would like to be added and
how the dialog should look like I planned to file several bugs
addressing the different areas with several smaller patches. I thought a
reasonable way could be something like this:

1) add tabs to the existing dialog
2) move existing recurrence dialog to appropriate pane
3) change controls on the main page (add,remove,reorder)
4) add the attendee-free/buys pane
5) add the timezone-pane
6) add toolbar and menues to the dialog
7) make the dialog modeless
8) add caching to speed the dialog up

> Such a discussion would be possible if we were to take the current
> dialog as a starting point. Why not add the attendees tab here as a
> window reached from 'Edit Attendees', which already exists? Why not add
> the preview-pane to the current recurrence dialog?

As stated above I agree that incremental changes are generally a good
thing. Maybe I'm wrong but I would like to drive those changes towards
the final solution we all agree on. First introducing more
dialog-windows as an interim solution just to remove them later and
integrate them into tabs doesn't seem reasonable since it wastes
precious time. I can't see a benefit of such an approach. Of course if
we all disagree on using tabs in the first place we need to find some
other solution.

> More generally, what objections do you have to the current dialog,
> other than that it doesn't have those 2 features (and timezones)?

There are several reason. Opening a new dialog for recurrences does not
look very nice at all. And both dialogs being modal forces the user into
some sort artificial sequential process which is generally bad design.
But placing the recurrence stuff into the 'more' section is not an
option since it would take far too much space, which obviously was the
motivation to put them into a separate dialog in the first place. The
attendee stuff has the same problem. If we add the free/busy feature we
need more space. So everything naturally leads to placing the different
sections on different tabs. I truly believe that if we simply add the
new features without reordering the dialog the user interface will look
cluttered, which i thought is what we would like to avoid at all costs.

mickey.

Joey Minta

unread,
Apr 26, 2006, 10:44:36 AM4/26/06
to
Michael Büttner wrote:
> I would like to start a discussion about the proposal for the new event/task
> dialog. Please find the appropriate wiki-pages at
> http://wiki.mozilla.org/Calendar:Event_Dialog
Some more specific comments to the event dialog follow:

-Several features of the current dialog seem to have been lost [1].
Most notably:
-Categories
-Status
-Priority
-Privacy

-What does the URL button do? My only guess is that it will open the
event's url in a browser. However, I think my confusion stems somewhat
from the fact that it has now lost its association with the url. I bet
if you did some eye-movement studies you'd see the user's eyes jumping
back and forth between the URL field and the button as they go to click
it. That distance (much larger in the proposal than in the current
design) should be reduced by moving the button back by the URL in my
opinion.

-Top to bottom: My impression of a user working with a dialog is that
pretty much everything (reading/grokking/filling out) happens from
top-to-bottom. This leads to 2 points:
-The removal of the OK/Cancel buttons from the bottom are
problematic.
A user's focus needs to return back to the top to complete the
action. Also, the lack of an explicit 'Cancel' function could be
problematic for users wanting to cancel edits. (In general, I oppose
the toolbar altogether.)
-Moving the 'Calendar' option above the time seems counter-intuitive.
In my mind, there are 3 important questions about an event: What?
When? Where? Thus, the current dialog places the answers to those
3 questions as the first 3 elements in the dialog. The proposal does
not.

==Attendees==
-The 'Out of Office' option: I have a couple of problems with this
introduction.
-This is an explicit affront to end-users. If we want to encourage
sharing, etc, we shouldn't have a main category like this that is
completely useless to them.
-RFC2445 only specifies "FREE", "BUSY", "BUSY-UNAVAILABLE", and
"BUSY-TENTATIVE" as standard options and I'm concerned about
interoperability if we start defining X-names here. Does 'Out of
Office correspond directly to one of these?
-It's unclear to me how one would specify Out-of-office periods
without additional UI.
-My instinct is that someone scheduling a meeting only cares about
'Can you make it?' not 'Can you make it and if not, why not?' If
this is true, the additional key is not necessary.
-The screenshot only shows 1 attendee. I think a screenshot with 10-12
attendees will again show how complex (read 'confusing') this dialog is.
Accordingly, I'd like to again argue for the premise that the Week
View (or Day View, as necessary) is actually the ideal scheduling
component. This is how Zimbra operates and it has a few advantages:
-Notice that this dialog is just a condensed day-view.
-The Day/Week-view is larger, allowing for more information to be
presented in a less-cluttered way.
-Checking/Unchecking a calendar (with a particular attendee's
freebusy) is an action the user is already familiar with. It's
also analogous to adding attendees to the event. Why provide a 2nd
method of having to add/subtract this data in a view?

-Why is 'Contacts' a top-level button, when it only seems to apply to
the Attendees tab?

-How does the end-user do basic attendees?

==Recurrence==
-How do I make exceptions? Please don't say this is buried in the
minimonths. The minimonths work fine as a preview mechanism, but have
very little affordance for modifying data. I think most users would be
lost trying to find this functionality.

==Timezones==
-The timezone information should be more closely linked to the times.
It should be possible to specify different timezones for start/end.[2]

-Joey

-----
Footnotes:
[1] This concern was previously expressed in
https://bugzilla.mozilla.org/show_bug.cgi?id=324657#c12
[2] See http://wiki.mozilla.org/Calendar_Talk:Event_Dialog for a
counter-proposal for the timezone tab. It also addresses the issue
about separate TZs for start/end. This concern was previously expressed
in https://bugzilla.mozilla.org/show_bug.cgi?id=324657#c5

Matthias Schäfer

unread,
Apr 26, 2006, 10:54:44 AM4/26/06
to dev-apps...@lists.mozilla.org
Hi all!

Michael Büttner schrieb:


> I would like to start a discussion about the proposal for the new
event/task dialog. Please find the appropriate wiki-pages at
http://wiki.mozilla.org/Calendar:Event_Dialog and
http://wiki.mozilla.org/Calendar:Task_Dialog. I've just uploaded some
more screenshots from the prototype implementation. I'd love to get some
feedback on this feature.

I miss a listbox (or similar thing) to choose the calendar in which the
event/task appears directly on the Event tab. I think this is an
essential feature for every user with more than one calendar.
Perhaps this field can be so intelligent that it hides itself if there
is only one calendar available.

> In light of the ongoing discussion about our intended target audience
this proposal hopefully helps us in finding a common sense since it's a
good example for how to offer a range of features to the user. those
features are ranging from basic stuff to more advanced features
(recurrence, free/busy handling, etc.) where someone could claim that
those advanced features distract the low-end user.
>
> I believe that there's basically no difference between the low-end
and enterprise-user as both types of users will use the same set of
features at the end of the day. It's just a matter of how often a
feature will be used by which type of user. the gui should clearly not
be cluttered by an overwhelming set of features, but i think that the
proposal of the new dialog solves this issue by using tab pages where
the different set of features are clearly seperated from each other. if
a user doesn't need e.g. recurring events, she does not need to visit
the page, but more advanced users can easily find this feature if they
need to.

Perhaps you can handle this by just hiding away confusing tabs.
For more thoughts about that see:
http://groups.google.com/group/mozilla.dev.apps.calendar/browse_frm/thread/93ce281871d186cb/663a9f51bf409ac7?lnk=raot#663a9f51bf409ac7

best regards

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

Joey Minta

unread,
Apr 26, 2006, 10:57:33 AM4/26/06
to
Michael Büttner wrote:
> Joey Minta wrote:
>> 1.) I still feel this discussion is a bit premature. I agree with
>> Dan's expressed sentiment that coming to more concrete conclusions
>> about our overall target will help to frame this discussion in a
>> better way.
>
> I don't think this discussion is premature since it could fit well into
> what Stephan already suggested in the "imaginary users"-thread. We
> should pick a requirement, propose an implementation and see if it
> conflicts with the target groups. I fully support the suggestion to
> stick to corporate users and end users as our target audience.
This feels like putting the cart before the horse. Just because a
feature "doesn't conflict" doesn't mean it should be implemented. Nor
does it give an answer to how it should be implemented. Without a
high-level picture of where we're going, we could easily end up with a
very fragmented implementation, instead of a seemless program that helps
users X, Y, and Z accomplish tasks A, B, and C.

>
>> In particular, the current dialog is 'light', the new dialog is
>> 'heavy'. If we are targeting end-users as our primary focus, then a
>> 'heavy' dialog is the wrong approach.
>
> I can't resist the impression that the predominant opinion is that
> everything a corporate user could find useful is generally heavyweight
> and too complicated for the end user.
It's not that the feature is too complicated, it's that the feature is
superfluous to the tasks they want to accomplish. Thus, including it
harms their experience.

> maybe I'm missing something
> obvious but the set of features we'll most likely offer in the dialog
> will be used by all users, the more advanced features will just be used
> less often. the trick is of course to make the most used features more
> prominent than the more advanced ones.

The Firefox model shows the important of simply *not providing* the
features that people don't use very often. Things like "Mouse Gestures"
are things that power users often use and would be used less often
(maybe one gesture) for 'regular users'. Thus, the feature was not
included in the standard Firefox package. One of the most insightful
quotes I think I heard during last week's meeting was the philosophy
that helped make Firefox successful "Just be you can, doesn't mean you
should."

> even if we agree that we'll focus
> on end users primarily (which hopefully will never happen) the proposed
> dialog is still a perfectly valid solution since it presents all
> features in a tidy way, sorted from basic functionality towards more
> advances features.

I disagree with 'tidy' as being the goal. Being 'correct' or 'best'
would be terms I'd rather hear.

>
>> 2.) Incremental changes. It's unclear to me the motivation behind
>> some of these changes. When you have a total-rewrite, the sheer
>> number of changes renders discussion difficult. If we could break
>> this up into a discussion on attendees, then a discussion on
>> recurrence, etc, I feel like everyone would benefit more.
>
> I never had in mind to contribute one large patch with everything in it.

I was not referring to patches, but rather to discussion. The 'Event
Dialog' isn't a feature. Attendees is a feature, and I'd rather have a
discussion just on them. Then another discussion on Recurrence, etc.

>> More generally, what objections do you have to the current dialog,
>> other than that it doesn't have those 2 features (and timezones)?
>
> There are several reason. Opening a new dialog for recurrences does not
> look very nice at all.

Really? I never had the impression that merely opening a window was ugly.

> And both dialogs being modal forces the user into
> some sort artificial sequential process which is generally bad design.

I have no problem with removing the modality issue.

> But placing the recurrence stuff into the 'more' section is not an
> option since it would take far too much space, which obviously was the
> motivation to put them into a separate dialog in the first place.

That doesn't seem like the only available solution.

The
> attendee stuff has the same problem. If we add the free/busy feature we
> need more space. So everything naturally leads to placing the different
> sections on different tabs. I truly believe that if we simply add the
> new features without reordering the dialog the user interface will look
> cluttered, which i thought is what we would like to avoid at all costs.

If we keep the multiple windows model, the UI in the main window
wouldn't change at all (or barely) so I don't see why clutter would be a
danger. I don't think the 'modal' issue should be an objection, since
that can be fixed fairly easily. Therefore, I'd like to hear more about
why opening a new window is 'ugly'.

-Joey

Dan Mosedale

unread,
Apr 26, 2006, 8:26:18 PM4/26/06
to
Joey Minta wrote:
> This feels like putting the cart before the horse. Just because a
> feature "doesn't conflict" doesn't mean it should be implemented. Nor
> does it give an answer to how it should be implemented. Without a
> high-level picture of where we're going, we could easily end up with a
> very fragmented implementation, instead of a seemless program that helps
> users X, Y, and Z accomplish tasks A, B, and C.

The old suite was indeed a rather fragmented pile-o-features, and this
is generally believed around these parts to be one of the reasons that
Firefox and Thunderbird succeeded where the suite did not.

> Michael Büttner wrote:
>> I can't resist the impression that the predominant opinion is that
>> everything a corporate user could find useful is generally heavyweight
>> and too complicated for the end user.
> It's not that the feature is too complicated, it's that the feature is
> superfluous to the tasks they want to accomplish. Thus, including it
> harms their experience.

Adding features without increasing UI complexity is hard. Every feature
we add makes it more of a challenge to design UI that is actually usable
and liked by the majority of users. What often seems to happen is that
at some point, UI becomes complex enough that it has something to
irritate every user. So if we figure out which tasks are likely to be
the most used by the largest number of our users and design for those to
be the easiest (and most prominent in the UI), we win. Pushing off some
features into extensions is another way that we've seen this sort of
complexity dealt with, but you need to have some idea of who your users
are in order to do that.

>> even if we agree that we'll focus on end users primarily (which
>> hopefully will never happen) the proposed dialog is still a perfectly
>> valid solution since it presents all features in a tidy way, sorted
>> from basic functionality towards more advances features.
> I disagree with 'tidy' as being the goal. Being 'correct' or 'best'
> would be terms I'd rather hear.

I don't know how one would define 'correct' or 'best' in way that's
specific enough to be meaningful. I'd suggest, instead, that being
'easy to use' is one of the most important goals for any end-user
exposed feature. 'learnable' and 'discoverable' might fit in here
somewhere as well. I can imagine other goals for the core app which are
also interesting but significantly less important including 'efficient
work flow', and 'powerful', in large part because these things can be
done if necessary, but simplicity cannot.

>>> 2.) Incremental changes. It's unclear to me the motivation behind
>>> some of these changes. When you have a total-rewrite, the sheer
>>> number of changes renders discussion difficult. If we could break
>>> this up into a discussion on attendees, then a discussion on
>>> recurrence, etc, I feel like everyone would benefit more.
>>
>> I never had in mind to contribute one large patch with everything in it.
> I was not referring to patches, but rather to discussion. The 'Event
> Dialog' isn't a feature. Attendees is a feature, and I'd rather have a
> discussion just on them. Then another discussion on Recurrence, etc.

I agree that the 'Event Dialog' is indeed just one possible mechanism
for many of the features being proposed in this redesign, and not a
feature in and of itself. Framing (and prioritizing) our discussions in
terms of the tasks our users are trying to accomplish strikes me as more
likely to produce a usable app. Whether this actually means splitting
all these discussions apart into separate mini-discussions, I'm not
sure. It would be interesting to hear more opinions on this from folks
who have more UI design experience than I.

Dan

Dan Mosedale

unread,
Apr 26, 2006, 10:08:07 PM4/26/06
to
Dan Mosedale wrote:
>>> even if we agree that we'll focus on end users primarily (which
>>> hopefully will never happen) the proposed dialog is still a perfectly
>>> valid solution since it presents all features in a tidy way, sorted
>>> from basic functionality towards more advances features.
>> I disagree with 'tidy' as being the goal. Being 'correct' or 'best'
>> would be terms I'd rather hear.
>
> I don't know how one would define 'correct' or 'best' in way that's
> specific enough to be meaningful. I'd suggest, instead, that being
> 'easy to use' is one of the most important goals for any end-user
> exposed feature. 'learnable' and 'discoverable' might fit in here
> somewhere as well. I can imagine other goals for the core app which are
> also interesting but significantly less important including 'efficient
> work flow', and 'powerful', in large part because these things can be
> done if necessary, but simplicity cannot.

"done in extensions if necessary" is what I meant there.

Dan

FrankL

unread,
Apr 27, 2006, 4:55:59 AM4/27/06
to
>Joey Minta wrote:

[...]

> -Why is 'Contacts' a top-level button, when it only seems to apply to
> the Attendees tab?

The 'Contacts' button behaves the same like in Thunderbird's mail
composing window. An updated mock-up showing this behavior is in progress.

[...]

Christian Jansen

unread,
Apr 27, 2006, 10:02:34 AM4/27/06
to
From a user experience point of view I agree to the fact that features
which aren't used by most users shouldn't clutter the interface all the
time. This interrupts especially the workflow of the standard user (I
don't like the term End-Users not, because all users using a product are
End-users (even administrators ;-)).

How ever we can't solve here the problem which complex level is except
able for an specific target group and which is not. To get an answer on
that we need to gather real user feedback. Based on that we can decide
what's too complex or what is not.

Regarding the issue how to setup up an event and how complex this dialog
needs or can be I suggest a three step solution.

1. Users can edit the Event title directly main calendar view. This is
very fast, needs one click and (I assume) works for all type of users
and is more than enough in many cases.

2. A single click or a double click (this should be decided based on
feedback) on an event in the calendar view should open a bubble shaped
dialog allowing users to define/modify a set of items which are less
important than Title. But more important than the enterprise features.

3. From the bubble shaped dialog users should have access to the fully
loaded Events dialog. For example by clicking on a Attendee button.

If this is something what others support I can provide rough mock-up
visualizing that more in detail.

Any thoughts?

- Christian


Dan Mosedale schrieb:

Michael Büttner

unread,
Apr 27, 2006, 10:42:01 AM4/27/06
to
Joey Minta wrote:
> -The removal of the OK/Cancel buttons from the bottom are problematic.
> A user's focus needs to return back to the top to complete the
> action. Also, the lack of an explicit 'Cancel' function could be
> problematic for users wanting to cancel edits. (In general, I oppose
> the toolbar altogether.)
The initial idea was to make the dialog look much the same as the mail
compose window since this would be a good idea in terms of a consistent
dialog design. but since there's not a large number of prominent
commands which can justifiable be put into a toolbar i would agree with
your suggestion here. but i would like to here christian's opinion on this.

> -The 'Out of Office' option: I have a couple of problems with this
> introduction.
> -This is an explicit affront to end-users. If we want to encourage
> sharing, etc, we shouldn't have a main category like this that is
> completely useless to them.
> -RFC2445 only specifies "FREE", "BUSY", "BUSY-UNAVAILABLE", and
> "BUSY-TENTATIVE" as standard options and I'm concerned about
> interoperability if we start defining X-names here. Does 'Out of
> Office correspond directly to one of these?
> -It's unclear to me how one would specify Out-of-office periods
> without additional UI.

I have no problem with just specifying what RFC2445 allows, furthermore
it's a flaw of the posted screenshot since the implementation only
features free/busy anyway.

> -The screenshot only shows 1 attendee. I think a screenshot with 10-12
> attendees will again show how complex (read 'confusing') this dialog is.

I disagree with that, I find the attendee control to be clear and
concise. Furthermore this is a subjective opinion and i would like to
hear other opinions as well.

> Accordingly, I'd like to again argue for the premise that the Week View
> (or Day View, as necessary) is actually the ideal scheduling component.
> This is how Zimbra operates and it has a few advantages:
> -Notice that this dialog is just a condensed day-view.
> -The Day/Week-view is larger, allowing for more information to be
> presented in a less-cluttered way.
> -Checking/Unchecking a calendar (with a particular attendee's
> freebusy) is an action the user is already familiar with. It's
> also analogous to adding attendees to the event. Why provide a 2nd
> method of having to add/subtract this data in a view?

If I understood this right you're suggesting to schedule an event
directly from the week-view (probably using drag'n'drop) where all
people get invited based on which calendars you're currently viewing? Is
that right? I already thought that this would be a nice idea but is just
another option in order to accomplish the task of inviting people. Even
if we decide to implement such an option there are other reasons to
stick to the proposed free/busy control. 1) a user would like to invite
more than a couple of people, in that case the free/busy control is more
concise 2) while scheduling an event one is just interested in whether
the attendees are available or not, i don't need to see all details of
their meetings/events.

> -Why is 'Contacts' a top-level button, when it only seems to apply to
> the Attendees tab?

see above, maybe the toolbar is not such a good idea at all.

> -How does the end-user do basic attendees?

end-users just use the attendee-page as corporate users would do, where
should be the difference?

> ==Recurrence==
> -How do I make exceptions? Please don't say this is buried in the
> minimonths. The minimonths work fine as a preview mechanism, but have
> very little affordance for modifying data. I think most users would be
> lost trying to find this functionality.

I thought that exceptions add too much complexity to the dialog and are
not of much use anyway. Users create exceptions by changing events, why
would anyone need to 'make' exceptions? they're created as needed,
nobody would ever care whether an event is an exception from the rule or
not. Furthermore nobody will ever know in advance of time which
occurrences will happen as an exception to the regular event. In other
words, exceptions will always be created after the event already has
been scheduled.

mickey.

FrankL

unread,
Apr 27, 2006, 10:52:56 AM4/27/06
to
Joey Minta wrote:
> Michael Büttner wrote:
>> Joey Minta wrote:
>>> 1.) I still feel this discussion is a bit premature. I agree with
>>> Dan's expressed sentiment that coming to more concrete conclusions
>>> about our overall target will help to frame this discussion in a
>>> better way.
>>
>> I don't think this discussion is premature since it could fit well
>> into what Stephan already suggested in the "imaginary users"-thread.
>> We should pick a requirement, propose an implementation and see if it
>> conflicts with the target groups. I fully support the suggestion to
>> stick to corporate users and end users as our target audience.
> This feels like putting the cart before the horse. Just because a
> feature "doesn't conflict" doesn't mean it should be implemented. Nor
> does it give an answer to how it should be implemented. Without a
> high-level picture of where we're going, we could easily end up with a
> very fragmented implementation, instead of a seemless program that helps
> users X, Y, and Z accomplish tasks A, B, and C.

I think it is impossible to write one software that fits best for all
types of users and all the different (A, B, C, ...) tasks they have to
accomplish. This is not only true for software, think about cars.

>>> In particular, the current dialog is 'light', the new dialog is
>>> 'heavy'. If we are targeting end-users as our primary focus, then a
>>> 'heavy' dialog is the wrong approach.

The user must not use the dialog to create a new event. Just a click
into the calendar view allows the user to create a new event just by
click & drag and/or typing a title without leaving the calendar view.

Furthermore we thought about something like a bubble appearing when
clicking on an existing event. Then just the basic settings could be
shown to the user. A link inside the bubble guides the user to the full
blown dialog and a check box could be set to always open up the full
dialog instead of opening the bubble first.

>>
>> I can't resist the impression that the predominant opinion is that
>> everything a corporate user could find useful is generally heavyweight
>> and too complicated for the end user.
> It's not that the feature is too complicated, it's that the feature is
> superfluous to the tasks they want to accomplish. Thus, including it
> harms their experience.
>
>> maybe I'm missing something obvious but the set of features we'll most
>> likely offer in the dialog will be used by all users, the more
>> advanced features will just be used less often. the trick is of course
>> to make the most used features more prominent than the more advanced
>> ones.
> The Firefox model shows the important of simply *not providing* the
> features that people don't use very often. Things like "Mouse Gestures"
> are things that power users often use and would be used less often
> (maybe one gesture) for 'regular users'. Thus, the feature was not
> included in the standard Firefox package. One of the most insightful
> quotes I think I heard during last week's meeting was the philosophy
> that helped make Firefox successful "Just be you can, doesn't mean you
> should."

If you dig a bit deeper in FireFox or Thunderbird the complexity gets
very high. Think about configuring an e-mail account. There are tons of
options (necessary for enterprise users etc.) available. The normal
user is guided by a wizard when creating an account to hide this
complexity. That is the same what can be ensured by something like the
bubble I have proposed above.

>> even if we agree that we'll focus on end users primarily (which
>> hopefully will never happen) the proposed dialog is still a perfectly
>> valid solution since it presents all features in a tidy way, sorted
>> from basic functionality towards more advances features.
> I disagree with 'tidy' as being the goal. Being 'correct' or 'best'
> would be terms I'd rather hear.
>
>>
>>> 2.) Incremental changes. It's unclear to me the motivation behind
>>> some of these changes. When you have a total-rewrite, the sheer
>>> number of changes renders discussion difficult. If we could break
>>> this up into a discussion on attendees, then a discussion on
>>> recurrence, etc, I feel like everyone would benefit more.
>>
>> I never had in mind to contribute one large patch with everything in it.
> I was not referring to patches, but rather to discussion. The 'Event
> Dialog' isn't a feature. Attendees is a feature, and I'd rather have a
> discussion just on them. Then another discussion on Recurrence, etc.

If you just talk about a single features, your will not get the whole
picture. This often results in inconsistent implementations inside the
product.

Best regards,

Frank

Christian Jansen

unread,
Apr 27, 2006, 11:15:31 AM4/27/06
to
If the goal of Lightning is to be a well integrated Calendaring tool
than we shouldn't force the user to learn different interaction models
just because she is in a different part of the application. For the user
is Thunderbird + Lightning one app.

It seams that the concept of composing and sending an e-mails in
Thunderbird has been well accepted and got understood even with no
OK/Cancel button.

- Christian


Michael Büttner schrieb:

Joey Minta

unread,
Apr 27, 2006, 11:40:12 AM4/27/06
to
Christian Jansen wrote:
> 2. A single click or a double click (this should be decided based on
> feedback) on an event in the calendar view should open a bubble shaped
> dialog allowing users to define/modify a set of items which are less
> important than Title. But more important than the enterprise features.
I'm curious to learn more about this. Google calendar does something
similar. My first instinct was that the 'Less' view of the current
dialog seems very much like this proposed bubble. Secondly, 'bubbles'
are more commonly associated with AJAX apps, and aren't standard
interface in Mozilla apps. Would this perhaps be better as a standard
dialog? Third, very careful planning would need to go into which
options to expose here. Too few and the bubble becomes useless. Notice
however that we can already edit title and times from the view and there
is an open bug on Location/Description too.

>
> 3. From the bubble shaped dialog users should have access to the fully
> loaded Events dialog. For example by clicking on a Attendee button.

Doesn't this imply that Attendees should be its own window as I argued
for previously? Then the user who doesn't want attendees can just
ignore the single button, which might be a reasonable compromise.

-Joey

Joey Minta

unread,
Apr 27, 2006, 11:47:33 AM4/27/06
to
I don't understand these arguments. It seems in one case we have a list
of calendars (John's Freebusy, Fred's Freebusy...) that get
cheched/unchecked. These display freebusy data in the day/week view.
In the event dialog, we have contacts that get added/removed that
display freebusy data in a smaller (horizontal) day-view. How is the
workflow different for 'more than a couple of people'? and The only
'details' of the schedule that you're seeing is the titles. Simply
looking at the geometry gives you the availability.

>
>> -How does the end-user do basic attendees?
> end-users just use the attendee-page as corporate users would do, where
> should be the difference?

Well, I thought we were previously including this in 'complex'. I've
posted elsewhere about the advantages we might gain in the end-user
market by making the bar for inviting attendees as low as possible.

>
>> ==Recurrence==
>> -How do I make exceptions? Please don't say this is buried in the
>> minimonths. The minimonths work fine as a preview mechanism, but have
>> very little affordance for modifying data. I think most users would
>> be lost trying to find this functionality.
> I thought that exceptions add too much complexity to the dialog and are
> not of much use anyway. Users create exceptions by changing events, why
> would anyone need to 'make' exceptions? they're created as needed,
> nobody would ever care whether an event is an exception from the rule or
> not. Furthermore nobody will ever know in advance of time which
> occurrences will happen as an exception to the regular event.

Not true. I do this quite a bit with my schedule, due to vacations that
I know ahead of time. It doesn't seem strange at all to me to know
exceptions in advance.

-Joey

Michiel van Leeuwen

unread,
Apr 27, 2006, 4:07:27 PM4/27/06
to
Joey Minta wrote:
> -The screenshot only shows 1 attendee. I think a screenshot with 10-12
> attendees will again show how complex (read 'confusing') this dialog is.
> Accordingly, I'd like to again argue for the premise that the Week View
> (or Day View, as necessary) is actually the ideal scheduling component.

I disagree. Imagine planning a meeting for 10 people. You open the week
view with 10 somewhat busy calendars on it. There are a lot of
'conflicting' events (events at the same time). The boxes will get very
small, and it becomes hard to find a spot wich is blank over the whole
width of a day.

Michiel

Michael Büttner

unread,
Apr 28, 2006, 3:24:10 AM4/28/06
to
Joey Minta wrote:
> I don't understand these arguments. It seems in one case we have a list
> of calendars (John's Freebusy, Fred's Freebusy...) that get
> cheched/unchecked. These display freebusy data in the day/week view. In
> the event dialog, we have contacts that get added/removed that display
> freebusy data in a smaller (horizontal) day-view. How is the workflow
> different for 'more than a couple of people'? and The only 'details' of
> the schedule that you're seeing is the titles. Simply looking at the
> geometry gives you the availability.
see mvl's posting, he explained it much better than i did. the boxes
that will be displayed in the viwes will get very small if you're
inviting a couple of people with decently filled calendars. generally
the proposed free/busy control doesn't have this problem.

> Well, I thought we were previously including this in 'complex'. I've
> posted elsewhere about the advantages we might gain in the end-user
> market by making the bar for inviting attendees as low as possible.

I disagree with the argument that the proposed free/busy control being
'complex'. I can't resist the impression that you argue against it
because of your subjective opinion of it being too complicated. I think
we really should come to a conclusion to avoid endless discussion with
just using personal preferences as arguments. the alternative you
mentioned (display free/busy in the main views) is not really an option
since it simply doesn't scale. It's something that may work well for the
end-user but it clearly doesn't work for the corporate user. We could
adopt both options but you should not deny the proposed solution because
you just don't like it. Again I would love to hear other opinions as
well, as it might pave the way to a conclusion.

> Not true. I do this quite a bit with my schedule, due to vacations that
> I know ahead of time. It doesn't seem strange at all to me to know
> exceptions in advance.

Of course this is a valid scenario, you want to exclude your vacations.
But the functionality of adding those exceptions adds complexity to the
dialog, which is not needed. Adding those vacation dates by entering the
specific dates is way too abstract for the average user. You could
easily display your vacation in the views (subscribe to a vacation
calendar, enter the events on your own, etc.), and then delete the
conflicting events directly from the view and create those exceptions in
a clean and intuitive manner.

I would like to hear other opinions as well as I feel that we're
approaching the final solution from totally contrary point of views here.

mickey.

Christian Jansen

unread,
Apr 28, 2006, 3:34:13 AM4/28/06
to
Joey Minta schrieb:

> Christian Jansen wrote:
>> 2. A single click or a double click (this should be decided based on
>> feedback) on an event in the calendar view should open a bubble shaped
>> dialog allowing users to define/modify a set of items which are less
>> important than Title. But more important than the enterprise features.
> I'm curious to learn more about this. Google calendar does something
> similar. My first instinct was that the 'Less' view of the current
> dialog seems very much like this proposed bubble. Secondly, 'bubbles'
> are more commonly associated with AJAX apps, and aren't standard
> interface in Mozilla apps. Would this perhaps be better as a standard
> dialog? Third, very careful planning would need to go into which
> options to expose here. Too few and the bubble becomes useless. Notice
> however that we can already edit title and times from the view and there
> is an open bug on Location/Description too.
>

I think a calendar is a perfect app for playing with new and not classic
UI elements. Having an Web-Like Calendar UI would fit more into that
what users expect in 2006, than having a classic widget set. I can
imagine that in term Rich Web apps and Desktop apps merge together. If
you take a look at Mac OS, Vista, or even Gnome they all move into a
more web style UI.


>>
>> 3. From the bubble shaped dialog users should have access to the fully
>> loaded Events dialog. For example by clicking on a Attendee button.
> Doesn't this imply that Attendees should be its own window as I argued
> for previously? Then the user who doesn't want attendees can just
> ignore the single button, which might be a reasonable compromise.
>
> -Joey

Maybe, but in both cases you need one click to access the dialog. A tab
has the big advantage that nothing pops up. But I agree, too many tabs
are more confusing than helping. That why I personally like the Sheets
Apple introduced with OSX. A sheet is attached to the window from which
it emerges. It is a modal dialog. It assures that the user never loses
track of which window the dialog applies to.

- Christian

Michael Büttner

unread,
Apr 28, 2006, 3:43:45 AM4/28/06
to
Matthias Schäfer wrote:
> I miss a listbox (or similar thing) to choose the calendar in which the
> event/task appears directly on the Event tab. I think this is an
> essential feature for every user with more than one calendar.
> Perhaps this field can be so intelligent that it hides itself if there
> is only one calendar available.
The control you're referring to is contained in the screenshot of the
prototype implementation. It's missing in the mock-up, you're right. And
it's hidden if there's just one calendar available or the other
calendars are read-only. Thanks for the hint.

The prototype also has a control for assigning a category to the event
(which is named 'label' in the mock-up). Like with the above mentioned
control it's hidden if there are no categories specified in the preferences.

> Perhaps you can handle this by just hiding away confusing tabs.

I personally don't like to idea to change the ui based on preferences
since nobody will ever change the configuration after the application
has been installed. The only other option would be to have
pre-configured installation packages but this sounds somehow awkward.

I still believe that it should manageable to create a user interface
which offers all the functionality needed by the intended target
audience while still being clean and concise. If this shows up not to be
a goal that can be reached in a reasonable timeframe we probably need
other ways (extensions, hiding ui by prefs, etc.). but i would try as
hard as possible to not being forced to employ those other possibilities.

mickey.

Michael Büttner

unread,
Apr 28, 2006, 3:56:46 AM4/28/06
to
Christian Jansen wrote:
> Maybe, but in both cases you need one click to access the dialog. A tab
> has the big advantage that nothing pops up. But I agree, too many tabs
> are more confusing than helping. That why I personally like the Sheets
> Apple introduced with OSX. A sheet is attached to the window from which
> it emerges. It is a modal dialog. It assures that the user never loses
> track of which window the dialog applies to.
I already tried to 'overlay' the attendee-page on top of the main page,
but I didn't find a solution to this problem. But I think we're
discussing several issues at once here. In order to find a conclusion in
a reasonable timeframe I would suggest to find a consensus on the
proposed solution before moving to the innovation front.

Of course ideas on how to get together all the different pages
(recurrence,attendees,timezones) without using tabs are welcome. I
personally don't like the idea of different separate dialogs popping up
and I didn't find a solution on how to overlay the pages on top of the
main dialog page.

mickey.

Michael Büttner

unread,
Apr 28, 2006, 4:17:26 AM4/28/06
to
Joey Minta wrote:
> If we keep the multiple windows model, the UI in the main window
> wouldn't change at all (or barely) so I don't see why clutter would be a
> danger. I don't think the 'modal' issue should be an objection, since
> that can be fixed fairly easily. Therefore, I'd like to hear more about
> why opening a new window is 'ugly'.
Several windows distract the user from the main focus. I would like to
hear Christians opinion on this as well. Maybe beltzner could as well
comment on this.

mickey.


Michael Büttner

unread,
Apr 28, 2006, 4:18:47 AM4/28/06
to
In order to drive this discussion to a consensus, I see the following
issues which need to be resolved:

1) using tabs vs. multiple window model vs. more/less buttons

In case there are any other ideas on how to offer the functionality i
would love hear them. Otherwise I would like to vote for tabs.

2) reordering of the controls on the main-pane

Besides some minor objections this seems not to be a major issue, or did
i miss something?

3) recurrence-pane

The recurrence-page did not receive any objections until now except the
one regarding whether or not to modify exceptions directly from the
dialog. This needs to be clarified.

4) free/busy pane

This seems to be a major issue and I'm still not sure how we could come
to a reasonable conclusion. Any thoughts?

5) timezone pane

Joey pointed out that there's a counter-proposal for timezone tab. "The

timezone information should be more closely linked to the times. It

should be possible to specify different timezones for start/end". This
issue needs more discussion. Any thoughts?

mickey.

Matthias Schäfer

unread,
Apr 28, 2006, 12:09:19 PM4/28/06
to dev-apps...@lists.mozilla.org
Thanks for clarification!!!

Your implementation seems very easy usable (hiding if unnecessary)!

That is what software should do: provide features and hide them if
unnecessary - if possible to decide for a stupid computer ;-)

Matthias

Michael Büttner schrieb:

Michiel van Leeuwen

unread,
Apr 28, 2006, 3:33:28 PM4/28/06
to
Michael Büttner wrote:
> 1) using tabs vs. multiple window model vs. more/less buttons
>
> In case there are any other ideas on how to offer the functionality i
> would love hear them. Otherwise I would like to vote for tabs.

I've been thinking of a use of the more/less buttons. I'm not sure how
it will work out, the dialog might get to big. My idea is to add a
more/less button (or twisty, or expander) below the start/end date rows,
labeled 'help me pick a time'. When you expand it, you would get
something like the attendee tab. When there are no attendee, only your
own calendar would show, in the same format. More attendees would mean
more vertical space (with a scrollbar of course)
When done, the widget will disappear again.
Again, this is just a thought, and might not work at all. Please tell me
that it sucks, if you think it does.

> 2) reordering of the controls on the main-pane
>
> Besides some minor objections this seems not to be a major issue, or did
> i miss something?

The missing 'ok' button worries me. In outlook (which i have only used a
few times) I was always looking for 'ok' in the bottom right, but
failing to find.
I know about the similarity with send mail, and I don't have a problem
finding that button. So i'm not sure why i expect it on the event
dialog. I think it has to do with my mental idea that after i composed a
mail message, i want to take the next action: really send it. For an
event, all i want is to close the dialog and save the item. No real next
action. (But maybe that's because i know how email actually works.)

> 3) recurrence-pane
>
> The recurrence-page did not receive any objections until now except the
> one regarding whether or not to modify exceptions directly from the
> dialog. This needs to be clarified.

I think editing exception from the main view is ok. But how about adding
extra recurrence dates?

> 5) timezone pane
>
> Joey pointed out that there's a counter-proposal for timezone tab. "The
> timezone information should be more closely linked to the times. It
> should be possible to specify different timezones for start/end". This
> issue needs more discussion. Any thoughts?

I like jminta's idea of putting the timezone picker in the time
dropdown. But we need to figure out how keyboard-accessible that is.

Michiel

lilmatt

unread,
May 1, 2006, 9:48:17 PM5/1/06
to
Drive-by comment:

"File", "Edit"... etc. should not go in the Event/Task Dialog, as this
will break on Mac OS X (where there is a single menubar, not one per
window)

Jef Driesen

unread,
May 2, 2006, 5:33:43 AM5/2/06
to
Michael Büttner wrote:
> Joey Minta wrote:
>> Not true. I do this quite a bit with my schedule, due to vacations
>> that I know ahead of time. It doesn't seem strange at all to me to
>> know exceptions in advance.
> Of course this is a valid scenario, you want to exclude your vacations.
> But the functionality of adding those exceptions adds complexity to the
> dialog, which is not needed. Adding those vacation dates by entering the
> specific dates is way too abstract for the average user. You could
> easily display your vacation in the views (subscribe to a vacation
> calendar, enter the events on your own, etc.), and then delete the
> conflicting events directly from the view and create those exceptions in
> a clean and intuitive manner.
>
> I would like to hear other opinions as well as I feel that we're
> approaching the final solution from totally contrary point of views here.

How would a user be able to remove the exception again in this model
(e.g. add it again in case of a mistake)? Creating an exception will be
easy, but the opposite will be almost impossible I think.

Christian Jansen

unread,
May 2, 2006, 8:37:16 AM5/2/06
to

I don't see huge problems there. The menu changes due to a context
change. In the same way works Thunderbird.

Again. If the goal of Lightning is to be a well integrated Calendaring

tool than we shouldn't force the user to learn different interaction
models just because she is in a different part of the application. For
the user is Thunderbird + Lightning one app.

From my point of view this is exactly one of this cases where being
consistent has an higher value than being innovative (Ok, a tabbed
OK/Cancel dlg is not innovation - but it behaves different).

Another plus for having a modeless dlg is the fact that users could open
multiple instances of the Event dlg and -- this is the most important
advantage -- that they aren't blocked working in the calender while
having the event dlg opened.

Less important items can be moved into the menu. This reduces clutter on
the tabs.

Last but not least, I've discussed this in the User Experience team I'm
working in. My colleagues agreed that in this special case a consistent
design and behavior provides, compared to a different interaction model,
more advantages.

Michael Büttner

unread,
May 3, 2006, 3:32:37 AM5/3/06
to
Jef Driesen wrote:
> How would a user be able to remove the exception again in this model
> (e.g. add it again in case of a mistake)? Creating an exception will be
> easy, but the opposite will be almost impossible I think.
exceptions are by definition something that diverges from the rule. as
soon as the user changes an occurrence an exception will be created. of
course a problem arises if the user revokes those change since the
exception would still be kept in the model. if this is really considered
something we would like to avoid we could check if the exception equals
the regular occurrence (check if the exception matches the occurrence it
masks) and remove the exception if so. of course this would avoid
keeping dead exceptions. i don't really see a necessity for this feature
but nothing hinders us from implementing it as it would keep the number
of exceptions to a minimum.

exceptions are nothing the user should be aware of since they are just a
detail of the recurrence model. they can be handled 'under the hood' and
since the goal is to hide unnecessary complexity i would claim getting
rid of exception editing is one of the prime candidates in order to
achieve this goal.

mickey.

Michael Büttner

unread,
May 3, 2006, 3:45:22 AM5/3/06
to
the idea is to make the event/task dialog a modeless window similar to
the mail compose window. the motivation behind this is to strive for
consistency in order to seamlessly integrate the calendar into
thunderbird. since the mail compose window also has "File", "Edit" items
in its menu bar i can't see why this should be problematic.

most of the items offered in the menu bar of the mail compose window
have a direct counterpart in the event/task dialog so it makes perfectly
sense to make those items available to the latter.

mickey.

Michiel van Leeuwen

unread,
May 3, 2006, 4:06:18 AM5/3/06
to
Michael Büttner wrote:
> the idea is to make the event/task dialog a modeless window similar to
> the mail compose window. the motivation behind this is to strive for
> consistency in order to seamlessly integrate the calendar into
> thunderbird. since the mail compose window also has "File", "Edit" items
> in its menu bar i can't see why this should be problematic.

Just because the mail compose window is a modeless window with a toolbar
and a menubar, not all windows should be that. The preference window
doesn't have a menubar...

The mailcompose window just has so many options (formatting etc) that
the toolbar and the menubar are needed. But they are not needed for the
event dialog, so I think we shouldn't add those UI elements.

We could make it look the same if for the user it feels like almost the
same action: creating an email or creating an event. But in my mind,
it's very different.


Michiel

Michael Büttner

unread,
May 3, 2006, 4:38:32 AM5/3/06
to
Michiel van Leeuwen wrote:
> I've been thinking of a use of the more/less buttons. I'm not sure how
> it will work out, the dialog might get to big. My idea is to add a
> more/less button (or twisty, or expander) below the start/end date rows,
> labeled 'help me pick a time'. When you expand it, you would get
> something like the attendee tab. When there are no attendee, only your
> own calendar would show, in the same format. More attendees would mean
> more vertical space (with a scrollbar of course)
> When done, the widget will disappear again.
> Again, this is just a thought, and might not work at all. Please tell me
> that it sucks, if you think it does.
picking the start/end date by using the organizers own calendar is an
excellent idea. i find myself creating new events using the week view
(click'n'drag) and later doubleclicking the event to modify the rest of
the properties so it would be a natural process to somehow employ the
same feature from within the dialog. christian, what's your opinion on this?

generally i don't like windows that change its size depending on the
state of the application (expand and shrink depending on a more/less
button). that's my personal taste, i don't know whether this can be
backed by any hard figures from user experience or any other source. i
assume this has to do with the habit that application windows normally
don't show such a behavior.

furthermore, as you already pointed out, i suppose the window might get
too big. again, my personal taste would be to allow the user to resize
the window to some size she feels comfortable with and stick to it.

are there any real objections against using tab pages at all? i find
they are a nice tool which could easily combine all the features we
would like to offer without being forced to 1) resize the event/task
window and 2) open more windows on top of it. any thoughts?

> The missing 'ok' button worries me. In outlook (which i have only used a
> few times) I was always looking for 'ok' in the bottom right, but
> failing to find.
> I know about the similarity with send mail, and I don't have a problem
> finding that button. So i'm not sure why i expect it on the event
> dialog. I think it has to do with my mental idea that after i composed a
> mail message, i want to take the next action: really send it. For an
> event, all i want is to close the dialog and save the item. No real next
> action. (But maybe that's because i know how email actually works.)

granted, but the basic idea is to strive for consistency with the mail
compose window. i would suggest to simply try this approach out. i'm
working with the new dialog for some weeks now and i really got used to
it. if users really complain about it we can easily revoke the changes
and come back to the ordinary ok/cancel buttons.

> I think editing exception from the main view is ok. But how about adding
> extra recurrence dates?

good question, didn't even think about this option ;-) nevertheless this
can be easily solved by allowing cut/copy/paste operations to selected
events in the view. to create an extra recurrence date select an
occurrence and 'copy' it to a new location. does this sound reasonable?

> I like jminta's idea of putting the timezone picker in the time
> dropdown. But we need to figure out how keyboard-accessible that is.

i also like the idea joey pointed out, it's an extremely nice and
elegant way of assigning the timezone to the start/end times. but even
this approach needs a 'other/more' button. we could easily combine the
two proposals. we offer joey's timezone/timepicker in addition to the
proposed timezone tab. i personally prefer to pick the timezone more
visually from a map instead from a long list of names.

we could also have a list of 'favorite timezones' shown below the world
map which represent the 3 most recently chosen or the 3 most common (as
joey already suggested in his proposal). i'm wondering where the
favorite list has been gone? i remember this was part of the initial
proposal of the timezone tab. christian, did you remove this feature
from the wiki? it would come in very beneficial here since it would
allow us to combine the two proposed solutions.

mickey.

Michael Büttner

unread,
May 3, 2006, 4:53:41 AM5/3/06
to
Michiel van Leeuwen wrote:
> The mailcompose window just has so many options (formatting etc) that
> the toolbar and the menubar are needed. But they are not needed for the
> event dialog, so I think we shouldn't add those UI elements.
i don't insist on the toolbar and menubar at all. but i'm still not
convinced that we don't need them.

the toolbar of the mail compose window has the following items along
with their respective counterpart as it can be mapped to the
functionality of the event dialog:

Send -> Save
Contacts -> Contacts
Spell -> Spell
Attach (files,URL) -> Attach (files,URL)
Security -> doesn't apply, granted
Save -> Save (to file, etc.)

The same goes for the menubar, all menues apply to the event dialog as
well except for the options menu which would need other commands.

of course just because the mail compose window is a modeless window with
toolbar and menubar, not all windows should look the same. but am i
alone with the opinion that writing mails and scheduling events has so
much in common that the user interface should look similar?

> We could make it look the same if for the user it feels like almost the
> same action: creating an email or creating an event. But in my mind,
> it's very different.

how could we make it look the same? any suggestions? besides any visual
trickery i still claim that much of the functionality can and should be
offered by the event/task dialog as well. any other opinions?

mickey.

Joey Minta

unread,
May 3, 2006, 9:23:48 AM5/3/06
to
Michael Büttner wrote:
> Michiel van Leeuwen wrote:
>> I think editing exception from the main view is ok. But how about
>> adding extra recurrence dates?
> good question, didn't even think about this option ;-) nevertheless this
> can be easily solved by allowing cut/copy/paste operations to selected
> events in the view. to create an extra recurrence date select an
> occurrence and 'copy' it to a new location. does this sound reasonable?
This sounds highly undiscoverable.

>
>> I like jminta's idea of putting the timezone picker in the time
>> dropdown. But we need to figure out how keyboard-accessible that is.
> i also like the idea joey pointed out, it's an extremely nice and
> elegant way of assigning the timezone to the start/end times. but even
> this approach needs a 'other/more' button. we could easily combine the
> two proposals. we offer joey's timezone/timepicker in addition to the
> proposed timezone tab. i personally prefer to pick the timezone more
> visually from a map instead from a long list of names.

I think offering both is overkill. Also, my proposal intended to
include a map that would be display when 'Other...' was chosen. Only
the last N chosen timezones would be available in the popup, since this
would reduce the times the entire map needed to be used, but the map
would be available within 2 clicks.

-Joey

Joey Minta

unread,
May 3, 2006, 10:59:56 AM5/3/06
to
I'm confused here. One mock-up has attendees in the main tab, but
another does not. I was working off the more xul-looking one, where
attendees do not appear, and hence the contacts make no sense. Which is
the definitive mockup that we're supposed to be discussing?

If attendees also appear in the main tab, then a previous concern I've
raised about consistency returns: Only the attendees tab has
information that it contains also displayed in the main tab. This seems
weird. Either the information belongs in its own tab or it doesn't. I
don't think it should be in both.

-Joey

Frank Loehmann

unread,
May 3, 2006, 11:01:13 AM5/3/06
to
Joey Minta wrote:
> Michael Büttner wrote:
>> Michiel van Leeuwen wrote:
>>> I think editing exception from the main view is ok. But how about
>>> adding extra recurrence dates?
>> good question, didn't even think about this option ;-) nevertheless
>> this can be easily solved by allowing cut/copy/paste operations to
>> selected events in the view. to create an extra recurrence date select
>> an occurrence and 'copy' it to a new location. does this sound
>> reasonable?
> This sounds highly undiscoverable.

I think it is the default place beside the context menu. Furthermore
menu entries are important for accessibility reasons.

>>> I like jminta's idea of putting the timezone picker in the time
>>> dropdown. But we need to figure out how keyboard-accessible that is.
>> i also like the idea joey pointed out, it's an extremely nice and
>> elegant way of assigning the timezone to the start/end times. but even
>> this approach needs a 'other/more' button. we could easily combine the
>> two proposals. we offer joey's timezone/timepicker in addition to the
>> proposed timezone tab. i personally prefer to pick the timezone more
>> visually from a map instead from a long list of names.
> I think offering both is overkill. Also, my proposal intended to
> include a map that would be display when 'Other...' was chosen. Only
> the last N chosen timezones would be available in the popup, since this
> would reduce the times the entire map needed to be used, but the map
> would be available within 2 clicks.
>
> -Joey

- Frank

Joey Minta

unread,
May 3, 2006, 11:22:54 AM5/3/06
to
Frank Loehmann wrote:
> Joey Minta wrote:
>> Michael Büttner wrote:
>>> Michiel van Leeuwen wrote:
>>>> I think editing exception from the main view is ok. But how about
>>>> adding extra recurrence dates?
>>> good question, didn't even think about this option ;-) nevertheless
>>> this can be easily solved by allowing cut/copy/paste operations to
>>> selected events in the view. to create an extra recurrence date
>>> select an occurrence and 'copy' it to a new location. does this sound
>>> reasonable?
>> This sounds highly undiscoverable.
>
> I think it is the default place beside the context menu. Furthermore
> menu entries are important for accessibility reasons.
>
My point was not that Copy and Paste are undiscoverable in the context
menu, but rather that it would be undiscoverable that this unique
combination of selecting an occurrence+copy+paste would result in this,
in my opinion, unexpected behavior. For a user looking at the program,
wondering 'How do I add an unscheduled occurrence?' I doubt this course
of action would occur to them.

-Joey

Frank Loehmann

unread,
May 3, 2006, 11:52:07 AM5/3/06
to
Joey Minta wrote:
> FrankL wrote:
>> >Joey Minta wrote:
>>
>> [...]
>>
>>> -Why is 'Contacts' a top-level button, when it only seems to apply to
>>> the Attendees tab?
>>
>> The 'Contacts' button behaves the same like in Thunderbird's mail
>> composing window. An updated mock-up showing this behavior is in
>> progress.
> I'm confused here. One mock-up has attendees in the main tab, but
> another does not. I was working off the more xul-looking one, where
> attendees do not appear, and hence the contacts make no sense. Which is
> the definitive mockup that we're supposed to be discussing?

The Attendees field is hidden as long as there are no attendees for the
current event. If the Contacts pane will be opened, this field is also
shown, even if it is empty. Then the user will get direct feedback, if
she is adding contacts from this pane. Today I have added some more
descriptions to the event dialog mock-up. More will follow tomorrow.

http://wiki.mozilla.org/Calendar:Event_Dialog#Event_Tabpage


> If attendees also appear in the main tab, then a previous concern I've
> raised about consistency returns: Only the attendees tab has
> information that it contains also displayed in the main tab. This seems
> weird. Either the information belongs in its own tab or it doesn't. I
> don't think it should be in both.
>
> -Joey

-Frank

Michiel van Leeuwen

unread,
May 3, 2006, 4:10:33 PM5/3/06
to
Michael Büttner wrote:
> are there any real objections against using tab pages at all? i find
> they are a nice tool which could easily combine all the features we
> would like to offer without being forced to 1) resize the event/task
> window and 2) open more windows on top of it. any thoughts?

With my idea, i want to try to keep all the information visible at once.
After you created the event, and look at it later, the times in which
the other attendees are available doesn't matter, so it can be hidden.
Tabs also do that, but it's slightly different.
And it's not that I don't like tabs at all, but I just had an idea for
an alternative, and wanted to explore it. Maybe it would work really
good, maybe not.

> granted, but the basic idea is to strive for consistency with the mail
> compose window. i would suggest to simply try this approach out. i'm
> working with the new dialog for some weeks now and i really got used to
> it. if users really complain about it we can easily revoke the changes
> and come back to the ordinary ok/cancel buttons.

I tried it in outlook, and i always had to search for how to close the
window. It wasn't immediately clear to me. (But i didn't use outlook
that much.)

Michiel

Christian Jansen

unread,
May 4, 2006, 8:12:30 AM5/4/06
to
Michael Büttner schrieb:

I agree to your opinion. But wouldn't be more likely that one started
directly in his/hers calendar creating an event?

@ Michiel:
I like the idea of having a 'help me pick a time' button. Whereby i
suggest not to call it 'help me on some thing', because this might
rise expectations that calendar auto-pick the next available time slot.

I've crerated a rough mock-up showing your proposal.
http://wiki.mozilla.org/Image:Event-with-plugged-calendar.gif

Instead for extending the length I've reduced the size of the
Description field and hided the URL box.

I'm seing an real issue regarding the length of the dialog. Personally,
I do not like extensive scrolling and dialog which always change their
change their size. This might be different, if we offer some real spiffy
resizing animations ;-) Just kidding. Instead of expanding the dialog it
might be a solution to open another dialog which contains the calendar
view.


>
>> The missing 'ok' button worries me. In outlook (which i have only used
>> a few times) I was always looking for 'ok' in the bottom right, but
>> failing to find.
>> I know about the similarity with send mail, and I don't have a problem
>> finding that button. So i'm not sure why i expect it on the event
>> dialog. I think it has to do with my mental idea that after i composed
>> a mail message, i want to take the next action: really send it. For an
>> event, all i want is to close the dialog and save the item. No real
>> next action. (But maybe that's because i know how email actually works.)
> granted, but the basic idea is to strive for consistency with the mail
> compose window. i would suggest to simply try this approach out. i'm
> working with the new dialog for some weeks now and i really got used to
> it. if users really complain about it we can easily revoke the changes
> and come back to the ordinary ok/cancel buttons.
>
>> I think editing exception from the main view is ok. But how about
>> adding extra recurrence dates?
> good question, didn't even think about this option ;-) nevertheless this
> can be easily solved by allowing cut/copy/paste operations to selected
> events in the view. to create an extra recurrence date select an
> occurrence and 'copy' it to a new location. does this sound reasonable?

So, the menu is in the game again? ;-) I like this idea, but at the
moment it is not clear to me how to indicate best that an occurrence is
selectable and can be copy and pasted.

>
>> I like jminta's idea of putting the timezone picker in the time
>> dropdown. But we need to figure out how keyboard-accessible that is.
> i also like the idea joey pointed out, it's an extremely nice and
> elegant way of assigning the timezone to the start/end times. but even
> this approach needs a 'other/more' button. we could easily combine the
> two proposals. we offer joey's timezone/timepicker in addition to the
> proposed timezone tab. i personally prefer to pick the timezone more
> visually from a map instead from a long list of names.

Same do I. Apple did a great job with their time zone picker in iCal.


>
> we could also have a list of 'favorite timezones' shown below the world
> map which represent the 3 most recently chosen or the 3 most common (as
> joey already suggested in his proposal). i'm wondering where the
> favorite list has been gone? i remember this was part of the initial
> proposal of the timezone tab. christian, did you remove this feature
> from the wiki? it would come in very beneficial here since it would
> allow us to combine the two proposed solutions.

Yes, I removed it -- based on feedback. If there is demand for a "My
Time Zone Favorites" List with should live the idea up again.
>
> mickey.

Michiel van Leeuwen

unread,
May 5, 2006, 5:57:27 AM5/5/06
to
Christian Jansen wrote:
> I agree to your opinion. But wouldn't be more likely that one started
> directly in his/hers calendar creating an event?

Dragging to create a new event isn't very discoverable. The most obvious
way to create a new event is using the toolbar icon. It's the most visible.

> @ Michiel:
> I like the idea of having a 'help me pick a time' button. Whereby i
> suggest not to call it 'help me on some thing', because this might
> rise expectations that calendar auto-pick the next available time slot.

Wording is open for suggestions of course :)

> I've crerated a rough mock-up showing your proposal.
> http://wiki.mozilla.org/Image:Event-with-plugged-calendar.gif

My idea was more to have a small horizontal bar, just like the bars in
the proposed attendees tab. But you only have one attendee (the user
itself), so the bar doesn't take much vertical space, maybe only 10 px.

> Instead for extending the length I've reduced the size of the
> Description field and hided the URL box.

Using the description box as an overflow-area may be a nice solution for
the resizing dialog.

Michiel

Michael Büttner

unread,
May 5, 2006, 10:31:39 AM5/5/06
to
I just uploaded the first version of the prototype implementation.
Please refer to https://bugzilla.mozilla.org/show_bug.cgi?id=324657#c23
for further details. Feel free to post any comments on this.

In order to get this rather large feature rolling, I think it would
probably be a good idea to break things apart. So discussion and
reviewing could be done in smaller incremental steps. Furthermore this
approach doesn't block me on contributing the bits and pieces we agree on.

I'm currently breaking the attendee-control down into separate bindings
since I found it annoying that the grid (the right-hand side of the
page) can be resized but the size of the listbox containing the names of
the attendees stays fixed. The idea was to separate the names and the
grid with a grippy between those two controls. This would allow for
adjusting the relative sizes. As a first step we could take the
resulting attendee-listbox and put this into the currently existing
dialog. This would already include tight address book integration and
LDAP support.

As a next step I planned to apply the modification to the recurrence
related part of the existing dialog. These are relatively minor and
since nobody complained about the additions to the rules I think I
should just go for it. A further step could be to add the preview
control to the recurrence dialog if there are no objections.

I already wrote a caching mechanism for the new dialog. The
implementation is based on how the mail compose window handles this sort
of problem. The extension I uploaded does not employ this features since
I implemented the caching stuff in native code and I wanted to keep the
extension platform neutral. But on slow machines we obviously need some
sort of speed-up for the dialog. I think that the discussion about the
details is worth some other thread but this whole thing could be another
step along the road.

Any thoughts?

mickey.

Michael Büttner

unread,
May 5, 2006, 10:42:18 AM5/5/06
to
Joey Minta wrote:
> My point was not that Copy and Paste are undiscoverable in the context
> menu, but rather that it would be undiscoverable that this unique
> combination of selecting an occurrence+copy+paste would result in this,
> in my opinion, unexpected behavior. For a user looking at the program,
> wondering 'How do I add an unscheduled occurrence?' I doubt this course
> of action would occur to them.
If copy and paste is discoverable in the context menu I think it's
obvious that one can just copy'n'paste occurrences to create new
occurrences of the same event.

By the way, I think that we should offer hints wherever possible in the
final product. I'm thinking about tooltips or popups explaining the
application while the user is working with it. So if a user drag'n'drops
an event some form of inline help could tell her that it's also possible
to copy'n'paste. This maybe doesn't sound like an extremely good
example, but you get the point.

Furthermore I find such solutions as just copy occurrences around to
create exception an extremely elegant way to handle this sort of
problem. I can't imagine users will ever use the datelist-like control
for editing exceptions. again, this is just a coder's view of how users
probably would use a feature. Of course this is just my personal opinion.

mickey.

Joey Minta

unread,
May 5, 2006, 11:08:33 AM5/5/06
to
Michael Büttner wrote:
> Joey Minta wrote:
>> My point was not that Copy and Paste are undiscoverable in the context
>> menu, but rather that it would be undiscoverable that this unique
>> combination of selecting an occurrence+copy+paste would result in
>> this, in my opinion, unexpected behavior. For a user looking at the
>> program, wondering 'How do I add an unscheduled occurrence?' I doubt
>> this course of action would occur to them.
> If copy and paste is discoverable in the context menu I think it's
> obvious that one can just copy'n'paste occurrences to create new
> occurrences of the same event.
My problem with this is that, under this proposal, copy and paste
behaves differently based on whether an event is recurring. If I copy
and paste a non-recurring event, I get a new, unrelated, event. If I
copy and paste a recurring event, I would probably expect a new,
unrelated recurring event, not a new instance of the original recurring
event. I also still don't see how a user is supposed to intuit this as
the solution to his problem.

>
> By the way, I think that we should offer hints wherever possible in the
> final product. I'm thinking about tooltips or popups explaining the
> application while the user is working with it. So if a user drag'n'drops
> an event some form of inline help could tell her that it's also possible
> to copy'n'paste. This maybe doesn't sound like an extremely good
> example, but you get the point.

Note that there's a Facebook (think MySpace) at my university called "Go
to hell, Paperclip from Word." This proposal sounds a lot like the
Paperclip/Office Assistant option, except without the anthropomorphizing
of the object. The bottom line is that these kinds of help-object,
while meant in good faith, generally come off as condescending and
annoying to the user. It usually is quite distracting, too. If I just
drag+dropped an event, copy+paste is likely completely unrelated to the
next task I want to perform.

Also, users don't like to read. [1] That means, yet again, that they
will be annoyed by us trying to force them to read. I think it'd be
much better if we allocated the time to making the UI more intuitive and
easier to use out of the box, rather than coming up with ways of
educating the user about features that weren't designed well enough to
be figured out on their own. (That came out harsher than I intended.)

>
> Furthermore I find such solutions as just copy occurrences around to
> create exception an extremely elegant way to handle this sort of
> problem. I can't imagine users will ever use the datelist-like control
> for editing exceptions. again, this is just a coder's view of how users
> probably would use a feature. Of course this is just my personal opinion.

As I said, I use this datelist all the time.

-Joey

[1] http://www.joelonsoftware.com/uibook/chapters/fog0000000062.html

Michael Büttner

unread,
May 5, 2006, 11:33:12 AM5/5/06