先讲讲最近自己想来想来去的一个小按钮的发现，目前也一直实践在项目中，闲话不说，放个图先
普通的对话框（dialog）控件除了文本标签外，还有两个按钮控件「确定」和「取消」，用意很明显，这样方便用户确定和取消当前操作。
而另一种则是下面按钮控价区域只有一个确认选项，右上角则有一个关闭窗口的小控件，二者都为对话框，内容和功能（确认取消）也大相径庭，区别又在哪儿呢。
我自己定义的情况是，图一一般用于被动性或非用户主观操作时的行为处理，比如，不可预期结果的弹框，可能性的误操结果，因为这种对话框，功能平衡，触发的机制存在偶然和不确定性，所以两个按钮保持位置平衡，只在视觉上面做了颜色区分。
而第二种主要用于用户可能存在目的性指向型的操作，确定作为唯一重提醒的按钮控件，在用户进行一系列操作后，能立即处理用户操作，同时也减少了复杂任务之后误操（比如误点了取消）的可能，在确定用户的可能性操作情况下，使用这种对话框设计，方便用户聚焦目标，快速处理（这里的案例是只用户在点取菜品属性之后的确认操作，因为目的性强烈，所以适用）。
也不知道我是第一个这么思考的，还是孤陋寡闻了，总而言之两种对话框可以灵活使用，在关键位置使用正确的对话框，能更好的贴合场景，服务目标任务。
和上篇提到的情况一样，目前产品，处于需求的井喷阶段，运营人员不是很了解产品，就直接把各种奇葩用户反馈都提交到worktitle（恩····我们车间一直是用这个来协同工作的）里面来，整个开发需求列表冗长又繁琐……
补个彩蛋：在上一篇提到的处理用户反馈的方法里，和开发、运维协调处理产品开发资源和需求紧急重要性的具体操作后，开发排期的事情被CTO的一句话给毙掉了······
恩，大意就是，现在都以几个重要客户说的问题为主，不要管什么先后，不管这个需求有多耗时难做，都要先满足这几个重要客户的需求，我问那其他用户之前也提了几个比较中肯的意见已经准备做了啊，“哦，这样啊，那还是先把这个几个客户的问题解决了吧”
恩··········/笑cry······
