We've been working through these very issues with Darshana for the
command-line-for-dummies quick item entry UI.
Darshana, could you chime in about how we're figuring out what's a
task versus an event?
I believe that only dates/times with duration are events, unless the
user specifically says it's an event. So it's in-line with what
you're describing below.
Mimi
On Sep 13, 2006, at 1:14 PM, Brian Kirsch wrote:
Hello,
Actually I am amending my Chandler Task IMAP folder to Chandler
Task suggestion.
Since Tasks in Chandler now have an alarm setting, if the Mail
Message contains a due date a custom alarm will be set when the
IMAP mail message is downloaded and stamped as Task in Chandler.
If the Mail message contains start and end dates etc. it should be
stamped as an Event and not a Task i.e. placed in the Chandler
Event folder on the IMAP server instead of the Chandler Task folder.
If the user places a Mail message with start and end info in the
Chandler Task folder I am open to suggestions as what to do. When
downloading to Chandler we could display a warning dialog such as
"This Task contains start and end date information would you like
to add it to your Calendar?" or simple ignore the date info and
just stamp it as a Task.
-Brian
Brian Kirsch wrote:
Hi Oren and Mimi,
I think the suggestion of creating custom folder names is a good
one. But will probably be differed for 1.0 since it is not mission
critical. If we use folder names such as 'Chandler Tasks' and
'Chandler Events' the odds of someone already having a folder with
that name are incredibly slim.
You bring up a good point regarding stamping and Item types. Some
tasks do have date information in them. In this case they are both
a Chandler Task and a Chandler Event.
My initial thought is when a mail message is dropped in to the
Chandler Task folder and downloaded, Chandler parses the text for
date / time information and if found stamps the Item as both a
Task and a Event. FYI, the Item is already stamped as a
Mail Message.
See the rest of my comments in line.
Oren Sreebny wrote:
Off the top of my head, I think I'd put them all in Chandler -
they tend to be just check-off type of task lists, though
sometimes they have due dates associated in them. I'm not smart
or sophisticated enough to keep multiple task lists in multiple
places :)
- Oren
On Sep 11, 2006, at 12:02 PM, Mimi Yin wrote:
Hi Oren,
Can I ask, are the things you put in your mytasks folder today
the sort of things you would want to put into Chandler? Or would
you prefer to keep those 2 things separate? If so, could you
provide some examples of tasks you would want in 1 folder, but
not the other?
On Sep 11, 2006, at 11:16 AM, Oren Sreebny wrote:
Hi, Mimi and all -
That sounds like a good workable plan to me, and one that would
certainly work for higher ed folks, who have imap deployed widely.
At some point it would probably be good to let the user choose
an imap folder name for each of these three purposes - for
instance, if I already have a folder named "mytasks", I
probably would want to just tell Chandler to use that for
messages to go into the Task Dashboard. Not necessary for an
initial implementation probably.
Is this just a one time transfer of messages from IMAP to
chandler, or is some sort of sync implied? For instance, what
happens if I put a message in my Chandler Tasks imap folder, it
gets imported to Chandler, and then I delete it on the IMAP
server?
It would still be in Chandler. We're pulling stuff down, but not
trying to keep the IMAP folder and the Chandler collection in
sync. Is that right BrianK?
Yes that is correct! We do not maintain sync between the IMAP
server and Chandler. The IMAP protocol and the feature sets in
Chandler just do not map well and if we truly support IMAP it
would put such large limitations on Mail in Chandler that we would
end up being just another IMAP Mail Client app.
For example, it would be really weird if a Mail item in Chandler
that I stamped as a calendar event and added to three different
collections suddenly disappeared because the original mail message
on the IMAP Server was deleted.
-Brian
Forgive me if that's already addressed in the document and I
just haven't read it closely enough
Cheers -
- Oren
On Sep 8, 2006, at 9:46 AM, Mimi Yin wrote:
We are continuing to figure out our email plan. Here was the
last, most complete summary (from Sheila) of the various
'Email - Bridging the Gap' options we have available to us:
http://lists.osafoundation.org/pipermail/design/2006-August/
005225.html
The two candidates at the top of our list is subscribing to
IMAP folders and implementing special Chandler headers so that
Chandler clients can communicate with each other directly,
without forcing users to pull down all the email in their Inbox.
Brian Kirsch has proposed a stop-gap measure for IMAP folders,
which is perhaps even better than allowing users to pull down
arbitrary IMAP folders.
When users fill out IMAP account information, we provide them
with an option to set up special "Chandler IMAP folders" that
allow them to not only add messages from their email clients
into Chandler, but also to specify whether they want the
message to be added to the Task list or Calendar. (All
messages are automatically added to Mail.) (The option should
probably be checked by default, with a [Configure] button that
allows the user to choose which of the 3 folders they want.)
The 3 folders would be:
+ Chandler Mail: Messages in this folder are added to the Mail
Dashboard
+ Chandler Tasks: Messages in this folder are added to the
Task Dashboard
+ Chander Calendar: Messages in this folder are added to the
Calendar Dashboard
This of course, doesn't allow users to add the same message to
both the Task list or Calendar. But it's a huge improvement to
not being able to specify a context at all.
For mock-ups, see: http://wiki.osafoundation.org/bin/view/
Journal/UnifiedDataInAndOutProposal#CommentsSection
Brian also raised the excellent question of: will our target
users have IMAP accounts? How widely deployed is IMAP amongst
small workgroups with scarce IT resources?
Thx,
Mimi
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design
--
Brian Kirsch Internationalization Architect / Mail Service Engineer
Open Source Applications Foundation
543 Howard Street 5th Floor
San Francisco, CA 94105
http://www.osafoundation.org
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design
