陈勇-咨询-北京(139107533) 13:27:03
这个是我们的组织结构维护视图,本来是一个很简单的树控件,但就Domain而言,一个人只有看到长相如此的东西,才会理解它是一个组织结构图(尽管M就是树)
 

但是,V里边的代码,不过如此:


真正的代码,被放到M里边了。

如果从这个案例分析,就会看到至少三个人都参与了:

1. 产品经理,他要求不要搞一个树控件,要做一个和平时纸上印刷的一样的组织结构图

2. UI设计,开始设想了一个方案

3. 但最后实现它的,是程序员。

这也是我为什么最后兼任产品经理、UI设计、程序员的原因。

如果分开三个人,还能实现,但必须有相同的价值观,不要各干各的。

 

问: 13:30:54
不要各干各的 指的是什么?

 

陈勇-咨询-北京(139107533) 13:30:55
其实,我们有一个纯Html版本的组织结构图,后来封装到C#里边了。

各干各的,就是程序员说:“哪,你看这是数据读取接口,你自己画你那个组织结构图去吧”

我们有3个地方用到组织结构图,都是这三行代码搞定。如果各干个的,就需要把大约200行Html重新拷贝三遍。

但由于程序帮助封装了ViewModel和View的Helper,一切就这么简单了。

回到问题本身,UI设计怎么敏捷?


陈勇-咨询-北京(139107533) 13:34:03
首先,应该有一个人作为打通跨职能部门的纽带,应该是产品经理。
他综合提出对UI的最终设想,基于的是,用户如何与产品交互,才能最好地完成业务(这个好,不完全是方便、美观这些,而是直接和业务切合

其次,UI和程序应该是跨职能的,或至少处于一个跨职能团队中,不要分到两个部门或团队里边,这样大家才会集体思考最佳做法(比如前面程序帮助UI封装Html为Helper)。

以我三位一体的体会,很难想象如果有三个思想不统一的人做这件事情,最后结果是什么。

 

问: 13:37:51
达成共识

 

陈勇-咨询-北京(139107533) 13:38:48
是的。

要把UI长到客户的心里边,而不是展示在眼前而已。

我们现在还有几个页面不太满意,感觉看到以后,还要思考一下:这是什么……这样的UI,就有问题。

看到后应该是:哇塞居然可以这样!

或者:你看,就是我上次说的那样

有一次在之前的公司去做售前讲解方案,对方老总就一个劲地捅旁边另外一位,指着屏幕窃窃私语。我就知道那个单子成了。

 

陈勇-咨询-北京(139107533) 13:46:30
总之,用户看不到M,看不到D,看不到C,只能感受到V

 

另外一位QQ成员: 13:50:47
勇哥,你说的客户感受V,能否说的具体点。是不是说除了用户体验,还要业务体现出来,让客户觉得咦~~这就是我所要的。对吧。

 

陈勇-咨询-北京(139107533) 13:51:50
是的,V不要只图做得漂亮、方便,要理解用户来这里干什么,他看到这些,是否真的知道自己应该干什么了。


另外一位QQ成员: 13:52:05
明白了,谢谢~~

(问题讨论结束了,下面是关于MVCD中D的来历,一般只说MVC)

陈勇-咨询-北京(139107533) 13:53:38
MVC说法比较多,D是我自己说的,因为我发现D比较独立。

我把数据的读写和缓存都归结为D。

 

另外一位QQ成员: 13:55:44
由M到D,我理解就是数据持久化到数据库

 

陈勇-咨询-北京(139107533) 13:56:30

外加应用缓存吧,
比如火星人里边,史诗故事-用户故事-增强-缺陷……这些,有父子关系,表面上看,是属于Model的行为。
但我们发现,部门-团队-小组,产品线-产品-版本-Release……也有父子关系

所以,后来“父子关系”,被从Model的层面,挪到Data的层面

所以,我们的部门/产品/用户故事……(一共7种)东西,是存储在一张数据库表里边的,因为他们被从D的层面抽象过了(注:被抽象成为了“有父子关系的数据)。

但是,这种存储会造成性能恶化,所以,又做了应用缓存,把他们拆开。

从父子关系看,他们是iheritable-item

从数据的差异看,他们是udcable(user-defined-column-able可定义字段的)我们用这两个类来管理他们。
这些都是和M没什么关系的,用D来维护更好。