The success of your data product is directly related to how accessible it is. And how do we access data? Through interfaces. But interfaces are everywhere, and how those interfaces are designed ends up impacting our lives profoundly. As strategists and builders, we can notice interfaces and build more accessible products, services, and processes.
Everyday Interfaces.
Data is an awkward product. It is only really useful when there are tools and processes to consume or understand it. Independently of tools, data is useless. For some data products, interpretation tools are intrinsic to the human experience, such as a price tag. I can consume that data visually and decide if the sweater the tag is attached to is a fair price. Then, I can take that sweater to a cashier and carry out the purchasing process. I can then choose to head home or conduct other business. In doing so, I interface with numerous human and digital processes. I interface with data, people and things. Some of these interfaces are well-designed, and some are painful. Some interfaces are equitable; some are not. If I were visually impaired, the above process would be impacted; the interface would break down.
When I think of interfaces, I think about a process and how one might interact with the process. The input and outputs, if you like.
Interfacing geography.
In modern geospatial, I talk about openness as a complementary asset. One facet of openness is the interface to a product. Geography is somewhat unique. By existing, we all consistently interface with geography. Now, as an office worker, perhaps my geography doesn’t change as much as I might like, yet by existing, I have a location and, therefore, have a geography.
When we try to represent the geography of places we are interested in, perhaps for planning purposes, things get more complex, and we are challenged to think abstractly about geography. In doing so, we have built models of abstraction called maps. Maps are interfaces which demand a surprising amount of supporting experience. In many ways, maps are bad interfaces.
User Interfaces are like jokes; if you have to explain them, they’ve failed.
I have no idea who first said this, but I generally agree. This is also true for maps, geography, data, and derivative analytics. We need to start thinking more deeply about interfaces. Interfaces between machines and people.
A reasonable modern geospatial workflow model assumes that people start and end things and machines do things in the middle. However, those middle things should not be assumed to be a single monolithic activity.
The logical implication is that we have:
people talking to machines,
machines talking to machines, and
machines talking to people
All of which can be good or bad experiences for the parties involved. Again, let's not forget that most technology problems are really human problems, but some human problems can be solved through machine-to-machine communication. (Some, certainly not all!)
Clearly, I’m not talking about the interfaces between people here. Better humans than I have discussed that topic for thousands of years, and we still have bitter disagreements.
APIs and taking care of business.
With apologies to Randy Bachman. The power of interface thinking is in distributing responsibility. By considering interfaces, we can assume that the work of a machine or process is being done within the context of a task. An Application Programming Interface (API) can access a procedure or process that takes care of business.
For many of us who have emerged from the tech sector, the notion of an open API is simply obvious. However, there is still a mixed adoption in the geospatial community, especially around data and data access. Open doesn’t necessarily mean free; it means accessible, well understood and reliable. This means that an API endpoint will receive a request with a payload and subsequently operate in a repeatable well understood manner.
Open APIs allow different machines to access a particular workflow in a structured manner, allowing for ease of maintenance and a building block approach to designing digital systems.
Data is an interface.
However, this is not just about systems or workflows; data itself can have an interface. I started this post with an assertion that data products rely on tools for interpretation. I believe this is true, but those tools can be built into the data itself in the form of metadata.
I know I’m getting old because I have started to evangelize about the value of metadata - </sigh>
However, a data product can be viewed through the interpretation of a metadata standard. The SpatioTemporal Asset Catalog (STAC) is a great example of this. Using metadata as if it were a prism from which to extract different spectra from the data allows the data product to operate similarly to the API-powered workflow: some of the internal workings of the product can change without disrupting surrounding workflows.
The effect of distributing responsibility means that APIs and Metadata hold the keys to building robust workflows, but they must be carefully designed and can rarely change. Indeed, a natural benefit of the distributed responsibility idea is a natural defence against error propagation. As various API and metadata gateways are navigated through, consistently sensible requests must be made, ensuring that anything erroneous or unusual can be identified.
Interface thinking allows us, as strategists, to design better systems and distribute responsibility effectively. It is worth noting that systems can be carved up into parts that are too small and parts that are too big. I will leave the distinction of sizing digital and human responsibility to you, but do consider the interfaces surrounding us and how we can build better digital and human systems.
North51
A short note on North51. We have assembled a ludicrous line up of geospatial deep thinkers. If you are looking for more discourse, like what you find on Strategic Geospatial, take a look at who is coming to Canmore in April.