The user is an API

The best interface is no interface. In his Don’t Make Me Click talk, Aza Raskin (the son of famous human–computer interface expert Jef Raskin) eloquently explains that the best shovel is a hole.

Don’t Make Me Click by Aza Raskin

Although we still haven’t found a way to make completely invisible apps (hopefully AI will get us there), a good guideline is to only prompt the user as a last resort.

Only prompt the user as a last resort.

For example, if an application needs access to the user’s location, it should first try to call the location API. Only if that fails, should it prompts the user for manual input. Whenever user input is not absolutely necessary, such as when a drop-down only has one option, it shouldn’t be requested.

Today, building an application that follows the above guideline requires a lot of effort. Most people assume that interacting with an API and interacting with a user are completely different things, and have adopted different tools, strategies and abstractions for dealing with them. But what if they were the same things? What if we started thinking about the user as just another API? What if the code for getting the user’s location was the same, whether it ultimately asks the GPS or the user?

What if we started thinking about the user as just another API?

When you start thinking about your entire system as a collection of API calls, and stop thinking about the user as a special case, things become very interesting. You realize that API calls are just functions, and an interesting property of functions is that you can compose them. All you need is the type of inputs and outputs to match, like dominoes.

• Need access your user’s avatar? The same line of code should be able to access the avatar the user previously selected, or prompt the user with avatars from linked accounts (Facebook, Twitter, Gravatar), the device’s camera roll, the camera, a drawing app, a random avatar generator, or any API that outputs an image (or something that can be converted to an image using other APIs). If necessary, compose the function with image cropping APIs (automated or manual), image resizing APIs, image compression APIs, moderation APIs, etc.
• Need access to your user’s location? The same line of code should be able to access the cached location from 10 seconds ago, the GPS location, the cell tower triangulation, the last Foursquare check-in, or prompt the user for his location using a map, text input, or even speech (by composing with a speech-to-text API).
• Need access to your user’s destination? The same line of code should be able to access the next destination from calendar events (Facebook events, Google Calendar events, Meetup event, Outlook meeting), wallet’s tickets, previous destinations, recent “opening hours” searches, or prompt the user for his destination using a map, text input, etc.
• Need access to your user’s package tracking number? The same line of code should be able to access recent orders from linked accounts (Amazon, eBay, Best Buy), tracking numbers in emails, or prompt the user’s package tracking number using the camera (by composing with a QR code, bar code, or OCR API), or text input.

When you realize that the user is just another API, you notice that a lot of existing API concepts naturally apply to it:

• Caching: Do I already know the user’s answer to this question?
• Offline: What can I do when your user isn’t able to interact?
• Serialization: What language does the user speak?
• Batching: Can I group all these questions into one?
• Load balancing: Can I ask this question to another user?
• Load scheduling: Can I ask this question at another time?
• Versions: How do I accommodate users who prefer the old UI?
• Exceptions: How do I deal with users who interact unexpectedly?
• Documentation: What do I know about my users?
• Analytics: Why is my user’s response time increasing and availability decreasing?
• Authentication: How do I prove my authenticity to the user?
• REST: Can I standardize the UI using entities and verbs?
• Microservices: Can microinteractions improve user experience?
• GraphQL, OData, Swagger, JSON-LD, SOAP, Stateless, Pagination: ?

I strongly believe that thinking about the user as an API is the key to the next user interface revolution.