Your Interface is NOT Your Application

By Deane Barker on May 23, 2006

Let me throw out an observation.

Your application is worth exponentially more to me if I can write my own user interface for it.

No, wait – that’s jumping the gun. Let me back up a bit:

Your application is not your user interface. The interface is just a nice, optional add-on.

I believe this is true, though getting software developers to believe it and acknowledge it will be a struggle.

When building a new piece of software, you really need to completely divorce the interface from the API. You need to get in the mindset that your app is really just a data store and a set of logic modules that do something. That is your application.

At the same time, you can build an interface that lets a human interact with your application. This an obviously very important piece, so it should get at least as much attention as the application itself. But never forget that the interface is layered on top of the application. In a perfect world, it can be lifted off and thrown away, leaving a fully-functional API underneath.

This means that the guy programming your application and the guy programming your interface shouldn’t get too cozy. More specifically, the “interface guy” shouldn’t be allowed to know more about the app than the “application guy” is willing to expose to him in an API. The two pieces need to be developed separately.

So, if the interface needs to do something, the application needs to expose methods and properties to allow it to do that. The interface should never “go around” the application by executing SQL or business logic. The interface should be a complete slave to the application. It should end up as nothing more than a pretty way to make API calls.

And why is this? Because, more and more, the “person” running as app is no longer a person, it’s a machine. Applications with strong APIs are worth so much more to me these days because I can run them from code. Let me throw out another theory that may drive the point home with the folks building software:

I will pay vastly larger sums of money for your product if it can be controlled completely via API. And I will move heaven and earth to to encourage a client to buy your product.

True story: a client is paying me to select some software for which they’re ready to pay thousands of dollars. I’m looking at dozens of options, but if a product doesn’t have a full-blown, documented API, it immediately goes on the discard pile. I won’t even take a second look. It’s the first thing I try to find, and if I don’t find it, then I immediately move to the next product.

Why is this so important? Consider —

I’m working with a server-based product right now that has a very strong, and very celebrated, user interface. This interface is the “face” of the product – the thing everyone uses. Unfortunately, a lot of the logic of the app seems to be buried in the bowels of the interface. I can’t find it in the API, so I can only assume they kept that part to themselves, or inextricably wed it to the interface.

I have a set of users that use a very small part of the app. If this application had a fully functional and documented API, I could build a “mini-interface” that spoke directly to the application and let me expose a small set of functionality for these people.

But I can’t. There have been some inroads with this product lately to expose more of the API, so there are some things I can do. But I can’t do everything, and it’s frustrating.

That application is a slave to its interface. No interface, no application.

We talk a lot around here about “exposing the API,” but let me take it a step further just so we’re completely clear:

Your appplication should not only expose an API, your own interface should be forced to use the same API that you expose to the customer.

There’s a tendency to let your own interface “cheat” and do things with its own, special API (or process business logic or from the presentation code itself). This really sucks, because it’s a great way to screw your customers. Why should your interface be any more important than my interface?

Wait, that deserves to be indented:

Your interface is no more important than my interface. In fact, in many cases, my interface is vastly more important than yours and, consequently, it should be catered to and treated like friggin’ royalty.

We talked about this same thing in-depth about eZ publish, which gets very high marks in this area.

The developers of eZ publish had to eat their own dog food when developing the default admin interface, since it’s rendered using the same architecture and the same templating language as the default public side. I’m quite sure the designer who put together the default admin interface really pushed the developers who were writing the template engine, since he had to use it himself.

Not surprising, the templating language is very, very good. The developers didn’t “cheat” (for lack of a better word) and develop the administrative interface with a different, more powerful language than the one they’re making you render the content with. If you can see it on the admin side, you can do it just as easily on the public side.

Not only did this improve the language, but it improved the core API, since if the eZ developers wanted to get at some functionality on the admin site they wrote, they had no choice but to expose it in the API. They didn’t let themselves “go around” their templating language, so they had to make sure it could do absolutely everything you might need.

Not only does eZ let you you use the same template API for your public side as they used for their admin side, but they even let you use the same PHP API their templating language uses to get anything done.

eZ has taken this principle to its perfect conclusion: the user interface that ships with the product is optional. It’s nicely done, and 99% of the people use it, but you’re welcome to:

  1. Toss it and write your own.

  2. Write “mini interfaces” that run alongside the main interface to expose subsections of functionality to different audiences.

It’s an absolutely gorgeous piece of work, and it’s a reason why eZ publish is worth many, many times more to me than any other content management system.

But, as always, there’s a wrench that falls into these gears: licensing. By exposing all this functuionality to the end developer, you’ve given him numerous points in which to circumvent your licensing.

For example: the application I mentioned above is licensed by URL. When you log into the interface, it checks what URL you accessed it under, and will either work or not work based on that. This means that if I write a command line script to do something via the API, how can the software check its license? There’s no URL to verify.

But, let me finish with a final commandment:

If your licensing does not work apart from your interface, change your licensing model.

Yes, it’s that important.

What I’ve explain here is, in my mind, the thing that separates the men from the boys – it separates the products I’ll get pissed off with from the products that I’ll constantly choose, gladly and gratefully rearrange to do what I want, and constantly evangalize to the ends of the Earth.

Rant over.

Addendum: Years ago, I was working in ASP and I was writing my very first COM component. I was taking a bunch of ASP code and wrapping it up in this DLL. I remember turning to Joe and asking, “But how do I know what to put in the DLL and what to leave in ASP?”

His answer was brilliant – he said something like:

The DLL shouldn’t know or care if it’s being called from ASP in a Web app, or Visual Basic in a desktop app.

I remember he said it without even looking up from what he was doing – the answer was that simple to him. The DLL was my application. The ASP was just the interface.

The interface should be so divorced from the application, that the application shouldn’t care what is talking to it. The interface should be interchangeable.

Amazing that all these years later, I’m writing about this very same thing.

Comments (6)

Ian Muir says:

I’d have to agree with you in many ways Deane. In many cases, the default interface of an application is great, but sometimes it just doesn’t cut it. As a UI designer, you will constantly be working with clients of various skill levels, cultures, preferences, etc. This often leads to the need for a customized interface.

When creating new software, it’s rather easy to seperate the API from the interface. As you said, it forces the developers to provide all the tools that their users might need. The problem comes in when working with existing software.

With small target software package, the interface is usually designed with a certain audience in mind. The interface is designed for that audience and in many cases there is little or no API. The software continues to develop and evolve and at some point you’re no longer dealing with the audience the interface was designed for. If the interface is tied to business logic or a DB, then the developer needs to backtrack through the interface and seperate it piece by piece.

I’m actaully glad I read this. It’s made me take a look at some of my own code and realize how much of my functional code is tied up in my interface. I also know the server-based technology you’re talking about and I know that they in a similar process of re-examining and extending their API.

Joe says:

I agree with this on two points:


Your UI and your system have to be separate. If you can’t easily separate them, you can’t modify the design easily, and you can’t reuse the system.


You have to have a good, understandable, and (preferably) documented API. Without it, your app limited to its original purpose. With it, your app is only limited by the imagination of the people using it.

However, it seems to me that the purpose of the system is to drive a really good UI. To your user, your UI IS your app. The app should be developed screens-first. If you develop screens from the API, you’ll end up with something that makes good sense to the programmer, but not much sense to the user.

Design your screens first, know what the app is supposed to do, and then make sure you have a good API to back it up.

Sauron says:

It’s amazing how that which I take to be obvious is considered a revolutionary idea among others. One of the biggest arguments for a *nix system is that most programmers understand the difference between and interface and an application. However, this quickly turns into one of the biggest arguments against *nix systems, as many applications don’t have an intuitive interface (or any interface beyond the command line functions, in many cases) included, counting on the user or another kind programmer to develop the interface.

AN says:

This was a good piece, though I wasn’t really sure we were on the same wavelength until I got to the end and found

The DLL shouldn?t know or care if it?s being called from ASP in a Web app, or Visual Basic in a desktop app.

The application framework my team has built was designed with this as a grounding principle. We started writing a replacement in .Net for a surprisingly effective MS Access application, and one of our initial directives was that we had both to replace the desktop application our clients were using and to provide a web interface for clients who preferred that path. So everything simply had to work both places, or it was worthless.

This informed pretty much every design decision, because the sheer breadth of the app was big enough that if anything gratuitous had to be done twice, there was no way we would ever have shipped the web version. Because of this requirement, we ended up with an architecture in which not only the business logic and database access was abstracted, but even the interface design. That way, if you design a form for the desktop client, it’s automatically there for the web interface.

The net result is that we have an interface design system that’s completely abstracted between windows and web, and anyone who is interested can tack on new interface components up to and including throwing all of the forms away and starting with a blank slate.

Our program API for accomplishing this under the hood uses rock-solid abstraction between the interface and the data and logic, but we haven’t gone out of our way to really open up the API to anyone else yet. As we get people who are interested in programming against it in completely different ways, the hard part is going to be figuring out whether to open it up as is (in all its highly abstracted ways) or provide a configured intermediate piece that makes it easier for people who aren’t code ninjas to understand.

This piece provides a good perspective on how to make that decision. Thanks.

Chip Chippington says:

Great post, and prescient. Four-and-a-half years later, I’m supposed to be leading customer-facing API product development for a bunch of applications, but instead am working on pulling out all sorts of business rules out of the UI that should be in middleware or the backend already to lay the ground work for APIs. I hope more developers and business leaders working on tech-driven products read this post to understand that layer abstraction for their application’s future is as important as delivering to market on time.

owen says:

only problem is once you start building all your applications as client server apis you begin to waste a large amount of time adding extrenous features that will never be utilized. There is a growing/shrinking market for frameworks and apis if you need to expose a api then it is just as well you build you application on a framework. If you are building a API built, if not stop wasting time.