Forgot your password?
typodupeerror
GUI Software

Software Usability As A Technical Problem 551

Posted by timothy
from the problem-is-that-people-like-different-things dept.
An anonymous reader writes "Let's face it. Poor user interface design is a big problem in software today, particularly in the Open Source world. A recent article on NewsForge addresses this problem from the perspective that software usability is a technical issue that Open Source developers can and should face and conquer, just as we have conquered other technical problems that have stood in our way." (Slashdot and NewsForge are both part of OSDN.)
This discussion has been archived. No new comments can be posted.

Software Usability As A Technical Problem

Comments Filter:
  • Expanding market? (Score:5, Insightful)

    by LeahofRivendell (797671) on Sunday July 18, 2004 @03:45PM (#9732626) Journal
    Isn't this synonymous for saying that the market for computer software has grown so much that all sorts of people are using it?
    • by MasterVidBoi (267096) on Sunday July 18, 2004 @04:17PM (#9732891)
      No. This was a problem even when only geeks used linux. Just because you are a 1337 h4x0r doesn't mean the interface doesn't matter.

      My most recent example? I decided on the advice of a friend to try Fluxbox a few days ago. In fluxbox, pretty much all configuration of happens inside a context menu. Fluxbox was definitly designed for technical users, but that doesn't change the fact that this is *terrible* UI design. Why? let me count the ways:

      - Error prone: if you move the mouse the wrong way, you have to drill through several levels of submenu to get back to where you want to be. Similarly, when you activate a menu item with a submenu, you have to drag the mouse straight across the current menu horizontally until it enters the submenu, then drag up or down to the item you want. If you do the natural motion (drag diagonally directly to the desired item), the mouse will almost invariably cross another submenu first, forcing you to go back and re-activate the menu you wanted.

      - Bad choice of widget for the type of action necessary: Incrementing or derementing transparency levels as a menu item!? It takes ~20 clicks to go all the way from opaque to fully transparent.

      - Slow: In keeping with the previous comments, actually making this menu system work takes time and concentration. Fluxbox devs and users may think they're cool for having 'every option at your fingertips', but actually getting to those fingertips takes longer than if they had brought up a conventional window with sliders and buttons.

      There are a set of utilities that provide conventional GUIs for configuring these things, but they are quite incomplete feature-wise, and suffer from their own ugly interface problems. In addition, you have to restart fluxbox to see the changes. Things done in a preferences panel should take effect instantly, which gives the user the ability to experement easily, giving them, in effect, more control.

      There's been a lot of research done on how menus should work, and submenus really slow users down. A lot. For this reason, Apple's UI guides recommend that under no circumstances should you ever have a submenu inside another submenu, to eliminate this nasty nesting.

      Just because you or I are technical users doesn't change the fact that there are other interfaces for this functionality that are faster and more forgiving.
    • by GCP (122438)
      From the article:

      One of the advantages of open source is its ability to put the consumer ahead of profit.

      This is bordering on nonsense because, though OSS has that "ability", strictly speaking, it certainly doesn't have that *tendency*.

      On the contrary, companies that pursue *profits* are more likely to be interested in consumer usability because all profits come from the consumer.

      What OSS does is put the developer's needs ahead of those of consumers. If there is no profit to be had, then it has to mee
  • by Threni (635302) on Sunday July 18, 2004 @03:47PM (#9732641)
    Ford Prefect: No, but I've got a different name for the problem.

    - The Hitck-Hikers Guide To The Galaxy.
  • Moo (Score:5, Insightful)

    by Chacham (981) * on Sunday July 18, 2004 @03:48PM (#9732655) Homepage Journal
    Software should be designed, not just coded. And interface must be part of the design.

    Personally, i like to ask the users what they want to see. Let *them* draw the screens, then merely implement it. A three-tiered approach is best, where called for. The backend should be design and implemented according toi a decent set of guidelines and rules, and the frontend should be completely designed by the user. The middle teir is where the magic should happen, even using a nasty hack here and there.

    Ultimately the disparity between those who code software, and those who use software is a big problem. Perhaps a recognition of the separate group will go a long way.
    • by BiggerIsBetter (682164) on Sunday July 18, 2004 @04:20PM (#9732919)
      Remember Homer's car?
      • Re:The Simpsons (Score:3, Interesting)

        by geekoid (135745)
        the problem with that, wes they let him engineer it.
        Some of his idea were good.
        Bigger drink holder.
        Better viewability.
        That's Useability stuff.

    • by MooseByte (751829) on Sunday July 18, 2004 @04:41PM (#9733036)

      "Personally, i like to ask the users what they want to see."

      EXACTLY! Sometimes the users don't see the Big Picture and have old habits they want to keep around, but more often in my experience it's some boneheaded developer's choice to squander resources to "improve" an interface without ever actually investigating whether the users will get any improvement at all.

      On my latest project (in-house application) I've actually had to go head-to-head with our senior developer (not a software engineer) over how the interface should look and work, me going to bat for the users.

      The users of the new application want it to look and function in a manner that suits the way in which they need to operate day in/day out. Simple, straightforward. I prototyped it for them and they loved it.

      Our senior developer then told me no, we're going to do it using MegaSuperKewl WizBang crap, something the users were fundamentally opposed to (it would actually tangibly interfere with the way they use the data in production).

      I'm hardly junior myself - 11 years fulltime S.E. - and figured screw it, I'm not going to watch this abomination progress unchallenged. I arranged a meeting between the users, the senior developer and myself. The conversation was hilarious. I asked him to explain to the users how his design would improve their productivity. Let your imagination run wild and you'll come close. The users won in the end, but it was hard fought

      But then the same week I had to argue, yes ARGUE, to store constants to be shared across applications in a common header file. The same fellow argued it would be much easier to hardcode it in each application separately. A heated 20-minute meeting later, I get to store the constants in a common header file.

      I *WISH* I was making this stuff up. My life is a Dilbert strip.

      • I feel for you. (Score:5, Interesting)

        by geekoid (135745) <dadinportland&yahoo,com> on Sunday July 18, 2004 @08:28PM (#9734352) Homepage Journal
        I started working at a company a few years back. When I got there, the developer had written an application to replace the users 'green screen' interface.
        The user where data entry where they never looked at the screen, much less the keyboard. we're talking about 100's of pages a day of entry.

        This software engineer had created an application that was almost completly mouse driven. The tabbing wasn't in any order, you had to use the ouse to drop down to any option, to select were the document is sent to, etc...
        They went from 100's of docs a day to dozens.
        The software engineer always blamed the users, and said what he did was 'standard'.

        I went in, fixed the tab order, and assigned keystrokes to all the options. The same keystrokes that had been used on the previous app.
        It took me a week, when the engineer found out, he blew a gasket. Screamed at me, mostly at my back, since I don't tolorate that behaviour, then up to the Sr. Managment team.
        When I got thir, he had them all convinced that I had broke the app, made it unusable, and it would takes "years" to fix it.
        So there I am, looking at a Sr.VP, a Jr VP, and an HR person. I'm not stupid, I know what they had in mind.
        The converstaion went like this:
        VP: "Did you make all these changes to the application?"
        Me: "yes"
        VP: "did you consult the engineer?"
        Me: "yes, he said that the mothod they were using was a 'standard'"
        VP: "I think you may have stepped out of bounds"
        Me: "excuse me, I need to use your phone."
        [Calls the data entry manager]
        "hi brenda, I'm here with some VP's, can I put you on speaker phone?"-"Great"
        ME: "Brenda, what was the user average per day for document input before the new system"
        Brenda: "About 700"
        ME:"And what was it last month?"
        Brenda: "about 80"
        Me: "I see, and what was it last week after the new changes went in?"
        Brenda: "I haven't finished the report, but I'd guess about 700"
        Me: "Thanks Branda, that what I needed."

        The VP excused me. later i the week I got a promotion to fill the former engineers position.

        The point of this story? User interface is for the user. Give them what they need, to do what they want.

        You should hire me, we could fight the good fight together. ;)
    • Re:Moo (Score:5, Insightful)

      by Jerf (17166) on Sunday July 18, 2004 @04:52PM (#9733110) Journal
      Let *them* draw the screens, then merely implement it.

      You think developers know nothing about usability? That is nothing compared to users ignorance.

      Your suggestion, while noble sounding, is a recipe for a design where every whim a user ever had is encoded as a button that does just that, nothing more, resulting in a Million Buttons design.

      Users are moderately competent at designing an expert interface but utterly incompetent at designing a beginner interface. (So are most developers, so that's not a horribly user-hostile thing to say.) And note I mean moderately literally.

      The problem is, first and foremost, that people need to understand what usability is. Here you are with a +5 comment on Slashdot and you seem to think its just a matter of drawing screens. You evidently have no clue. It goes way beyond that. It is a matter of making software easy to use.

      What is Usability [useit.com]? "We Don't Need Usability, We Already Listen to Customer Feedback" (at the bottom) [useit.com].
    • Because they almost universally don't know what they really need. Asking them to draw screens is great - but don't take it as gospel.

      Instead you need to understand that Feature requests are symptoms of goals. If you follow up a particular feature request or screen widget with 'Why' you'll be able to design a UI that actually meets their needs, instead of something that they think will meet their needs.

      ps developers shouldn't design UI either. That's why we have user researchers, information architects,

  • A good book (Score:5, Informative)

    by Chairboy (88841) on Sunday July 18, 2004 @03:48PM (#9732660) Homepage
    A great book on the subject of the importance of software usability is Set Phasers on Stun: And Other True Tales of Design, Technology, and Human Error [amazon.com]. The title sounds funny until you read that it comes from a story about the infamous Therac-25 where a victim (who was killed by the device) was quoted as saying 'Captain Kirk forgot to set his phaser to stun'.

    It's a collection of 20 or so stories about where human factors problems caused injuries and, in many cases, death. Poor documentation, unclear designs, and poor handling of expected user situations (for instance, the reactor technician being pinned to the ceiling by a control rod because there wasn't a safety stop to prevent supercriticallity) is serious business.

    There's more to usabillity and human factors then just 'that guy is too stupid to use linux', it can literally be the difference between life and death.

  • by StateOfTheUnion (762194) on Sunday July 18, 2004 @03:51PM (#9732691) Homepage
    I'm not an active open source community person (just a user) . . . but I have to wonder if the open source community attracts the kind of people typically needed to create excellent interfaces. I'm talking about people that are into ergonomics, spatial perceptions and relationships for desingning interfaces e.g. psychologists, product designers and the like. These are the kind of folks that come up with familiar and intuitive interfaces and design button layouts for consumer products.

    • The OSS community is fragmented, and values "do it yourself" too highly. Developers don't ASK for designs (other than skins and icons), and they ignore any interaction designs you offer them. I'd like to see that change, but honestly, I see little hope. There are very few people who can both design for the user AND implement the design.
    • I'm not an active open source community person (just a user) . . . but I have to wonder if the open source community attracts the kind of people typically needed to create excellent interfaces.

      It doesn't. I'm an architect and I regularly observe UIs that have no sense to them whatsoever. Open Source acts usually as a meritocracy and I've never found a coder who was willing to redesign his entire application because the UI sucked. It's not a chicken and egg problem (as other posts around seem to indicate) since the UI always comes last.

      I once considered starting a project that designed application interfaces for tasks that were needed in hopes that some coder would come along behind and actually write them. (I had a great idea for a clock that doubled as a date/location/world time zone applet.) But we have no influence. UI is considered like the body molding tacked on to American cars half way through a model's life to re-energize sales. It's never considered as an integral part of the design the way someone Porsche does.

      • by StateOfTheUnion (762194) on Sunday July 18, 2004 @05:46PM (#9733444) Homepage
        This is what I was afraid of when I posted the original post . . . Personally I get the impression that a lot of open source folks create great applications for themselves or their peers . . . few seem to want or to know how to write applications for the average joe.

        Perhaps there is an unspoken rule in the community that "easy user interfaces" = "simplistic programming" and perhaps that causes one to lose points in the open source "meritocracy"?

        I really like your idea of designing interfaces for tasks and then developing the code to support the interface next. It implies that the user's need is defined first by the design of the interface. This locks the programmer into coding in a way that meets the user's need exactly as specified by the UI. It's a shame that didn't take off . . . But perhaps that doesn't leave enough creative freedom for the programmers to feel the project is "fun" enough to work on.

        • by dbIII (701233)
          I really like your idea of designing interfaces for tasks and then developing the code to support the interface next
          Not such a silly idea - the Palm Pilot design started off as a block of wood and a pencil, then the actual device was developed to fit the form factor of the handiest sized block of wood.
    • I think there are plenty of people with those skills who would like to help out. The issue is that they would need to learn to code and become familiar with the internals of the project before they could actually change things as systems are done currently.

      My feeling is that the useability issue will be solved once UI implementation doesn't require any significant coding. At that point, users with ideas about how UIs should be done will work on projects.
    • Yes, I'd say it definitely does.

      There are already a lot of replies to this post saying "no definitely not, OSS developers are all elitest ignoramuses" because it's easy to sound insightful when criticising, but really what they're saying doesn't stack up. It might have been right 3 years ago but the improvements made since then have been staggering.

      A lot of software has been rewritten or redesigned with usability being core. Example: grip [nostatic.org] was deemed a lost cause as far as UI went, so Sound Juicer [burtonini.com] was written instead. XMMS was deemed fundamentally flawed so Muine [gooeylinux.org] and RhythmBox [rhythmbox.org] were written. Gnome has adopted a pervasive HIG and while it may have a few rough edges still it's arguably more consistent than both Windows (hands up if you read the Windows HIG - thought not) and even Apples (brushed metal or aqua - what mood is Steven in today?).

      Today, if you want, you can get software that's had well thought through usability. That doesn't mean everybody uses it, but it's certainly available to those who want it.

      Now, there are some big remaining usability issues in free software but these tend to be structural/architectural. For instance Linux software installation is frequently very difficult and it's not easy to solve without a great deal of engineering [autopackage.org].

      On Windows the GIMP user interface isn't anywhere near as good as on Linux, despite the GIMP 2 itself making great strides over the 1.2 release in absolute terms, the different (arguably worse) Windows WM model and UI paradigms aren't accounted for and there aren't enough Win32 Gimp developers to give Gimp/Win32 an excellently integrated UI. Or at least, not rapidly.

      This is more a side-effect of the Gimp being most popular on Linux and the core developers all using Linux though, rather than any fundamental insight into the nature of open source. I've seen some pretty crap ports to Windows UI from commercial companies as well - for instance, the laughable QuickTime 4 which not only made zero effort to integrate with the host operating systems UI but also committed quite a few usability sins like the thumbwheel.

  • by Anonymous Coward on Sunday July 18, 2004 @03:56PM (#9732728)
    The author alludes to the real problem with usability and open source when he comment about egotistical mailings on the newsgroups.

    Too many open source developpers think of themselves as GUI experts. Until developpers are prepared to give up their egos and admit that while they may be shit-hot kernel coders, they know jack-shit about GUI development, open source will be stuck with poor usability. Unfortunately everyone seems to have their opinion on GUI development, and somehow believe that their opinion is right, despite having no training whatsoever in usuability engineering (does this remind you of how everyone is a 'pop psychologist', and a 'pop computer language expert'? -- it should).

    Until developpers understand that GUI development is hard, and that it's also a science with reputable metrics, and until GUI developpers are put on the same footing as other developpers in projects, open source will continue to have poor usability.

    Apologies for being so harsh on the open source world, but that's the reality of it, and we need to face that fact.

    • Somebody mod this AC up, please. He is stating a simple fact, which most coders will admit - most coders can't design UI. Is there proof of this? Not exactly, I guess. But I know in my experience that I'm so into the architecture of most technology I use that I have very little idea anymore of what "hard" and "easy" are for a regular user. When a friend/coworker comes to me with a problem, I'm frequently surprised at the problem's existence at all. The solution to me seems intuitive. Yet at the same time, I

  • Usability (Score:5, Interesting)

    by Jim_Hawkins (649847) on Sunday July 18, 2004 @03:56PM (#9732730)
    I like this quote from the article:

    Here's an example: Konqueror, KDE's file and web browser, has a menu entry called "smbUmount." I don't need a laboratory with video gear to figure out that this is nearly impossible for non-hacker users to understand.

    Exactly. Submit it as a bug. This is the first thing. Many of the people who work on OSS projects realize that there is a usability problem. However, nobody wants to do anything about it. It seems that many developers do not consider usability issues to be a defect in the software. As a person who is *very* interested in usability of software (part of my degree), I have to disagree -- issues with usability is a MAJOR defect. It's the reason that many people will not turn to Linux/OSS options. They are scared by the command line. They don't like it when menus in one program do not match up with menus in others. I can't say I blame 'em! (Well, I like the command line, but that's a byproduct of me being a nerd.)

    As a backup to my previous statement, I am constantly submitting usability bugs to projects when I find them. However, I am constantly ignored. WHY? There are so many things that could be improved upon and made easier so it's more appealing to the users. Why do you think Microsoft products do so well? People recognize them. They know where stuff is. There's no guesswork needed.

    And, yes, some OSS projects do this very well. Mozilla products (Firefox, etc.) are very well designed. There are minor usability flaws, but nothing that isn't easy to figure out.

    Personally, I would love to sit down with a team and work through usability issues. I would love to have someone actually show some interest in fixing these problems. However, it seems that, too many times, these issues are discarded for ones that are more technical. And, of course, the usability issues will come up again later. It's a pretty vicious cycle that needs to be stopped. If only someone were willing to do it.

    (BTW - I realize I could code these changes myself, but I do not have the necessary skills to do this. Otherwise, I would.)
    • Re:Usability (Score:4, Insightful)

      by Quasar1999 (520073) on Sunday July 18, 2004 @04:34PM (#9732996) Journal
      I'm a software developer, I work on commerical software. What you propose is great, lets fix the usability problems, and then worry about the technical 'behind the scenes' problems.

      The problem is, that there are many cases where a seemingly minor UI change to the program would downright destroy the backend. For example (and it's a crappy one, I know, trying not to overcomplicate it...) Take a look at how the clipboard works. You can copy one item of infromation on it at once, and take one item off at once. As an end user, I don't understand why I can't copy text from notepad on it, then copy an image from paint, and then paste the text I had into Word, and paste the image I have back into paint. Obviously all the changes needed would be to know what I want to paste. Problem comes when as a programmer I now have to figure out what to paste where. Text into notepad, that's easy... but what about Word... now what, image or text? Okay, lets ask the user... oh wait, I can't, because I'm not able to do any UI in another program (hypothetically here...)

      Yes it can be solved, but from a user point of view, it's minor, and from a programmers point of view it is damned complex and not worth the trouble. Let the user do two copy operations, instead of me having to write and debug thousands of lines of code that is trying to assume what the user wants (and the user will bitch about if I get it wrong anyways). Add to that most OSS developers are doing this for free, and are not going to want to rewrite their backend just for a seemingly minor UI change, which isn't going to make everyone happy, just a few people who complained.

      What some people find intuitive is complex for others... there is no happy median... there will always be UI's that are not liked by some... there is no perfect UI design out there... and very few people willing to try and find it, especially for free.
      • Re:Usability (Score:3, Insightful)

        by Planesdragon (210349)
        You DO realize that the whole "clipboard problem" was solved, and solved in a very elegant and clever fashion?

        When there are subsequent copy operations without pasting, move the buffer to a new file and display a UI to select items from it.

        It's actually a great example. You don't give users what they want--you figure out their problem, and then come up with the best solution for it.
      • Re:Usability (Score:4, Insightful)

        by Ilan Volow (539597) on Sunday July 18, 2004 @06:33PM (#9733734) Homepage
        The problem is, that there are many cases where a seemingly minor UI change to the program would downright destroy the backend.

        And that's precisely why we usability folks advocate designing the UI at the *start* of the development process, so usability is there from the get go and programmers won't have to re-write zillions of lines of code.

        Unfortunately, designing UI before writing code is seen as heresy by the Unix Culture that dominates Open Source, often being referred to as a "proprietary" development methodology. And this is one of the big reasons why Open Source usability sucks.
      • system versus apps (Score:3, Insightful)

        by bcrowell (177657)
        I think your example of the clipboard is an important one, because it touches on the interface between the system and apps. In my view, most of the most severe usability problems in OSS are system problems, not problems with applications.

        I just gave my father a Linux machine as a present. He is not a computer ignoramus. He's a lawyer, but he used CP/M for years, and is at least conversant with the idea of using a command line. The biggest problem he's running into is that I gave it to him configured for 8-

  • by Anton Anatopopov (529711) on Sunday July 18, 2004 @04:01PM (#9732781)
    We will never get usable software. Very few CS courses make their students study cognitive psychology, or design, or anything else in the 'creative' area of science.

    Your average linux-using developer thinks that everyone else is as smart as he is, and that command line interfaces are a good thing. The GUI is seen as a fisher-price interface for retards.

    We need to get rid of this way of thinking. Software should be like a vending machine. You press a button, and it does exactly what its supposed to.

    Linix and Windoze have set back the cause of usable software about 20 years!

  • by stonebeat.org (562495) on Sunday July 18, 2004 @04:02PM (#9732785) Homepage
    i speak this from experience: there are 2 kinds of good graphics designers: 1) those who have a real job; and 2) those who work a starbuck (or other coffee shops) Those who have a real job, make way too much money to care about OpenSource stuff. And those who work at coffee shops don't have enough time/money to spend on OpenSource stuff. Both of these types don't have time to write HOWTOs on good User Interface design.
    • by 0x0d0a (568518) on Sunday July 18, 2004 @06:27PM (#9733700) Journal
      Graphic designers generally suck at user interface design.

      User interface design is wildly different from graphic design. As a matter of fact, there are probably more industrial designers that would do a better job of doing software user interface design than graphic designers.

      I'd say that a lot of awful websites out there were due to people with traditional publishing and graphic design experience trying to apply old knowledge to the Web and failing.
    • [graphic designers] who work at coffee shops don't have enough time/money to spend on OpenSource stuff.

      Like they have enough money to keep up with Adobe and Apple? The designers I know are bummed out that they can't afford the software they were trained on in school. Introducing your favorite graphic designer to free software would be the biggest favor you could do for them.

      Oh yeah, doing a little free design work is one way for an up and coming designer to get exposure. They don't need to write howtos

  • Recommend-a-newbie (Score:4, Interesting)

    by tezza (539307) on Sunday July 18, 2004 @04:04PM (#9732800)
    I think that people on the project need to volunteer friends, wives, parent to accomplish the user tests.

    This is the secret to open source stuff: drawing on the community skill. This method is just in a non 'programming-skill' oriented fashion

    If you get a Chilean developer to have his grandpa, who has no stereo vision, have half a look at it, then there'll be lots more important feedback, at least after Babelfish has done its work.

  • by StateOfTheUnion (762194) on Sunday July 18, 2004 @04:04PM (#9732803) Homepage
    When we design systems for plants we typically involve the users . . . like for a compactor, the users demanded that two separate buttons be pressed to engage the machine and the buttons must be held down and must be located about 1 yard apart.

    Why? Because then to operate the machine, each of the users hands had to hold down a separate button making it nearly impossible for the user to inadvertently reach into the machine while it was running.

    At first I thought it was a silly thing to do that would insult the operator's intelligence (who would be stupid enough to reach into a compactor while it was running?) But one of the operators confided that it was a great idea because after being burned out from working a couple of double shift days in a row, he didn't want to loose his hand from a simple operational oversight.

    The operational interface was well recieved because we gave the users ownership in the design process. I think that the same should apply in designing software UIs.

  • by halo1982 (679554) * on Sunday July 18, 2004 @04:07PM (#9732830) Homepage Journal
    I've tried to switch over several times, and I just can't do it. KDE and Gnome get better and better, but they are still so different from the Windows I've been using for the past 14 years. I always have the same problems: I can't find things, wizards don't work properly forcing me to go to HOWTOs and the command line/conf files, and theres not enough integration between the window managers and X. I'm quite technically competent and I get better and better with Linux everytime I try it, but for the average user or your mother/grandmother there is still so much work to be done.
    • by theCoder (23772) on Sunday July 18, 2004 @05:17PM (#9733249) Homepage Journal
      What you're talking about isn't a usability problem per se, but an interface difference. And you're right -- Linux and Linux programs are different from Windows. KDE is similar, but it's not the same. And it will never be. Some things will always be different -- either because of design differences or because Windows just does the wrong thing. And that's not a bad thing either.

      For me, the best way to really learn Linux is two get a second computer and put Linux on it (if you're really adventerous, put it on your only computer, but I wouldn't recommend that). Don't dual (or as I call it "duel") boot, because you'll always fall into the trap of "I know how to do this in Windows, so I'll just use that". There's still that temptation with two computers, but IMO, it's not as bad since you still have the Linux one up to use. Gradually, you'll learn more and more about Linux and how it operates (it actually is fairly logical and intuitive -- just not the same as Windows).

      You may want to use something like Putty [greenend.org.uk] to ssh to the Linux computer from Windows and use both at the same time. You'll learn about Linux while using the more comfortable (for you) Windows GUI.

      One other thing to remember -- you can't hurt the Linux computer while you're not root (unless, as root, you give your user account permission to hurt it). So don't be afraid to poke around (especially in places like /proc) to learn more.

      Personally, I don't think Linux has as many usability problems (at least not in general) as people claim. After all, most Linux softare is OSS, and most OSS developers actually use the software they're developing. So, the developers are the users. In that case there is tremendous user feedback and interaction in the development of OSS. It may not be usable for everyone (it may not even be usable for most people), but it is usable for someone. For example, gcc is a very difficult to use program. In fact, most developers rarely execute it directly, except for very simple compilations. Usually, the gcc command line is built by make through a Makefile (at work, we use imake to make exceedingly complex Makefiles from Imakefiles). Some compile command lines can be dozens of terminal lines long, and would be difficult to type in by hand. But gcc (and other compilers) are powerful tools intended only for experts. They really aren't intended for average users, and thus don't need to be usable for them. But they are usable (or usable enough) for developers, and work exactly as developers want.

      I think most of the perceived usability problems with Linux (and KDE/Gnome/etc) are because of different expectations by the users. KDE and Gnome are certainly very usable (I only run Linux at home now). But different expectations lead to this perceived "crisis" in usability that can apparently be fixed (I'm not sure it can ever be completely addressed). While some tools could use improvement (especially integrating with hardware), there are a lot of tools that do have good (or at least usable) interfaces.

      Anyway, sorry for the rant :)

  • by fishlet (93611) on Sunday July 18, 2004 @04:13PM (#9732865)
    I am a developer myself, so this post is in no way meant to offend developers. However it's true that developers (generally) do not see things the same way that most users do.

    When i ponder what makes Microsoft so successful (aside from the questionably legal business practices) is that their company is not ruled by the developers but by the PHB's of this world. Microsoft invest considerable effort into researching what people are actually doing with their computers. Say what you want about them, they are actually pretty good about listening to their customers when it comes to features. By contrast, Linux developers often concentrate on scratching thier own itches which ultimately only appeal to like minded individuals. I could list several things right now that are not easily possible in Linux right now.

    I write software for a small company, and we are very blessed to have a very technically less-literate person on our staff. He is our functional expert and he gives us a lot of great feedback on our UI's. Open source projects should never underestimate the value of such a person.

  • by Gldm (600518) on Sunday July 18, 2004 @04:15PM (#9732876)
    Is it just me or are video games way ahead of other apps on user interface? These days most people can pick up a game and given the general type (fps, driving, rts, rpg) have a pretty damn good guess at the interface. It's not that the game authors have agreed on a standard interface for each genre, it's that they've figured out the things that frustrate new gamers the least so they enjoy the game more with less manual reading. When was the last time you had to read a game's manual to actually jump in and play it? I mean just the basic playing around, not the detailed stuff.

    Why haven't desktops and apps incorporated advances from here? Let's take an old RTS, say Command and Conquer. The designers figured out how to make a USEABLE virual desktop that DOESN'T SUCK! You can navigate around this huge screenspace and the radar keeps track of where you are. Also, how do they handle things similar to launching apps? Well there's a sidebar full of big easy to distinguish one click icons, and a set of tabs at the top that switches what set of icons is displayed by type (units, buildings, etc). Seems pretty easy to figure out to me. Want to quickly get back to the thing you were last working on? You can designate hotkeys with ctrl+number an then pressing the number jumps back to it. Some RTS's have seperate select and change focus but all seem to use a similar hotkey system.

    One of the things that keeps me happier with windows than linux is the at least moderate effort at standardized interfaces. Most apps of simlar types have similar interfaces and I don't have to relearn all the terms that someone decided to use THEIR names for. Every time I see a custom media player or something with this horrible neo-future interface on windows I cringe, because it's such a bad idea. I don't want to spend time relearning how to use a media player just so it can look cool, I want to watch media with it. On linux it seems every app suffers from this "I want to look unique" urge, or a complete lack of asthetic design whatsoever. So your choices are pretty and confusing or ugly and confusing.
    • Is it just me or are video games way ahead of other apps on user interface.

      I think it's just you, but let's take a look.

      Let's take an old RTS, say Command and Conquer. The designers figured out how to make a USEABLE virual desktop that DOESN'T SUCK! You can navigate around this huge screenspace and the radar keeps track of where you are.

      The goals of C&C are not that of a desktop. You can do C&C-style virtual desktop stuff by just having an enormous virtual desktop under xorg -- move your mous
  • by graiz (647982) on Sunday July 18, 2004 @04:19PM (#9732914) Homepage
    There is no UI that will ever satisfy 100% of the people who use it. In a closed source OS you sacrifice UI flexibility for consistency. Not everyone is happy but the UI can be built consistently to satisfy novice users and intermediate users.

    In an open source world everyone can customize the software to suite their needs so you sacrifice Consistency and Usability for Flexibility. Advanced users are happy but novices loose out.

    If you want to improve usability in Linux or other open source projects you need to put someone in charge of the UI. Linus is the de-facto gatekeeper of the kernel but the UI seems to be fair game for just about anyone.

    (A Former MS UI Guy)

  • Consistency (Score:3, Insightful)

    by zaphod_bee4 (752609) on Sunday July 18, 2004 @04:30PM (#9732973) Homepage
    The real key to Good UI design is consistency. Many open source projects have unfinished features, differing UI conventions and throw the user curve balls. This can be expected for testing and non stable releases. However any release labled stable build or 1.0 and so on should have a clear consistent UI and NO I repeat NO unfinished features.

    This alone would help greatly. When a user downloads a stable build binary he should never see a menu that doesn't work or a radically different approach to a task that doesn't fit with the rest of the app. CVS snapshot builds and testing builds are a different ballgame.

    Also Stable builds need to be clearly marked as such and stressed as the "polished" version.
    • Re:Consistency (Score:3, Insightful)

      by 0x0d0a (568518)
      Many open source projects have unfinished features, differing UI conventions and throw the user curve balls. This can be expected for testing and non stable releases. However any release labled stable build or 1.0 and so on should have a clear consistent UI and NO I repeat NO unfinished features.

      Frankly, I've found commercial software to generally be worse off with v1.0 releases. There are lots of pieces of OSS that slowly climb the ladder towards version 1 for a *long* time.
  • by G4from128k (686170) on Sunday July 18, 2004 @05:00PM (#9733174)
    What apps and OSes need is scalable UIs - UIs that scale as the knowledge level of the user grows. A total novice, non-technical, casual users should be just as comfortable and productive as a hard-core, 80-hour-per-week developer. This has not happened yet because there are two distinct camps in UI development. Profits in the mass market drove closed source, mass-market software to create useability on the low-end. The natural interests and abilities of its contributors drove open-source to create useability at the high end.

    The biggest challenge to scalability is creating inuitive metaphors or abstractions between the human interface (i/o modalities) and underlying digital constructs that does not get in the way of the power-user. Apple's early OS effort were great for the novice, but derided by more experienced users - the UI was not scalable in the upward direction. In contrast, Unix/DOS/CPM was fine for power-users, but it arcane command interface made it not scalable in the downward direction.

    I suspect that the answer will be concepts like Mac OS X that combine GUI and CLI elements. But even OS X is not as scalable as one might like because it is really an intuitive Apple GUI grafted on to a separate powerful *nix CLI core. Although novice Mac users can "graduate" to the command line, the transition is not smooth -- using Finder does not teach one how to use ls, cd, mv, cp, rm, etc. Rather than being scalable in a continuous sense, Mac OS X offers interfaces at two different scales - the intuitive GUI and a separate power-user CLI.

    Perhaps future OS/app UIs will be truely scalable -- early GUI use will seamlessly teach the user and help them slowly become more powerful users. Developign scalable UIs will require contributions from both novice-oriented usability experts and power-oriented developers. It will require forethought and coordination so that the disparate elements of the system are "consistent" without being inflexible.
  • by Animats (122034) on Sunday July 18, 2004 @05:19PM (#9733262) Homepage
    That's not an approach, that's a pep talk that says nothing. "Usability is a relatively new matter for us". Like, hello, Mac programmers have been doing this for two decades. We need to hit the "I am l33t because I can use a command line" people with a clue stick.

    Ten things you can do to make your program at least tolerable for end users:

    • No funny key combinations. Repeat, no funny key combinations. Everything must be accessable through the menus. Yeah, I know you want to be able to bind any control key combination to any function. Don't. It doesn't really speed up use anyway. Read Apple's old studies on this. People blank out on the 500ms they're thinking about the control key combo. And never, ever use keyboard toggles that don't have a permanently visible state on screen.
    • If it's undoable, you don't need a confirmation dialog. If it's not undoable, you need a confirmation dialog. Make it undoable if at all possible.
    • Distinguish clearly between severe and non-severe errors. "You are about to change your font to sans-serif" should look very different than "You are about to permanently delete all your files".
    • The user should never have to tell the computer something it already knows. This is basic, and routinely violated in the Open Source world. The user should never have to fill in a blank when the computer can find out what goes in that blank. Offer a choice if necessary. Yes, much of this comes from UNIX's crappy approach to system administration. Work on that.
    • If you need a database, use a real database. Flat files are so 1970s. Databases work today. The most troublesome apps in computing, BIND and Sendmail, are both database apps with a bad homebrew database. Provide for database validation and recovery.
    • Anything that can get itself into a bad state must be able to get itself out of that state. No more having to delete "XUL.mfl" every time Mozilla screws up. Anything with cached data must get this right.
    • If you try to be smart, make sure you're not being stupid. Try entering data into an OpenOffice spreadsheet. If you have something like "12 VDC" somewhere in your spreadsheet, and you type "1", it fills in "12 VDC". Which you have to erase. Every time. Now go try that in Microsoft Excel. Microsoft's wizards will fight you once, but if you override them, they give up.
    • Modal dialogs should be short and clear. They consist of a statement of the problem and a suggested corrective action.
    • Get the subtle stuff right. Grey out the options you can't use now. Show in the menus whether something is off or on.
    • Be rigorously consistent about how things appear to work, even when it's more work for some cases.
    • I actually would like to add one more bullet point to this list, which Microsoft in particular seems to get wrong a lot.

      Have command buttons that describe an action, whenever possible! "Save" and "Don't Save" is one hell of a lot better than "OK" and "Cancel"! If you name the buttons after actions, the user doesn't even have to read the dialog most of the time.
  • Usability resources (Score:4, Informative)

    by darkpurpleblob (180550) on Sunday July 18, 2004 @05:28PM (#9733316)

    From the article:

    But If I want to learn how to write phrases understandable by users or what colors to use that still allow color-blind people to use my software or how to best name categories for efficient navigation, I can do nothing but listen to people's opinions in the matter. Where is the open source community's pool of facts and knowledge covering usability issues?

    Bulls***.

    There are numerous books and resources on usability. For example:

  • How boring! (Score:3, Interesting)

    by tchernobog (752560) on Sunday July 18, 2004 @05:38PM (#9733388)
    It has to be the tenth article about OSS and usability that I see in a couple of months (and at least two were mentioned here on ./).

    Listen, as someone pointed out: if there's a usability problem, fill in a bug report. This is OSS real force.
    We are all a bit lazy. If something don't fits your needs, fill in a bug: it is like black ink on your dress, you HAVE to have it fixed, or what sort of programmer are you?! :)

    Moreover, I think that's still the same old story: who says "command line is good enough for everyone, and if you don't like it, it's a problem of yours" versus "mouse is beautiful, why should I use that keyboard? It'll bite me, if I touch it!"

    Well, I'm for: keep them both. For example, I noticed that in Kdevelop you haven't key accelerators when debugging your code. This is a problem for me, so I'll fill in a bug report, and I'll point it out.

    See Emacs: you have menus, you have toolbars. Me, I spent some time learning the keyboard shortcut, and I never ever touch the mouse anymore! That's fine for me, and that's fine for the newbie, because the UI is there to help him.

    As always, FS is about freedom, expecially to choose. And since we are here to get better, if you want it "your way", speak with the right people (the devs), don't just complain! OSS is about community, take part in it, don't just sit on the bench criticizing.

    (Sorry for the awful english)
  • by master_p (608214) on Sunday July 18, 2004 @06:02PM (#9733545)
    Everybody says how difficult it is to design the proper gui. I think that if a little common sense is applied, then guis can be functional and pretty at the same time. Here are some tips:

    1) don't clutter things closely together; provide the proper spacing between elements of the gui. KDE/Gnome severely violates this rule.

    2) use soft colors. Harsh colors make the user tired very soon.

    3) Use bitmaps and labels that have a clear meaning to the user, not to the developer.

    4) Be consistent with interfaces. The File menu should be there to open/close files; Ctrl+S must save the current document etc. There are lots of established conventions that work really well.

    5) group similar things together (similar by concept).

    There are really good sites with lots of examples of what or not what to do. But I don't think it is extremely difficult to make a GUI. All that is needed is plain common sense. I am a programmer, but people never complained about my GUIs.
  • I would like to throw out a couple of observations here:

    I have found the very best programs are those built into two parts; namely, the command line part and the GUI wrapper part. Take a look at the SGI Indigo Magic desktop utilities and programs for very good examples of this. Of particular note is their software manager application. The command line is 'inst'. It is text based and can do everything from a terminal. The GUI portion is 'swmgr'. It simply wraps around 'inst' and presents a good interface.

    The nice thing about this is the choice the user has. Running remote on low bandwidth, or want to script something? Use the text only portion. Perhaps a number of advanced operations need to be performed, such as new installations, or upgrades that break the GUI. Also use the text version.

    Have a nicely running box and just want to organize and manage some software, perhaps install something new. Use the GUI and perform the task with ease.

    Don't like the GUI? Well, write another one that does what you want in ways you want it to. Nothing breaks as a result and you don't have to talk with the people who wrote 'inst' in the first place.

    Sure there are exceptions, like OpenOffice.org, so lets set those aside for a moment. I am not sure how well this approach would work for a large application like this.

    However, most of the little programs people want to use are easily done in two parts. Doing this splits the work in that the geek developers can get the technical part done. Nothing really gets in the way of their innovation because they can leave the equaly hard GUI development to others.

    Distributions, and corporations can build GUI interfaces that make sense without having to directly involve the core developers of the project.

    Seems to me this fits in with both UNIX and FS/OSS core ideals.
    • The command-line + GUI part however won't work much good for anything more then rather trivial stuff. Command-line tools are just far to inflexible for this, making it hard, slow or even impossible to get correct data out of them (ps auxw output is outdated already as it gets printed, find ... | xargs ... won't work for filenames with newlines in them, many utils output 'ascii art' (statusbars and such) stuff that one has to filter away or even interpret, etc.).

      Sure for some of these things there are worka
  • Maturity (Score:4, Funny)

    by BorgCopyeditor (590345) on Sunday July 18, 2004 @08:10PM (#9734266)
    From the article:
    Our backends have matured.

    They have a pill for that sort of thing now, you know. Technical problem indeed.

  • Speaking Heresey (Score:4, Insightful)

    by coaxial (28297) on Sunday July 18, 2004 @08:48PM (#9734444) Homepage
    Now you may want to call me a heretic, a troll, and a baiter of the flame, but listen my brothers and sisters to what I am about to speak none the less.

    Many have you say, "Linux isn't any harder to use than windows/mac." That my friends is a lie. Still many more of you say, "Linux is almost there!" Again, I say that is a lie. I know! I have been using Linux since 1994. It has suckethed in the past, and it sucketh today. Has it improved, yes, but it is still quite bad. While I can only speak for the state of GNOME, I can say that it is actually becoming harder to use in the name of useability. How you ask? Why the file chooser dialog has no filename entry. Support for typing filename or URIs, things that have been included in everyone of the filechoosers ever developed is hidden under arcane keystrokes and even then lack the support of 2.4. Abilites that distinguished the GNOME desktop from others have been removed in recent years inorder to make it "more intuitive", which is merely a synonym for "poorly cloned in the broken in the way of Redmond".

    The linux user experience is one of confusion and inconsistency. Applications don't look the same. Applications don't behave the same. Applications having improper interface criteria ("Edit|Preferences"? Why would I look for configuration details in the same menu that I use copy, paste, and search the text in?) Installing packages leaves them unconfigured, or configured with broken defaults. Too many times, the user is forced to enter commands at the terminal, or edit cryptic configuration files. Things that should be automatic aren't.

    I postulate that this situation could be be resolved with a two pronged approach. First, a distribution that doesn't try be the One True distribution with every conceivable package in it. It should have one desktop environment, one office package, one media player, one emailer, et cetra. In short, one and only one of every software type. This simplifies package configuration, and enables almost complete autoconfiguration.

    Secondly, all the user applications must be tightly integrated. There shouldn't be a mixture of say Gtk, GNOME, wxWindows, and Motif applications. All applications be of the same toolkit and of the same desktop enviroment. This will help make the user experience more cohessive. Unfortunately this isn't enough either. There has been developments in some of the required software that seem to be actually detremental to the user experience. Either a new enviroment will need to be developed (*bleh*) or perferably patches against an existing enviroment/applications developed. (Think Ximian, only not based on a cult personalities.)
  • by i-Chaos (179440) on Sunday July 18, 2004 @10:39PM (#9734909)
    The biggest reason why Windows has a definite edge over Linux in terms of adoption is because of its user interface for configuration. For example: In Windows, if I want to add something to my startup sequence, all I have to do is add it to my aptly-named Startup folder.

    Poor user-interface design was what kept me away from using Litestep as my Windows Shell replacement I couldn't just drag things where I wanted them, but instead had to go in and edit some configuration file. Expose users to settings in different graphical menu systems - that's what they were designed for.

    I myself know that I have a great sense of usability when it comes to wetware-software interaction (I, Robot reference ripped). It's unfortunate that I don't have all the necessary skills to help a project. Would love to do some free design/consulting work for a project, though, if I was taught how to do the whole design process.

  • by Animats (122034) on Monday July 19, 2004 @12:04AM (#9735348) Homepage
    One of the biggest problems with the Unix/Linux world is an obsession with "configuration". Most users could care less about "configuration". Most of the things you can "configure" should either be automatic or on-demand.

    Printing, for example. You should never have to "configure" a printer. When you try to print something, you should be offered a list of available printers. The system should find them. If the system doesn't have the tools to find printers, why should the user be expected to do it? Maybe you have buttons like "look for more printers", or "ask neighboring machines for help finding printers". But the user should not be typing in IP addresses or installing "drivers".

    Yeah, this takes some programming work. But it saves the user work. That's the idea.

  • by nathanh (1214) on Monday July 19, 2004 @03:24AM (#9736061) Homepage
    A recent article on NewsForge addresses this problem from the perspective that software usability is a technical issue that Open Source developers can and should face and conquer, just as we have conquered other technical problems that have stood in our way.

    FLOSS is a really good development model when the software can be incrementally written in a distributed manner. Linux works because the majority of work in the kernel is in maintaining the drivers; small and independent chunks of code. Debian works because of packages; without packaging, Ian says Debian would never have succeeded.

    Projects that require a big bang from a small group of people do sometimes occur with FLOSS but it's much rarer. And I think those projects are far less successful. The last example I can think of was the DRI; it took a small team of very dedicated people to invest a lot of effort before there was a result. The barrier to entry (the knowledge required to contribute) with the DRI is very high so progress is slow. It's not possible to just jump in and fix something small. You have to spend ages learning how it all fits together.

    In my mind, the way to solve the "UI problem" with KDE and GNOME is to figure out how to break the problem into smaller independent chunks. Then just sit back and allow the distributed model of development take over. 1000s of programmers each contributing 10 lines of code has the same coding power as 10 programmers contributing 1000 lines each but it's only possible if the problem can be broken up into 1000 independent chunks.

    Maybe UI design isn't one of the problems that can be broken up that way.

  • by jandersen (462034) on Monday July 19, 2004 @04:04AM (#9736190)
    People keep talking about 'intuitive' as if they knew what it was; and most of the time it turns out that it is just another word for 'cool'. A lot of things would be a lot better if application designers would concentrate a little less on making the 'perfect' Fisher-Price look or implementing their own, private 'vision' of how the world ought to function. We have enough primadonnas as it is.

    To achieve usability, I find that it is much better to focus on a few things:

    1. Simplicity. It helps a lot if the application simply does what it says on the packet. Please note that simple is not the same as 'not advanced' - it just means that it does what you expect it to do. An electric drill is simple, even though it is a complex piece of mechanics - a Swiss Army knife with toothpicks, saw blades, compass and that pointy thing you can't figure out what is, is not simple, even though it is just some bits of metal stuck together.

    2. Extensibility. When you have learned the basics it should be possible to add things in one way or another. Again, the function of an electric drill can be extended little by little as the owner gets more competent and/or wants to do more.

    3. Discoverability. It shouldn't be necessary to learn-by-guessing a new ideographic script in the form of icons. This means there has to be documentation and a help system - and preferably one that isn't limited to some moronic context sensitive help. It's amazing so often you need to do something out of the immediate context.

    4. Configurability. Quite contrary to common belief, people actually want to be able to customize and configure far more than developers want to let them. Yes, in the first few hours too many options may be intimidating, but very soon people get over this and want to make changes. Some applications manage this by providing more than one configuration interface - one simple, where the system sets a lot of defaults, and another where you have full access.

    Some might think that these things conflict with each other. Like, how can it be simple, if the user can configure a million parameters? Well, provide sensible defaults, of course, so people are not forced to learn everything at once - but another thing to remember is, that a simple tool is also one that is adequate for the task - if you have to configure something that by nature is complicated, then the tool has to give you access to that complexity. As Windows so abundantly illustrates, it can get very complicated if the configuration tool is inadequate; and in Windows you often come across the sort of tool that is too simple, but at the same time cumbersome to use, where it would have been so much easier if only the configuration has been kept in a simple text file, and you could use a simple editor.
  • by pandrijeczko (588093) on Monday July 19, 2004 @04:12AM (#9736207)
    Why do we have this same old argument raging yet again and why is the finger of "lack of usability" always pointed at Open Source?

    The perception that all software should be intuitive and 100% usable the moment you unwrap the shrink-wrap is an incorrect one & has been created as a result of heavy over-marketing by commercial software vendors in order to generate more sales.

    Sure, I accept that if Joe Bloke buys himself a digital camera, he wants to load some software from a CD on his Windows machine, plug his camera into the USB port and start downloading his images to his PC for editing.

    But the fact is that the majority of normal users still believe the hype that when you buy a PC, it's no different to buying, say, a TV where all you do is just switch it on and it works. There is no mention by the PC salesman of having to perform regular defrags, keep the OS updated, update virus checkers, install firewalls, etc.

    Just because a piece of software takes some time to familiarise oneself with, does not mean that it is unintuitive - if anything, results are far more rewarding when one has put in a little effort to achieve them.

    The UNIX/Linux command line philosophy, for example, is frequently targetted for "lack of usability" complaints. However, the fact is that taking the time to understand what programs are on a UNIX system and how to bolt them together in things like shell-scripts means that some very repetitive and boring tasks can be completely eliminated very quickly.

    The Open Source movement is not about trying to compete with, or displace, Microsoft - it is simply about doing the right thing which means sticking to open standards that all of us can enjoy (rather than closed standards that we pay a subscription for). Therefore, the creation of cohesive GUIs for software is not the prime concern of the OSS community, albeit that the same are receptive to feedback from users of their software.

    Commercial software vendors have to make profits which means listening to their users and rushing their software out to the marketplace - therefore, in the case of Windows software, those same vendors will use the Windows GUI libraries for their software, cutting down on development time and fitting in with the Windows "look & feel".

    I'm not denying that OSS software is viewed by some as "difficult to use" - but this should be taken into context that OSS demands a degree of responsibility and time commitment from each user to learn how the software works and to feed back into the developers what the user perceives to be problems with the functionality or layout of the software.

1 Mole = 25 Cagey Bees

Working...