Recently, I’ve been pondering the future of applications. In particular, I’ve been thinking about the future of creational applications â that is, applications that are used to create, such as graphics programs, video editors, and coding environments. In order to understand where I think things are heading, you need to understand where we’ve been.
In the beginning, there was code. If you wanted to run a program, you had to punch the cards or type in the basic code yourself. My earliest memories of computing are of typing in the basic code for a skiing game from some magazine so that I could play it.
From the code arose the command line. The DOS-style command line was basically the first manifestation of Application Programming Interfaces (APIs). You could write a simple line of “code”, and an application would execute a much more complex behaviour. You could even chain these commands together to build more complex custom behaviours. In effect, applications didn’t have APIs, they were APIs.
The Graphical User Interface, popularized by the Macintosh ushered in the modern application. You no longer wrote code to work with an application. Instead, an application’s functions were presented to the user in a point and click interface. This made computing accessible to the everyman, but restricted the options available to more advanced users to only those surfaced in the GUI. This application model largely stabilized by MacOS 6 and has seen only evolutionary change since 1988.
Now, 20 years later, I think we are going to see the next shift in the model, specifically for creational applications. The market forces driving this change are increasingly obvious to anyone that works with tools like Photoshop, AfterEffects or Flash: Complexity, customizability, and market segregation. Creational applications typically address the needs of a huge diversity of professionals â I use Photoshop for web design and sketching, others use it for photo retouching or print work â and each of these professionals use only a segment of the functions available in any of these applications. This means that we are presented with a massively over-complex interface for achieving a particular goal. This is partially addressed by improvements in interface design (modern panel UI in particular). These tools, which were initially built with a specific market in mind, now face the daunting task of presenting their functionality to a wide range of user types carrying out an even more diverse range of tasks.
So how do you provide a level of customizability that allows an application to serve so many purposes? I think the answer is to reintegrate the idea of applications as APIs. This doesn’t mean that we return to command line applications, it simply means that most core application functions and interface objects are surfaced and documented. The default interface to the application would be written on top of this API layer, and would be simply one of many possible views to the underlying core capabilities. Ultimately, the bigger software shops (Adobe, Apple, Microsoft) can provide robust conduits for launching and communicating between their different applications. Suddenly these companies move from having “tools” and “suites” to having “solution platforms”.
This has already started happening. Apple has AppleScript, Microsoft has VBScript. Adobe is well along this track already, with current technologies like JSAPI, SWF panels, and socket servers in applications like PhotoShop that allow you to call APIs directly. They have also already announced further capabilities like stage core, which makes the actual authoring stage a potentially customizable instance of the Flash Player. Stage core, building gProject, and some recent work we’ve done with tool integration and Bridge panel development were the catalyst for this post.
The next steps for companies like Adobe are to standardize their APIs (not necessarily inter-company, but within their own suite), expand the extensibility and communication models fully, and most importantly to eliminate the deep rooted conception that the interface is a sacrosanct part of the application, and begin looking at it as a component (a very important component, mind) that sits on top of the core application. With these things in place, suddenly there will be a third party market for developing application surfaces on top of these functional cores. It will be possible to build a view for Photoshop that is specifically optimized for the workflow of one market segment, or even a specific company or task. Creative professionals (including programmers), will suddenly be able to build or purchase customized interfaces that better reflect the way they work. Likewise, it will be possible to create “macros” that automate, optimize or enhance workflows within an application or across a variety of tools.
This is the concept of user generated content applied to applications. No longer would these companies be limited to providing just the features that they can build, test, surface in the UI and test within a version cycle. They can focus on what they do best: creating amazing technology, and leave some of the burden of feature development to third party developers. They then have the option to select the cream of the crop and integrate it into the next version of the “default view” for the application. This will provide a more rapid, and semi-democratic feature development process, which seems like a logical extension to the “public beta” model that’s arisen in the past few years. Of course, licensing details will be critical, but that’s a topic for another post.
Certainly this won’t be nearly as significant a shift as the move to a GUI was, but it could have a significant positive effect for how we work with and perceive our tools, and how these large companies develop software.
It puts me in mind of my Grandfather, who was a carpenter. When he passed away and we opened up his workshop, it was amazing to me how many tools, templates, jigs and widgets he had built himself to make his work easier and more consistent. I want to be able to do the same thing with my tools!
Just a little something to think of, while we all wait for applications to all go online (*shudder*).
Totally with you on this one. I tried to think about where this is all going and presented some ideas along these lines at FOTB. The example I gave was a 7 year old girl leveraging the power of these API-like systems to accomplish a “programming task” way beyond her capabilities if she were trying it today. All going on-line is something I feel is crucial to the development of this sort of programming (but not in the app-in-a-webpage sense), as well as application generation and cross application cloud computing.
For the pres I started to build (but didn’t include) something that made use of JavaScript to automate Photoshop (the new versions are so scriptable it’s unreal), and that was to be controlled as a result of some website interaction. The subject was “cross application scripting”, I wanted to see how easy it was to control the raw power of a fully fledged desktop app behind a website to generate user content. If it wasn’t for the practicalities of running Photoshop on a server reliably I’d definitely have some uses for this right now rather than the limited graphics libraries that you find for various platforms.
Recently I was given a demo of Windows Powershell by a die-hard Windows fan, and I was really impressed at the level of interoperability Microsoft have introduced to the operating system via .NET, it’s like command line but each entity is an object (one of the many .NET classes), so you can perform some very complex tasks compared to the text-based command-lines of other OS’s today. It would be very interesting to see how this could be taken into the GUI realm as you mentioned. Perhaps AppleScript is the closest thing we have right now, it’s a shame about the syntax because I can’t help but feel its no easier on a non-programmer than something C-based, but I might be jaded 🙂
I guess we all need to get together as much as possible to make this sort of thing a reality, making sure we don’t have companies running the risk of giving anything away for free without a suitable return.
OK … I just don’t understand why does everyone sound so enthusiastic about apps going online.
I’m with you Kris. I can see definite benefits to occasionally connected apps. I can also see benefits to having online versions of my apps (so I could do some quick edits to a client’s FLA from an internet café for example). However, I don’t want my core apps to be dependent on internet access, or worse yet, primarily web deployed.
Very interesting post.
Just to add to that, it’s interesting to see the level of functionality the OS is providing for applications now. For example, ImageKit in OS X is and image browser. While I’ve only skimmed the surface, it looks like a nice head start to making an iPhoto/Picasso/Aperature/Lightroom type application. It’s a different approach, making small development shops more feasible. Not quite as interesting as the ideas you’ve posted though.
@Richard: Apparently Ruby and Python can now be used to do everything AppleScript does (on Mac OS X 10.5 Leopard). Apple has made them first class languages for building Cocoa apps as well.
I’d love to see Adobe standardize the languages used behind their applications. A single form of ECMAScript would be great and of course class based with a decent editor.
Hey Grant,
I agree this would be great, but before that happens, we MUST have total portability with our customizations. I used Corel a lot in the early days, and it allowed you to really configure things – key bindings, ui, etc. I was doing very specific things, so I went hog wild. A new version would come out, and it was a big pain. Eventually you could transfer those settings, but then I would sit down at another machine, total pain all over again.
Maybe this is an argument for much deeper online integration. Your settings and UI is online, and you can sit at any connected desk, and voila, the interface is your own. Obviously it could go beyond your UI (work backup, relevant docs and email to a project etc).
It still is a problem for showing people how to do stuff (which is usually why you sit down at another machine), but SEAMLESS, GLITCHLESS portability is a minimum baseline I think.
Apps go online sooner or later.. Check youtube.com “remix” function, which is like a “lite” version of Adobe Premiere..
I agree web apps are among us and making these pluggable would be key. What you describe is like what 3dsmax has had for a while in MaxScript and it allowed all types of plug-ins. But there is a problem with allowing mass plug-ins under your own appname to non technical users that might blame problems or difficulties with a plug-in with your app. But maxscript plug-ins and tools allowed 3dsmax to beat out many others for sometime.
I think I wasn’t really sold on web apps fully until this year with google docs, buzzword, and especially this one http://www.picnik.com/ made me realize this model (targeted feature sets) would probably win out. A.viary, AIR, Gears etc all added to make this closer to reality.
Nonetheless, It is an interesting time that is for sure as the web and desktop get merged further and online apps really take over.
Something like Automator?
Thanks for yet another interesting post, Grant. Your description sounds a like a move toward the NextStep OS from the old Next computer — lots of functional modules & generic documents to which they can be attached. Seems like this did not happen primarily because developers couldn’t make sense of changing to this model & maintaining profits. Maybe web services & more robust client components, more closely attached to underlying OS’s, can make this more likely. Seems like there is a huge task ahead of building code to broker agreements between services, components, & OS’s. Sounds like cool work. Something along the lines of the ‘Dependency Injection’ pattern?
It would be great if base OS’s got simpler again.
Grant, this is a really interesting post. The evolution of application interfaces is just amazing.
Your idea seems sort of like fully exposing the fundamental functionality of the application as an API or framework. From the sounds of some of the comments, this trend is well on its way.
In a sense, the flickr api is good example of this, its just not exactly a ‘creative application ‘ set of functionality. I think this can also been seen in the facebook apps. One of the reasons these have gotten significant attention in terms of third party contributions is because they’re social, potential profitable, and also approachable (easy to get started developing).
Both the flickr and facebook APIs have spawned a wide variety interesting interfaces for engaging their functionality. I think it will be truly fascinating to see what interfaces are created to interact with APIs that are geared more towards creative application –functionality– rather than just the access of basically static content.
To date, much of interface design has been limited by deep business investment and the rigid business factors that go with it. Exposing complex functionality, giving third parties appealing ROI potential for the development of interfaces, and allowing the parent company to profit nicely from the third-party interfaces will yield explosive innovation. I really hope this happens, because I think this stuff is truly fascinating.
Thanks for your inspiring post.