Leopard – death of the application?

by Andy Polaine on June 12, 2007

I assume that most people interested in Apple, operating systems or UI design have seen Steve Jobs’s WWDC07 Keynote by now. He shows off lots of new features of Leopard and I saw the death, or at least transformation, of the application.

Leopard has got all the usual bells and whistles of a new Mac OS. It’s easy to dismiss some of these things as simply cutesy, but sometimes minor tweaks make a massive difference (like YouTube’s awful decision to change that tiny ‘share’ button to ‘menu’).

The three features that interested me are tightly woven together – the new Finder, the new Desktop and, most importantly, Quick Look. The Desktop and Finder tweaks aren’t so important except that they integrate Quick Look, the ability to look into files without opening the host application. Some of this has already existed in terms of dragging objects between applications seamlessly, etc., but this a much bigger step.

<a href=”http://www.polaine.com/playpen/wp-content/images/quicklook_gallery_keynote20070611.jpg” rel=lightbox’ alt=’Quick Look’ title=’Quick Look’>Quick Look

For Mac application files this pretty much means being able to use the files directly in the Quick Look mode – you can browse for a movie and play it, then zoom it to full screen and watch it, without launching another application. The same appears true for PDFs and Keynote presentations, etc. But Apple have made Quick Look available for most popular file types (like Word and Excel files) as well as creating a plug-in architecture for any odd file types left out.

Death of the application

From a user-interface point of view this is the death of the application in the way that we currently conceive it. Finally, data of all types are just objects, not Photoshop files or Word documents, etc. Just ‘stuff’ that you can pick up and look at, maybe work with, and put down again. It’s a subtle but giant leap because it shifts the metaphor of thinking about the computer as a toolbox, to one of objects to be used. It’s quite a Web 2.0 concept (I hate that term too, but there it is). Objects are out there in the world, tagged (probably) and can be used or mashed together in all sorts of ways.

It’s a leap because it’s a much more natural way of existing in the world, much closer to lived experience. As a human I use and manipulate all sorts of objects and information in different ways, often all at once, without having to shift in and out of, say, a special room or suit. As I sit at the breakfast table, I don’t have to swap in and out of ‘newspaper’ mode and into ‘eating’ mode in order to butter my toast. They’re all just objects on the table, which is why the integration with the Finder and Desktop are important.

The concept behind Quick Look enables you to do many of the things you need to do without having to launch the application, so why have the application at all? Imagine, when you needed the application’s ‘tools’ you just brought up the palettes and menu items. Think of the application’s engine as always there in the background, ready to be used. I’m having a look through some spreadsheets (to choose a really ‘tool-based’ example) via something like Quick Look and I need to change a couple of cells. Perhaps I can just do it there and then, without launching the app. The file type is mapped to the application and the required code is accessed as needed.

Maybe if I need to do more complex work the application launches, but instead of it feeling like I’m moving to another environment, I just see the toolbars appear. You could gradually drift into a ‘deeper’ application mode if you needed, or you could stay shallow. It would be one of the ways around feature bloat in an application. If I need a screwdriver, I just take it out of the toolbox, I don’t empty out the entire toolbox onto the table.

Most importantly, this is the ideal way of thinking for mobile devices. Applications and folders are a nightmare to navigate on mobiles and most applications are slow to launch. I’ve yet to see a decent example, although maybe the iPhone will deliver. What it does show, though, is decades of misguided thought about computers and applications – all that HCI focus on tool-based functionality. Sometimes it’s about the tool, but the objects (the data) that you are working with are the focus of your attention and intention – the content should be the interface, which is why, I think, that all those multitouch interfaces are increasingly popular. Applications make much less sense in those environments.

{ 6 comments… read them below or add one }

1 Knotty June 12, 2007 at 11:57 am

I think you overstate the death of the application.

Just because you can see stuff, it doesn’t mean you can edit stuff or create stuff… You can use Preview to open PSDs but it doesn’t replace Photoshop :-). The only reason QuickLook works at all is that the OS doesn’t have to load all of the functions for opening, saving, preferences and other advanced functionality, all it has to do is un-archive from a bundle and view…

I’m not 100% sure, but QuickLook seems to be a plug-in style architecture and so application developers will need to provide a plug-in with their applications in order for their document types to be supported in QuickLook.

2 Andy Polaine June 12, 2007 at 1:19 pm

Yes I am, to a certain extent, but I’m envisioning a future way of working/playing.

Actually I think we work that way quite a lot online already, it’s conceptually equivalent to RSS readers at present. It’s the ability to do a lot by scanning through content before having to work with it.

Of course I understand what an OS needs to do to run an applicaiton. My point was, what if you extend something like Quick Look so that you can do simple things? I can load a PSD file into Preview and not see the layers or have the functionality of Photoshop, sure. But I can crop, export, rotate, etc. So in many cases that might be enough. Quite often I have to only change a couple of cell values in a spreadsheet – do I need to load the whole bloated Excel app to do that? Not really.

I could see this way of working developing because there are so many examples of it with things like Widgets and Web Clips too. Taking the parts you need – using them as a small portal onto a larger set of applications. If online applications like Google’s become more popular and they’re running through the Webkit engine, then much of what I’ve spoken of is also possible. Of course it doesn’t replace fully-fledged applications, yet. But think of a kind of cascading model of an application – you have the important, everyday functions available at an OS or Quick Look for basic edits and manipulation, then other parts of the app load.

The really important point is the conceptual shift from being tool-centric to data-centric. It’s been coming for a while, but this is a big step.

3 Matthew Polaine June 28, 2007 at 9:53 pm

AP – Hmmm. So how would the software corporations generate revenue to pay researchers/developers to build the apps we currently use if we follow this process to its logical conclusion :-) Tough one, but I can see both sides….

4 Andy Polaine June 29, 2007 at 8:13 pm

It’s not about there being no applications, just the way we think of applications actually running as a complete thing that you open up before you use any part of it. As has been the case with the web, it would be more about building the links and interfaces that plug data together in a smarter way.

5 Sam Bauers July 11, 2007 at 4:36 pm

do I need to load the whole bloated Excel app to do that? Not really.

Well in the case of the applications you cite (Adobe and Microsoft apps), the answer is probably yes. Those apps are Carbon based (I believe) and probably can’t exist outside of their monolithic codebase, that is without writing a whole new “lite” app, which would still have to reside in memory as a separate blob. So if you are talking about application bloat, then that would be it. More code, more memory used etc. etc., of course the same doesn’t necessarily apply for Cocoa apps in OS X, but they usually aren’t the problem.

That being said, I do understand the “vision” thing to which you refer. But quicklook is a little bit of smoke and mirrors in my opinion, and is mostly just a left-over feature from the iPhone (where they needed at least Excel/Word file viewing to enter the “smartphone” market.

Some of what you are talking about is more evident in the iPhone UI, but again not really. You still use a “I am now in this application” modality, just with some nicer hooks into the core phone functions, which really aren’t working any differently to how URL handlers work on modern operating systems.

I could see this way of working developing because there are so many examples of it with things like Widgets and Web Clips too.

Widgets maybe, but not Webclips. Webclips load the whole page every time it is refreshed, they need the included Javascript and CSS and the rest of the webpage to give it it’s position and functions and style etc. So it is totally inefficient in terms of processing, except from a UI perspective.

Widgets also exist almost entirely outside of the desktop experience, you actually “drop-out” of the desktop to use them. Although they have more potential to interrogate and utilise the underlying system than normal webpages do. I don’t use widgets at all, like most people I set up a few to start with, but eventually turned them off as I found myself not “dropping-out” enough and also found that each widget instance was reserving a good chunk of memory 100% of the time.

The other thing I wanted to mention was that none of this takes into account the growing dominance of web based applications and their integration paths into the desktop experience (or lack thereof).

Integrating web based services seamlessly into the desktop is more probably the death of the application. The OS in my opinion needs to be a better web services client and specifically a better browser more than it needs to be a better file handler.

6 Andy Polaine July 12, 2007 at 1:55 pm

Oh! You technical guys spoiling all my fun!

I know what you mean about this side of things, but there are some interesting underlying trends here though. On is that a sizeable chunk of memory and processing time is now being give up to the UI ‘experience’ rather than just the functionality. This is true of both Vista and OS X now and it’s interesting to see this trade-off – i.e., that the experience of the interface has value.

I do use widgets quite a lot, regardless of their sluggishness and I do think that Exposé in general was a big leap in the Desktop UI precisely because it broke the Desktop metaphor without much detriment. One of those things that seems so obvious to do it’s a wonder it didn’t happen earlier (graphics processing notwithstanding).

I get that quicklook and webclips are smokeand mirrors (as are widgets really), but it’s not so much the technical implementation as the mindset and UI metaphor that interested me. If apps could become less of a process of ‘now I’m in this app, now I’m moving back to this one’ how would this look and how would it affect the way we work?

I think your comment on the rise of web apps is spot on, not only because of the current lack of integration into the Desktop (though that’s a mixed blessing), but also because web apps are becoming more and more integrated with other web apps thanks to open APIs. So in some respect you can just sit in the browser all day and that’s your ‘app’. But at the moment you still have to switch between tabs/windows for mail, etc.

I’m not necessarily thinking that some kind of master console is a great idea (it’s good to have some stuff hidden from time to time) but more that any data is accessible and usable from anywhere else without having to go into the app to do it. In that sense it would be more like a desktop version of having a thin client front end with all the apps residing on the ‘server’ (local machine in this case) doing the processing of requests.

Previous post:

Next post: