386张合成动画

        一、Model保存对Proxy对象的引用，Proxy负责操作数据模型，与远程服务通信存取数据。

        二、View保存对Mediator对象的引用。由Mediator对象来操作具体的视图组件（View Component，例如Flex的DataGrid组件），包括：添加事件监听器，发送或接收Notification ，直接改变视图组件的状态。

        三、Controller保存所有Command的映射。Command可以获取Proxy对象并与之交互，通过发送Notification来执行其他的Command。



        我们要所要做的是编写具体的Command，Mediator，Proxy。

        一、Proxy是负责操作数据模型的，什么是数据模型？数据模型就是数据库，XML等等。我们可以直观地理解为，Proxy是用来对数据模型进行查询、插入、更新、删除等操作的类。操作完成后，它就会发送Notification，也就是通知，告诉其它两个层我已经完成工作了。

        二、Mediator负责操作具体的视图组件，包括：添加事件监听器，发送或接收Notification ，直接改变视图组件的状态。好像抽象了点。具体的说吧，Mediator是负责管理用户界面，与用户进行交互操作的。如：给Button添加事件，当用户点击按钮时，发送Notification，告诉Controler我们执行什么样的操作。比如这是一个登录的按钮，那么Mediator就会告诉发送通 知给Controler，告诉它要执行登录操作。此外，Mediator还负责直接改变视图的状态。就像，我点击了登录按钮后，Mediator就改变 它，让登录按钮不过用，避免重复操作。它还可以在视图上显示一条信息，告诉我正在执行登录操作。总的来说，Mediator是用来管理视图的。

        三、Command可以获取Proxy对象并与之交互，通过发送Notification来执行其他的Command。再拿上面的 登录例子作解释，当点击了登录按钮后，Mediator就会告诉Controler要执行相应的Command了，比如LoginComand。既然是登录，那么还得要知道用户的信息才行。Command就会发送Notification告知Proxy，我需要某个用户的信息。那么Proxy就会访问数据库（也可以是别的数据模型），查询对应的用户信息，然后发送Notification通知Command我已经查询好了，差把信息返回给Command进 行验证，与些同时，Mediator也可以接收Proxy发送的Notification，通过视图告诉用户正在验证信息。Command验证了用户信息 后，发送Notification把验证结果返回给Mediatory，告诉用户验证的结果。或者，Command也可以发送Notification执 行其它的Command操作，比如验证通过后，读取用户的详细资料。

       上面的Command，Mediator，Proxy的具体实现类都是要自己编写的，工作量还是比较大的。

当前版本新增功能：

• 大红斑预报
• 手动设置时间

以下是Franco提供的十条逆向建议，并解释了为何要避免它们，而应该如何去做：

1. 如果你想失败，那就不要理解最终用户——70%的IT项目失败都是由于用户可接受性出了问题。
2. 如果你想失败，那就相信开发人员能够正确的做出设计决定。开发人员被逼迫着做出糟糕的设计，因为他们的工作量是由其所完成的功能数量决定的。当一个项目将要接近截止日期时，开发人员就会关注于删除功能而不是从最终用户的角度思考。
3. 如果你想失败，那就期望一个银弹式的设计。好主意是值得肯定的，但一个伟大的功能建议不应该取代优秀健康的UI设计。
4. 如果你想失败，那就满足所有人的需求。“如果一个公司试图为所有人创造一个产品，那么最后不会适用于任何人”。
5. 如果你想失败，那就启动项目然后忘却。在项目启动之后，产品需要更多的迭代以不断完善。
6. 如果你想失败，那就不要定义成功。不定义成功意味着不知道目标是什么。
7. 如果你想失败，那就避免冲突。冲突未必是坏事，因为“没有冲突就没有进步”。当屋子里的所有人都赞同某种看法时，那么就要提高警惕了。
8. 如果你想失败，那就相信不需要推销自己的想法。利益相关者应该努力在组织内部推销自己的想法，但不要期望仅仅因为来源于你就会被接受。这需要准备回答类似下面的问题：投资回报率如何？优点是什么？为什么要现在做？如果不做会怎么样？
9. 如果你想失败，那就追求完美。不应该一开始就把所有都计划好，并期望现实会按照计划行事，因为变化无处不在。
10. 如果你想失败，那就重视过程甚于产品。这条建议可以改写为：“如果你想失败，那就不要冒险”。我们可以非常重视开发过程，但是“按时生产一个糟糕的产品毫无意义”，通过迭代的方法构建满意的产品更轻松一些。

以下是Waloszek总结的糟糕用户界面18黄金法则，提供了负面的例子：

1. 让客户忙于那些不必要的工作——让用户在某些控件填写数据，随后又提示他们不能在那里输入数据（比如，一个应用让你在假期或周末填写数据，随后又提示说你不能在那些天工作）。
2. 不遵守标准——不把菜单条目放置在通常的类别和位置上（比如，在“编辑”菜单中放置“保存”按钮）。
3. 让软件运行缓慢——有无数的可能性导致软件运行缓慢。比如，你可以在每个用户输入之后包含长时间的验证或者切换。或者你可以强制用户浏览一连串的对话框。
4. 尽可能地使用缩写，特别是在有足够空间显示完整单词的情况下——使用“dat.”而不是“date”，“Tolky”而不是“Tolerance Key”，“NxOb”而不是“Next Object”，等等还有很多......
5. 使用技术型语言指导用户——使用UTF-8格式发送URL（需要重启，在MS IE的高级设置里）
6. 隐藏在用户看来重要和常用的功能——把其藏在用户永远找不到的菜单里。
7. 让你的应用只支持鼠标——绝不提供任何键盘快捷键。
8. 使用你的应用成为一项挑战——即使用户操作会导致严重的后果也不加以提示。
9. 脱离最终用户——许多用户有许多的选择，你只提供一个。这倒是可以更快更简单的实现。
10. 宣扬糟糕的示例——只需要听从本页的其他黄金法则就可以实现。
11. 花费大量精力设置糟糕的缺省参数：与用户的期望背道而驰，缺省配置极其糟糕、令人厌恶、无用——反正由你决定——在web表单上做缺省设置使用户收到不想要的新闻或者广告，散布他们的地址等等。
12. 在每次系统重新恢复之后都破坏工作上下文——在系统重启之后取消之前选择的屏幕元素。
13. 忽略让用户更方便的功能——让他们很辛苦——当用户需要在列表中添加条目时，只允许他们在列表末端插入条目，然后再让用户把条目移动到正确的位置。换句话说，没有提供额外的功能用于直接将条目插入到目标位置。为了增加点情趣，当用户直接把条目移动到目标位置时，应用提示一些伪造的错误，然后把条目插入到末尾。
14. 不让用户中断消耗时间和/或消耗资源的进程——偷偷启动一个备份或者索引进程，让用户难以取消，也就是说，无视用户的鼠标点击和键盘操作。
15. 应用不合逻辑——添加一个准备某操作的按钮使用户确认可以做该操作了。这里有一个真实例子：在许多电子邮件应用中，“转发”按钮实际上没有真正执行转发操作，而是做转发之前的准备工作（因为，我们不得不提供收件人地址）。
16. 时不时的来一次系统崩溃或者让应用僵死——让编辑器或者编辑域在用户事先未预料的情况下僵死，以至于用户还没有来得及保存他们的工作成果，而频繁保存的习惯会浪费宝贵的系统资源。
17. 尽可能的阻碍用户输入——页面加载也是阻碍用户输入的好机会。在等待的时候，用户可能会与室友聊天、读报或者盯着空屏幕发呆。
18. 阻碍用户输入，即使没有必要——阻碍用户在图片浏览器更新缩略图的时候输入就是一个很好的例子——没有任何理由阻止用户滚动、选择图片或者发起操作。