all-in-desktop

[Magnus Bergman]

> > > Users only want access to what's important to them. The concept
> > > that there might be stuff there, but hidden, I would think is more
> > > complicated, not less. Why should we see only Desktop/, a subdir
> > > of home -- why don't we see home on the desktop, and then have a
> > > directory (represented as a folder of course) that people can put
> > > all their unused stuff in? Wouldn't it make more sense to show
> > > the user the *top* of this tree rather than a leaf?
> >
> > As said before, the reason is that a lot of settings and such is
> > also stored in the home directory (in it's root in most cases).
> > That would clutter the desktop, which is bad (in the taste of most
> > users). Also things might break if users (perhaps by mistake) move
> > such files, which is likely to happen if they are present on the
> > desktop.
> 
> Which is why you'd obviously hide directories starting with a '.' - I
> wouldn't think you'd reveal *everything* in the home dir, just the
> user's files, which would be things they'd created and are working on,
> not hidden conf dirs that programs have created.

This is the actual issue to deal with then: apart from dot-files, what
files should be hidden?

> > Yes. But is it really that much easier to understand the difference
> > between an application and a launcher if the launcher is somewhere
> > else than on the desktop?
> 
> Users think icons are programs. In Windows, you can also 'open' a file
> or 'open' an application. I mean wtf? If you have, say, an icon on the
> desktop representing a shortcut, and an identical icon representing
> the installer to that program, and an icon on the quick-launch bar,
> and an icon in the system tray which represents the running process of
> that app, and an icon in the main programs menu for it (and other
> associated clutter, as is the case in windows), and one in the top bar
> perhaps, and so on - this becomes brain-numbingly confusing.
>
> Therefore, applications should have only one representation in the
> interface.
> 
> Therefore, it should be in a menu or bar, because:
> - to have it on the desktop with files will clutter things more
> - it will confuse people if there are files with OpenOffice icons, and
> also an OpenOffice launcher with the same icons, etc.

I agree that it's a confusing mess in Windows, and I'm very much
against reimplementing all that. I particularly dislike the start menu
and the system tray (which I don't have to use in Unix so to me it's
not a big problem). The ideas of yours seems very close to the idea of
removing the concept of applications all together. Instead put the
focus on documents and call everything else (applications not dealing
with documents) tasks. With that design you will never see any launcher
for a wordprocessor, instead you edit existing and create new text
documents. Many Gnome developers think this is the best design. Other
developers work toward different goals.

> > > Hey, why don't we give users the freedom to have root access to
> > > everything, so they can put their images in /my cools pics!!@ or
> > > something like that? Why don't we just give them a console, and
> > > the freedom to write their own operating system into in RPN
> > > assembler? Great! That's Freedom!
> >
> > Yes, absolutely. I don't think it's a good idea for a (main stream)
> > distro to expose users to all that freedom. But that doesn't mean
> > that there should be a standard that forbids freedom.
> 
> Uh... so you actually think we're *forbidding freedom* by only showing
> what a home user needs to see? If they want to be exposed to more
> freedom, they can open a console! Which they'll never, ever do. And if
> they do, it's because they even know what a console is or what it
> does.

The problem is that different people have different ideas of what is
needed to be seen.

> The answer to courting home users to the linux desktop is not
> presenting them with an interface they can't understand because it
> exposes elements that are meaningless to anybody but a developer.

I Agree.

> > I don't know exactly how Mac HD or My Documents work (since I never
> > use Mac nor Windows). But it seems quite redundant to have a
> > separate folder for "my documents" I must say, since that's exactly
> > what the home directory is for. But is there a problem with saving
> > files directly to the desktop? What hinders people from keeping all
> > their documents on the desktop now?
> 
> Nothing, which is why it should be ~/ and there should be no thing we
> call desktop. As I say, if people want to archive their files out of
> view, they can make a folder on the desktop called 'crap i'm not
> working on' and put it there. Like they do now, since almost everyone
> thinks the desktop is their area, and is confused by the separation,
> etc. ad nausium.

Another way of tackling this is to  hide the existence of the home
directory from the user. I don't think the term "desktop" is very
confusing (compared the the term "home directory"), I guess most people
know what it means.

> > If the desktop is obscured by windows or not depends on how you work
> > (and on which window manager you use). If you have a very small
> > monitor (and also a low resolution) you will probably want to
> > maximize the windows. But if you have a large monitor (which is
> > what traditional unix desktops are designed for) you will probably
> > find it more comfortable to have windows smaller than full screen.
> > I think DnD between multiple windows is one of the main benefits of
> > the concept of using windows. (If you think it's best if all
> > windows are maximize always there are so called tabbed window
> > mangers you might find superior to the traditional ones.)
> 
> Well perhaps we could explore the idea of measuring elements on the
> desktop in cm instead of pixels - that way, things would always be the
> same size on every monitor, and people would have the incentive to buy
> larger ones to see more, not just to have the ability to make things
> tiny and hurt their eyes.

Fonts (and a few other things) are measured in points (one point is
1/72 of an inch) so this is already the case in some extent. I think
it's a good idea to measure icons in points too, and I think things will
develop in that direction.

> That caveate aside though, what I mean here is - the size of your
> monitor should not compensate for a faulty design. Unless you are
> running at a resolution higher than 1280x1024, you don't have a haope
> of copying things between file-manager windows. Most people run at
> this res or lower. People should always see the things they need, and
> where they're copying them to (this is my opinion anyway). Minimizing
> and maximizing and resizing just to do basic file operations is a pain
> in the arse, and users shouldn't spend 40% of their day doing this,
> they should spend 100% of the time working on what they want to, not
> doing the window manager's job.

I have not experienced the faulty design you are talking about (except
in GEM and Windows 3.x a long time ago). But I also blame it on the
annoying click-to-focus behaviour (which I know people who actually
like). Using Nautlis and XFWM in 1024x768 works just fine for me. (But
I must admit that I mostly use MC or bash for most file operation since
that is a lot faster.)

> > > You just have one space for files - desktop. You have one bar for
> > > application shortcuts. You have another bar, perhaps, showing
> > > locations - of opened folders, attached storage, network shares.
> > > Let's call it a location bar. You drag files from your file space
> > > (desktop) to one of the *always visible* icons representing a
> > > place you want to drag it to on the location bar.
> > >
> > > Simple, effective.
> >
> > Yes, that sounds like a very reasonable setup. And what you want to
> > do is to make a standard which forbids everyone from having any
> > other setup?
> 
> Uh... yes. Actually forget the entire proposal, I'm making a desktop
> like this myself which everyone is free to use. I'm working on some
> other componenets too, they'll be detailed on a site soon as soon as I
> can get a domain name for it. I'll post details on this to xdg when
> I'm done.

That's a great idea.

> > This just sounds like a bug in Word. There shouldn't be a problem
> > opening files stored on the desktop. But since this is the second
> > time you mention it there must be something I don't know about?
> 
> What I mean is, because of the similarity between file and application
> operations, people get confused as to which is which. They don't
> understand the underlying structure of what's going on, so they get
> confused when opening Word itself, where it presents a blank documents
> or a file open dialogue for them to edit something. Opening a word
> document of course brings up the coument immediately.
> 
> And when something goes wrong, they say 'there's something wrong with
> my microsoft', because they don't even know it's a company. They're
> just shortening it from 'Microsoft Office Word 2003 Special Edition
> Blah Blah'.
> 
> So my point was: app icons not on desktop, only files; apps work
> differently, should not be treated the same with billions of stupid
> icon shortcuts to them everywhere.

Yes, billions of stupid icon shortcuts is bad. But the question is,
what should happen if a user tries to create a shortcut on the desktop
(or even in a subdirectory on the desktop)?

> > > > Some people don't usually maximize their windows (some
> > > > window-managers don't even have such a concept) but place them
> > > > so they don't cover the icons. Some other people only use one
> > > > application at a time (on each desktop) and therefore they feel
> > > > no need to access the desktop once the application is started.
> > > > So if this this is a problem or not only depends on your habits.
> > >
> > > I don't know of any DM that doesn't have a concept of maximizing
> > > files. If you're referring to the way Mac opens most windows at
> > > 90% maximized but not fully, well, you can still full-screen
> > > things.
> >
> > No, I was thinking of all TWM based window managers (and I think
> > also the OW based ones). And again I claim that not everybody want
> > their windows maximized, and why should they?
> 
> Well great, then taking up 80% of the screen. My main point was just
> that, maximizing and minimizing is a flawed mechanism for showing
> screen space and allowing users to switch between processes. It should
> be alt+tab only or the like.

I believe there are window managers behaving like that. Have you looked
at PWM and Ion? But people who likes to work with one maximized window
at a time usually experience difficulties with multi-window
applications such as Gimp. Those applications simply require a window
manager which does a good job managing multiple windows.

> [...]

> > > Now, if you opened different documents a user clicked on in
> > > different workspaces, and you showed the icon or name of that
> > > document in a little bar at the top of the screen (like with a
> > > desktop switcher applet), and let them click there to see that
> > > document, they might understand. Why? Because they'd link the
> > > concept of clicking on a document to it opening up in it's own
> > > area. And you know what? You'd have to darken the icon of an
> > > opened document on the desktop, so that when they came across it,
> > > they couldn't click it again. They'd understand it to be being
> > > 'worked on'. Multiple open instances is very confusing.
> >
> > You may have some good ideas there. Is there anything in the current
> > standard that hinders you from implementing them? Or is there
> > rather a matter of fixing current applications?
> 
> Well to implement the above you'd have to generate a new standard
> dictating that files should only have one open representation. Also, I
> suppose various desktop managers would have to conform.

Yes, that might be something to work on.

> > > > I'm quite sure that is something only a minority of users want.
> > > > But sure it could very well be available as an option to
> > > > satisfy that minority.
> > >
> > > It's only a minority of users because a) you're talking about
> > > users on linux, which exclusively constitutes hackers and
> > > developers, because normal home users run at the mention of the
> > > word linux; and b) because normal users, if there are any on
> > > linux anymore, don't write into desktop standards discussion
> > > forums, so you might not hear their views.
> >
> > I'm not saying a minority of users would want the home directory as
> > desktop. I'm saying a minority of users want *the consequences* of
> > having the home directory as desktop. As discussed above.
> 
> Wrong, a minority of developers posting to this forum want the
> consequences.

It all depends on what the consequences are, I guess. What it boils
down to is how to not clutter the desktop with all the files in the
home directory; how to decide which ones to hide.

> > > The same way we screw home users by making systems
> > > only developers could possibly use or understand. 'Oh, the
> > > packager had an error, you just need to change the config. The
> > > config. Yeah you just edit a config file! No in a console. No,
> > > okay, go
> > > to /usr/share/etc/files/xsessions/config/config.config/asdfaew.fgar.gaerheasht
> > > -- but you have be root first. What's root, uh... well anyway you
> > > put in a special password... well didn't you write it down at
> > > install time? What? No install time is when you... oh forget it
> > > just use Windows.' Yeah, exactly.
> >
> > This very common argument is pretty much to suggest that systems
> > should be so complicated that not even developers could understand
> > them. If a Windows system has problems because "the packager had an
> > error" the situation isn't much better just because there is no
> > config file that could be edited to fix the problem. The standard
> > Windows problem solving solution (format the disk and install
> > everything from scratch) can be used on X based systems too.
> 
> So there should be methods to fix things without needing lots of prior
> knowledge - eg. how to use a console. What about a standard which
> dictates all application config files should be in a common XML
> format, so config files can be edited by programs as well as users?
> Then you could have GUI programs to edit config data, and it would be
> the same as editing it in a console.

I'm of the opinion that XML doesn't solve anything. This has been
discussed many times before only coming to the conclusion that a file
format alone is not enough for the needs of most applications (cross
process change notification and such). This is a complicated, and quite
controversial issue. Search for d-conf, gconf and elektra if you want
to know more.

> And if there are problems beyond this, which can only be fixed using a
> console and lots of knowledge? Then these programs should be better
> written so they don't cause these sort of catastrophes. And failing
> this? Then the system should have a method to reverse operations made
> by a program/installer/whatever.

Yes, programs should be better written. I won't argue with that. A
method to reverse operations sounds like a very interesting idea. Does
such a system exist? Some new standard for that might be needed?

> > Yes, but more importantly, everybody is also free to choose not to
> > follow standards. So why do people follow standards, why do they
> > think it's important?
> 
> Because they want things to work. Home users also want things to work.
> But they are not programmers, and will not go and read 5 books about
> gconf and the bash shell to fiddle the options to a couple of
> programs. They do not underatand how the base system works, and they
> shouldn't need to. A computer is a multi-purpose device for *getting
> work done*.

You make it sound so easy. If we just write a standard saying
everything MUST work, then the problem is solved?

> > The bottom line is this: There are many different opinion of what's
> > best regarding usability. There are several different concepts which
> > aren't even really compatible, the usability gets better if they
> > aren't mixed. Rox for example is heavily based on a
> > document-centric design. While others lean more toward an
> > application centric design. The users have the freedom to choose
> > (if they care to), but what matters is that the distros have the
> > freedom to choose. And why should someone else make that decision
> > for them really?
> 
> Well it's hard to argue with this. But the problem is that, again, if
> the distros all make incompatible choices, nothing works - and using
> Linux is really a case of using XYZ distro. And if applications aren't
> ready for the package tree in XYZ? You're screwed.

Do you mean that (all) distros are incompatible with themselves? In
that case the problem is with the distro and should be solved there
too. But if you mean that distros are incompatible with each other
there is no easy solution. I think the best way to solve it is to stick
with one distro and don't mix.

> So all distributions need to conform to common standards - which is
> what freedesktop provides, now doubt. But if these standards don't
> include things pertaining to what the home user wants - one the
> reasons we have GUI's, I imagine, and try to make them easy to use -
> then Linux will never be ready for the desktop. It isn't now, so why
> do you think that is? Because it copies what Windows does, because
> developers agree this is the easiest for them.

If there was just one desktop environment available for Linux then the
problem you describe would not exist (or at least be much easier to
solve). But since everybody cannot agree on one desktop environment
there are several different ones with different design and philosophy.
There are some things that everybody want to work in (essentially) the
same way and can be agreed on. GUI design just isn't one of those
things. Therefore it is very unlikely that freedesktop will take
anyones side against the others.