In https://bugzilla.mozilla.org/show_bug.cgi?id=277731#c16 mvl asks
"What is a task and what is an event?"  While these are incredibly broad
topics, and I'm skeptical about the possibility of arriving at an actual
consensus, here goes...

A 'task' seems to be generally synonymous with a 'to-do.'  The
paradigmatic examples seem to be "Take out the trash," "Walk the dog,"
"Do my taxes," etc.  Looking at the above examples, combined with the
comment about 'to-do' it appears that tasks are fundamentally *actions
that must be performed.*  All of the examples in the list contain verbs,
and these seems to be emblematic of tasks.

A task will often contain the following additional information: a
duration (the known amount of time it will take to perform the action)
and a drop-dead date (the date before which the action must be performed
in order to avoid being moot.

An 'event' is slightly more difficult to pin down.  Paradigmatic
examples seem to be 'Doctor's appt at 2pm' and 'Meeting with boss at
10am.'  As near as I can tell, events essentially boil down to *a
conjunction between: a person (or persons), a place, and a time.*  This
fits with the above examples and most others that I think people would
put forth.

I think it's important to note that, although all 3 of the above
elements are needed for the event to occur, at any point prior to the
event one or more of them may not be known.

The real difficulty occurs when the conjunction requires an action.
Then it becomes unclear whether the item is actually a task or an event.
  The classic example here is "Pick up Susie at the airport at 2pm."
The natural characterization casts this as an action about a conjunction.

For this reason, as well as to try and avoid forcing users into a mental
model they're not amenable to, I'd suggest trying to keep the
distinction between tasks and events flexible.  I'd like to hold off on
teasing out the more specific implications of this framing until there's
more consensus on it.

The main advantage of this framing is that it seems to fit nicely with
my intuitions.  It makes the easy questions easy and the hard questions
hard.  I'm very curious in hearing other ways of defining these two
classes, and especially in seeing the way they resolve the difficult
airport case.

Comments?

-Joey

Joey Minta escreveu:

But what exactly is the problem with the airport case?

I agree with you when you say that these two things should be kept
clearly distinct; and I think the distinction alone will solve the
"problem" above: if you have in your mind the "event of your sister
arriving", you will create an "event"; if you have in your mind the
"task of picking up your sister", you'll create a "task".

What am I missing?

--
  Pedro Lamarão

This was precisely *not* my point.  I argue that the two classes are
naturally intersecting and the program's model should portray them as such.

My point is that I don't have either (clearly) in my mind when I want to
add this to my calendar.  Forcing me to choose one of them (especially
if that choice is irrevocable) makes me feel angst, and I don't like to
use programs that cause me angst.  This is something that I probably
want to appear in my normal views (with my other events) but that I also
want to be able to check off (complete) when I have done it.

-Joey

Hi,
Maybe this was discussed before, but I think the issue is just about
this too restricted dichotomy between event and task.
For task, there is no problem IMO, it's something to do with a due date.
But event in Sunbird seems to gather several notions : event,
appointment and meeting.
These are really different things and trying to put them in an only word
may confuse people.
IMHO :
- an event is something that happens in a day or several days with no
particular time schedule; like a birthday for instance, or the FOSDEM,
or whatever. We could say that an event lasts a whole day and can be
repeated.
- an appointment or a rendez-vous has a start date and time and no due
time. When I go to an appointment at my doctor's for instance, I only
have to know the day and time to be there, but I've got no precise idea
of when this will end.
- meeting, on the contrary, has start day and time and due time, and
attendants.
Well, maybe I'm only talking about obviousness :) .
I use Lotus Notes at work and maybe it has an influence on me; but I
found these notions really natural and easy to catch.

My two pence

--> task: start date undefined, due date defined

--> event: start date defined, end date defined (meeting, birthday) or
undefined (appointment).

So I think tasks and events can be recognized by start date being
defined or undefined.

As for the airport case I would argue that the start date is not really
undefined (you don't want to go to the airport 3 days in advance...). It
should be treated as an event.

/Sebo

To me events are items that span a certain timeframe. This includes
going to work,
going to the university, the movies. These items are important to see
in a view, to
better plan my time.

A Task is something of higher importance to me. I need to see tasks
extra to know
what I have to fit in the time where I have no events. Therefore, a
Task to me is something
that needs to be done, but dosen't have a set date when to do it.

The other case, which makes things a lot more complicated is a
recurring task. For
example, I have to turn in papers every week at 10am. I have to do this
some time
over the week, again in that time where I have no events. When this
task is done
it should show up again after the due date so I know I need to turn in
my papers
for the next week.

It actually boils down to a Task being something important, that can be
procrastinated
until it is due, and an event being something that has to be
attended/done at a certain
point in time.

I also think there should be a way to convert between these. As Joey
already stated,
there are situations where one becomes the other.

This also sheds some different light on the airport case. If the
airport case would be a
task in my view, then that would mean that I would have to go to the
airport once in a
while to get it done. It might be interesting seeing someone driving to
the airport (10%),
going home again to get something else done (an event), driving back to
the airport,
parking the car (20%), attending a meeting (event), find out what gate
to go to (30%), and
so on. So yes, the airport case is definitly an event.

I use events and tasks intuitivly, I have never heard of someone not
doing so. As long
as they can be converted, you can always decide differently if you feel
that way.

Philipp

Joey Minta escreveu:

But if you create the "Pick up sister at airport" task (to be able to
check it off when it's done), doesn't it appear in the calendar view
together with the other events?

--
  Pedro Lamarão

I don't understand this. To me, it's an event, an appointment. There is
a time associated with it. You don't want to check-off all your meetings
when they are done, right?

Michiel

Another twist that you could add to the airport example:
Let say you want to add an event to your calendar that says "Susie's
Flight Lands at 2pm". In my opinion a flight landing is an event (it
certainly isn't a task, and shouldn't be in your to-do list). However,
it doesn't have a duration, just a time. You could enter this in your
calendar several ways:
1) You could put Susie's entire flight as an event in your calendar and
use the end of the event as the time the flight lands. The disadvantage
here is that you may not care when Susie's flight takes off, and you
may not want your calendar cluttered by Susies 12 hour flight from the
other side of the globe.
2) You could put an event in your calendar that says "Pick up Susie",
but presumably you would want to start driving before the flight lands,
and the event wouldn't end as soon as the flight ends, so you would
have to store the time the flight lands somewhere else.
3) You could put a task in your to-do list that has a due date/time
corresponding to her flight landing, but as I mentioned, this isn't a
task, and shouldn't be in a to-do list.
4) You could put two separate events "Driving to Airport" and "Driving
from Airport", with the landing time the time in between. This just
doesn't seem like a clean way to do it.

Other examples of events with no duration (that may be more relevant to
this crowd): "String Freeze: Midnight Sept. 2" or "Beta Release: Noon
Oct. 2". Presumably these events would have one or several tasks
associated with them, but by themselves they are events.

I don't think you can distinguish an event from a task based on whether
they have a start date or duration. Some tasks may be ongoing projects,
and some events may be instantaneous occurances.
I do like xFallenAngel's suggestion that a task is something you can
partially complete, put aside, then come back to. You can write half a
report, then drive to the airport and back, then finish the report. But
you can't half release a release candidate, and you probably won't half
drive to the airport.

- Ben

I essentially agree with this. Keeping it simple is best. The current
Task or Event creation dialogues handle things pretty well, in terms of
leading users to look at a calender entry as either type. I do think it
would be handy to be able to toggle between the two options. A task
'Organise Meeting' may morph into an event 'Meeting about ....'

Events have a time frame - be it because a movie or meeting has a
defined length. By virtue of this they are generally fixed in time. The
current event creation dialogue is right on in my view.

I'd consider changing the task creation dialogue to allow tasks to have
a length/time frame if the user knows it. That way, in the Airport case,
you could define the task with the due date being the pick-up time, and
use the length of the task to take into account, and show in your
calender view, the half hour it's going to take you to get out there and
back. That way the user can easily look at their calender view and see
how their day is taking shape. Perhaps the 'Todo' (Maybe should be
renamed 'Tasks'?) summary could have a counter with the number of hours
of tasks that the user has to get done? This could perhaps be useful for
people in terms of being able to look at it and get a rough idea of
their workload?

Thinking about the way I use Lightning now, I tend to create all my jobs
as events, when really they should be tasks - by and large I can do them
when I get a chance. But Phillip hits the nail on the head with the case
about recurring tasks. Some things can happen any time before a fixed
deadline, and you may know that it's going to take you and hour and a
half to grade the papers and walk them to where they are handed in, and
allowing tasks to have duration as well as a fixed Due Date would allow
better handling of these cases.

 From this discussion, i see that most events are pretty clear: they
start at some point in time, end end some time later.

Tasks are much more vague: some tasks need to be done at a certain point
in time, but you can actaully do them much earlier. You might know or
might not know how much time they take. It's more open.
Some events have the same: you know that you have a meeting sometime,
but the time isn't defined yet.
Because of this undefinedness, it's hard to show those open events and
tasks in the views. Where should they be drawn? That's why we put them
in a list, instead of in views.
We need to make some decisions, I think. Do we want good ways to deal
with all those cases? Do we want to innovate here?

It's hard to get go-ahead in this area as it comes up fairly firmly
against the problem of different users wanting to use the Event/Task
systems in unique ways to suit their own purposes. On one hand I'm
tempted to suggest that if people can change an Event to a Task and vice
versa then options are open for the user and they will use them as suits
them. However, looking at the Event and Task creation windows they do a
good job of giving a user a sense of how to use the different tools -
Tasks vs. Events. But the same features that allow this clear definition
to be apparent to the user can be restrictive - I'd love to be able to
at the very least create tasks with my guess at their length so I could
look at my 'ToDo' and see the amount of time my tasks are looking like
taking me to do, for example. But the task creation dialogue doesn't
really allow this currently - and I end up creating Events rather than
tasks so I can see them roughly in time in the day/week calendar views.

Events are definitely something that occur over time. And part of the
creating an event dialogue does allow a user to toggle it's Status
between Not specified|Tentative|Confirmed|Cancelled. In a GUI could a
Confirmed event have a bolder border in the view to indicate it's Status?

I could almost see myself arguing for only giving the user one way to
create a calendar entry, replacing the two current options, and within
the dialogue box giving them the means to toggle whether the entry
should appear in a task list, how long it takes/may take, whether it's
confirmed or still unassigned in time, or whether it has a definite
deadline it has to occur by etc etc. Just thinking out loud...

To me, the answer is simple: A task is something that needs to _be
done_, and an event is something that is going to _happen_. Tasks have
the benefit of showing up as nice checkboxes in the Task list, where
you can sort tasks by priority, etc.

Of course, tasks should probably be improved in more fundamental ways
in order
to really get useful. For example, there should be a visual indicator
how close
you are to the deadline, it should be easier to modify the progress
(perhaps a
progress bar embedded in the task list item which you could click in to
modify?), the alarm should be relative to the deadline (Due Date), not
the
start date (Date), and so on.

That's a good point. But if there is a pretty clear distinction, why do
people ask for turning a task into an event? That means that something
that needs to be done turns into something that will happen. Guess that
means that the user will actually do that tasks then.
Maybe if we have a concept of an event with no start/end times set, of a
concept of tasks with a start/end time (and thus show on the view) takes
away the need for the conversion.

Still just thinking... Comments still welcome.

Michiel

I agree. First, tasks are things to do without determined timeframe
(sometimes with a due date), as soon as I plan to do it specifically,
there is the need to convert it into an event. --> determined timeframe.
There is no need to convert it into an event if tasks can behave the
same (show up in the views, in the event list, be ordered correctly in
month view, have alarms, have recurrence patterns, ...).

It would be a bonus feature if a temptative duration could be set in
tasks. This would help in the specific planning of the tasks.

Just as a note: there exists a design page for the task feature. [1]
Maybe this page should be revisited for a deeper discussion.

/Sebo

[1] http://wiki.mozilla.org/Calendar:Task_Support

Aside from the fact that you may simply have chosen the wrong type from
the beginning, a valid reason for changing a task to an event would be
a change of responsibility. For example, maybe you were assigned to
complete a task, and later on the responsibility was moved to someone
else. You still depend on it to be completed, but you don't want it in
your list of things to do.

This leads to a clarification: a task needs some kind of action from
you to be completed, whereas an event will occur whether you do
something about it or not.

This is a good distinction - it defines the two types of calendar
entries well for me
I think this is a step in the right direction - if we keep the options
open for users rather than trying to be too prescriptive, they will use
  lightning as  suits them.

Perhaps only having one way of creating calender entries but allowing a
check box to assign something as a task, so it turns up in the Todo list
and can be ranked and have it's progress tracked would make life easy
for users? And allow them to reassign things as tasks (they have to do
and they may or may not guess at the tasks duration - and it may or may
not have a deadline) or as an event (when, for example, collaboration
with others leads to a meeting (fixed in time) to work on the task?

I think the key is to keep it flexible and provide useful options so
users can easily manage their work flow and schedules/tasks.

---On 2006.Oct.26 01:02 AM, ten...@gmail.com wrote:

the original definition and the clarification are exactly right on
correct, and defined simply enough to move this forward into design.

i would add that workflow can be enourmously complex, and project
management software exists for the hardcore.  taking it too much further
will be distracting, and in fact neverending, so it would be good to set
bounds for where the calendar should stop in this area.

The easiest way to do at least parts of this would be to add UI to set a
start and end time in the task dialog. If those are set, we show the
task in the views, the same way we show events.
This won't solve the events-with-no-known-starttime yet, but i think
that's much less of a problem. And it is easy to workaround: just set
some tentative time, and make a note of it.

Michiel

Would these be instead of, or in addition to, the current start and due
dates?

-Joey

The current startdate can stay, it would add an end date:

Due         [v] [31-10-06   [v]] [23:00    [v]]
Start Date  [ ] [31-10-06   [v]] [21:00    [v]]
End Date    [ ] [31-10-06   [v]] [22:00    [v]]

That way, you can store when a task is due, and when you are planning to
actually do it. I'm still thinking about how to make it one checkbox for
start and end, because i'm not sure what only a start (or end) date means.

Michiel

I use Tasks and events all the time so maybe this might help with
defining the difference between them.
Task: I use tasks for something that is due on a certain date but can be
done before or even a couple of days later (it stays in the "To Do" list
until completed) eg. payment of a bill , I like it to stay in the list
until completed so it reminds you it needs to be done.
Event: I use events for an appointment for eg. an event that has to be
done on a certain time on a certain day, like a lunch appointment,
Birthday etc.
I hope this helps, one thing I would like to see within the "To Do" list
is the tasks are arranged in order of date due and also if it is overdue
the task changes to Red and is at the top of the list.

**

*Andrew Hansen*
Director
*Hansen's Paint Place*
PH: +61 8 9185 1457
FAX: +61 8 9185 3249
MOB: 0419 046 796
and...@hansenspaintplace.com.au <mailto:and...@hansenspaintplace.com.au>
Skype: hansens2

/Motivate them train them care about them and make winners out of them
we know that if we treat our employees correctly they'll treat the
customers right and if customers are treated right they'll come back.
J Marriot, Jr.
/

I tend to like this idea a lot.  There are a couple of detail questions
that would need to be resolved, but I don't think they're terribly
difficult.
-Is any combination of the 3 dates possible?  I would think, like
events, having a startDate would require having and endDate, but I'm not
sure.
-Which times should we use to display tasks in the views?
-The alarm code would need some refactoring, since, in theory, alarms
could be offset from any of the three times. (Note that this is where
the toughest interop problem would be.)

With reasonable solutions to these I'd be behind this idea, but it does
raise an interesting question: Are tasks now a superset of events?  What
properties does an event have that a task does not?

Nice work.

-Joey

On 11/1/06, Joey Minta <jmi...@gmail.com> wrote:

While it may be semantically more meaningful to have an end date on
it, the fact that there aren't error bars or "ranges" in ical (or our
UI!) makes me think that we shouldn't require the user to enter one.
They may well not know exactly when it has to be completed when they
set it up, and forcing them to make up a date doesn't seem like it's
really what we should be doing.

(This is a common complaint about project planning software, too -- at
least, when I'm talking!)

Mike

Sold. :-)

-Joey