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.
About static linking: it’s not the entire library which goes into the binary, only the parts which are actually called by the program. And that’s ususally only a fraction of the library’s size. So the memory overhead is not that big (except for some huge frameworks like e.g. Gnome or KDE). Modern desktop systems have memory to waste, anyway.
Also, the startup time of the program improves, as it doesn’t have to invoke ldd to gather its dynamically-loaded libraries each time. This is certainly a benefit for programs that are invoked continuously, e.g. gcc in a make process.
“Conculsion”
Proper spelling avoids confusion in the brain and prevents time being wasted by re-constructing the proper word or sentence.
Sorry, could not resist myself
lumburgh has managed to derail a real good discussion into a flamefest. i dont think i have seen a troll able to do that so consistantly, if there were a prize for being the biggest waste of time to the most people, it would definately go to you lumburgh.
congratulations.
when you do anything, you have only one focus of attention. a good gui is designed to keep that focus on whatever you are actually working on, and allow for automatic behaviors for anything not related to that. disruption of that focus is what seperates a usable product from an unusable product, users will not fully understand the reasons, but a product that requires your active focus to operate will be more difficult and frustrating to use. invisible application modes are probably the most efficient way to accomplish this, which is why that white “INSERT” in vim is such a colossal improvement over vi. the edit/command mode switch is still phenomenally error prone, but at least making it visible makes it leaps and bounds better. what would make it better still is elimination of the mode itself, or figure some way to establish a quasi-mode while retaining the power of vim.
regardless, any interface which has an inconsistant interface will result in more errors, which results in the shifting of your focus on to the interface rather then your work, which results in a frustrating experience and loss in productivity. a former vim zealot posted earlier about this, and how cursing over frequent errors becomes habitual for the vim user.
the only type of person who would find something like vim even remotely acceptable is a geek. geeks love learning complex systems, even when they become less efficient in doing so. why do you think the pc guys laughed at macs back in the 80s? it wasnt complex, required no maintenance, and you could accomplish virtually anything in a fraction of the time. but thats so BORING. if it easy, it cant be powerful, and therefor inferior. this is the geek mentality. couple that with the standard belief that your perception of your efficiency is even close to reality, and vim users can be explained.
when i fire up any text editor other then an ide, it will be for simple text editing. any editor that requires more then five minutes to learn is needlessly complex for someone in my situation. i would like to hear, especially from lumburgh, why you need something so complex. if i need to crop an image, i most definately will not be launching photoshop, and if i need to change a line in a text file, i wont use vim.
… when you don’t split up articles only to pester users with more ads.
I’m a long time Vi(m) user. I recently tried switching to joe, an editor which you (mattb) would probably classify as more usable. But I was just constantly typing vi commands in joe. They’re simply in my fingers. Usability is in habit, and in nothing else. When I am doing anything more complex than simply typing text (like copy/pasting), I am MUCH quicker with Vim, just because I know it so well.
I can image that if I learned joe as my first text editor, I’d hate Vim for the very same reason as I disklike joe right now.
I’m a long time Vi(m) user. I recently tried switching to joe, an editor which you (mattb) would probably classify as more usable. But I was just constantly typing vi commands in joe. They’re simply in my fingers. Usability is in habit, and in nothing else. When I am doing anything more complex than simply typing text (like copy/pasting), I am MUCH quicker with Vim, just because I know it so well.
I can image that if I learned joe as my first text editor, I’d hate Vim for the very same reason as I disklike joe right now.
im fairly competant with CDRoast too. just because i know it, doesnt make it more usable then k3b, which i have used about twice in my life.
when you learn an interface, you will develop all sorts of automatic behaviors for it. you will develop the same behaviors in joe eventually, and when you have aquired a similar level of compitance with your new editor, you will find it easier, and more productive then vim. until then, it will be a foreign land where nothing does what it should. this isnt usability, its the subjective perception of usability, which is exactly the reason design cannot be done from a “common sense” point of view. my favorite color is probably a dark shade of green, however when i painted my house it was in white or offwhite with a hint of yellow. even though i like dark green, that color would make the room seem half the size to anyone who entered it. that is subjective perception vs psychological principal.
Usability is making an object easy to use and understand. You are making the subject needlessly complex. Software usability is equally similar. Making software easy to use and understand.
That comes second. Usability is about helping a specific type of user accomplish a specific task. “Easy to use and understand” come out of that.
VIM’s interface is not easy to use and understand.
And here I think we are at loggerheads on what is meant by “easy to use” still. There are dozens of things that I find quite easy to use that required quite a bit of skill and learning: pencils, cars, and shoelaces come to mind. Too much of this debate has been focused on vim as an application rather than vim as an example of a group of interfaces that allow people to get things done quickly, but are not necessarily easy to learn.
Editors are general purpose applications in any operating system environment. General purpose in the sense that anyone should be able to use a text editor to edit textual information. Or, at least, this is my assumption.
Again, you have that infamous anyone pop up. Rule one of designing for usability: know your users. A program that will be great for one class of users might be completely unusable for another class of users. So the first thing you do is understand your target audience.
For general purpose software, like a silly editor, why does one need to spend weeks learning how to edit files?
For something like Microsoft Word, I wish that most of my collaborators had spent a few weeks in a class learning how to format documents? Why? Because Microsoft Word offers quite a few capabilities for doing things the wrong way, ending up with wasting my time unraveling a mess of conflicting embedded styles and formatting directives.
Why should one go to diver’s school to drive a car? vim is much easier to learn than driving a car (15 minutes vs. 5 weeks). And I would argue that GEdit is only usable because you spent 15 minutes sometime in the past learning the pull-down menu paradigm which cannot be called intuitive either. (And unusable once you start needing as routine any of the features that I listed that it lacks.)
Special purpose software is a little different. For special purpose software, your audience is usually targetted.
Your audience is ALWAYS targeted. The simple fact that you are writing a comptuer interface rather than a door means that you are desinging for someone as opposed to anyone.
If I’m a database specialist, the interface of a database program should just make sense just by looking at it, at least in a utopian world.
Well, here is another issue. Visual interfaces are great until you reach a certain level of complexity. After you’ve gone beyond the point where you can point and grunt or drag and drop, I think it’s time to really start considering thinking in complete sentences and shift to a linguistic interface.
For a general purpose application, VIM is lousy with regards to usability. I mean, the first time I sat before VIM, which the first time I used linux, I had a cerebral panic.
There is no debate that vim has bad learnability. The key debate here is whether learnability and usability should be equated with each other.
Gedit does those everything you listed.
Actually it does not. Regular expressions are not supported and google revealed no plans for supporting them. Some of the functions are supported through plug-ins that are turned off by default. (Had to read the manual to find that.) According to the wiki plugin support is problematic because many of the plugins are of “dubious usability.”
So exactly why should I use a program that lacks some of the features I use every day, and diables some of the features I use every day by default?
regardless, any interface which has an inconsistant interface will result in more errors, which results in the shifting of your focus on to the interface rather then your work, which results in a frustrating experience and loss in productivity. a former vim zealot posted earlier about this, and how cursing over frequent errors becomes habitual for the vim user.
You see. I have this experience every time I have to draw my focus away from what I’m doing to a pull-down menu bar. Especially for those “once a day” or “once a session” functions that frequently don’t have a mnemonic key sequence. So for example, while I’m reasonably certain that “Save as…” is going to be in the “File” menu, I’ll have no idea how far down in the menu it might be, or whether that is in fact the function I need. (Sometimes you need “Export…”.) Is spell-check in “Edit” or “Tools” for this application? Or for that matter, preferences can be either in “Edit” or “Tools” for the same application on two different platforms! History in Firefox is another one of those things that I just seem to have trouble finding on a regular basis.
I’ve done enough usability testing to know that the semiotics of pull-down menus are a bit more complex than has been stated here, and that pull-down menus force users to linearly search through a foreign taxonomy, and that many users find this frustrating.
Of course, we are all just pissing in the wind without data and swapping anecdotes. My anecdotal experience is that mode errors cause me relatively little frustration (they are infrequent and easy to fix), while finding a function through taxonomies of menu systems cause me much frustration.
when i fire up any text editor other then an ide, it will be for simple text editing. any editor that requires more then five minutes to learn is needlessly complex for someone in my situation. i would like to hear, especially from lumburgh, why you need something so complex. if i need to crop an image, i most definately will not be launching photoshop, and if i need to change a line in a text file, i wont use vim.
Well, I agree. I wouldn’t recommend learning vim to change a line in a text file. I also wouldn’t recomend learning LaTeX or Framemaker to write a letter to grandma, R to balance a checkbook, perl to calculate sales tax, Premire to edit home movies, or Blender to doodle a cartoon.
For me however, vim is great for working and editing large texts. Visual mode with the keyboard is IME quicker and less error prone than selection of text with the mouse. /subsubsection.*Structural gets me to where I need to edit quicker than [Ctrl-f] Structural [Enter] [Ctrl-g][Ctrl-g][Ctrl-g]. It’s not that I have not tried or am not familiar with other text editors. What I found was that vim after a very short learning period, was more efficient for the editing I needed to do than WinEDT or Notepad.
my favorite color is probably a dark shade of green, however when i painted my house it was in white or offwhite with a hint of yellow. even though i like dark green, that color would make the room seem half the size to anyone who entered it. that is subjective perception vs psychological principal.
And I would argue that subjective experience should be a critical part of any usability test.
Great point who need 50windowsmanagers? There are several apps. that do the same thing, I know linux is about choice, but this is overkill. I agree with the pakage mangment part also. Really OS X is a great example to look at.
in a perfect world one would not need any window manager, you would just fire up a app and if it needed a gui it would point itself to a subsystem that handled gui apps. in fact with the right setup you could build a “desktop” based on a combo of gui apps started by a script.
and if you want a linux dsitro without a package manager? check out gobolinux, there you just drop the app into a folder based on its name and a subfolder based on version. they only maintain a set of symbolic links for backwards compatiblity for apps that may need a total rewrite to support their internal structure. most user apps will in fact work after a basic folder drag&drop job as the location they are dropped in is allready set in bashrc and similar.
we are getting closer and closer to agreeing 😉
one of the problem with the whole pulldown menu loving amoung prominant usability guys is that most of them have worked at apple at one point or another, and there are a great many things that make apple menus more usable (the position is alwas the same, the structure is designed by the HIG, and more importantly followed by third party developers, targetting time and difficulty is reduced by leveraging fittes law, etc). none of these are really used on other systems, so naturally menus wont be as attractive.
the goal is leveraging spatial memory for infrequently used tasks. “an option near the top of the third menu” is much easier to remember then “:ldskfjkd”, and you will be far less error prone while using it.
also, using a graphical input device like a mouse is using a different part of your brain then the one that is used while entering text commands, or mentally working out a problem. there were tests that bruce tognazzi did at apple, where he was basically trying to defend keyboard cursor manipulation against arguments that the mouse is less complicated. the argument he was planning on making was that keyboard navigation is simply more efficient, and he purposefully skewed the test to make his point. his tests were along the lines of “select the second l in the third sentance, copy it, select the fourth i from the last sentance and paste.”. it turns out that mouse selection was significantly more efficient then keyboard selection, AND to a man, users will report the exact opposit. turns out that there is perceptual time distortion when using keyboard commands, your brain is more active and you are less conscious of the time that passes, where as with a mouse, instead of thinking of what key to press next, you will be both processing your next task and performing the current operation in tandem. your brain will be less active, and perceive time to be longer then it is. (the article is on asktog.com somewhere, after he put it up he got all kinds of email saying that the experienced typist is faster with keyboard commands. he basically said that he has done extensive testing on the subject, and unless anyone came to him with hard evidence (aka use a stopwatch), he was going to ignore all future mail on the subject)
taking subjective user preference into consideration is important. but putting pleasing your customers over reducing the quality of the product means that you are abdicating your responsability as a developer. any interior decorator who let me paint a room dark green would be doing the same thing, as would any archetecht who encourages monolithic design because a manager thinks there are too many source files (no joke, ive seen it happen). if you are working with people who do not have the nessicary background to understand the implecations of their desires, its your job to fight it.
they are two seperate things. if i would design something for a programmer, then i would do things like give more burdens on memory in exchange for more flexibility. that means i wont be as much of a nazi on things like having over crowded menus or toolbars. that doesnt mean that i will allow the minimize/maximize/close buttons to be re-arranged, or have a modal dialogue pop up saying “Document has been saved successfully” after every save. if i were to design for a child, i would put greater emphasis on keeping the memory burden low (keeping menus and toolbars to a minimum), and put a very large emphasis on consistancy (there should be very, very few configuration options on an app targeted at a five year old). another example would be designing for the physically handicapped, you would want to do things like eliminate timing or anything that requires some dexteriety to use from operations (i.e. no things like double click), and strongly recommend things like magnification and text to speach functionality.
but who do you design a browser for? or email program? or im client? none of these have particularily complex functionality, so it is feasable to design so that it will be quite usable to the vast majority of users. saying one program for each class of users will for the most part cause more harm then good. a child using a “kiddie” browser would lose the substancial benefit of alot of use when he switched to something more fully featured as he grows up. on the other hand, if he could use a small subset of those features almost as effectively as the kiddie browser, it will be a natural progression from novice to expert.
specialized designs most definately have their place, but for the most part designing for the human will be more effective, at least in the long run.
The goal is leveraging spatial memory for infrequently used tasks. “an option near the top of the third menu” is much easier to remember then “:ldskfjkd”, and you will be far less error prone while using it.
Some honest comparisons would help this coversation along. I’m looking at my menu options and seeing very little that would not be expressed in one or two characters. Is there a menu item that encompases a function that requires a 9 letter keyboard sequence in vim? In addition, I’m still prfoundly skeptical that the gains from leveraging spacial memory are that different from the gains from using language memory. If I have to read the menu items to find what I’m looking for rather that use the hot-key sequence, I’ve been pulled out of my task.
In regards to mouse vs. cursor travel, I’d like to point to one important caveat in that document:
<blockquote>On the other hand, Peter, I have seen some mouse implementations that were slow enough that cursor keys might very well outperform them. I’m particularly suspicious of a “cursor that obscures half of what you’re trying to select.” I also assume you implemented a cursor scheme that would enable you to travel by word-at-a-time and sentence-at-a-time. Such schemes will increase the speed of cursor travel, although the decision-making necessary to select the most effective key combination can increase the mental burden—and time—even more.</blockquote>
Which pretty much gets to the core of what I see as a factor in the mouse selection problem:
1: Mouse selection in many programs attempts to “anticipate” what you really mean when you select a block of text. With results that are only half the time what I want.
2: Many pointers suck, obscuring parts of the text or offering poor precision.
3: Quite a bit of mouse hardware sucks, especially on laptops.
So I have some questions about the methods used in this study. It seems to be stacking an ideal mouse implemenation, vs. a less than ideal pattern of keyboard use, for an unrealistic task could be solved in 5 seconds by a skilled editor.
but who do you design a browser for? or email program? or im client? none of these have particularily complex functionality, so it is feasable to design so that it will be quite usable to the vast majority of users.
Again. It depends. The email program I used when I was answering 100 tech support messages a day is different from the email program I use now. The tech support center had a demand to track each piece of incoming and outgoing mail including my my comments on the interaction, and macros to automatically include text from our knowledge base.
Likewise, I have colleagues who organize learning sessions by chat, placing higher demands on their im clients.
specialized designs most definately have their place,
Well, that’s a start. A shame that it only took 80 messages to get to a point where you agree with the core of this debate. Specialized designs have their place.
That is what this entire argument is about. Specialized designs have a place, and we should not expect a design that works well for a specialized audience, to work well for the impossible-to-exist human.
… but for the most part designing for the human will be more effective, at least in the long run.
The big problem is, who is this archetypical “human?” As a designer, I’ve never seen, met, or worked with a “human.” I’ve never seen that “human” described in the serious usability literature. And I strongly suspect that a “human” tabula rasa in the terms you describe it, does not exist.
So I have some questions about the methods used in this study. It seems to be stacking an ideal mouse implemenation, vs. a less than ideal pattern of keyboard use, for an unrealistic task could be solved in 5 seconds by a skilled editor.
i would agree with that to a point. i dont think things are quite as stacked as you imply. also, characters like “|” were used, literally a one pixel wide selection, which is especially difficult to perform with a mouse. but his results were quite dramatic, like the mouse being twice as fast if i remember right. maybe its not quite that high, but its probably still significantly faster. i believe raskins LEAP system offers a far better navigation/selection than any current methodology (to try it out, download the cvs version of archy from http://www.raskincenter.org, its quite cool), and that is keyboard only. so i do think there is potential for keyboard based interfaces to be more efficient, but it would be quite alien to most users, and would be hard to get adopted as standard.
The big problem is, who is this archetypical “human?” As a designer, I’ve never seen, met, or worked with a “human.” I’ve never seen that “human” described in the serious usability literature. And I strongly suspect that a “human” tabula rasa in the terms you describe it, does not exist.
you are real close to where im comming from, but not quite. im saying that you should alwas be designing around the way the mind works. if you are developing an app that will have a specialized user base, you should still be using the same principals, just adjusted to take into account the additional complexity that would require a specialized program (or significantly different in the case of programs for the handicaped or children). ive used alot of java ides, and idea is the only one ive seen so far that has really gone all out on the usability principals. because of that, its quite a joy to use. our entire team loves it, and says it is the best ide they have ever used. before idea, we used jdeveloper at the office, and the user experience was quite a bit worse. that being said, even though it does a remarkable job of helping a complex process, it still requires more effort to use then say, gedit. considering how much easier it makes coding, the tradeoffs are worth it,
emailing isnt an insanely complex process, so those tradeoffs are no longer worth it. i use outlook at work, i would never consider it in a million years for home. more functionality, resulting in a less usable interface, but not unacceptable considering how easy it makes life.
you are real close to where im comming from, but not quite. im saying that you should alwas be designing around the way the mind works.
The question is, “whose mind?” Of course cognitive psychology should be a big player in regards to design. That has never been called into question. My postion in approaching these issues from a research/design view in psychology:
1: current approaches to “usability” have poor construct validity because they mix up “time to use” and “time to learn.” A saxophone for example is an interface that is highly optimized for use, but not well optimized to learn.
2: there are no simple design paradigms that work for all tasks, all humans, and all domains.
3: talking about designing for a “human” rather than designing for a specfic population is dangerous because it hides critical assumptions that include some humans and exclude others.
Since gedit comes up over and over again, I’ll use that as an example. Gedit makes a large number of assumptions about its user base:
they can use a computer input device.
they can see
they are literate (4th grade level?)
they are literate in a language in which text is displayed from left to right.
they have a familarity with the concept of files and search in the context of computer-generated text.
they don’t need much in the way of text formatting features or spell-check
This is only scratching the surface.
“While aiming at simplicity and ease of use, gedit is a powerful general purpose text editor.
Currently it features:
* Full support for internationalized text (UTF-8)
* Configurable syntax highlighting for various languages (C, C++, Java, HTML, XML, Python, Perl, etc.)
* Undo/Redo, with configurable levels
* Loading files from remote locations
* File reverting
* Print and print preview support
* Clipboard support (cut/copy/paste)
* Search and replace
* Go to specific line
* Auto indentation
* Text wrapping
* Line numbers
* Right margin
* Current line highlighting
* Bracket matching
* Backup files
* Configurable fonts and colors
* A complete online user manual”
http://www.gnome.org/projects/gedit/
Gedit’s search function supports regular expression. And unlike VIM, activating Gedit’s plug-ins is a matter of selecting check boxes. VIM is neither easier to use nor learn as compared to Gedit, period.
You say you have conducted usability studies. Well lets conduct one together. Put seven random users before Gedit and another seven before VIM. Given them a 30 minute tutorial. Assign them generic tasks. Measure how long it takes them to get acquainted with either interfaces. Measure how long it takes them to get the task assigned accomplished. Collect feedback.
I just conducted this same test, a lot more detailed, on members off my household. None of them found VIM easy to use, easy to understand nor easy to learn! Most members of my household are very learned and have vast computer experiences. They have all used relatively complex software. Yet, none of them found VIM usable at all. I didn’t even need to teach them to use Gedit. It’s interface is discoverable.
We will continue to disagree because our fundamental understanding of usability is different. I believe usability is about making objects easier to use, period. You believe usability is about making objects easy to use only for a certain group of people. So by your definition VIM is usable, because only a certain group of people can weild it proficiently and effectively. By my definition, it isn’t for the same reasons and many more. I’ve listed the high learning curve, the absurd amount of time it takes to become proficient, it’s obscure discoverability, it’s inability to scale well with more than a few documents (usage wise), to mention a few.
Your peeve against Gedit is that it doesn’t support regular expressions, which I think is false. You also mentioned Gedit doesn’t support many functions you use in VIM, which again were false. However, none of your grievances had anything to do with usability, ease of use and understanding. VIM has serious usability flaws, and so do 90% of applications and objects I use, including Gedit.
Your rebuttal is going be that VIM is targeted at touch typists, geeks and programmers. I’m not buying that either because Gedit is also programmers editor. Yet, geeks, non-touch typists, touch typists, mama, papa, aunt Sue, uncle Joe, me, you and anyone can use it.
mtabb and I are different people.
I think software is written to solve problems. As a coder, I look at things from a problems perspective most often. I believe most programmers do. When I write software, I don’t look at it from how a particular group of users can use it to solve problems, rather, I look at it from how “anyone” can use the software to solve problems.
The users are not the problem. The problem is the problem. The software, I believe, exist to make users solve complex problems. It doesn’t exist to make only skilled users solve complex problem. Computers and software exist to empower users. To make them accomplish things they would never have accomplished without a computer.
My mother is not an accountant. Annually, she needs to balancer her taxes. She has several options. She could hire an accountant to do it for her. She could learn how to do it herself. She could purchase a software, that acts like an accountant, to do it for her.
Her decision was to purchase the software. If the software expects you to be an accountant to use it, it is broken! Software and software designers need to stop making nasty assumptions, and that is much of th problem with VIM. Thankfully, the people who designed the tax software designed for anyone to use. She launches the software it guides her through all what she needs to do, as if it were an accountant. She hits the finish button and voila, her taxes are done!
That’s how software should work and that is designing with usability in mind. Software empowered her to solve a problem without fuss. That’s the ultimate goal of software usability. We, geeks, prefer to argue about trivialities such menu placement, widget choice, programming languages, touch typing, features, power, CLI, GUI, LUI etc. My mother, she doesn’t give a damn! Why should she?
You also have specialized software. Specialized software is software only people in a particular field of knowledge or specialty. I argue that even those should be easy to use by anyone, not just the specialists. The specialists due to his wealth of knowledge regarding the subject matter will be able to accomplish a lot more and wield the software with prowess and power,.but my mother should equally be able to do something with the software even though she knows nothing about the field. The fact that the software is specialized is irrelevant. The fact that anyone can use the software is what matters. What the software does is irrelevant. How hard it is for people, humans, to use the software is what matters.
That’s why people are loosing it over Apple and Macintosh technology today. Grandma overnight can make movies, author DVDs, manipulate images and she says it’s easy. That’s what software should be about. That’s what I think usability is encouraging. And that’s why I disagree with many so cold usability experts who get buried in the details and fail to see the big picture. Once again, usability is making objects easy to use and understand. VIM fails in this regard.
I understand that he appreciates good documentation, but isn’t this carrying it a little too far?
What is your major malfunction? You’re so worked up in this vim troll that you’re now posting over at the Gnome thread – offtopic.
Seriously, get your head checked by a professional if you think that Vim is supposed to be dumbed-down so your grandma can use it. It never will be.
There is no vim problem. Only the problem in your head that assumes that vim should be designed for your grandma. Go use gedit, because people that use vim don’t care that you think it should be like gedit.
You are completely incapable of designing anything for anybody with these ridiculous arguments that vim should appeal to everybody.
I never said VIM should appeal to everybody. And unlike you, I don’t have a reputation for trolling.
Yeah, the rest of the nuts don’t like it when they’re smacked with the truth too.
> […] Yet, none of them found VIM usable at all. I didn’t
> even need to teach them to use Gedit. It’s interface is
> discoverable.
Let me add that this is one of the most important points of usability for me (speaking of whether _I_ feel comfortable with the software, not about _others_). It’s whether the software shows me my options.
I’ll pick up the example of text editors. For me, GUI-based editors are simple to use. VIM is hard to use. On the other hand, joe is simple to use. joe’s interface isn’t that different from VIM, since typing ctrl-k-q isn’t very different from typing :something. What makes joe different is the simple fact that it says “ctrl-k-h for help” without being asked for it, and within that help I can see in 10 seconds how to work with it. Similar for GUI-based editors: Just open the menus and look what’s there. I did the same with VIM, and the results were quite different. Differences that slapped into my face (apart from a nasty keyboard localization bug that made navigation in the help screens difficult):
1. After closing the help screen, the information HOW to get help disappears. Even worse, there’s not even information how to quit the editor at all.
2. The information how to navigate, especially to jump back, is only visible on the main screen, and not in the referenced screens where you would need it.
3. After entering “edit” mode, there was no visible information on how to exit it again.
4. The “overview of the most common commands (I) will use” is a whole screen full off references, each with a full screen of commands behind it. So just the “most common” commands, with which I’ll start editing, number more than 200? I don’t think so. Rather, these are much more than the common ones.
It always comes down to the same thing: I know what I want to do, but I don’t know how to do it, and the program leaves me without *any* clues. In other cases it also happens that I’d like to know *if* I can do something at all. Complaint #4 is the reverse case: The program shows me my options, but they are so many that it’s practically the same as not viewing at the help at all, unless I dig 10 minutes to get the information I could get in 10 seconds with a well-designed interace.
Note that the same problem – the lack of discoverability – as also my greatest problem with (bad) command line interfaces.
Your peeve against Gedit is that it doesn’t support regular expressions, which I think is false. You also mentioned Gedit doesn’t support many functions you use in VIM, which again were false. However, none of your grievances had anything to do with usability, ease of use and understanding. VIM has serious usability flaws, and so do 90% of applications and objects I use, including Gedit.
If a given piece of software does not support functions I need to use on a daily basis, then it is not usable for what I need?
If the functions are there, then where are they? I wouldn’t mind trying out a new editor. But if the functions I need are not available through menu items, nonexistent or existent but hidden and undocumented, then that editor is not usable for my needs.
You also have specialized software. Specialized software is software only people in a particular field of knowledge or specialty. I argue that even those should be easy to use by anyone, not just the specialists. The specialists due to his wealth of knowledge regarding the subject matter will be able to accomplish a lot more and wield the software with prowess and power,.but my mother should equally be able to do something with the software even though she knows nothing about the field. The fact that the software is specialized is irrelevant. The fact that anyone can use the software is what matters. What the software does is irrelevant.
Lets take an example of a specialized software doman: statistical analysis. When I run an anova on a dataset, I’m interested in a set of numbers that are meaningful to me, but not meaninful to someone without a basic grasp of statistics.
In order for the software to be usable for anyone (never mind the fact that all you are doing when you say “anyone” is simply masking your own political assumptions about who the users are), I’d have to put in a whole series of caveats, interlocks, and explanatory text. I’d want to check to see of the data was reasonably normal before hand, explain in detail what an anova does and how to use it, and then explain with the output degrees of freedom, sum of squares, F, and p.
In designing for “anyone” you’ve made it more difficult for the people who need the software to get stuff done. I don’t want software that forces me through a tutorial of picking a test for significance. What I is software that says “anova” and gives me df, SS, F and p.