An effort has been started for closer cooperation between the KDE and GNOME usability teams. Additionally, you can read this long article about the corporate KDE. Also, several companies have joined to launch a consortium to promote Linux for desktop computers. The consortium’s goal will be to raise awareness of desktop Linux and to speed its adoption, the organization plans to announce today.
KDE, Gnome to Share Common HIG; Desktop Linux Gets Together
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
Human Interface Guidelines can’t make usability where the mindset isn’t there from the beginning. The purpose of such a guideline is to help lay out within the confines of a particular system the shared conventions that bring a consistency to the environment, but good usability planning must be there from the beginning. Given that, I wonder how much success this will really have. After all, KDE developers so far seem to lack the common sense that says that program names like “kscd” aren’t exactly intuitive. Why exactly would a shared HIG suddenly make them realize this?
Also, does it really make sense to share HIGs between desktop environments, when the point of such a guideline is to lay out the consistent guidelines for a particular desktop environment?
There are plenty of names of applications that are utterly non-intuitive: Mozilla, GIMP, Excel, Outlook, Quicken – none of these give a computer novice the slightest idea what the program does. I don’t think you can single out KDE in this regard. Many of their apps are very descriptively named (KWord, KSpread) but I admit that there are also some bizarre ones, at least for English speakers (anyone have a clue wtf a “Kugar” or a “Kivio” might be???)
When will they share a common Zig?
>Human Interface Guidelines can’t make usability where the mindset isn’t there from the beginning.
Very true. That must be why on my NT machine the “close window” button (a destructive operation) is placed next to the “maxmimise window” and “minimise window” buttons (non-destructive operations). Or with the MDI interface (maximised children), the destroy child window button is just under the destroy application button. So when I was using Opera to browse the web with about 7 windows full of hard to find sites, I accidentally closed the application down when I wanted to close just one window. Seems like bad usability, but then it didn’t stop Windows from becoming popular.
btw – the original MacIntosh system (pre-OS X) had the close window button as far away from the other controls as possible to prevent just that kind of mistake. Users of all abilities will always make errors, and the system should prevent the effects of those mistakes from being too severe.
> Also, does it really make sense
> to share HIGs between desktop
> environments
Yes, its the only thing that makes sense. About time too. This is only a hint of the future.
> btw – the original MacIntosh system (pre-OS X) had the
> close window button as far away from the other controls
> as possible to prevent just that kind of mistake
I hate that. Having to move the mouse far away to close a window is very unusefull. I have to move my hand to put my mouse on the upper left corner of the window (or the screen if maximised).
And it is not difficult to clic on maximise button and not the close one. Don’t you play xbill ?
_ [] X roxor !!!
It certainly gives me more optimism for the future of desktop Linux. Hopefully this will be the first step in making a consistent Linux GUI, where KDE and GNOME apps are indistinguishable from each other. Neither DE has enough apps on it’s own IMO, I always have to use a mix of KDE and GNOME apps. Having them look and feel the same and work together would greatly enhance the experience. There are other apps in use such as OpenOffice that wouldn’t be effected, but it would still be a big leap forward.
How does seperating the window controls increase the distance you have to move the mouse? I can’t think of many situations where you have to move directly from one control to another. I don’t see why it would require more mouse movement to click a control on the left of the screen rather than the right.
Window titlebars tend to have plenty of space, most app/document names aren’t large enough to fill them even at low resolutions IME. So placing together destructive and non-destructive controls without even a pixel between them is simply bad design. At least in Mac OS X there are gaps between the round buttons, reducing the chance of hitting the wrong one.
So placing together destructive and non-destructive controls without even a pixel between them is simply bad design
There are two pixels between them.
Honestly, although I agree with all the complaints about maximize and close, I’ve never in my computer usage history accidentally clicked close accidentally.
On the contrary, (and I’m not alone here), moving from Windows to MacOS pre-X, it was very anoying not to have the close button where I expected it to be.
Besides I didn’t miss the absence of a maximize button at all since I almost never use it. So again, for those of you maximize-a-holics, your mileage may vary.
“This project brings advanced features allowing you to experience a professional workstation class environment. The name of the game with IMD for Linux is high performance Desktop environment with style! So if you need stable 3D graphics performance, advanced features like overlay planes, robust sound system (based on SGI dmSDK), leading edge 3D APIs (OpenGL, Open Inventor, OpenGL Performer and many more) or simply a UNIX Desktop that doesn’t slow you down, then IMD for Linux is the right choice.”
“IMD for Linux is going much further that those *Themes that simulate IRIX look and feel. IMD for Linux has it own window manager that looks, behaves and provides the same features found on an IRIX box. The Motif widget set has been revised to give a true SGI Motif look and feel and new SGI specific widgets will be provided for source code compatibility between the two environments. Yes, IRIX based applications could be ported to Linux with very little changes in the GUI front-end. IMD for Linux will provide a similar Interactive Desktop environment where applications like toolchest, iconcatalog, fm and others made SGI’s Desktop Technology so famous.”
“A professional version of IMD will be made available some time in 2K3 for those who want to migrate IRIX applications or are serious about performance, FX houses for example. This version includes advanced features like Overlay Plane support and the complete Desktop Environment with source code and headers… Pricing information will be made available in due time.”
Mainpage
http://www.5dwm.org
Betatesters
http://www.5dwm.org/beta.html
The article on corporate KDE is a touch misleading in the beginning where they seem to claim that LTSP is some sort of KDE-only feature. I’ve used LTSP with GNOME, works fine.
-Erwos
On the contrary, (and I’m not alone here), moving from Windows to MacOS pre-X, it was very anoying not to have the close button where I expected it to be.
Windows is the odd fellow here. Every other OS has got the close gadget where it should be. Apple set the standard, Windows only wanted to be different. Probably to prevent further legal disputes with Apple.
Yes, they should have a direct link to the KDE specific features right at the first page for those who already know what LTSP is. Imo the article gets really interesting beginning at page 4 http://www.linux-mag.com/2002-11/kde_04.html