Stories
Slash Boxes
Comments
Search

News for nerds, stuff that matters

Slashdot Log In

Log In

Create Account  |  Retrieve Password

Improving Software Usability?

Posted by Cliff on Wed May 24, 2006 10:45 PM
from the UIs-that-users-won't-mind-using dept.
Software
kevin_conaway asks: "Software usability is one of the hardest things to get right. Writing good, usable software is the holy grail of software development, yet few developers give it more than an afterthought. As a professional developer, I delight in writing software for other developers but shy away from writing an interface that the end users will see. What resources/books are recommended for improving your Human Computer Interaction (HCI) / software usability skills?"
+ -
story
This discussion has been archived. No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.

Improving Software Usability? 50 Comments More /

 Full
 Abbreviated
 Hidden
More
Loading... please wait.

  • here are a couple: (Score:5, Interesting)

    by yagu (721525) * <<yayagu> <at> <gmail.com>> on Wednesday May 24 2006, @10:47PM (#15399119) Journal
    Don't Make Me Think [amazon.com] and The Design of Everyday Things [amazon.com]... two of my very favorite books.

    "Think" is more web centric, but has many tips and insights, and is an accessible read cover to cover.

    "Design" is a bit more pompous, and I don't agree with all points, but I give it high marks for making you take a different look at things you'd always taken for granted (Microsoft asked me a question at my interview from this book, btw).

    A few more thoughts: don't confuse usability with user responsibility. If a task if tediously complex, it's going to be difficult to design a thin elegant easy-to-use interface. For example, photoshop can be amazingly obtuse to use, but there's a reason. Overall I give photoshop a "5" (out of ten) for their ergonomics, but I give them a "10" for what their application can do. I consider it partially my responsibility to climb that learning curve to do real work in digital graphics.

    On the other hand, the unusable applications out there are infinite. My favorite example is Windows Media Player. I still have to figure out what to do just to play a CD with WMP. (And what's with the disappearing window?)

    (Here's an interesting non-software example of horrible design: my parents have an RCA TV, not that old, but not HD. It has Videos 1, 2, 3 input, Cable/Air input, and VCR. There's a "SETUP" button on the front panel that lets you change the signal input from Cable/Air to VCR (or something like that), but the only way you can get Video 1, 2, or 3 is by tuning the TV channel to 91, 92, or 93 respectively. Until I found the manual and got to page 60 I was convinced the TV was broken.)

    My favorite example of transcendental usability: Google.

    (Some runners up: Picasa; Amazon.com (one-click), wish list, etc.)

    (Also, I am opposite as to who I like to write for: I cringe when writing for other professional software developers, they're some of the biggest whiners about "what should be". I do however delight in writing software for clients. If you do it right, it's a genuine high.)

    • Re:here are a couple: (Score:4, Interesting)

      by vanyel (28049) * on Wednesday May 24 2006, @11:38PM (#15399318) Journal
      I consider it partially my responsibility to climb that learning curve to do real work in digital graphics.

      For the stuff that is technically advanced, I agree, though it should still be intuitive for someone who is technically advanced in the field.

      Photoshop and Illustrator are classic examples of what I consider bad user interfaces, because things that should be simple and obvious, aren't. For example, cropping a picture (Elements actually fixed this one): you drag the border as you'd expect, then you want to fine tune it. Bzzzt. You had to use some combination of shift-alt-click-something to adjust it, or do the add/subtract from selection thing.

      On the other hand, Elements has broken something simple and basic: resizing images. Something even earlier versions of Photoshop did well. No more: "resize/image size" just changes some parameter it saves that says how big to print it, and the only options you get are printer units. OK, fine, leave "resizing" to the printer people, there's a canvas size option, but no, that is effectively a crop if you shrink it and adds blank space if you expand it. How about the scale menu item, that should work. Nope: "transformations should be applied to layers. do you want to make the background a layer?" Despite the word "should", your only options are to cancel the entire operation or to let it make a layer out of it. And I don't want to resize one layer, I want to resize the entire thing!

      Sorry, but crappy non-intuitive user interfaces are a hot button, and I just recently tripped over this one. In my mind, the entire point of a GUI is that you shouldn't have to RTFM to do the basic functions of the application.

      Just because a tool is powerful doesn't mean it has to be non-intuitive...

      • You said, "Photoshop and Illustrator are classic examples of what I consider bad user interfaces, because things that should be simple and obvious, aren't". I agree.

        I did, by the way, say, "Overall I give photoshop a "5" (out of ten) for their ergonomics...". Yes, I still consider a steep digital graphics curve my responsibility to climb, but I'm not letting Photoshop skate completely. ;-)

      • IIRC, you have to click "Resample" in the Image resize dialog to actually resize the image in pixels. Not exactly intuitive, but it is there. I think PSE4 gets a lot right in the UI in general, but it has some rough edges.

        • Re:here are a couple: GIMP? (Score:4, Insightful)

          by vanyel (28049) * on Thursday May 25 2006, @11:10PM (#15407440) Journal
          I went and fetched the latest gimp, and it looks like it actually supports both X's now, that's an improvement, and there are things I like about it, like the markers on the edges showing where your pointer is.

          The main thing I've always disliked about GIMP is that it's too busy and stuff is scattered all over. It's a bit overwhelming for someone starting with it, a bunch of icons that really don't mean much unless you already know what they mean or spend a lot of time mousing over. Since I've used lite versions of photoshop for a decade now, it wasn't worth the effort of jumping the hurdle.

          On the other hand, it's really not much different than the little side menus photoshop puts up (which is another change I'm not sure I like in Elements, building them all into a frame around a hole where your image goes), so I'm not sure why they're more daunting.

          Maybe it's just inertia... Now that I just spent the bucks on Elements a week or so ago, I guess I'll try using Gimp again ;-)
    • "Overall I give photoshop a "5" (out of ten) for their ergonomics, but I give them a "10" for what their application can do. I consider it partially my responsibility to climb that learning curve to do real work in digital graphics." This reminded me of my trials and tribulations with 3D graphics applications. Maya allows you to do some amazing stuff. Arguable, it's much more obtuse than Photoshop. 3D Studio Max allows you to do just as amazing stuff - but it's more obtuse than Maya. Silo3D, on the other
    • My favorite example is Windows Media Player. I still have to figure out what to do just to play a CD with WMP. (And what's with the disappearing window?)

      Err... insert CD, wait for the dialog box to appear, click on "Play this CD in Windows Media Player", click OK. Doesn't seem hard to me.

      The disappearing window bugs the hell out of me, though. As does all the crap it does. I started a media player... why would I want it to load a web browser in it?

      It's so annoying that I usually use media player classic
    • Me too with respect to those books. I read them in graduate studies and found them both helpful. They are both very easy reads. In addition, anyone technical doing web design would benefit from a basic study of print design topics... how to align things, set up good contrast, using proper fonts and all that.

  • Interface design != Software design (Score:5, Insightful)

    by teh moges (875080) on Wednesday May 24 2006, @10:52PM (#15399134) Homepage
    As much as everyone here loves to create their own programs and websites, for professional jobs, it must be known that those that create the software should NOT be responsible for designing the interface. Its a challenging field. While almost everybody here can create a good design without thinking, creating a great design is alot harder. Its the same with everything. Using certain software, ANYONE can create a good website. It takes skill to create the great ones though. Using certain software, the company I work for has their interns creating press releases. They work, but they aren't great. Anyone can design a logo, but theres a reason the big companies hire design artists. The very same is true in interface design. If you are worried about it and your budget can afford it (it should be budgeted for anyway), hire an interface designer.
    • Yes, and that's why they have people called UI designers.

      That being said, just because someone is a developer, does not mean that they cannot do things to make their UI better.

      For web development there are a few things you can do to make your site better and a book I read called "Defensive Design for the Web" by New Riders, is actually a pretty good book and a must read IMHO for anyone doing web site design, expectially if you are doing a web site that provides more than a personal home page. It goes ove

    • As much as everyone here loves to create their own programs and websites, for professional jobs, it must be known that those that create the software should NOT be responsible for designing the interface.

      While this may be true in some sense, things will still rely heavily upon implementation architecture. Good user interface is NOT about a pretty front end, but about a logical hierarchical control layout and a minimalist featureset. On a PC, a highly usable program should be possible without a single piec
  • http://developer.gnome.org/projects/gup/ [gnome.org] This is definitely worth a read. Many people who are good programmers aren't necessarily good at user interfaces, or worrying about how people will interact with the software. That is an area that open source software really needs to improve on, both in efficiency in usability, and in aesthetics.

    • Re:Gnome Usability Report (Score:4, Funny)

      by julesh (229690) on Thursday May 25 2006, @06:06AM (#15400275)
      If I didn't find Gnome software so damned difficult to use, I'd probably be a little more interested. But they don't even seem to be able to make an open-file dialog box that's intuitive and easy to use, let alone a complex application.
      • I couldn't agree more. Trying to tie usability and gnome together is like saying oil mixes well with water...

        Gnome usability makes me puke, this socalled "linux desktop" does not remotely do what anyone would want a desktop shell to do - hence when we are talking about gnome, we should talk about useless instead of usability.. *sighs*.

        KDE now, here we have a consistent user interface, usability is high and you can actually get it to function as you would like - heck, this even goes a long way for Windows (X

    • Re:Gnome Usability Report (Score:2, Interesting)

      by Anonymous Coward
      Kind of ironic, then, that usability is the thing Gnome does worst.

      They concentrate entirely on complete newcomers, people who've never used a computer before, and try to make everything simple for them. Unfortunately, this completely ignores the fact that the majority of people in the developed world have learned just enough about computers to blunder through Windows - which means that Gnome, by deliberately making things work totally differently (the "spatial" thing is a great example), actually makes it

  • Making data export difficult or expensive (Score:3, Interesting)

    by Freaky Spook (811861) on Wednesday May 24 2006, @10:58PM (#15399161)
    I can't stand software that makes it extremly difficult to get your data out of, that is one of the worst things about a lot of software.

    Developers deliberatly giving people software, then making them "upgrade" to a premium version if they want to export their mail, documents, photos, or anything else should be shot on site!

    Easy import and export of data should be the one thing your product should be easy to do, aggrevating your customer because you chose to take their data then try to extort it out of them definatley does not go well for easy usability.

    • I can't stand software that makes it extremly difficult to get your data out of

      It sounds like you're pretty bitter. Do you think software inherently comes with import/export functionality and these developers take the time to hide it from you, just so they can extract more money?

      Import/export functionality takes time. Time costs money. It is also something that most users don't care about. Sounds like a premium feature to me.

      BTW, If import/export functionality happens to be especially important to you, it w

    • Developers deliberatly giving people software, then making them "upgrade" to a premium version if they want to export their mail, documents, photos, or anything else should be shot on site!

      Or off site, if they don't offer on site support.

  • The best resource for making sure your software is usable is to watch people use it. While large companies can afford professional UI designers and formal usability studies, even a humble F/OSS developer can do some simple UI testing.
    When I'm working on software that is intended for users who are not developers or otherwise computing professionals, I usually try to get a regular user to sit down with my software for a half-hour or so and I watch them use the software. Generally, I just say something along the lines of "hey, wanna do me a favor? play around with this program for a bit and tell me what you think". Then watch over their shoulder. Generally this is a good way to get a list of what sorts of things are poorly placed "how do I...?", things that are confusing "what is this?...", features that users will like "can I ...?" and it's a good way to start finding bugs that only a user will discover.
    A few tips that I've found doing this include
    If any option is unavailable then it should be obvious WHY it's unavailable.
    No matter how obvious your icons are, they should ALWAYS have text with them.
    Avoid dialog boxes as much as possible
    If you make your program look too much like another program, then you better make sure it looks and works exactly like that program. In other words, either stick completely with the standard way of doing things, or do it completely different. If you take some common UI element and tweek it, then you'll just confuse users. Menu bars tend to be the most common violators of this.
    Understand color. A lot of applications throw colors around willy-nilly, if you are going to use color then study up on color theory and learn what colors go together, what colors are calming, etc.
    • As an addition to this when someone asks how to do something, even if it's clearly documented in the manual the simple question "How do you think it should be done?" can be very enlightening. Often the users are better UI developers than programmers are.
      • Often the users are better UI developers than programmers are.

        I might say that each user brings a different perspective to the discussion, and maintaining perspective on the UI they're writing is a skill that is very difficult for most developers to maintain.

        Restates, I disagree that the user is a better UI designer, but instead, they can help developers get outside their normal "deep in the guts" perspective. I intensely dislike the assumption that developers are "bad at UI development". Most are actuall
        • As a developer I'm not going to say that I'm a bad UI designer. Actually quite the opposite, I regard myself as a good UI designer. That doesn't mean that I can't accept advice even from users because as you say they bring a different perspective (and most notably a different skill level).

          I just said that they "often" are better UI designers for rhetoric effect, it wasn't designed to be looked at with pedantry.
    • Extending on from this - Don't forget about accessability. A correctly placed well named button is only half as good as a correctly placed well named button with a shortcut key. If your application is more than just a use-occasionally tool, and is something users are expected to use on a regular basis, ensure that they have many (standard) ways of accessing each function. Also although you think you've found a really nice way to render dialogs, or buttons, or toolbars, think about whether partially sighted
      • I definitely agree that Windows Media Player 10 (and below) were pretty crappy UI wise. But I'm still debating about WMP 11 (as I just started playing with the beta). It actually does a lot of things fairly well--like grouping by CD (with an image of the CD), although this would be nicer if you could change the way you view the CD's so that it would be more like picking a CD off of a CD rack (especially since scrolling through 100+ CD's can be tedious in the way it's currently layed out. Of course, on the o
    • One important thing to remember which comes before you can do any actual usability testing is that you need to know about the potential users for the product. You have to bear them in mind during the design of the program; miyako touches on this by mentioning making your application look like other applications and what this means, but there is more to this. If your application is closely linked to another (a Firefox extension, maybe), then the users will be users of the other application and will have expe
      • I read The Humane Interface and it's an interesting book. Raskin had some odd ideas, but the book gives you a different view on interface design beyond the standard menu, toolbar and mouse layout.

        I think his concept of a zooming interface is basically what iPhoto, Picasa and Photoshop Elements use in their browse modes and it works pretty well there.

  • I quite liked (Score:3, Informative)

    by LukeRazor (960201) on Wednesday May 24 2006, @11:10PM (#15399207)
    I recently read "About Face 2.0" I found myself dis-agreeing with some of the details and felt there were a few ommisions but the definitions of software was sound

    Also Joel on software has a great book excerpt online to get you in the mood

    About face link [amazon.com]
    Joel book excerpt [joelonsoftware.com]
  • There is information [wikipedia.org] about him on the web, and he has a few good books such as "Notes on the Synthesis of Form".

    Why do I mention him? To a certain extent, especially to users of software, the interface IS the product. The interface is the only way they will ever use any of the features, so if something is hidden, hard to find, hard to use, or designed to be misused, then that feature will never be of any prominence.

    So remember to design the interface around your users and your problem. Your program is literally the interface that sits between the users and the problem, a bridge as it were.
  • Designing from Both Sides of the Screen [amazon.com]. Worked really well for the project I worked on, and it's a great process and implementation book.

  • Usability Studies are a must (Score:5, Interesting)

    by jchenx (267053) on Thursday May 25 2006, @01:35AM (#15399608) Journal
    I think too many companies focus just on heuristic evaluation [wikipedia.org]. That's basically paying a UI expert to tell you what to do and what not to do. A lot of companies won't even hire a usability expert, instead relying on their own engineers to "read a lot of books" and try to wing it.

    This is bad.

    Just like how software engineers should not be trusted to test their own code, they should also not be trusted to do "good usability". I'm saying this as a software engineer, who also has a Masters in usability engineering and has been in the field for a few years. Too often I'm surrounded by fellow engineers who think they know what's best for the user. Also, they'll claim that a certain design is best because it also makes for a "clean UI" and "clean code design". Then we sit users in front of the application, and all hell breaks loose.

    Don't do this. Spend the money to hire a good usability expert, and have THEM perform proper usability studies. Good usability is NOT necessarily about a "clean UI" or "clean code". It's about a product that people know how to use. After this is established, it is then up to the engineers to make sure the actual implementation itself is clean, extensible, un-cluttered, etc. Not the other way around.
    • I couldn't agree more. As a systems analyst and systems engineer, the first thing I do is spend at least a week working with and observing the people (workers) that will be using whatever I design. After I have the semi-final product, I do the same thing again, this time observing and talking to them about the program. Sometimes a rewrite of the UI is required and I don't have a problem with it on my end. If they are unhappy with the product, they won't use it or will use it reluctantly which is unaccep

    • I think too many companies focus just on heuristic evaluation. That's basically paying a UI expert to tell you what to do and what not to do. A lot of companies won't even hire a usability expert, instead relying on their own engineers to "read a lot of books" and try to wing it.

      This is bad.

      But it is a start.

      In an ideal world we'd all be at stage 5 or better [useit.com]. Unfortunatly, some of us are still at Stage 1 [useit.com] and spending 50% of our development time just fighting political battles simply to stop developers

  • See http://wyoguide.sf.net/ [sf.net], it can be used with any programming language with any framework on any platform. So far it's the only guide which gives advice in a cross-platform fashion, has sample code and if you happen to use C++ a demo sample for use as your starting code base.

    O. Wyss
    • I glanced at your guide and then I glanced at your Desktop. Two quick suggestions:

      On screenshots for a desktop usable by "everyone" the first screenshot should ABSOLUTELY NOT BE A TERMINAL WINDOW... My grandma wouldn't use a terminal. Oh, and maybe not have the login as 'Root'--although that's a lesser issue since it's just a screenshot.

      The other thing is that you may want to consider switching from wxWidgets or GTK+ or whatever you're using to Qt. It has more controls available to it and its considerab

  • A few simple guidelines (Score:5, Insightful)

    by c0d3h4x0r (604141) on Thursday May 25 2006, @01:52AM (#15399644) Homepage Journal

    Just by following a few simple common-sense guidelines, you can drastically improve the usability of any given software:

    • Simplicity: keep things as simple as possible. Fewer options/settings/etc means less to have to figure out. If you must provide an option for something, supply a reasonable default. The user should never have to configure a bazillion options before being able to just use the program.

    • Sane hierarchical organization: The human mind can only processes and deal with the external world by grouping, categorizing, and thinking of a collection of items as a single "chunk". So sanely organize options in hierarchical menus; sanely organize navigation into a tree-like path; etc.

    • Direct manipulation: users always expect to be able to direclty manipulate an on-screen object by clicking directly on it, dragging it, etc, so design your UI that way. (Example that violates this: a listbox with items in it, with buttons underneath that must be clicked to act on the selected item, rather than allowing the user to right-click on the item itself to get a pop-up menu.)

    • Data transparency: there should always be a way in the UI for the user to clearly see the information they want organized in the way they want it, and it should never be a mystery to the user where some calculated field came from or how it was calculated.

    • Terminology: keep technical lingo out of the program's UI as much as possible, and make all text and phrasing clear to non-technical users. Whenever an error occurs, present a dialog that clearly explains the nature of the error and which also suggests a course of action that might rectify the error.

    • Real-time on-screen feedback: when a user performs an action, they need immediate feedback to know whether the action succeeded or failed. Real-time responsiveness is super important. If a user-initiated action will take longer than about 0.1 seconds to achieve the ultimate result, then you need to put up a suitable progress indicator that updates itself responsively as the operation proceeds. If the user clicks on something and they don't realize the system is just busy processing their request, they are likely to click on it again and again without realizing the first time succeeded. (Example that violates this: you launch an app from the Windows XP start menu... you don't hear the hard drive churning or see a hard drive light because you are remoted in via Remote Desktop... no visual on-screen cue is given that the app is actually loading up... so you try to launch it again... in the end you get 2 or 3 instances of the app).

    • Don't assume user expertise: always assume your user knows NOTHING about computers.

    • Scenario-based design: don't merely dump a bundle of functionality on the user; give them a program that guides them through all the steps needed to solve their scenario. It's the difference between handing someone a graphing calculator and handing them a math expert.

    • Users won't read, and shouldn't have to: users don't read text -- it's a proven fact. Nor should they generally have to. For most people, reading is an unpleasant expenditure of valuable energy and time that could instead be used getting something done. If you need more than one brief sentence in the UI to explain something, then your UI is too unusable and you're just leaning on text (that won't get read) as a crutch. Users should be able to jump in and start being productive with your software without having to read a manual, README file, or any other long-winded explanation whatsoever.

    • And, most importantly:
      • Software model should conform to user model: Always have the program do what the user expects [joelonsoftware.com].
    • Just by following a few simple common-sense guidelines, you can drastically improve the usability of any given software:

      I just read your comment because of two reasons, first it just comes after mine and second because it's just about what I had in mind when I designed wyoGuide (see http://ask.slashdot.org/comments.pl?sid=186617&cid =15399619 [slashdot.org]. But the difference is you tell just common sence while I show how this common sense can be implemented into code. I invite you to look through the guideline and d

    • Re:A few simple guidelines (Score:5, Insightful)

      by isj (453011) on Thursday May 25 2006, @03:12AM (#15399881) Homepage
      Don't assume use expertise

      I am one of the few people that have read the CUA guidelines, and they make at lot of sense, although many of the specific details are now outdated. The CUA guidelines say that you have to first decie if the UI is going to be a standard UI where it has the conform to system defaults and in general user's expectations; or if the UI is a so-called walk-up-and-use UI (such as ATM interfaces). The difference is that the standard UIs have to conform to standards but can contain many features, while the walk-up-and-use UI has to be simplistic and require absolutely no learning, but can break any standard as long as it makes it simpler to use.


      So the guideline should be:

      • Know your users: Don't assume your users have no expertise, but neither assume that they have. Find out. This impacts not only the program UI but also the documentation. If you do not know your users (or the intended target group) then the program is always too simple and to complex at the same time.

    • Re:A few simple guidelines (Score:4, Insightful)

      by Haeleth (414428) on Thursday May 25 2006, @06:38AM (#15400356) Journal
      Just by following a few simple common-sense guidelines, you can drastically improve the usability of any given software.

      You appear to be claiming that the guidelines you quote are universal and apply to every conceivable bit of software. I would beg to differ.

      Simplicity: keep things as simple as possible. Fewer options/settings/etc means less to have to figure out.

      Photoshop would not be a popular program if it only provided the five most common graphical operations and only let you configure three aspects of each. It's successful precisely because it's insanely configurable.

      In other words, while there is indeed a place for simplistic software (witness the popularity of basic photo editing programs that literally only offer crop, size, and red-eye removal), it is by no means desirable for all software to be simplistic. Complex tasks require complex interfaces. Simplistic interfaces limit users to the options you have chosen, and I find it hard to believe that you can imagine all the possible ways a user will want to use your program.

      Don't assume user expertise: always assume your user knows NOTHING about computers.

      You cannot possibly believe this applies to all software. Are you seriously saying that the writers of a kernel debugger should assume their users know nothing about computers?

      Scenario-based design: don't merely dump a bundle of functionality on the user; give them a program that guides them through all the steps needed to solve their scenario. It's the difference between handing someone a graphing calculator and handing them a math expert.

      If a mathematician asks for a graphing calculator, you think they should instead be handed another mathematician?

      Yes, simple tasks should have simple interfaces. Anyone should be able to answer emails, browse the web, write letters, keep an address book and diary, and print photos from their digital camera.

      But that does not mean that simplicity should always be prized over functionality. Some things in life are tough. I've never driven an 18-wheeler: I would not expect to be able to sit down in one and take it across the continent. I've never filed a lawsuit: I would not expect to be able to waltz into a court and win a billion-dollar case. Why should I expect computers to be any different? If users won't read manuals, that is the users' problem.
  • If you want to that the basic principles, simply go with the Apple Human Interface Guidelines. Yeah I know, sometimes Apple do weird things too... But the first part of the book (the first 3 chapters) contains the basic information you need to create a good interface, totally platform-agnostic. It's been my guideline for years, since the System-Finder times. *sigh* back then the interfaces were easy and there was no brushed aluminum to foil the day.

    http://developer.apple.com/documentation/UserExper ience/Co [apple.com]
  • Read Nielson's essays [useit.com]. Then do what they say. Specifically conduct usability testing in the manner he prescribes - anything else is a waste of time and money.
  • For example, we tried several times to start using Ajax (forgive me for saying it) to make interfaces more like desktop applications.

    Users completely rebelled. The general sentiment was, "Why doesn't that bring up a page when I click on it?"

    The importance of "usability" is overstated by people who make money parroting it.

    Yes, simplicity and obviousness are important. Just don't confuse those objectives with usability as it is now sold.

    Usability starts with a set of normative values that most users acc

  • The Inmates are Running the Asylum [amazon.com] (disclaimer: Amazon link provided as a courtesy and is not a referral link to the best of my knowledge)

    This is a good book by the designer of VB that has a nice model of user-oriented design and some pretty interesting case studies -- design of airplane entertainment units, scanner software, and others.

  • There needs to be a way to immediately cancel something if I want to bail out. Examples of this not working are in Safari. While a webpage is loading, I can click the cancel button, and it will not register until several seconds later. Sometimes when the button is depressed, it then takes 5 seconds to actually stop. Or in Final Cut Pro, canceling a render can take 10-15 seconds. My computer is by no means the fastest, but how hard is it to make a cancel button that actually works? How difficult is it to sim

    • First mistake... Thinking that reading a book and using the HCI (Human Computer Interface) buzzword will improve the user experience of your software.

      I disagree. There is definitely low-hanging fruit for usability improvement. Certainly procedural changes in the design process and testing is the way to go to have a truly usable UI, but that is not always possible in every environment. Just reading a book can allow a designer to avoid some of the most common snafus and provide them with a better framework

All trademarks and copyrights on this page are owned by their respective owners. Comments are owned by the Poster. The Rest © 1997-2009 Geeknet, Inc.