New way of accessing software (WAS: Re: Big Panel menus (32x32))

["Eugenia Loli-Queru" <eloli hotmail com>]

>http://shaun.dog-berry.com/temp/menu-16px.png
>http://shaun.dog-berry.com/temp/menu-32px.png
>http://shaun.dog-berry.com/temp/menu-xd2.png

For the record, I much prefer the 16x16 ones (and I am even running
1600x1200). Gnome should just make sure that there is a generic icon
displayed there, if the app has no icon. Leaving holes there is just plain
ugly.

However the real problem is different here. We keep arguing which pixel size
is better, while this menu method with icons on the left side something
already used by all OSes the last 10 years and they have perfected the
procedure for us to use. We shouldn't even be arguiing about it. Just use
whatever most OSes have come to use at the end.

Instead of arguing about this traditional way of accessing software (which
shows its age by seeing this terribly long sub menu and the also half-baked
hack of Ximian's and Red Hat's "More"), we should be doing innovation.
We should be discussing the next big thing on accessibility and not lose
time on trivialities.

While working for Sequel OS last year, I did some research on alternative
methods of accessing these piles and piles of applications people are
generally using. Because Sequel would be using a filesystem that supported
extended attributes (Note: Reiser, XFS and JFS also support them) it made
absolute sense to use this ability of the fs to do statistics.

Linux today has this power via its filesystem too. However, applications
don't take advantage of these abilities. This is one of my problems with
Unix/Linux: the very conservative way of doing things. For example, while
XFS supports cool stuff, the software on Linux doesn't take advantage of it,
because "it won't work if the user runs on ext2". Who cares? Gnome should be
steering innovation and even changing status quo on other parts of the
system, like the filesystem. Gnome is big enough to dictate one of  the ways
forward. *Integration*, forward thinking and decisions made by a number of
people of different projects can help OSS go further. For example, _I want_
Gnome people talking to the X people say to them "you know, we need this and
this and this, and we expect it to have it in 3 months". And then, I want to
see the X people going to the kernel people and say "you know, the gnome
people want this thing done, but to do that, we need this thing supported in
the kernel in order to accelerate it enough". This is how things work in a
real company-OS environment, you get meetings with people from different
departments and get them on the same room, order them pizza, and they solve
the problems in an integrated way. If other Unices don't have these
features, they should sit their a$$ down and create them. Exactly as Sun did
with the XRender extension that made their Gnome pot slow. They sat down and
said "ok, we need to add this functionality" and they do it. Same thing
BSDs, IRIX etc will have to do if they want a *modern* DE ported to their
OS. They should not get it for free because that holds Gnome itself back.

Once, I asked my (ex-Be engineer) husband "why BeOS always felt so fast?"
and his reply was: "because the kernel guy had his desk next to the
app_server guy." This explains it all, he didn't have to get into technical
details.

Anyways, enough with my usual rambling, what I am trying to conclude here is
that we should be using the goodies that Linux and other OSes offer today in
order to bring Gnome really forward. I don't want to hear the word
"innovation" only from MS and Apple. It is getting old to hear them rambling
about it all the time. So, my proposal for software accessibility might need
either a database lib, or the use of a modern filesystem (it might be doable
without breaking OS compatibilty, you decide, I don't exactly know the
internals of Gnome).

In the three mockups below (please note that these mockups are just mockups
to show the logic, don't pay attention to icons, fonts, organization,
KDE-based etc, I did those many months ago),  you will find a new concept of
organizing menus and work evenly. Here is the logic behind it:

When people are using computers, they always use them in one of these three
fashions:
1. Configure the environment. (just an old mockup:
http://www.osnews.com/img/3721/1.png)
2. Launch applications. (work in progress:
http://www.osnews.com/img/3721/2.png and
http://www.osnews.com/img/3721/3.png)
3. Load and process files. (files should have the same window launcher as
the apps above, but with options regarding files instead of apps, depending
on the MIME type)

These should be three big buttons in the gnome-panel. The first opens a
normal menu, the second two open a smoothly sliding window (essentially a
new application) with no window manager. It slides in and out of the
gnome-panel, but there should also be the option to have a small button to
"un-stick" it from the gnome-panel, give it the window manager and use it as
a real standalone app.

Until now, KDE, Gnome (and all other OSes) is trying to do these three
DIFFERENT
operations in ONE menu, the gnome foot/kmenu. People are complaining about
the bloat of
KDE menus for years, and whatever the KDE Project has tried to do in order
to clean up the situation, they were never succeeded. Why? Simply, because
they tried to combine  three *different* actions, into one. They had to cut
in
corners, remove functionality, and even after all that, they were still
bloated (and the same happens on the gnome menu too as I see in the
menu-32pix screenshots above).

This new way of organizing the menus is much more clean and efficient and
offers more functionality, without adding bloat, because you know where to
find the settings, where to find the apps and where to find the files, all
in an instant. I understand that when you are seeing this nested categories
there (main, graphics tools, image viewers) you keep thinking "how is that
any faster than the menus we have today?". The trick is that the app listing
on the right hand side of the second and third mockup is only there to not
always be used. The main way of launching apps is via the statistics menus
on the left. We just need to perfect some algorithms there, to "know" what
the user is trying to find.( if Google did it, we can too. ;-). Overall, it
is a launching way based on usage patterns and stats.
The right hand side navigation is just extented functionality for apps, e.g.
description, info, uninstallation (which should be handled from the same
panel as launching, as this should the THE software handling app)

To implement these changes, you will need to add some stuff in the OS
itself, especially for the "Connect To.." option, while gnome vfs might have
to
see changes too. But that's where integration comes to play, a desktop OS
can only be good when there is proper integration. More over, please note
that the three icons/buttons that will open these three menus, have to be
BIGGER than the icon shortcuts found on gnome-panel, or to have text next to
them, as the "gnome logo/Applications" text found on the default gnome in
the upper left corner. These three buttons/text *will have to stand out*,

My experience has shown me that people don't really use more than 10-15 apps
daily, even if they want everything installed (so they can impress their
younger bro :-)
These 10-15 apps should be easily retrievable via the live filesystem
statistics as shown the second mockup. Also, a package management that keeps
track of the recently instaled apps is good too. (in the second shot forget
the "Recent Files/Docs" as these go to the File management similar window
where files are shown there instead of apps)

I know that these mockups are not shown clear what I mean, sorry for this.
Please reply if you have questions. I made these mockups some time ago and
some things have actually changed since then. It is not a fool proof
concept, as I said, I have changed my opinion on some of the things shown
there with time, it was still work in progress when I stopped thinking too
hard about the whole thing, so please be nice. :)

Eugenia