Your Interface is NOT Your Application

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 application 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 functionality 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 evangelize 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.