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.

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?

  • 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.