The UI/API divide

This past weekend I attended a fantastic workshop on APIs (Application Programming Interfaces). [For more general info see the series of articles by Julie Meloni and the workshop’s introductory remarks by Raymond Yee.] For my purposes here, I consider APIs as the technology that facilitates access to data. A library website might use an API to get information from its database; your email client might use an API to get messages from your mail server. The workshop, funded by the NEH and hosted by the Maryland Institute for Technology in the Humanities, brought together a variety of humanists, librarians, and technologists in various capacities to share their experiences, think about best practices, and to think about the future of APIs in the humanities.

My principal reason for attending was to learn about what people are doing with APIs and how current API development can enable historians to access and manipulate the vast amount of the historical record now coming online—especially since increasingly numbers of non-programming mid-tech historians want to play with data, and have conceptual, if not technical, facility with APIs. I wanted to explore the extent to which audience (especially a non-technical one) should be a larger concern in API development, rather than continuing to see APIs as fundamentally for programmers by programmers.

Early in the workshop, I tried to engage with the provocative secondary conversation happening in the Twitter stream. I tweeted a question asking how much API development should consider non-programmers as their users. The only reply, from MITH’s Doug Reside, answered “not at all”, since that’s what UIs (User Interfaces) are for. In a way possible (acceptable?) only via Twitter (at least in form), Reside included a not-so-oblique admonition to #StopScopeCreep. The rejoinder was clear: the development of the technology to get and serve data (the programming interface) should remain independent from the development of the tools that the user employs to get at the data (user interface).

Such a reply perhaps summarized the sentiments of many of the participants (to judge by the conversations that happened over the course of the workshop). In my opinion, however, invoking the traditional separation between the UI and the API entirely misses the point of the question. In fact, such an attitude might well slow the adoption of new methodologies in the humanities that require APIs.

Granted, drawing a clear distinction between a UI and the API it uses on the basis of scope (i.e. job description) prudently addresses the practical realities of software development. Designing and implementing APIs have innumerable intrinsic challenges—largely to what the workshop was dedicated to exploring. Adding more responsibility to the developers who make them does not necessarily make for more usable APIs. Shouldn’t a good API remain agnostic of its use?

Precisely because so many of the interesting discussions brought up but did not pursue the question of audience, I want to elaborate here my own motivation for the question and my opinion on the matter. My larger point, obscured by my original phrasing of the question (not Twitter itself), was that we need to think more about how data is actually used and by whom—which means thinking about designing APIs for use by a broader audience in the digital humanities.

Partly from more attention from ‘analog’ humanists, and partly from proliferating digital humanities courses, the audience for APIs in the humanities has grown and continues to grow. As a result, humanists have shown new kinds of technical expertise—a “technical middle class” (for lack of a better phrase)—who cannot write code on a sophisticated level, but certainly have some understanding of what can be done with APIs, and who now have enough skill and curiosity to play around with them and the data they can provide.

The central concern in API development has centered almost exclusively around “exposing” data. No surprise here: this is certainly what APIs are designed for and what they do well. But expose to whom? The model user (to subvert a phrase from Umberto Eco) is in this case another programmer, someone who can make API calls (in a web application, say) and process the resulting data. As Reside’s reply implied (sorry, I had to), the model audience must also include UI designers, who provide users an entirely non-technical way of getting at the data. But as the consumer of audience is changing, the profile and identity of the model user is changing as well.

As a result, as humanists get access to almost mind-boggling amounts of raw data—scholars who have some knowledge of methodologies in text mining and visualization— perhaps it’s time to stop thinking about APIs as being only by programmers for programmers, but broaden their intended audience. However, this is not to say that all APIs, with all of their diversity in function and purpose, must necessarily embrace such concerns.

Besides, there are good reasons for holding a UI and an API as entirely separate propositions. They certainly can be considered as fundamentally different “things”. But I do not mean to suggest that they should be considered as essentially the same thing. An interface to browse and search data requires important and difficult work to facilitate a productive user experience. Nor do I suggest that APIs should be designed and developed with a complex interface.

Instead, I submit that the line between the UI and API has blurred with the rise of a sophisticated humanist audience that wants, and increasingly needs, the most open possible access to data—but without having the expertise to write their own programs to get it from traditional APIs. Yes, it is true that the ultimate digital humanists’ arsenal is stocked with various of scripting languages and protocols, but this seems like a long way away (if even possible), and possibly not all that useful anyway. In terms of bridging the humanist/technology gap, isn’t it easier to slide the APIs a bit closer to the humanists than the other way around? A number of quick demonstrations at the workshop showed movement in this direction. For example, making small changes to the URL of a search is one easy way to make an API more directly accessible to the end-user.

BUT, contrary to my larger point here: perhaps as the API-hungry audience grows, developers of APIs should think even less about ideal users and instead aim for the most general functionality possible. To be sure, API developers normally don’t care about who is getting data and why. They just want to make data available in a clean, fast, reliable way.

This attitude would work if we all used Platonic UIs, entirely unobtrusive and invisible. But of course, as Platonic forms are wont to do, such UIs remain elusive. Even the best of them rarely provide unfettered access to data and often, because they are designed to mediate between the user and data, functionally they provide roadblocks to the data itself. And their labor-intensive nature makes adaptation slow at best. Why impose an unnecessary middleman? The digital humanities machine has trained new API-aware members; tools for handling data have become more visible and usable. Now we need better access to raw data. And this is, of course, the job of the API—with perhaps a bit of UI sprinkles on top. Could this be considered scope creep? Okay, I concede the point.

But it seems as if the cost/benefit ratio for stepping outside the traditional UI/API boundaries is a wise investment in the future of the digital humanities. If nothing else, easy access to data in this way can help facilitate the scholarship that digital humanists keep saying is so great. Let’s make it easier to create examples.