-
版权声明:转载时请以超链接形式标明文章原始出处和作者信息及本声明
http://gundam215.blogbus.com/logs/47240892.html
这个续是专门回复一下“师母”的评论的:
- 对于你第一个问题的答案,我好像在哪本书上见过,不过印象已经很模糊了。。。应该还是从人的心智模型出来的,不过可以肯定的是,在创造的时候是没有研究心智模型的,就是你说的巫术。
界面的消亡还需要智能技术能有个突破~~
然后我觉得开发平台如果嵌入jquery这些框架的话,会比较限制自身,现在的思潮是前后端分离,jsp都快落伍了自然不会有人逆流。开发平台还是要适应具体的系统环境。像前端控件这种在sofa下面还是有一些限制。然后js和java的区别还是不小,js太灵活了。
最后看好json。
看好json,发展起来了
这里我逐个来解释一下。
1.人类社会本来就没有设计、心智模型等等的说法,也依旧靠自我修复纠正发展到了今天的状态。在很多事情理论化之前,人们是怎么创造的?那是经验的积累和感觉。即便是理论化了,这两者依旧是不可替代的。不得不说,即便到了今天,所谓的心智模型的研究和设计也没有很好的结合起来,很多人还是凭感觉。
这在about face那本书里其实allan cooper是这么说的,工程师有技术上的实现模型,人本身有自己的心智模型,而产品要弥合这两者的差距。所以关键是弥合这种差距。人们没有专门的先把两种模型提取出来,然后来做弥合,而是经验和感觉本身会帮助人们去做这些事情,慢慢最后可以总结出这个结论。而所有设计,在我看来只剩下两个字——“隐喻”,所以早期的设计,苦苦追寻的就是一些隐喻。
其次,人因工程(human factor)发展的比交互设计要早很久,所以其实在初代的图形界面设计中,心智模型已经被很多人因工程学家研究了很久了。
2.智能技术的突破这是自然。不过现代设计师有一个致命的误解,这也是我曾经一直以来的误解,那就是在等技术的突破。
突破往往会是外行指导内行,这是一个哲学层面的问题。因为技术人员会执迷于方法本身(这也是现代交互设计师的通病),但是每一种方法最初都有一个立论,有一个理论在支撑,这种理论代表着大家的哲学观,也就是人生观、世界观和价值观。但是科学的证伪性告诉我们,没有任何理论会永远正确。这种时候,往往是哲学观上异于常人,甚至有些离经叛道的人,才能提出新的理论。这就是我自己总结的——所有科学到最后只剩下哲学。这个问题上,其实可以关注下爱因斯坦、牛顿等等大科学家他们的真实历史,他们都对神学宗教极其关注,甚至痴迷。哥白尼的日心说是唯一一个被正史流传下来的广为传颂的故事。
而在设计史上其实不乏这样的事实。被我们广为熟知的包豪斯,甚至可以说我们现代中国设计教育的根基之源包豪斯的历史,也是被修饰的很离谱的。仔细参考文献,会发现当初那些人设计思想的基础来自于一个很小的有点宗教性质的组织,“神智论”。当然这不是我考证出来的,是上交的某位建筑学的刘老师(网名“城市笔记人”)在他的文章中提出的。我这就拾人牙慧而已,那篇文章叫《抽象,抽走了什么》。
这里我只想说明一个问题,我们认为的很多理所当然的事情是错的。智能技术的突破,不光在技术本身,更在我们的逻辑能力之中。为什么是逻辑能力?因为任何问题都是要靠分析总结的,智能技术说白了,就是把我们已有的技术进行整合优化。比如说,模拟自然人的思考的时候,就可能会先分类什么情况下做什么事情,这样的罗列,然后用程序语言或者机械语言或者什么什么语言进行记录。当然有的问题很复杂,涉及到概率论或者拓扑学,那么就将这些学科的方法用某种语言记录存储起来,这就是智能技术。
所有的分析总结,我觉得就是一门学科——分类学,所以我认为世上只有一种方法,那就是分类学,拓扑数学这些的属于分类学里面处理一些不确定情况的方法。在以后我发的设计手记中,我会提到我的这些观点。
3.第三是框架问题,框架问题被人误解,是因为国内的人刨根问底的精神太少,框架既然为人所写,必然也可以为人所用。如果你不理解框架,那就是被框架所困,如果理解这个框架应该怎么搭建,那么你就可以改造这个框架,提供很多自定义的扩展。
框架是为了代替很多不必要的重复劳动。这个本质上跟分离是一样的思路,这个思路我过会细写。不可否认,框架必然比纯手写组织结构来的臃肿,对待具体问题上肯定会有很多冗余,但是框架可以提供极大的灵活性。框架可以把一类问题都用一类方法解决,反复调用,这就是分离的思想;框架可以预留很多这类问题可能需要的扩展,这就是弹性设计的思想。
框架会束缚创造力这点毫无疑问,但往往框架都是很合理的,合理到毫无创造力!如果你光有创造力,但这种创造力做出的东西并不能重复使用,没有扩展性,那这种创造我认为往往属于小聪明,这是做广告做营销的思路。这个问题,跟我们所受的设计教育有关(这里不批判下去了)。创造一个可以重复使用易于扩展的东西,你就是在创造一个框架,这就是一个架构师要做到的。
关于jsp, asp这些东西,简单的说来不能单纯说是一个框架,而是一种平台,这些东西的确是上个时代的产物,要写这个问题的原因,我还可以再写一篇文章,这个涉及到客户端控件和服务器端控件这个概念。这些概念有兴趣的人可以去看,最后也许会发现一些BS(browse side)架构和CS(client side)架构的问题。这也是一般web应用和桌面应用采用的不同的架构。jsp, asp这些我说是早期为桌面开发的延续,所以他本身的架构中,很多东西集成的过密,所有界面端的控件,都是在服务器端包好,发送到浏览器端的。不过这也是没有办法的,早期没人想到互联网会发展到现在这个地步啊。
而为何互联网上就没有像桌面上这样出现UI框架呢?我觉得这个问题很简单,早期的互联网上只有文本和超链接,根本谈不上应用。只是信息的传输,这和计算机刚开始时用DOS或者其他的系统是一个原因的,纯文本的世界根本没有GUI,所以早期的互联网也是没有GUI的,这就是互联网上UI框架滞后的一个原因。另一个原因是,当时JS等语言还不成熟,网络上各种协议和格式都还不规范,要开发出这些规范,完善语言,都不是一朝一夕的事情。这些就是互联网上的UI框架不成熟的客观原因。
不过这都不是本质,这些都属于现象。分析这个问题的本质不是按这些网上的名词来思考的。还是按照一些基本分析问题的方法,我是和谁交流?电脑还是另一个人还是另一群人?我们之间有多少道介质,如何让信息在这些介质中传播,等等等等,然后将问题逐渐细化分解,然后再将适合集成的问题集成起来。
4.现在我来讲一下,这个分析这些问题的思路。用程序员们的术语来说就是解耦和集成。所谓前后端分离,就是前后端解耦,就是把原来asp或者jsp那种服务器端一锅端的内容,分到服务器端和浏览器端两个地方。然后行为/内容/表现分离,就是将这三者分成三部分去架构,然后让每一层架构通过一些接口去关系起来。
界面interface也有接口的意思,这都是有原因的。因为界面相当于人这层和电脑这层的接口,人暴露了五感作为接口,电脑暴露了屏幕、音箱、鼠标和键盘等等作为接口,然后人的接口和电脑的接口进行对话,就成为了交互。所以交互设计的思想来源就在这层解耦上面。
设计的关键,在于将问题细分到什么程度,也就是将模块解耦到什么程度。当然没必要解耦到原子的程度对吧。然后将一些问题的单元结合到一起,统一调度,这个就是集成。每个集成实际上内部就是一个小框架,因为每个集成都有一个小小的内在结构在里面。对应到计算机领域,最后就是数据结构。
这里这个解耦和集成怎么样合理?这就全都是分类学的功底了。人们发明了关系型数据库和面向对象的编程,都是在这层思想的基础上的。所以我会说所有方法到最后只剩分类学。
这是一个普遍适用的方法,绝不仅仅限于计算机相关领域。用这个问题去质问你的设计方法吧。“以用户为中心的设计”?用户真的是一个合适的单元吗?为什么唐纳德·诺曼最近又会提出“以活动为中心的设计(Activity Centered Design)”?那么活动是否又是他对设计方法上解耦后的终极单元呢?
5.JSON、XML这些是围绕着AJAX的各种数据格式,不过即便AJAX不流行,这些也是大量科学家和从业人员整理出来的一些规范格式。各有优缺点,XML通用,JSON轻巧灵活但只有JS能解析这个格式。JSON的流行是一种现象,这是因为现在流行的AJAX中JS算是其中的一个核心,所以JSON可以流行,那么在未来JS不会被替代掉吗?未来硬件性能提高后,不在乎一些效率问题了,是否更通用的XML会再次成为最主流?这种属于各种历史现象。看好那种语言什么的不该是我们的目的。我们的目标应该是了解本质,这样就不会被各种计算机语言的特性困住,而能更好的利用这些语言。语言是工具,不是目的。既然是工具,我们就可以选择。关键是我们要有自己的选择标准。有很多相关的带上“设计模式”的书可以一看,有很多相关于“数据结构”的书也值得一看。看完之后就更能理解这个问题。
这里是我个人设计哲学中的第三个核心——所有工具到最后只剩下一种,那就是语言。计算机的工具是计算机语言,设计的工具是设计语言(符号学等等),绘画有绘画语言(用色,用料等等),音乐有音乐的语言(乐谱),机器有机器语言。
在这个思想下,我们要关注的是我们使用的是哪一种大类级别的语言,而不要在小类上纠结,那样只能变成一个执迷于细节的工匠。
以上每一条,其实我都想单独写一篇博文,无奈时间有限,最后还是只能拼凑这么一篇笼统的文章而已。不过希望能抛砖引玉,各路专家来纠正文中谬误,扩充文章内容,增加相关知识。
收藏到:Del.icio.us
- 对于你第一个问题的答案,我好像在哪本书上见过,不过印象已经很模糊了。。。应该还是从人的心智模型出来的,不过可以肯定的是,在创造的时候是没有研究心智模型的,就是你说的巫术。










评论
它只是个数据的标记法(Notaion),所以并非 JavaScript
依赖的,官方网站链接的 JSON 处理库已经几乎涵盖了所有常用编程语言。
与它相似的,还有 YAML,两者都是很简明有效的数据结构表示方式,比起 XML 的纷繁冗余,清爽太多了。