'Simple' recurrence options
Joey Minta
additional options/functionality to the recurrence dialog. What should
probably come as no surprise to many of you, is that the end result is
starting to look more complex than I would like. Accordingly, I'd like
to try to keep users out of the more complex dialog as much as possible.
In line with Bug 338215, I'd like to propose that we offer some
'shortcut' options for the most common recurrence options. We'd move
the recurrence widget to a new row right below the start/end times.
Options I'd like to offer here:
Repeats:
*every day
*every [weekday]
*every Mon., Weds., and Fri. (when appropriate)
*every Tues., and Thurs. (when appropriate)
*on the Nth of every month
*on the last day of every month (when appropriate)
*every year on [month] [day]
*Custom...
This is the model that iCal has adopted, and many web-calendars (Google,
Trumba) only offer these pre-set options. It also allows us to
streamline the most common paths. "Custom..." would of course open the
current recurrence dialog, offering more options.
Note that I've only seen the every M/W/F and every T/H options offered
in Google's calendar. They are, however, particularly well-suited to
student scheduling, as most class schedules follow those patterns.
Given that this is one of our main target uses, I think these options
should also be included, but I'm not 100% convinced of that.
Another option to consider is
*on the last [weekday] of every month
Thoughts? Objections? Opinions?
-Joey
Michael Büttner
> In line with Bug 338215, I'd like to propose that we offer some
> 'shortcut' options for the most common recurrence options. We'd move
> the recurrence widget to a new row right below the start/end times.
> Options I'd like to offer here:
> Repeats:
> *every day
> *every [weekday]
> *every Mon., Weds., and Fri. (when appropriate)
> *every Tues., and Thurs. (when appropriate)
> *on the Nth of every month
> *on the last day of every month (when appropriate)
> *every year on [month] [day]
> *Custom...
premature. we still didn't find a conclusion on the layout of the
dialog, whether or not using tabs to factor the various complex chunks.
or even use a radical different approach (see
https://bugzilla.mozilla.org/show_bug.cgi?id=338215#c1). so i suspect
that offering shortcuts on the main page of the dialog would conflict
with the 'more complex' rules offered elsewhere in case we're not using
the layout as it currently is (open a separate dialog to select the rules).
furthermore i would like to point to the "Make changes quickly and then
get them to people so that we can refine them based on observation of
user interactions" piece of the Firefox charter. basically this
shortcut-proposal involves two successive changes (change the recurrence
rules and synchronously provide shortcuts). i would prefer to take the
second step if people really find the recurrence rules too complicated.
also note that the proposed changes to the recurrence rules could be
pre-selected (see
https://bugzilla.mozilla.org/show_bug.cgi?id=337671#c10), which means
they offer a nearly identical functionality as the proposed shortcuts.
for example under monthly recurrence, we could preselect the Nth day of
the month, which would be the same as selecting the above mentioned
shortcut (*on the Nth of every month).
mickey.
Christian Jansen
Your proposal leaves me to the question:
Which one are the most common recurrence options? I can't answer that.
Of coarse there might be a good chance that one event repeats once a
week, or once yearly. I can also imagine that often events repeat on a
monthly bases... but than? Too often these pattern fit to one user
group. What is if one event should occur only 5 times? Do users have to
specify that in the advanced recurrence rules Dialog which users can
reach via Custom...
Or in other different culture ares where the pattern "every Mon., Weds.,
and Fri." does not fit in, because Sunday is a working day or Friday a
non working day?
With the proposed solution we are not simpler than for example Outlook,
or Yahoo Mail. But it give users the flexibility to specify pattern
without being pressed into a sequence of commands (Apple's does that. It
looks very simple, but is very annoying if you need to schedule a couple
of events).
There is no real good size fits all solution. The proposed design is
from my point of view a good compromise in offering a flexible but not
too complex solution.
-Christian
Joey Minta
> Your proposal leaves me to the question:
> Which one are the most common recurrence options? I can't answer that.
there's one most-common recurrence option, but offering 5-6 seems to do
exactly what beltzner suggested we do with our target users: optimize
for their common tasks.
> ... Too often these pattern fit to one user
> group.
Then it's a good thing we have target users.
> What is if one event should occur only 5 times? Do users have to
> specify that in the advanced recurrence rules Dialog which users can
> reach via Custom...
Yes.
>
> Or in other different culture ares where the pattern "every Mon., Weds.,
> and Fri." does not fit in, because Sunday is a working day or Friday a
> non working day?
That's a good argument in favor of perhaps dropping these. As I said in
my comments, these were the options I was least certain should be included.
>
> With the proposed solution we are not simpler than for example Outlook,
> or Yahoo Mail.
Is this supposed to be a good or bad thing? Are we talking about my
proposed solution here or the recurrence dialog as proposed on the wiki?
But it give users the flexibility to specify pattern
> without being pressed into a sequence of commands (Apple's does that. It
> looks very simple, but is very annoying if you need to schedule a couple
> of events).
>
> There is no real good size fits all solution. The proposed design is
> from my point of view a good compromise in offering a flexible but not
> too complex solution.
Perhaps it's better to not talk in terms of simple/complex but rather
streamlined/time-consuming. In retrospect, I may have positioned this
proposal incorrectly as a simplicity discussion, when really, my
intention was to make it as easy as possible for users to do their most
common tasks.
My proposal here doesn't remove any functionality, and it doesn't make
things more difficult on users who want the advanced rules. (2 clicks
in each case.) What it does do is make things easier for small business
owner to enter birthdays, weekly pay-check/reports/meetings, and monthly
audits/meetings. It also makes it easier for the student to specify
weekly classes and assignments.
-Joey
George L. Sexton
I think our software does a pretty decent job of things like this. You
should take a look at it:
http://www.mhsoftware.com/caldemo/
Click on the login and edit the calendar button.
When you're viewing a calendar, click the right most icon to add a new
event.
Change to the recurrence tab
Change the recurrence dropdown through the various settings.
> Another option to consider is
> *on the last [weekday] of every month
>
> Thoughts? Objections? Opinions?
>
> -Joey
--
George Sexton
MH Software, Inc. - Home of Connect Daily Web Calendar
http://www.mhsoftware.com/connectdaily.htm
Michiel van Leeuwen
> Note that I've only seen the every M/W/F and every T/H options offered
> in Google's calendar. They are, however, particularly well-suited to
> student scheduling, as most class schedules follow those patterns. Given
> that this is one of our main target uses, I think these options should
> also be included, but I'm not 100% convinced of that.
That's very locale specific. At the schools that I went to, there was no
rule like that. Classes could be on monday and tuesday or whatever. I
never found any logic in it. So assuming that the rule works for
students doesn't work for all students. Likely only for US students, and
i can imagine a lot of schools in the US not following that rule.
Michiel
Dan Mosedale
>
> My proposal here doesn't remove any functionality, and it doesn't make
> things more difficult on users who want the advanced rules. (2 clicks
It also has the advantage of making the basic details of recurrence
visible on the main event dialog without having to click through to the
full recurrence UI.
In general, this strikes me as a solid proposal for which there is
precedent in other products. As far as I can tell, we have
near-consensus that the mechanism (having a menu with basic options and
a link to some way to choose more complex options) is a good one.
Furthermore, it seems to be basically compatible with all of the various
event dialog options that are currently on the table, including the
mockup in recently posted to bug 338215.
The one place there does not appear to be consensus is on the set of
possible recurrence details to be displayed in the dropdown menu. Once
the mechanism is implemented, however, this is easy to change as we go.
So this seems like an ideal thing to iterate on based on user feedback.
Since we don't have a large number of proposed milestones between now
and 1.0, and since this has clear wins in the areas of "executing common
tasks" and "visibility with fewer clicks", I'd propose that we go ahead
with this work now, rather than waiting.
Joey, given this discussion, what is your thinking about how we should
seed the menu?
Dan
Michael Büttner
> In general, this strikes me as a solid proposal for which there is
> precedent in other products. As far as I can tell, we have
> near-consensus that the mechanism (having a menu with basic options and
> a link to some way to choose more complex options) is a good one.
me if i'm wrong, but i don't had the impression that we came to a
decision about how the dialog is structured. there are currently several
options on the table:
1) main dialog, opens separate recurrence dialog to enter pattern.
2) separate chunks into tabs (see proposal)
3) bug 338215, comment #1 (mickey)
4) bug 338215, comment #3 (christian)
the reason why i suggest to postpone adding the recurrence shortcuts is
because they only work with the current structure of the event dialog.
if we decide to step towards one of the other proposals those shortcuts
have only limited or not use at all. i would suggest to first find a
consensus on the final layout and then flesh it out.
i made bug 337713 depend on 338215 for the same reason, so i can't see
why the same shouldn't be true for the proposed shortcut options.
mickey.
Joey Minta
> Joey, given this discussion, what is your thinking about how we should
> seed the menu?
*every day
*every [weekday]
*on the Nth of every month
*on the last day of every month (when appropriate)
*every year on [month] [day]
*Custom...
-Joey