No Application
No ApplicationA UserInterface pattern for software.
Context: You're designing software that presents a small set of object types to users and a limited number of operations on them.
Forces: You shouldn't create Yet Another User Interface for users to have to learn. Users should focus on the objects rather than the interface to deal with them. The objects in your software should be able to interact with other objects in the system.
Solution: Don't create an application. Carefully define each object type and provide different shell extensions for each so your users can manipulate the objects from within the already existing standard GUI.
Resulting Context:
Examples:
JefRaskin is a proponent of this approach. A reviewer of his book "TheHumaneInterface" says "Perhaps we don't need applications at all. This revolutionary idea is explored at length in the book. In Raskin's world, instead of buying software applications, we buy application-independent command sets that plug into our general user interface." Review appears on Jef's site at http://humane.sourceforge.net/humane_interface/hollands_review.html
The GUI design principle TheScreenBelongsToTheUser? can also be regarded as arguing for NoApplication when taken to an extreme.
A RelationalWeenie may suggest a table browser where ER information allows one to drill down and drill up and use left-right-based selectors for many-to-many selections based on relationships and use things like QueryByExample to find stuff. Event columns can be used to run stuff.
A person's ideal generic browser will probably be based on their own particular EverythingIsa viewpoint.
All the examples listed are simply file management programs, and file management is essentially what the "standard GUI" was written for, so of course it can work in those cases. But the problem with this logic is that most applications aren't just file managers. Sure, you can write shell extensions that invoke custom dialogs, and you could technically represent data in list controls in the default folder view of most OSes, but then all you'll have is the same functionality as an app with its own GUI, but it won't be as concretely tied together. What's the point in that?
The point in it is to keep the interface consistent, so that there's always a default basic interface (the unextended file manager) that everyone can rely on, just like everyone can rely on the existence of VI in Unix. An additional point of decoupling is to make reuse and maintenance easier.
Further, PlanNine tried to make everything into a file precisely so that all applications would be file managers. And that doesn't even go into what you can achieve with a genuine ObjectBrowser over a powerful object system. As opposed to broken objects (files).
I'd still be curious to hear of any examples where this type of design has worked for programs that aren't actually file managers at heart. (I understand that the point is that programs can be designed so that they *are* essentially file managers, but all the examples cited above are file managers even without any creative design)
PlanNine did it for every application, including their window manager. Is that sufficiently non-file manager for you? As an added kick, the files which the window manager exported were identical in nature to the files it imported so it could be run recursively, on top of itself.
The only thing missing there to fit the scheme described here is to link the window manager to some file extension so that it runs automatically, but this is trivial. The important thing is for a program to do no more than extend the existing standard interface.
PlanNine's "plumber" utility does what you're talking about, I think.
OK, I think you have me convinced :) Thanks for the information, I hadn't heard anything about PlanNine before.
I had this idea in the mid-80s, when I wanted to be able to use my favorite word processor commands in my vt100 terminal emulator. I didn't want to have to cut and paste between applications. I wanted one big application that did everything. I didn't call it "no application", but "one big application" because I saw the computer running one and only one application that grew bigger as new abilities were added. At the time, it seemed like a logical extension of the GUI trend. Microsoft's OLE is the closest I've seen to this in practice. -- EricHodges
Microsoft OLE is the antithesis of NoApplication. It's embedding, not extending. Of course, the way you're thinking about it, you're extending by embedding the extension. You've basically reversed the usual meanings of the terms.
Every extension must be embedded in something, whether its an application, a set of applications, the file manager, the OS or the BIOS. The distinctions don't have much meaning to an end user. Microsoft's OLE lets the user add new capabilities to their existing applications. From where I sit, that's extending.
[Even if so, so what? What happened to the "NoApplication" part?]
The difference between "no application" and "one big application" is meaningless to the end user. The top of this page says:
"users can manipulate the objects from within the already existing standard GUI"That "already existing standard GUI" is an application from a different perspective. It becomes one big application if all capabilities are added to it. Most PC users would probably be happier adding new capabilities to Microsoft Office than Explorer or cmd.exe.
[Office is multiple apps. You could argue that there's no difference between "no app" and "just one big app that is ever used on the platform, period", if in fact that ever happened on the Windows platform, which it absolutely does not.]
Office is multiple apps, but each of them can contain the features of the others. I was just using it as an example. Substitute Microsoft Word if that works better for you.
[At the moment you are speaking as if NoApplication is purely about extending each of zillions of apps on a platform, which means you don't grok the point of the page. You might want to read JefRaskin's book cited above.]
And you might want to think about what I wrote. It doesn't matter if we start with zero apps or one app. The idea of purchasing and adding new capabilities to one "whatever" produces the same result. The review cited above says:
"In Raskin's world, instead of buying software applications, we buy application-independent command sets that plug into our general user interface. The command sets would work with transformers that change content from one data type to another (allowing you to check spelling in a graphic using optical character recognition, for example)."
This is exactly what I imagined as "one big application". I wouldn't buy a word processor or a terminal emulator. I would buy word processing and terminal emulation abilities and add them to the only application that came with the computer. There would be no artificial modes of operation. All behavior would be available at all times.
+ You mean an emacs?
At the time I was thinking about this, most home computers were single-tasking. To edit a document you found on a BBS, you had to save the document, exit the terminal emulator, launch a word processor, save the document again and re-launch the terminal emulator. Modern GUIs have popularized the idea of cutting and pasting between running applications, but at the time I saw that as just a stepping stone to the idea of "one big application".
In addition, OLE was something for developers to use, not users. I've certainly never ever heard of a normal user extending the standard GUI.
On the contrary, OLE is used by end users to add new capabilities to existing applications. The most common example I've seen is Excel users dropping database queries, web searches and real-time data acquisition into cells.
I'm sorry, but that's really a very pale shadow of what adding functionality to a GUI involves.
No need to be sorry. I agree. That's why I said it was the closest I've seen.
Something similar to a mashup of Windows Explorer (hierarchy browser) and a TableBrowser/editor with button-in-cell-able tables could potentially provide a one-stop-shopping GUI interface such that an app or sub-app simply communicates through this gizmo. Somewhat related: FlikiBase.
One problem of NoApplication is that it has no GUI in the usual sense (namely: 'graphical'). I like the command line. But not everyone does. Granted - no one has yet found a general graphical UI. The best we have is the usual two panel view with tree on the left and an associated 'native' edit view on the right. This works well for - oh wonder - tree-structured data. Which is a lot. But it doesn't work well for genral graphs and - oho - images.
NoApplication is not incompatible with GraphicalUserInterface. Given a little reflection, one might render objects to HTML, for example - which is basically what the NakedObjects framework does. Also see ObjectBrowser, and maybe OpenCroquet, for other understandings of GUI without dedicated application.
Maybe what first needs to be done is a universal API/interface/protocol be created, and then the choice of visual (or textual) representation can be up to the individual or browser. In other words, don't hard-wire the visual layout too early in the game. For example, the API could return a list/table of results for certain activities, but does not necessarily have to dictate how that list is displayed: as a list, as icons, as an alphabetic spheres mobile dangling in a virtual room, as MicrosoftBob?'s household items, etc. Maybe this is overly-idealistic, but at least it's a starting point in terms of not being unnecessarily over-specific. -t
And herein the doom of this idea can be found: nobody will ever agree on what "universal" should mean, because everyone wants to control whatever that is. So evil closed-source companies won't agree on anything because its not in their interest to (consider the state of the web -- which we've mistaken for an application delivery platform), and the open source world is so fractious and subject to the whims of the GoodIdeaFaerie? that it won't come from there, either (reconsider the state of the web). In a way we've already got this in the web, and it sucks royally; further, I don't think we can do much better outside of a WalledGarden, and this is the great merit of WalledGardens. --CraigEverett?
EditText of this page
(last edited July 15, 2014)
or FindPage with title or text search