激活该程序

rel="File-List" href="file:///C:%5CDOCUME%7E1%5Cfeng%5CLOCALS%7E1%5CTemp%5Cmsohtmlclip1%5C01%5Cclip_filelist.xml"> rel="Edit-Time-Data" href="file:///C:%5CDOCUME%7E1%5Cfeng%5CLOCALS%7E1%5CTemp%5Cmsohtmlclip1%5C01%5Cclip_editdata.mso"> rel="themeData" href="file:///C:%5CDOCUME%7E1%5Cfeng%5CLOCALS%7E1%5CTemp%5Cmsohtmlclip1%5C01%5Cclip_themedata.thmx"> rel="colorSchemeMapping" href="file:///C:%5CDOCUME%7E1%5Cfeng%5CLOCALS%7E1%5CTemp%5Cmsohtmlclip1%5C01%5Cclip_colorschememapping.xml">

昨天参与了一个临时任务的开发工作，主要为了解决企业管理软件在BS模式下，那些需要高频率访问单据的可用性、易用性的问题。

先简单介绍一下环境，BS模式、ajax框架(zk)、compiere企业业务。目前存在问题主要体现在用户体验差：a.可用性Explorer和服务端的频繁交互(界面展示、业务规则、业务逻辑等)，导致用户响应延迟；b.易用性 用户操作不方便，不能很好提供快速操作方式(纯键盘、辅助输入等) ；

相关负责人出具了如下“解决方案”：a.使用Swing提供人机交互，以便提供较好的用户交互感受，同时在Explorer中使用java实现界面控制、业务规则、业务逻辑处理； b.使用applet集成到Explorer中；c.可用重用公司积累的富客户端资产；

 

 

 

初看起来，这几乎是一种很不错的方案，在很大程度上解决了前面的问题。企业业务固有的复杂性和特殊性，和程咬金式需求，使得问题的解决过程远远没有想象中的那么平坦，相反使得整个过程显得耐人寻味。

因为应用的业务结构和实现方式的特殊性，使得业务规则、逻辑的客户端化工作进行得很不顺利，从实际分析来看相关业务逻辑的迁移变得得不偿失；最后不得不对方案作折中：UI事件、控制继续在客户端处理，业务规则、逻辑则被迫驻留服务端。虽然项目组的大部分人都认可这种方式，但我认为事情已经到了一个比较尴尬的境地了。

 

 

 

 

 

 

 

 

 

 

        

最终的这种方案，还能解决我们最初的问题吗，会给用户带来好的使用体验吗？这个“？”变得越来越大，越来越不可预估了。最终的结论还需要真实地数据来说明，但不管结果怎么样，这种折中方案带来的问题，远不是只有实现层面这么简单。

当问题的发展和我们的预期相违背时，是时候回头看看我们是不是已经在技术的沙漠中迷失了最初的梦想。我们在人生旅途中又何尝不会出现这样的场景。