为什么不能合到一起？
最近两周一直在纠结一个问题，夜不能寐，连上厕所都在想：
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。我估计很可能两者同时用的人会很少。
冒昧说一句，白鸦是否真正把这两个产品融入自己的工作中呢？如果你真的大量的使用过这两种产品来安排自己的工作，应该就不会有这样的困惑。瞎说的，说错了别介意