需要一行代码

经过上面一番描述，API的工作单元可通过如下方式描述：

如果用户编写的代码包含在一个本地的代码块中，并且代码可以递增式的完成，那么工作单元可描述为本地递增式（local incremental）。

如果用户编写的代码包含在多个代码块中，或者代码需要多个类来交互完成，那么工作单元可描述为并行式（parallel）。

如果用户编写的代码既不是本地递增式也不是并行式，而是处于一种中间状态，那么工作单元可描述为功能式（functional）。

可以看出创建自定义标注的过程是本地的递增式的

Progressive Evaluation

To what extent can partially completed code be executed to obtain feedback on code behavior?

这个维度描述了开发者在编写每个任务的过程中，是否很容易的停下来并检查自己的进度完成情况。

如果开发者在写完每一行代码就能够停下来评估进度，那么API支持单行代码级别的评估。

如果开发者在写完两个或更多任务的代码后才能评估自己某一项任务的进度，那么API支持功能级别的评估。

如果开发者需要同时使用多个类，并要求类之间的状态要保持某种一致性，这样才能查看自己的工作进度，那么该API支持并行模块级别的评估。

我们还拿上面添加自定义标注的任务来举例，它最接近第二种情况。因为在创建icon和marker实例后，开发者并不能看到目前已经编写的代码是否OK，他/她需要执行第三个步骤，即把标注添加到地图上之后才能看到整体的代码是否正确。

Premature commitment

wiki上的解释为：

Are there strong constraints on the order with which tasks must be accomplished?
Are there decisions that must be made before all the necessary information is available?
Can those decisions be reversed or corrected later?

微软将其改为如下说法：

To what extend does a developer have to make decisions before all the needed information is available?

开发者在使用API完成任务之前，有时不得不提前思考一些问题，比如使用API的哪些接口完成任务，它们之间有何联系，调用顺序是怎样的等等。那么开发者的思考代价有多大呢？

是在写代码之前就能轻松得出结论，还是写了一些验证性的代码之后才可以，还是整个代码都写得差不多了才发现当初思考的方式并不正确，需要重头再来？

如果开发者在使用API过程中经常遇到最后一种情况，那么就认为该API含有过多的不合理的约束（我对premature commitment的理解）。

出处：百度泛用户体验
责任编辑：bluehearts

上一页 认知维度与API的可用性评估 [4] 下一页 认知维度与API的可用性评估 [6]

◎进入论坛网页制作、WEB标准化版块参加讨论，我还想发表评论。