Task List/Tree proposal feedback
Joey Minta
Lightning and Sunbird. Accordingly, I've just finished writing up a
proposal for a new 'Task View' that would be used alongside the
Day/Week/(Multiweek)/Month views. The proposal, along with ASCII Art
and questions for feedback can be found on the wiki at:
http://wiki.mozilla.org/Calendar:Task_View Please place feedback here.
Michiel van Leeuwen
The different 'views' made me think of thunderbirds/outlooks 'group by'
function. Why not name it like that, and make it behave like that? You
would get Group By: due date, task, week.
Michiel
Joey Minta
proposal (as modified by mvl's comments), it seems remarkably like the
unifinder. Perhaps we should consider combining the task-list with the
unifinder and simply include a [Events, Tasks, All] menu?
-Joey
Dan Mosedale
I like this idea; it seems less complex (one fewer view), while just as
powerful.
Dan
Clint Talbert
> Joey Minta wrote:
> proposal (as modified by mvl's comments), it seems remarkably like the
> unifinder. Perhaps we should consider combining the task-list with the
> unifinder and simply include a [Events, Tasks, All] menu?
>
Great idea!
Clint
Marcus
More random thoughts. I use the ToDoList quite a bit and would love to
have some of the functionality that provides in Sunbird/Lightning.
http://www.codeproject.com/tools/ToDoList2.asp
I find the hierarchical input brilliant. In fact I just realised I use
quite a bit of the functionality, priority and risk, colouring,
categories, status, cost etc.
I think you guys might be able to glean some ideas from this.
Regards,
Marcus
P.s.
Is there a formal way for making suggestions?
Dan Mosedale
> http://www.codeproject.com/tools/ToDoList2.asp
>
> I find the hierarchical input brilliant. In fact I just realised I use
> quite a bit of the functionality, priority and risk, colouring,
> categories, status, cost etc.
>
> I think you guys might be able to glean some ideas from this.
Thanks for the input; that does look interesting.
> Is there a formal way for making suggestions?
For very general input sources like this, this newsgroup is a reasonable
way. For anything more specific, filing a bug on bugzilla.mozilla.org
with a severity of 'Enhancement' is probably better.
Dan
Mike Beltzner
The UI looks good to me, Joey. Some comments:
- Recently completed sounds like something that would be useful when
you're viewing someone else's calendar as opposed to your own. I think
the view menu option controlling
- The recurring event display UI is going to be hard. "Infinitely
more" might be pretty confusing. Perhaps use "Recurring event",
instead? It might even be useful to have a "< Previous 5 | Next 5 >"
style selector for these infinite events as well as for large groups.
- The "Percent Complete" thing is a load of hooey. Who takes out 50%
of their garbage and then updates their calendar? Who can actually
evaluate what percentage of their task they've completed? I'd suggest
this column not be shown by default, or it be replaced by something
far more lightweight like: "Not Started / Started / Almost Finished".
- I really think the toolkit needs a search builder UI since there
are a lot of apps that need to provide custom views which are built up
from many criteria. In the absence of this, I agree that we'd need a
custom view, and a way to save custom views so that the user can
easily get back to them (if, say, they want to see all the entries for
this month that are part of these two calendars, etc).
cheers,
mike
--
/ mike beltzner / user experience lead / mozilla corporation /
Joey Minta
> On 4/18/06, Joey Minta <jmi...@gmail.com> wrote:
>> I've recently turned my attention to improving support for tasks in both
>> Lightning and Sunbird. Accordingly, I've just finished writing up a
>> proposal for a new 'Task View' that would be used alongside the
>> Day/Week/(Multiweek)/Month views. The proposal, along with ASCII Art
>> and questions for feedback can be found on the wiki at:
>> http://wiki.mozilla.org/Calendar:Task_View Please place feedback here.
>
> The UI looks good to me, Joey. Some comments:
>
> - Recently completed sounds like something that would be useful when
> you're viewing someone else's calendar as opposed to your own.
checkbox model where checking off a task makes it immediately disappear,
making it more difficult to correct mistakes. As we don't have a clear
calendar-ownership idea, was this a suggestion to not use Recently
Completed or to include it?
I think
> the view menu option controlling
>
> - The recurring event display UI is going to be hard. "Infinitely
> more" might be pretty confusing. Perhaps use "Recurring event",
> instead? It might even be useful to have a "< Previous 5 | Next 5 >"
> style selector for these infinite events as well as for large groups.
Interesting idea! I like it. :-)
>
> - The "Percent Complete" thing is a load of hooey. Who takes out 50%
> of their garbage and then updates their calendar? Who can actually
> evaluate what percentage of their task they've completed? I'd suggest
> this column not be shown by default, or it be replaced by something
> far more lightweight like: "Not Started / Started / Almost Finished".
Sold.
>
> - I really think the toolkit needs a search builder UI since there
> are a lot of apps that need to provide custom views which are built up
> from many criteria. In the absence of this, I agree that we'd need a
> custom view, and a way to save custom views so that the user can
> easily get back to them (if, say, they want to see all the entries for
> this month that are part of these two calendars, etc).
I completely agree. Were you suggesting that the search-builder be
integrated into this view? It's easy to do a light-weight search a la
Thunderbird's quick-find, but a full-fledged search builder seems like
it would be a separate task that might better coincide with
calendar-creation/display rather than view display. (current Calendars
are effectively searches based on the Calendar field)
I'd like to move forward on this, but my biggest question at this point
is where I stand on mvl's 'Group By Sort' suggestion, versus these fixed
views I initially proposed. Group By Sort would allow the planning view
to be easily created (without the Recently Completed group) by simply
sorting based on Due Date. In this way, I think we'd have Group by:
None, Sort, Sub-Tasks, Recurrence as options. We'd lose the
1-week/1-month views in favor of grouping much like Thunderbird's mail
grouping ("Last Week", "Today", "Tomorrow", "This week"). This would
encroach on the agenda view too, but would be pretty powerful. Thoughts?
Joey Minta
> ...The proposal, along with ASCII Art
> and questions for feedback can be found on the wiki at:
> http://wiki.mozilla.org/Calendar:Task_View Please place feedback here.
thing to start sorting out for 0.3. That way we can get some feedback
on how well we actually match with users' mental models.
-Joey
Stephan Schaefer
I really would like to see a solution similar to your proposal. As a
first step I would appreciate if the recently introduced display of
tasks in the views could be reverted. It is inconsistent as only some
tasks appear and makes the views unreadable if you have many tasks.
A separate task view, as you proposed, is the way to go. There have been
comments in this thread to put everything into the unifinder and avoid
an additional view. Again, this will have a an impact on readability so
I would prefer a full task view that is able to display all important
task details at once.
I only see a problem in the hierarchical approach. Is this something
that can be safely exported ? Does e.g., ics support groups or
hierarchies of todo's ?
Stephan
Stefan Sitter
> display of tasks in the views could be reverted. It is
> inconsistent as only some tasks appear and makes the views
> unreadable if you have many tasks.
You can do that yourself:
In Lightning 0.1+:
Deselect 'Calendar -> View -> Tasks in View' menu option
In Sunbird:
Deselect 'View -> Tasks in View' menu option
/Stefan
Clint Talbert
I like these designs.
How would these handle the "unscheduled" task? One without a start date
or a due date? Is that the "Never Scheduled" bucket? If so, I'm not
certain that's an intuitive name for it. Perhaps "Unscheduled" would be
better?
As far as the task/subtask problem goes, it would be really awesome if
we enabled drag/drop on these and the user could visually drag and drop
tasks to create the task/subtask arrangement.
I don't think that "Recently Completed" would be a useful bucket.
As far as showing recurring tasks, I would treat them in the same manner
that we treat infinitely recurring events. Is there a problem in doing that?
Where are you thinking of putting this in the overall UI? In the same
place as the current task window? Have you thought about allowing the
user to undock the task window? That might allow you more realestate for
the calendar view, especially if the new task window is wider than the
old one (and it appears it will be).
As far as the tasks-in-calendar-view issue, (which is entirely
separate), I think that it is useful to have the tasks in the calendar
view (which is why we have that preference). But, the tasks should show
up in the "all day" section of the view, not as giant events from 12AM
to 12PM.
Clint
Joey Minta
> Joey Minta wrote:
>> Joey Minta wrote:
>>> ...The proposal, along with ASCII Art
>>> and questions for feedback can be found on the wiki at:
>>> http://wiki.mozilla.org/Calendar:Task_View Please place feedback here.
>> Bump. Be nice to get some traction on this, since tasks would be a
>> good thing to start sorting out for 0.3. That way we can get some
>> feedback on how well we actually match with users' mental models.
>
> I really would like to see a solution similar to your proposal. As a
> first step I would appreciate if the recently introduced display of
> tasks in the views could be reverted. It is inconsistent as only some
> tasks appear and makes the views unreadable if you have many tasks.
that I'm eventually going to have to spend time on. When I do allocate
time for them, by giving them a start and end time, I would definitely
expect them to show up in the views. As ssitter mentioned, we've
already devoted a high-level menu to turning this off if it bothers you
that much.
>
> A separate task view, as you proposed, is the way to go. There have been
> comments in this thread to put everything into the unifinder and avoid
> an additional view. Again, this will have a an impact on readability so
> I would prefer a full task view that is able to display all important
> task details at once.
I think this point gets down to some of the more fundamental questions
regarding task semantics. At Toronto it was suggested that perhaps we
want to do more to unify tasks and events, rather than forcing users to
work in this dichotomy. (Is 'go for a run' a task or an event? Are
scheduled tasks just events that used to be tasks? etc) The idea I was
working with here was exploring one such way of unifying them. The
logic works something like:
All other views merge tasks and events.
This would be a list-view.
This view should merge tasks and events.
Under this model, I'd be in favor of turning the current, non-view, task
list into an 'Unscheduled items' box.
> I only see a problem in the hierarchical approach. Is this something
> that can be safely exported ? Does e.g., ics support groups or
> hierarchies of todo's ?
Kinda. They tried to support this with the RELATED-TO property, but
it's so badly spec'd that we're going to have to do a lot of "what did
they mean here" in the process of handling hierarchical tasks.
-Joey
Joey Minta
> I like these designs.
> How would these handle the "unscheduled" task? One without a start date
> or a due date? Is that the "Never Scheduled" bucket? If so, I'm not
> certain that's an intuitive name for it. Perhaps "Unscheduled" would be
> better?
>
> As far as the task/subtask problem goes, it would be really awesome if
> we enabled drag/drop on these and the user could visually drag and drop
> tasks to create the task/subtask arrangement.
The problem is that it's really easy to get into a situation where we
overload drag-n-drop to the point of being unusable. Imagine a layout like
[-] Today
Walk the dog
[-] Tomorrow
Feed the cat.
Dragging "Feed the cat" on top of "Walk the dog" might mean I want to
move this task to today (normal dnd moves times), but it might mean I
want to make "Feed the cat" a subtask of "Walk the dog." More and more,
I'm thinking the hierarchical tasks might be a good thing to leave for
extension experimentation.
>
> I don't think that "Recently Completed" would be a useful bucket.
This was to address a concern about working in the Sunbird model with a
'Hide Completed' checkbox. In that case, marking a task complete makes
it completely disappear. Imagine misclicking and marking the wrong task
complete. Now you have to go through all your tasks and find the one
that just disappear. In the new view, it would easily be found in the
subset of your completed tasks, the recently completed ones.
>
> As far as showing recurring tasks, I would treat them in the same manner
> that we treat infinitely recurring events. Is there a problem in doing that?
There is a problem in that we're not always showing defined date ranges
with this list. In every other view, we show occurrences. This would
be the one place where we show parent items only. I don't think that's
a semantic model the user should have to deal with.
>
> Where are you thinking of putting this in the overall UI? In the same
> place as the current task window? Have you thought about allowing the
> user to undock the task window? That might allow you more realestate for
> the calendar view, especially if the new task window is wider than the
> old one (and it appears it will be).
See my recent post to ssa. I'm thinking this should be an additional
view and that the current location of the task list should be used for
unscheduled items. (Currently it's impossible to create an unscheduled
event, but I'd like to eventually fix that.)
Docking scares me. Many times I've accidentally undocked a toolbar in
Writer or Word and can never figure out how to get it back the way it was.
>
> As far as the tasks-in-calendar-view issue, (which is entirely
> separate), I think that it is useful to have the tasks in the calendar
> view (which is why we have that preference). But, the tasks should show
> up in the "all day" section of the view, not as giant events from 12AM
> to 12PM.
I think that's a good place for tasks with only a start or only a due
date. But tasks that have specific start and end I think should be
shown in the normal grid.
-Joey
Stephan Schaefer
> Stephan Schaefer wrote:
>> Joey Minta wrote:
>>> Joey Minta wrote:
>>>> ...The proposal, along with ASCII Art
>>>> and questions for feedback can be found on the wiki at:
>>>> http://wiki.mozilla.org/Calendar:Task_View Please place feedback here.
>>> Bump. Be nice to get some traction on this, since tasks would be a
>>> good thing to start sorting out for 0.3. That way we can get some
>>> feedback on how well we actually match with users' mental models.
>>
>> I really would like to see a solution similar to your proposal. As a
>> first step I would appreciate if the recently introduced display of
>> tasks in the views could be reverted. It is inconsistent as only some
>> tasks appear and makes the views unreadable if you have many tasks.
> My intuition regarding task lists is that they serve as lists of things
> that I'm eventually going to have to spend time on. When I do allocate
> time for them, by giving them a start and end time, I would definitely
> expect them to show up in the views. As ssitter mentioned, we've
> already devoted a high-level menu to turning this off if it bothers you
> that much.
>
Introducing this option documents that we are not sure if this feature
is useful or not. And as people typically do not change defaults as
surveys have shown they currently have to live with a default that
brings a lot of inconsistencies. The reasoning you gave above is not
obvious, instead, the user will not understand why certain tasks appear
while other tasks do not. If my task has a due date but no start date I
could expect to see it in the view always until the due date is reached.
If my task has a start date but no due date it could also appear.
A clean and obvious approach is to not show tasks in the calendar views
at all (regardless of any specific task properties) but to put all tasks
in a separate task view. That's the ToDo-List people understand and are
used to and it avoids introducing a new option that promises something
it doesn't keep (in fact the menu item should read 'Show *some* tasks in
view').
People importing their tasks from other calendar sources (iCal, Outlook,
Sun Calendar Server) would also appreciate if their calendar views were
not suddenly cluttered with tasks which none of those apps do - for good
reason I think, as many compromises have to be made.
In fact I cannot understand why this decision has been made without any
kind of public discussion. This is certainly a prominent UI change and
we all agreed on a UI review process - why hasn't it been applied here,
or did I just miss it ?
>
>> I only see a problem in the hierarchical approach. Is this something
>> that can be safely exported ? Does e.g., ics support groups or
>> hierarchies of todo's ?
> Kinda. They tried to support this with the RELATED-TO property, but
> it's so badly spec'd that we're going to have to do a lot of "what did
> they mean here" in the process of handling hierarchical tasks.
>
If you think of interoperability you have to stick to the same
interpretation like other applications. If eg a provider cannot perform
a safe roundtrip with your data due to a different model on the backend
this feature becomes unusable. So I would not start working on the
hierarchies if it is not clear that they can be represented at all.
Stephan
Clint Talbert
>>
>> Where are you thinking of putting this in the overall UI? In the same
>> place as the current task window? Have you thought about allowing the
>> user to undock the task window? That might allow you more realestate for
>> the calendar view, especially if the new task window is wider than the
>> old one (and it appears it will be).
> See my recent post to ssa. I'm thinking this should be an additional
> view and that the current location of the task list should be used for
> unscheduled items. (Currently it's impossible to create an unscheduled
> event, but I'd like to eventually fix that.)
Somehow, I missed that part of the proposal. I would be all for a
separate view for tasks.
>
> Docking scares me. Many times I've accidentally undocked a toolbar in
> Writer or Word and can never figure out how to get it back the way it was.
>
recently changed my mind is MSoft's C++ Visual Studio 2005 Express
Edition. You can download it for free from their site. They have several
small dockable windows in the gui and you can experiment with moving
them around. It's the first truly "somewhat easy to use" dockable
interface I've seen. It's got its own set of issues but it's far better
than anything I've seen to date.
As far as XUL goes, Venkman does a really decent job of dockable windows
too, although I think MSoft's UI is a bit more usable.
Anyhow, I'm not saying we need to emulate either of these behaviors,
just that they demonstrate the power, the usability and the pitfalls of
a dockable solution.
>>
>> As far as the tasks-in-calendar-view issue, (which is entirely
>> separate), I think that it is useful to have the tasks in the calendar
>> view (which is why we have that preference). But, the tasks should show
>> up in the "all day" section of the view, not as giant events from 12AM
>> to 12PM.
> I think that's a good place for tasks with only a start or only a due
> date. But tasks that have specific start and end I think should be
> shown in the normal grid.
How will you then deal with the tasks so that they do not take up the
entire day in your day view? Perhaps place the task at its start time in
a thirty minute window box, and have that box repeat once a day until
the deadline which would be indicated by a box at the due date time?
Clint
Joey Minta
> Introducing this option documents that we are not sure if this feature
> is useful or not. And as people typically do not change defaults as
> surveys have shown they currently have to live with a default that
> brings a lot of inconsistencies. The reasoning you gave above is not
> obvious, instead, the user will not understand why certain tasks appear
> while other tasks do not.
part of their schedule and others wish to manage them separately. I
want to stress that the only tasks that should not appear in the views
are those for which no date information (start or end) is available.
If other tasks are not shown, this would be a bug in my mind. Having
users realize "This task isn't shown in a date-specific view because it
doesn't have any date" doesn't seem too much to ask at all.
There's also a very large gap between "typically do not change" and
"have to live with" that I don't think is reasonable to conflate here.
> If my task has a due date but no start date I
> could expect to see it in the view always until the due date is reached.
> If my task has a start date but no due date it could also appear.
I agree. I think these are definitely improvements to this that we
should consider.
> A clean and obvious approach is to not show tasks in the calendar views
> at all (regardless of any specific task properties) but to put all tasks
> in a separate task view. That's the ToDo-List people understand and are
> used to and it avoids introducing a new option that promises something
> it doesn't keep (in fact the menu item should read 'Show *some* tasks in
> view').
I disagree. This feature has existed in Sunbird since 0.2, and rather
than receive complaints about how hard it is, we received one of the
largest numbers of votes for this to be implemented in the other views
as well.
>
> People importing their tasks from other calendar sources (iCal, Outlook,
> Sun Calendar Server) would also appreciate if their calendar views were
> not suddenly cluttered with tasks which none of those apps do - for good
> reason I think, as many compromises have to be made.
I really don't understand what "compromises" have to be made here. You
have to check one highly visible menuitem.
>
> In fact I cannot understand why this decision has been made without any
> kind of public discussion. This is certainly a prominent UI change and
> we all agreed on a UI review process - why hasn't it been applied here,
> or did I just miss it ?
There are a couple of points to be made here.
1.) I landed this under the heading of "bring lightning up to
functional parity with sunbird." When people began pushing for this, I
was under the impression that they thought these additional functions
were all good ideas. I didn't realize that we needed to audit all of
these to "bring lightning up to functional parity with sunbird except
where people object."
2.) The patch was on the bug for over 2 months without a single
objection.
3.) The patch was reviewed by shaver with the blessing of dmose. It
was my impression that dmose, being one of the UI owners, would not
have let such a review happen if he had UI concerns about it.
> If you think of interoperability you have to stick to the same
> interpretation like other applications. If eg a provider cannot perform
> a safe roundtrip with your data due to a different model on the backend
> this feature becomes unusable.
Isn't that a bug in the provider? The caldav provider can't currently
roundtrip modified occurrences, but we haven't yanked that feature.
The spec does define how the RELATED-TO property should work, but it
has certain shortcomings that I've realized in trying to implement it.
As long as we're not explicitly violating the spec, I don't see any
problem with extending it to cover a use case that we feel is
important. Perhaps some examples are in order here:
BEGIN:VTODO
UID:19970901T13...@host.com
DTSTAMP:19970901T1300Z
DTSTART:19970415T133000Z
DUE:19970416T045959Z
SUMMARY:1996 Income Tax Preparation
CLASS:CONFIDENTIAL
CATEGORIES:FAMILY,FINANCE
PRIORITY:1
STATUS:NEEDS-ACTION
RELATED-TO;RELTYPE=CHILD:<19960401-0800...@host.com>
END:VTODO
is a subtask that is perfectly well defined under the spec. Where the
spec fails in my mind, is specifying subtasks of particular instances
of repeating tasks, since these cannot be identified strictly by UID.
This shortcoming is currently the only extension I would want to see to
the spec, and could easily be done with an X-PARAM which would degrade
in a fairly graceful manner in other applications:
RELATED-TO;RELTYPE=CHILD;X-MOZ-RID=recid12345:<19960401-0800...@host.com>
other apps can disregard the X-MOZ-RID param and still preserve the
majority of the user's intent.
> So I would not start working on the
> hierarchies if it is not clear that they can be represented at all.
I think it's clear that they can be represented, and for the most part
within the spec.
-Joey
Joey Minta
> By different view, you mean on the same level as "Day", "Week", etc?
> Somehow, I missed that part of the proposal. I would be all for a
> separate view for tasks.
think that's a good idea though.
> How will you then deal with the tasks so that they do not take up the
> entire day in your day view? Perhaps place the task at its start time in
> a thirty minute window box, and have that box repeat once a day until
> the deadline which would be indicated by a box at the due date time?
I feel like I'm misunderstanding the question. If a task starts at 9:30
and ends at 10:30, it should take up an hour. If it starts at midnight
and ends at midnight it should take up the whole day. Basically, for
tasks that have both a start and due date, we should treat those exactly
like an event with a start and end. If someone schedules a task in that
way, isn't the implication that they actually do want it to span the
whole day?
If the task has an allday flag set, it should be treated just like an
event with the same flag.
If an event just has a start or due time, then I think we should dump it
in the all-day event box, but include the time as info up there.
What am I misunderstanding?
-Joey
Mike Shaver
> 3.) The patch was reviewed by shaver with the blessing of dmose. It
> was my impression that dmose, being one of the UI owners, would not
> have let such a review happen if he had UI concerns about it.
I might well have been in error here, since I was not aware of the UI
process agreement when I conducted that review. If so, I apologize
sincerely for any confusion here, and also totally blame dmose for
everything.
More seriously, it's probably to be expected that work that "spans"
the introduction or ratification of new policy things like the UI
review process will cause a bit of bumpiness. Where the review was
conducted before something came into effect, and the commit happens
afterwards, it's easy for people to have different impressions of the
state of things.
So my grovelling and excuse-making aside, it would be interesting to
know more about the use of tasks with different providers, or if there
are heuristics (such as having > N tasks in a given day, or coming
from a given provider) which would let us use an alternate display
mode or suppress entirely, to better match the user's expectations.
Stephan: can you get aggregate stats from Sun calendar users or
another such audience about numbers of tasks and the like?
(I recommend taking the hierarchy discussion to another thread; if
history is any guide, it will be a loooooong one.)
Mike
Mike
Michiel van Leeuwen
> If it starts at midnight
> and ends at midnight it should take up the whole day. Basically, for
> tasks that have both a start and due date, we should treat those exactly
> like an event with a start and end. If someone schedules a task in that
> way, isn't the implication that they actually do want it to span the
> whole day?
It might not be. How do you say: "i want to do this task next wednesday.
doesn't really matter when, just as long as i do it. I think it takes
about an hour to do it"?
> What am I misunderstanding?
Tasks are not simple. We don't really know how to make it work right. It
needs a lot more research.
Michiel
Cédric Corazza
> Joey Minta wrote:
>> If it starts at midnight and ends at midnight it should take up the
>> whole day. Basically, for tasks that have both a start and due date,
>> we should treat those exactly like an event with a start and end. If
>> someone schedules a task in that way, isn't the implication that they
>> actually do want it to span the whole day?
specific day but at lesat, before the end of it or the day before, that
depends.
> It might not be. How do you say: "i want to do this task next wednesday.
> doesn't really matter when, just as long as i do it. I think it takes
> about an hour to do it"?
I know you (the team) have targeted Sunbird / Lightning to SME employees
and students at Toronto meeting, but the needs for larger organizations
are quite the same, the only difference is the people involved are much
numerous. The only thing 'repellant' for the moment is that we want to
post appointments, re-schedule them, invite people to it and make it
repetitive if needed, make people able to refuse and propose other
schedule, have a graphical planning of people available and not, and so
on. Well, I'm working in an organization which hires 7000 people, and we
currently used Lotus Notes.
But that's not the subject of this post; a task has only a start date
and a due date, not a forecast duration. For this kind of thing, you'll
have to deal with project planner (forgive my bad English :) ) as MS
Project or whatever FOSS or proprietary software. In my professionnal
experience, a task is something to accomplish before the due date,
whatever the time it takes. Time and resources are not handled by the
Calendar software.
My two pence.
Cédric
Simon Paquet
>So my grovelling and excuse-making aside, it would be interesting to
>know more about the use of tasks with different providers, or if there
>are heuristics (such as having > N tasks in a given day, or coming
>from a given provider) which would let us use an alternate display
>mode or suppress entirely, to better match the user's expectations.
I don't have any statistical relevant data, but in my company (big audit
firm, Outlook-based) especially the partners and the managers use the
task feature a lot and most of them have between 20-40 active tasks at
any time together with hundreds of old tasks, which are archived every 30
days (Outlook-default IIRC).
The lower-level staff members seem to not use the tasks feature so often.
Some of them don't use it at all and most of them only have between 2-5
active tasks at any time in Outlook.
For the first group, the "tasks in view"-feature would be a total
'No-Go'. The second group would perhaps accept it, even though most of
them would probably be somewhat confused, because it is a totally
different concept.
Simon
--
Sunbird/Lightning/Calendar Website Maintainer:
http://www.mozilla.org/projects/calendar
Sunbird/Calendar blog: http://weblogs.mozillazine.org/calendar
Stephan Schaefer
> Stephan Schaefer wrote:
>> Introducing this option documents that we are not sure if this feature
>> is useful or not. And as people typically do not change defaults as
>> surveys have shown they currently have to live with a default that
>> brings a lot of inconsistencies. The reasoning you gave above is not
>> obvious, instead, the user will not understand why certain tasks appear
>> while other tasks do not.
> I disagree. It means that we recognize that some people feel tasks are
> part of their schedule and others wish to manage them separately. I
> want to stress that the only tasks that should not appear in the views
> are those for which no date information (start or end) is available.
> If other tasks are not shown, this would be a bug in my mind. Having
> users realize "This task isn't shown in a date-specific view because it
> doesn't have any date" doesn't seem too much to ask at all.
>
I fully understand what you want to achieve and I understand the
algorithm behind it. But this approach has several drawbacks which have
to be sorted out before prematurely enabling an uncommon feature.
- There is not the smallest hint in the UI that explains why some tasks
appear in the calendar grid while others do not.
- You are introducing a third data object that is not used or referred
to in the UI or anywhere else: tasks with start and end date (besides
events and 'general' tasks)
- A new option defaults to an advanced setting instead of making the
common and indisputable setting the standard.
> There's also a very large gap between "typically do not change" and
> "have to live with" that I don't think is reasonable to conflate here.
I see it as the obvious consequence, not as a gap.
>> If my task has a due date but no start date I
>> could expect to see it in the view always until the due date is reached.
>> If my task has a start date but no due date it could also appear.
> I agree. I think these are definitely improvements to this that we
> should consider.
Sorry for this misunderstanding, I should have made it more obvious that
those suggestions were meant ironically. Of course following those would
render the calendar views totally useless.
>> A clean and obvious approach is to not show tasks in the calendar views
>> at all (regardless of any specific task properties) but to put all tasks
>> in a separate task view. That's the ToDo-List people understand and are
>> used to and it avoids introducing a new option that promises something
>> it doesn't keep (in fact the menu item should read 'Show *some* tasks in
>> view').
> I disagree. This feature has existed in Sunbird since 0.2, and rather
> than receive complaints about how hard it is, we received one of the
> largest numbers of votes for this to be implemented in the other views
> as well.
>
Just because a feature existed in previous versions does not
automatically justify it for all time. And even votes require that
features are thoroughly designed especially regarding usability.
>> People importing their tasks from other calendar sources (iCal, Outlook,
>> Sun Calendar Server) would also appreciate if their calendar views were
>> not suddenly cluttered with tasks which none of those apps do - for good
>> reason I think, as many compromises have to be made.
> I really don't understand what "compromises" have to be made here. You
> have to check one highly visible menuitem.
>
I meant the compromises that have to be made if tasks are displayed in
views. The fact that you have to deal transparently with three
optional(!) time stamps (start/due/completion) and arbitrary
combinations thereof which you can never get right leads to compromises.
For instance the compromise of only displaying some tasks as currently
done by Lightning. The designers of the other applications just avoided
those compromises by introducing a separate task view.
>> In fact I cannot understand why this decision has been made without any
>> kind of public discussion. This is certainly a prominent UI change and
>> we all agreed on a UI review process - why hasn't it been applied here,
>> or did I just miss it ?
> There are a couple of points to be made here.
I know that the UI review process is quite new. Nevertheless it would be
nice (even without adhering to processes) to inform people of upcoming
bigger UI changes - not everybody is aware of every bug status.
>> If you think of interoperability you have to stick to the same
>> interpretation like other applications. If eg a provider cannot perform
>> a safe roundtrip with your data due to a different model on the backend
>> this feature becomes unusable.
> Isn't that a bug in the provider?
May be. But the fact that no calendar application can deal with
hierarchical tasks today makes me a little bit nervous. If your exported
hierarchies are flattened out when you access them with the web client
of the given server (eg, Outlook Web Access, Sun JS Calendar Express)
wouldn't you call this data-loss ?
> The caldav provider can't currently
> roundtrip modified occurrences, but we haven't yanked that feature.
Because it is well defined and available in every mature calendar
application. But hierarchical tasks are apparently not.
Stephan
Stephan Schaefer
> On 21 Jul 2006 10:52:45 -0700, Joey Minta <jmi...@gmail.com> wrote:
>> 3.) The patch was reviewed by shaver with the blessing of dmose. It
>> was my impression that dmose, being one of the UI owners, would not
>> have let such a review happen if he had UI concerns about it.
>
> I might well have been in error here, since I was not aware of the UI
> process agreement when I conducted that review. If so, I apologize
> sincerely for any confusion here, and also totally blame dmose for
> everything.
>
> More seriously, it's probably to be expected that work that "spans"
> the introduction or ratification of new policy things like the UI
> review process will cause a bit of bumpiness. Where the review was
> conducted before something came into effect, and the commit happens
> afterwards, it's easy for people to have different impressions of the
> state of things.
Sure, this overlap explains why the UI process could not be fully
applied here. However, since we all agreed on it, and this change
appeared shortly thereafter, I would like to see some statements from
the reviewers/UI owners. Apparently not everybody agrees with this UI
change and regarding user feedback, I only saw people complaining about
it since the first day it appeared in the views. So if the reviewers
overlooked the impact this decision had they might consider to do
another review. If they still fully agree with their decision I would
like to hear their opinion.
Unless there is a clear concept regarding the display of tasks I
strongly recommend removing this code again.
> So my grovelling and excuse-making aside, it would be interesting to
> know more about the use of tasks with different providers, or if there
> are heuristics (such as having > N tasks in a given day, or coming
> from a given provider) which would let us use an alternate display
> mode or suppress entirely, to better match the user's expectations.
>
The fact that none of the big calendar apps displays tasks in the
calendar grid is a clear indicator that you just have no choice here.
People migrating from those apps will be confused because you display
their data in a fundamentally different way than before. And because
only some of their tasks appear their first impression can only be that
not all data could be imported. Or in other words, they suppose data
loss, which is not the best impression shortly after migration.
> Stephan: can you get aggregate stats from Sun calendar users or
> another such audience about numbers of tasks and the like?
I will try to get some information regarding task handling. But because
tasks have more optional parameters than events their usage is probably
quite manifold. The (hypothetical) fact that many people do not use a
due date or that they fill in a completion date should not lead to a
special task handling that differs from everything those people are used
to. I think there are other areas where we can be innovative.
Stephan