OSNews

There is still room for discussion, though. Consider your usability definition:
refers to whether a certain Product, software or not, enables a user to perform a certain more or less well defined task.
The single user has a variety of dimensions, among which is time. Graphically oriented systems get you in the door, but some users will graduate to keyboard shortcuts, and those annoying twits in the right tail of the distribution will want to put everything in macros.
I worry that "a user" might imply a static view of the user in question.
Best,
Chris

makes sense to me.

"I worry that "a user" might imply a static view of the user in question."

I think that that issue is somewhat covered in the "Obscurity/Complexity" section of Richard's article (or at least it's somewhat implied there).

Open source in general suffers from usability problems, the applications are fragmented and developers should address this problem (that is THE reason i switched from linux to osx)

I believe this can only change if the attitude of the developers change, i want finished applications and limited choice. having more than 50 windowmanagers makes no sense at all.

Don't get me wrong, i think open source it the way to go. Firefox is heading in the right direction. The find/search function of firefox is a really good example of good usability. I can search (and it search directly), and i can highlight the keyword. it's even better than the safari search function

I agree with every word, and I hope the various developers will take the points of view mentioned into consideration.

Static linking has its uses, but trying to use it in order to make mandrake rpms work well on redhat is a bad solution. Take, for example, a complex application like Evolution. My installed version links directly to over 70 different libraries. Some of these may make sense to link statically when we're distributing binaries - for example, gal is used only by evolution.

In these limited cases, static linking can give us a little extra portability. However, if we truly want the application to work anywhere, we need to link everything statically. This gets into a whole new realm of problems.

In the end, we're really not going to gain much. Static linking may solve a few library dependency issues, but it can't help at all when there's integration with distribution-specific config files or layout. In many cases, the bugs that result from bad integration are much more frustrating than the fact that your suse doesn't want to install a fedora rpm.

We also run into problems if a library has bugs. Bugs, as you said, are a significant hinderance to usability. Let's assume that distro X chooses to statically link the mozilla libraries, because there's so much variation that it makes portability hard. If a security bug is found in one of those libraries, not only do we have to rebuild all those packages, but what happens when a user finds an old package in some index somewhere and decides to try to install it?

Static linking is not a silver bullet. zlib, anyone?

while i agree with the majority of what was said, i disagree slightly with the authors definition

usability is the science of how usable an interface is. it is as strongly tied to cognitive psychology as it is to engineering. themes CAN be a usability issue, but only in the case of say, dark red text on a black background. (of course, if you subscribe to the jef raskin school of design, preferences in general are something to be avoided whenever possible).

i think the biggest misconception about design is it is some sort of subjective art form. it really isnt, good interface design benefits all humans, as it is based on the way the human mind thinks. if you happen to have learned the system already, that doesnt make it better then something that requires your brain to jump through less hoops to accomplish the same task. what it does require is for you to establish new habits for using the system, and that will make you feel "uncomfortable" or "out of place"(that is also the reason that consistancy is the sacred cow of HCI). once again, this has nothing to do with how usable something is, it has to do with your brain adjusting to a new system where none of the previously established behaviors work anymore.

as for the whole back end stuff the article mentioned, an interface that doesnt do anything is pointless. good design alwas starts with the interface being based on the functional requirements, which will then influence the technical requirements. so something like apt could be considered part of the usability of the system, if the functional requirement was the ability to install software, and through the design phase it was decided to do online repository style.

There are, indeed, a lot of misconceptions about usability out there, and I applaud the author for providing a nice overview of such an important subject. A few additional points that I hope will be useful:

- Usability engineering begins even before we design the product to perform the task. We can start by saying, who is the user? What are his skills and expectations? What task, precisely, does he need to do? Thus in the best case, usability guides the most basic aspects of the product design.

- What makes a product usable varies from product to product: Different users have different needs, and the same task might require a different implementation and/or user interface for different users.

- There are empirical methods (most notably, usability testing) for determining how usable a product is. I have been periodically dismayed to see heated discussions, particularly in the open source community, about the usability of a particular tool, with once side insisting users think a certain way and another side insisting the opposite. Sure, we need to make educated guesses sometimes. But there are good methods for getting real, factual data on usability and resolving these questions.

Anyway, thanks again.

>> refers to whether a certain Product, software or not, enables a user to perform a certain more or less well defined task.
>>

I disagree. Useability is not about whether a product an peform a task or not. It is about HOW EASY it enables the user to perform that task. There are many ways to kill a rat, but some are more efficient, aka useable, than others. For every job, there is a good tool, a not so good tool, and a bad tool. You can use a piece of wood to hammer in a nail, but you are much better off using a hammer. You get my drift? An OS or program is a tool. It is more useable if it is easier to use, and less so the more difficult it is to use. That's why "click on setup.exe" is generally a more useable procedure than "Edit Makefile && ./configure && make && make install".

Verdict on this article: Conclusions reasonable (mostly common sense, SMB is a spectacular example of Micrisloppieness for example) but some of the recommendations are flawed, like custom installer programs.

And I agree about the Obscurity/Complexity points, especially with the directions GNOME and KDE (most notably the tendency to start hiding things and adding layer upon layer of abstractions) are taking to turn Linux into another Windows XP.

But STATIC LINKNIG?!?!?! No the advantages can be had with out the serous disadvantages of run away blote and great difficulty plugging security holes in libraries. Please do some research, some REAL INNOVATION is being done in this area. See http://zero-install.sourceforge.net/ and http://autopackage.org/.

And I agree that some OSS projects could use improved QA, for that matter so could the leading proprietary software companies. Many OSS projects maintain a rapidly developed branch and a stable, often near effortless to install and use branch. I think the Sylpheed, Sylpheed-Claws project is a perfect example of how to do it.

And I also agree that proper use of forums/Wiki to cooperatively create and maintain the documentation is important.

In conclusion I defiantly agree that usability issues are something that everyone working on a project, even the entire collective of OSS needs to take responsibility for.

Separate installer programs for each application is definitely not the way to go. That creates issues with individual application developers providing buggy, incomplete installers that don't do the right thing. For instance, on Windows there are many uninstallers that don't remove the entire program. Also, one installer won't work for all distributions. Different distributions handle file placement in different ways. This is why the current methods of program distribution work. Someone who knows the ins and outs of a specific distro takes the source and makes it into an appropriate package. You can't depend on every application developer to know how to make packages for each distro and to spend the time doing so. For commercial applications it makes sense, but when the source is available, the community can pick up the slack. Package management systems are necessary for the open source world because we all share libraries between programs. Dependency checking is necessary for this to work, and I think package management systems are the most elegant way to do this. This relates to your point about static linking, which I also disagree with based on arguments that have already been discussed here.

I agree with your stability issue, but I don't agree with the solution. Releasing less often means less testing gets done. Many people aren't willing (or don't know how) to compile programs from CVS. By actually making a release and people making packages for it, more people get it. Instead, developers should create stable and unstable branches, so users know when to expect bugs and when not to. Intrepid users will still use the development versions and provide the valuable feedback necessary to keep the stable versions bug-free.

It's a well written article. Usability does not just apply to graphic user interfaces. It applies to all interfaces. What is an interface? An interface is a way to communicate with an object. The object could be anything.

An article that nobody understands is bad usability. An application programming interface that takes 4 years to master is bad usability. An electronic appliance that makes you curse incessantly is bad usability.

Usability means making things easier and efficient for people to use and understand. You don't need to be a usability expert to apply usability principles. 90% of usability is common sense and consideration for your users. Apparently, common sense is not common. OSnews' comment editor is an example of bad usability, but I digress.

Once again, it is an elegant and well written article.

when your target audience has a diverse setup.

one example is QT programs. you really think that a developer should expect tat a user of a QT program should have QT installed all the time? not just LDE here, but the general widget set.

when you are going for platform independence, you need a statically linked binary.

Decent article, but it didn't really answer any questions concretely.
First of all, it's been mentioned before, but static linking is NOT the answer. Yes, you should avoid linking to a million and one different libraries, keep it sane, but if a library is probably used by more than one application on the system, it should be shared.

Remember the security holes in libpng on windows? (or was it in GDI+ somewhere, doesn't matter). Hundreds of applications had to be updated to fix just that issue. On Linux, I downloaded the updated libpng and all my apps automatically used the new, fixed version.

Secondly, and I bring this up every time, is that what is usable for one user may not work for another. The statement
that usability is defined by allowing a user to easily perform some task is nice, but ignores how many different users there are.
You say, even advanced users have better things to do than learn unintuitive interfaces when they could just use discoverable ones. This is only true if the interfaces are equally productive. I have spent time learning many features that are not intuitive to a new user, yet make me much more productive.

Now I think that an intuitive interface and an advanced one are not mutually exclusive, it just hasn't been successfully done yet. The MacOS X GUI is discoverable, but lacks many advanced features that I want. KDE is cluttered and complex to a new user, but has all the features that make me more productive, so I use it.

Usability means making things easier and efficient for people to use and understand. You don't need to be a usability expert to apply usability principles. 90% of usability is common sense and consideration for your users. Apparently, common sense is not common. OSnews' comment editor is an example of bad usability, but I digress.

totally and completely wrong, but a very popular misconception. 90% of usability is understanding how the mind works when operating your interface. if you dont understand that, you will be walking blindfolded through a minefield. there are a great many things that are not common sense. for example, modal dialgues are plain evil. modal anything is evil. dialogues with only one choice are evil. dialogues asking for confirmation using a stock message and stock buttons are completely and totally pointless to the experienced user. the human mind can only actively focus on one thing at a time. task flow should alwas go noun-verb rather then verb-noun. preferences and customization are a sign of bad design.

do i need to go on? none of those are common sense, most of those fly in the face of common sense. joe coder wouldnt know that unless he has an interest in the subject.

yes let's have all static linked programs of 20Mb with all their own version of the dependencies...talk about bloatware!

That does not mean static linking is not usefull sometimes.

> it's not about having all application share the same looks

Actualy, this is prety much 50% of usability.
Consistency.

Statically linking packages is broken by design. Apart from the fact that is makes your application needlessly bloated, it's security ramifications are disastrous. What does a user do if a few of the libraries a statically linked application depends on are known to have security and design bugs? The response is nothing. The user lives with it, or waits for a developer to statically repackage the application with the necessary fixes.

Not only does that increase the work load of the developer, users of the application suffer especially if there a fixes available for bugs in libraries but not the application.

static linking makes for overly large applications BAD if you want a small install.

separate installers for programs. what if I want to upgrade my entire computer? how usable is opening 50 installers?

I agree with linux_baby Usability is about HOW easy a program is. you can have a program and it'll do everything you've ever wanted it to do.. but if I can't understand it what good is it?
portage in gentoo comes to mind on this. It can do _EVERYTHING_ or so it seems.. but it's taken me 2 years of using it to understand how to do all the cool fun stuff. I'm still no whiz at it but I like it none-the-less.

When I think of usability nightmare I think of Kaffeine 0.5
why? pause/play's keyboard shortcut is now separate keys??
No skipping ahead shortcut. when the author made this new version he wasn't going forward in features and usability he went backwards!

You say that you should test your programs. that's the reason for the "release early release often." this is so that programs can get a lot of testing and development can move forward quickly.
releasing not very often doesn't get programs tested that often. Take for example the linux kernel. Linus was complaining about how no one tested the unstable branch so they tried to make testing releases more frequently. this got A LOT of testing done.. until people knew it wasn't considered "stable" I personally think the kernel's development moved quicker than even the jump from 2.4 to 2.6

"Take, for example, Firefox. I installed the 1.0 Version, imported my Preferences from Mozilla, and after some days, I became aware that some sites were subtly broken. I did some research on the Net and found out that I had to delete my .mozilla file to fix Firefox, because the old preferences file was screwing up something. That's poor usability too."
No I'd concider that a bug.

If you want to understand usability look at the word .. and make it usable.

Secondly, and I bring this up every time, is that what is usable for one user may not work for another. The statement
that usability is defined by allowing a user to easily perform some task is nice, but ignores how many different users there are.
You say, even advanced users have better things to do than learn unintuitive interfaces when they could just use discoverable ones. This is only true if the interfaces are equally productive. I have spent time learning many features that are not intuitive to a new user, yet make me much more productive.

sorry, but you are incorrect. good design is based around the human mind, and the way the mind works at a fundamental level is universal to everyone on the planet. if a well designed interface is not usable to you, that means you are an alien ;-)

intuitive != usable. machines and humans dont work the same way, it requires training for humans to be able to use machines. now, you can design based on the task, or even worse based on the way the machine works, but doing so forces the user to jump through mental hoops to use your interface. basing an interface on the way the mind works will minimize that, reducing the amount of energy that the brain consumes (how usable an interface is can be judged by how much glucose is consumed while performing the task, however we cant accurately, cheaply, and safely measure that yet.).

there was an editorial here awhile back by a coder who hated all guis till she hit the mac. at one point she says that using windows actually leaves her feeling more exhausted. thats because it takes more energy to operate windows then it does mac (of course, that is an educated guess, but i would be quite suprised if i am wrong). i have had similar experiences, especially when using an unfamiliar or "clunky" design, by the end of the day i feel like i have run a marathon.

as for advanced/novice distinction, anything designed along those lines will once again be doomed to failure. there will be learning involved no matter how usable your interface is (note that intuitive is something completely different, and is more directly related to learning). while not forcing the user to learn every intrecacy of the entire app to perform even trivial tasks is a good thing, operating under the assumption that beginners need different things then experts is faulty. first of all, how will the beginner become an expert without the expert features? if the expert features are hidden, then using them frequently will be a problem. if the expert features are say, a toggleable toolbar, you will have thrown consistancy out the window and forced the user to develop a new set of behaviors, effectively making your new "expert" a novice again in this area. its far better to ignore the whole thing, and have things like visibility be determined by frequency of use rather then user level.

anyways, i apologize for the long rant, but i, like the author, get frustrated by the gross misunderstanding of the word, especially now that it has become trendy.

i hate it when geeks try to redefine words. here is the M-W unabridged:
Main Entry: us·able
Function: adjective
1 : capable of being used
2 : convenient and practicable for use
- us·abil·i·ty /"yü-z&-'bi-l&-tE/ noun

this is the basic definition folks.

for example, modal dialgues are plain evil. modal anything is evil.
Not if they are informing/asking about something that is critical to you continuing to work in the application.

dialogues with only one choice are evil.
That would be a message box, not a dialogue, and they are very useful.

dialogues asking for confirmation using a stock message and stock buttons are completely and totally pointless to the experienced user.
Standard save dialogs are a bad idea? I think you're cracked.

preferences and customization are a sign of bad design.

Wrong. Very very wrong. In any given complex software there is a very large set of preferences that cannot be removed no matter how much additional code you write to make it automatic. A simple one is: "Use left handed mouse button mappings". There are millions more just like this.

do i need to go on? none of those are common sense, most of those fly in the face of common sense. joe coder wouldnt know that unless he has an interest in the subject.

Remind me not to use any of your software if you seriously believe in those rules.

just thought of an example that may be helpful (30 seconds after i hit submit, when will we get an edit button eugenia?)consider the IDE. it is downright impossible to make an intuitive ide. noone can just sit down and start coding, there is a great deal of learning involved. that being said, the one that i use (intellij idea) is both the most usable, and unintuitive application i use on a daily basis. i have developed automatic behaviors for countless small operations, at the same time after two years of daily usage i STILL discover new features, and STILL have to google for a good explination of what something does.

intuitive = obviously works a certain way (how to operate a button)

learnable = easy to learn. you can become a master in a short amount of time.

usable = minimal amount of mental cartwheels needed to operate.

You are the typical example of someone who thinks usability is all about graphic user interfaces and some obscure rules written in some books. Open your mind friend and read my comment again. This time, calmly.

Also, modal dialogues are not evil. There are situations where they are needed. Developers that abuse modal dialogues just don't apply "common sense". Are "goto" statements just plain evil too?

Usability is not about whether or not modal dialogues are evil. Can your subjects use or understand your work without having a cerebral panic? Without fiddling and fighting with your work? And most importantly, without cursing? If the response is yes, your work exhibits good usability.

In brief, you can apply usability principles to anything with an interface, not just the use, or abuse, of graphic widget sets.

That's why "click on setup.exe" is generally a more useable procedure than "Edit Makefile && ./configure && make && make install".

exactly. the average user just wants something that works and doesn't give a crap about ad-hoc pseudo-scientific definitions of usability. let's face it, linux is a pain in the ass whether one chooses KDE, Gnome, or whatever. the end user doesn't want to hear off-topic stuff like "linux is a kernel, not an OS", "KDE sucks, use <insert WM here>", "RTFM!", and so on.

linux will ultimately fail on the desktop if this inanity and obliviousness continues. (and i could care less since i like its exclusivity.) not that MS "oversimplification" and one-button mouses are much better.

as for advanced/novice distinction, anything designed along those lines will once again be doomed to failure

You misunderstand me. I didn't mean we should design an application with an advanced and a simple mode, I mean, there are interfaces geared towards different users available right now. OS X and KDE were my examples.

its far better to ignore the whole thing, and have things like visibility be determined by frequency of use rather then user level.

Please never do that. The selective hiding of features in the menus of Microsoft Office is horrible for usability. The fact that menu items will dissapear just because I haven't used them in a while is unbelievably dumb. It takes me twice as long to find anything in MS Office because half of the time its either hidden, or has changed location. It's much better to display the whole menu, and users will eventually build muscle memory so they barely have to look at what they are clicking on.

separate installers for programs. what if I want to upgrade my entire computer? how usable is opening 50 installers?

We only need a standard way of defining an interface for an installer. Installers would provide a standard interface and register itself. Then the installation manager would execute each installer automatically.

Think about Windows. Every program can have its own installer, but most programs can be uninstalled by using the control panel. We just need a similar solution where there is also a standard way of calling the program. How the program works is unimportant as long as it supports a standard interface.

About bugs:

There are flexible installation makers on Windows (Wise, InstallShield, Nullsoft) etc. It's not necessary to reinvent the wheel each time you want to make an installer. Just configure your program and compile the installation script/program. When we can have a standard way of compiling programs (make, configure), we can certainly create a standard installation program for Linux.

usable = minimal amount of mental cartwheels needed to operate.

Yes. I'm not sure why we're arguing really. I completely agree on that point.

It's just that I don't think there are a fixed set of usability rules that work for every user.
Take the task of moving or resizing a window. For the novice user, it is most discoverable to drag it by the titlebar, and to use the little grab handles in the corner of the window to resize. For the casual user, this is also the most usable since it is quite evident how to do it, and doesn't have to be explicitly remembered. It also requires little coordination since it can be done entirely with a mouse.
In KDE (and other DE's for linux) you can move a window my holding a key (windows key for me) and dragging anywhere on the window. You can resize by holding the same key and dragging with the right mouse button. This is not discoverable, but very usable, and very fast, since I don't have to aim for the titlebar or the little grab handles with my mouse.

So there is an example of the same process done in different ways, one is more usable for a novice user, and one is more usable for me.

Greetings

I agree with basically everything mentioned in the article but there is one major and very important question that it misses: usability for everybody, including the handicaped.

Software should not only be developed to be cross-platform, structurally adequate, etc., but it should also be adequate for being interpreted by screen readers, it should be carefuly studied from the point a view regarding colour contrast, figures, icons and font tipology, and it should also be very easy quick and effective (as mentioned) to use by all sort of people with as much physical and cognitive diversity as possible.

Building a great program and doing it inside the open-source and free software world is not only providing it with technical quality but it is also giving it for free and to make it accessible to everybody in the true sense of the expression. I think open-source has the oportunity to make this come to reality and to also pioneer it and take advantage comparing it to proprietary software.

for example, modal dialgues are plain evil. modal anything is evil.

Not if they are informing/asking about something that is critical to you continuing to work in the application.

forcing the user to stop what he is doing will result in him losing anything that isnt commited to short term memory. there are a great many things you are sub consciously paying attention to, and they will fade in around 10 seconds. not only that, it requires a shift of the users locus of attention, which is both time consuming and frustrating. sometimes they are unavoidable, but should be used as little as possible.

dialogues with only one choice are evil.
That would be a message box, not a dialogue, and they are very useful.

do you consciously think about how you walk? drink? ride a bike? the mind combines groups of actions into "gestures", and will automate those gestures as much as possible. psychologists call this "chunking". closing a dialogue (or message box, or alert box, or whatever specific name you have for it) will become part of the gesture after frequent use unless it requires your locus of attention. that either makes it pointless, or disruptive, depending on how its used. once again, sometimes unavoidable, but should be kept at a minimum.

dialogues asking for confirmation using a stock message and stock buttons are completely and totally pointless to the experienced user.
Standard save dialogs are a bad idea? I think you're cracked.


read above. "Do you wish to quit?" "Yes, No" only has a use if you are not actively focused on anything in particular (i.e. not using the app) hitting "yes" or "ok" has become automatic for many windows users, driving support people crazy. what you need to do is break consistancy, which will force the user to actually pay attention to what is displayed rather then just hitting ok automatically. by the same note, standard save screens are a good thing for all those reasons, operating the interface becomes automatic, allowing the user to just be thinking about WHERE he wants to save it rather then HOW to save it.


preferences and customization are a sign of bad design.

Wrong. Very very wrong. In any given complex software there is a very large set of preferences that cannot be removed no matter how much additional code you write to make it automatic. A simple one is: "Use left handed mouse button mappings". There are millions more just like this.

you picked one of the few exceptions ;-) any interface that can be made better by a few arbitrary changes, means that it wasnt designed right in the first place. in fact, any change to the default behavior will be breaking consistancy, and if the user ever has to reinstall, upgrade, or use another machine, they will be in "unfamiliar territory" and way less productive. i have a friend who broke a wrist when she was 13, so used the mouse with her left hand while she had her cast. guess what? she still switches the mouse to the left handed mappings.

do i need to go on? none of those are common sense, most of those fly in the face of common sense. joe coder wouldnt know that unless he has an interest in the subject.

Remind me not to use any of your software if you seriously believe in those rules.

oh, not me, pretty much everything i quoted comes from jef raskin, who was one of the greatest designers of computer interfaces. each of those are based on proven psychological principals, and many have been tested in real world situations. if that isnt your cup of tea, i guess there isnt much i can do about that. but this is what usability is, not some nebulous subjective art form.

the point you make is decent however.
Lets look at the current installer for linux or better yet limitations of how programs are.

First when you compile a program it is linked to that file in terms of filename and path.
Distributions have different ideas in where to place certain libraries and programs.
another problem with this is should the library be upgraded every program that was linked to that library will now be broken. unless there is some sort of backwards compatibily in place.
Another problem is different distributions use different versions of programs and libraries. why? some distributions think they are stable and some think they are not.

Lets say you wrote an installer. and lets look at everything you'd have to take into concideration.
Where do the distributions put your type of program?
What versions are they using. Do they have what your program was linked to?
If not then your installer is broken.... Oops...

Lets now look at distributions installers.
Do they know where they put stuff? I'd hope so.
Do they have installed what you used? They are running the same thing you are...
It works.

Also lets look at if people did write their own installer like windows.
it's true that some use a simular installer... not very many do. that's not very standard. in a distribution you are always using what your distribution provides that IS standard for EVERY program.

All of the ideas you say these installers should implement are already done.
it's true that if you go to a different distribution you have another interface to learn but who cares stick with a distribution. there was an article earlier on osnews that discussed what linux distribution was the best and I agree to what he said. if you install a distribution stick with it. you'll only find other quirks that you don't like in others. now if that distribution's quirks out weight the good.. yah I'd say switch but if there is just 1 or 2 quirks.. stick with it and tell them about it.. maybe they'll like your idea.

[quote]I disagree. Useability is not about whether a product an peform a task or not. It is about HOW EASY it enables the user to perform that task. There are many ways to kill a rat, but some are more efficient, aka useable, than others. For every job, there is a good tool, a not so good tool, and a bad tool. You can use a piece of wood to hammer in a nail, but you are much better off using a hammer. You get my drift? An OS or program is a tool. It is more useable if it is easier to use, and less so the more difficult it is to use. That's why "click on setup.exe" is generally a more useable procedure than "Edit Makefile && ./configure && make && make install".[/quote]


That only holds true for the dumb.

I have seen the easiest of easy OS/programs that some say is so hard they wont use it at all.

The artical hit the nail on the head.

Yes, I understand that dynamic linking is great in theory. In practice, well, dynamic linking has its problems.

To start with, every developer has their own pet libraries. Some use gtk, some use qt, some use motif, some use tk, some use xaw, some use xforms, some use ncurses, some use slang. This list is far from complete, and it is just at the UI level. How much code reuse do you actually have here, unless you purposefully set out to limit yourself to one widget set?

On top of that, the developers have to make their libraries as appealing as possible to as broad a range of developers as possible. Enter the concept of bloated libraries which are duplicating the function of several other libraries on the system. This does not sound like code reuse to me.

As for upgrading libraries due to bugs, that sounds like a great way to introduce bugs to me. Think about it: software needs to be tested, particularly if you want usable, bug-free software. Now if the end-user may have one of several versions of the (implied) buggy library installed, the application developer must test against several versions of the library. Heck, they even have to test against versions of the library which do not exist yet. By moving to static linking, the responsibility for bugs in the libraries lies in the hands of the application developer: if there is a bug in a specific version of the library, they can link against a different version of the library; if there are bugs in the version of the library being used, they can patch around the bugs.

You are the typical example of someone who thinks usability is all about graphic user interfaces and some obscure rules written in some books. Open your mind friend and read my comment again. This time, calmly.

actually, im using the word the way it is used by human/computer interaction professionals ;-)

Also, modal dialogues are not evil. There are situations where they are needed. Developers that abuse modal dialogues just don't apply "common sense". Are "goto" statements just plain evil too?

actually, goto and modal dialogues are evil in the same sort of way. anyone who makes a modern language with gotos will be doing everyone who ever has to maintain code written in that language a disservice. there are ways around it, they are just less straight forward. sometimes it cant be avoided, but if you are unaware of the problem its kind of hard to minimize its effects.

Usability is not about whether or not modal dialogues are evil. Can your subjects use or understand your work without having a cerebral panic? Without fiddling and fighting with your work? And most importantly, without cursing? If the response is yes, your work exhibits good usability.


except for the first sentance, you are bang on ;-). what i am trying to say is that the things which cause fiddling, fighting with your work, and cerebral panics, are not alwas obvious unless you have a backing in cognitive psychology.


In brief, you can apply usability principles to anything with an interface, not just the use, or abuse, of graphic widget sets.

agreed. a lightswitch is a fantastically usable object. microwaves on the other hand (for the most part) are not. the reason is that it is quite easy to design a good lightswitch (in fact, it would take some work to mess it up), while a microwave is alot more complex. it is significantly harder to make a usable gui then a usable cli, as the complexity of gui environments tends to be much higher.

Systems I work on at work with large user populations tend to satisfy either *them* or *me*. This is a problem which isn't discussed very often. Usability is something we approach at least in part through mockups and focus studies with groups comprised of actual future users of whatever it is we're doing. Inevitably, there's a good portion of what these users want that I don't want, or that I think will reinforce pre-existing bad habits. A good example of this was a search engine we rolled out. Users (technical to semi-technical, but inexperienced) wanted, initially, a "natural language query" and I wanted a robust boolean search, which we would then train users on, under the theory that in the long run the ability to construct complex boolean queries would allow the people who use this system to work faster (which was a major issue we were striving for). We were in a fortunate position because we had access to the entire user community; something generally rare.

The users won out and now several years later they complain that they get too many hits with each search, and now that they have been around longer, they want a boolean search.

I think there's a lot less consensus about usability - everyone wants it but everyone has a different idea what constitutes it - than many people think. People more than anything resist change even if what they're used to is pretty craptastic (consider the number of users still running Windows 9x). This is a huge problem in my direct experience. If you rolled out a new version of Windows that addresses every usability issue it has, you'd get resistance and complaints from most users, who absolutely hate change, even for the better. This is an immutable law of physics. People eventually adapt, but under protest, and slowly.

Another example - I *hate* pop up message boxes. Hate them. What I want is a small notification or message area. If I had my way, all apps would output errors to this specific box with a nice big cut and pasteable scroll buffer, and this box would never steal focus (For me, a big usability issue with any system is that it should *NEVER* steal focus, and Linux far far better in this regard than Windows. I don't care if it's God trying to communicate with me on IM - never, EVER, take focus from a window I'm typing in. Not even if it's a life and death issue.)

Yet most people kind of blink at me when I recommend this.

To me, a computer with crap popping up all over the screen, and, depending on the OS and configuration, sometimes stealing the focus, is *not* usable...or useful. Actually it irritates the hell out of me. The way Evolution pops up the "checking mail" status box drives me up a wall. Not only does it not give any information as to what it is checking (save the server - and in my case I have about 6 e-mail addresses on a single server I need to check, and when one hangs, I don't know which one it is), but it takes up half of the screen. It would be nice if you could maybe even choose globally whether you wanted pop ups or what I describe.

To me pop up boxes are miserable. I'd rather have something like a tailing log in a small box on the taskbar. (Then again a lot of people hate taskbars/toolbars and consider them a waste of screen real estate - another example of lack of consensus.) Perhaps Y/N/Cancel dialogs could also be somehow wrangled into a single area.

I'm going to beat the hell out of a dead horse for a minute and suggest too that a lot of usability issues don't seem very interesting to developers. The inconsistent clipboard in Linux - a common complaint - drives me batty. I use more profanity daily as a result of the multiple clipboards / broken cut-paste system / whatever it is, than for anything else - not just as relates to computers but in LIFE. I have developed a foul, foul mouth largely as a result of being a Linux user. Unique and perhaps groundbreaking combinations of biblical figures and common filth pour out of my mouth like Niagara Falls.

In some apps, I can simply highlight and middle-click, but not so with, say, Firefox, where I have to select text, copy it, and then CTRL-V to get it to paste elsewhere. I don't usually use CTRL-V to paste anywhere, and I'm always middle clicking, and dumping some hours or days old text to the wrong place. If there was a consensus on one way to cut and paste, I'm sure a significant amount of the user community would protest that it wasn't *their* way, and this is likely to be a big issue especially on very habitual, instinctive skills like cutting and pasting. Look at how freaked out people were over the introduction of spatial browsing (Apparently this is the greatest idea ever / proof of the existence of Satan, depending on who you talk to).

That this (getting back to the clipboard) is even still an issue suggests that there's just not a lot of interest in making these things consistent, and as I am not a Linux developer and pay nothing for these programs, I can only sort of grumble under my breath about it, because I don't want to be laying negativity down on people who are providing a mostly-really-good thing for free. For free software projects, this may be the actual hidden cost. Use what you're given, or lead a development effort to address it. That's maybe not a bad trade-off but it certainly turns off a significant amount of users nonetheless. (If anyone knows of a silver bullet that exists out there now to address clipboard problems, please let me know; you will make my day.)

Even when you bring issues like this up, it generally results in a significant amount of finger pointing. It's not the WM's fault, it's X's fault. Or the application's fault. Or the library. I've felt kind of discouraged, as a user, about bringing these things up. I've tried to be positive and constructive about my usability complaints the few times I did (as opposed to just bitching), but the defensiveness of developers is palpable. And frankly watching the really negative, abusive way some folks complain, as well as their sense of entitlement, I can understand.

And I can even understand why fixing mundane problems, especially if you're not getting paid, just doesn't hold the allure of adding cool features. For the most part, the free software model works, but this is an example (I think) of how it is rough around the edges.

Still, I use it, and will continue to use it, because when I tally it all up I still come out way ahead. I just wish there were less annoyances.

Ok fair enough. I agree with what you say. I was just adverse to the militant: this feature is _always_ bad.

Thanks for replying to my points. Doesn't always happen on OSNews. Mostly people like to attack and not debate.

"Do you know a gui front-end that discovers Windows and Samba Servers in your LAN quickly and reliably, without starting obscure services, setting strange options and requiring you to hit the "refresh" button ten times? The answer is: there is no such thing. It doesn't even work in Windows."

SMB4K. Try it, don't whine. Again, try it and report back.It is instant, it works!

yeah, go figure. every time i argue with someone intelligent here we alwas end up agreeing, and the source of the arguement was a misunderstanding.

first of all, adaptive interfaces are stupid, stupid, stupid. the amazing shifting menus in word is the perfect example of why consistancy is so important, simply because of their extreme disregard for it. its hard to find a user that feels comfortable with that "feature". what i meant about visibility is what do you have on a toolpallet, and what do you have in a menu. something like a paintbrush goes somewhere very visible and accessable. "wreath my selection in flames" belongs somewhere out of the way.

It's just that I don't think there are a fixed set of usability rules that work for every user.
Take the task of moving or resizing a window. For the novice user, it is most discoverable to drag it by the titlebar, and to use the little grab handles in the corner of the window to resize. For the casual user, this is also the most usable since it is quite evident how to do it, and doesn't have to be explicitly remembered. It also requires little coordination since it can be done entirely with a mouse.
In KDE (and other DE's for linux) you can move a window my holding a key (windows key for me) and dragging anywhere on the window. You can resize by holding the same key and dragging with the right mouse button. This is not discoverable, but very usable, and very fast, since I don't have to aim for the titlebar or the little grab handles with my mouse.

what you describe is a quasi-modal approach to window resizing that i like alot (didnt even know about it ;-)) you effectively make the target the size of the window rather then the title bar or the handles at the bottom right corner. doing that makes the target easier to both visually aquire, and physically target, hence improving speed, and reducing the amount of effort required to perform the task.

the modifier key enters you into a mode, where things behave differently. in a general sense, modes are evil, and will lead to frequent user error. a quasi-mode however (one where the mode automatically reverts back after the operation), allows your brain to "chunk" it into one gesture, you arent hitting escape, resizing, then hitting i to go back to "normal" mode, so conceptually the windows key becomes part of the resize operation.

now, im not a usability expert (ive just read alot of books, and am facinated by the subject), but from what i know of usability principals, that sort of resizing is quite usable. there are some problems with multiple ways to do the same thing, but that is often outweighed by improved flexibility as long as you dont go overboard (the more you do something, the easier a job your brain has of doing it automatically. by switching back and forth, you dont take advantage of the training you have already given yourself. however in this case i would say the benefits outweigh that. and again, this is a beginners opinion, the only way i could say for sure is through testing)

now, that was my (extremely noobish) usability analysis of that feature. there were no real rules, it was more along the lines of trying to think of what the process of someone resizing a window would be. every programmer knows that disk reads or writes are expensive in terms of performance. i dont think anyone would say dont save or read from the disk. but they all say to keep it to a minimum. those comments on things like modal alerts are the same. at times it is unavoidable, but it will be expensive in terms of usability.

if this is a subject that is of any interest to you whatsoever, i highly suggest jef raskins "the humane interface". he was the guy who came up with the basic ideas behind the first mac, but left half-way through the project, and didnt consider anything available today (including the mac) to be usable.

For example, take Slackware; indeed it requires a fairly experienced Linux user to keep control of it, but it's fairly easy to fix if something is broken. So in one sense Slackware is not usable because of its high barrier to entry, but in a more important sense it exhibits good usability because its configuration is straightforward and fixable for its target users.

The above quote illustrates exactly what I think is the problem with usability in F/OSS. Usability is linked directly with the product's - wether it be software or anything else - intended audience.

Usability and HCI are sciences in their own right and go well beyond the scope of this article, however the link between audience and usability is an interesting aspect here.

In general F/OSS developers don't necessarily get the usability of their products wrong, rather, they fail to properly identify their audience, which in turn leads to poor usability. This is not surprising, since most F/OSS products are designed bottom-up by programmers and programmers are not usability experts, nor are they system architects. Because of this, most F/OSS products assume a level of expertise far higher than that of the actual audience.

If developers take more time to actually identify their audience and identify their audience's needs and expectations for the product at hand, good usability is more likely to follow.

Poor usability is not strictly a F/OSS problem, a lot of proprietary products - projects with massive amounts of money intended for research - get it wrong. This is in part because usability still doesn't get the attention it deserves, but also because usability is a field in development and, most importantly, because usability is a human-centered field. Humans have a terrible interface to interact with because every single instance of the class "Humans" is different.

This is so true, infact this my gripe with Linux. We have great applications in Linux but when you look at the UI. Here are my thoughts on a few
1. Gimp -> the ui pre 2.0 was all over the place now also it is confusing. You have the same menu repeated if you right click or you use File.
2. KDE -> normally it takes me 3 hours after installing any new distro to arrange menus to my liking otherwise its a whole bunch of KBla KBlaa KBlabla in the Start menu. Gimme a break why cant I have a notepad a calculator a paint in the accessory. Also why do I need to have a prefeence/system tool/system setting why cant it be SETTINGS.
3. Gnome does not let me edit menus in Fedora so I gave up. I was trying to edit them in JDS 3.0 and the system totally crashed on me.
4. I know there are Billion and a Half apps for linux but really the Linux distros should prioritize what they want to include with their distros based on usability. Rhythmbox comes to my mind off hand as an app good for nothing. None of the distros that I have installed had rhythmbox work for me.
5. Why do we have rhgb bootsplash [ok] prompt when the system boots. Agreed there is a geek aspect to it but really who cares. I always get amused when I get the boot message "Wireless adaptor wlan0 failed to initialize check you cable"
6. I liked mandrake in the pre 8 days because it was the only distro that had proper menus no matter what WM you used .
I guess Linux need some direction from artists who need to work more than coders.

Useability is a matter of opinion, and therefore, any debate over this is utterly pointless and destined to end in a flamewar.

I find Tracker/Deskbar the the highpoint of useability. Yet, my next-door neighbour may completely disagree. And I'm cool with that; my perception of useability is different than his.

I agree with you on almost every point but very few. You do not need to be a cognitive psychologist, human computer interaction expert or usability engineer to produces usable objects. Also books on usability, user interface design and user interactions only serve as guides. They are not unconditional and unbreakable laws or rules.

Many of the so called "expert" suggestions, with regards to usability, break when implemented in real world testing and deployment. This isn't the fault of the "experts," but rather it is the fault of the designers who failed to acknowledge when the rules were inapplicable. Good designers know when to break or bend the rules, and when or how to apply them.

I encourage people to read books, articles, journal and papers on usability and related topics. However, they equally need to understand that there is no substitute for the practicality, critical thinking, creativity, innovation, experimentation and testing with regards to producing usable works.

In short, not using "goto" statements or modal widgets because it conflicts with usability authority X's principles wouldn't produce usable works. Rather, thinking critically about your subjects, their usage patterns and the problems they are trying to solve should be a start. In addition, extensive testing and experimentation can not be overlooked. Finally, using usability materials written by experts as reference material and guidelines may produce usable objects.

At the core of it all is common sense. I mean Jeff Raskin is a respected and renowned usability authority and all, but some of his postulations are too radical for practical deployment.

dear lord, this thread is full of posters who arnt morons! whats happening to osnews?

Systems I work on at work with large user populations tend to satisfy either *them* or *me*. This is a problem which isn't discussed very often. Usability is something we approach at least in part through mockups and focus studies with groups comprised of actual future users of whatever it is we're doing. Inevitably, there's a good portion of what these users want that I don't want, or that I think will reinforce pre-existing bad habits. A good example of this was a search engine we rolled out. Users (technical to semi-technical, but inexperienced) wanted, initially, a "natural language query" and I wanted a robust boolean search, which we would then train users on, under the theory that in the long run the ability to construct complex boolean queries would allow the people who use this system to work faster (which was a major issue we were striving for). We were in a fortunate position because we had access to the entire user community; something generally rare.

The users won out and now several years later they complain that they get too many hits with each search, and now that they have been around longer, they want a boolean search.

"the customer is alwas right" is a good way to sell units, but a terrible way to build a quality product (paul graham had a fantastic essay on this called "made in america" in his book). the fact of the matter is, the customer knows what they want, not what they need. this is a beautiful example of this fact. making a car "better" by putting tailfins on it is another.

I think there's a lot less consensus about usability - everyone wants it but everyone has a different idea what constitutes it - than many people think. People more than anything resist change even if what they're used to is pretty craptastic (consider the number of users still running Windows 9x). This is a huge problem in my direct experience. If you rolled out a new version of Windows that addresses every usability issue it has, you'd get resistance and complaints from most users, who absolutely hate change, even for the better. This is an immutable law of physics. People eventually adapt, but under protest, and slowly.

you can learn to use pretty much any interface. it is a matter of how exhausted you will be at the end of the day that will never fully go away from using a bad interface. where the problems come from is users are unaware of this, and someone who has learned to use a bad interface will find a good one difficult, frustrating, and unfamiliar. that is, until he learns it. then he will love it.

Another example - I *hate* pop up message boxes. Hate them. What I want is a small notification or message area. If I had my way, all apps would output errors to this specific box with a nice big cut and pasteable scroll buffer, and this box would never steal focus (For me, a big usability issue with any system is that it should *NEVER* steal focus, and Linux far far better in this regard than Windows. I don't care if it's God trying to communicate with me on IM - never, EVER, take focus from a window I'm typing in. Not even if it's a life and death issue.)

Yet most people kind of blink at me when I recommend this.


dude, read my comments to leo about this very subject. there are psychological reasons for this, you happen to be more aware of how you work then the vast majority of users. congrats ;-)

To me, a computer with crap popping up all over the screen, and, depending on the OS and configuration, sometimes stealing the focus, is *not* usable...or useful. Actually it irritates the hell out of me. The way Evolution pops up the "checking mail" status box drives me up a wall. Not only does it not give any information as to what it is checking (save the server - and in my case I have about 6 e-mail addresses on a single server I need to check, and when one hangs, I don't know which one it is), but it takes up half of the screen. It would be nice if you could maybe even choose globally whether you wanted pop ups or what I describe.

To me pop up boxes are miserable. I'd rather have something like a tailing log in a small box on the taskbar. (Then again a lot of people hate taskbars/toolbars and consider them a waste of screen real estate - another example of lack of consensus.) Perhaps Y/N/Cancel dialogs could also be somehow wrangled into a single area.


"A modeless and monotonous interface would be extrodinarily pleasent to use"
-jeff raskin

(monotonous meaning one clear way to do things, lowering learning time and increasing automaticity)

I'm going to beat the hell out of a dead horse for a minute and suggest too that a lot of usability issues don't seem very interesting to developers. The inconsistent clipboard in Linux - a common complaint - drives me batty. I use more profanity daily as a result of the multiple clipboards / broken cut-paste system / whatever it is, than for anything else - not just as relates to computers but in LIFE. I have developed a foul, foul mouth largely as a result of being a Linux user. Unique and perhaps groundbreaking combinations of biblical figures and common filth pour out of my mouth like Niagara Falls.

the geekier the person, the more resistance you will get because they will be more willing to learn an inhumane system. i have been on a usability crusade here at work for awhile now, and meet constant resistance from my fellow developers who dont see the how many of them are worth the effort. thats why i started buying books, so i could have something concrete to back up my statements. linux is the result of a high concentration of uber-geek, so it stands to reason that features would be paramount, and usability an afterthought.

In some apps, I can simply highlight and middle-click, but not so with, say, Firefox, where I have to select text, copy it, and then CTRL-V to get it to paste elsewhere. I don't usually use CTRL-V to paste anywhere, and I'm always middle clicking, and dumping some hours or days old text to the wrong place. If there was a consensus on one way to cut and paste, I'm sure a significant amount of the user community would protest that it wasn't *their* way, and this is likely to be a big issue especially on very habitual, instinctive skills like cutting and pasting. Look at how freaked out people were over the introduction of spatial browsing (Apparently this is the greatest idea ever / proof of the existence of Satan, depending on who you talk to).

That this (getting back to the clipboard) is even still an issue suggests that there's just not a lot of interest in making these things consistent, and as I am not a Linux developer and pay nothing for these programs, I can only sort of grumble under my breath about it, because I don't want to be laying negativity down on people who are providing a mostly-really-good thing for free. For free software projects, this may be the actual hidden cost. Use what you're given, or lead a development effort to address it. That's maybe not a bad trade-off but it certainly turns off a significant amount of users nonetheless. (If anyone knows of a silver bullet that exists out there now to address clipboard problems, please let me know; you will make my day.)

inconsistant behavior is the great satan of usability. there is no better way to jolt a user out of whatever he is working on by having things behave inconsistantly. imagine you are walking, eating a snack, and working out an algorithm. eating and walking are done automatically, your focus of attention is on your algorithm. suddenly, you notice something fuchia in your tuna sandwich. what will happen now?

you stop walking.
you stop thinking about that problem.
you stop eating, and shift your focus to investigating the anomoly.

the same thing happens whenever you encounter an inconsistancy in an interface.

Even when you bring issues like this up, it generally results in a significant amount of finger pointing. It's not the WM's fault, it's X's fault. Or the application's fault. Or the library. I've felt kind of discouraged, as a user, about bringing these things up. I've tried to be positive and constructive about my usability complaints the few times I did (as opposed to just bitching), but the defensiveness of developers is palpable. And frankly watching the really negative, abusive way some folks complain, as well as their sense of entitlement, I can understand.

And I can even understand why fixing mundane problems, especially if you're not getting paid, just doesn't hold the allure of adding cool features. For the most part, the free software model works, but this is an example (I think) of how it is rough around the edges.

agreed. programmers are not qualified to design interfaces (and i include myself in that statement, i am a self-taught noob) the problem is that your average coder has no clue how important this stuff is.

"make sure that your file formats and configuration data is at least forward compatible"

Bacward compatible data formats can sometimes be used, such compatibility is many times a must.

"Forward compatible" is just a desire, a good foundation may help, but you can never promise to be compatible with some software that was not yet written.

Nice article anyhow.

jef refused to accept the times he lived in, and was alwas frustrated both by how little he had to work with, and what a poor job everyone does with what they have. on one side you are correct, many of his ideas are not really practical, at least today. on the other hand, someone who thinks outside the box will not be afraid to challenge faulty conventions.

taking the time to think things through would be a collosal improvement over current designs, but it still wouldnt take into account things you are not aware of. i am a better designer now then i was six months ago, and that is because of the reading i have done on the subject (i still suck in a major way). i think we need to develop a set of sane standards before anyone can be a designer.

that being said, i dont think that the words of raskin or the tog, or nielson, or anyone else are nessicarily law. i think however, that there is a fundamental level that needs to first be achieved before we start getting into the more subjective "this is better then that". when the tools available discourage developers from making usability blunders, then we can all be designers. until then, we need to understand how the various elements work before we begin, or we will be doomed to failure.

You've got umpteen OSs that happen to run on top of the linux kernel that are slightly dissimiliar enough to be annoying. That is the real reason that issues like deployment and static linkage have to be brought up. You don't run Linux, you run RedHat or Suse, or Debian.

I agree. The bar is further raised, unfortunately, for free software projects because many of them do not have access to usability experts, or do not pay attention to usability at all!

Fortunately, some projects, GNOME in particularly, are beginning to understand the importance of usability. I sympathize with free software developers. They have to be graphic artist, project manager, system architect, usability expert, tester, documentation writer, hacker and many more at the same time!

Yet, people never cease make fun of and disparage the efforts of these developers instead of help. Articles like this are a blessing because it reinforces that usability should be a key part of software development, or any other creative pursuits for that matter.

intuitive = obviously works a certain way (how to operate a button)

learnable = easy to learn. you can become a master in a short amount of time.

usable = minimal amount of mental cartwheels needed to operate.

I think this is really interesting because one of the things that has been bothering me after 10+ years of doing usability tests is that we are confusing two separate questions: How much time does it take to perform a task? (usability) and How much time does it take to learn an interface? (learnability).

A lot of this is highlighted for me by the inexplicable popularity of vim. Vim breaks most of the dogmatic rules that tend to go with usability: it's modal, capabilities are hidden, it has a high learning curve. The assumption here is that given a choice between an editor like vim and a more "usable" editor like Kedit, ultraedit, bluefish or bbedit that I'd adopt the editor with functions that use nice pull-down menus. I suspect the popularity of vim is because once you've learned the interface, it permits some pretty powerful edits using a minimal amount of time and/or keystrokes. Similarly, regular expressions require quite a bit of time to learn, but make quite a few tasks easier after you have learned them.

A lot of the most powerful systems available use interfaces that are not exactly easy to learn: a car, a motorcycle, a multi-speed bicycle. A lot of what makes these systems highly "usable" in the hands of an expert is that they sacrifice explicit labeling for ergonomics. In addition, it is difficult to claim that these interfaces are intuitive. (Especially the toe-shift on a motorcycle that typically puts neutral a half-step between first and second.)

The more I have to deal with usability, the less convinced I am about the validity of the standard usability testing protocol that starts with a novice user, and measures time to perform a task.

Actualy, this is prety much 50% of usability.
Consistency.

So, in your opinion, apps such as Windows Media Player and WinAmp are not useable?

How about games? Are all games unusable because they all have their own interfaces?

Consistency is overrated.

To prove that usability sure ain't just a matter of taste, here's an interesting site about examples of bad usability design (not just softtware but many sorts of machines etc. too):

Educate yourself:
(and read the text beside the images too)
http://www.baddesigns.com/

uhm..., so to be accurate: the site http://www.baddesigns.com/ I mentioned above is not really about software at all, but about usability in general. But basically usability is usability, whether you use a PC or a car or a washing machine: you have study what the needs of the typical users are, and then design the product for them.

From Wikipedia:
Usability is the measure of how easily a thing can be used (typically a software application or a piece of hardware). This is generally defined in terms of the needs of the users of the thing. Often, the intentions of designers directly conflict with these needs.

Usability addresses the full spectrum of impacts upon user success and satisfaction. The usability designer provides a point-of-view that is not dependent upon computer programming goals because the usability designer's role is to act as the users' advocate.

I disagree with the author's comments about ``releasing early, releasing often.'' Te whole point of this is to gain more feedback from the userbase and other developers in order to refine the program and, amongst other things, make it more useable.

Open source should not be subjected to marketing pressures. Programmers should notbe pressured to delay releases as this will be a detrimentto the quality in the longer term. If an early release is buggy and unstable, so be it. It is necessary to have something to review in order for advice to be give on how to improve it.

Hopefully, the programmer will act on that advice and any patches supplied. If they fail to, it is quite likely the software will splinter and a rival will emerge fromthe original code base.

So, in your opinion, apps such as Windows Media Player and WinAmp are not useable?

Yes. You may be used to these interfaces, but they are not usable. Especially Windows Media Player is horrible. That UI is one of the most confusing ones I use on a daily basis and adds nothing good to the application. A case can be made for Winamp's UI, since it permits some useful things that are not possible with standard widgets, but overall, it is confusing as hell to someone who is not used to it.

How about games? Are all games unusable because they all have their own interfaces?

For the most part, yes. The reason they have non-standard interfaces is
A) eyecandy
b) there are no good standard opengl/directx widgets to use

Menu systems for games are pretty crappy. Each one works differently. Yes they're not impossible to use, but they could be better. These menus all provide the same functionality, but each one forces you to think about what you're doing instead of just doing it.
However in the case of in-game interfaces, a non-standard interface may be beneficial just to preserve the feel of the game.

"Learnability" is a key aspect of usability. VIM, albeit one of the most powerful editors I've ever used, is a leading example of how not to design an editor. Randomly select 10 individuals from your local store and place them before VIM. Marvel as they curse all day in front of the monitor.

VIM is a powerful editor designed by geeks for geeks. You need to spend weeks reading the manual and book, months mastering its interface and idiosyncrasies and years realizing it doesn't scale well for large projects. Many times, one is better off using Notepad or Gedit than VIM.

I've used VIM religiously in the past, and I was a staunch advocate of it at some point. But even then, I remember cursing a lot when using VIM. It never became second nature to me, even though I pretended it did. VIM is a great editor, but it's only usable by those who have way too much time on their hands. I forsee it's popularity diminishing with time. I'm going to get flamed for this.

"
You may be used to these interfaces, but they are not usable. "

How is he playing the latest Britney mp3?

The buttons lkook different, butt hey're still buttons! If anything, Winamp as an app was harder to learn how to use then WMP.

Interesting to note that nobody mentioned that an ISO standard exists for usability (ISO 9241): the three requirements of usability are effectiveness (the ability of a user to complete a task), efficiency (the resources used to complete the task), and user satisfaction (self explanatory). Some folks in the BayCHI group think that all three are highly associated so a single metric can describe the usability of a product, though my own research differs from this.

A lot of usability is based on empirical work in human-computer interation (i.e., there is a rational basis for a lot of it), though in my experience quite a few industry 'experts' are not that well educated (they often spend a long time 'discovering' things that have been understood for a long time).

The biggest problem is that a lot of HCI is counter-intuitive - it's not obvious and only good user testing shows up the flaws.

My advice to anyone interested is read around. Card, Moran and Newell's 'The Psychology of Human-Computer Interaction' is a good start for those who like hard evidence. Best of luck!

Static linking seems just fine when you release: you ship one big honking binary and everything's fine; it runs everywhere.

But whoops, there's a security bug reported against one of the libraries you use, it's a bad one, and all the distros release an update. If you statically linked, your app has a security bug still. If you dynamically linked, it does not.

Static linking also increases memory requirements, especially if you statically link against common libraries (like the C library, or basic X libraries). Other apps the user already has running use those libraries; if you prevent sharing, you make paging and loss of performance more likely, especially for those with older machines.

All that said, it may still pay to ship binaries that are at least partially statically linked if they require "bleeding edge" libraries, that is, libs not commonly available on distros that are in common use. Even in this case, the decision to link statically or dynamically can be made separately for each library.

I think this is really interesting because one of the things that has been bothering me after 10+ years of doing usability tests is that we are confusing two separate questions: How much time does it take to perform a task? (usability) and How much time does it take to learn an interface? (learnability).

well, i would disagree for a few reasons. theres this standard evaluation heuristic called GOMS thats widely used to get an idea of how long it will take a user to perform a task, and i know that some of its extensions take into account learnability. the other thing is that learning doesnt end, a user will keep getting better and better. i have seen photoshop pros at work, and it is an incredable thing to watch. another example would be touch typing, you do slow down around 40wpmish, but you will still increase at a steady rate. the same is true for computer interfaces. what we need is to have a good emphasis on help systems (the man who came up with tooltips should get a friggin medal)

A lot of this is highlighted for me by the inexplicable popularity of vim. Vim breaks most of the dogmatic rules that tend to go with usability: it's modal, capabilities are hidden, it has a high learning curve. The assumption here is that given a choice between an editor like vim and a more "usable" editor like Kedit, ultraedit, bluefish or bbedit that I'd adopt the editor with functions that use nice pull-down menus. I suspect the popularity of vim is because once you've learned the interface, it permits some pretty powerful edits using a minimal amount of time and/or keystrokes. Similarly, regular expressions require quite a bit of time to learn, but make quite a few tasks easier after you have learned them.

ive been thinking about vim alot recently as well. regular expressions is another one i hadnt thought of, but its real similar. a third would be a ascii based rpg i used to play called "angband" (based on moria, and quite roguelike for those who are into such things) it has a redicules amount of commands, but once you learned them all you could do a remarkable amount of things, far more then most "modern" games in the genre. you do make a real good point, but i think it goes a bit further. there is no more powerful way then regular expressions for pattern matching, and something like that in and of itself is a conceptual work of art. same thing with vim, i cant think of a more powerful editor. the thing is, just because it is powerful, doesnt make it easy on the brain. the amount of work it takes to get profiecient in it is just phenomenal, and the demands on the memory are far more then are acceptable to inflict on the average user (remember,