Since usability seems to be a major topic on the OSNews forums, I think time has come to clarify some common misconceptions. Usability is not about selecting the fanciest Theme from kde-look.org, it's not about 'Reading the F*** Manual', it's not about having all application share the same looks, it's not about nice front-ends to obscure command line programs, it's not about newbie-friendliness, it's not about apt-get install foobar and it's not about setup.exe.
Post a Comment
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
"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, spatial cues can be used for memory in a gui, it cant in a cli). what makes regular expressions, vim, and angband so enjoyable to people who have gained some profincy is the trivial amount of effort to perform quite complex tasks. just think of what you can do in five keystrokes with vim, compare that with a similar amount of effort in word. in angband, i can do virtually anything in under three keystrokes. with regular expression, i can do more with one string then i can in ten steps using virtually any other sort of pattern matching. i would say that these kinds of interfaces require a substancial amount of effort to both learn and operate, but that can be outweighed by their power for complex tasks, but only for a specific class of users. i use and love the cli in linux, but if im hunkering down for some long term work, im going to drop it for my ide and graphical environment. that doesnt mean having it available isnt downright indespensible at times, but i find coding all day in a gui to be more enjoyable.
but anyways, like i have said before, im still quite new to this stuff, and could be wayyyyy off. im definately an armchair usability expert, so take my opinions with a grain of salt ;-)
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.)
well, industrial design is still usability. how many people nowadays use manual, compared to the amount that use automatic? for shear interface design, one example that is in virtually every book i have read on the subject is a plane crash that was due to bad cockpit design, the pilot thought he was doing one thing and was actually doing something else. in an environment like that, a bad interface can literally be fatal. the most powerful mp3 player interface i can think of is the ipod, and that has apples design style all over it.
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.
i completely and totally agree. any usability testing that caters to new users will end up only slowing them down when they become experts.
Yes. You may be used to these interfaces, but they are not usable.
...which is why I instantly figured out how to use each of them?
I'll give you that WMP was a bit confusing at first (not as much as RealPlayer, though). But WinAmp wasn't. Why? Because when I pressed the play button, I already knew what was going to happen. Intuitiveness can trump consistency, and consistency is overrated.
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
You're talking about PC games, which are a sub-genre of video games in general (the PC game industry is dwarfed by the console game industry). In console games, consistency is practically non-existent as far as look'n'feel go. Some functionalities are enforced by console makers, however (i.e. Sony's Technical Requirements Checklist), but apart from that one cannot say that they are consistent. And yet 5 year-old kids learn them easily.
Again, it's more important for an interface to be intuitive (and efficient, once you've learned it) than to be consistent. Consistency is something that has recently been brought up by Linux critics who've latched on the KDE/Gnome rivalry, but in the long run it's a false problem.
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.
I doubt you've even used Vim for more than a couple hours, because anybody with half a clue would know that you only have to learn a small subset Vim to be very productive, and in fact, most experienced vim users only use a small subset of the features available of vim.
If you want to be critical of vim, be criticial of something worthwhile like the non-modular architecture of the code, and not try to cover your own incompetence because you couldn't learn to use it.
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.
The more I engage in studying usability, the less convinced I am this is true.
Give 10 random individuals an SLR camera, or a cello and you will see similar results. However, wouldn't you agree that a person with the skills to use an SLR can take better photos than a person using a fixed-focus camera? Wouldn't you agree that a person with the skills to use a cello can create better music than a person using a kazoo?
The camera issue is really interesting. Most of the techniques I can do with an SLR, I can also do with my point and click Cannon digital. The difference is that setting the SLR to photograph in snow involves turning one dial a few notches, while the Cannon digital requires drilling down through two submenus. The digital camera makes the most common kinds of photographs easy: turn the camera on, point and click. The SLR is a bit more difficult to use, but is quicker to adapt to the "difficult shot" where I need control over depth of field, exposure, and focus.
The bottom line is that I'm not convinced that the strategy of putting everything in menus and toolbars is effective as a long-term use strategy. I don't see a big difference between learning a keyboard sequence, and learning a complex taxonomy of functions in pull-down menus.
I have had this VIM argument before. A friend of mine uses it religiously and the sight of him editing text files is spectacular and very efficient BUT I avoid it if possible. He spends alot of time editing text files and has invested the time in it - congrats. I use Nano. It took 10 seconds to learn it. I do use VIM when there is nothing else. There IS a place for VIM and for Nano. This example is very significant in all this discussion and extends across many applications/OS you name it.
Static libs. Apparently OSX apps rely on static libs. How do they deal with the "security" issues? It is a good point. What if Openoffice released a new version everytime a small library had a venerability? Ouchy.
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, spatial cues can be used for memory in a gui, it cant in a cli).
This is one of those things I'm less than convinced about. Do linguistic mnemonics really take more memory than spacial ones? The problem I find with most gui's is that I have to deal with quite a bit of memory load in the form of a taxonomy. For programs with a relatively small number of affoardances such as firefox and notepad, it's not a big deal. When you start looking at Microsoft Word, we have an entirely different story.
Microsoft Word is an excellent case example. I've used MS Word, taught MS Word, provided end-user support for MS Word, and for a disturbingly large number of questions I get asked about MS Word, I have to resort to hunting and pecking through a very large taxonomy to find what the user needs to do in MS Word. And even with the GUI, you still have to rely on some hefty linguistic processing as well because you have to know how the term is used in language of MS Word designers. From my experience, the effort to achieve proficiency in MS Word is also non-trivial.
I think the popularity of vim (which appears to be increasing) is not just due to a peverse desire of unix-heads to be l33t, but due to the experience that the GUI becomes more and more unwieldy when you start piling on more and more affoardances.
well, industrial design is still usability. how many people nowadays use manual, compared to the amount that use automatic? for shear interface design, one example that is in virtually every book i have read on the subject is a plane crash that was due to bad cockpit design, the pilot thought he was doing one thing and was actually doing something else. in an environment like that, a bad interface can literally be fatal.
Certainly. I don't think there is ever an excuse for bad design. What I disagree with is the notion that a design that can't be mastered in 20 minutes is necessarily a bad design. I also disagree with the notion that good design necessarily involves a spacial metaphor (GUI) rather than a linguistic metaphor (CLI).
Lumbergh,
Who me? I doubt you've used VIM for anything other than editing 10 line configuration files. If :wq, hjkl, :v, y and p are your definition of using VIM, I've got news for you.
``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.''
``i completely and totally agree. any usability testing that caters to new users will end up only slowing them down when they become experts.''
I partially agree with these sentiments. In GNOME, useability studies employing novices have helped to remove the obvious issues where a GUI is clearly confusing orinitmidating. However, catering exclusively for new users also slows experts done in some instances. An example of this, found in most GUIs, is the use of the``Okay'' or ``Apply'' button to confirm every single change when formatting documents. For a new user who is hesitant, it is arguably of value but for an advanced user, it becomes a nuisance to confirm everything (or, to defeat the purpose, they click without looking after long.)
It would be far better for all canes to be applied to a document instantly, without confirmation. Instead, an ``undo'' button should be available on formatting dialogues to rolback mistakes. Thus, instead of needing to confirm everything, only those times when an error has been made could be undone.
New users would quickly learn from their mistakes and rollback would be instantly accessible on the less common occassions when they do something in error. There would be far fewer unnecessary mouse clicks through doing this.
I have already raised this on the GNOME bugzilla (don't have the issue number available at the moment, unfortunately.)
probably the greatest flame wars of all time are over this subject. personally, as a user who only uses that small subset of features, i find nano alot more pleasent to work with. cant do much compared to vim, but it is a hell of alot more pleasent to use. and that doesnt come from incompitance, i can use it when i have to, it comes from preference. i also dont use anywhere near all the features that word has to offer, so i avoid it whenever possible.
CBrachyrhynchos,
Perhaps the question you should be asking is how long it takes a photographer to become proficient with an SLR camera as compared to how long it takes a user (or programmer) to become proficient with VIM.
I'm willing to bet it takes longer to become proficient with VIM. :-) I really suck at photography so half of the advance techniques you may use as arguments will be greek to me.
Like I mentioned elsewhere, usability is not about memorizing usability studies and regurgitating usability principles. It's about studying usage patterns and the problems users need to solve. It's not easy. One needs to do a lot of thinking, experimenting and testing.
I believe 90% of usability is common sense. The other 10% is where you call upon experts and scientist to elaborate on theories no one understands. :-)
I think intuitivity (is that even a word?) does play a large part in usability. When a user uses an application, there're 2 main types of users, novice and seasoned users. Between them, there is a difference in what is intuitive. Seasoned users will expect to find things in certain places, for them the consistency is intuitive; we expect applications to function in a certain way after awhile, because we are used to it. The key here is the target audience.
But your application has to be accesible to people starting to use it as well. If you can't keep them on then your application is useless. It's after you can maintain their interest in using your application that they then start looking around at what else it can do, not before.
If you manage to piss off your users when they get started, it doesn't matter what features your application has; they won't use it. In short, your application has become useless. Usability is a combination of many things and is very complex, finding the right balance is the real challenge.
Perhaps the question you should be asking is how long it takes a photographer to become proficient with an SLR camera as compared to how long it takes a user (or programmer) to become proficient with VIM.
I'm willing to bet it takes longer to become proficient with VIM. :-) I really suck at photography so half of the advance techniques you may use as arguments will be greek to me.
In my experience, the SLR took longer: An 18 week photojournalism course. (And I still don't consider myself "good".) I would also argue that the process of learning vim is easier because it offers instant feedback. In vim, I know right away if I hit the wrong key. With a camera, I don't know if I selected the wrong f-stop until I process the film or view the image on a good screen.
But the point is not specifically to champion vim. The point is that there are quite a few interfaces that are extremely "usable" but require varying levels of investment in learning them. Musical insturments for example are hard to learn but very efficient to use once you have learned them.
There are two fundamental usability design flaws I observe in most graphical user interface applications today, namely;
i).they try to provide too many functions/features many of which are needless/useless
ii). they inundate users with too many distractions, intrusions and useless information
How does one solve the problem? My naïve solutions are as follows;
i).design applications that provide one function and one function only.
ii).design applications to target particular users. Don't try to generalize and engineering software for the public, it's silly.
iii).design applications for particular environments. OSS developers think it's cool to brag about how their application runs on GNOME, KDE, OS X, CDE, Windows XP, Palm, Zaurus etc, even though it works, runs, looks and feels different to the native applications on those platforms. Well it isn't. Inconsistent interface can ruin user experience and make software harder to learn and use. Pick and environment and design for it.
iv).every environment worth using has a human interface guide for it's environment. When it makes sense, abide by it.
v).Less is more! GUIs don't scale well for complex task. Try to make the interface minimalist, spartan and simple. Your users will love you for it.
vi).Don't try to build a GUI application when a CLI application makes sense and vice versa
There are more, but I'll bore you if I continue. But these are basic, common sensical solutions. I'm not a usability expert, but I'm sure if solution i). listed above is applied religiously more than 50% of your GUI problems will solved from a usability, design and coding perspective. If advanced users need special functionalities, they can always install special plug-ins to provide for their needs.
vim is retarded and backwards.
I would not take the time to learn it, because I know a text editor should be easy to use. The time it would take me to be productive in vim to how productive I am in open office, or ms office; I would have finished what I was doing in the first place.
It is amazing that people still use it, and its foolishness hasn't died off.
My responses are in CAPS.
There are two fundamental usability design flaws I observe in most graphical user interface applications today, namely;
i).they try to provide too many functions/features many of which are needless/useless
AGREED. AS SOMEONE ONCE QUOTED, GUIs MAKE SIMPLE TASKS EASY BUT COMPLEX TASKS IMPOSSIBLE. THEREFORE, STICK TO MAKIG THEM REALLY GOOD AT SIMPLE TASKS.
ii). they inundate users with too many distractions, intrusions and useless information
EXACTLY. THINK ABOUT THE CONCEPT OF FRAMING. CAMERAMEN AND CINEMATOGRAPHERS DO NOT CLUTTER IMAGES BUT DRAW THE EYES TO A CENTRAL FOCUS IN PART OF THE SCREEN. GUI developers need to do the same.
How does one solve the problem? My naïve solutions are as follows;
i).design applications that provide one function and one function only.
YES, MINIMISE AND SPECIALISE AS MUCH AS POSSIBLE. THERE ARE ALSO THE OBVIOUS PERFORMANCE BENEFITS FORM REMOVING BLOAT.
ii).design applications to target particular users. Don't try to generalize and engineering software for the public, it's silly.
DEPENDS REALLY ON THE APPLICATION. KDE HAVE THREE TEXT EDITORS FOR DIFFERNET AUDIENCES. IS THIS GOOD?
iii).design applications for particular environments. OSS developers think it's cool to brag about how their application runs on GNOME, KDE, OS X, CDE, Windows XP, Palm, Zaurus etc, even though it works, runs, looks and feels different to the native applications on those platforms. Well it isn't. Inconsistent interface can ruin user experience and make software harder to learn and use. Pick and environment and design for it.
NOT SO SURE ABOUT THIS. IN THE CURRENT MARKET, CROSS-COMPATABILITY IS NEEDED.
iv).every environment worth using has a human interface guide for it's environment. When it makes sense, abide by it.
DEFINITELY.
v).Less is more! GUIs don't scale well for complex task. Try to make the interface minimalist, spartan and simple. Your users will love you for it.
AS PER MY COMMENTS ABOVE, GUIs ARE BEST FOR SIMPLE TASKS.
vi).Don't try to build a GUI application when a CLI application makes sense and vice versa
EXACTLY. FOR ANYTHING TRULY COMPLEX, THINK ABOUT USING CLIs and PIPING.
Missed this.
Like I mentioned elsewhere, usability is not about memorizing usability studies and regurgitating usability principles. It's about studying usage patterns and the problems users need to solve. It's not easy. One needs to do a lot of thinking, experimenting and testing.
No, of course not. I'm talking about usability from the point of view as a designer and frequent end-user supporter. I'm talking about usability from the point of view of someone who has sat through many usability studies, and has done followup studies to find that the scaffolding the users requested early became annoying later.
As an example of the difference between linguistic and GUI interfaces. I just spent an extended amount of time trying to figure out a way to design (not program, design) an interface for making complex queries from a hugely complex research database without exposing the user to a lick of sql. The end result was that after going through a couple of different paper prototypes, the programmer and DB administrator said, "you know, it takes me about 5 minutes to get anything out of the database. How about they just tell me what they want."
I'm a competent VIM user. It's the only command line editor I use. I've spent years learning it. I've written plug-ins for it. I know it inside out. You may have skipped over much of my comments, but I acknowledge it's one of the most powerful editors I've used.
However, it is usability nightmare! Its learning curve is beyond the heavens. Working with more than 3 documents simultaneously is hideous. Working with code longer than 1000 lines is torture. And it's emphasis on keyboard mnemonics appeals only to geeks. Its designer's obsession of keyboard efficiency above all else, such as ease of use, discoverability and *gasp* convenience is questionable.
You see when I work with code, I usually have anywhere from 7 to 20 documents open each with thousands of lines of code. I can tell you from experience, VIM does not scale well! And really in that type of setting, I'd rather use Notepad. Keep challenging my incompetence, but I'm willing to bet that you hardly use VIM for anything other than editing configuration files, otherwise some of its usability flaws will be apparent.
Don't believe me? Put any random individual from your household who isn't a geek before VIM and marvel at their feedback. Then we'll know who's full of shit.
P.S. By VIM, I mean the command line editor, not the GVIM the GUI for VIM. I haven't used GVIM and I'm not referencing it in this case.
Personally, I do not think GUIs scale well for complex tasks such as the one you mention. I think a well designed CLI interface will be a more prudent choice. But today, there is such anatema towards CLI applications it's scary. Have you tried experimenting with other user interface appart from GUIs?
1. Choose suitable metaphors. Office analogies have been pushe past tehre limit. Make sure what is chose is accessible to all users. For example, media players that resemble stereos are bad as not all stereos are the same.
2. Avoid icons that are not obvious. Indeed, text is much clearer than icons. As Raskin noted, there was a reason why people moved fromhieroglyphics to alphabets. If in doubt, add a text caption below th icon. The icon would capture the attention of the user and the text would provide instant confirmation, rther than the ridiculous need to hover a mouse to confirm something.
3. Focus on the core product. MS Word has extraneous, tacky garbage like Word Art and ClipArt, making it into a pseudo-DTP tool but still cannot produce standard text of the quality of LaTeX. Give your product some substance.
4. Forego dialogue boxes and focus on floating palettes. Palettes provide instant feedback by applying changes immeidately , do not require the user to click on ``okay'' to confirm everything and enable multiple pieces of text (or whatever) to be selected. Lotus SmartSuite had this absolutely correct.
5. Avoid metaphors that confuse users. All I. T. is discussed in metaphors, even the technical side (``buffer overflows'', `files'', ``directories'', ``bugs'' and so on) so choose simple, clear instructions users can understand.
6. Do not hide options or make menues too long. It is better to forego features tan bury many options in obscure dialogues or produce lengthy menus whre it s too hard toremember options.
7. Only a few options perdialogue, not multiple tabs.
However, it is usability nightmare!
It's not supposed to be the default editor of a desktop, but an editor for fast touch typists.
Its learning curve is beyond the heavens.
But apparently tons of people like using it and have managed to break through "learning curve beyond heavens"
Working with more than 3 documents simultaneously is hideous. Working with code longer than 1000 lines is torture.
That's just your opinion and obviously there are hundreds of thousands of people that disagree with you. why do you continue to use it, if you are unable to figure out Vim after all this time?
And it's emphasis on keyboard mnemonics appeals only to geeks.
It appeals to people that are fast touch typists and understand the philosophy that most code editing is not just typing in characters.
Its designer's obsession of keyboard efficiency above all else, such as ease of use, discoverability and *gasp* convenience is question
It's vim. It's not some stupid little editor like gedit or notepad that is completely unsuited for programming.
I can tell you from experience, VIM does not scale well! And really in that type of setting, I'd rather use Notepad.
Your incompetence shows with ridiculous statements like that. Notepad? bahaha
but I'm willing to bet that you hardly use VIM for anything other than editing configuration files, otherwise some of its usability flaws will be apparent.
No, I learned vim a long time ago and use it in a programming environment as well as using IDES. The only problems I have with vim is its lack of modular architecture which is wholly independent of its usability. This has been discussed on the vim-dev mailing list about creating a "vim-engine" so that IDEs could plug it in.
I don't know why you sought to bring up your frustrations with Vim in here, because obviously its not, nor will it ever be the default editor for any kind of desktop environment.
Go use Emacs if you can't figure out vim.
Personally, I do not think GUIs scale well for complex tasks such as the one you mention. I think a well designed CLI interface will be a more prudent choice. But today, there is such anatema towards CLI applications it's scary. Have you tried experimenting with other user interface appart from GUIs?
In this case, it would have been nice if we could have used sql views and just taught a subset of sql with the name of a few views. However, it a big difference between teaching something like "select * from usersView where..." and teaching "select ... from foo ... join .... join ... join ... join ..."
However, the database software we are using didn't support views.
I'm not questioning VIM's capability. It is a capable and efficient editor, after you spend a decade learning it. Pardon my hyperbole. However, I still maintain VIM is a usability disaster. An application can be capable and yet still be a usability failure. I don't understand which of these two concepts you can't wrap your brain around.
Usability is only relavent to the target audience. Slackware is very usable for who it targets, as is Vim.
The modal philosophy of vim is the usability. The concept that a large percentage of time is not typing in characters, but navigating, changing,yanking, deleting, etc... and that it's easier to be on the homerow rather than fumbling around for the mouse or messing around with ctrl-meta-blah is the usability of vim.
It's not supposed to be a notepad for grandma that is completely usuitable for programming. Usability doesn't exist in some universal context.
I guess that's the point under debate. I think that too often, people talk about "ease of use" when they really mean "ease of learning." These concepts may be related, but I think they are distinct enough that we should not confuse them.
Do you find vim easy to use? Assuming you had a wife, and she is not a computer geek, do you think she will find vim easy to use, and it's features easy to discover and learn without consulting a manual, tutorial or book?
If your response to both questions are yes, you win. If your response to either question is no, then you really do not have a grasp of what usability is all about. You can check online encyclopedias and dictionaries for the definition of usability, if you disagree with me.
In short, it really has nothing to do with touch typing or not lifting your fingers from the keyboard. Heck, you can use almost any application today without lifting your finger from the keyboard. That doesn't make them well designed from a usability point of view.
I'm not a mouse person either. I prefer keyboard shortcut keys to fiddling with a mouse and for that reason I love VIM. However, that doesn't make it a usability model. For one, it's functions are almost impossible to discover unless someone directs you to relevant sources. This is true even for very experienced users, not just our grandmothers, assuming they are computer n00bs.
Yes I find Vim easy to use, no a new user would not. Ease of learning is not the same as ease of use. Don't confuse the two. Vim is hard to learn, but easy to use.
For the last time, Vim is not supposed to be used by Aunt Polly. There are perfectly good tutorials to learn vim, but I don't expect my mom to ever use it.
There is no universal "usability". Is a space craft control system "usable"? Yeah, for astronauts, but not for Aunt Polly - nor should it be.
The purpose of vim or emacs is not to be dumbed down to the point of being a notepad.
Sorry but what is this fear of need ing a manual? I think people should really ovecome this. If there is a need to consult documentation, so be it. Make the software easy to use but there should be nothing shameful about reading the book.
Ease of use and ease of learning are very related. It is understandable why people often use them interchangably. Usability encompasses not only ease of use, but also ease of learning and discovering.
Applications are extreemly high level programming languages. Therefore, all applications need to be learnt. Nobody can avoid this fact. However, some applications are easier to learn than others. Some are also easier to use than others. The goal of designing good interfaces is making them both easy to use and learn. I don't understand why people like to create an artificial distinction between easy to use and easy to learn. I think they go hand in hand.
A software that is easy to use means you can start using it right away without much handholding, fiddling or trial and error stunts. Software that is easy to learn is intuitive. That is, you can guess how things should work and most of the time they work well. It also means you don't need to take 20 course seminar classes and spend weeks discovering advanced functions in the software.
Take APIs for example. With good APIs, you can almost guess how functions work, if behaviours are consistently organized. You wouldn't need to read how every damn function works to use the library. If you are experienced, your experience taps into the logic of how APIs are organised to guess function behaviour. If you are inexperienced, you use patterns to recognize the organisation of the library and the functions within them. That's where intuition and interface design merge. It is the natural human instinct to guess and guess correctly without being surprised by fact that your guess is right.
Either way, ease of use and ease of learning are very related. And in usability, both are key elements to designing interfaces anyone can use. There is no way around it, everyone has to learn how to use software. Some are harder to learn than others. VIM falls under the category of bloody hard to learn and use. It takes a good while to become very proficient with VIM too.
The target audience for Vim isn't your Aunt Sue. A good interface targets a specific audience, and Vim does this very well. If you design to please everyone, you will usually aim to please no one. Vim does not aim to please someone using it for the first time. On the other hand, for someone with plenty of experience is very easy to use.
Do you find vim easy to use? Assuming you had a wife, and she is not a computer geek, do you think she will find vim easy to use, and it's features easy to discover and learn without consulting a manual, tutorial or book?
I've found that there are very few applications that pass the "without consulting a manual, tutorial or book?" In fact, I'll put out this usability maxim based on experience, "for every user interface, there will be at least one person who needs help using it."
If your response to both questions are yes, you win. If your response to either question is no, then you really do not have a grasp of what usability is all about. You can check online encyclopedias and dictionaries for the definition of usability, if you disagree with me.
I think I've read quite a bit of work on this in the last 10 years. And I've noticed one consistent flaw. Usability testing almost always involves testing the time to learn to complete a task in an application. You very rarely hear studies that examine a user 6, 12 or 18 months down the road. The fact that I disagree with you, does not mean that I'm not informed about the issues and research involved.
I prefer keyboard shortcut keys to fiddling with a mouse and for that reason I love VIM. However, that doesn't make it a usability model.
I don't think anybody is putting it up as a usability model. It is an interesting study. If it is so horrible from a usability standpoint, why do people still learn how to use it?
You can apply this to a lot of other interfaces as well, why use R when there is SPSS? Why use mouse gestures or keyboard shorcuts when there are pull-down menus? Why use a command line rather than a file browser? Why use Photoshop rather than a more simple image editor?
The answer is that while these things are harder to learn, once learned they make some critical tasks easier than the alternative.
Interfaces don't target audiences. An interface is a way to communicate with an object. I could write a 1000 word essay where you would have to open a dictionary for every word in the essay. It would make me look cool and smart, but I will be doing great disservice to my readers. My essay can be categorized as a usability disaster. Yes, literate people can read it and eventually understand it, but after how long, at what pace and at what expense?
There are also other aspects of usability. Like preventing the user from making errors and preventing the user from his/her own stupidity. Believe me, you don't want to be drowsy when using VIM. There have been times where I accidentally hit random keys in VIM and didn't know what the fuck just happened. Of course, Lumberg will yell I'm incompetent again. And I should use Aunty Suse's software instead or Emacs.
*sighs*
"I've found that there are very few applications that pass the "without consulting a manual, tutorial or book?" In fact, I'll put out this usability maxim based on experience, "for every user interface, there will be at least one person who needs help using it.""
I'm not surprised. Read one of my comments above. I stated all software must be learnt. This is especially true with users new to computing or specialized software.
"I think I've read quite a bit of work on this in the last 10 years. And I've noticed one consistent flaw. Usability testing almost always involves testing the time to learn to complete a task in an application. You very rarely hear studies that examine a user 6, 12 or 18 months down the road. The fact that I disagree with you, does not mean that I'm not informed about the issues and research involved."
That statement was not directed to you. It was directed to Lumbergh. My apologies for the mix up.
"I don't think anybody is putting it up as a usability model. It is an interesting study. If it is so horrible from a usability standpoint, why do people still learn how to use it?"
People use anything they've spent considerable amount of time learning. That's why VIM users are particularly defensive about it. They've spent way too much mastering it for it to have any flaws. The same is true with programming languages. So languages clearly have design flaws, yet they are powerful. However, you have people willing to behead for pointing out flaws in these languages. They've spent years acquiring and mastering the language, so they take thing personal. I guess it's human nature.
"You can apply this to a lot of other interfaces as well, why use R when there is SPSS? Why use mouse gestures or keyboard shorcuts when there are pull-down menus? Why use a command line rather than a file browser? Why use Photoshop rather than a more simple image editor?
The answer is that while these things are harder to learn, once learned they make some critical tasks easier than the alternative."
I don't see anything VIM does that a good simple text editor can't do. I use Gedit to do everything I used to do with VIM. I use Eclipse to do things I can't even dream of doing with VIM. Well, technically, it may be unfair to compare Eclipse to VIM, but still it needed to be mentioned. :-)
Ease of use and ease of learning are very related. It is understandable why people often use them interchangably. Usability encompasses not only ease of use, but also ease of learning and discovering.
Now you see. Here is the problem. You've admitted that we are talking about two different constructs, and then you go back to treating them as if they were the same construct. The end result is that you destroy just about any validity you have when you attempt to describe or measure "usability."
The goal of designing good interfaces is making them both easy to use and learn. I don't understand why people like to create an artificial distinction between easy to use and easy to learn.
But this is a distinction you just admitted is real, that we are in fact talking about two different constructs. Now you say that the distinction is artificial. Which is it?
Here is a good example. How easy is it for Yo-Yo Ma to perform five octave Gminor scale on a cello? Pretty darn easy. How easy is it for a person to learn how to perform a five octave Gminor scale on a cello? Not so easy.
If Stradivarius had concerned himself with designing an interface that was easy to learn rather than easy to use, we might all be listening to symphonic music built around the the harmonica! (Not really true, getting more than Oh Suzana out of a harmonica is really difficult.)
We are surrounded by interfaces that work brillantly well that we had to learn how to use: books, newspapers, cars, forks, spoons, (anyone who has been around a toddler knows that dining ware requires quite a bit of practice), chopsticks, pencils, shoelaces (my dad still ties his shoes with a granny knot at age 55), rulers. These are also not interfaces that are "intuitive."
A software that is easy to use means you can start using it right away without much handholding, fiddling or trial and error stunts. Software that is easy to learn is intuitive. That is, you can guess how things should work and most of the time they work well.
Don't buy the notion of "intuitive." I think that's just a catch phrase for, "building on a person's prior experience." The concept of cut and paste for example is not at all "intuitive" even with the options in the menu. (Just taught a family member how to do it.) In fact, one of my teachers helped to design one of the first Apple Macintosh tutorials in the days when a fair number of people had no idea how to use a mouse.
It also means you don't need to take 20 course seminar classes and spend weeks discovering advanced functions in the software.
Well, here is where I think you run into some nasty trade-offs. Human perception can deal with a limited number of items in a list of choices. The advanced functions in a software package with a lot of features involve considerably more choices than human perception can handle. (Much less screen real estate.) So what do you do? If you hide the functions behind heirarchy of menus, then you make those functions less obvious and less easy to discover. If you eliminate those functions to create a more usable interface, then you create something that is unusable for the people who need those functions. The Microsoft solution is even worse of selectively hiding little-used functions.
In addition, I don't know of any software package that is used in professional practice that meets this criteria.
Either way, ease of use and ease of learning are very related. And in usability, both are key elements to designing interfaces anyone can use.
Now here is where you show that you don't understand usability. Usability is not about designing interfaces anyone can use. It's about designing interfaces the target population can use. If you are designing a violin, you design for people who play violin. If you are designing a cash register, you design for checkout clerks. If you are designing bibliographic software, you design for graduate students and researchers. If you are designing cockpits, you design for pilots.
Trying to design for anyone is the easiest way to produce something that satisfies no one
``Well, here is where I think you run into some nasty trade-offs. Human perception can deal with a limited number of items in a list of choices. The advanced functions in a software package with a lot of features involve considerably more choices than human perception can handle. (Much less screen real estate.) So what do you do? If you hide the functions behind heirarchy of menus, then you make those functions less obvious and less easy to discover. If you eliminate those functions to create a more usable interface, then you create something that is unusable for the people who need those functions. The Microsoft solution is even worse of selectively hiding little-used functions.''
I think the best of these bad choices is to eliminate the functions. If people need a certain number of special features, let them obtain plug-ins (generally, only the more advancd users will require these extra features). It works for Firefox and GEDit . Tose who need something extra will put in the effort to obtain them whilst it leaves the software clean and simple for those who do not.
In this way, menues are kept small for hte majority whilst a selective number of specialist tools can be downloaded, rather than the current all or nothing approach.
I agree the Microsoft ``solution'' ofselectively hiding has been the worst of all.
Interfaces don't target audiences. An interface is a way to communicate with an object....
Really? I work on a project that serves late elementary school children. Should I design my user interfaces for children to the reading level of adult computer programmers? Should I design my user interfaces for teachers in the project at a 4th grade reading level?
There have been times where I accidentally hit random keys in VIM and didn't know what the fuck just happened.
Unlimited undo.
I can certainly see the benefit for control-key sequences. However, to reiterate my previous point. Usability is not about anyone. vim is easier on my rsi than a lot of control-key sequences.
I'm not surprised. Read one of my comments above. I stated all software must be learnt. This is especially true with users new to computing or specialized software.
Well, it seems you are a bit inconsistent on this. Is it the case that only software that can be understood without a manual is usable, or is all software something that can be learnt. And what counts as "specialized" software? IME new users need significant help with Word, and my wife who is no stranger to computers, is currently on a spree of going through Photoshop tutorials.
In fact, after 20 years of using computers, I still grab a manual or book for any program I intend to spend more than an hour using.
People use anything they've spent considerable amount of time learning. That's why VIM users are particularly defensive about it. They've spent way too much mastering it for it to have any flaws.
Why is vim usage growing?
Certainly, vim does have its flaws. But I don't think this explains all of its usage. I also think that the learning curve is highly exagerated.
I don't see anything VIM does that a good simple text editor can't do. I use Gedit to do everything I used to do with VIM.
Just opened up gedit and notepad to check this out, here is what I find missing.
go to line (gvim but not notepad).
any regex search or replace (neither gvim or notepad)
joining lines
indenting lines
re-wrap paragraph
put output of shell command in buffer (useful for bug reports)
open gpg encrypted files
collapsing sections
spell check
parethetical, brace and bracket matching
open documents in read-only mode
The author has some points, but the issue is made overly complex. If a hammer was designed by software people, we'd have a billion hammers. A hammer was designed to do a particular task for a "user." It can be misused (if you're a bad carpenter), it can be abused (if you're a criminal), or it can be used for the task it was designed for.
So let's talk computers. Originally designed for very specific tasks, they were altered into a general purpose, one size fits all device. Fabulous, except reality sets in and computers really aren't good at being all things for all people. In fact, I can't think of a single example of something that meets that criteria.
I'd rather see several small, well designed devices to do a task (and do it well) than to have one big clunky device to do all of them horribly. Don't look now, but we're doing it with phones now.
It wasn't enough to have cell phones do ten things phones were never meant to do, but now they can get virii and other malware because our desktop has migrated to our palm.
Where are the Internet server machines, computer devices *designed* to be Internet machines and can stop virii and malicious attacks before they start (I have seen it in action - it can work if implemented). Why don't ISP POP mail systems have the capacity to scan you mail for malware - oh that's right, some *do*. I bet those users appreciate that usability feature - they do nothing and their mail is free of disease.
Word processor software is generally overpowered. Why did programmers stop using modularity in software *assembly* (not design)? That is, why can't I install a word processor with just the features I want or need, with the ability to add or subtract them without the need to remove the entire program and re-install it. When programs were written for low memory requirements, the spell checker was in a separate *physical* module. Some are today, but the inclusion of the feature requires it to be a problem to add or remove it by itself. If plug-ins work for browsers and other applications, why don't they work for all applications and even operating systems?
Usability means this and only this: Can I sit down and use this tool to accomplish my task without having to be more sophisticated than I am or can learn to be in the future?
If you answer that question positively, you have usability. If not, you do not have usability. One size may not fit all, but too many engineers trying to make my tool do my thinking, my corrections and so forth without my permission are making a lot of software user-hostile.
If you want to know why you're getting laid off in industry, here's a clue: I neither need nor desire your "updated," "New and Improved," "Must Have" software. I may be out of date, but my computer crashes less than all the people I know, and I use it far more.
I don't use it for a radio (though I *do* buy tunes), I don't use it to watch movies (though maybe to order some), I don't use it to play games very much (well, maybe the occasional solitaire), but I do use it. I use it to write letters, I use it to prepare software for my vertical market buyers, I used it to develop lessons when I taught Computer Science. I use it for various web services you simply cannot do without a computer. But my OS and applications take less than 100Mb and my data can easily be stored on Compact Flash. My usage is, without a doubt, atypical. But maybe if you look at what you have on your computer and ask yourself "do I use this" you'll realize you don't need it. That's when it hit's you.
Usability means using everything you have installed - if you're not using it, how can you justify saying it is usable?
I think the best of these bad choices is to eliminate the functions. If people need a certain number of special features, let them obtain plug-ins (generally, only the more advancd users will require these extra features). It works for Firefox and GEDit . Tose who need something extra will put in the effort to obtain them whilst it leaves the software clean and simple for those who do not.
Resulting in a system that is usable for one group of people, and unusable for another group of people.
You just revealed why you can't just design for anyone.
Usability is making an object easy to use and understand. You are making the subject needlessly complex. Software usability is equally similar. Making software easy to use and understand.
When you design interfaces, you want users to find it easy to use, manipulate and understand, regardless over whether the interface is for a hardware, software, magazine, whatever.
VIM's interface is not easy to use and understand. Editors are general purpose applications in any operating system environment. General purpose in the sense that anyone should be able to use a text editor to edit textual information. Or, at least, this is my assumption.
Browsers, music players, dvd players are other examples of general purpose application that target users of operating systems. A special purpose application will be an accounting software, an image manipulation software, a special effects software to mention a few.
For general purpose software, like a silly editor, why does one need to spend weeks learning how to edit files? All software have a learning curve. The aim of usability proponents is to reduce the time it takes a user to learn or master a given tasks. If the user can guess how a software functions without resulting to opening manuals, tutorials or books, then the software is well designed. This usually applies to general purpose software, like a freaking text editor.
Special purpose software is a little different. However, the same usability principle applies. For special purpose software, your audience is usually targetted. It may be accountants, engineers, artists, law enforcement, whatever. Even then, the goal of usability proponent is to ensure that the learning curve for using an image manipulation tool is as low as possible and the time it takes to learn the software is as short as possible.
For special purpose software, there might be need for training. Why? It's the same reason why one needs years of training to be a software programmer as opposed to say a driver. Driving is a general purpose function. Software programming at professional levels is a speciality. Even with training, via books, manuals tutorials, whatever, a very well designed software will reduce the amount of time you need to get acquintated to the software.
If you are an image editing specialist, using an image editor should not be foreign. Just like if you are a computer user, editing files should not require a manual. Well designed software enables their intended audience use software without fuss. Without unnecessary handholding. It lets users discover functionality, shortcuts easily. It removes needless clutter and encourages a smooth seemless workflow.
If I'm a database specialist, the interface of a database program should just make sense just by looking at it, at least in a utopian world. Maybe if I need to do something complex or advance, I might need to consult a manual. But wouldn't it be better if I play around with the software and discovered how to do it without interrupting my workflow? Okay since I did X to B and I did Y to C, lets see if Z gives me C. Ah, it does! This is cool. This is what discoverability and learning is all about. Getting comfortable with software without breaking workflow, or if possible reading manuals.
Back to Vim. For a general purpose application, VIM is lousy with regards to usability. I mean, the first time I sat before VIM, which the first time I used linux, I had a cerebral panic. "What the fuck is going?" was what constantly resounded in my brain for like, erm hours! I was an idiot. The manual said I should use my favorite editor to edit some files like vim. So I typed in vim and the file name into the command, and there I was battling with a text editor for hours. I couldn't quit VIM. Didn't know how. I didn't know about virtual consoles, there I was with VIM, just pressing random keystrokes.
For an editor, it is utterly dissappointing. Anyway, that motivated me to spend years studying VIM and when I became good at it. I swore by it. Well, until I had an epiphany. I asked myself why editing files needed to be so complex. It just didn't make sense. I also had several problems with VIM which other users ignore that I listed above.
Today, VIM is the only editor I use in console mode or when I'm root for system administration. For everything else, a use a GUI text editor with a simple, intuitive and discoverable interface, Gedit.
Gedit does those everything you listed. I'm not sure about opening files in read-only mode, though. But everything else it can do. And guess what, I didn't need to read a freaking manual to do any of this tasks, and my grandaddy, Aunt, Uncle, girlfriend, whatever can use it too. That's what usability is all about. If I told my girlfriend who isn't a geek to use Gedit to search for a string, I'm willing to bet money she'll discover the search function quicker, easily and without force in Gedit, and she may never, ever, ever, figure out how to do it in VIM. And guess what, they are both text editors. The same applies to specialized software. If an accountant needs a manual to use your accounting program to figure out simple takes such as entering business transactions, we have a problem.
It's late over here, I apologize for my grammatical blunders. Yeah, bad usability, I know. :-)
By designing for anyone, I mean design so that anyone can use a software not just geeks. At the moment, I don't know anything about astronomy. If I'm put before an astronomical software, I should at least understand basic functions. What are basic functions? Some of them are as follows:
1). I should know how to quit/shutdown/terminate the program
2). I should know how to navigate the program
3). I should be able to guess that the red button over their might be dangerous.
4). Function commands should be descriptive. (e.g a button says "calculate the distance between stars")
5). I should be able discover an information status widget that tells me useful information about what is going and what the program is doing.
7). I should be able to use a help function to determine how the interface works.
8). I should be able to determine how the interface works via trial and error (aka discoverability)
9). Tool tips should everywhere guiding me through(applicable to GUI interface that use a mouse)
Even if I knew diddly squat about Astronomy, that doesn't mean I should completely lost infront of an astronomy software. If the interface was designed for anyone to use, I wouldn't be lost. In fact, I might even learn a few things about astrononmy via the software, if it is designed with optimal usability in mind.
Games are also like that. Good games are ones that anyone can figure out. So designing for anyone is certainly possible.
About static linking: it's not the entire library which goes into the binary, only the parts which are actually called by the program. And that's ususally only a fraction of the library's size. So the memory overhead is not that big (except for some huge frameworks like e.g. Gnome or KDE). Modern desktop systems have memory to waste, anyway.
Also, the startup time of the program improves, as it doesn't have to invoke ldd to gather its dynamically-loaded libraries each time. This is certainly a benefit for programs that are invoked continuously, e.g. gcc in a make process.
"Conculsion"
Proper spelling avoids confusion in the brain and prevents time being wasted by re-constructing the proper word or sentence.
Sorry, could not resist myself
lumburgh has managed to derail a real good discussion into a flamefest. i dont think i have seen a troll able to do that so consistantly, if there were a prize for being the biggest waste of time to the most people, it would definately go to you lumburgh.
congratulations.
when you do anything, you have only one focus of attention. a good gui is designed to keep that focus on whatever you are actually working on, and allow for automatic behaviors for anything not related to that. disruption of that focus is what seperates a usable product from an unusable product, users will not fully understand the reasons, but a product that requires your active focus to operate will be more difficult and frustrating to use. invisible application modes are probably the most efficient way to accomplish this, which is why that white "INSERT" in vim is such a colossal improvement over vi. the edit/command mode switch is still phenomenally error prone, but at least making it visible makes it leaps and bounds better. what would make it better still is elimination of the mode itself, or figure some way to establish a quasi-mode while retaining the power of vim.
regardless, any interface which has an inconsistant interface will result in more errors, which results in the shifting of your focus on to the interface rather then your work, which results in a frustrating experience and loss in productivity. a former vim zealot posted earlier about this, and how cursing over frequent errors becomes habitual for the vim user.
the only type of person who would find something like vim even remotely acceptable is a geek. geeks love learning complex systems, even when they become less efficient in doing so. why do you think the pc guys laughed at macs back in the 80s? it wasnt complex, required no maintenance, and you could accomplish virtually anything in a fraction of the time. but thats so BORING. if it easy, it cant be powerful, and therefor inferior. this is the geek mentality. couple that with the standard belief that your perception of your efficiency is even close to reality, and vim users can be explained.
when i fire up any text editor other then an ide, it will be for simple text editing. any editor that requires more then five minutes to learn is needlessly complex for someone in my situation. i would like to hear, especially from lumburgh, why you need something so complex. if i need to crop an image, i most definately will not be launching photoshop, and if i need to change a line in a text file, i wont use vim.
... when you don't split up articles only to pester users with more ads.
I'm a long time Vi(m) user. I recently tried switching to joe, an editor which you (mattb) would probably classify as more usable. But I was just constantly typing vi commands in joe. They're simply in my fingers. Usability is in habit, and in nothing else. When I am doing anything more complex than simply typing text (like copy/pasting), I am MUCH quicker with Vim, just because I know it so well.
I can image that if I learned joe as my first text editor, I'd hate Vim for the very same reason as I disklike joe right now.
I'm a long time Vi(m) user. I recently tried switching to joe, an editor which you (mattb) would probably classify as more usable. But I was just constantly typing vi commands in joe. They're simply in my fingers. Usability is in habit, and in nothing else. When I am doing anything more complex than simply typing text (like copy/pasting), I am MUCH quicker with Vim, just because I know it so well.
I can image that if I learned joe as my first text editor, I'd hate Vim for the very same reason as I disklike joe right now.
im fairly competant with CDRoast too. just because i know it, doesnt make it more usable then k3b, which i have used about twice in my life.
when you learn an interface, you will develop all sorts of automatic behaviors for it. you will develop the same behaviors in joe eventually, and when you have aquired a similar level of compitance with your new editor, you will find it easier, and more productive then vim. until then, it will be a foreign land where nothing does what it should. this isnt usability, its the subjective perception of usability, which is exactly the reason design cannot be done from a "common sense" point of view. my favorite color is probably a dark shade of green, however when i painted my house it was in white or offwhite with a hint of yellow. even though i like dark green, that color would make the room seem half the size to anyone who entered it. that is subjective perception vs psychological principal.
Usability is making an object easy to use and understand. You are making the subject needlessly complex. Software usability is equally similar. Making software easy to use and understand.
That comes second. Usability is about helping a specific type of user accomplish a specific task. "Easy to use and understand" come out of that.
VIM's interface is not easy to use and understand.
And here I think we are at loggerheads on what is meant by "easy to use" still. There are dozens of things that I find quite easy to use that required quite a bit of skill and learning: pencils, cars, and shoelaces come to mind. Too much of this debate has been focused on vim as an application rather than vim as an example of a group of interfaces that allow people to get things done quickly, but are not necessarily easy to learn.
Editors are general purpose applications in any operating system environment. General purpose in the sense that anyone should be able to use a text editor to edit textual information. Or, at least, this is my assumption.
Again, you have that infamous anyone pop up. Rule one of designing for usability: know your users. A program that will be great for one class of users might be completely unusable for another class of users. So the first thing you do is understand your target audience.
For general purpose software, like a silly editor, why does one need to spend weeks learning how to edit files?
For something like Microsoft Word, I wish that most of my collaborators had spent a few weeks in a class learning how to format documents? Why? Because Microsoft Word offers quite a few capabilities for doing things the wrong way, ending up with wasting my time unraveling a mess of conflicting embedded styles and formatting directives.
Why should one go to diver's school to drive a car? vim is much easier to learn than driving a car (15 minutes vs. 5 weeks). And I would argue that GEdit is only usable because you spent 15 minutes sometime in the past learning the pull-down menu paradigm which cannot be called intuitive either. (And unusable once you start needing as routine any of the features that I listed that it lacks.)
Special purpose software is a little different. For special purpose software, your audience is usually targetted.
Your audience is ALWAYS targeted. The simple fact that you are writing a comptuer interface rather than a door means that you are desinging for someone as opposed to anyone.
If I'm a database specialist, the interface of a database program should just make sense just by looking at it, at least in a utopian world.
Well, here is another issue. Visual interfaces are great until you reach a certain level of complexity. After you've gone beyond the point where you can point and grunt or drag and drop, I think it's time to really start considering thinking in complete sentences and shift to a linguistic interface.
For a general purpose application, VIM is lousy with regards to usability. I mean, the first time I sat before VIM, which the first time I used linux, I had a cerebral panic.
There is no debate that vim has bad learnability. The key debate here is whether learnability and usability should be equated with each other.
Gedit does those everything you listed.
Actually it does not. Regular expressions are not supported and google revealed no plans for supporting them. Some of the functions are supported through plug-ins that are turned off by default. (Had to read the manual to find that.) According to the wiki plugin support is problematic because many of the plugins are of "dubious usability."
So exactly why should I use a program that lacks some of the features I use every day, and diables some of the features I use every day by default?
regardless, any interface which has an inconsistant interface will result in more errors, which results in the shifting of your focus on to the interface rather then your work, which results in a frustrating experience and loss in productivity. a former vim zealot posted earlier about this, and how cursing over frequent errors becomes habitual for the vim user.
You see. I have this experience every time I have to draw my focus away from what I'm doing to a pull-down menu bar. Especially for those "once a day" or "once a session" functions that frequently don't have a mnemonic key sequence. So for example, while I'm reasonably certain that "Save as..." is going to be in the "File" menu, I'll have no idea how far down in the menu it might be, or whether that is in fact the function I need. (Sometimes you need "Export...".) Is spell-check in "Edit" or "Tools" for this application? Or for that matter, preferences can be either in "Edit" or "Tools" for the same application on two different platforms! History in Firefox is another one of those things that I just seem to have trouble finding on a regular basis.
I've done enough usability testing to know that the semiotics of pull-down menus are a bit more complex than has been stated here, and that pull-down menus force users to linearly search through a foreign taxonomy, and that many users find this frustrating.
Of course, we are all just pissing in the wind without data and swapping anecdotes. My anecdotal experience is that mode errors cause me relatively little frustration (they are infrequent and easy to fix), while finding a function through taxonomies of menu systems cause me much frustration.
when i fire up any text editor other then an ide, it will be for simple text editing. any editor that requires more then five minutes to learn is needlessly complex for someone in my situation. i would like to hear, especially from lumburgh, why you need something so complex. if i need to crop an image, i most definately will not be launching photoshop, and if i need to change a line in a text file, i wont use vim.
Well, I agree. I wouldn't recommend learning vim to change a line in a text file. I also wouldn't recomend learning LaTeX or Framemaker to write a letter to grandma, R to balance a checkbook, perl to calculate sales tax, Premire to edit home movies, or Blender to doodle a cartoon.
For me however, vim is great for working and editing large texts. Visual mode with the keyboard is IME quicker and less error prone than selection of text with the mouse. /subsubsection.*Structural gets me to where I need to edit quicker than [Ctrl-f] Structural [Enter] [Ctrl-g][Ctrl-g][Ctrl-g]. It's not that I have not tried or am not familiar with other text editors. What I found was that vim after a very short learning period, was more efficient for the editing I needed to do than WinEDT or Notepad.
my favorite color is probably a dark shade of green, however when i painted my house it was in white or offwhite with a hint of yellow. even though i like dark green, that color would make the room seem half the size to anyone who entered it. that is subjective perception vs psychological principal.
And I would argue that subjective experience should be a critical part of any usability test.
Great point who need 50windowsmanagers? There are several apps. that do the same thing, I know linux is about choice, but this is overkill. I agree with the pakage mangment part also. Really OS X is a great example to look at.
in a perfect world one would not need any window manager, you would just fire up a app and if it needed a gui it would point itself to a subsystem that handled gui apps. in fact with the right setup you could build a "desktop" based on a combo of gui apps started by a script.
and if you want a linux dsitro without a package manager? check out gobolinux, there you just drop the app into a folder based on its name and a subfolder based on version. they only maintain a set of symbolic links for backwards compatiblity for apps that may need a total rewrite to support their internal structure. most user apps will in fact work after a basic folder drag&drop job as the location they are dropped in is allready set in bashrc and similar.
we are getting closer and closer to agreeing ;-)
one of the problem with the whole pulldown menu loving amoung prominant usability guys is that most of them have worked at apple at one point or another, and there are a great many things that make apple menus more usable (the position is alwas the same, the structure is designed by the HIG, and more importantly followed by third party developers, targetting time and difficulty is reduced by leveraging fittes law, etc). none of these are really used on other systems, so naturally menus wont be as attractive.
the goal is leveraging spatial memory for infrequently used tasks. "an option near the top of the third menu" is much easier to remember then ":ldskfjkd", and you will be far less error prone while using it.
also, using a graphical input device like a mouse is using a different part of your brain then the one that is used while entering text commands, or mentally working out a problem. there were tests that bruce tognazzi did at apple, where he was basically trying to defend keyboard cursor manipulation against arguments that the mouse is less complicated. the argument he was planning on making was that keyboard navigation is simply more efficient, and he purposefully skewed the test to make his point. his tests were along the lines of "select the second l in the third sentance, copy it, select the fourth i from the last sentance and paste.". it turns out that mouse selection was significantly more efficient then keyboard selection, AND to a man, users will report the exact opposit. turns out that there is perceptual time distortion when using keyboard commands, your brain is more active and you are less conscious of the time that passes, where as with a mouse, instead of thinking of what key to press next, you will be both processing your next task and performing the current operation in tandem. your brain will be less active, and perceive time to be longer then it is. (the article is on asktog.com somewhere, after he put it up he got all kinds of email saying that the experienced typist is faster with keyboard commands. he basically said that he has done extensive testing on the subject, and unless anyone came to him with hard evidence (aka use a stopwatch), he was going to ignore all future mail on the subject)
taking subjective user preference into consideration is important. but putting pleasing your customers over reducing the quality of the product means that you are abdicating your responsability as a developer. any interior decorator who let me paint a room dark green would be doing the same thing, as would any archetecht who encourages monolithic design because a manager thinks there are too many source files (no joke, ive seen it happen). if you are working with people who do not have the nessicary background to understand the implecations of their desires, its your job to fight it.
they are two seperate things. if i would design something for a programmer, then i would do things like give more burdens on memory in exchange for more flexibility. that means i wont be as much of a nazi on things like having over crowded menus or toolbars. that doesnt mean that i will allow the minimize/maximize/close buttons to be re-arranged, or have a modal dialogue pop up saying "Document has been saved successfully" after every save. if i were to design for a child, i would put greater emphasis on keeping the memory burden low (keeping menus and toolbars to a minimum), and put a very large emphasis on consistancy (there should be very, very few configuration options on an app targeted at a five year old). another example would be designing for the physically handicapped, you would want to do things like eliminate timing or anything that requires some dexteriety to use from operations (i.e. no things like double click), and strongly recommend things like magnification and text to speach functionality.
but who do you design a browser for? or email program? or im client? none of these have particularily complex functionality, so it is feasable to design so that it will be quite usable to the vast majority of users. saying one program for each class of users will for the most part cause more harm then good. a child using a "kiddie" browser would lose the substancial benefit of alot of use when he switched to something more fully featured as he grows up. on the other hand, if he could use a small subset of those features almost as effectively as the kiddie browser, it will be a natural progression from novice to expert.
specialized designs most definately have their place, but for the most part designing for the human will be more effective, at least in the long run.
The goal is leveraging spatial memory for infrequently used tasks. "an option near the top of the third menu" is much easier to remember then ":ldskfjkd", and you will be far less error prone while using it.
Some honest comparisons would help this coversation along. I'm looking at my menu options and seeing very little that would not be expressed in one or two characters. Is there a menu item that encompases a function that requires a 9 letter keyboard sequence in vim? In addition, I'm still prfoundly skeptical that the gains from leveraging spacial memory are that different from the gains from using language memory. If I have to read the menu items to find what I'm looking for rather that use the hot-key sequence, I've been pulled out of my task.
In regards to mouse vs. cursor travel, I'd like to point to one important caveat in that document:
<blockquote>On the other hand, Peter, I have seen some mouse implementations that were slow enough that cursor keys might very well outperform them. I’m particularly suspicious of a "cursor that obscures half of what you're trying to select." I also assume you implemented a cursor scheme that would enable you to travel by word-at-a-time and sentence-at-a-time. Such schemes will increase the speed of cursor travel, although the decision-making necessary to select the most effective key combination can increase the mental burden—and time—even more.</blockquote>
Which pretty much gets to the core of what I see as a factor in the mouse selection problem:
1: Mouse selection in many programs attempts to "anticipate" what you really mean when you select a block of text. With results that are only half the time what I want.
2: Many pointers suck, obscuring parts of the text or offering poor precision.
3: Quite a bit of mouse hardware sucks, especially on laptops.
So I have some questions about the methods used in this study. It seems to be stacking an ideal mouse implemenation, vs. a less than ideal pattern of keyboard use, for an unrealistic task could be solved in 5 seconds by a skilled editor.
but who do you design a browser for? or email program? or im client? none of these have particularily complex functionality, so it is feasable to design so that it will be quite usable to the vast majority of users.
Again. It depends. The email program I used when I was answering 100 tech support messages a day is different from the email program I use now. The tech support center had a demand to track each piece of incoming and outgoing mail including my my comments on the interaction, and macros to automatically include text from our knowledge base.
Likewise, I have colleagues who organize learning sessions by chat, placing higher demands on their im clients.
specialized designs most definately have their place,
Well, that's a start. A shame that it only took 80 messages to get to a point where you agree with the core of this debate. Specialized designs have their place.
That is what this entire argument is about. Specialized designs have a place, and we should not expect a design that works well for a specialized audience, to work well for the impossible-to-exist human.
... but for the most part designing for the human will be more effective, at least in the long run.
The big problem is, who is this archetypical "human?" As a designer, I've never seen, met, or worked with a "human." I've never seen that "human" described in the serious usability literature. And I strongly suspect that a "human" tabula rasa in the terms you describe it, does not exist.
So I have some questions about the methods used in this study. It seems to be stacking an ideal mouse implemenation, vs. a less than ideal pattern of keyboard use, for an unrealistic task could be solved in 5 seconds by a skilled editor.
i would agree with that to a point. i dont think things are quite as stacked as you imply. also, characters like "|" were used, literally a one pixel wide selection, which is especially difficult to perform with a mouse. but his results were quite dramatic, like the mouse being twice as fast if i remember right. maybe its not quite that high, but its probably still significantly faster. i believe raskins LEAP system offers a far better navigation/selection than any current methodology (to try it out, download the cvs version of archy from www.raskincenter.org, its quite cool), and that is keyboard only. so i do think there is potential for keyboard based interfaces to be more efficient, but it would be quite alien to most users, and would be hard to get adopted as standard.
The big problem is, who is this archetypical "human?" As a designer, I've never seen, met, or worked with a "human." I've never seen that "human" described in the serious usability literature. And I strongly suspect that a "human" tabula rasa in the terms you describe it, does not exist.
you are real close to where im comming from, but not quite. im saying that you should alwas be designing around the way the mind works. if you are developing an app that will have a specialized user base, you should still be using the same principals, just adjusted to take into account the additional complexity that would require a specialized program (or significantly different in the case of programs for the handicaped or children). ive used alot of java ides, and idea is the only one ive seen so far that has really gone all out on the usability principals. because of that, its quite a joy to use. our entire team loves it, and says it is the best ide they have ever used. before idea, we used jdeveloper at the office, and the user experience was quite a bit worse. that being said, even though it does a remarkable job of helping a complex process, it still requires more effort to use then say, gedit. considering how much easier it makes coding, the tradeoffs are worth it,
emailing isnt an insanely complex process, so those tradeoffs are no longer worth it. i use outlook at work, i would never consider it in a million years for home. more functionality, resulting in a less usable interface, but not unacceptable considering how easy it makes life.
you are real close to where im comming from, but not quite. im saying that you should alwas be designing around the way the mind works.
The question is, "whose mind?" Of course cognitive psychology should be a big player in regards to design. That has never been called into question. My postion in approaching these issues from a research/design view in psychology:
1: current approaches to "usability" have poor construct validity because they mix up "time to use" and "time to learn." A saxophone for example is an interface that is highly optimized for use, but not well optimized to learn.
2: there are no simple design paradigms that work for all tasks, all humans, and all domains.
3: talking about designing for a "human" rather than designing for a specfic population is dangerous because it hides critical assumptions that include some humans and exclude others.
Since gedit comes up over and over again, I'll use that as an example. Gedit makes a large number of assumptions about its user base:
they can use a computer input device.
they can see
they are literate (4th grade level?)
they are literate in a language in which text is displayed from left to right.
they have a familarity with the concept of files and search in the context of computer-generated text.
they don't need much in the way of text formatting features or spell-check
This is only scratching the surface.
"While aiming at simplicity and ease of use, gedit is a powerful general purpose text editor.
Currently it features:
* Full support for internationalized text (UTF-8)
* Configurable syntax highlighting for various languages (C, C++, Java, HTML, XML, Python, Perl, etc.)
* Undo/Redo, with configurable levels
* Loading files from remote locations
* File reverting
* Print and print preview support
* Clipboard support (cut/copy/paste)
* Search and replace
* Go to specific line
* Auto indentation
* Text wrapping
* Line numbers
* Right margin
* Current line highlighting
* Bracket matching
* Backup files
* Configurable fonts and colors
* A complete online user manual"
http://www.gnome.org/projects/gedit/
Gedit's search function supports regular expression. And unlike VIM, activating Gedit's plug-ins is a matter of selecting check boxes. VIM is neither easier to use nor learn as compared to Gedit, period.
You say you have conducted usability studies. Well lets conduct one together. Put seven random users before Gedit and another seven before VIM. Given them a 30 minute tutorial. Assign them generic tasks. Measure how long it takes them to get acquainted with either interfaces. Measure how long it takes them to get the task assigned accomplished. Collect feedback.
I just conducted this same test, a lot more detailed, on members off my household. None of them found VIM easy to use, easy to understand nor easy to learn! Most members of my household are very learned and have vast computer experiences. They have all used relatively complex software. Yet, none of them found VIM usable at all. I didn't even need to teach them to use Gedit. It's interface is discoverable.
We will continue to disagree because our fundamental understanding of usability is different. I believe usability is about making objects easier to use, period. You believe usability is about making objects easy to use only for a certain group of people. So by your definition VIM is usable, because only a certain group of people can weild it proficiently and effectively. By my definition, it isn't for the same reasons and many more. I've listed the high learning curve, the absurd amount of time it takes to become proficient, it's obscure discoverability, it's inability to scale well with more than a few documents (usage wise), to mention a few.
Your peeve against Gedit is that it doesn't support regular expressions, which I think is false. You also mentioned Gedit doesn't support many functions you use in VIM, which again were false. However, none of your grievances had anything to do with usability, ease of use and understanding. VIM has serious usability flaws, and so do 90% of applications and objects I use, including Gedit.
Your rebuttal is going be that VIM is targeted at touch typists, geeks and programmers. I'm not buying that either because Gedit is also programmers editor. Yet, geeks, non-touch typists, touch typists, mama, papa, aunt Sue, uncle Joe, me, you and anyone can use it.
I think software is written to solve problems. As a coder, I look at things from a problems perspective most often. I believe most programmers do. When I write software, I don't look at it from how a particular group of users can use it to solve problems, rather, I look at it from how anyone can use the software to solve problems.
The users are not the problem. The problem is the problem. The software, I believe, exist to make users solve complex problems. It doesn't exist to make only skilled users solve complex problem. Computers and software exist to empower users. To make them accomplish things they would never have accomplished without a computer.
My mother is not an accountant. Annually, she needs to balancer her taxes. She has several options. She could hire an accountant to do it for her. She could learn how to do it herself. She could purchase a software, that acts like an accountant, to do it for her.
Her decision was to purchase the software. If the software expects you to be an accountant to use it, it is broken! Software and software designers need to stop making nasty assumptions, and that is much of th problem with VIM. Thankfully, the people who designed the tax software designed for anyone to use. She launches the software it guides her through all what she needs to do, as if it were an accountant. She hits the finish button and voila, her taxes are done!
That's how software should work and that is designing with usability in mind. Software empowered her to solve a problem without fuss. That's the ultimate goal of software usability. We, geeks, prefer to argue about trivialities such menu placement, widget choice, programming languages, touch typing, features, power, CLI, GUI, LUI etc. My mother, she doesn't give a damn! Why should she?
You also have specialized software. Specialized software is software only people in a particular field of knowledge or specialty. I argue that even those should be easy to use by anyone, not just the specialists. The specialists due to his wealth of knowledge regarding the subject matter will be able to accomplish a lot more and wield the software with prowess and power,.but my mother should equally be able to do something with the software even though she knows nothing about the field. The fact that the software is specialized is irrelevant. The fact that anyone can use the software is what matters. What the software does is irrelevant. How hard it is for people, humans, to use the software is what matters.
That's why people are loosing it over Apple and Macintosh technology today. Grandma overnight can make movies, author DVDs, manipulate images and she says it's easy. That's what software should be about. That's what I think usability is encouraging. And that's why I disagree with many so cold usability experts who get buried in the details and fail to see the big picture. Once again, usability is making objects easy to use and understand. VIM fails in this regard.
I understand that he appreciates good documentation, but isn't this carrying it a little too far?
What is your major malfunction? You're so worked up in this vim troll that you're now posting over at the Gnome thread - offtopic.
Seriously, get your head checked by a professional if you think that Vim is supposed to be dumbed-down so your grandma can use it. It never will be.
There is no vim problem. Only the problem in your head that assumes that vim should be designed for your grandma. Go use gedit, because people that use vim don't care that you think it should be like gedit.
You are completely incapable of designing anything for anybody with these ridiculous arguments that vim should appeal to everybody.
I never said VIM should appeal to everybody. And unlike you, I don't have a reputation for trolling.
Yeah, the rest of the nuts don't like it when they're smacked with the truth too.
> [...] Yet, none of them found VIM usable at all. I didn't
> even need to teach them to use Gedit. It's interface is
> discoverable.
Let me add that this is one of the most important points of usability for me (speaking of whether _I_ feel comfortable with the software, not about _others_). It's whether the software shows me my options.
I'll pick up the example of text editors. For me, GUI-based editors are simple to use. VIM is hard to use. On the other hand, joe is simple to use. joe's interface isn't that different from VIM, since typing ctrl-k-q isn't very different from typing :something. What makes joe different is the simple fact that it says "ctrl-k-h for help" without being asked for it, and within that help I can see in 10 seconds how to work with it. Similar for GUI-based editors: Just open the menus and look what's there. I did the same with VIM, and the results were quite different. Differences that slapped into my face (apart from a nasty keyboard localization bug that made navigation in the help screens difficult):
1. After closing the help screen, the information HOW to get help disappears. Even worse, there's not even information how to quit the editor at all.
2. The information how to navigate, especially to jump back, is only visible on the main screen, and not in the referenced screens where you would need it.
3. After entering "edit" mode, there was no visible information on how to exit it again.
4. The "overview of the most common commands (I) will use" is a whole screen full off references, each with a full screen of commands behind it. So just the "most common" commands, with which I'll start editing, number more than 200? I don't think so. Rather, these are much more than the common ones.
It always comes down to the same thing: I know what I want to do, but I don't know how to do it, and the program leaves me without *any* clues. In other cases it also happens that I'd like to know *if* I can do something at all. Complaint #4 is the reverse case: The program shows me my options, but they are so many that it's practically the same as not viewing at the help at all, unless I dig 10 minutes to get the information I could get in 10 seconds with a well-designed interace.
Note that the same problem - the lack of discoverability - as also my greatest problem with (bad) command line interfaces.
Your peeve against Gedit is that it doesn't support regular expressions, which I think is false. You also mentioned Gedit doesn't support many functions you use in VIM, which again were false. However, none of your grievances had anything to do with usability, ease of use and understanding. VIM has serious usability flaws, and so do 90% of applications and objects I use, including Gedit.
If a given piece of software does not support functions I need to use on a daily basis, then it is not usable for what I need?
If the functions are there, then where are they? I wouldn't mind trying out a new editor. But if the functions I need are not available through menu items, nonexistent or existent but hidden and undocumented, then that editor is not usable for my needs.
You also have specialized software. Specialized software is software only people in a particular field of knowledge or specialty. I argue that even those should be easy to use by anyone, not just the specialists. The specialists due to his wealth of knowledge regarding the subject matter will be able to accomplish a lot more and wield the software with prowess and power,.but my mother should equally be able to do something with the software even though she knows nothing about the field. The fact that the software is specialized is irrelevant. The fact that anyone can use the software is what matters. What the software does is irrelevant.
Lets take an example of a specialized software doman: statistical analysis. When I run an anova on a dataset, I'm interested in a set of numbers that are meaningful to me, but not meaninful to someone without a basic grasp of statistics.
In order for the software to be usable for anyone (never mind the fact that all you are doing when you say "anyone" is simply masking your own political assumptions about who the users are), I'd have to put in a whole series of caveats, interlocks, and explanatory text. I'd want to check to see of the data was reasonably normal before hand, explain in detail what an anova does and how to use it, and then explain with the output degrees of freedom, sum of squares, F, and p.
In designing for "anyone" you've made it more difficult for the people who need the software to get stuff done. I don't want software that forces me through a tutorial of picking a test for significance. What I is software that says "anova" and gives me df, SS, F and p.