What Features Would Make a "Better" GUI?
Rudyatek asks: "When it comes to desktop OSs, there has been much talk about 'the end of the desktop', 'reinventing the GUI', etc. Usability has become increasingly important as we battle the ugly UIs of Windows and X11, and watch companies like Red Hat and Ximian try to improve them. But I'm curious if anyone has any clear ideas on what a truly 'better' UI would really be like? As a hobby OS programmer I have a great interest in alternative OS ideas, and this is one that I hear more complaining about than actual ideas. Anyone have ideas?"
Maybe you can play around with text files to tweak your system's fonts, but most users have neither the technical expertise nor the inclination.
If you release a distro with unreadable font, people don't say "hey, this distribution isn't configured very well". They say "Linux is hard to read".
Oh, and can we please have checkboxes that make it obvious whether they're checked or not?
Everything out there now sucks.
:)
:)
There have been some neat ideas tossed around, including those with are not only 3d.. but '4d', allowing you to track file and system history through a 3d interface.
Eventually we will have commonity hardware that can display 3d (opposed to hardware which currently only displays on a 2d surface).. at which point we will need a truely 3d interface, we should develop this interface now... rather than waiting for the hardware before building the software. History has proven that progress is best done with software pushing the development of hardware, not the other way around... current hardware is fast enough to write software that could be viewed from a 3d display, even if such displays aren't available yet
There are a few features I'd suggest for 2d widget s like those with GTK..
The tabs in GTK are done terribly wrong as they are modelled after Microsoft's equally bad tab widget. If there are more tabs than can be displayed, then the tabs should either create a new row (causing problems with nested tabs which shouldn't ever be used anyhow), or it should provide a menu for the selection of the hidden tabs like with SGI's Motif (which is different than plain Motif).
Close buttons for windows should be on the upper left side of the window.. I'm not sure why Microsoft changed this (and hence creating a whirlpool effect); Windows 3.1 had a upper-left close button, MacOS has it, MWM (and clones/spinoffs), etc. It much faster, easier, and more natural to have it on the upper left. I believe Microsoft's intention was that it should be difficult and slow to close windows.. something that may help novices from making mistakes (which is why MWM and clones, including Windows 3.1 require it to be double-clicked); however, I find that a lot of people new to computers cannot find the close button due to it's location... advanced users are just annoyed or learn to use keyboard shortcuts.
Speakers of languages based on latin are instinctfully drawn to the upper-left.. this is why having a menu in the upper-left is more effective than one in the lower-left (Microsoft Windows 95, per default). This can be different for those who read/write languages from right->left or from bottom->top. I believe Microsoft put their menu on the lower-left as it was initially designed to be 'supplimental' to the desktop icons which would be more prominently placed in the upper-left. However, desktop icons are a bad idea.
Desktop icons are a bad idea. There should be a distinction between the execution layer and the runtime layer. A menu-bar which provides the execution layer then a 'viewport' for the runtime layer. Putting launchers in the runtime 'viewport' causes confusion between the runtime and execution layers. Think of a panel in Gnome as the 'execution layer', this is where programs are executed from.. and then the desktop where windows are allowed as the 'runtime layer'. This also means that programs should not be allowed to overlap the panel.
I must agree; however, that the PalmOS interface is quite adequate considering some of it's defiance of some of my suggestions (desktop icons , for instance). However, their desktop icons could be easily replaced with a 'spring-loaded' folder such as in MacOS.. this would provide the abstraction of the 'execution' and 'runtime' layers by providing a panel, while still being usable on a small display. This 'spring-loaded' folder while minimized would sit along the bottom of the display for easy access while the user is utilizing any programs within the 'runtime' layer.
A distinction between 'runtime' and 'execution' layers should require that the 'runtime' layer cannot overlap the viewport of the 'execution' layer, but the 'execution' layer's programs should be able to visually overlap programs contained within the 'runtime' layer.. as would be necessary for menus or usage on small displays as found on PDAs.
Look at the Palm OS gui. The Palm was the first widely used PDA because it's interface is so intuitive and easy to use. Why?
There is no concept of a "running application", nor is there a real concept of files or a file system. You basically just switch between apps, and you never have to worry about exiting, saving, quitting, etc. Furthermore, you are very abstracted from files. Each app knows what bits of data were created with it, and which to let you open.
Now granted, the apps on a PDA are much simpler than those on a desktop machine, but the concept is still good.
Applications are always available and you don't worry about "runnig" or "quitting"
Modern OSes have virtual memory, so there is really no need to worry about apps running and not being used. With slight additions of features like app "sleeping" (disallowing it from using CPU cycles on demand), File->Quit is a thing of the past. Just leave apps running when your first start them (or start common ones at boot time). The Mac OS X Dock fakes this pretty well by combining an app launcher and task bar. It's great, because I always do the same thing to use a particular app, regardless of whether or not it's running.
Removing the "file" metaphor, and the concepts of "saving" a file
By having applications constantly save files, and additionally version them as well, the user really has no need to ever save. I mean, you don't "save" your memo-pad entries or contacts in the palm, because you don't need to. They are simple structures, so versioning isn't needed, but for larger documents, something similar to the VMS file versioning can be used. Furthermore, since you abstract the user from managing files, their task is greatly simplified; you just click on your app, and choose which thing to work on. Since it's always saved, you never need to worry about exiting, or crashing, or anything. Additionally, apps know what files they created and can open, so the user never has to wade through files that aren't relevant to the current application (Mac OS 9 faked this by using the Type/creator codes).
Files, folders/directories, running apps, are a construct the user shouldn't need to be exposed to. That is why the Palm is so simple to use, and browsing in Windows Explorer is such a pain (for the avg. user).
http://www.naildrivin5.com/davec
I've seen a fair number of people mention that they want something closer to the command-line, and more involved file-system management. That may be fine for you, but what about for my grandma who just wants to use word, outlook, and her knitting pattern designer. She dosen't want anything to do with the command line - she wants a (virtual) button to press that will "make it go" and run what she means.
So when you say a better GUI, I challenge you to qualify what you mean. Do you want a better GUI for the programmers and hardcore command-line-junkies out there, or do you want somthing for the majority of users who don't give a shit about the command line or the filesystem, and who just want to "make it go?"
Fos us who like the line (and like things like gcc, regexps, or **nix), then maybe a GUI with command lines everywhere is what we need. But all my grandma (or Joe Sixpack) needs is a bunch of buttons - like (as someone suggested) PalmOS. Or a Mac.
Cue The Sun...
MULTIPLE MOUSE POINTERS
That's right, I would like to see multiple mouse pointers. Society is stuck on the singular-mouse idea. We need to move beyond this 20th century dogma and start developing a multiple-mouse environment. If we can put a man on the moon, we can add a second mouse pointer to a GUI.
BUILT IN HOMELAND SECURITY ALERT SYSTEM
Are we at orange or yellow? I have no idea! But if my GUI incorporated the Terror Alert System into the desktop, I would always know precisely how scared I should be. Right now there is a 14-Click pathway to information about our current Alert Level. With integrated Homeland Security Alertware, the 14-Click barrier could be broken, and America would be that much more safer. If the next popular GUI doesn't feature Alertware, then the terrorists have already won.
SUPERFLAT 3D-THIN BUBBLE BUTTONS
In the beginning, all buttons and menus were flat. Then, Windows developed buttons and menus with a 3D appearance. Windows 95 took buttons and menus to a new level by incorporating the 3D-Thin look. While these new buttons appeared 3D, they had that appealing Thin look. Windows XP revolutionized Three Dimensional flatness by inventing the 3D-Thin bubble buttons. These button, although appealingly 3D, are so flat that they appear to be bubbles. I don't know about you, but this is already getting old. We need to add another dimension of flatness. I would like to see Superflat 3D-Thin Bubble buttons! Although Three Dimensionally thin and bubbly, these buttons would appear to be Superflat. I could get a lot more done, as a user, this way.
----
"Those who quote others are more likely to one day be quoted" -Tom Planter
On kde-look there is a very nice looking replacement proposal for kicker and the desktop metaphor.
The author proposes a card based metaphor which would allow you to mix and match componants to create your own desktop environment. There is no code yet, just some annotated "screenshots" here and here.
In the discussion there are several people volunteering to help code so this project may actually become reality.