Event/Task dialog
Michael Büttner
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
> I would like to start a discussion about the proposal for the new event/task
> dialog.
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
> 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
> 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
-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
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
> 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.
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.
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
> 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
>>> 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
[...]
> -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
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
> -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.)
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
> 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
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
> 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.
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
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
> -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
> 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.
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
> 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
> 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.
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
> 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.
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
> 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'.
hear Christians opinion on this as well. Maybe beltzner could as well
comment on this.
mickey.
Michael Büttner
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
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
> 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
"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
> Joey Minta wrote:
>> 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
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
> 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.
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
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
> 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
> 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.
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
> 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.
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
> 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?
>
>> 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
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
> 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
> 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.
>
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
> 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
> 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
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
> 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
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
> 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.
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
> 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.
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
> 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.
or not is totally irrelevant. To the user all events are the same. This
is why i'm opposing the exception model in the first place. If I copy an
event i expect it to be copied, why is it important whether or not this
new event belongs to the series or not? maybe it would even be a good
idea to not make the new instance part of the series at all and always
create an unrelated event.
> 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.)
It was just an idea, no need to play tough.
> As I said, I use this datelist all the time.
I don't think that this is relevant at all. We should not project our
personal way we think users probably will use the application but let
people decide who have expertise in the field of ui design. christian,
beltzner, any comments on this? obviously we have totally contrary
opinions here.
mickey.
Michiel van Leeuwen
> 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.
unfortunately, the extension doesn't work in sunbird. I added sunbird
support to install.rdf, but that wasn't enough...
Guess i have to play some more with the overlays.
Michiel
Christian Jansen
users to define nothing more than recurrences. It should use standard
UI-Elements, no drag & drop, no copy paste. Defining (recurring)
exceptions might be from interest too. But my guess is that this feature
is less important and more a nice to have.
- Christian
FrankL
In general this is true for dialogs or helpers like clippie, but tool
tips on icons are often (actively) used by users to explorer the
application I have learned in usability tests. Also menus are scanned
systematically from left to right if they stuck or want to get familiar
with the application.
>> 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
-Frank
> [1] http://www.joelonsoftware.com/uibook/chapters/fog0000000062.html
Dan Mosedale
>
> Whether or not the initial event is an occurrence of a recurring event
> or not is totally irrelevant. To the user all events are the same.
I think above statement is the center of the issue. If we were to
decide that that were always the case, it would indeed be a helpful
simplifying assumption. However, consider the case of weekly meetings:
things like dial-in phone number, location, and URL to the agenda are
likely to be the same from week to week, and thus would be something
that you'd want to inherit from the parent, unless explicitly overridden
in the exception event. So at some level, the data-model really is
exposed to the user. It would certainly be interesting to know how
existing calendar apps deal with this issue...
>> As I said, I use this datelist all the time.
> I don't think that this is relevant at all. We should not project our
> personal way we think users probably will use the application but let
> people decide who have expertise in the field of ui design. christian,
> beltzner, any comments on this? obviously we have totally contrary
> opinions here.
This goes back to UI ownership, which hopefully we'll have nailed down a
bit better soon. That said, it strikes me that anecdotal evidence is
worth mentioning in these sorts of discussion as a data point, keeping
in mind that it is neither more nor less than a single data point.
Dan
Dan Mosedale
> 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.
This sound like an excellent strategy.
> 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.
Make sense. I assume the leftmost checkbox in the attendee list is for
confirmation status, correct? What's the box between that and the name for?
> 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.
It should be easy to see if the relevant contractids are contained in
Components and then use that info to decide whether to offer
autocompletion in the textbox or not.
> 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.
Those look like pretty reasonable changes to me, and the changes are
small and self-contained enough that if this gets broken out into a
separate bug, it should be easy enough to discuss them in Bugzilla.
> A further step could be to add the preview
> control to the recurrence dialog if there are no objections.
I kinda like the preview stuff, though it sounds like we probably want
to figure out our exceptions model first, given the lack of existing
dialog space.
> 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.
I'll try and have a look at that bug sometime in the next several days.
I think this work actually touches on several higher level issues,
though. Specifically: whether it's better to imitate very standard
lightweight dialogs that have ok/cancel or imitate the heavier weight
mail compose dialogs, whether we want tabs or not, discussions about
modality, etc. So this may not be the lowest-hanging fruit to pick from.
Another piece of functionality that might be straightforward to split
out is timezones. Since people seem like the iCal UI, it might not be
hard to find agreement around something similar there.
Dan
Joey Minta
>
> Another piece of functionality that might be straightforward to split
> out is timezones. Since people seem like the iCal UI, it might not be
> hard to find agreement around something similar there.
picker in the date calculator extension:
http://jminta.googlepages.com/cal-extras
It's not wired up into a <datetimepicker> there, and it doesn't remember
old selections, but I think the concept should be relatively clear.
-Joey
Frank Loehmann
In general this is true for dialogs or helpers like clippie, but tool
tips on icons are often (actively) used by users to explorer the
application I have learned in usability tests. Also menus are scanned
systematically from left to right if they stuck or want to get familiar
with the application.
>> 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
-Frank
> [1] http://www.joelonsoftware.com/uibook/chapters/fog0000000062.html
Michael Büttner
> things like dial-in phone number, location, and URL to the agenda are
> likely to be the same from week to week, and thus would be something
> that you'd want to inherit from the parent, unless explicitly overridden
> in the exception event. So at some level, the data-model really is
> exposed to the user. It would certainly be interesting to know how
> existing calendar apps deal with this issue...
parent, unless overridden. this is the very nature of exceptions. but
what i was trying to say is that it would be nice to perform the
exception model under the hood instead of exposing the data-model and
let the user directly modify the list of EXDATE's. just dragging an
event already creates a new exception. the user doesn't need to know
anything about the internal data-model nor about exceptions at all.
deleting an occurrence creates a new EXDATE. this observation led me to
the idea of allowing to copy and paste occurrences to create extra
recurrences to follow the same path.
after thinking a while about the discussion i was asking myself how is
it possible to add extra recurrence dates at all? basically, the
date/time list as it currently stands is nothing more than a list of
EXDATE's. how should it be possible to create *new* occurrences? it is
just a list of dates were an exception masks a regular occurrence. if i
didn't miss something obvious here, we're talking about a feature which
is currently not available. so it has nothing to do with removing the
list of EXDATE's.
mickey.
Michael Büttner
> This sound like an excellent strategy.
> I assume the leftmost checkbox in the attendee list is for
> confirmation status, correct? What's the box between that and the name
> for?
The leftmost icon stands for the role (required or optional participant)
and the next icon is meant for the status (accepted, declined, etc).
Only the organizer of an event is allowed to set the roles of the
attendees but can't change their status. Each attendee is allowed to
change its own status but can't change anything else. All of this rights
related stuff is currently missing in the available extension since I
based it on the upcoming wcap connector. As far as I know there's
nothing like an identity of the calendar user so there's no way of
matching the user with the organizer of an event. This is something we
need to find a solution for. But as a first step I possibly could just
provide the attendee-listbox and add the rest afterwards. So we can
discuss how we address the identity stuff in parallel.
> It should be easy to see if the relevant contractids are contained in
> Components and then use that info to decide whether to offer
> autocompletion in the textbox or not.
agreed, good hint.
> Those look like pretty reasonable changes to me, and the changes are
> small and self-contained enough that if this gets broken out into a
> separate bug, it should be easy enough to discuss them in Bugzilla.
great.
> I kinda like the preview stuff, though it sounds like we probably want
> to figure out our exceptions model first, given the lack of existing
> dialog space.
is there something unclear with our exception model? i didn't have the
impression that there's still the need to figure something out.
furthermore, the recurrence related stuff is currently handled in its
own separate dialog (assuming we don't go for tabs first that is), so
the dialog space is probably not such a large issue?
> I'll try and have a look at that bug sometime in the next several days.
> I think this work actually touches on several higher level issues,
> though. Specifically: whether it's better to imitate very standard
> lightweight dialogs that have ok/cancel or imitate the heavier weight
> mail compose dialogs, whether we want tabs or not, discussions about
> modality, etc. So this may not be the lowest-hanging fruit to pick from.
I'm fine with it. I just started to divide what I did in the last weeks
into several smaller patches and the caching stuff was the first thing
which fell apart. So I though I just get this out instead of waiting.
Whether or not we go for this solution or employ dynamic overlays (as
you suggested some time ago) is of course open for discussion. I would
be fine with either option. My primary concern was just to get the patch
out of the door ;-)
> Another piece of functionality that might be straightforward to split
> out is timezones. Since people seem like the iCal UI, it might not be
> hard to find agreement around something similar there.
I'm still not sure whether we go for joey's proposal or for something
similar like the suggested timezone page. Possibly even a mixture of
both, I'm not sure. Maybe we should wait until we find some agreement on
this. I would be fine with joey's approach, but I'm still unclear about
how to visually select a timezone.
mickey.
Stephan Schaefer
> Michael Büttner wrote:
> >
>> Whether or not the initial event is an occurrence of a recurring event
>> or not is totally irrelevant. To the user all events are the same.
>
> I think above statement is the center of the issue. If we were to
> decide that that were always the case, it would indeed be a helpful
> simplifying assumption. However, consider the case of weekly meetings:
> things like dial-in phone number, location, and URL to the agenda are
> likely to be the same from week to week, and thus would be something
> that you'd want to inherit from the parent, unless explicitly overridden
> in the exception event. So at some level, the data-model really is
> exposed to the user. It would certainly be interesting to know how
> existing calendar apps deal with this issue...
>
If I remember correctly, the whole discussion started with the request
to allow for defining additional occurrences to a (recurring) event. At
least this feature is not supported by iCal, Outlook or Google calendar.
This means there is either much room for innovation or no need at all. I
think we should postpone this discussion and try to agree on features
where proposals already exists.
Stephan
Michiel van Leeuwen
> I'm still not sure whether we go for joey's proposal or for something
> similar like the suggested timezone page. Possibly even a mixture of
> both, I'm not sure. Maybe we should wait until we find some agreement on
> this. I would be fine with joey's approach, but I'm still unclear about
> how to visually select a timezone.
What do you mean with joey's proposal? The one in
http://wiki.mozilla.org/Calendar_Talk:Event_Dialog or more like the
image in http://jminta.googlepages.com/Screenshot3.png ?
(I personally prefer the first)
Michiel
Dan Mosedale
The one in the wiki has the issue that except when the picker is dropped
down, it doesn't display the timezone along with the time when viewing
the event dialog. This sounds like it has the potential to lead to a
lot of mistakes by people inadvertently assuming that those times are in
the default timezone.
If I'm understanding Joey's proposal in Screenshot3, it's a lot like
iCal, except that it has a timezone after each time, instead of just a
single timezone for the event. I think the dropdown also wants UTC &
Floating in addition to Other, and I wouldn't be averse to doing what
iCal does and having timezones be off by default and easy to toggle on.
Dan