为什么不能合到一起？
最近两周一直在纠结一个问题，夜不能寐，连上厕所都在想：
1、OUTLOOK里有日历、任务两个独立功能，为什么非得分开不能合并到一起？ 微软是怎么考虑的？
2、Google原先有文档、记事本，后来把记事本给关掉了。但很快，在我看来非常类似的事情，Google又反着做了一次：原来有个日历，是独立于gmail的产品，现在又再Gmail里加了个“任务”。
为什么？ Google是怎么考虑的？
3、同样，Mac有独立的产品“日历”，但在mail里还有个功能“待处理事项” 。 Apple是怎么考虑两者关系的？
4、在一个衣柜里可以放完的前提下。
有一堆Tee和牛仔裤，有N套西装领带。 是应该搞两个衣柜，还是应该在一个衣柜里分开两个区域？
有一堆Tee和一堆休闲衬衣，是否需要搞两个衣柜？
5、分开的好处是什么？ 合并的好处是什么？坏处呢？
.
以后面试产品设计师，我会问这个问题。
我理解的使用方式是——
日历倾向于确定到某日（甚至某时）的事件提醒。
任务倾向于需要一个时间段来完成的事务备忘（××××年××月××日至××××年××月××日完成某事）。
跟一楼的想得一样。。
写了半天，跟一楼一样，不发了～
其实是一个系统的两种表现，做项目管理的时候可能会侧重于任务式的管理模式，项目中任务的从属和递进关系在日历模式中很难表现；做工作安排的时候就是根据现有任务分配时间了，日历更合适。
一个是为事情设定时间
一个是根据时间安排事情
立足点不同
一个衣柜放不同的东西，需要考虑东西的多了，衣服多了怎么办，开始是男人的衣服，如果有了女人之后，那么他的衣服放哪去，怎么放，有小孩之后呢？
总之麻烦
多个衣柜只需要考虑衣柜放那，多一个人，或者多一类衣服，增加一个衣柜（或者储物箱）就可以了，简单！
衣橱的问题我理解为数据存储的问题，既然都是衣服，用一个衣橱就可以了，但是最好有不同标示来区分；
家里我的衣服是蓝色撑子，LP的是粉色
日历强调时间，任务强调时序
关于outlook –
Calendar更多是用来安排会议，对于其他人来讲是看availability at certain time.
Task这个功能我很少用，很难把todo items规划到timeline上，肯定不断有人来打断，或者需要去请教别人，所以我只是keep a list and know what’s going on.
日历和任务是两个不同的概念。经常EX的话，就会明白。
也有可能是大家一起在模仿什么。。。而最源头被模仿的，做成这样也许是因为团队组织结构、干系人利益的关系。。。我乱扯的。。。
挺热闹，我发表下个人的看法
任务是用来标志完成、未完成的，很多情况下是一个状态变化，不是时间变化。
而日历更多是列出某个时间内要做的事情
还是有些不同，有结合点，但是又有不同点。
比如某个事情我不在乎完成时间，只在乎完成状态，这种情况下日历很难体现。
而比如某些情况下我要为每天的时间排上事情，日历就比较有用。
我的想法是：文化与思维方式
老外重视流程和规则，什么事情都要一板一眼的，一是一二是二，工作流就更不必说了。outlook是office系列，致力于提高工作效率，把需求分的很细，同时兼顾协同办公需求。
但是有些日常生活的小应用就可能会比较随意，比如gmail的tasks,rememberthemilk这些，因为这时是图方便，和工作不一样。
原来老板说过:给老外设计产品就要把他们当小学生的智力水平，很多功能混淆在一起就傻眼不会用了，为什么国外网站除了广告和帮助外都是一个窗口走到底？都是思维方式的问题。
日历把日期定死了，适合生日，会议日程之类的提醒
而任务我只是记下有件事情要去完成，没有说具体时间。
所以，，
没有deadline的放在任务里，是to do
有deadline的可以放在日历里，是will have done
这个问题确实很难回答啊……楼上的意见都很值得参考
1楼和12楼13楼的结合在一起 这个问题就很明了了 总想着整合不是好事 如果真的从用户角度考虑了 就不会整合在一起 否则即山寨用难用
@Ray
这就是筷子和打蛋器的不同了
说说偶的理解，日历适合对时间要求很高的，比如今天1：00-2：00开会，那么这个时候一定要开会，误了就是误了。但是任务是以事件为主的，比如10号前昨晚某事，但是误了可以拖延，而且可以设置优先级，日历就不要优先级，因为时间一般都是独占的，1-2点这个小时不管怎么着都是要占用的，除非很特殊的事情才可能出现共享。任务可以在时间上重叠，所以需要优先级。
至于衣服，偶的观点是，这是一个便利检索的问题。按照分类分，比如T恤一堆，牛仔裤一堆，西装一堆，因为你挑衣服的时候，一半是一件T恤+一条牛仔裤，或者一套西装。这样如果分开，这样可以减少总的检索数目。例如你需要挑T恤和牛仔裤的搭配，而且你每样有10件，分开后最多检索20件衣服就行了。但是在一起的时候你需要检索2次20件。毕竟对于偶这样的对衣服没感觉的男人，但是出门如果是参加会议什么的又要多少打扮一下的情况啊。如果什么都不考虑抓两件就行了的话就不再考虑范围内。
所以把相互排斥的(同种类的衣服)放到一起，至于是一个框还是一个隔间还是一个衣柜那么就根据数量来决定了。
Google Calendar里有周末采购一项，到了Tasks里就是一个List，每种商品各为一项。对我来说完全不同的用处。而且购物清单是可重复使用的，这次完成标记一下，需要购买再反标记。用Calendar到话太不方便了。
我则觉得功能可以让用户选择集成或者弃用。
虽然存在一些用户不会主动去配置，但可以引导的，配置如果足够简单的话。
如果用户确实感觉到需要某功能则会配置。
我也觉得不可理解
日历可以当成“日记”，是一种特殊任务。
任务就不一样了。
鸦现在到底是做UE还是做产品
其实这是一个做加法还是做减法的问题，而微软，Google等显然经过研究用户习惯，认为这两个部分是可以并存的，而并存肯定不止一点原因，比如：
1. 一个项目管理，一个个人时间管理
2. 根据个人使用习惯不同选择最适合自己的
3. 习惯任务的，不一定习惯日历，不能简单粗暴的关掉
还有很多原因……
显然，微软，Google等是认为这两个东东的权重都很大，而互联网公司在能够实现的情况下，应该尽量给用户更多的选择权。
既然无法替代，那么就只有并存。
顶terrysnake，分析的蛮有道理。
用户习惯不同，加法和减法不适合，并没有更好的解决方案的时候，就只好并存着了。
产品设计流程和产品设计部门间竞争的缘故。
与“为什么不能合在一起”这个问题没有半点关系。这就像部门间的资源重叠现象，谁都看得见，但谁都不会讨论，组织架构的副产品。
这种现象大多发生在大公司，小公司对资源的重复利用率更为关注。
当某一产品设计部门在整个产品设计分布降低权重，自然他的功能就会被整合到更高一级的产品设计中。那更多的意味着部门合并，但外人很少能够察觉。
若是形而下的“强行分析”，倒是可以从用户需求和行为学方面阐述，但那在面试中意味着投其所好。那就是公关了。
即使一个衣柜可以放完的情况下 我还是会把TEE和西服放在两个衣柜里面。 然后在上面打个标签“正装”“休闲”
都是衣服，但是我去作**活动 只会用到一个柜子里面的东西。 如果哪天我抽风， 想穿个T恤+西裤的装扮，这个偶尔的选择成本增加也不会多花我多少时间。
但是分开对我老说有一个好处，那类的衣服只要放在哪边就好了，这样我归类整理的成本低了，甚至IF有一天能有幸不是我自己整理这个事情，别人也很容易清楚的看到我什么样的衣服该放在什么地方，很少会出现在正装的柜子里面找不到某件西服 而被放到TEE的柜子里面了。但是在一个柜子里面，放“串边”的情况会远远的多。
在日历和任务这个问题上， 我是这么看的：两者实现的功能很相近，都是和日程相关的内容，但是信息的组织方式不一样。一个是以日期为主线的，一个是以任务（事件）为主线的。在底层的数据上，甚至可能是一个数据，但按照不同的展示方式，这就是两个不同的信息。要实现的功能/解决的需求也是不一样的。
例如 18日我要完成A项目的任务1； 和A项目的任务1要在18日完成；这两个本来是一个信息，但是多项目聚合以后就不一样了。 按照日程的方式就成了18日我要完成A项目的任务1,B项目的任务2,C项目的任务4； 而在任务中就成了 项目A的任务1要18日完成 ， 任务2要20日完成， 任务3要25日完成。
哈哈，04年给手机做产品策划的时候，特别研究过日程和任务，
简单的说，功能侧重点不一样：
日程侧重于事件的提醒，以及占用的时间段。
任务侧重的则是某一件事情的进展程度，是未开始、取消了、挂起了、还是执行了20%了……
受教！
日历：从时间角度安排事情，以时序管理（查看、提醒等）事情
任务：从事情角度安排时间，以事列管理（查看、并更等）时间
虽然有上面的区别，但完全可以合并成一个产品，用户可以从两种角度使用该产品。
为什么微软、GOOGLE、APPLE没有合并，原因有2：
1、后来开发该产品的公司考虑了用户习惯的延续，降低产品风险；
2、后来开发该产品的公司考虑了产品互通、兼容问题，也是为降低产品风险；
日历，比如约会，在什么时候做了什么事。
待办事项可以不确定时间，就写下一堆即将办的事。有的也不好确定时间。
实际用中就会感觉到，强制要合成在一起也可以。但是分开的话，也不错。
而且分开不好找到。比如我半年之后想干么，写在日历里面写在哪一日？日历是要一页页翻的，以后想看的话简直大海捞针。很模糊不好确定时间的，还是待办事项好。
嗯。。。
应该像是炒饭和皮蛋瘦肉粥为什么不能同时存放在一个碗里。
也可能有时..人家跟本没想那么多…
好多都是这样的…原来也不知道怎么就放上了..但时间长了..别人就给定义了..这很专业.那也很专业..
但这些.自己还不知道..呵呵….做设计的可能有时会有这种感觉..
太坏了，拿自己纠结不清的问题来考别人 ：D
我想，如果两者合在一起，尤其是任务整合进日历，日历的基本功能从字面意义而言就是用户来了解日期的更迭，如果没有任务的单独功能，而很容易让一般用户忽略掉有任务这个功能，之所以看上去有点画蛇添足的原因可能是任何一个设计师都不可避免的要让用户真正的享受到最优的用户体验。
白鸦提了个有讨论价值的问题，很多回复也把日历和代办事宜区分得比较清楚。
我和8楼的Neo习惯刚好相反，我不太习惯用日历，但一直使用用todo list。我是公司的产品经理，手中有2-3个产品，即使这样，一般情况下todo list已经能满足生活和工作的需要了（比如有什么问题需要找人确认？有什么文档需要我写？要准备什么会议的召集？有什么人的进度需要我去询问？），几十条的todo基本上花几秒中扫一眼也知道后面需要干什么了。我没有太多的明确的日程需要安排，如果一定要把todo和日程放在一个地方显示的话，对我来说很浪费。
什么情况下使用日历？（我的习惯）
到一定时间必须会要发生/执行的事
有规律循环发生的事
什么情况下使用待办事宜？（我的习惯）
无论是否有deadline的有待解决的事
（在todolist不是很庞大的情况下，比如超过100条，不太需要吧有deadline的任务放到日历里面，一般todo附带一下时间上的说明就可以了，扫一眼的时候会发现deadline的，扫完之后，最重要的todo就会一跃而出）
使用日历主要看最近会发生什么事情，好提早准备或者提醒自己到期执行，着重于“提醒”。
使用代办事宜主要是在自己有时间的情况下，看什么事情比较重要，按优先级解决，着重于“记录”和“筛选”。
流程上是最先进入“代办事宜”，安排好了之后，才有机会进入日历。对于mail来说，代办事宜比日历更有结合的意义。
日历和待办事宜在电脑出现之前就已经独立存在。在电脑上面出来的时候，延续传统分开处理是非常合理的，至于结合起来是否能更合理，我相信还是存在可能的，哪位GTD达人来颠覆一下传统？
时间触发和事件触发
以日历和任务有限的使用分析结果如上
Outlook是Office的核心产品之一，要从办公角度考虑这个问题，然后再考量google如何从战略角度考虑它的产品
Outlook不是个人邮件系统，而是群体办公软件，用户不止是个人
这是个好的开头，值得探讨研究。
QQ也有日历，为啥，登陆QQ的时候，不能同时也登陆日历，需要2次登陆，它们怎么想的？- -|||orz
ps：
撇开以上，扯个远的，google reader的note功能不能重新编辑，为啥 – – 它们怎么考虑的？
呵呵，看了这么多留言，似乎没有一个赞成合并的。
但我却深有同感，任务和日历事件本质上是一致的：都是需要完成的一些事情。
没有安排具体时间的是任务，任务安排了具体时间之后就变成了日历中的事件。
因此两者本来就应该合在一起，即使展现上分离，数据上也应该是一致的。
更细一点的想法写在自己的blog里面了：
http://aleung.blogbus.com/logs/36648190.html
大家也不想一想，日历，任务这么简单的应用，为什么在国内就没有一个像样点的软件或服务能占领市场？什么原因？脱离了用户，在这里分析日历和任务的区别，有点纸上谈兵了。
[…] 今天看见白鸦提出日历和任务列表是分还是合的问题，我自己谈点想法，请各位专家批评指正。 […]
应该还是合并了比较好吧。。
日历跟任务根本就是两个东西.
可能部分功能有类似的,但是使用和用途是不一样的.
比如你家的浴缸,可以接水和放水,跟坐便器一样,也能接水和放水,但是你不能在坐便器里洗澡,不能在浴缸里大便一样.
呵呵，面试设计师的时候您能不能测试一下，这个设计师是否有一颗为人民服务的心？为什么成了设计师就成了爷了？！
不好意思，今早又遇到了（曾经遇到过无数次的）不负责任的设计师，没有信誉，没有专业精神。
我觉得是不同的视图罢了。从不同角度去管理事务而已，不同的人习惯不同的视图。
日历和任务结合就好，nokia的手机就是结合。我想懒人比勤奋的人多吧，一次能完成的没有人想两次！
谁会从日历里面去找任务，我们叫它日历，它还是个日历。功能再多不能忘本:)
我在1楼匆忙发了二者的区别，又看了楼上这么多评论都很有道理。但反思之后又在想，其实二者的区别白鸦TX应该也是非常清楚的，那么为什么不合在一起呢？我想站在客户导向的角度再抛几块砖头——
1、占比比较多的客户：觉得日历和任务是有必要分开两个功能用的
2、占比比较多的客户：觉得日历比较实用，任务没什么用，但多一个也无所谓，甚至压根就没发现还有任务这个东东（我个人认为OUTLOOK界面UI上强调了日历，淡化了任务）
3、占比比较少的客户：觉得日历、任务如果不合并，多一个看着就很碍眼很难受的
综上，选择日历和任务并存，强调日历、淡化任务是符合绝大多数客户需求和习惯的。
我觉得16楼nightheart打的比方非常精辟——“筷子和打蛋器”，筷子可以用来吃饭也可以用来打蛋。
只要你想，日历又何尝不能用来做任务安排？
只要你想，竹子都可以做剑用，但前提是你是个高手，但一旦是个高手似乎又脱离了绝大多数剑客的水平了。
那么，我们是在为少数高端用户还是绝大多数普通用户做产品呢？值得思考！
在一开始，我觉得白鸦的想法是很好的。
但是现在突然豁然开朗，还是坏人那句话：更专业呀
：）
从软件的定位上讲，如果用户需要区分开的话，显式得区分更好；
如果用户觉得软件太复杂，则合在一起更好。
具体还是要看软件的使用人群，以用户为中心进行设计。
还有软件的或者公司的文化
如果微软区分开来我能理解，apple或google区分开来我就不能理解了。
如果合到一块,会设计成什么样子呢? todo可以直接拖拽到日历上?过期未完成的todo,直接顺延到第二天?
微软比较彪
google会把task独立开来的
最近在用hitask 很不错
说说我的理解
首先，安排的时间段长短不一样。
日历：是对较长一段时间的安排，十天后的上午要做什么事情；
任务：是最近一个时间点或较短时间段（今天、明天）要完成的事情；
概括起来也可以理解为29楼Raymond所说：
日历：从时间角度安排事情，以时序管理（查看、提醒等）事情
任务：从事情角度安排时间，以事列管理（查看、并更等）时间
其次，应用范围不一样。
日历：可以用于多人或者团队项目管理，可公开。多人应用如Google日历；团队项目管理如进度安排。
任务：侧重个人，提醒个人某一时间内要完成什么事情，绝少有人把自己要完成的任务想团队所有人公开。
再次，应用对象也会有所不同。
例如我昨天预约牙医，接电话的是护士，在问完我预约哪位医生后直接告诉我26号上午十点你过来。这个时候，护士用的就是日历功能。我想那位医生在一定时间内不会知道我的预约，也许只有到25号的时候，她才知道有这么回事，而对她而言那就是任务而不是日历了。同样的应用还有大公司的老总秘书安排老总会议会客等应用。即日历可用于安排别人的时间。而任务只能用户安排自己的时间。（老大命令小兵的情况除外）。估计最初任务和日历的分离更多是考虑到这这样的应用。
最后说说对分与合的看法。
从自己的个人应用角度我会倾向于合并，简单啊，我只要在日历里安排未来某个时间段内要做的事情就好了，当日期临近的时候之前的安排就自动变成我要完成的任务了。具体的内容还可以根据时间紧迫性和不同性质通过不同的UI表现予以区分。
但作为产品经理，我会把两者分开。因为，我是用户，但我不代表大多数用户。我相信绝大多数用户对日历和任务的应用还是上述的第二和第三种应用。一个产品除了好用之外，还应该考虑目标用户，无论microsoft、apple还是Google，他们面对的还是所有的电脑/互联网用户，因此必须考虑产品的普遍适用性。
楼上已经讨论了很多了，两个产品有关系但是解决的不是同样的问题，所以整合在一起会让只有一个产品需求的人不舒服。比如我，两种产品都用，最后我还是喜欢用to do list。我估计很可能两者同时用的人会很少。
冒昧说一句，白鸦是否真正把这两个产品融入自己的工作中呢？如果你真的大量的使用过这两种产品来安排自己的工作，应该就不会有这样的困惑。瞎说的，说错了别介意
大家说得都很明白，我说说我的理解，答非所问：
其实无论Calendar也好mail也罢，其中有一个“相关任务条目不集中（也可以理解成需要分类的碎片）”的问题，这也正是Gmail Tasks解决的问题之一，比如：
1、老师使用mail收取全班12位学生的作业（部门助理收取全部门成员填写的同样一份表格等等）；
2、一个周期较长的项目中，不同的人员参与的不同的阶段性任务；
如果给Calendar加上类似Gmail Tasks来链接相关的条目（就像链接相关邮件一样），从而在一定程度上解决了Calendar里“相关任务条目不集中”的问题，是不是会好一些？
这里的意思是Tasks是一个大任务，通过将它分解成为若干的子任务放到Calendar里，明确到时间线上，如果这个Tasks还没有开始执行的，仍然跟Calendar（时间线）没关系。
——————————————————–
“而，我认为Task的管理，更多的在于Task登记下来后，如何去执行，如何将Task变成一个一个可以作的明确的Action和人、物等。”via:http://www.kimihome.net/blog/?p=779
——————————————————–
甚至，更加疯狂一些，Calendar与Gmail共享同一个Tasks。
纯属个人拙见，无任何科学依据，that’s all~
从技术角度出发：
calc：用时间做索引
todo：用事件做索引
生活中，你可能想知道，某段时间会有什么事情，那么你看calc。
工作上，你习惯想看看手头有什么事情好去安排时间，那么你看todo
不同的用户可能有不同的习惯，如果一个产品能适应好不同用户的习惯，那么就非常完美了。（me.com做的不错）
不过，就目前而言，Gmail做的并不好，就像我女朋友说的：“不是有igoogle了吗？我干嘛要在gmail左边放task”
[…] 为什么不能合到一起？ Sunday during 8:17 pm – Comment – […]
日历：记录目标；
任务：记录目标的实现流程，也可以说是任务列表。
柜子的问题：
a.如果有一堆Tee和牛仔裤，有N套西装领带：这是两种不同着装类型（正装与休闲类），当你明确需要穿哪种类型的服装时，分开两个衣柜可以相对快地找到衣服（特别在衣服多的时候），坏处是没明确需要穿哪种类型的服装时，增加了使用成本（要打开两个柜子，就像要打开两个收藏夹）。如果只有一个衣柜并分开两个区域时，坏处是当衣服增多的时候，过多的衣服可能会影响查找的效率，个人倾向于一个衣柜即可。
b.如果只有一堆Tee和一堆休闲衬衣,就不需要搞两个衣柜。作为我的理解，tee和休闲衬衣都是同一类休闲类，如果我需要试穿来决定裤子搭配时，要打开两个衣柜，那樣会增加我的使用成本, 所以這種情況只需要在一个衣柜里分开两个区域并进行对应标签，這樣我放衣服或找衣服只需要打開一個櫃子並注意標簽即可。
打个收藏夹比方：
1）一个衣柜
收藏夹→打开→Tee/休闲衬衣→选择
2）两个衣柜
收藏夹1（Tee）→打开→Tee →选择
收藏夹2（休闲衬衣）→打开→休闲衬衣→选择
当我需要选择Tee和休闲衬衣進行對比时，则需要同时打开两个收藏夹，并且要在两个收藏夹中不断切换。
流程2）明显会比流程1）的操作成本要高
楼上的大大们从个个角度上都分析的很精辟了，个人认为绝对有必要分开，大部分的产品的复杂之处在于整合了太多的同类的内容，反而使之混淆不易区分，而易用的产品无疑是简捷、明了的，比如我有一个约会要提醒，outlook很方便的日历快捷设定，而每个人做的项目未必是单个的，所以用并行的优先级来提示，还可以对状态更新，一目了然
另外单纯讲衣柜的问题,作为经常需要换女生的女生，在选择同时就需要现场进行颜色搭配，也就是说我选择了一件上衣，肯定立刻根据上衣对裤子进行即时的搭配，所以，一个衣橱两个区域比较好一点
文化差异就差生不同了！ 不过很少用原装的产品，邮箱会用FOXMAIL，任务都用QQ记录！！
GPHONE啊～
是GOOGLE定制的Android平台的智能手机
内置了Google自身产品如Gmail、Google Maps、YouTube等服务。
主要对抗IPHONE
虽然我对移动没好感，但是这个应该和移动没关系。
无非在醒目位置上加上移动自己的服务。
懒得看上面的回复了，自己的理解很简单：
记事本，待办事件藏在日历后面以后容易忽略
我的桌面有日历，也有待办事件。我之所以将待办事件独立出来是因为他不会被我忽略
强帖！
受教！
装B者死
就这么简单
我最近也一直在线nokia手机s60版都有备忘录和记事本，如果说日历和任务，一个从时间命题，一个从事件命题，那备忘录和记事本的区别是什么呢？
另:留了我的邮件地址，从事无线6年了（看邮箱地址能看出来），一直是我朋友的朋友认识白鸦，所以想直接认识一下，不知如何联系？
我每天上班，有许多事情要记下来。
举几个例子，比如，首页优化，定在4月1日-4月15日；
明天上午10点，就某按钮样式问题跟UI设计碰一下；
新招聘的某某4月入职，把工作提前安排一下；
明天下午1点面试编辑；
网站搜索功能还太薄弱，后续抽时间着重优化。
后续某功能设计可以借鉴某某产品，好好体验下某某产品。
这些内容，往往都是明后两天明确了执行时间点的记在一起，后续明确了时间段的记在一起，以后打算做的没有明确时间的记在一起。
当然，记录的工具很土，自制excel和txt。
因为，我还没用过一款能把这三类内容很好的整合记录下，让我很方便的安排、提醒等辅助的日历or任务or记事or备忘。
尝试回答一下：）
把这个问题还原到现实生活中来考虑：为什么有日历了还要有便签纸？
同楼上几位的观点，“日历”是时间导向，“便签纸”是任务导向。分开可以满足不同的应用场景和用户习惯。
合并起来也没问题，一样能满足不同的应用场景和用户习惯。
google和apple他们分开做个人理解是产品定位原因。两家相同之处都是把“日历”做成独立产品，“任务”做成mail里面的一个特性。因为功能上“日历”更重，“任务”更轻（现实生活中一般“日历”卖的也比“便签纸”贵）。把“任务”搭在mail里做，因为mail是“任务导向”。想看日程安排？看“日历”去吧您就！
qq日历就是把两个合并起来了（同一份任务列表，分别按“日历模式”和“事件模式”查看）。因为它是独立客户端产品，专门做这事儿的。也是产品定位原因。
前两天我也在想这个问题，不管是outlook,google,连我用的e71也就是symbian os也都是calendar和todo分开。
我是这么说服自己的，相对来说，todo可以没有具体时间，不用定义提醒。在定义一个todo item时，只需要定义subject和detail，最多再放个target day.但是，calendar可以为即将发生的事情定义提醒，可以为已经发生的事情写memo。相对来说比较详细。
另外，calendar有标准(iCal RFC-2445)，可以参照一下。
呵呵，洗洗睡了。
我以前对 outlook 也很疑惑 ，当我买了 索爱P990 智能手机之后 就完全明白了 ，
有了任务 查看起来更方便 就是 把任务项目化 1 2 3…… 那个没完成 跟进
日历 一般记录 长时间的时间 比如 我要在 8：00~10.20 这个时间 和某人谈事情 ，10：30 ~11：30 去和朋友打桌球……
日历是对时间的安排 ，而任务 是对 事件的安排
我也经常在想这些问题，不过考虑的都是手机方面的
手机短信为什么要分成为短信和彩信两个模块；现在这两个模块合并的趋势已经显现
短信为什么要分为收件箱、发件箱、已发信息和草稿箱等，是不是完全从邮箱的设计照搬过来的，但这对与短信而言合理吗？反正用了下黑莓，不区分的，觉得挺顺手
手机里还有很多区分存储位置的，比如手机内存、sim卡和存储卡，感觉有些区分没啥意义
我觉得你的思维有点陷入一个模式，要么合并要么分开，都是由用户体验设计师来决定，但是人都有不同的想法。简单的从一个时间顺序来思考，产品的价值点逐渐变得立体。远在原始社会，生产出来的产品价值主要是使用价值，是它的功能性。逐渐发展后，社会结构有了分化，有些产品标榜了社会价值，比如一些装饰物。发展到封建社会，社会分工更加明确，交换越来越频繁，产品的属性也越来越多，但是功能越来越专一，越来越有针对性。到了现在，商品的概念出现了，就连一个小小的塑料瓶子，里面也包含了很多因素，engineering tech, brand identity, human factor, print making, graphic design, industrial design，management, marketing, distribution等等等等，这些都无形的跟着产品，我觉得产品（不论是虚拟产品还是有形的产品）都已经逐渐开始形成一个自己的系统，而目的性越来越强，服务的用户群体也越来越有代表性，我叫它symbolism，因为客户或者是人群已经不在根据简单的肤色，地域来区分，而是应该根据共同特征来区分，产品也更倾向于设计给一个单独的用户。但是这可能是一个很长时间以后的趋势。现在是一个mass customization的时代，我讨论的可能不是解决方案，我只给各我的想法，也许应该从根本上 定义几个功能块，也许google,mac,microsoft作了很多用户体验的调查，也许还请了ideo, frog这样的设计咨询公司作了设计和评估，理论上非常有说服力。但是中国客户是否能够同样满意呢，未必，这些东西到底是否被检验有效只有用户最有发言权，如果用户在第一眼看到或者第一次使用就已经有障碍，不想继续使用，我想它已经在用户那里被打叉了。然而可能有很多用户使用了并且觉得方便，但是在一段时间内，总会觉得这个不是专门给自己使用的，因为每个人都有自己独特的习惯，后面的设计就衍生的太复杂了，有点跑题了。
我觉得windows的开始那里也许有点启示，用户使用一个软件超过一定次数，就会自动上升到那个快捷面板，就好像我一个开外卖店的朋友，他的员工都是在那工作几十年的老员工，客户也都是很长时间的老客户，他们的menu只有几道菜，选择不多，但是都是最受顾客欢迎的，每次老客户去了，根本都不用点菜，自然而然的老员工就帮忙点好了。客人不单得到了方便，还有一种归属感，菜式不是很多，但是每道都会很精髓，选择的时候也不会做出太有偏差的选择。
也不知道自己在说什么，交流一下而已
可以合并，但實現起來比較復雜，最近正在反復思考這個問題。
對于OUTLOOK，合并就好了。
對于google這種產品線相對獨立的情況，我追求的是數據合并，但在不同產品線可以互相調用、互相讀寫。
看了大家讨论的问题突然想到一些和题目不很贴切的内容。
将日历和任务结合
因为日历是时间标识，什么时候做什么东西，以时间为先
任务是事件标识，什么事情需要做，或什么事情需要什么时候内完成，是事件为先。
如果将两者结合方法如下，至于技术实现暂不考虑。
上部显示日历
下部显示任务标题
按照操作方式来说明功能
添加事件–》填写详细内容或按快捷方式选择内容类别–》填写时间（开始及结束时间，如不填结束事件则只为开始时间当天）–》选择定义颜色–》确认–》日历上以定义的细直线颜色条显示该条事件所经历的时间–》下部以添加事件时间排列–》点选日历上有细线的时间时出现提示框–》框内显示该时间内所有的事件标题–》点击某事件–》下部显示该事件的详细内容。
（想到可以添加在某个产品的功能，大家提提意见，欢迎喷我）
很简单的说明下：
以用户为中心
产品是外国人做的，自然以外国人用户为中心，国外对事物的理解模式就和中国有本质区别
我们用的只是汉化版
当然，NB的人可以做一个中国人版的产品，把任务、日历放一起一点问题都没有
关键问题，您的用户有这个需求没？
举个例子：
路边公厕设计有两种：
1.一个大门进入以后再分男厕入口和女厕入口
2.直接分男厕入口和女厕入口进入
哪种会很方便识别使用了，显然是第二种
我比較習慣使用我nokia手機裡面的日歷，隨時可以打開日歷，然後選日期設置任務。
但本身系統當中日歷和任務是分開的兩個功能～
不同产品组开发的或者是前期需求分析或者规划设计的时候没搞清楚。沟通不及时搞了个各自的想法。如果是一个人自己安安心心做几乎不会有这种问题。口多，心眼也多了，想法也就莫名其妙了。说到底团队合作的事儿。有人喜欢弄N个衣柜乱七八糟的放，有人喜欢井井有条，萝卜青菜各有所爱，做这种产品设计也都这样，有哪个团队一开始设计的时候就考虑到身边另外一个团队做出的另外一个产品会和自己有藕断丝连的关系啊。要你这辈子只用过日历或只用过任务，也就自然没这种纠结了。
任务可以指派，日历可以共享，可以通过各人的日历来挑选一个大家都有空的时间来确定开会的时间。
任务可以没有时间限制，不见得非要放到日历中。任务可以指派给他人，对方更新状态后，你的Outlook会自动更新。任务指派后，可以限时完成。
日历中记录的都是确定时间的事件，而任务可以是确定时间的，也可以是不确定时间的，任务中的事件完成之后可以拖入日历中。日历是个“圣地”，只有明确时间约定的事件才放入日历，其余就放在待办事项栏里。outlook中为什么要分别设置“任务”和“日历”呢，我想它们的区别也就在于一个是确定时间的（即Must do)，另一个则相对没有确定罢了(可做可不做， 希望你尽快做，但不设时间，根据地点、剩余时间、精力、优先度而定）。
每当我将“待办事项栏”里的任务完成时，我会用鼠标将该条“任务”拖往“日历”栏，即弹出一个新建“日历”的对话框，我会详细设置“开始时间”和“结束时间”，同时将这件事的相关情况（比如心得、体会、感想等）记在下方的编辑栏里。这样不断重复，一天的时间就被这一件件完成的任务所排满，日子自然过得充实而丰富了。
我们经常收取邮件，并因此按邮件的要求完成相应的任务。在outlook中支持方便地拖拽添加任务的方式，即用鼠标左键点击邮件并拖拽至任务栏后立即可弹出新建任务对话框。
每周日的晚上用一个小时进行每周回顾，这点通过周期性地日历安排设置在outlook里了。并明确地记载了回顾的内容：
1. Email：回顾并且清理“待定”和“即将到来”的文件夹。把那些拖了很长时间都没有处理的事情都删去。
2. To-do列表：浏览现在所有的任务清单，删除那些已经不重要的任务，并且重新给下周要完成的工作项目进行安排。
3. 项目: 把每一个项目中的下一步行动都放入任务清单。对项目列表进行更新和整理。
4. 日历: 检查下一周的约会和会议。把(参加约会或会议) 要做的预先准备加入任务清单中。
Update：
正如我#58说的，Google Calendar和Gmail共用tasks了。
Tasks in Calendar：google.com/support/calendar/bin/answer.py?answer=144246
我希望能够合并在一起，因为我使用日历的提醒功能。至于Google到处放Tasks，我想是因为他的Task功能没有“提醒”，所以得时刻放在那提醒着用户去完成，也就是“无缝连接”
[…] 3月16日，白鸦同学写了篇博客，他问： […]
[…] 1、一个季度前，我提出过一个被认为“幼稚”的问题：日历、任务两个独立功能，为什么非得分开不能合并到一起？ 2、其实是当时正在做一个类似设计，我认为：“分开，对于用户认知、产品维护都是一个问题”，就此和拍档们分析了很多，后来，我们作了“合并”的决定。 3、 如这个问题一起的，还有另外一个，今天在UCD书友会上我再次提起：有多少人把收藏夹当购物车用，又有多少人把购物车当收藏夹用？“收藏夹”和“购物车”为什么必须是两个产品？放到一起，不行吗？ 4、我想先听听更多人的看法。 […]
我觉得Ray 说的是非常有道理的，东方人的思维模式和西方人的思维模式有这巨大的区别，我觉得说白鸦在对合并的概念只考虑到了东方人的思维模式，东方人往往缺乏逻辑思维能力，但是对于关系的把握却比西方人要强的多，当日历和任务有所关联的时候，往往东方人对于这个的把握和认同远远要比西方人要高，就好像西方人和东方人买东西一样，一个六块的东西，东方人会给出10+1元、或20+1元这样的付款方式，而西方人会给5+1、10元、20元这样的付款方式，这就是思维模式的不同，东方人看重的是付款和结算之间的联系，也就是说会计算这个付款过程，而西方人不太会，他们更愿意思考付款的行为，也就是说他们只负责付款，至于付款的结算的事情他们不负责，这就是思维的不同，说老外木头也好，呆板也罢，只能说由于生活方式、思想、和社会构成方面的巨大差别，并没有对错之分的。
也许微软当初做这个的时候，本就没有考量过东方人的行为，又或许它认为东方市场或者说中国市场并不重要，或许是不理解东烦人的思维模式，但不管是何种行为，至少说明我们在学习西方人的发明和理论的时候，要根据自己的本地特点来发展的更适应一些。
这就是百度为什么比GOOGLE更加适应中国市场的原因吧，虽然百度在搜索引擎上未必比的过GOOGLE，但是它适合中国人的需要，我看才是根本点。
[…] 1、一个季度前，我提出过一个被认为“幼稚”的问题：日历、任务两个独立功能，为什么非得分开不能合并到一起？ 2、其实是当时正在做一个类似设计，我认为：“分开，对于用户认知、产品维护都是一个问题”，就此和拍档们分析了很多，后来，我们作了“合并”的决定。 3、 如这个问题一起的，还有另外一个，今天在UCD书友会上我再次提起：有多少人把收藏夹当购物车用，又有多少人把购物车当收藏夹用？“收藏夹”和“购物车”为什么必须是两个产品？放到一起，不行吗？ 4、我想先听听更多人的看法。 […]
[…] 3月16日，白鸦同学写了篇博客，他问： […]
[…] 我们常常会用日历和任务来安排自己的工作和日程，比较常用见的有Google Calendar，Outlook等。一直以来存在着讨论，就是日历和任务这两个东西区别是什么，他们究竟是应该放在一起还是分开。（鸦：为什么不能合到一起？） […]
[…] 黑莓本身带有calendar和task，而我在给别人刷机的时候往往会将其中的task给忽略掉，因为考虑到（事实也证明）很多中文用户可能根本不了解这两者的区别，而且也基本上不会想到有机会能用到“task”这个功能。上次＠kcome搞的白血病捐赠送Gtask的code让我重新开始思考这个问题。于是我欣慰的发现原来白鸦前辈也曾经有过类似的疑问，也看到了很多前辈对于两者区别的思考，比如（1）和（2）对两者的区分讲的也比较明白，还从两者的功能实现上从而希望用户能够达到怎样的一个效果进行了说明。 […]
其实很简单，思维模式的自适应问题。
一句话：分久必合，合久必分！
[…] 关于Event和ToDo两者的区别，可以参看白鸭博客上的精彩讨论，或者電腦玩物的介绍 Rainlendar 行事曆軟體中的 TO […]
个人来说，还是希望能统一起来，
任务完成了20%，那么是在那一天，又是以哪件事为标识，意味着任务完成了20%呢？
不要过度思考
请不要过度思考
task: A piece of work to be done or undertaken
放task的情况：task是未来需要去完成的work，可以有due date也可以没有。
如果没有due date，那么很明显只能用task而非calendar，时间选项对calender是必要条件；
如果有due date,那么要看具体task的理解了,比如“xx项目需要在6.15上线”，这个是有due date的，但是很明显放在calender是不合适的，因为如果今天是1.1号，而这个task在6.15号，这个跨度过大，你甚至在月视图里都看不到6.15号有这么一个task！又比如“周日完成xx报表”，这个也有due date，如果放calender也可以，可以设定某段时间来做这个event,但仔细比较其实还是放在task中比较合适。