-
Notifications
You must be signed in to change notification settings - Fork 0
Lesson 3: Deal with the unknown set of developers and devices
The unknown is out there: you have to deal with the large set of unknown developers and devices.
Put something on the internet and basically everyone can reach it. The same applies if you publish a dataset as open data. For wide adaption you need to know who may want to use it, how and when. But nowadays, by opening up software systems and using a supply-driven approach, every developer in the world could implement and embed your data on every device. This means a publisher should manage the community, and take certain security and performance risks into account.
One important aspect here is the Time To First Successful Call (TTFSC). Being capable of doing a successful request to the API within a few minutes will increase the chances that the developer will stick to your API.
To help developers on their way to get started with your data, you need to provide good documentation, code examples and so forth with your dataset (API). This will improve the Developer Experience (DX).
Options to filter the data should be clear to a developer. Even though the meaning of a dataset can be clear, it can still be a lot of work to fully understand its possibilities. Metadata should not only explain what the meaning is of a field, it should also include what form the data can take. For example, when data is categorized, a developer would like to know which categories exist. Or in the case of zip codes in the Netherlands, that the format is always four digits and two letters. When this information is available, developers will know what to expect, run into fewer errors and get what they want sooner.
Furthermore, to make your data API better workable for a large group of developers and devices, you could follow these approaches:
The second phase of the testbed confirmed that this is perhaps the most important of the lessons learned with regards to software developers. Current data services in the testbed do not always apply these lessons learned and are difficult to use by a developer.
All this is not only in the interest of the developers, but also of the data providers. For example, if a data provider does not document the limitations of his platform, web developers will go search for the limits themselves, which could result in unexpected high payload for the data platform.
The use of persona to define and test the Developer Experience is a powerful method that can be used when defining data APIs. Multiple personas can be used to represent different groups of developers, with different skills, and using different devices.