@
FarmerChillax 对普通用户门槛提高,一个是因为哪怕以可视化的操作提供给用户,对于一个完全不懂的普通用户来说,有些东西,一时间也难以进行操作,第一时间也不知道如何使用,我帖子里面的 STM32 的示例动图 1 ,里面的芯片引脚就是一个例子;再者是生成代码以后,后续的编译等工作,普通用户难以完成。
可阁下可以想想,再以 STM32 的示例动图为例,像里面的那些芯片引脚,其实只是让用户稍微理解一下是什么意思,按照实际情况选择一下而已,哪怕真的完全不会,开发者直接事先设置好,然后让用户对此没有任何需求进行更改的话,直接按照开发者默认设置即可。这种提供可视化的操作思路的背后,不是简简单单的把代码逐句翻译成中文,然后让用户再去学习这项技能,而是直接围绕开发者事先设想的某种应用场景,在该场景下,把能提供给用户进行选择或者调整的地方,通过可视化的功能让用户得以通过自己的需要进行局部的个性化调整,这也是这种所谓搭积木的交互方式,适合的场景所在。普通用户只是不会,不是说他们是傻子,连稍微听一下人家说明一下,然后按照自己需要进行选择的理解能力都没有,而且这种方式,从实现方式而言,本身也只能尽可能满足一些功能简单的需求(可以再进行迭代让实满足的需求更进一步),而对于一般用户来说,由于他们不是开发,往往也难以提出一些复杂的功能需求(如果有,那也不应该使用懒农,而是直接找开发定做),当数据文件的数量达到一定程度,是可以很大程度对此类需求进行覆盖,再通过技术上,让用户表达实现自己所需要实现的效果,来匹配到对应的数据文件的。
至于生成代码以后,后续的编译等工作,确实对于普通用户来说难以进行,这也是我将项目开源并且推动的原因之一,当代码生成以后,后续的工作,由于代码的确定,很大程度已经是一件明确的事情,而且由于数据文件的原因,同一个数据文件生成的代码,后续的工作相似性较高,如果能提供环境整合等服务,可以进一步降低门槛,让更多的普通用户可以得以普及。
对于开发人员看都不看一眼的问题,那纯粹是开发人员想把懒农当做提高效率的开发工具来用,才会有这种想法,懒农从设计开始,本来就不是作为开发工具使用的,对于开发人员而言,懒农能发展起来的话,它更多可能是作为像一个给开发人员通过自己的技能知识,还有项目等作为对外展示自己的渠道,或者说提供了一种高复用、边际成本极低的方式,来通过满足普通用户对一些功能简单的需求的快速实现,来创造经济价值的一个工具而已。