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

Some good ideas there! (Aside of the ranting ;))

A few points:
Have you noticed how similar your configuration mockup is to what Ximian
did in XD2 with the "System" menu? They obviously liked some of those
ideas. ;) I'm very happy with Ximian in this regard. They don't have a
"This Computer..." item but a "My Computer" on the desktop. They also
have no "Connect To" but you can browse the network from "My Computer".
I think that "Connect to a remote server" (like FTP) should be handled
differently (maybe in Nautilus). "Switch User" is probably not very
important because you could just log out. If you are thinking about a
feature that will keep your session open while logging in as another
user, that would certainly be nice. However, it seems that today
computers are getting used less and less by more than one people at the
same time, so probably not the most important thing in the world.

I think that instead of creating a new application for your proposed
applications/files view, this is something that Nautilus could very well
handle. Maybe a new view for applications with some more information. I
don't think it would be a great idea to have a full window slide down
when you click the Applications button though. In most cases you will
only want your most used applications list, so I would suggest to show
only those (and maybe recently added, recently used) and an item like
"All Applications" which would then open this new window. This should be
very efficient and also much easier to realize I assume.
Not sure about including information and the possibility to uninstall,
this is certainly easier to handle with a specialized app like Red
Carpet. Maybe this Nautilus view could provide hooks for uninstallers
which then is only displayed when available or something like that.
Information about software could probably be placed in the desktop file
if it isn't already, but I'm not sure that this is needed. The
information usually is there to make you decide whether you need this
package or not, but if you have installed it already, the name and short
description (tooltip) should usually be enough to remind you what it is.

File management will probably become more metadata like soon. I'm not
sure how far Medusa goes into this direction but it might be a good way
to support it whether the filesystem can do it or not (this is not
something we should simply ignore, because reformatting your harddrive
is no fun. Microsoft will certainly face the same problem). 
Nautilus will have to support this sooner or later anyway and I hope
that this will be kept in mind for further development. For example I'm
a bit worried that placing user files on the desktop (as some usability
people are suggestion) might make it more tricky to switch to a
hierarchy-less system. 


On Fri, 2003-06-13 at 01:53, Eugenia Loli-Queru wrote:
> >
> >
> >
> 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:
> 2. Launch applications. (work in progress:
> and
> 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
> 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
> _______________________________________________
> Usability mailing list
> Usability gnome org

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