User Interfaces in Free Software 351
Havoc Pennington wrote a piece on creating good user interfaces, with special attention toward GNOME 2. See also the advogato thread.
This discussion has been archived.
No new comments can be posted.
User Interfaces in Free Software
Related Links Top of the: day, week, month.
He has not acquired a fortune; the fortune has acquired him. -- Bion
simple: (Score:2, Interesting)
Re:simple: (Score:3, Insightful)
It is strange how many OSS fans relate to such things: On the one hand, they do not accept strict guidelines that tell you how an application has too look or behave - for them it is taking away their "freedom". OTOH, at the same time they're very strict and disciplined when it comes to following technical guidelines like RFCs, IEEE and W3C standards. No, I did not say hippocrats. But I did think it.
Re:simple: (Score:3, Insightful)
Standards are standards. You screw with the implementation of a standard and your application is worthless.
You screw with the UI and it may be ugly or less user friendly, but it still works.
Most developers follow the basics regardless of OS - File, Edit, View, Help is always the last menu item on the menu bar. "File|Open", "File|Save", "File|Print"
IIRC, the last time someone emulated MS and followed guidelines (Ximian's evolution) there was an outcry from
Dammit, make up your minds!
And we won't even discuss the "Look and Feel" lawsuits in the early 90's when people emulated other UIs.
Re:simple: (Score:2)
Re:simple: (Score:2)
Re:simple: (Score:3, Insightful)
Don't get me wrong, Apple do some good work with UI design, but to pretend that they have the most intuitive UIs is naive. When I first started using my friends Mac, he had to sit next to me and constantly remind me to close the app manually, which button means right click, and so on.
People waay overrate the Mac as GUI perfection. Open software shouldn't just copy it mindlessly.
Re:simple: (Score:2)
Consistency across the OS and across applications.
Making free software mainstream (Score:3, Insightful)
Re:Making free software mainstream (Score:2, Funny)
Worth reading (Score:4, Insightful)
A lot of people do not understand how themes and options do decrease the usability of the UI. If you are able to improve the UI significantly by changing a few options or applying a skin, then there was something wrong with the whole thing in the first place. People should not waste their energy on themeing engines or messy options dialogs (my favourite horror is the KDE control center) but focus on one UI style and make that the best. Rather one perfect UI than a dozen so-so ones.
Re:Worth reading (Score:2)
People can get seriously religious about, e.g., focus behaviour, and there's no way that you'll succeed in pleasing everyone with only one type of focus behaviour -- but no way you can have one consistent UI experience unless you enforce one and only one.
And that's for a simple option -- difficulty is magnified when it gets to more complex stuff. UIs that are good for the beginning user may not be good for the power-user... and so on.
I'm glad I'm not a UI designer, so I can just sit here and shoot down everyone else's hard efforts.
Re:Worth reading (Score:2, Interesting)
That's a common point I have yet to see proven. Usually, expert users use different applications than beginners and the designer/developer of an application can adjust to that.
For applications that are being used by all kinds of users (e.g. a file manager), ease of use serves both sides. If you find something that makes a beginner's life easier, why should experts not be able to profit from that? It's not like having to throw annoying wizards all over the place was ever essential for an easy-to-use system.
The pure beginner is, IMSO, overrated. Easy to use should not mean beginnerfriendly but userfriendly. A homecomputer is not an ATM or ticket vending machine that needs to be understood immediately. If it's a little hard to learn, the user will bother once. If it's a pain in the ass to use, the user will bother every time. See the Anti-Mac Interface [acm.org] for details.
Average user vs. power user UIs (Score:3, Insightful)
While I agree with much of what you write, I think the distinction between "average" users and "power" users is an important one. (I dislike "beginner" and "experienced" because that's not really the issue; often, some beginners will immediately want to learn all the tricks, while some experienced users will never need them.)
To take a prime example, and one of my pet peeves, consider the interface for your file system. On many systems, you can have a CLI with commands to do things like copying or renaming files, creating directories, etc., and you can have a GUI interface with folder windows and so on. Most users are happy using the folder windows most of the time, experienced or not. I'd much rather browse my file system with something like a tree view and file list combination than with a CLI and constant use of ls or dir commands, and I doubt I'm alone here.
OTOH, suppose you want to create a new folder at me/one/two/three/four/new, and currently all you've got is me. It's faster to open up the CLI and use a command that can make five directories in one go than to create one in the GUI, open it, create two under it, open that, and so on. Anyone who's tried to rename "*.doc" to "*.bak" using a windowing GUI is probably familiar with the problem, too: a few seconds at the CLI, a few minutes in the windowing system. And hey, when's the last time you saw regular expressions being used in a GUI? ;-)
So I think it's fair to say that some applications are universally required in some form, and that sometimes, different perspectives on the same functionality are more useful to different people (or to be more correct, are more under different circumstances, and it just happens that some people encounter those circumstances more than others). They key thing, though, is not so much the functionality -- you can rename a file in either a CLI or a GUI -- but the way(s) you provide that functionality to the user.
Re:Worth reading (Score:2)
That's a common point I have yet to see proven.
One example is some of Eudora's message boxes. The UI Hall of Shame has an example of Eudora displaying the direct communication between the mail server and client, instead of whiteswashing it. Well, I remember that as a nice features, even before I even knew where to look up the RFC. The SMTP tags are menomic, and the client-server communication is usually clear about what exactly went wrong, unlike the stuff that tries to summarize everything and gives back a "Um, _something_ went wrong" error for anything even slightly unusual. But, yes, for someone with no tolerance for computese, and who really doesn't care what exactly went wrong, it's probably bad.
Re:Worth reading (Score:2)
Hello? "Know Your User"? (Score:5, Insightful)
The article lists these issues as why Free Software UI sucks.
Hello? Where is the #1 reason?
Sure, developers write things for themselves. Developers write things for their co-workers. But do developers of Free Software really go out and research the goals of their users?
In looking at Linux user interfaces, I see that most tools merely tie some toolkit strings onto the underlying code so that it can be manipulated. The current thinking seems to be that if the underlying driver can do something, expose that ability directly on the command line or in a preferences dialog box.
A great case-in-point is cd-burning software. Type (cdrecord --help). The typical GUI wrapper is just the Gtk equivalent of (cdrecord --help). A massive soup of options with little help for people who don't know what a leadin is, don't care what a TOC is, don't understand how the lovers Romeo and Joliet got into CD-burning, and don't understand whether they want to fixate the disc or not.
Instead, turn it over.
Make some archetypical example users of your application. Nate the newbie. Seth the secretary. Judy the junior admin. Devin the developer. Whoever it is that needs your help to accomplish their goals, get to know these people.
A useful CD burning tool doesn't need to expose everything the driver can do. Add music files here. Add data files or folders here. Might you want to add more files at a later date? Burn the disc.
In Alan Cooper's words, "don't make the user feel stupid."
A user interface needs to start with the user, and proceed to the interface.
Re:Hello? "Know Your User"? (Score:2)
The idea of developing _for_ end-users is merely a bunch of hotair. The developers are still writing things for themselves--but indirectly. They want what they perceive comes with a desktop--power and control.
The reality is these same people who help GNOME/KDE truely _despise_ neophytes. I have seen countless times where developers on either side become frustrated with newbie questions and complaints. The developers can also be very mocking of the same people they target. Take Lycoris (aka Redmond Linux) [lycoris.org]. There is a subtle (and sometimes not) condescending attitude present. "Linux is for everyone" is their motto. Are they saying that the pre-Lycoris Linux was not for everyone? Are they saying that end-user Joe is too stupid to use regular Linux, therefore he must use dumbed-down Linux?
There are no intended users of KDE and GNOME. There very much is an expected gain--power and control. Stereotypical Linux users (read: nerd) are very controlling. They must be able to control every aspect of their computer, their network, their house, etc. They enjoy this, but they crave more. Who is perceived to have a power on this thing called "desktop" which these nerds might enjoy having (and often times claim a god-given right to)?
This article isn't about usability at all. There are countless usability studies and thesis papers available, but the "Linux for the desktop" developers never seem to take notice. This is merely developer propaganda to tell others (and themselves) that they are doing this for the "end-users" and take focus off of their true intentions. Perhaps their true intentions are hidden even from themselves? Which I think is the case for many of them.
Re:Worth reading (Score:2)
That's a perfect example of Matthew Thomas' points 7 and 8. KDE has almost no central control and there's a lot of reluctance to just say, "This is how it's going to be." So every new feature is accepted and generates yet another option to configure.
installing (Score:2)
This is even more true when you're installing software. The classic example of this is Linux itself. If you read the documentation on how to install a typical Linux distribution, it's like reading code. If you're installing from this medium, then... If you want this option but not this one, then
Another good example is CPAN. I have a Perl/Tk-based GUI app [lightandmatter.com], which I've tried to make relatively easy to install, but inevitably, the user is going to have to use CPAN to install some modules. The first time you run CPAN, it asks you for decisions about a zillion options. For instance, it wants to know what continent you're on. Are you in Tahiti? Then apparently there's a special CPAN server located conveniently nearby. God forbid that all those Tahitians should be downloading from servers in the US.
The installer is always the first part of your UI that the user sees. Unfortunately, it may also be the last.
Re:installing (Score:3, Insightful)
In many cases the question of "why should the end user be installing anything in the first place?" is totally ignored. No-one demmands that cars must be end user servicable. Or expects the typicall office worker to install their own network, telephone and power sockets, let alone assemble their own office using bricks, wood and plasterboard.
But suddenly when it comes to computers it's vital that everything be end user installable (even if it results in making the job of real sysadmins considerably harder.)
Re:Worth reading (Score:2)
This statement does not do Linux justice - part of the reason that it's grown so rapidly is that people CAN customise their environment if they want to. To pretend everybody is the same, and wants the same thing, is to be immediately contradicted by about 10 million people. Don't assume that the Apple/Microsoft GUIs are perfect, or that you can create one interface that everyone will find works 100% for them. It won't happen.
Also, you appear to be confused about what themeing/skinning is. This is a feature that lets you change the way my GUI looks - I could have a grey windowsish look, a beige Mac look, a heavy industrial greenish look, whatever. It DOES NOT, I repeat DOES NOT change the layout of the interface or how it works. It only affects what it looks like.
If you have a specific complaint about the KDE interface, then please articulate it here. I do not see how KDE is a fancy graphics shell, I do see it has a lot of options. Bear in mind that the KDE Control Centre is coming up for a redesign in KDE3.1 because of it's confusing layout. This says a lot about 1 application, and nothing about OSS UIs in general. I've seen some awful OSS UIs, and some inspired ones.
Re:Worth reading (Score:2, Insightful)
Even worse. If it looks like MacOS, it should behave like MacOS. If it looks like Windows, it should behave like Windows. Unfortunately, this is not the case and confuses users even more.
Yes, I do have specific complatins about the KDE UI and I have expressed them in various places, but they will never be addressed, because they apply to the general concept of KDE: Not making any decisions. Wether the menu bar is global or inside the application window should never be optional - this is a fundamental decision that should be made by the developers once for all. The same goes for button placements and the terminology used in programs.
If you write an application, you want to know what the user's system looks like. Does it use 3D or 2D icons? How does the system use bevels and mouseovers? Is there a per-window or a per-application menu? Where am I supposed to put OK and Cancel buttons in dialogs? What colors am I supposed to use for which meaning? Making all of this a user option makes it impossible for developers to write applications that fit into the user's system. For example: Neither KDevelop nor Opera are able to deal with a global menu bar. Opera retains a per-window menu bar and KDevelop places some dialogs behind the menu bar, making their title bars inaccessable. And if you want real fun, activate global menu bars and focus-follows-mouse in KDE.
Re:Worth reading (Score:5, Informative)
Develop a good UI and let experts in the area choose it and you will find that there are few people who disagree that it's the best. UI design doesn't come down to personal preference, it is based on common traits that almost all people share. People only have one locus of attention, it is easier to use an interface that makes the options visible in a clear manner rather than making you guess at it, the time taken to hit a target is directly related to the distance distance to the object and the size of the object, etc, etc. It's all been documented, go do some reading on it.
Re:Worth reading (Score:2, Funny)
These posts highlight the problem (Score:4, Insightful)
The fact that it's free should not mean that you should have to be a nerd to use it. Good useability is probably more important than correct functionality.
Re:These posts highlight the problem (Score:2, Interesting)
I would imagine you use Windows then... or perhaps OSX. Because in my experience Linux on the Desktop is hardly "easy to use" or intuitive despite all the efforts made to make it so. It's fun to play around with on my dual-boot WindowsXP system but my day-in day-out uses revolve around Windows simply for the fact that everything works. I don't mind tinkering with configuration files for hours or days on end to get my Linux server to do something I want it to do. (i.e. samba, ftp server, e-mail, dns, dhcp, etc..) but when it comes to my Desktop, I just want the stuff to work. I don't find it enjoyable or even tollerable for that matter to fight my system for hours or days just to get an MPEG or DiVX music video to play back. And when it finally works, the quality and speed is sketchy at best. And the functionality of the program that I'm using to play it back with consists of "Play/Stop".
If it were just that one aspect that was a pain in the neck I could easily look past it and use Linux for my Desktop. Unfortunately I run into the same type of half-butted configuration nightmares for just about everything I want to do. Fonts, image display, games, instant messaging, web browsing, e-mail, printing, cd recording, copying images from my digital sitll camera, downloading video via firewire from my video camera, and on and on and on.
The X Window System works great when I just want to fire up some shells and ssh/telnet to a bunch of remote hosts and have them all on one screen at the same time.
Re:These posts highlight the problem (Score:2, Insightful)
Like first divx. Works like hell for me and for all of my converted friends. Way better than windoze. My best result is watching divx, formating floppy, burning cd, listening to mp3, and meanwhile opening staroffice. All that on Celeron 400 (wanted to test low end machine). About picture being sketchy, mplayer set with correct parameters has best picture based on my testing.
I guess that the main thing you've done wrong, was testing gnome. Anyone reading your comment would say, that UI that you want is KDE and not GNOME.
KDE is not for tweakers like me, but usefull for Windowze users, that want to become Linux users on a fast lane. I personally wanna tweak every bit of my desktop and make additional lower underlaying scripts, to get job done as fast as it gets. For that I really don't consider waste of time. Every new distro takes me about a day to adapt my changes to it, but hey, I don't need to install software
So in conclusion I give you few tips to better usage so you wouldn't need to complain about settings anymore. Tips for a first install:
a. Hardway
1. Reconsider install partitions well (make
2. Install
3. Make some
3.1. If you're geeky enough put some your rc.d inside of that etc and execute as a deamon from original
uptime from 4 days after release
3.2. Be carefull about security
4. add bin and sbin and others to your $HOME/bash_profile
5. decide which configurations you'd like to preserve but not
6. Install additional system software by making chroot or specifiying
7. Add some deamon of your choice that tracks changed files in fonts folder and here is your font manager best there is
8. After that start tweaking your desktop manager
8.1. Set file type owners
8.2. Browsing
8.3. etc
9. Enjoy until new release
10. Install new release (don't format home)
11. start your etc configuration replacment script to restore links to your configuration
12. Tweak new things in new version
13. Enjoy this version until new release
b. Have some friend that knows how to tweak system like that do tweaking
c. Stick with what you were doing, nobody will force you
Don't wanna start flame war about KDE and GNOME, same tweak applies for KDE also. What I was reffering is that KDE is preset for user, GNOME not (allows us to choose our tools, but it wouldn't do bad if preset would be an option too for newcomers, as in my case I wanna do it my self).
Re:These posts highlight the problem (Score:2, Interesting)
Apparently you are the one that failed to notice what the article was about. Look again. The post was about "creating good user interfaces".
2. You shouldn't be offenced, here's why. How many people is using Windows? How many are geeks? What is average user in what field? Am I resonable to say what I've said?
I fail to see your point. If there was one.
3. We've got same hobbies I guess? Network is my field of interests. But you were the one that was complaining not me.
What was I complaining about?
I've just pointed out how you wouldn't need to do that more than once. Believe me I could extend this thing further.
Wouldn't need to configure my system more than once? That's highly unlikely. I install and uninstall programs all the time. I upgrade to new hardware, update my drivers, remove old drivers, and so on. Every so often, probably twice a year on average, I like to dump my system, start with a clean hard-drive, and install everything fresh. I also have multiple computers in my house and I'm the elected computer guru in my family so I'm often called on to help with their needs. I don't really want to spend 8 hours on the phone with my mom explaing to her how to add GTKLIB to her environment so she can compile the libraries that are needed in order to compile the base system which is needed in order to compile the user interface so she can have a GUI when all she wants to do is check her e-mail.
A Perfect Example (Score:2, Insightful)
FYI,
MOST people just want to get in a car and get from point A to point B. They don't want to deal with a manual transmission.
MOST people don't want to fly a 747. They want to get in one and get from point A to point B.
MOST people don't want to jump from a perfectly functioning aircraft.
As long as average people have to deal with that extraneous arcana to get simple (or even complex) things done, they will not use Linux on the desktop.
And when hardware and software support for desktop oriented technologies starts or continues to lag or fade because other platform providers do cater to the average user's needs, I will have no sympathy for you.
Re:These posts highlight the problem (Score:2)
So the source of your problem is no Linux not beign ready for the desktop, but that some apps are still missing or incomplete (say stuff similar to Ilustrator, Powerpoint, Cooledit Pro, 3D Max, etc).
Another problem is when you don't know what program is what you need. For example, mplayer may be what you are looking for, provided you can find a usable GUI for it. But that's a temporary problem as distro's job is, partially, to preselect the stuff you'll probably want or need to use.
I think I'll just restate what I said last time (Score:5, Informative)
In a previous posting [slashdot.org], I sum up what I think are the main reasons why Linux won't make it to the desktop just yet. Wrapping up my arguments nicely, the article was scored down as a troll.
Re:I think I'll just restate what I said last time (Score:2)
Things (IMHO) are usable when you know how to acomplish some task you need done. Launching a program or doing a calculation or sending a photo.
Thnigs are easy to use, when you can acomplish the task with little effort. That's 99% of the value of an interface. Just a new control (say a number-changer bar) that's easy to manipulate and understand can be a great adition to an interface.
Things are easy to learn when they are intuitive, that is, when you can figure out the what and how by thinking, not reading a manual.
So in the end, i think a nice interface has to do with this issues and methaphoring everything just leads to confusion. After all (for example) people don't put their letters and printed docs using "the town and cities methaphor" or whatever you like, they just put them into envelopes or folders inside drawers!
User Interface Design principle (Score:4, Insightful)
Good user interface designers follow a more prudent policy. They make as limited assumptions about their users as they can. When you design an interactive system, you may expect that users are members of the human race and that they can read, move a mouse, click a button, and type (slowly): not much more. If the software addresses a specialized area, you may perhaps assume that your users are familier with its basic concepts. But even that is risky.
Which lead to the following design principle:
User Interface Design principle
Do not pretend that you know the user; you don't
Re:User Interface Design principle (Score:2)
User Interface Design principle Do not pretend that you know the user; you don't
This leads to different problems. This requires that all User Interfaces be dumbed down to the lowest common denominator. While this may mean that the interface can be used by the largest possible customer base, it also means that a large segment of the customer base will find it cumbersome and not as easy to use as it otherwise could be.
Microsoft's menus that highlight recently or often used items is a good step in the right direction here. Provide all the options, but only put forward those that are used often by a given user. So, the software initially assumes nothing about the user and slowly learns their preferences.
This should be extended to all widgets, not just menus, with some kind of scripting available so that power users can easily combine operations into shortcuts so as to cut through all the steps required for the inexperienced user.
Re:User Interface Design principle (Score:2)
This is why one of the foremost goals of GNOME 2 is accessibility.
Re:User Interface Design principle (Score:3, Interesting)
His design principles lead one to construct things which always work. And depend on things which always work. Good approximations are not allowed. When and where this works, it's great. When and where it doesn't
E.g.: He disallows the overloading of operators, because the type of the operand is not an always reliable method for disambiguating the meaning. And he's right, it isn't. But it works most of the time, and in Eiffel (his language) one could create separate types for degrees_Centigrade and degrees_Farenheit, and thus disambiguate those arguments. But because a float could be either, he disallows overloading.
Where he to strictly follow his own rules, he would say that because a user interface cannot be guaranteed to work for everyone, you shouldn't have one. He's not that self consistent, but that's the only thing that saves him.
Everyone should read his book. But then they should immediately try to read a file with multiple types of data items in it that have different interpretation rules depending on the content. (Say a CVS file, where some of the fields may contain internal carriage returns.)
I always pretend to know my target audience. I just know that it's a pretense. So I try to cluster the possible incompatibilities into a cluster (or at least place an easily findable mark by them). This allows me to get the first version out in a reasonable amount of time, but still enables me to go back and adapt for a more general case on an "if needed" basis. (So far I haven't needed two. Most of my applications have a very small audience [around 20 people]. But this is a "be prepared" kind of thing that I can do with minimal cost. The other would involve either massivley expensive software purchases or considerably more work.)
Re:User Interface Design principle (Score:2)
While I agree that the starting point for a UI design does involve making few to no assumptions, this must be pared down to target "personas" (to borrow from Alan Cooper). Without target end-users, your UI design will be either:
a) too broad with no depth where users need such things as inductive UI, iconography, or blackboxing of features
b) too deep in certain areas that users won't care about, and too shallow in other areas that users do care about
It's important to define a market or user base, and then go out and show them prototypes of your design and/or study them in the lab. Without F2F, lab, beta, or other forms of feedback from users that you think will use your product, you stand a high chance of developing a user interface that meets few to none of your users' goals.
Copying the Microsoft/MacOS route ? (Score:4, Interesting)
The major stumbling block I see in free desktop software is it's inability to innovate much further than win32 or MacOs, but there's a reason for that.
It's called familiarity - to innovate too far, would be to alienate users, so it has to be a gradual process.
KDE and Gnome have improved enormously, but they are still lacking the cohesive feel that win32 and MacOS desktops have. IOW, things like keyboard shortcuts, copy and pasting text between applications etc. are virtually universal between all different applications.
The question should be asked, are features like transparent window borders, animated icons, slide-out-menus really neccessary for a productive desktop ?
Shouldn't more development time be put into creating an efficient, robust and stable work-horse desktop and less time on the fancy bits ?
There's another aspect to this - the UI 'hobbyist' or 'tinkerer' - the very people who support and participate in the development of free UI's sometimes seem to loose the most important idea behind a good UI - the end user. Much time is spent on the idea that 'total customisation' should be the end goal - is this flawed thinking ?
How many people really want to customise thier UI to the 9th degree ? - surely the majority of people simply want a plain and effective UI that helps there productivity ?
More customisation = more code = more bugs = slower UI
Re:Copying the Microsoft/MacOS route ? (Score:4, Insightful)
Yes.
The goal should be the exact opposite: the have a system so intuitive and powerful that customising it is entirely unnecessary. Of course, you'll never reach that goal, but it should always be the target.
Your post was right on the mark.
Re:Copying the Microsoft/MacOS route ? (Score:2)
More customisation = more code = more bugs = slower UI
Sure. It's great to have UI that novices can use easily without hassle.
But if you target novices so narrowly that you end up with a very easy to use, uncustomizable, interface that I (a hacker, who loves to customize everything) hate, then I'm going to stop using it, and make my own interface that I like. Maybe I'll fork your UI to do it (presuming it is free software).
If all the other hackers do the same thing, then your UI stops being a FS/OS `community' thing, and becomes yet another corporate UI. That means it loses whatever benefits accrue from having a large community of people hacking on it out of a love of what they're doing; whether that's a big loss or not, I'll leave to you to decide.
My Rules (Score:4, Insightful)
As obvious as these sound, here are my rules for a good user interface on the work I do, whether it's a web page or a GUI app:
1) Keep It Simple Stupid
2) Think Like a User (the dumber the user, the better the UI)
3) Make it LOOK better than it WORKS
The last rule is true because if the app looks like crap, no one will be happy, but if it looks GREAT and works so-so people (users, your boss) will be excited and give you more time to get the bugs worked out. This is my main problem with someone like Jakob Nielson's whiny biatching... the app has to be simple, but it's got to have good design too. Colors, buttons, subtle eye-candy, well balanced spaces, etc. Usability is key, but design is always first.
Anyways, many of the people who work on open source software seem like the people who CAN'T STAND USERS. And by users, I mean the stupid, stupid people who might use their software. It seems pretty weird, but it's true... Maybe a little less antipathy for the newbies would go a long way to helping OSS GUI design.
-Russ
OSS Startup Idea: SimpleFace (Score:5, Interesting)
Okay, I was thinking about this offline and I wanted to add that there's a perfect opportunity here for an OSS startup:
Give it a cool name like "SimpleFace" or something non-frightening like that (i.e. real words).
Then this company would do three things (complying to KISS):
1) Create a set of rules and guidelines for GUI applications along the lines of Apple's Human Interface guidelines. Include all of the most recent theories and practice. Publish this online. Use versions so that people can tell what's the latest draft, etc.
2) Certify apps that comply to the SimpleFace rules. Open Source Software gets certified for free. Certify non-free software for a fee. They get to put a SimpleFace smile icon on their web pages or boxes.
3) Create a set of classes - both online and corporate training - based on the guidelines. Some for free, others for a fee.
Once momentum started building on something like this, corporations would be more willing to switch to OSS software if they knew that training was going to be minimized because the apps that use the SimpleFace guidelines would be easy to use for those already familiar with other SimpleFace apps.
SimpleFace could also actively participate in the other projects as a GUI testing center. Whereas the rest of the OSS crowd might not pay attention to usability and design issues, SimpleFace would be there to help out. Providing feedback, suggestions, or even app dev for those interested.
Why am I thinking "startup" and not just "movement" or "organization?" because I think that something like this is needed now before the OSS movement loses any more momentum in the UI race from companies like M$ and Apple. (Under the theory that a startup could move faster than a committee.) How many Unix heads do YOU know that are switching to Mac OSX because their GUI is awesome? Lots.
-Russ
Good idea (Score:2)
Furthermore, as we've seen discussed, good UI can take a lot of development, intellectual, graphic, and otherwise. A company that has paid for that shouldn't be penalized further by having to pay *more* than a competing project which can further copy the ideas and interface of the first project after the first has been 'certified'.
Keep a fee structure in place which is small, but will help cover the costs of the certification process. The certification process should be independant of politics as much as possible.
If you want more help on developing this idea, please contact me at michael@tapinternet.com or 734-480-9961.
Re:OSS Startup Idea: SimpleFace (Score:2)
but how does SimpleFace MAKE MONEY FAST? Open source projects are not going to pay money to use SimpleFace's UI recommendations or testing. Corporations already have people trained in Microsoft Office and can always find more in the want ads. They do not want to invest extra time/money to retrain all of their employees on SimpleFace's software.
People should be asking lots of questions about Mac OS X's success. How did Apple, a non-Unix company, give Unix a facelift and become the top selling Unix ever? Why was the Unix community incapapble improving its UI itself? There is a huge cultural difference. I think Mac OS X is popular mostly because it runs Mac apps without crashing, not because it runs Unix apps!
Re:My Rules (Score:5, Insightful)
Every time you hear someone tell a user to 'RTFM', note the question down as an area of your app that you think is good but probably needs to have a UI redesign. The more the question is asked the more it needs a UI redesign.
Have You Walked the Hall of Shame? (Score:4, Interesting)
Everyone enjoys a scape goat; I noticed that a lot of university professors also reference this site in their online GUI course notes!
Anyone know of any other good "chambers of GUI horrors".
Torturé par la fenêtre.
Re:Have You Walked the Hall of Shame? (Score:2)
And let me tell you, our interfaces in that class needed all the help they could get. Programmer art as far as the eye could see.
Re:Have You Walked the Hall of Shame? (Score:2)
But yes: XP
Nice to see (Score:2, Insightful)
Though geeks like to tinker, there's something to be said about every application being consistent and keeping preferences, as much as possible, to a minimum and also to put them at the system level so they can easily be changed in a way that will modify all applications.
Its nice to be able to sit down to a Windows or MacOS system and be able to start working right away, not worrying what crazy menu is bound to your middle mouse button in application XYZ vs application ABC or where the person who configured this PC hid some other menu you need just because the preference system allows him/her to move it whereever.
I realize one size doesn't fit all and that geeks will always want to tinker, but I think if anyone is to take Linux/UNIX seriously on the desktop, there needs to be one clear Linux UI standard that is followed, and the rest must be relegated to 'alternatives'. This is similar to how Windows has its UI, but you can (if you really want) go swap it out with litestep or windowblinds or whatever.. The option is there, if you really really want it, but there's also a clear default UI system that companies and groups can standarize on.
Make it look like MS Windows and move on? (Score:4, Interesting)
Why? Because I use Windows NT all day long at work, so that's what I'm used to. Like the qwerty keyboard, 'doze UI may not be the best, but is what most people are most familiar with. This is not a silly attempt to generate flames. I think there is some merit to just conceding the "look and feel" battle to M$ and concentrating on areas where there is a competitive advantage, like security, or just developing quality free software, with no privacy-transgressing EULAs.
Of course, tinkering with window managers and desktop setups is still a fun pastime. :)
Re:Make it look like MS Windows and move on? (Score:3, Insightful)
I 100% agree with this. The QWERTY example is a perfect analogy. We all need something similar to what we work with right now.
I say EMBRACE and EXTEND. Copy Window's UI down to the pixel, get everyone to use *nix and then when M$ changes their UI again, everyone will say "why doesn't Windows work like my Unix box?"
Think about the hardware equivalent of this: Compaq started creating IBM clones which was great, but eventually IBM tried to move to the PS/2 and Microchannel, yet everyone by that time was used to the open architecture and balked at IBMs proprietary play. The same could be done for software, but first you have to make a perfect copy.
-Russ
Re:Make it look like MS Windows and move on? (Score:2)
Start Button: Starting applications is the primary function of the desktop. Limiting this function to a one one-hundreth the screen space in the most unused corner of the monitor is almost perverse. Right-clicking the desktop makes so much more sense.
Single desktop: Still! It's unbelievable that a Windows user still can't arrange applications on a desktop and then move on to other work without messing it up. Think the difference between the old Staroffice desktop and Openoffice. Windows desperately needs a proper pager.
Tabs: After using them in Mozilla and Fluxbox there's no going back. Turn on sloppy mouse focus and navigating the desktop(s) is immediate, intuitive and click-free.
To reiterate, MS makes some very elegant user apps and the Linux desktops would do very well to mimic some of the configuration modules Windows has, but when it comes down to a mouse-click per mouse-click, day-to-day usability comparison between it and the best desktops out there, Windows is still 95.
Re:Make it look like MS Windows and move on? (Score:2)
Drop the start button & panel.
Multiple desktops.
Tabs(!).
...to which I would add:
Easily modifiable user menus and keybindings.
Everything action should be keyboard accessable.
No icons on minizmize. Just a menu, please:-)
Keep it clean. Keep it simple.
I like KDE's KVim kpart. VI or Emacs, it'd be nice to be able to set all text entry *everywhere* a text entry widget ever shows up to use the same interface.
Re:Make it look like MS Windows and move on? (Score:2)
Windows has had single-click file opening since IE4.
Ask the users (Score:2, Interesting)
Here's a hint: before you start making the software, ask your would-be users for screenshot mockups how they would like it. You can learn a lot that way.
Kernel holding back back GUI development? (Score:3, Interesting)
Re:Kernel holding back back GUI development? (Score:2)
(I'm not a coder, but I've bought, and read chunks of, Abrash's books. I actually understood a lot of it. My brain hurts.
Re:Kernel holding back back GUI development? (Score:2)
>Do you know what NT version Abrash was brought in for?
afaik, the first version. Before the 3.1 release. Incidentally, NT 3.1 was supposed to slow at graphics anyway* -- NT caught on to an extent in the CAD world only after NT4 came out.
*In v3.1/3.51, video drivers executed in userland like normal programs, so the implentor was under a huge handicap as against (say) Win95: on NT 3.1 each call the video driver made to the system would go through involve a costly (in terms of time) ring transition.
In NT4 they took the the video drivers out of userland (ring 3 on intel) and put it in with the rest of the privileged system at ring 0.
Re:Kernel holding back back GUI development? (Score:2)
Didn't realise his involvement with NT was that long ago -- that's like before electricity
I see what you mean about NT's original video scheme -- what on earth were they thinking?!!
Thanks for the info!
Re:Kernel holding back back GUI development? (Score:2)
I don't think he was talking about video acceleration because people are working on that in the kernel. The only thing I can think of is fam and imon. The code for those sucks and they are unmaintained and Linus is right to reject them.
>>But given Linus' focus on 80 character terminals (not a bad thing either, imho) this is unlikely to happen anytime soon.
It's rather unfair to blame Linus for not programming your favourite feature. It's your job to prgram it, and Linus's job to tell you whether it sucks or not.
Re:Kernel holding back back GUI development? (Score:2)
> It's rather unfair to blame Linus for not
> programming your favourite feature
Sorry, I wasn't aware of video acceleration work being done at the kernel level. But then, accelerated video is not my favorite feature -- I could care less, I interact with my Unix boxen mostly through SSH sessions -- it is just that the there doesn't seem like there are too many kernel hackers for whom a usable desktop is a priority. Again, there's nothing wrong with that.
Re:Kernel holding back back GUI development? (Score:2)
Possibly the fact that the Linux kernel is optimised for maximum throughput, which is great for a server, but a workstation OS is better served with maximum responsiveness.
It is things like this that have given rise to the pre-empt patch for example. Let me tell you, it makes a world of a difference to still have a responsive desktop when the system is doing something I/O-intensive.
In fact, Linus has been known to say in interviews that getting the kernel optimisations for workstation class machines right is one of the goals of the 2.5 series of development kernels.
MartRe:Kernel holding back back GUI development? (Score:2)
Reminds me of TurboVision (Score:2)
After that, under OS/2, I had something similar but then under the OS/2 Presentation Manager. Then Unix... oh dear... I love the commandline, but sometimes I need to make something graphical and that was a huge job. Luckely I could escape most of it by making the output of the applications as in HTML so I didn't to worry about the drawing and formatting, only about how it should look like.
It isn't until less than a year ago that I heard about the GDK/GTK/Glib library and actively made a program with it and found it... euh... handy. I also found a dialog-editor (glade) and yes, I like it. Except for the fact that it doesn't use resource-files (files in which you specify how a dialog should look like instead of coding it in C and hardcode every location in the code. Maybe it can be dnoe via a resource-file, I would be happy if somebody could tell me.
Woops, got a little bit too enthousiastic. Just my 2 cents
Edwin
Re:Reminds me of TurboVision (Score:4, Informative)
/Janne
Re:Reminds me of TurboVision (Score:2)
My GUI is not your GUI (Score:3, Insightful)
However, the Man-Machine Interface (MMI=GUI+CLI) is the front-ent between me and the computer. Better yet, is _the_ computer as I see it. And what I like about Gnome is that it is a reasonable good platform with a lot of components (panels, menus, applets) with which I can build _my own_ GUI. Which is surely not the best GUI. But is it the GUI which best fits my needs.
I whish good luck to Gnome developers in their quest. I just hope they don't loose the component approach they had up to now. And don't lock users in _their_ idea iof the best GUI (while I agree that too many preferences are evil).
Re:My GUI is not your GUI (Score:2)
Regarding the issue of too many preferences, I will say that the problem of complexity and testing rings true for me. On the other hand, raise your hand if you love tweaking application preferences, and the sometimes-false but reassuring feeling of control that doing so gives you? If you know what I'm talking about, you must be a geek. I really don't see the problem with dumping geek prefs into an "Advanced" bucket that the ordinary user will perhaps never see. Microsoft was probably on to something with the Windows XP control panel, where it is now a royal pain in the ass to get to certain settings. The average user never has to see advanced settings, but they're in there somewhere if you are determined to tweak the OS.
GNOME Usability Study (Score:5, Interesting)
The report can be found here [gnome.org].
Re:GNOME Usability Study (Score:2)
Anyone know if someone meticulously went through sun's article and fixed everything?
W
I Code, Therefore I Am (Score:2, Insightful)
This is one of the reasons why preferences are as common as dirt - you have to write code to make them work.
It is also the same reason why we have dozens of sendmail/ftp/irc etc... replacements out there. We don't need them, there are plenty already, but coders feel they have the need to code rather than feeling the need to think about what they code.
A Great UI Without Graphics (Score:3, Insightful)
In the last few weeks, my hosting co's ftp software has been randomly giving me errors that suggest it doesn't know how to list a directory, put or get a file. Not that I need any of those features anyway, so I did some research and ended up installing ncftp [ncftp.com] (Mac OS X installer pkg [versiontracker.com]). I realize ncftp's not a new program, but I am amazed.
It has everything I've ever wanted in an FTP client: speed, easy-to-use "bookmarks" (no more dumping passwords into clear .netrc files or entrusting them to Apple's security-hole-prone Keychain [macosxhints.com]), status reports on transfers, and I can even use wildcards to up/download a whole mess of files at once without having to sift through ftp's man pages. Everything works intuitively, and I suspect there is much more I will discover just by using the tool.
I guess that's what a great UI is -- one that you can use and learn without having to RTFM.
(Before you reply in defense of the RTFM concept, I agree that there are types of software that should not be used until one has RTFM, but it doesn't hurt to give the FM a great UI.)
Re:A Great UI Without Graphics (Score:2)
Hrmm interesting (Score:3, Interesting)
1. Things are as usable and only usable when people can generally agree on operation or functionality. If only 10 people agree on usability no matter how smart you believe you are, it won't be usable. The most usable applications, cars, planes, clocks, or whatever got that way through the users being able to say, "I want this and I want that". Just because you don't think it's a good idea or it will slow down performance or whatever doesn't mean you should keep those ideas out or wait to act upon them, especially simple things. This is what I see on the Gnome usability list.
2. There is no such thing as a beginner, intermediate or advanced user when it comes to usability. Sure, people need to become accustomed to a new interface but the interface should always be made so that a total newbie could walk by and get the hang of it in little to no time at all.
3. Suns usability team created CDE; have you used CDE? Was it usable to you? Ok.. I won't talk about that anymore and no offense to the Usability guys I'm sure you know more about this than I do but CDE just was not a usable product.
If you want usability in gnome I think you have to start with the basic shit. Like havoc said no one likes doing mundane work but until I'm able to drag something from Nautilus or GMC into my menu or for that matter edit my menu without being root Gnome is less usable.. It's the tiny things that count and I think that Gnome in general has neglected the tiny little things.
Would you rather jump through your window to get out of your car or use a latch mechanism to open the door?
A plane is usuable? (Score:2)
You've got to be kidding, right? You are aware that it takes training and getting a license in order to fly a plane. A lot of training. Large numbers of hours logged in a simulator, and tests and such. Do you think that we should just get rid of the whole idea of a "pilot's license"?
(If by usuable you were referring to the passenger, then that's just wrong. Passenger's don't use an airplane. They are cargo that the airplane carries around. You could pick them all up and throw them in a big pile and it would still work (aside from the occasional death-by-crushing). But the only thing that a passanger on a plane has to do to be successful is not try to blow up the plane. That's not using the plane, and the plane isn't easy to use for a passenger. At least no more than your average room is easy to use because you just stand in it.)
And cars - if you had to spend as much time studying to use a web browser as to get a license to drive on the roads, the web would be in pretty sad shape.
Look, just face it. Computers are complex. There is nothing on this planet, made by people, that can do as many different functions as a computer can. Consequently everything else is going to be easier to use because it doesn't do as much.
Oh, and the lach mechanism is more complicated than jumping out your window (which I presume wouldn't have glass in it for simplicity). First, you have to find the latch, then you have to figure out how to pull it. Everyone should have to jump out of their windows so that they're not as confused.
Re:Hrmm interesting (Score:2)
Re:Hrmm interesting (Score:2)
Heh...
But on the other hand you clearly haven't read the papers that the sun usability guys wrote. They were pretty good.
I sometimes think people imagine if they find the right magic silver bullet of useability everything becomes wonderful and useable. But in real life useability is about a million mundane little things.
One thing that I remember from some of the Sun studies is that people are confused by the log in procedure on gnome. The sun team proposed several changes that would make the log in easier to understand. Stuff like asking for the password on the same window that you ask for the username. I think they also changed some of the phrasing so that it was more clear as well.
The real benifit from Sun's useability work is not the changes they make, but the papers they write. Developers, myself included, need to constantly remind ourselves about how little things like phrasing and placing text boxes makes a tangible difference to users.
Also I think the papers really show how un-magical useability testing is. I bet a bunch of people did testing on their own after reading the papers. The Sun papers provide a good place to start talking about useability in real world terms instead of looking for mythical silver bullets.
Re:Hrmm interesting (Score:2)
Usability doesn't just mean "how easy is it to do the simplist things the first time", but also, how easy is it to do harder things fast the next day or week or month (or year, even). There is a reason vi is so popular. Its certainly not because its easy to use the first time you fire it up. By your definition MS notepad has a higher level of usability than vi. Yet notepad can be used to do such a small range of things easily, it can hardly be used at all!
Re:Hrmm interesting (Score:2)
Wrong! CDE was designed by a bunch of Unix vendors working together to create a common interface for all proprietary Unices, hence the name "*Common* Desktop Environment"--common across the Unices. IIRC, CDE's dtwm, the window manager + panel, was based on donated code from HP's vuewm.
Re:Hrmm interesting (Score:2)
Re:Hrmm interesting (Score:2, Interesting)
How on earth (Score:3, Funny)
Re:How on earth (Score:2)
The solution to the open software UI problem is obvious but difficult - open software needs to attract the best UI designers before it can have the best UI.
Write all the tomes on UI design you want; open software won't have good UI till it attracts as high calibre UI designers as it attracts programmers.
mirror of mpt's 9 points (Score:4, Informative)
There are another 5 points that he added today, but weren't in the google cache.
If you're interested in his writings, please check his site after it comes back up from being slashdotted, as he clarifies some points that upset some people.
"Why Free Software usability tends to suck"
I've been having a discussion with someone from IBM about whether it's ever possible for for Free Software to have a nice human interface.
In theory, I think it is possible. But in practice, the vast majority of open-source projects are also volunteer projects; and it seems that the use of volunteers to drive development inevitably leads the interface design to suck. The reasons are many and varied, and maybe one day I'll turn this into a long and heavily-referenced essay. But in the meantime, here's a summary.
1. Dedicated volunteer interface designers appear to be much rarer than their paid counterparts -- and where they do exist, they tend to be less experienced (like yours truly).
2. First corollary: Every contributor to the project tries to take part in the interface design, regardless of how little they know about the subject. And once you have more than one designer, you get inconsistency, both in vision and in detail. The quality of an interface design is inversely proportional to the number of designers.
3. Second corollary: Even when dedicated interface designers are present, they are not heeded as much as they would be in professional projects, precisely because they're dedicated designers and don't have patches to implement their suggestions.
4. Many hackers assume that whatever Microsoft or Apple do is good design, when this is frequently not the case. In imitating the designs of these companies, volunteer projects repeat their mistakes, and ensure that they can never have a better design than the proprietary alternatives.
5. Volunteers hack on stuff which they are interested in, which usually means stuff which they are going to use themselves. Because they are hackers, they are power users, so the interface design ends up too complicated for most people to use.
6. The converse also applies. Many of the little details which improve the interface -- like focusing the appropriate control when a window is opened, or fine-tuning error messages so that they are both helpful and grammatical -- are not exciting or satisfying to work on, so they get fixed slowly (if at all).
7. As in a professional project, in a volunteer project there will be times when the contributors disagree on a design issue. Where contributors are paid to work on something, they have an incentive to carry on even if they disagree with the design. Where volunteers are involved, however, it's much more likely that the project maintainer will agree to add a user preference for the issue in question, in return for the continued efforts of that contributor. The number, obscurity, and triviality of such preferences ends up confusing ordinary users immensely, while everyone is penalized by the resulting bloat and reduced thoroughness of testing.
8. For the same reason -- lack of monetary payment -- many contributors to a volunteer project want to be rewarded with their own fifteen pixels of fame in the interface. This often manifests itself in checkboxes or menu items for features which should be invisible.
9. The practice of releasing early, releasing often frequently causes severe damage to the interface. When a feature is incomplete, buggy, or slow, people get used to the incompleteness, or introduce preferences to cope with the bugginess or slowness. Then when the feature is finished, people complain about the completeness or try to retain the preferences. Similarly, when something has an inefficient design, people get used to the inefficiency, and complain when it becomes efficient. As a result, more user preferences get added, making the interface worse.
Where a project is heavily influenced by a company under commercial pressure to ship a usable product (such as Netscape, Eazel, or Ximian), you'd expect the interface to improve as a result. But in such projects so far, it would appear that the opposite has happened. I think this is partly because the companies involved aren't large enough to employ designers who are both smart and stubborn, and partly because the business model of the companies involves maximizing the revenue (rather than the user satisfaction) gained from the interface.
mpt (Score:3, Funny)
Open Source Interface Designers (Score:2)
It seems to me that this powerful incentive is missing, or at least greatly reduced, for many non-coding areas, such as interface design.
This could be one reason it is hard to get good interface designers interested in helping fix bad open source interfaces.
The Mao suit of software. (Score:2)
I find the software that these people produce absolutely dreadful. Making software so simple that a disinterested moron can use it results in software that usually only a disinterested moron would want to use.
Just as bad is this desire for consistency. Is your car consistent with your washing machine? No? So, why does your spreadsheet need to be consistent with your word processor? Seems to me that if you can get the data from one to the other, you're fine.
Leave the whiners to Microsoft. When you write open source software, write software that you yourself want to use; chances are there are many more people like yourself who like the choices you make. Don't get all worked up about the advice of programmers and experts whose main goal in life is to expand the market share of their product by making it appealing and trivial.
KDE ain't bad (Score:3, Interesting)
The user interface doesn't have to be like Windows, it just needs to be intuitive. I've been programming for 23 years, and frankly I find Gnome very counterintuitive. I just can't seem to get the hang of it.
If they want a large audience of non-programmers using it, it's going to have to get significantly more intuitive.
The first time I ran KDE, I was able to navigate around the different applications and OS tools, quite easily. Everything made sense and were in places that I could find easily.
With Gnome, I frequently had trouble finding what I was looking for, not just in the OS, but in applications as well. The left and right mouse buttons always seemed to be backwards to what I was used to as well, though this is something that one could easily adapt to with use, but why do it that way in the first place?
What Gnome needs is some real UI experts working on the interface. Your average programmer is pretty bad at UI design, in my experience. I used to be terrible, and I don't claim to be great, but with the help of an old co-worker, I improved significantly. Since then, I've read quite a bit about UI design, and I've become a UI critic, I suppose.
I wish Gnome the best. I'd love to see Linux with Gnome or KDE on every desktop, but they both (and especially Gnome) still have a long way to go. If I had the free time, I'd love to contribute. Maybe when I win the lottery, I'll spend the rest of my life contributing to open source.
At least he's honest... (Score:3, Funny)
Super. I stopped reading right about there.
Feedback (Score:2)
Abstract UIs (Score:4, Interesting)
Schools teach children to use applications specifically. No one sits down and explains to them the concept of a file and actions that apply to a file (open, save, save as, print...) or editing (copy, cut, paste, etc.. )
If the process of educating people in the realm of computer use included a more abstract view of computers and how they work, the average joe schmo wouldn't need to "relearn" every time a new UI design came out, they'd be able to reason through it.
We moved our 8 year old daughter and 14 year old son from Windows to SuSE and Gnome, respectively. With the exception of not knowing the names of applications that do what she wants, she can get around just fine because we've taught her the basics, without being specific to an OS. She knows how to manipulate files and open applications, she understands that web browsers and can use IE, Netscape, opera or Galeon with equal ease.
This ease of adaptation is partially due to commonlality of UI implementation across applications and platforms, and partially due to their education @ home, which focuses on exploration and understanding the computer rather than a specific application.
Of course, if schools/enterprises did that, M$ would lose its edge because users would no longer be frightened to death when presented with a word processing app other than Word, or a browser other than IE.
Just collect some data... (Score:4, Interesting)
But what should be removed? What is a good default? Let's ask the user. KDE could collect information on what is used and how the prefs are set, and send it back to the developers.
I think noone would have a problem with that as long as: The info is anonymous, only sent with explicit consent, and it is stated clearly what information is sent.
Single Menubar = Simpler (Score:3, Insightful)
'Perfection is achieved not when there is nothing more to add,
but rather when there is nothing more to take away.'
(Antoine de Saint-Exupery)
You can increase the apparent simplicity and focus of an OS
simply by consolidating five menubars into one.
--| INTERFACE DESIGN > A SINGLE MENUBAR |-----
>> WHAT? Give me the summary.
A SINGLE MENUBAR AT THE TOP OF THE SCREEN that changes according to
the current context (window) instead of a menubar for every window.
Setting this as a User Default will improve Linux's ease-of-use.
Placing a single Menubar along the top of the screen:
1 - Makes it faster and easier to hit.
(no mouse overshoot to slow things down)
2 - Eliminates clutter in the interface.
3 - Reduces ambiguity (and hence - user error).
--| DISCUSSION |---
>> LINUX MENUS WORK GREAT NOW.
>> WHY SHOULD WE DO SO MUCH WORK TO CHANGE THE ACCEPTED DEFAULT?
In programming, if you compute a static variable within a loop - it is
highly innefficient - it slows down the loop. You optimize code by pulling
all the computes you can out of the loop and processing externally.
Interface design is the same. If a user has to click: A, B, C three hundred
times a day - it would make him 3 times as efficient to collapse those three
steps into a macro and execute with one keystroke. Making things less steps
for users optimizes the UI just like computing static variables outside the
loop optimizes code.
Since Menus are one of the most frequently used items in an operating system,
optimizing something small in this frequent behaviour equates to a Big savings
for the user over time. Therefore getting the menus right is one of the most
crucial and fundamental UI decisions that must be made by those implementing
the OS.
Linux currently imitates Windows' menubar implementation of putting a menubar
in every window. UI studies show this is not the optimal way of implementing
menus in an operating system. Linux can beat Windows in menubar GUI by providing
the option of a single context-sensitive menubar. There are several good reasons
for doing this:
1 - TARGETING CONSTRAINT
How easy it is to hit a target - virtual size.
2 - CONSISTENT PLACEMENT
How easy it is to remember "where" a target is.
3 - SIMPLICITY KEEPING FOCUS
Elimination of extraneous controls that are not
relevant to the current task at hand.
>> See the rest of this posting - Why Single Menubar [earthlink.net]
best regads,
john.
No menu bar = simpler still? (Score:3, Interesting)
I've heard many such arguments before, but I can't help thinking that you're mixing up a good idea (simplify the menu system) with a particular implementation that you're stuck on (top-of-screen menus, a la MacOS). How about a single, context-sensitive menu accessed from a right-click with the mouse? No, wait, we've already got one of those. So, how about having an application menu and a context menu off a right-click, with subsequent right-clicks alternating between them? And so on...
While I'm not necessarily advocating any of these ideas as "better" than the top-of-screen layout, they would appear, at least superficially, to have many of the same advantages you cite in your article: reduced clutter, easy to find (always where your mouse pointer is, some eye-catching animation to make it obvious when you click?), etc. Surely what is needed is a comparison between not just the status quo and a top-of-screen system, but between many different basic ideas, to see which are more intuitive and easy to use for the guy in front of the keyboard/mouse?
Re:No menu bar = simpler still? (Score:2)
Re:Single Menubar = Simpler (Score:2)
You are partly right. The single menubar does take better advantage of Fitts' Law; menu entries on the bar are in effect "mile-high," making them a harder to miss target.
"Setting this as a User Default will improve Linux's ease-of-use."
Wrong! There is a crucial difference between Linux/X and a Mac. There is only one GUI toolkit on the Mac, so apps written for the Mac will consistently be able to use the menubar. On Linux, however, there are multiple toolkits, and not all of them can use that single menubar. The lack of consistency in switching between apps that can and can't use the single menubar washes out the speed gains from using the single menubar.
Remember, designers of X-based desktops are not starting from scratch. There are constraints that they have to work with that are not present in the Mac and Windows environments.
Why'd he leave out the most important part? (Score:2)
Releasing a beta isn't even nearly the same thing, however.
Nice Gnome Trolling article! (Score:2, Insightful)
We see this kind of crap all the time, seems that it's usually Gnome, but KDE tends to do it too.. A developer on (name your window manager here) posts a big ditribe about how (this or that) should be written, and behold, (our window manager here) does it perfectly!
Sheesh.
Re:unbounded growth of useless features (Score:2)
Ah ha! You see my friend, you are an example of somebody who likes things light. Light is good of course, but I have tried both WindowMaker and KDE and prefer KDE. Perhaps because I came from the Windows world, I like the Windowish feel and lots of features/functions of KDE. I dunno.
But you clearly prefer something different. Your perfect GUI is different to mine. Therefore, we can conclude that the fact that we can both use whichever GUIs we want, and yet they still interoperate with each other (netwm for instance) is why we are both still using Linux. And that's why if market share for say OS X or Windows was at 100% we'd be unhappy, because we'd be using something that wasn't right for us.
Remember: there is no such thing as the Perfect GUI, in the same way that there is no such thing as the Perfect TV or Perfect Microwave Oven. People have different needs. As long as they all work on standards, that's what counts.
Re:unbounded growth of useless features (Score:2)
Unfortunately, packages are incomprehensibly named and vaguely described. So there's no easy way to select those that are needed at install time. So perhaps what should be done is to create a really minimal system, install that, give the user the option of copying the package files to his disk (if he so chooses, and if there's enough space), and then have a really simple package manager (based on rpm? apt?) that can install packages and all of the necessary packages that they depend on quickly when needed.
It seems to me that I remember that the minimalist systems have already been created (doesn't the new Red Hat have a minimalist install? Or was that some other distribution?) And there are multiple packaging systems to choose from. So all that's left is actually a pretty simple job.
Now someone has to think that it's important enough to do.