昨天参与了一个临时任务的开发工作,主要为了解决企业管理软件在BS模式下,那些需要高频率访问单据的可用性、易用性的问题。
先简单介绍一下环境,BS模式、ajax框架(zk)、compiere企业业务。目前存在问题主要体现在用户体验差:a.可用性Explorer和服务端的频繁交互(界面展示、业务规则、业务逻辑等),导致用户响应延迟;b.易用性 用户操作不方便,不能很好提供快速操作方式(纯键盘、辅助输入等) ;
相关负责人出具了如下“解决方案”:a.使用Swing提供人机交互,以便提供较好的用户交互感受,同时在Explorer中使用java实现界面控制、业务规则、业务逻辑处理; b.使用applet集成到Explorer中;c.可用重用公司积累的富客户端资产;
初看起来,这几乎是一种很不错的方案,在很大程度上解决了前面的问题。企业业务固有的复杂性和特殊性,和程咬金式需求,使得问题的解决过程远远没有想象中的那么平坦,相反使得整个过程显得耐人寻味。
因为应用的业务结构和实现方式的特殊性,使得业务规则、逻辑的客户端化工作进行得很不顺利,从实际分析来看相关业务逻辑的迁移变得得不偿失;最后不得不对方案作折中:UI事件、控制继续在客户端处理,业务规则、逻辑则被迫驻留服务端。虽然项目组的大部分人都认可这种方式,但我认为事情已经到了一个比较尴尬的境地了。
最终的这种方案,还能解决我们最初的问题吗,会给用户带来好的使用体验吗?这个“?”变得越来越大,越来越不可预估了。最终的结论还需要真实地数据来说明,但不管结果怎么样,这种折中方案带来的问题,远不是只有实现层面这么简单。
当问题的发展和我们的预期相违背时,是时候回头看看我们是不是已经在技术的沙漠中迷失了最初的梦想。我们在人生旅途中又何尝不会出现这样的场景。