Re: Running vs starting apps



I agree with the below, loet me extend it a little.

The distinction between apps is an artifact of having different file types, each
one being handled by a different type of application.  What happens when we have a
system that has one type of document type that can embed ANY type of information
in it?  We can use meta-information and small components to make a seemless user
interface.

What happens when you have an MP3 embedded on a layer, with an image on another
layer, and a word processing layer on top of it?  Microsoft Word can already do
stuff like this, but MS still makes the artificial distinction between document
types, mostly because it fits into their marketing scheme.  If we simply say that
there are DOCUMENTS, and these documents are read by components (bonobo and <A
href="http://devworld.apple.com/techpubs/macos8/Legacy/OpenDoc/opendoc.html";>OpenDoc</a>
idea?) then we could simply define a document by its meta information instead of
by file extention or MIME type, or by user guessing.

Under this idea (extended from OpenDoc), one would have a 'document frame' with
layers, like in photoshop or GIMP.  Then, you can embed ANY kind of information
you want on those layers:  slideshow presentations, word processing, images,
sounds, vector graphics, etc. etc.

Every Layer would have its own set of tools that you could use, so if working on
an image layer, you would have tools viable for making images, vector tools for
vectors, ripping/playing tools for MP3s, etc. etc.

Then you would have some easy way of sharing those files:  a gnutella, napster,
ftp, http, samba, nfs, whatever.  Some seemless way of sharing//storing the
document.

OK, now let's take a look at 99% of the applications out there that poeple use
daily:  netscape, acrobat reader, photoshop/gimp, ftp, lynx, napster, XMMS, etc.
They are all used for document VIEWING, CREATING, MODIFYING, STORING, and
SHARING.  If linux/gnome were to have a system where a single 'frame' or
'container' was able to do all of these things to a document via bonobo
components, then the clusters of icons would disappear and in its place we would
have workspace.

The interface could then be divided into two things:  commands and document
handling.  People do not normally use interface elements (such as button bars and
taskbars) to run commands**, most people use them to open programs that view,
create, store, or share documents.

Then, when we get rid of the confusion of 'this document goes with this program'
then we can create better interfaces for giving commands and interacting with the
computer.  Right now, we are concentrating on making a good user interface for a
broken idea: instead of making the problem go away, we making a bad system a
little more efficient.  Instead, let's leverage bonobo to its logical
conclusion...

me,
delmar watkins

** Well, ok, that is kind of a tricky thing;  theoretically people SHOULD be
commanding more than document creating.  Solving problems is what computers are
good at.  However, realisitcally most people simply make or view documents.
Making a better interface so joe/jane user could solve problems would be good,
too.


Alan wrote:

> On 23-Nov-2000 Michael T. Babcock wrote:
> > ... but that aside, the task bar is those things that are taking up RAM
> > -- from a ressources point of view, this is relevant.  On my handheld
> > computer (an Apple Messagepad 120), all programs installed take up some
> > amount of heap memory at all times so they can be activated based on the
> > use of their data ressources, so there isn't much difference between
> > starting a program and seeing that its already started.
>
> I think part of it is on a PDA you really only have one app running at once.
> If you are on a PC you have finite resources, so you can't run everything at
> once.  This harkens a bit to how staroffice/office/etc do it when they don't
> say "start ms word" but just 'create new document', or 'create new spread
> sheet', or 'create new image'.
>
> This could be an interesting path to go.  Instead of starting up gimp you
> select 'make a new image' or 'make a new gmc window'.  If the app is open, it's
> new document is called, if not it's started first and then new is called.  Of
> course, this sort of paradime doesn't work well for things like xterms (sure,
> create new terminal works, but it doesn't really continue with the "document"
> style).
>
> In a way I think that desktops should take on an entirely new direction.  I
> mean *completely* different.  Throw it all out and start again!  GNOME, KDE,
> windows, mac, all of these desktop environments are based on the same concept
> and ideas, with slight variations.  Why not move to something new like the
> "sims" interface (mentioned earlier by delmar I belive).  I'm not saying use
> *the* sims interface, but just something totally new like that.
>
> The other problem of course is that we're still working with (or rather on top
> of), the same old unix OS, requiring us to have things like file managers,
> terminals, etc.  There are some windows managers out there that are starting on
> some totally new concepts like the LARS window manager
> (http://www.fnurt.net/larswm/).  Of course, because to make something *really*
> new you get a very, very unfamiliar environment which is unpopular and unused
> due to the fact no one wants to use it!
>
> My thoughts anyway....
>
>
> --
> Alan Bailward -=><=- <alan ufies org> -=><=-http://arcterex.net
> Sometimes, too long is too long.
>                 -- Joe Crowe
>
> _______________________________________________
> gnome-gui-list mailing list
> gnome-gui-list gnome org
> http://mail.gnome.org/mailman/listinfo/gnome-gui-list

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]