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.
Whenever I read comments that suggest something of the above, It makes me believe that the author has only a very basic and incomplete idea of usability.
Unfortunately, it’s not that easy to explain the term usability. I’ll try anyway. I’d say that usability refers to whether a certain Product, software or not, enables a user to perform a certain more or less well defined task. It’s not that one single feature decides whether a product has “usability” or not. Usability is more about the overall feature set, appearance and above all, usefulness of the Product.
Throughout this article I’ll briefly explain common misconception that usually appears when the discussion turns towards usability, then I’ll try to identify some usability problems that might not be obvious to the average developer, and as a conclusion I’ll propose some suggestions that will hopefully overcome the shortcomings of today’s Software.
Common Misconceptions
UI:
The problem of “usability” should not be confused with “User Interface”, because there is a set of usability problems that can not be solved on the UI-Level, take for example network browsing (think of Apple’s Rendezvous). This has to be implemented on a rather low-level network basis. So this time we need a network engineer to solve a usability problem.
Novice Users:
Among the most common misconceptions is that usability engineering aims towards the novice user. Software with bad usability is actually more of a hindrance to advanced users, because while a new user can learn complex software, an advanced user will be saddled with broken usability for years, hindring their job. Certainly the advanced user might be able to master obscure, overly complex, ‘not self-explaining’ software. This may be true, but certainly he has more interesting ways of spending his weekends.
Front ends:
Another thing that pops up randomly as soon as the magic word usability flows around is: “Just add nice front end to cdrecord/cups whatever” (see ESR’s Cups Rant) Well, how good is a front end if the back end is broken? Let me give you an example: 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. Have you ever read the Samba Documentation on how to set up network-browsing in your Windows network? Don’t even try. The whole protocol seems to be so broken and overly complex that it can’t be fixed on the implementation level. I admit that some of these features might be necessary to run a network with a hundred machines attached. However I do not care, as it does not work for my environment therefore it’s broken. In contrast, have you ever used a Apple Rendezvous-based Network? Surprisingly, it works, it’s fast and it’s reliable. In conclusion, I think this proves my former statement: if the back-end is broken, the front-end won’t fix it.
Common Problems
Deployment:
Another non-UI Usability Problem is the issue of deployment. Think of “how good is program if you’re unable to install it on your machine?”
Under Linux, people tend to use a so-called package system that integrates a lot of different applications into the distribution. This is a really nice feature, however, people complain that it’s next to impossible to exchange packages between distributions, and therefore it’s difficult to install a piece of software and resolve dependencies if it’s not integrated by your distributor.
Actually there is a reason why these package systems exist, and why it’s a good idea for certain applications and why it’s not so good for others. For example, a typical server application like Apache needs to be integrated fairly deep into the OS. There might be cron jobs referring to the application, config files for logrotate have to be setup, init-scripts have to be added. This is a task that might be difficult for a generic installer, therefore it’s good idea and a usability improvement to handle this at the package-system level. Other Applications like Firefox or OpenOffice, on the other hand, are more or less independent from the underlying OS. Therefore Applications like these should, and some do, provide standalone installers.
Obscurity/Complexity
One thing that severely decreases usability on some occasions is unneeded complexity in a solution to a problem where a simpler solution would be possible. This is usually an issue that is invisible as long as everything works as intended. However, as soon as something is broken, it becomes apparent that it’s increasingly difficult to fix it, as the underlying system is too complex. 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.
Stability:
Release early, release often. This is a popular motto for Free Software Developers. However, I do not really like it because it encourages developers to mark unstable software as a release. There is one thing that I consider very, very poor usability, and that is crashy software. It’s about reliability. If a program behaves nicely, and doesn’t crash on my system, I start to trust this piece of software, and I like to trust my programs. I can then happily recommend this software to friends, and they will be happy too, hopefully.
But if you really want to get your cutting edge software out, I recommend to use CVS as some kind of secondary release mechanism. Encourage your most enthusiastic users to check out from CVS, and they’ll happily comply and compile, but without the presumption of stability.
File Formats, Config Files:
One thing that should be considered carefully is the file-format for application data. That includes both, configuration data and user data.
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. This case actually describes a bug, but the point I am trying to make is, make sure that your file formats and configuration data is at least forward compatible.
Documentation:
Some Words on Documentation: avoid lengthy complicated instructions. Nobody likes to read it. Provide simple examples and provide commented screenshots if the application includes a GUI.
If your software requires lengthy descriptions, rethink your front-end design. Where the front-end includes plain text configuration files and APIs (See Writing Small Software by Felix von Leitner) this of course depends on the type of application.
Possible Solutions
Static Linking:
One common complaint about Linux is that binary packages from one distribution are not compatible with other distributions, and there is a need to create a Technology to circumvent this problem. Well, a solution exists, it’s named “static linking”. For those unfamiliar with this term, it’s a means to include parts of an application normally distributed as shared libraries into the application executable. Some people dislike this solution because of the additional overhead if two programs statically link to the same library. However, there are cases where the tradeoff is insignificant compared to the advantages. With careful selection of libraries to compile into your binary and some serious testing of your binary packages, it is possible to create a program that works well on the vast majority of the standard Linux distributions.
Vendors of closed source software do this all the time, and it works surprisingly well. The only thing that’s missing in the Open Source World is an awareness of the importance of high quality binary packages.
Testing:
Test your Program on different Machines, Distributions, test whether they import old File formats, whether the preferences file from the previous version screws it up.
Test your binaries, if you really can’t make them work on a specific Distribution, provide a note on your Download Page.
Website:
Keep your Website up to date. If you’re too lazy, provide yourself with an easy to use web-based tool to manage your project homepage. I’d recommend a wiki based System for this, for example PmWiki. Make sure that you provide a decent selection of screenshots at every new release, I love screenshots, and so do a lot of other people I suppose.
Free Software Advantages:
There are of course areas where Free and Open Source Software provides a better usability then others. One such example Is that most applications are available for multiple platforms. I appreciate it actually very much to have all my commonly used applications ready whenever I have to work on a win32-based machine. I recommend everybody to recognize this as a key-superiority of Free Software and encourage everyone to provide win32 binaries of your applications.
Conculsion
Why should you care about Usability? Because it improves the quality of the product. If you do not care for quality, maybe you should ask yourself why do you actually publish software. A severe usability problem should be rated as important as for example a memory-leek in your program, it’s a simple “Must fix it”!
Some Links of possible Interest
HighQuality-Apps-HOWTO
Software-Release-Practice-HOWTO
About the Author:
Richard Spindler is a computer-science student, usability, security and free-software advocate. Homepage:http://ggseq.sourceforge.net/
If you would like to see your thoughts or experiences with technology published, please consider writing an article for OSNews.
There is still room for discussion, though. Consider your usability definition:
refers to whether a certain Product, software or not, enables a user to perform a certain more or less well defined task.
The single user has a variety of dimensions, among which is time. Graphically oriented systems get you in the door, but some users will graduate to keyboard shortcuts, and those annoying twits in the right tail of the distribution will want to put everything in macros.
I worry that “a user” might imply a static view of the user in question.
Best,
Chris
makes sense to me.
“I worry that “a user” might imply a static view of the user in question.”
I think that that issue is somewhat covered in the “Obscurity/Complexity” section of Richard’s article (or at least it’s somewhat implied there).
Open source in general suffers from usability problems, the applications are fragmented and developers should address this problem (that is THE reason i switched from linux to osx)
I believe this can only change if the attitude of the developers change, i want finished applications and limited choice. having more than 50 windowmanagers makes no sense at all.
Don’t get me wrong, i think open source it the way to go. Firefox is heading in the right direction. The find/search function of firefox is a really good example of good usability. I can search (and it search directly), and i can highlight the keyword. it’s even better than the safari search function
I agree with every word, and I hope the various developers will take the points of view mentioned into consideration.
Static linking has its uses, but trying to use it in order to make mandrake rpms work well on redhat is a bad solution. Take, for example, a complex application like Evolution. My installed version links directly to over 70 different libraries. Some of these may make sense to link statically when we’re distributing binaries – for example, gal is used only by evolution.
In these limited cases, static linking can give us a little extra portability. However, if we truly want the application to work anywhere, we need to link everything statically. This gets into a whole new realm of problems.
In the end, we’re really not going to gain much. Static linking may solve a few library dependency issues, but it can’t help at all when there’s integration with distribution-specific config files or layout. In many cases, the bugs that result from bad integration are much more frustrating than the fact that your suse doesn’t want to install a fedora rpm.
We also run into problems if a library has bugs. Bugs, as you said, are a significant hinderance to usability. Let’s assume that distro X chooses to statically link the mozilla libraries, because there’s so much variation that it makes portability hard. If a security bug is found in one of those libraries, not only do we have to rebuild all those packages, but what happens when a user finds an old package in some index somewhere and decides to try to install it?
Static linking is not a silver bullet. zlib, anyone?
while i agree with the majority of what was said, i disagree slightly with the authors definition
usability is the science of how usable an interface is. it is as strongly tied to cognitive psychology as it is to engineering. themes CAN be a usability issue, but only in the case of say, dark red text on a black background. (of course, if you subscribe to the jef raskin school of design, preferences in general are something to be avoided whenever possible).
i think the biggest misconception about design is it is some sort of subjective art form. it really isnt, good interface design benefits all humans, as it is based on the way the human mind thinks. if you happen to have learned the system already, that doesnt make it better then something that requires your brain to jump through less hoops to accomplish the same task. what it does require is for you to establish new habits for using the system, and that will make you feel “uncomfortable” or “out of place”(that is also the reason that consistancy is the sacred cow of HCI). once again, this has nothing to do with how usable something is, it has to do with your brain adjusting to a new system where none of the previously established behaviors work anymore.
as for the whole back end stuff the article mentioned, an interface that doesnt do anything is pointless. good design alwas starts with the interface being based on the functional requirements, which will then influence the technical requirements. so something like apt could be considered part of the usability of the system, if the functional requirement was the ability to install software, and through the design phase it was decided to do online repository style.
There are, indeed, a lot of misconceptions about usability out there, and I applaud the author for providing a nice overview of such an important subject. A few additional points that I hope will be useful:
– Usability engineering begins even before we design the product to perform the task. We can start by saying, who is the user? What are his skills and expectations? What task, precisely, does he need to do? Thus in the best case, usability guides the most basic aspects of the product design.
– What makes a product usable varies from product to product: Different users have different needs, and the same task might require a different implementation and/or user interface for different users.
– There are empirical methods (most notably, usability testing) for determining how usable a product is. I have been periodically dismayed to see heated discussions, particularly in the open source community, about the usability of a particular tool, with once side insisting users think a certain way and another side insisting the opposite. Sure, we need to make educated guesses sometimes. But there are good methods for getting real, factual data on usability and resolving these questions.
Anyway, thanks again.
>> refers to whether a certain Product, software or not, enables a user to perform a certain more or less well defined task.
>>
I disagree. Useability is not about whether a product an peform a task or not. It is about HOW EASY it enables the user to perform that task. There are many ways to kill a rat, but some are more efficient, aka useable, than others. For every job, there is a good tool, a not so good tool, and a bad tool. You can use a piece of wood to hammer in a nail, but you are much better off using a hammer. You get my drift? An OS or program is a tool. It is more useable if it is easier to use, and less so the more difficult it is to use. That’s why “click on setup.exe” is generally a more useable procedure than “Edit Makefile && ./configure && make && make install”.
Verdict on this article: Conclusions reasonable (mostly common sense, SMB is a spectacular example of Micrisloppieness for example) but some of the recommendations are flawed, like custom installer programs.
And I agree about the Obscurity/Complexity points, especially with the directions GNOME and KDE (most notably the tendency to start hiding things and adding layer upon layer of abstractions) are taking to turn Linux into another Windows XP.
But STATIC LINKNIG?!?!?! No the advantages can be had with out the serous disadvantages of run away blote and great difficulty plugging security holes in libraries. Please do some research, some REAL INNOVATION is being done in this area. See http://zero-install.sourceforge.net/ and http://autopackage.org/.
And I agree that some OSS projects could use improved QA, for that matter so could the leading proprietary software companies. Many OSS projects maintain a rapidly developed branch and a stable, often near effortless to install and use branch. I think the Sylpheed, Sylpheed-Claws project is a perfect example of how to do it.
And I also agree that proper use of forums/Wiki to cooperatively create and maintain the documentation is important.
In conclusion I defiantly agree that usability issues are something that everyone working on a project, even the entire collective of OSS needs to take responsibility for.
Separate installer programs for each application is definitely not the way to go. That creates issues with individual application developers providing buggy, incomplete installers that don’t do the right thing. For instance, on Windows there are many uninstallers that don’t remove the entire program. Also, one installer won’t work for all distributions. Different distributions handle file placement in different ways. This is why the current methods of program distribution work. Someone who knows the ins and outs of a specific distro takes the source and makes it into an appropriate package. You can’t depend on every application developer to know how to make packages for each distro and to spend the time doing so. For commercial applications it makes sense, but when the source is available, the community can pick up the slack. Package management systems are necessary for the open source world because we all share libraries between programs. Dependency checking is necessary for this to work, and I think package management systems are the most elegant way to do this. This relates to your point about static linking, which I also disagree with based on arguments that have already been discussed here.
I agree with your stability issue, but I don’t agree with the solution. Releasing less often means less testing gets done. Many people aren’t willing (or don’t know how) to compile programs from CVS. By actually making a release and people making packages for it, more people get it. Instead, developers should create stable and unstable branches, so users know when to expect bugs and when not to. Intrepid users will still use the development versions and provide the valuable feedback necessary to keep the stable versions bug-free.
It’s a well written article. Usability does not just apply to graphic user interfaces. It applies to all interfaces. What is an interface? An interface is a way to communicate with an object. The object could be anything.
An article that nobody understands is bad usability. An application programming interface that takes 4 years to master is bad usability. An electronic appliance that makes you curse incessantly is bad usability.
Usability means making things easier and efficient for people to use and understand. You don’t need to be a usability expert to apply usability principles. 90% of usability is common sense and consideration for your users. Apparently, common sense is not common. OSnews’ comment editor is an example of bad usability, but I digress.
Once again, it is an elegant and well written article.
when your target audience has a diverse setup.
one example is QT programs. you really think that a developer should expect tat a user of a QT program should have QT installed all the time? not just LDE here, but the general widget set.
when you are going for platform independence, you need a statically linked binary.
Decent article, but it didn’t really answer any questions concretely.
First of all, it’s been mentioned before, but static linking is NOT the answer. Yes, you should avoid linking to a million and one different libraries, keep it sane, but if a library is probably used by more than one application on the system, it should be shared.
Remember the security holes in libpng on windows? (or was it in GDI+ somewhere, doesn’t matter). Hundreds of applications had to be updated to fix just that issue. On Linux, I downloaded the updated libpng and all my apps automatically used the new, fixed version.
Secondly, and I bring this up every time, is that what is usable for one user may not work for another. The statement
that usability is defined by allowing a user to easily perform some task is nice, but ignores how many different users there are.
You say, even advanced users have better things to do than learn unintuitive interfaces when they could just use discoverable ones. This is only true if the interfaces are equally productive. I have spent time learning many features that are not intuitive to a new user, yet make me much more productive.
Now I think that an intuitive interface and an advanced one are not mutually exclusive, it just hasn’t been successfully done yet. The MacOS X GUI is discoverable, but lacks many advanced features that I want. KDE is cluttered and complex to a new user, but has all the features that make me more productive, so I use it.
Usability means making things easier and efficient for people to use and understand. You don’t need to be a usability expert to apply usability principles. 90% of usability is common sense and consideration for your users. Apparently, common sense is not common. OSnews’ comment editor is an example of bad usability, but I digress.
totally and completely wrong, but a very popular misconception. 90% of usability is understanding how the mind works when operating your interface. if you dont understand that, you will be walking blindfolded through a minefield. there are a great many things that are not common sense. for example, modal dialgues are plain evil. modal anything is evil. dialogues with only one choice are evil. dialogues asking for confirmation using a stock message and stock buttons are completely and totally pointless to the experienced user. the human mind can only actively focus on one thing at a time. task flow should alwas go noun-verb rather then verb-noun. preferences and customization are a sign of bad design.
do i need to go on? none of those are common sense, most of those fly in the face of common sense. joe coder wouldnt know that unless he has an interest in the subject.
yes let’s have all static linked programs of 20Mb with all their own version of the dependencies…talk about bloatware!
That does not mean static linking is not usefull sometimes.
> it’s not about having all application share the same looks
Actualy, this is prety much 50% of usability.
Consistency.
Statically linking packages is broken by design. Apart from the fact that is makes your application needlessly bloated, it’s security ramifications are disastrous. What does a user do if a few of the libraries a statically linked application depends on are known to have security and design bugs? The response is nothing. The user lives with it, or waits for a developer to statically repackage the application with the necessary fixes.
Not only does that increase the work load of the developer, users of the application suffer especially if there a fixes available for bugs in libraries but not the application.
static linking makes for overly large applications BAD if you want a small install.
separate installers for programs. what if I want to upgrade my entire computer? how usable is opening 50 installers?
I agree with linux_baby Usability is about HOW easy a program is. you can have a program and it’ll do everything you’ve ever wanted it to do.. but if I can’t understand it what good is it?
portage in gentoo comes to mind on this. It can do _EVERYTHING_ or so it seems.. but it’s taken me 2 years of using it to understand how to do all the cool fun stuff. I’m still no whiz at it but I like it none-the-less.
When I think of usability nightmare I think of Kaffeine 0.5
why? pause/play’s keyboard shortcut is now separate keys??
No skipping ahead shortcut. when the author made this new version he wasn’t going forward in features and usability he went backwards!
You say that you should test your programs. that’s the reason for the “release early release often.” this is so that programs can get a lot of testing and development can move forward quickly.
releasing not very often doesn’t get programs tested that often. Take for example the linux kernel. Linus was complaining about how no one tested the unstable branch so they tried to make testing releases more frequently. this got A LOT of testing done.. until people knew it wasn’t considered “stable” I personally think the kernel’s development moved quicker than even the jump from 2.4 to 2.6
“Take, for example, Firefox. I installed the 1.0 Version, imported my Preferences from Mozilla, and after some days, I became aware that some sites were subtly broken. I did some research on the Net and found out that I had to delete my .mozilla file to fix Firefox, because the old preferences file was screwing up something. That’s poor usability too.”
No I’d concider that a bug.
If you want to understand usability look at the word .. and make it usable.
Secondly, and I bring this up every time, is that what is usable for one user may not work for another. The statement
that usability is defined by allowing a user to easily perform some task is nice, but ignores how many different users there are.
You say, even advanced users have better things to do than learn unintuitive interfaces when they could just use discoverable ones. This is only true if the interfaces are equally productive. I have spent time learning many features that are not intuitive to a new user, yet make me much more productive.
sorry, but you are incorrect. good design is based around the human mind, and the way the mind works at a fundamental level is universal to everyone on the planet. if a well designed interface is not usable to you, that means you are an alien 😉
intuitive != usable. machines and humans dont work the same way, it requires training for humans to be able to use machines. now, you can design based on the task, or even worse based on the way the machine works, but doing so forces the user to jump through mental hoops to use your interface. basing an interface on the way the mind works will minimize that, reducing the amount of energy that the brain consumes (how usable an interface is can be judged by how much glucose is consumed while performing the task, however we cant accurately, cheaply, and safely measure that yet.).
there was an editorial here awhile back by a coder who hated all guis till she hit the mac. at one point she says that using windows actually leaves her feeling more exhausted. thats because it takes more energy to operate windows then it does mac (of course, that is an educated guess, but i would be quite suprised if i am wrong). i have had similar experiences, especially when using an unfamiliar or “clunky” design, by the end of the day i feel like i have run a marathon.
as for advanced/novice distinction, anything designed along those lines will once again be doomed to failure. there will be learning involved no matter how usable your interface is (note that intuitive is something completely different, and is more directly related to learning). while not forcing the user to learn every intrecacy of the entire app to perform even trivial tasks is a good thing, operating under the assumption that beginners need different things then experts is faulty. first of all, how will the beginner become an expert without the expert features? if the expert features are hidden, then using them frequently will be a problem. if the expert features are say, a toggleable toolbar, you will have thrown consistancy out the window and forced the user to develop a new set of behaviors, effectively making your new “expert” a novice again in this area. its far better to ignore the whole thing, and have things like visibility be determined by frequency of use rather then user level.
anyways, i apologize for the long rant, but i, like the author, get frustrated by the gross misunderstanding of the word, especially now that it has become trendy.
i hate it when geeks try to redefine words. here is the M-W unabridged:
Main Entry: us·able
Function: adjective
1 : capable of being used
2 : convenient and practicable for use
– us·abil·i·ty /”yü-z&-‘bi-l&-tE/ noun
this is the basic definition folks.
for example, modal dialgues are plain evil. modal anything is evil.
Not if they are informing/asking about something that is critical to you continuing to work in the application.
dialogues with only one choice are evil.
That would be a message box, not a dialogue, and they are very useful.
dialogues asking for confirmation using a stock message and stock buttons are completely and totally pointless to the experienced user.
Standard save dialogs are a bad idea? I think you’re cracked.
preferences and customization are a sign of bad design.
Wrong. Very very wrong. In any given complex software there is a very large set of preferences that cannot be removed no matter how much additional code you write to make it automatic. A simple one is: “Use left handed mouse button mappings”. There are millions more just like this.
do i need to go on? none of those are common sense, most of those fly in the face of common sense. joe coder wouldnt know that unless he has an interest in the subject.
Remind me not to use any of your software if you seriously believe in those rules.
just thought of an example that may be helpful (30 seconds after i hit submit, when will we get an edit button eugenia?)consider the IDE. it is downright impossible to make an intuitive ide. noone can just sit down and start coding, there is a great deal of learning involved. that being said, the one that i use (intellij idea) is both the most usable, and unintuitive application i use on a daily basis. i have developed automatic behaviors for countless small operations, at the same time after two years of daily usage i STILL discover new features, and STILL have to google for a good explination of what something does.
intuitive = obviously works a certain way (how to operate a button)
learnable = easy to learn. you can become a master in a short amount of time.
usable = minimal amount of mental cartwheels needed to operate.
You are the typical example of someone who thinks usability is all about graphic user interfaces and some obscure rules written in some books. Open your mind friend and read my comment again. This time, calmly.
Also, modal dialogues are not evil. There are situations where they are needed. Developers that abuse modal dialogues just don’t apply “common sense”. Are “goto” statements just plain evil too?
Usability is not about whether or not modal dialogues are evil. Can your subjects use or understand your work without having a cerebral panic? Without fiddling and fighting with your work? And most importantly, without cursing? If the response is yes, your work exhibits good usability.
In brief, you can apply usability principles to anything with an interface, not just the use, or abuse, of graphic widget sets.
That’s why “click on setup.exe” is generally a more useable procedure than “Edit Makefile && ./configure && make && make install”.
exactly. the average user just wants something that works and doesn’t give a crap about ad-hoc pseudo-scientific definitions of usability. let’s face it, linux is a pain in the ass whether one chooses KDE, Gnome, or whatever. the end user doesn’t want to hear off-topic stuff like “linux is a kernel, not an OS”, “KDE sucks, use <insert WM here>”, “RTFM!”, and so on.
linux will ultimately fail on the desktop if this inanity and obliviousness continues. (and i could care less since i like its exclusivity.) not that MS “oversimplification” and one-button mouses are much better.
as for advanced/novice distinction, anything designed along those lines will once again be doomed to failure
You misunderstand me. I didn’t mean we should design an application with an advanced and a simple mode, I mean, there are interfaces geared towards different users available right now. OS X and KDE were my examples.
its far better to ignore the whole thing, and have things like visibility be determined by frequency of use rather then user level.
Please never do that. The selective hiding of features in the menus of Microsoft Office is horrible for usability. The fact that menu items will dissapear just because I haven’t used them in a while is unbelievably dumb. It takes me twice as long to find anything in MS Office because half of the time its either hidden, or has changed location. It’s much better to display the whole menu, and users will eventually build muscle memory so they barely have to look at what they are clicking on.
separate installers for programs. what if I want to upgrade my entire computer? how usable is opening 50 installers?
We only need a standard way of defining an interface for an installer. Installers would provide a standard interface and register itself. Then the installation manager would execute each installer automatically.
Think about Windows. Every program can have its own installer, but most programs can be uninstalled by using the control panel. We just need a similar solution where there is also a standard way of calling the program. How the program works is unimportant as long as it supports a standard interface.
About bugs:
There are flexible installation makers on Windows (Wise, InstallShield, Nullsoft) etc. It’s not necessary to reinvent the wheel each time you want to make an installer. Just configure your program and compile the installation script/program. When we can have a standard way of compiling programs (make, configure), we can certainly create a standard installation program for Linux.
usable = minimal amount of mental cartwheels needed to operate.
Yes. I’m not sure why we’re arguing really. I completely agree on that point.
It’s just that I don’t think there are a fixed set of usability rules that work for every user.
Take the task of moving or resizing a window. For the novice user, it is most discoverable to drag it by the titlebar, and to use the little grab handles in the corner of the window to resize. For the casual user, this is also the most usable since it is quite evident how to do it, and doesn’t have to be explicitly remembered. It also requires little coordination since it can be done entirely with a mouse.
In KDE (and other DE’s for linux) you can move a window my holding a key (windows key for me) and dragging anywhere on the window. You can resize by holding the same key and dragging with the right mouse button. This is not discoverable, but very usable, and very fast, since I don’t have to aim for the titlebar or the little grab handles with my mouse.
So there is an example of the same process done in different ways, one is more usable for a novice user, and one is more usable for me.
Greetings
I agree with basically everything mentioned in the article but there is one major and very important question that it misses: usability for everybody, including the handicaped.
Software should not only be developed to be cross-platform, structurally adequate, etc., but it should also be adequate for being interpreted by screen readers, it should be carefuly studied from the point a view regarding colour contrast, figures, icons and font tipology, and it should also be very easy quick and effective (as mentioned) to use by all sort of people with as much physical and cognitive diversity as possible.
Building a great program and doing it inside the open-source and free software world is not only providing it with technical quality but it is also giving it for free and to make it accessible to everybody in the true sense of the expression. I think open-source has the oportunity to make this come to reality and to also pioneer it and take advantage comparing it to proprietary software.
for example, modal dialgues are plain evil. modal anything is evil.
Not if they are informing/asking about something that is critical to you continuing to work in the application.
forcing the user to stop what he is doing will result in him losing anything that isnt commited to short term memory. there are a great many things you are sub consciously paying attention to, and they will fade in around 10 seconds. not only that, it requires a shift of the users locus of attention, which is both time consuming and frustrating. sometimes they are unavoidable, but should be used as little as possible.
dialogues with only one choice are evil.
That would be a message box, not a dialogue, and they are very useful.
do you consciously think about how you walk? drink? ride a bike? the mind combines groups of actions into “gestures”, and will automate those gestures as much as possible. psychologists call this “chunking”. closing a dialogue (or message box, or alert box, or whatever specific name you have for it) will become part of the gesture after frequent use unless it requires your locus of attention. that either makes it pointless, or disruptive, depending on how its used. once again, sometimes unavoidable, but should be kept at a minimum.
dialogues asking for confirmation using a stock message and stock buttons are completely and totally pointless to the experienced user.
Standard save dialogs are a bad idea? I think you’re cracked.
read above. “Do you wish to quit?” “Yes, No” only has a use if you are not actively focused on anything in particular (i.e. not using the app) hitting “yes” or “ok” has become automatic for many windows users, driving support people crazy. what you need to do is break consistancy, which will force the user to actually pay attention to what is displayed rather then just hitting ok automatically. by the same note, standard save screens are a good thing for all those reasons, operating the interface becomes automatic, allowing the user to just be thinking about WHERE he wants to save it rather then HOW to save it.
preferences and customization are a sign of bad design.
Wrong. Very very wrong. In any given complex software there is a very large set of preferences that cannot be removed no matter how much additional code you write to make it automatic. A simple one is: “Use left handed mouse button mappings”. There are millions more just like this.
you picked one of the few exceptions 😉 any interface that can be made better by a few arbitrary changes, means that it wasnt designed right in the first place. in fact, any change to the default behavior will be breaking consistancy, and if the user ever has to reinstall, upgrade, or use another machine, they will be in “unfamiliar territory” and way less productive. i have a friend who broke a wrist when she was 13, so used the mouse with her left hand while she had her cast. guess what? she still switches the mouse to the left handed mappings.
do i need to go on? none of those are common sense, most of those fly in the face of common sense. joe coder wouldnt know that unless he has an interest in the subject.
Remind me not to use any of your software if you seriously believe in those rules.
oh, not me, pretty much everything i quoted comes from jef raskin, who was one of the greatest designers of computer interfaces. each of those are based on proven psychological principals, and many have been tested in real world situations. if that isnt your cup of tea, i guess there isnt much i can do about that. but this is what usability is, not some nebulous subjective art form.
the point you make is decent however.
Lets look at the current installer for linux or better yet limitations of how programs are.
First when you compile a program it is linked to that file in terms of filename and path.
Distributions have different ideas in where to place certain libraries and programs.
another problem with this is should the library be upgraded every program that was linked to that library will now be broken. unless there is some sort of backwards compatibily in place.
Another problem is different distributions use different versions of programs and libraries. why? some distributions think they are stable and some think they are not.
Lets say you wrote an installer. and lets look at everything you’d have to take into concideration.
Where do the distributions put your type of program?
What versions are they using. Do they have what your program was linked to?
If not then your installer is broken…. Oops…
Lets now look at distributions installers.
Do they know where they put stuff? I’d hope so.
Do they have installed what you used? They are running the same thing you are…
It works.
Also lets look at if people did write their own installer like windows.
it’s true that some use a simular installer… not very many do. that’s not very standard. in a distribution you are always using what your distribution provides that IS standard for EVERY program.
All of the ideas you say these installers should implement are already done.
it’s true that if you go to a different distribution you have another interface to learn but who cares stick with a distribution. there was an article earlier on osnews that discussed what linux distribution was the best and I agree to what he said. if you install a distribution stick with it. you’ll only find other quirks that you don’t like in others. now if that distribution’s quirks out weight the good.. yah I’d say switch but if there is just 1 or 2 quirks.. stick with it and tell them about it.. maybe they’ll like your idea.
[quote]I disagree. Useability is not about whether a product an peform a task or not. It is about HOW EASY it enables the user to perform that task. There are many ways to kill a rat, but some are more efficient, aka useable, than others. For every job, there is a good tool, a not so good tool, and a bad tool. You can use a piece of wood to hammer in a nail, but you are much better off using a hammer. You get my drift? An OS or program is a tool. It is more useable if it is easier to use, and less so the more difficult it is to use. That’s why “click on setup.exe” is generally a more useable procedure than “Edit Makefile && ./configure && make && make install”.[/quote]
That only holds true for the dumb.
I have seen the easiest of easy OS/programs that some say is so hard they wont use it at all.
The artical hit the nail on the head.
Yes, I understand that dynamic linking is great in theory. In practice, well, dynamic linking has its problems.
To start with, every developer has their own pet libraries. Some use gtk, some use qt, some use motif, some use tk, some use xaw, some use xforms, some use ncurses, some use slang. This list is far from complete, and it is just at the UI level. How much code reuse do you actually have here, unless you purposefully set out to limit yourself to one widget set?
On top of that, the developers have to make their libraries as appealing as possible to as broad a range of developers as possible. Enter the concept of bloated libraries which are duplicating the function of several other libraries on the system. This does not sound like code reuse to me.
As for upgrading libraries due to bugs, that sounds like a great way to introduce bugs to me. Think about it: software needs to be tested, particularly if you want usable, bug-free software. Now if the end-user may have one of several versions of the (implied) buggy library installed, the application developer must test against several versions of the library. Heck, they even have to test against versions of the library which do not exist yet. By moving to static linking, the responsibility for bugs in the libraries lies in the hands of the application developer: if there is a bug in a specific version of the library, they can link against a different version of the library; if there are bugs in the version of the library being used, they can patch around the bugs.
You are the typical example of someone who thinks usability is all about graphic user interfaces and some obscure rules written in some books. Open your mind friend and read my comment again. This time, calmly.
actually, im using the word the way it is used by human/computer interaction professionals 😉
Also, modal dialogues are not evil. There are situations where they are needed. Developers that abuse modal dialogues just don’t apply “common sense”. Are “goto” statements just plain evil too?
actually, goto and modal dialogues are evil in the same sort of way. anyone who makes a modern language with gotos will be doing everyone who ever has to maintain code written in that language a disservice. there are ways around it, they are just less straight forward. sometimes it cant be avoided, but if you are unaware of the problem its kind of hard to minimize its effects.
Usability is not about whether or not modal dialogues are evil. Can your subjects use or understand your work without having a cerebral panic? Without fiddling and fighting with your work? And most importantly, without cursing? If the response is yes, your work exhibits good usability.
except for the first sentance, you are bang on ;-). what i am trying to say is that the things which cause fiddling, fighting with your work, and cerebral panics, are not alwas obvious unless you have a backing in cognitive psychology.
In brief, you can apply usability principles to anything with an interface, not just the use, or abuse, of graphic widget sets.
agreed. a lightswitch is a fantastically usable object. microwaves on the other hand (for the most part) are not. the reason is that it is quite easy to design a good lightswitch (in fact, it would take some work to mess it up), while a microwave is alot more complex. it is significantly harder to make a usable gui then a usable cli, as the complexity of gui environments tends to be much higher.
Systems I work on at work with large user populations tend to satisfy either *them* or *me*. This is a problem which isn’t discussed very often. Usability is something we approach at least in part through mockups and focus studies with groups comprised of actual future users of whatever it is we’re doing. Inevitably, there’s a good portion of what these users want that I don’t want, or that I think will reinforce pre-existing bad habits. A good example of this was a search engine we rolled out. Users (technical to semi-technical, but inexperienced) wanted, initially, a “natural language query” and I wanted a robust boolean search, which we would then train users on, under the theory that in the long run the ability to construct complex boolean queries would allow the people who use this system to work faster (which was a major issue we were striving for). We were in a fortunate position because we had access to the entire user community; something generally rare.
The users won out and now several years later they complain that they get too many hits with each search, and now that they have been around longer, they want a boolean search.
I think there’s a lot less consensus about usability – everyone wants it but everyone has a different idea what constitutes it – than many people think. People more than anything resist change even if what they’re used to is pretty craptastic (consider the number of users still running Windows 9x). This is a huge problem in my direct experience. If you rolled out a new version of Windows that addresses every usability issue it has, you’d get resistance and complaints from most users, who absolutely hate change, even for the better. This is an immutable law of physics. People eventually adapt, but under protest, and slowly.
Another example – I *hate* pop up message boxes. Hate them. What I want is a small notification or message area. If I had my way, all apps would output errors to this specific box with a nice big cut and pasteable scroll buffer, and this box would never steal focus (For me, a big usability issue with any system is that it should *NEVER* steal focus, and Linux far far better in this regard than Windows. I don’t care if it’s God trying to communicate with me on IM – never, EVER, take focus from a window I’m typing in. Not even if it’s a life and death issue.)
Yet most people kind of blink at me when I recommend this.
To me, a computer with crap popping up all over the screen, and, depending on the OS and configuration, sometimes stealing the focus, is *not* usable…or useful. Actually it irritates the hell out of me. The way Evolution pops up the “checking mail” status box drives me up a wall. Not only does it not give any information as to what it is checking (save the server – and in my case I have about 6 e-mail addresses on a single server I need to check, and when one hangs, I don’t know which one it is), but it takes up half of the screen. It would be nice if you could maybe even choose globally whether you wanted pop ups or what I describe.
To me pop up boxes are miserable. I’d rather have something like a tailing log in a small box on the taskbar. (Then again a lot of people hate taskbars/toolbars and consider them a waste of screen real estate – another example of lack of consensus.) Perhaps Y/N/Cancel dialogs could also be somehow wrangled into a single area.
I’m going to beat the hell out of a dead horse for a minute and suggest too that a lot of usability issues don’t seem very interesting to developers. The inconsistent clipboard in Linux – a common complaint – drives me batty. I use more profanity daily as a result of the multiple clipboards / broken cut-paste system / whatever it is, than for anything else – not just as relates to computers but in LIFE. I have developed a foul, foul mouth largely as a result of being a Linux user. Unique and perhaps groundbreaking combinations of biblical figures and common filth pour out of my mouth like Niagara Falls.
In some apps, I can simply highlight and middle-click, but not so with, say, Firefox, where I have to select text, copy it, and then CTRL-V to get it to paste elsewhere. I don’t usually use CTRL-V to paste anywhere, and I’m always middle clicking, and dumping some hours or days old text to the wrong place. If there was a consensus on one way to cut and paste, I’m sure a significant amount of the user community would protest that it wasn’t *their* way, and this is likely to be a big issue especially on very habitual, instinctive skills like cutting and pasting. Look at how freaked out people were over the introduction of spatial browsing (Apparently this is the greatest idea ever / proof of the existence of Satan, depending on who you talk to).
That this (getting back to the clipboard) is even still an issue suggests that there’s just not a lot of interest in making these things consistent, and as I am not a Linux developer and pay nothing for these programs, I can only sort of grumble under my breath about it, because I don’t want to be laying negativity down on people who are providing a mostly-really-good thing for free. For free software projects, this may be the actual hidden cost. Use what you’re given, or lead a development effort to address it. That’s maybe not a bad trade-off but it certainly turns off a significant amount of users nonetheless. (If anyone knows of a silver bullet that exists out there now to address clipboard problems, please let me know; you will make my day.)
Even when you bring issues like this up, it generally results in a significant amount of finger pointing. It’s not the WM’s fault, it’s X’s fault. Or the application’s fault. Or the library. I’ve felt kind of discouraged, as a user, about bringing these things up. I’ve tried to be positive and constructive about my usability complaints the few times I did (as opposed to just bitching), but the defensiveness of developers is palpable. And frankly watching the really negative, abusive way some folks complain, as well as their sense of entitlement, I can understand.
And I can even understand why fixing mundane problems, especially if you’re not getting paid, just doesn’t hold the allure of adding cool features. For the most part, the free software model works, but this is an example (I think) of how it is rough around the edges.
Still, I use it, and will continue to use it, because when I tally it all up I still come out way ahead. I just wish there were less annoyances.
Ok fair enough. I agree with what you say. I was just adverse to the militant: this feature is _always_ bad.
Thanks for replying to my points. Doesn’t always happen on OSNews. Mostly people like to attack and not debate.
“Do you know a gui front-end that discovers Windows and Samba Servers in your LAN quickly and reliably, without starting obscure services, setting strange options and requiring you to hit the “refresh” button ten times? The answer is: there is no such thing. It doesn’t even work in Windows.”
SMB4K. Try it, don’t whine. Again, try it and report back.It is instant, it works!
yeah, go figure. every time i argue with someone intelligent here we alwas end up agreeing, and the source of the arguement was a misunderstanding.
first of all, adaptive interfaces are stupid, stupid, stupid. the amazing shifting menus in word is the perfect example of why consistancy is so important, simply because of their extreme disregard for it. its hard to find a user that feels comfortable with that “feature”. what i meant about visibility is what do you have on a toolpallet, and what do you have in a menu. something like a paintbrush goes somewhere very visible and accessable. “wreath my selection in flames” belongs somewhere out of the way.
It’s just that I don’t think there are a fixed set of usability rules that work for every user.
Take the task of moving or resizing a window. For the novice user, it is most discoverable to drag it by the titlebar, and to use the little grab handles in the corner of the window to resize. For the casual user, this is also the most usable since it is quite evident how to do it, and doesn’t have to be explicitly remembered. It also requires little coordination since it can be done entirely with a mouse.
In KDE (and other DE’s for linux) you can move a window my holding a key (windows key for me) and dragging anywhere on the window. You can resize by holding the same key and dragging with the right mouse button. This is not discoverable, but very usable, and very fast, since I don’t have to aim for the titlebar or the little grab handles with my mouse.
what you describe is a quasi-modal approach to window resizing that i like alot (didnt even know about it ;-)) you effectively make the target the size of the window rather then the title bar or the handles at the bottom right corner. doing that makes the target easier to both visually aquire, and physically target, hence improving speed, and reducing the amount of effort required to perform the task.
the modifier key enters you into a mode, where things behave differently. in a general sense, modes are evil, and will lead to frequent user error. a quasi-mode however (one where the mode automatically reverts back after the operation), allows your brain to “chunk” it into one gesture, you arent hitting escape, resizing, then hitting i to go back to “normal” mode, so conceptually the windows key becomes part of the resize operation.
now, im not a usability expert (ive just read alot of books, and am facinated by the subject), but from what i know of usability principals, that sort of resizing is quite usable. there are some problems with multiple ways to do the same thing, but that is often outweighed by improved flexibility as long as you dont go overboard (the more you do something, the easier a job your brain has of doing it automatically. by switching back and forth, you dont take advantage of the training you have already given yourself. however in this case i would say the benefits outweigh that. and again, this is a beginners opinion, the only way i could say for sure is through testing)
now, that was my (extremely noobish) usability analysis of that feature. there were no real rules, it was more along the lines of trying to think of what the process of someone resizing a window would be. every programmer knows that disk reads or writes are expensive in terms of performance. i dont think anyone would say dont save or read from the disk. but they all say to keep it to a minimum. those comments on things like modal alerts are the same. at times it is unavoidable, but it will be expensive in terms of usability.
if this is a subject that is of any interest to you whatsoever, i highly suggest jef raskins “the humane interface”. he was the guy who came up with the basic ideas behind the first mac, but left half-way through the project, and didnt consider anything available today (including the mac) to be usable.
For example, take Slackware; indeed it requires a fairly experienced Linux user to keep control of it, but it’s fairly easy to fix if something is broken. So in one sense Slackware is not usable because of its high barrier to entry, but in a more important sense it exhibits good usability because its configuration is straightforward and fixable for its target users.
The above quote illustrates exactly what I think is the problem with usability in F/OSS. Usability is linked directly with the product’s – wether it be software or anything else – intended audience.
Usability and HCI are sciences in their own right and go well beyond the scope of this article, however the link between audience and usability is an interesting aspect here.
In general F/OSS developers don’t necessarily get the usability of their products wrong, rather, they fail to properly identify their audience, which in turn leads to poor usability. This is not surprising, since most F/OSS products are designed bottom-up by programmers and programmers are not usability experts, nor are they system architects. Because of this, most F/OSS products assume a level of expertise far higher than that of the actual audience.
If developers take more time to actually identify their audience and identify their audience’s needs and expectations for the product at hand, good usability is more likely to follow.
Poor usability is not strictly a F/OSS problem, a lot of proprietary products – projects with massive amounts of money intended for research – get it wrong. This is in part because usability still doesn’t get the attention it deserves, but also because usability is a field in development and, most importantly, because usability is a human-centered field. Humans have a terrible interface to interact with because every single instance of the class “Humans” is different.
This is so true, infact this my gripe with Linux. We have great applications in Linux but when you look at the UI. Here are my thoughts on a few
1. Gimp -> the ui pre 2.0 was all over the place now also it is confusing. You have the same menu repeated if you right click or you use File.
2. KDE -> normally it takes me 3 hours after installing any new distro to arrange menus to my liking otherwise its a whole bunch of KBla KBlaa KBlabla in the Start menu. Gimme a break why cant I have a notepad a calculator a paint in the accessory. Also why do I need to have a prefeence/system tool/system setting why cant it be SETTINGS.
3. Gnome does not let me edit menus in Fedora so I gave up. I was trying to edit them in JDS 3.0 and the system totally crashed on me.
4. I know there are Billion and a Half apps for linux but really the Linux distros should prioritize what they want to include with their distros based on usability. Rhythmbox comes to my mind off hand as an app good for nothing. None of the distros that I have installed had rhythmbox work for me.
5. Why do we have rhgb bootsplash [ok] prompt when the system boots. Agreed there is a geek aspect to it but really who cares. I always get amused when I get the boot message “Wireless adaptor wlan0 failed to initialize check you cable”
6. I liked mandrake in the pre 8 days because it was the only distro that had proper menus no matter what WM you used .
I guess Linux need some direction from artists who need to work more than coders.
Useability is a matter of opinion, and therefore, any debate over this is utterly pointless and destined to end in a flamewar.
I find Tracker/Deskbar the the highpoint of useability. Yet, my next-door neighbour may completely disagree. And I’m cool with that; my perception of useability is different than his.
I agree with you on almost every point but very few. You do not need to be a cognitive psychologist, human computer interaction expert or usability engineer to produces usable objects. Also books on usability, user interface design and user interactions only serve as guides. They are not unconditional and unbreakable laws or rules.
Many of the so called “expert” suggestions, with regards to usability, break when implemented in real world testing and deployment. This isn’t the fault of the “experts,” but rather it is the fault of the designers who failed to acknowledge when the rules were inapplicable. Good designers know when to break or bend the rules, and when or how to apply them.
I encourage people to read books, articles, journal and papers on usability and related topics. However, they equally need to understand that there is no substitute for the practicality, critical thinking, creativity, innovation, experimentation and testing with regards to producing usable works.
In short, not using “goto” statements or modal widgets because it conflicts with usability authority X’s principles wouldn’t produce usable works. Rather, thinking critically about your subjects, their usage patterns and the problems they are trying to solve should be a start. In addition, extensive testing and experimentation can not be overlooked. Finally, using usability materials written by experts as reference material and guidelines may produce usable objects.
At the core of it all is common sense. I mean Jeff Raskin is a respected and renowned usability authority and all, but some of his postulations are too radical for practical deployment.
dear lord, this thread is full of posters who arnt morons! whats happening to osnews?
Systems I work on at work with large user populations tend to satisfy either *them* or *me*. This is a problem which isn’t discussed very often. Usability is something we approach at least in part through mockups and focus studies with groups comprised of actual future users of whatever it is we’re doing. Inevitably, there’s a good portion of what these users want that I don’t want, or that I think will reinforce pre-existing bad habits. A good example of this was a search engine we rolled out. Users (technical to semi-technical, but inexperienced) wanted, initially, a “natural language query” and I wanted a robust boolean search, which we would then train users on, under the theory that in the long run the ability to construct complex boolean queries would allow the people who use this system to work faster (which was a major issue we were striving for). We were in a fortunate position because we had access to the entire user community; something generally rare.
The users won out and now several years later they complain that they get too many hits with each search, and now that they have been around longer, they want a boolean search.
“the customer is alwas right” is a good way to sell units, but a terrible way to build a quality product (paul graham had a fantastic essay on this called “made in america” in his book). the fact of the matter is, the customer knows what they want, not what they need. this is a beautiful example of this fact. making a car “better” by putting tailfins on it is another.
I think there’s a lot less consensus about usability – everyone wants it but everyone has a different idea what constitutes it – than many people think. People more than anything resist change even if what they’re used to is pretty craptastic (consider the number of users still running Windows 9x). This is a huge problem in my direct experience. If you rolled out a new version of Windows that addresses every usability issue it has, you’d get resistance and complaints from most users, who absolutely hate change, even for the better. This is an immutable law of physics. People eventually adapt, but under protest, and slowly.
you can learn to use pretty much any interface. it is a matter of how exhausted you will be at the end of the day that will never fully go away from using a bad interface. where the problems come from is users are unaware of this, and someone who has learned to use a bad interface will find a good one difficult, frustrating, and unfamiliar. that is, until he learns it. then he will love it.
Another example – I *hate* pop up message boxes. Hate them. What I want is a small notification or message area. If I had my way, all apps would output errors to this specific box with a nice big cut and pasteable scroll buffer, and this box would never steal focus (For me, a big usability issue with any system is that it should *NEVER* steal focus, and Linux far far better in this regard than Windows. I don’t care if it’s God trying to communicate with me on IM – never, EVER, take focus from a window I’m typing in. Not even if it’s a life and death issue.)
Yet most people kind of blink at me when I recommend this.
dude, read my comments to leo about this very subject. there are psychological reasons for this, you happen to be more aware of how you work then the vast majority of users. congrats 😉
To me, a computer with crap popping up all over the screen, and, depending on the OS and configuration, sometimes stealing the focus, is *not* usable…or useful. Actually it irritates the hell out of me. The way Evolution pops up the “checking mail” status box drives me up a wall. Not only does it not give any information as to what it is checking (save the server – and in my case I have about 6 e-mail addresses on a single server I need to check, and when one hangs, I don’t know which one it is), but it takes up half of the screen. It would be nice if you could maybe even choose globally whether you wanted pop ups or what I describe.
To me pop up boxes are miserable. I’d rather have something like a tailing log in a small box on the taskbar. (Then again a lot of people hate taskbars/toolbars and consider them a waste of screen real estate – another example of lack of consensus.) Perhaps Y/N/Cancel dialogs could also be somehow wrangled into a single area.
“A modeless and monotonous interface would be extrodinarily pleasent to use”
-jeff raskin
(monotonous meaning one clear way to do things, lowering learning time and increasing automaticity)
I’m going to beat the hell out of a dead horse for a minute and suggest too that a lot of usability issues don’t seem very interesting to developers. The inconsistent clipboard in Linux – a common complaint – drives me batty. I use more profanity daily as a result of the multiple clipboards / broken cut-paste system / whatever it is, than for anything else – not just as relates to computers but in LIFE. I have developed a foul, foul mouth largely as a result of being a Linux user. Unique and perhaps groundbreaking combinations of biblical figures and common filth pour out of my mouth like Niagara Falls.
the geekier the person, the more resistance you will get because they will be more willing to learn an inhumane system. i have been on a usability crusade here at work for awhile now, and meet constant resistance from my fellow developers who dont see the how many of them are worth the effort. thats why i started buying books, so i could have something concrete to back up my statements. linux is the result of a high concentration of uber-geek, so it stands to reason that features would be paramount, and usability an afterthought.
In some apps, I can simply highlight and middle-click, but not so with, say, Firefox, where I have to select text, copy it, and then CTRL-V to get it to paste elsewhere. I don’t usually use CTRL-V to paste anywhere, and I’m always middle clicking, and dumping some hours or days old text to the wrong place. If there was a consensus on one way to cut and paste, I’m sure a significant amount of the user community would protest that it wasn’t *their* way, and this is likely to be a big issue especially on very habitual, instinctive skills like cutting and pasting. Look at how freaked out people were over the introduction of spatial browsing (Apparently this is the greatest idea ever / proof of the existence of Satan, depending on who you talk to).
That this (getting back to the clipboard) is even still an issue suggests that there’s just not a lot of interest in making these things consistent, and as I am not a Linux developer and pay nothing for these programs, I can only sort of grumble under my breath about it, because I don’t want to be laying negativity down on people who are providing a mostly-really-good thing for free. For free software projects, this may be the actual hidden cost. Use what you’re given, or lead a development effort to address it. That’s maybe not a bad trade-off but it certainly turns off a significant amount of users nonetheless. (If anyone knows of a silver bullet that exists out there now to address clipboard problems, please let me know; you will make my day.)
inconsistant behavior is the great satan of usability. there is no better way to jolt a user out of whatever he is working on by having things behave inconsistantly. imagine you are walking, eating a snack, and working out an algorithm. eating and walking are done automatically, your focus of attention is on your algorithm. suddenly, you notice something fuchia in your tuna sandwich. what will happen now?
you stop walking.
you stop thinking about that problem.
you stop eating, and shift your focus to investigating the anomoly.
the same thing happens whenever you encounter an inconsistancy in an interface.
Even when you bring issues like this up, it generally results in a significant amount of finger pointing. It’s not the WM’s fault, it’s X’s fault. Or the application’s fault. Or the library. I’ve felt kind of discouraged, as a user, about bringing these things up. I’ve tried to be positive and constructive about my usability complaints the few times I did (as opposed to just bitching), but the defensiveness of developers is palpable. And frankly watching the really negative, abusive way some folks complain, as well as their sense of entitlement, I can understand.
And I can even understand why fixing mundane problems, especially if you’re not getting paid, just doesn’t hold the allure of adding cool features. For the most part, the free software model works, but this is an example (I think) of how it is rough around the edges.
agreed. programmers are not qualified to design interfaces (and i include myself in that statement, i am a self-taught noob) the problem is that your average coder has no clue how important this stuff is.
“make sure that your file formats and configuration data is at least forward compatible”
Bacward compatible data formats can sometimes be used, such compatibility is many times a must.
“Forward compatible” is just a desire, a good foundation may help, but you can never promise to be compatible with some software that was not yet written.
Nice article anyhow.
jef refused to accept the times he lived in, and was alwas frustrated both by how little he had to work with, and what a poor job everyone does with what they have. on one side you are correct, many of his ideas are not really practical, at least today. on the other hand, someone who thinks outside the box will not be afraid to challenge faulty conventions.
taking the time to think things through would be a collosal improvement over current designs, but it still wouldnt take into account things you are not aware of. i am a better designer now then i was six months ago, and that is because of the reading i have done on the subject (i still suck in a major way). i think we need to develop a set of sane standards before anyone can be a designer.
that being said, i dont think that the words of raskin or the tog, or nielson, or anyone else are nessicarily law. i think however, that there is a fundamental level that needs to first be achieved before we start getting into the more subjective “this is better then that”. when the tools available discourage developers from making usability blunders, then we can all be designers. until then, we need to understand how the various elements work before we begin, or we will be doomed to failure.
You’ve got umpteen OSs that happen to run on top of the linux kernel that are slightly dissimiliar enough to be annoying. That is the real reason that issues like deployment and static linkage have to be brought up. You don’t run Linux, you run RedHat or Suse, or Debian.
I agree. The bar is further raised, unfortunately, for free software projects because many of them do not have access to usability experts, or do not pay attention to usability at all!
Fortunately, some projects, GNOME in particularly, are beginning to understand the importance of usability. I sympathize with free software developers. They have to be graphic artist, project manager, system architect, usability expert, tester, documentation writer, hacker and many more at the same time!
Yet, people never cease make fun of and disparage the efforts of these developers instead of help. Articles like this are a blessing because it reinforces that usability should be a key part of software development, or any other creative pursuits for that matter.
intuitive = obviously works a certain way (how to operate a button)
learnable = easy to learn. you can become a master in a short amount of time.
usable = minimal amount of mental cartwheels needed to operate.
I think this is really interesting because one of the things that has been bothering me after 10+ years of doing usability tests is that we are confusing two separate questions: How much time does it take to perform a task? (usability) and How much time does it take to learn an interface? (learnability).
A lot of this is highlighted for me by the inexplicable popularity of vim. Vim breaks most of the dogmatic rules that tend to go with usability: it’s modal, capabilities are hidden, it has a high learning curve. The assumption here is that given a choice between an editor like vim and a more “usable” editor like Kedit, ultraedit, bluefish or bbedit that I’d adopt the editor with functions that use nice pull-down menus. I suspect the popularity of vim is because once you’ve learned the interface, it permits some pretty powerful edits using a minimal amount of time and/or keystrokes. Similarly, regular expressions require quite a bit of time to learn, but make quite a few tasks easier after you have learned them.
A lot of the most powerful systems available use interfaces that are not exactly easy to learn: a car, a motorcycle, a multi-speed bicycle. A lot of what makes these systems highly “usable” in the hands of an expert is that they sacrifice explicit labeling for ergonomics. In addition, it is difficult to claim that these interfaces are intuitive. (Especially the toe-shift on a motorcycle that typically puts neutral a half-step between first and second.)
The more I have to deal with usability, the less convinced I am about the validity of the standard usability testing protocol that starts with a novice user, and measures time to perform a task.
Actualy, this is prety much 50% of usability.
Consistency.
So, in your opinion, apps such as Windows Media Player and WinAmp are not useable?
How about games? Are all games unusable because they all have their own interfaces?
Consistency is overrated.
To prove that usability sure ain’t just a matter of taste, here’s an interesting site about examples of bad usability design (not just softtware but many sorts of machines etc. too):
Educate yourself:
(and read the text beside the images too)
http://www.baddesigns.com/
uhm…, so to be accurate: the site http://www.baddesigns.com/ I mentioned above is not really about software at all, but about usability in general. But basically usability is usability, whether you use a PC or a car or a washing machine: you have study what the needs of the typical users are, and then design the product for them.
From Wikipedia:
Usability is the measure of how easily a thing can be used (typically a software application or a piece of hardware). This is generally defined in terms of the needs of the users of the thing. Often, the intentions of designers directly conflict with these needs.
Usability addresses the full spectrum of impacts upon user success and satisfaction. The usability designer provides a point-of-view that is not dependent upon computer programming goals because the usability designer’s role is to act as the users’ advocate.
I disagree with the author’s comments about “releasing early, releasing often.” Te whole point of this is to gain more feedback from the userbase and other developers in order to refine the program and, amongst other things, make it more useable.
Open source should not be subjected to marketing pressures. Programmers should notbe pressured to delay releases as this will be a detrimentto the quality in the longer term. If an early release is buggy and unstable, so be it. It is necessary to have something to review in order for advice to be give on how to improve it.
Hopefully, the programmer will act on that advice and any patches supplied. If they fail to, it is quite likely the software will splinter and a rival will emerge fromthe original code base.
So, in your opinion, apps such as Windows Media Player and WinAmp are not useable?
Yes. You may be used to these interfaces, but they are not usable. Especially Windows Media Player is horrible. That UI is one of the most confusing ones I use on a daily basis and adds nothing good to the application. A case can be made for Winamp’s UI, since it permits some useful things that are not possible with standard widgets, but overall, it is confusing as hell to someone who is not used to it.
How about games? Are all games unusable because they all have their own interfaces?
For the most part, yes. The reason they have non-standard interfaces is
A) eyecandy
b) there are no good standard opengl/directx widgets to use
Menu systems for games are pretty crappy. Each one works differently. Yes they’re not impossible to use, but they could be better. These menus all provide the same functionality, but each one forces you to think about what you’re doing instead of just doing it.
However in the case of in-game interfaces, a non-standard interface may be beneficial just to preserve the feel of the game.
“Learnability” is a key aspect of usability. VIM, albeit one of the most powerful editors I’ve ever used, is a leading example of how not to design an editor. Randomly select 10 individuals from your local store and place them before VIM. Marvel as they curse all day in front of the monitor.
VIM is a powerful editor designed by geeks for geeks. You need to spend weeks reading the manual and book, months mastering its interface and idiosyncrasies and years realizing it doesn’t scale well for large projects. Many times, one is better off using Notepad or Gedit than VIM.
I’ve used VIM religiously in the past, and I was a staunch advocate of it at some point. But even then, I remember cursing a lot when using VIM. It never became second nature to me, even though I pretended it did. VIM is a great editor, but it’s only usable by those who have way too much time on their hands. I forsee it’s popularity diminishing with time. I’m going to get flamed for this.
”
You may be used to these interfaces, but they are not usable. ”
How is he playing the latest Britney mp3?
The buttons lkook different, butt hey’re still buttons! If anything, Winamp as an app was harder to learn how to use then WMP.
Interesting to note that nobody mentioned that an ISO standard exists for usability (ISO 9241): the three requirements of usability are effectiveness (the ability of a user to complete a task), efficiency (the resources used to complete the task), and user satisfaction (self explanatory). Some folks in the BayCHI group think that all three are highly associated so a single metric can describe the usability of a product, though my own research differs from this.
A lot of usability is based on empirical work in human-computer interation (i.e., there is a rational basis for a lot of it), though in my experience quite a few industry ‘experts’ are not that well educated (they often spend a long time ‘discovering’ things that have been understood for a long time).
The biggest problem is that a lot of HCI is counter-intuitive – it’s not obvious and only good user testing shows up the flaws.
My advice to anyone interested is read around. Card, Moran and Newell’s ‘The Psychology of Human-Computer Interaction’ is a good start for those who like hard evidence. Best of luck!
Static linking seems just fine when you release: you ship one big honking binary and everything’s fine; it runs everywhere.
But whoops, there’s a security bug reported against one of the libraries you use, it’s a bad one, and all the distros release an update. If you statically linked, your app has a security bug still. If you dynamically linked, it does not.
Static linking also increases memory requirements, especially if you statically link against common libraries (like the C library, or basic X libraries). Other apps the user already has running use those libraries; if you prevent sharing, you make paging and loss of performance more likely, especially for those with older machines.
All that said, it may still pay to ship binaries that are at least partially statically linked if they require “bleeding edge” libraries, that is, libs not commonly available on distros that are in common use. Even in this case, the decision to link statically or dynamically can be made separately for each library.
I think this is really interesting because one of the things that has been bothering me after 10+ years of doing usability tests is that we are confusing two separate questions: How much time does it take to perform a task? (usability) and How much time does it take to learn an interface? (learnability).
well, i would disagree for a few reasons. theres this standard evaluation heuristic called GOMS thats widely used to get an idea of how long it will take a user to perform a task, and i know that some of its extensions take into account learnability. the other thing is that learning doesnt end, a user will keep getting better and better. i have seen photoshop pros at work, and it is an incredable thing to watch. another example would be touch typing, you do slow down around 40wpmish, but you will still increase at a steady rate. the same is true for computer interfaces. what we need is to have a good emphasis on help systems (the man who came up with tooltips should get a friggin medal)
A lot of this is highlighted for me by the inexplicable popularity of vim. Vim breaks most of the dogmatic rules that tend to go with usability: it’s modal, capabilities are hidden, it has a high learning curve. The assumption here is that given a choice between an editor like vim and a more “usable” editor like Kedit, ultraedit, bluefish or bbedit that I’d adopt the editor with functions that use nice pull-down menus. I suspect the popularity of vim is because once you’ve learned the interface, it permits some pretty powerful edits using a minimal amount of time and/or keystrokes. Similarly, regular expressions require quite a bit of time to learn, but make quite a few tasks easier after you have learned them.
ive been thinking about vim alot recently as well. regular expressions is another one i hadnt thought of, but its real similar. a third would be a ascii based rpg i used to play called “angband” (based on moria, and quite roguelike for those who are into such things) it has a redicules amount of commands, but once you learned them all you could do a remarkable amount of things, far more then most “modern” games in the genre. you do make a real good point, but i think it goes a bit further. there is no more powerful way then regular expressions for pattern matching, and something like that in and of itself is a conceptual work of art. same thing with vim, i cant think of a more powerful editor. the thing is, just because it is powerful, doesnt make it easy on the brain. the amount of work it takes to get profiecient in it is just phenomenal, and the demands on the memory are far more then are acceptable to inflict on the average user (remember, 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.