比如API约束了调用顺序，约束了接口之间的某种调用关系，并且这些约束是一般开发者不能提前思考清楚的。

比如地图API里可以给标注添加一个标题，当鼠标移到这个标注上时，就会显示这个标题，实际上，这是给标注的DOM容器元素增加了title属性。开发者在使用过程中可能会使用下面的写法：

var marker = new BMap.Marker(map.getCenter());  // 创建一个标注对象，并给定一个坐标点
marker.setTitle("百度大厦");            // 标注创建完了，给它加个标题
map.addOverlay(marker);             // 好了，添加到地图上

当我们把鼠标移到标注上，“百度大厦”四个字并没有显示，哪出问题了？API文档那个上明明写了这个接口的作用呀？实际上，只有下面的写法才能实现：

var marker = new BMap.Marker(map.getCenter());  // 创建一个标注对象，并给定一个坐标点
map.addOverlay(marker);             // 先添加到地图上
marker.setTitle("百度大厦");            // 再给它加个标题

其中原因很简单，由于标题是添加在DOM元素上的，那么在调用addOverlay方法之前，DOM元素并没有创建出来，setTitle发现DOM元素不存在就直接return了，也没有把这个title存起来，那么后来再添加到地图上也就看不到标题了。

这里，API就存在一个调用顺序上的约定，使用者可能在经历了失败时候才会知道这个约定，好在调整起来并不费力，至少代码没有白写。

一个好的API应该尽量减少这种不合理的约定。另外，如果想减少开发者的思考代价，一份结构清晰的文档是必不可少的。

Penetrability

How does the API facilitate exploration, analysis, and understanding of its components, and how does a targeted developer go about retrieving what is needed.

这个维度是指开发者需要理解API的底层实现细节到一个什么程度以及对这些细节的理解程度，也就是说API的透明程度（penetrability）如何。

比如，一个封装了很多底层接口的API需要使用者理解这些底层实现细节，否则API就不能正常工作。

API Elaboration

To what extend must th eAPI be adapted to meet th eneeds of a targeted developer?

开发者使用API来完成任务，其中一些任务仅仅通过调用几个API的现有接口就能完成，另一些任务可能需要继承API的一个类，并重载一些方法来完成，还有一些任务可能需要开发者自己编写接口的具体实现来完成。

这个维度描述了API暴露出来的扩展性，即API有哪些接口直接使用的，有哪些需要开发者自己继承扩展的，有哪些是开发者自行创建的。

当用户使用地图API时，有些功能可能是API中没有提供的，这时候就需要开发者自己写一些模块来处理（就像线上的百度地图）。

对于一些简单的任务，API要尽可能提供现成的接口供开发者使用。另有一部分开发者对接口的灵活性要求更高，希望通过扩展现有的API来实现自己的功能。API最好能同时满足这些不同的需求

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

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

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