About Me

Just when I lauded GNOME for (slowly) moving in the right direction, the GNOMEs failed me: I heard that the Nautilus CD Burner was dropped in favor of a "traditional" CD burning application. Oh ungrateful world!

I briefly blabbered about this in my article on DeepaMehta: traditional applications just do not make sense. No really, they don't. No sense at all.

I do not believe there was ever actually any technical or otherwise practical reason for having applications. Rather, it's just nuclear fallout from the proprietary software world: when one has a compulsive need for selling "products" (I'm convinced it is some kind of mania -- all that talk about business model is just alibi :-) ), then one needs to offer something tangible; something that the lemmings using it can associate with the neat (for some value of "neat") package they got from the maniac... err, I mean vendor -- and probably shelled out some money for. (Pun not intended, honestly :-) )

This is an exquisite demonstration of how formidably the proprietary model fails to produce real value; how the vendors' interests work in perfect opposition against the users': what we really want are *not* clearly distinguished applications. Quite the reverse: we want additional functionality to integrate as seamlessly as ever possible; to become an organic part of the system -- to become unexistent as an entity of its own. And in a free software world, once the proprietary "product" fallout clears, we can indeed attain this goal.

So, what's this about nuclear fallout; where does this applied hate come from, err I mean that hate against applications? Just what makes them such a first-order nuclear meltdown? Quite simple: it's just too many shells.

(Don't get me wrong -- I actually like seafood ;-) )

A shell, in this context, is the part of an application that reads interactive user commands, and invokes the corresponding functionality -- the spell casting interpreter so to say. But why does every application need it's own shell? Winning hint: It doesn't. There is really no good reason. Unless you like pain -- plenty of that in here. A genuine pain factory indeed.

For starters, having many shells naturally breeds inconsistence. (It's indeed a law of nature. Goes by the name of Entropy.)

Even if you mange -- by threats, pleas and bribes -- to keep the actual interfaces consistent, the user experience inevitably still will be inconsistent: simply because of having to open the same file in various applications to do certain things on it. There is no escaping the pain.

Multiple shells also inevitably result in redundancy; and thus bloat, confusion, and more pain in general: it is never quite clear which functionality best should be accessible from which shell. There is always a tendency to add more and more stuff to each one, to avoid the situation where you have to use another shell (application) just for this one feature...

This also goes for the main system shell, i.e. the file manager: which functionality should be available there? Surely it's useful to have a preview of images for example; but once you have that, how about slide shows? Or functionality to rotate images? And once you have rotation, why not other editing features? Where to stop?

The obvious answer is: don't stop at all. (Well, it is obvious, isn't it?... :-) ) Just put all the functionality in the main shell, thus avoiding the need for any other ones.

This way, there are no applications in the traditional sense anymore. All additional software just plugs into the main navigation facility. (Normally the file manager, though theoretically other object systems are possible as well... Except that using anything but the file system as the primary facility for managing objects, is probably an idea almost as bad as applications :-) )

If you install an SVG editor for example, you just get the SVG editing abilty available from the main shell. Simple and consistent -- no more pain. Life is good.

11 comments:

Let's see how a SVG editor works. It's a library that understands SVG file and given a SVG file it can load it , apply operations on it, and save it, and a graphical vector image editing shell which presents the objects contained in the file and allows invoking functions the library provides.

Since this is typically a standalone editor you can think of this image-edit shell as a bridge between the library and the user. The bridge is the same regardless of the other specific shells of the main session shell the user might be running. This user interface bridge is built for vector graphics so it should be easy to extend the bridge to another vector file types, say WMF or DXF.

What you propose is that instead direct bridge to the user there should be a vector-editor to main-file-shell bridge, and that the main-file-shell should provide a consistent bridge to the user.

This is nice - in theory.

There are some problems, though.

Firstly the interface used for working with images may not be ideal for working with text, .iso CD images, program sources, URLs, ..

You can perhaps come up with plugin system that makes it possible to add operations for different file types (and different objects altogether) but to this day specialized shells tend to work better than have-plugin-for-almost-everything shells (think Eclipse or Firefox) - Firefox can show images and browse directories but few use it for that I believe.

Also having something as plugin in a shell does not mean it works seamlessly. For example emacs allows browsing info pages from within itself but the commands used for navigation in those pages are different from commands used for navigation in text buffers.

So you technically don't have to leave emacs but it's practically pretty much the same as running the info browser separately.

Integration is nice thing but you still need equal number of threats and bribery and then some more to make things work seamlessly together in a single shell.

What's worse, this limits user flexibility. Having 3 applications for overlapping sets of tasks may seem weird but each may excel in different areas.

There may be an image viewer that excels at displaying huge images, another that excels at organizing large image collections, one at printing, etc.

Depending on their workflow different people may prefer different viewer or use multiple viewers depending on the task at hand.

Sure, you can integrate the functionality into a single viewer that does at least moderate job at each but the reason the viewers excel at different operation is that the user experience, and perhaps to some extent the internals are different.

You would need different settings profiles for different tasks and may as well run different programs.

What's worst for user experience and flexibility is the dependence on having quality bridge to the particular shell the user is running.

The very example of CD burner comes to mind. If nautilus-cd-burner crashes, does not support a particular feature or has interface layout that just confuses me I can easily use k3b (or wodim or growisofs) even while running gnome.

If every program I use needed to be bridged to my gnome shell first I doubt I would be able to burn my CD then.

Thanks for sharing your thoughts -- obviously, you gave some serious consideration to this... Well, either that, you know how to pretend ;-)

You are perfectly right that the same interface is not ideal for every task. (While some people are good at overgeneralizing stuff, I wouldn't allow them anywhere near to user interface design :-) ) As you mention yourself, the idea is for modules to also add new commands as necessary. In fact, they could even add completely different operation modes where appropriate -- but this requires some actual work, and thus there is a good chance that it will be used only where it really makes sense. Unlike with traditional applications, where the developers can show their individuality at no extra cost -- or rather, the cost is entirely on the side of the poor users ;-)

I'm not sure though why you think that this doesn't work out... Admittedly, I have no experience with DeepaMehta myself, or anything else seriously persuing this approach. My unfailable intuition however tells me that it should work :-)

Emacs is indeed an example in favor of this (perhaps I should have mentioned it in the article): there are many people who swear by it, and would like to do everything in it... There is even a church of Emacs! ;-) Though personally I think it uses a wrong technical approach, running everything in a single process, and generally using a framework completely detached from the actual operating system.

(Firefox is not really an example at all -- it definitely was never meant to be an universal shell.)

You are right of course that having a single shell doesn't automatically make everything completely seamless -- but it definitely helps with covering the stiches! :-) Again, most things will tend to converge naturally in such a setup; unlike with distinct applications, where entropy strikes at full force...

The point about different appliations excelling in different areas actually shows how flawed this model is: I should be able to pick the best bits of each *without having to run different applications*!

Also note that a single shell doesn't mean you can't have several plugins for the same task, and choosing among them accoring to your current mood, health status, or moon calendar...

Running foreign applications that do not plug into the shell, is not a problem either. Of course there will be a chasm in the user experience -- but not any bigger than with the present situation, where every application has it's own shell in the first place... Can't get any worse :-)

What's more, if peaple take to running "foreign" plugins often, someone will soon create a compatibility wrapper for that other plugin interface, allowing actually to integrate them in the main shell... So it does not only keep the status quo (which is not a small feat in itself :-) ), but indeed makes things better even for the unorthodoxic users mixing foreign software! :-)

Yes, emacs is an example of this concept brought to life and also an example of uselessness of the concept.

While you can bring up an info page in emacs it behaves as if you started the standalone viewer for info pages, not like emacs anymore (unless inconsistency is a major feature of emacs).

Similarly a plugin that implements a completely new browsing mode is as good as running a different application. It could perhaps reuse some plugins from the shell provided the shell plugin api implements the functionality such new mode requires.

Or put differently: why do you insist on putting the best bits into a single program if the best bits are in fact different and instead of different inconsistent program you will get inconsistent parts of a single program?

Sure, if you had plugins specifically written for this single shell there would be more pressure on interface consistency among these plugins. But this would not make other applications more consistent, even if an adaptor for running them inside the shell is written.

The problem is there are dozens of applications that can be used for a particular purpose, and only a few of them are actually any good at it. And how do you ensure that the one written for your shell is one of them?

I guess the reason behind dropping nautilus-cd-burner was simply that people used different better burning solutions anyway so there was no point in maintaining it.

Yes, it would be nice if the file browser shells had at least more useful previewers so that you would not have to run a different application if you wanted to find out the dimensions of a photo image or the label of an ISO 9660 CD image. However, few people write these previewers.

I think this is in part because people who could write such plugins mostly don't use graphical shells. There are multiple possible reasons including

- the previewers in such graphical shells suck, you have to look up the information elsewhere so you can as well start with a plain text terminal

- the performance of the graphical file browsers tends to be poor even on decent desktop systems and they could possibly not even run on systems with limited resources like specialized servers (which can run the text terminal shells just fine)

- different UNIX-like systems come with different graphics interface but very similar text shell

I think that many problems with interface inconsistency could be resolved if applications were actually configurable.

For example, if multiple selection is achieved by Ctrl-click in many applications but by Shift-click in certain graphics editor this is inconsistent because you cannot go to the preferences of the application and change the modifier. Unfortunately, making things configurable in any way is additional work which application programmers seldom undertake. It works for them and other people who really require their application will learn how it works anyway.

BTW I would not be so sure with Firefox. There was once a project for writing a Mozilla based terminal.

Most of this discussion is getting circular, so I'll just restate the major points:

- A central shell doesn't enforce consistency, but it does encourage it

- Independent of any other inconsistencies, distinct shells *always* cause a break in user experience -- a central shell would still be good, even if it wouldn't improve consistency otherwise at all

- Implementing additional functionality as shell extensions rather then standalone applications, does *not* preclude muliple implementations of the same functionality to choose from, or even to use several ones depending on the situation

BTW, I learned in the meantime that the Nautilus CD Burner wasn't actually dropped; but rather, Brasero can *also* integrate with Nautilus (in addition to offering a standalone shell) -- so it really just replaced Nautilus' own implementation with a new one offering the same functionality.

(Good luck I initially misunderstood it though -- it wouldn't have motivated me to write this article otherwise... ;-) )

I do in fact believe that most programs should be usable both in text and in pixel-graphics modes. A central shell, putting most UI functionality in a single place, should help with this a lot :-)

A related issue -- which you somewhat intermingled with the above one in your comment -- are command-line based vs. visual interfaces. While personally I too prefer command-line based ones for most tasks, that's not a reason for me to ignore the visual ones, which are more popular with most people. I used Nautilus as an example, as it actually already goes further regarding the central shell idea then the traditional text shells. This doesn't in any way imply that I don't want the same idea applied to command-line interfaces.

(Actually I think both types of interface should be integrated in a single shell -- but that's another topic, which unfortunately I haven't written about yet...)

Buddy, ronaldo, 9's inzaghi, Findings from a study of the brains of dead NFL athletes have found lasting damage to their brains after having received concussionsShare your answer for the reason that like a on-line shop with jerseys or gear, we are self-confident to stand around the peak of style steam, bringing one to write about large sensation during the game Even though each of people teams are great, it's not a great sign that Carolina didn't even look aggressive The game is played almost throughout the year

Larry bird, magician Johnson, Michael Jordan had this honorShare your answer Therefore, it would be the best decision to acquire the NFL playoff Tickets onlineThe use NFL T-shirts is becoming a traditionCOM SportsbookLists inside the earlier days, APFA people to hold on and never the celebration game

2002 NFL league season opener will be the new packaging, and accompanied by performance art, to the unparalleled audience expectations, the reform of the opener is called Kick Off Game It has been a tough day for equally teams we all knew that would definitely be described as a actual, aggressive gameAnother advantage is that the leftover merchandise should be cleared off before the upcoming seasonPittsburgh Steelers, situated Pittsburgh, Pennsylvania state, is a skilled NFL teamReconsider every part on the town The wholesale are quite inexpensive and affordable 500 in every single first 4 months belonging to the season

Just desirе to ѕay уouг artiсle is аs аstonishing. The clarіty in your рublish іs ϳuѕt cool аnd that i could аssume you're knowledgeable in this subject. Well together with your permission allow me to take hold of your feed to stay up to date with imminent post. Thanks 1,000,000 and please continue the enjoyable work.