最近在做文章转移，全部文字请点击http://fog-li.lofter.com/
对Demo的思考
在一个没有交互的团队里工作，PM和UI自然需要分别承担一部分交互的工作，所以多少会出现交互稿不完善的情况。到目前为止，我还没从PM或者交互手上拿到过我认为考虑完善画得漂亮的交互稿，不过倒是在每次阅读他人交互demo后，发现了一些看似很小，但实际需要深究的问题。
【1】数据的意义
工作中有参与过几次后台设计，在项目结束后会发现，后台的功能多用于展示数据和处理数据。在设计时会多注意如何清晰展示数据。但这次设计时发现，数据是否表达了准确的意义，比观感上清晰展现数据更重要。
一串数据的显示并不是在设计稿上加个字符这么简单，其实这涉及到开发，涉及到用户的理解，也涉及到设计的布局。既要符合开发数据调用逻辑和工作机制，也要清晰的表达数据意思减少用户的使用困惑。
每增加一种属性，可能对于开发来说，增加的就不止是一行代码
案例一
这是后台左侧导航最常见的个人信息模块，起初我认为红线部分只是一个关于人物属性的提示而已。后来和PM沟通之后才知道，不同的人物属性会触发不同的功能。后来的后来才了解，原来添加一个小小的人物属性，其实对开发来说，需要做的不仅仅是一行代码。
单从一用户对应一属性来说，比较好理解，是什么属性开什么功能就是了。但是一用户对应多属性的时候，就不是单纯的人物标记了，需要开发编程时去加入识别和判断，再让系统识别读取合适的数据。这样一来，要与开发讨论这种开发机制是否可行，讨论合适方案，而不是想当然的随便加个属性。
案例二
这是设计时遇到的个人信息浮层，需要满足信息告知和信息勘误两个功能。本来收到demo时（原型实在太丑，我自己做了左边那个示意）还没太注意，觉得这只是一个小控件，做完大的布局框架之后再说。后来仔细分析了一下这个控件，发现原型既没有满足清晰的信息告知，也不能明确的定位勘误。
左边的Demo是【A+B+C】的信息组合展现，表意并不明确。比如这个信息可以组合成【所在校区英语一年级】也可以组合成【所在校区语文一年级】，这样的话会出现很多种搭配，用户并不能明确知道自己名下的每一条信息，那个勘误接口也不能定位信息，总之这个原型考虑不周全。
后来，和PM沟通后，我把样式改成了右边这样。节约空间、信息清晰还能准确定位，能满足信息查看和勘误的两个功能。
【2】交互模型样式
这次开发比较基础，没有过多复杂模块。拿到Demo时，功能点是能看懂，但是看起来就很变扭，也说不上为什么。只能先想想自己有没有用过类似功能，找到合适的参考先。
方案一
这次的后台有个创建分组功能，原有Demo和常见的邮箱添加用户做法类似（见下图），选框会因人数的增加而变化，但实际载体却是一个弹窗。
如果真按照原型来做的话，弹窗的高度就不可控，样式会发生变化。虽然增加几行代码也许能解决的这个问题，但结合实际使用常见来看，用户大多使用1280*768的屏幕，并不是大屏用户的拥趸；而创建分组又需要大量添加成员；这样做的导致的结果就是弹窗变大，超出显示区域，操作起来很麻烦。
想来想去觉得这样不适合，然后想了想最常用的创建分组功能的应用 — QQ和微信
下图是：MAC版的QQ创建组，是上中下结构。
层级部分是左右结构，不需要一层层点开，这种设计和QQ二元分组结构有关。经常操作区域为紫色部分,鼠标移动带来的手部移动区域其实挺大的。选中后列表显示也不够直观，中间列表选中的内容要在底部列表才显示。
下图是：WIN版的QQ创建组，是左中右结构。
层级展示没那么清晰（需要一层层点击打开），鼠标移动基本在一条平行线上，使用起来很直观，就好像把左边篮子里的鸡蛋放到右边篮子里。但中间的按钮设计有点丑，应该是有改进的可能
下图是PC版微信发起群聊，左右结构。
我觉得这是三种建组方式里面最好用也最清晰的，所有操作集中在弹窗左边，右边列表仅做显示数据用，鼠标上下滑动就好，连鼠标移动都很少，选好之后一个确定就搞定，干净利索又好用。
看到这个控件的时候真心热泪盈眶啊（555...）越发觉得交互Demo的重要性啊！不然做到最后开发不出来，还是要重做设计，那就太苦逼了。最后我选择了微信发起群聊这种模式作为参考，能很好的满足这次的设计需求~
