我相信博课堂的兄弟们、以及常看博课堂的兄弟们，一定会同意我的看法：显然，通常所说的B/S并不能和“先进”画等号。那些在技术改造道路上将目光瞄准在把Windows Application迁移到Web Application的，是值得再反复思量的。最近我就接触了三个例子，充分说明了一个道理：不要盲目跟风，不要盲目的上Web Application，不要盲目的转向.NET或者J2EE。
例子1，航空订票系统
今天上午去公司的Travel Desk订星期五回上海的飞机票，结果很让我高兴：买到了5折的。要知道，前两个月，7折都是很罕见的。订票的时候，我仔细观察了一下那个终端：是在Windows上开了一个绿色的字符终端，直接敲命令查询航班，返回结果也是一行行的字符输出。返回的结果我是看不懂的，但Travel Desk的人就能看懂：他一眼就能看出有多少折扣，还有没有位子。而我只看到一串不知道什么意义的英文字符。
从纯粹的技术人员的角度来看，这种Client端显然是应该被淘汰的：操作不是GUI的而是Cmd Line的，查询是通过命令字符串而不是一个友好的Query Builder界面，返回结果也很不friendly。但我觉得这样的界面是很好的，因为它的用户已经习惯了用这样的界面，而且根据我的观察，Travel Desk的人操作起来很快，他们也能毫无困难的理解那些我无法理解的返回结果。所以，如果我是技术主管，我一定会反对任何把这种界面升级到GUI的提议。我的信条是：没有充足的理由，不要改动正用得好好的东西；没有充足的理由，不要引入新东西。
例子2，银行
根据我的观察以及我的一个同事跟我的转述，很多银行柜台上的服务员是纯粹通过数字键盘来操作他们的终端的。我同事说，他们的终端应用程序也是字符界面的，通过菜单访问。例如，第一层菜单是（假设的）：1-企业业务；2-个人业务。如果选了“1-个人业务”，第二层菜单是：1-开户；2-提款；3-存款；4-改密码。以此类推。久而久之，柜员脑子里面记住了很多数字串和功能的对应，例如“1-3-2-4”就是功能A，“2-5-1-1”是功能B，...，这样记熟了以后，操作起来非常非常快，远远比鼠标快。
当然，我也看到过有一些银行的柜员终端是Win32 Application。我觉得他们的操作速度没有“1-3-2-4”那种快。所以，如果我是银行的技术主管，我始终会坚持用那种字符界面加数字键盘操作。没有任何理由把柜员的终端改成Web Application——那多慢啊。
例子3，一个电厂监控系统
我们公司在北京有一个partner，做的产品是电厂和各种生产监控系统。他们的产品真的很不错。例如，可以在一个Win32 App的界面上看到一个很形象的大图，图上错落有致的排放着工厂里面所有的锅炉、管线、仪表等，每个锅炉或者管线边上都实时显示控制参数，例如锅炉的温度。如果温度过热，还可以变成红颜色。我问他们是怎么做的，他们说这是他们花了四五年时间积累下来的，都是用ActiveX开发的。
那天我去的目的之一是看看能不能有推广.NET技术的契合点。但看了他们的系统演示以后，我觉得如果我是技术主管，我坚决反对把那些积累了四五年的ActiveX控件升级到.NET——升级麻烦，也没必要。
--
最近这几个例子让我觉得，如果不根据实际情况一味单纯推.NET或者J2EE或者其他什么新东西，是对客户的一种不负责任。
打印 | 张贴于 2004-06-07 14:06:00 | Tag:Software Engineering
留言反馈
不过这种东西初学者不易掌握，如果系统上能直观显示折扣与空位，岂不是更好，为啥非要搞那么晦涩？
至于菜单
我确实开发过这种应用，那是在 Informix + 4GL 上开发的，菜单全在顶层，包括 Informix 本身的数据库管理程序 dbaccess （类似于 SQL Server 的 Enterprise manager）也是这样的。
用习惯了是很好，但也有很大问题：
1) 如果同级菜单太多，数字无法编码，也不好显示
2) 扩展性差，如果在“存款”里的有"1定期,2 活期" ，现在要增加“定期通知存款”，它应该和定期紧挨着，现在该编什么码？
在我们这儿，所有的交易有交易码，以 4 位数字，可以直接输入4 位数字以进行交易，但时间长了之后，就发现交易码不够用，类别不好管理，无法由各分行自定义等 ...
另外，我觉得在 Windows/Web Application 上，也可以不用 Mouse 呀，只要你的系统 UI 实现的足够好就成了，我们就做过完全不用 Mouse 可以在 Linux GUI 和 Web 上完全实现和 Terminal 一样的快捷键盘操作，用着感觉就很好。
另外，我一直想做一个监控的画面，在winform下这样做效率太差，【大家有什么高招给指点一下，好吗？ xpoint@126.com 】。每次刷新数据的时候都要连接数据库，取数据，断开。如果监控的数据来源与10个表，每个表的数据有100万条以上怎么办？不如unix下的重定向吧。或者干脆printf(...)直接显示到监控的终端上。
而助记符只是在文字终端下不得不采取的一种形式. 这种方式对于一个分支很广的企业来说,十分有用.
无论GUI或者Web都离不开local OS的支持,这是银行不喜欢采用这些UI的原因. 我自己就是从银行出来的.
( 也许有Web图形终端,但价格一定不菲).
因为航空公司的业务开展很早，所以一般的航空公司的数据服务器都在UNIX上的，返回数据也是早前固定好的格式。但是随着客户端操作系统的易用性方面的不断演进，目前很多的终端都采用了Windows座操作系统。
我知道的几家航空公司的做法是这样的：
在终端上，使用高级语言如C/C++来处理与UNIX主机的通讯；然后使用Java Swing来做用户界面；C/C++与Java之间使用JNI接口调用。
别笑这办法很土，很多公司都这么搞的。包括文中提到的那个类控制台终端，那时用Java画出来的阿，55~~~，累死了。
Yukon 和Sql Server2000相比绝对是一个飞跃，尤其对于开发人员来说。Beta2大概这个月底就会release了。
对键盘操作就支持得很好。
其实，UI和开发工具关系不大。
这样你在做新项目的时候就可以选择合适的产品。
.net超前不超前并不是我关心的，这个也没有一个合适的定义
我只关心使用这个是否可以给我带来利益。
BTW，其实我不关心.net，不关心vs 2005。我只关心yukon beta2。
虽然我并不是每个项目都使用sql2k。
但現實中有時候並不那樣。
人家被你吹得暈乎乎的就賺到錢，而且有的就喜歡你吹(自己暈了也不知道)
你把上面的话对客户说了一遍
回来以后，单子没了。
--
这种情况多了去了。
而且，就算我是甲方的，我的老板也未必能听我劝。上了项目是老板的政绩，花掉预算老板也能拿回扣。
所以，我也只是说说而已。
过年的时候去订票，订票的人不熟悉我要坐的那个航班号，结果查了半天代号。
新的方式不见得比Terminal方式差，只是用户有没有细心提出这个需求，设计者有没有动脑筋去设计。
很多公司上项目根本没有考虑最终用户的需求，变成大富翁游戏了。
你把上面的话对客户说了一遍
回来以后，单子没了。
我们公司也有一些，键盘操作的效率远远高于鼠标点击，所以，这种“劳动密集型”的工作用这些终端没有什么问题，，，UI可以改进的友好一些，，，只要键盘操作的方便性不变就可以了。
对于高级一些的程序，UI还是很重要的，，，过分复杂晦涩的UI会提高客户掌握的难度的。。。
比如travel agent的确普遍使用文本终端，但是网上订票的界面要好看好用也慢多了。