Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×
GUI Software Programming Technology

User-centric GUI Design Explained to All 355

Posted by michael from the bears-repeating dept.
TuringTest writes "The webzine User Instinct carries an article on Usable GUI Design showing that good user interfaces are not beyond the means of free and open software development: 'This article presents five key points of user interface design [...] that any software developer should be able to use.' In related news, The Economist writes against software complexity in an interview to MIT's John Maeda, PhD in interface design. See also OpenUsability, a project for testing user interfaces in a bazaar-like model. The specifics of UI design in Open Source projects has been previously debated on Slashdot."
This discussion has been archived. No new comments can be posted.

User-centric GUI Design Explained to All More

User-centric GUI Design Explained to All

Comments Filter:

  • I have doubts... (Score:5, Insightful)

    by gowen ( 141411 ) <gwowen@gmail.com> on Thursday November 25, 2004 @11:51AM (#10918218) Homepage Journal
    ... about User Interface research. My DVD, VCR, TV, CD, CD-writer, portable mindisc player are all laid out completely differently, and -- despite similarities -- behaved subtley differently from one another (If I hit Pause-record, what do I press to recommence recording? Is it Pause or REC?)

    My car has a completely different set of layout for dash controls from my girlfriends. The gears are in different places on the stick, and the feel of the clutch is completely different.

    And yet, after a short period of familarisation, I find I can cope pretty well with all of these things, as can everyone else I know.

    • Re:I have doubts... (Score:5, Funny)

      by nomadic ( 141991 ) <`nomadicworld' `at' `gmail.com'> on Thursday November 25, 2004 @11:55AM (#10918240) Homepage
      My car has a completely different set of layout for dash controls from my girlfriends.

      Wow, multiple girlfriends? One disqualifies you from slashdot, with more than one you should hand in your UID.

      And yet, after a short period of familarisation, I find I can cope pretty well with all of these things, as can everyone else I know.

      Go try Blender [blender3d.com], then come back and tell us that...
      • My car has a completely different set of layout for dash controls from my girlfriends.

        Wow, multiple girlfriends? One disqualifies you from slashdot, with more than one you should hand in your UID.

        I'm just impressed that he's so familiar with the "dash controls" of all his girlfriends. Please post links to any good manuals!

    • Re:I have doubts... (Score:2, Insightful)

      by curne ( 133623 )
      My car has a completely different set of layout for dash controls from my girlfriends...

      Would you not say, though, that the two cars have equivalent interfaces? What if you had to reach under the passenger seat to push the brakes? Would that not be a difference in design, possibly worse?

      That is what interface design is about, IMO.
    • Yeah, and yet you figured them all out. Imagine that!

      I recall the windows 95 design flaw - the ability to accidentally reduce your taskbar to 0 so you couldn't see the start button any more. Boy did I get a lot of calls from friends and family about disappearing start button. XP finally solved that with the locking taskbar.

      Windows has come a long way since win95 in usability. UI is not an absolute; it's an evolution.
      • Na, my favorite 95 flaw was the ability to close the start button... Toolbar is there, but no start button. It took all kinds of teachers to figure out how it to fix that!

    • Re:I have doubts... (Score:2, Interesting)

      by kaleco ( 801384 )
      Actaully, computer GUI design seems to follow conventions a lot better than consumer electronics. With consumer electronics I always have to fall back to RTFM in order to determine what the product is capable of and how to do it. Also, there are a large number of functions which are only available on the remote control only, the actual unit only or the on-screen menu only, which is very frustrating.

      I regularly use KDE, OS X and Windows XP (my ecclectic home network) and find that a brief period of stumbing

    • Okay, lets move the clutch, the brakes and the accelerator out of order, and to different locations. Cope with that.

      User interfaces must have certain aspects similar or they are confusing. The very fact that you use stickshift puts you far ahead of most drivers who can barely (if they actually do) cope with automatic.

      InnerWeb

      • "Okay, lets move the clutch, the brakes and the accelerator out of order, and to different locations. Cope with that"

        Simple solution: I kart and ride a motorcycle every weekend or so. Now I can switch easily. If you switch the accel and the brakes I'll enter "kart mode" and voila.

      • How about this:

        Let's remove the clutch and double the width of the brake.

        Now, put a person who has always driven a manual (US: stick) into an automatic and unless they are concentrating all the time, they will still check to see if the car is in neutral by trying to move the shifter left and right. Another one (my favourite) is when they go to press the clutch to change gears and press the brake.

        For those who only drive automatics: Pressing the clutch is a natural action and that action is to press it qu
    • Ideally, hitting either Pause or Rec would unpause the recording, similar to how hitting Play or Pause would unpause playback. Some people treat Pause as a toggle operation (because it's On or Off, and since there's only one button for it...), others treat it as a task (you pause, then you hit what you want the VCR to do next). But in that example, there's nothing really preventing one from supporting *both* options, making it intuitive to everyone.

      As for dash controls, you'll find that the iconic interfac
    • My car has a completely different set of layout for dash controls from my girlfriends. The gears are in different places on the stick, and the feel of the clutch is completely different.

      Well, it's not always that simple. Tried driving a left hand drive *and* right hand drive car ?

      Fortunately, the pedals are in the same position otherwise I would have had a lot of accidents.Also the gear layouts for manuals are in the same position too - at least in the cars I've been in. Otherwise I would have been star

    • ...because everyone knows that only complete idiots couldn't adapt.

      Take cars for example...I'm sure most people could adapt if you moved the trottle to the left foot. The "bipedal interface" is obsolete anyways. One only needs a single pedal on the floor for the brakes. I say we should try a hand-operated throttle instead.

      And who's idea was it to arrange the gears on an automatic as PRNDL? They might be easier to find if they were sorted alphabetically--DLNPR. And what's with the antiquated idea of a

  • Jokes aside (Score:5, Insightful)

    by Ninjy ( 828167 ) on Thursday November 25, 2004 @11:52AM (#10918223) Homepage
    I've said time to time again that a lot of free/open source software suffers from not having an ease to use interface. One can argue that functionality is more important than the presentation/interface layer, but seriously, users are more attracted to pretty pictures.

    But it's not just the subject of pretty pictures. Professional software companies may actually spend several subsequent dollar signs into providing a consistent, easy-to-navigate user interface. The trick isn't to show all functionality. The trick is to present the functionality the user needs, in a logical grouping as the users expect it.
    • I'm with you sort of. KDE -> yes - totally too much going on to be a good UI for all but the power user. GNOME is a bit cleaner in that sense. Sit an end user down in front of each computer and they'll figure both out eventually though... Although KDE will take a bit more time to explain.


    • Consistancy is the KEY and has been since the early days of cobol when report and screen generators were designed with consistancy in mind. IMO Apple does a pretty good job with this. It's a big part of what makes an intuitive system intuitive and needs to be approached from the lowest levels (naming and structure within the source) through presentation and the UI.

      • exactly right

        If, for example, the window frame doesn't look familiar, and doesn't have Help in the upper right, and File Save is renamed Keep This...

        Then most people will spend some time wondering whether they are about to get unexpected results. The purpose of using the device (hw/sw) is to accomplish some mundane task (99% of the time anyway). Some UI designers can't resist the urge to show the world how clever they are by doing interfaces in an innovative and new way. WAY bad!

    • The trick isn't to show all functionality. The trick is to present the functionality the user needs, in a logical grouping as the users expect it.

      The trick is to balance a few things: Ease of learning for infrequent users, ease of use for heavy users, easy to customize to meet particular user's needs.

      Predictability is the key.

      • "Ease of learning for infrequent users, ease of use for heavy users, easy to customize to meet particular user's needs."

        Which is why I think computers should know the experience level of the user, and adjust accordingly. Have an OS-wide setting "Newbie, Amateur, Expert". In Newbie mode, OS and applications (who read this environment variable) have Clippy, wizards, balloons, popups, confirmation dialogs, and that other crap. In Expert mode, all the fluff is turned off and your computer no longer treats you
    • I've said time to time again that a lot of free/open source software suffers from not having an ease to use interface. One can argue that functionality is more important than the presentation/interface layer, but seriously, users are more attracted to pretty pictures.

      There is a difference between functionality and efficiency. Making an app with an interface that is common to every other app may make for a small learning curve, but in the long wrong it may be less efficient. Look at commercial apps like

    • Re:Jokes aside (Score:3, Insightful)

      by mydigitalself ( 472203 )
      your point on cost is very valid. although it can be done for cheaper, we just spent short of £10, 000 doing an intensive 18-user usability testing study on our software.

      one thing that is important here is that you do need a usnability expert to coduct the review. of course if you can find one that's willing to work for free for the sake of the open source movement, that's just great.

      another thing is that you generally do have to incentivise the candidates with somewhere around £50.

      outside of

    • Re:Jokes aside (Score:2, Insightful)

      by kfg ( 145172 )
      One can argue that functionality is more important than the presentation/interface layer, but seriously, users are more attracted to pretty pictures.

      But it's not just the subject of pretty pictures.

      Because the command line is an interface.

      Ok, this is actually semi-offtopic, given the nature of the story, but I get a bit tired now and again with the word "interface" being used as a synonym for "GUI," and thus all interface usability research and guidelines being GUI centric.

      User interface 'friendliness'

  • dead already??? (Score:2, Informative)

    by Anonymous Coward
    google's cache right here [google.ca]

  • iPod and iTunes Complexity (Score:5, Insightful)

    by xanderwilson ( 662093 ) on Thursday November 25, 2004 @11:58AM (#10918258) Homepage
    This is probably why the iPod has been so successful. It doesn't have all the features you could hope for (FM tuner, voice recorder built in, Ogg Vorbis support, etc), but it does what it does so well that even technophobes can "get it."

    Part of the Audion Story [panic.com] from Panic software details how iTunes didn't have all the features of Audion, but how they (Panic) had a breakthrough realization that they didn't NEED to have all these great features (that only few people would use) to make a great app.

    Alex.

  • Damn you all! (Score:5, Informative)

    by BenjyD ( 316700 ) on Thursday November 25, 2004 @12:00PM (#10918268)

    Hi, I'm the guy who wrote the article.

    Yes, it's hosted on my 256k upstream ADSL line, which is why I said "Use the Coral cache" in all the story postings!

    Slashdot would also choose the day when I switch to my back up server (K6-2 233), in order to fix my main server, to post this on the front page. I was wondering why it was making that funny noise when I loaded the Slashdot front page...

    Please use the Coral Cache! [nyud.net]

    • Anyone know if the coracl cache is accessible from within the US only? I've never managed to connect to it (times out) from Europe.

    • Mirrors (Score:4, Informative)

      by Card ( 30431 ) on Thursday November 25, 2004 @12:09PM (#10918313) Homepage
      The Mirrordot version [mirrordot.org] and Google cache [google.com] are also available.
    • ...lol...

      You should know better than to give /.ers any kind of reference to your real server. If they get an itch, like lemmings they will follow each other until you fall. Why, that would be like giving your teenage son a house to stay in for a week with stocked cupboards and no adult supervision. Good luck on what you come back to.

      Though I am very sorry to hear that you were sunk.

      InnerWeb

      • You think I posted this here! I don't know who did, but a bit of warning would have been nice.

        It survived the combined attacked of osnews and gnomedesktop, but clearly slashdot is too much.
    • IN THE RED CORNER
      we have a trembling k6-233, never done any harm to anyone, never let you down since the day you purchased it, but worked away slowly processing any task thrown at it.

      IN THE BLUE CORNER
      We have the Might of a front page Slashdot Effect

      Secounds out, Round 1. Ding Ding......

      .....

      Will there be a burial at dawn?

      • Re:Slashdot vs K6-233 (Score:3, Interesting)

        by BenjyD ( 316700 )
        bdr@trillian:~ $ uptime
        17:47:03 up 5:14, 2 users, load average: 0.07, 0.09, 0.06

        Hah! My feeble pipe means my 233Mhz laughs at the Slashdot effect. I'm going to stop posting now and save some bandwidth for readers.

    • Interesting article. While I agree with many of your points, several of them do seem to assume that the user is going to be running applications maximised. I am almost always using more than one application at once (e.g. writing code in and IDE, reading documentation in a web browser. Reading Slashdot in a browser, chatting using a Jabber client. Writing something in a text editor, reading from sources somewhere else), so maximising an application isn't very useful. The maximise button is one of the bi
      • I don't believe that there was an assumption that the user will maximize the apps, there was a point that the GUI should remember its latest state and restart from that state. The browser's back button size example is just an example, I don't think it's a guidline to building browsers.

  • User feedback (Score:2, Interesting)

    by Anonymous Coward
    Part of every software project should be to analyze how the users interact with the software. Using that information, the interface can be tweaked to provide more efficiency and reduce errors. Of course, the customer would have to pay for this but it would probably pay for itself. For example, if a clerk takes two seconds less to input a transaction and there are 100 clerks doing 200 transactions per day, then the company saves 20,000 seconds per day. That's about five hours per day or say $50. That ti

  • False universals & the inevitability of compro (Score:5, Insightful)

    by G4from128k ( 686170 ) on Thursday November 25, 2004 @12:03PM (#10918282)
    Some people love GUIs for the same reason (ease & hand-holding) that others hate them. Some people love CLIs for the same reason (succinct power) that others hate them . Although people like to think there are universal design principles, and there are some, most real world designs require compromises based on the needs and proclivities of a diverse user population.

    The challenge for OSS is that its developers tend create the kind of software that they themselves want. It does not have many developers creating software for a non-developing/non-geek user populations. Thus, OSS will invariably create software in its own image. This is not a "bad thing" unless the only true goal is universal adoption of OSS at the expense of OSS geek-usability.

    The point: you can't please all of the people all of the time. And given the model underlying OSS, it is unlikely to focus on pleasing non-programmers.
    • ### Some people love GUIs for the same reason (ease & hand-holding) that others hate them. Some people love CLIs for the same reason (succinct power) that others hate them

      Usability is really NOT about religion, CLI vs GUI or whatever, its about doing things the right way, placing stuff where it makes sense and not wasting the users time. Sure there is not one true right way, so a lot of good interfaces don't necesarily make a consistend one, but for sure there are a lot of things that simple are done r

    • Your distinction is false (Score:5, Insightful)

      by yoz ( 3735 ) on Thursday November 25, 2004 @01:21PM (#10918769) Homepage
      It's not about programmers vs non-programmers. It's about the person who created the application vs everyone else. And when it's put like that, there's no choice to make. If software hasn't been designed for other people to use, there's no point releasing it.

      The idea that only non-programmers fall victim to usability problems is wildly wrong. The vast majority of usability problems are not about beginners not having enough general knowledge in the field, they're mostly about non-optimal design. Take the example in the original article (you did read it, didn't you?) about search tools throwing up error dialogs when they fail. A programmer is going to get just as annoyed about that as a non-programmer.

      I'm a coder who administers multiple Windows and Linux machines and codes in a variety of different languages. Usability problems piss me off more than most users, because I realise they're the fault of a programmer who just said, "It's good enough for me!"

      The distinction you make - that usability comes down to a choice between two groups of people who fundamentally differ in technical ability - is not only very wrong, it's actively harmful, and the reason why so many OSS interfaces (whether GUI or CLI-based) have such poor usability. The programmer thought he could get away with poor interface design because he was aiming at geeks. What he ends up with is no users.
      • It's not about programmers vs non-programmers. It's about the person who created the application vs everyone else. And when it's put like that, there's no choice to make. If software hasn't been designed for other people to use, there's no point releasing it.

        Excellent point. I know that I've been guilty of this at various times. It's so easy for a person to fall into the trap of thinking that "what is obvious to me, must be obvious to you." Like you, I too get pissed at bad programming because I kno

  • One Word... (Score:2, Insightful)

    by johansalk ( 818687 )

    showing that good user interfaces are not beyond the means of free and open software development

    Firefox

    • Re:One Word... (Score:4, Insightful)

      by MyLongNickName ( 822545 ) on Thursday November 25, 2004 @12:09PM (#10918312) Journal
      Actually, if you read the article, he has a few nits to pick with Firefox.
      • Yeah, I read it, but I thought those comments were pretty dumb. Well, maybe not dumb... but look, a usability expert can be educated and apply usability principles correctly, but that doesn't mean he's right. If you put an artist, a usability expert and a hardcore coder in exclusive charge of a project design, they will each come up with very different monsters. Each of them has only one hammer, and to each of them, the problems of design all look like nails.

        Now, specifically about the comments regarding

        • It would be monstrous to make a huge "back" button in Firefox, just because you click it more. By that reasoning, all buttons should be different size, proportionately to how likely they are to be clicked.

          I don't think that is the implication at all. A few buttons that are clicked a disproportionately large number of times should be made larger. Where you divide the "big buttons" from the "small buttons" is up to you.

          What is wrong with making the whole bar fatter? Is it impossible to redesign the noti

  • User Interface Design for Programmers (Score:4, Insightful)

    by Twylite ( 234238 ) <twylite&crypt,co,za> on Thursday November 25, 2004 @12:09PM (#10918315) Homepage

    An article with noble intentions, but it falls far short.

    To begin with, anyone involved in UI development needs to read Joel Spolsky's User Interface Design for Programmers [joelonsoftware.com].

    From Roe's article:

    Professional UI designers tell us that user interfaces should be the first thing designed when we come to develop an application, and that programmers are incapable of doing this kind of design. They say it can only be done by the professional UI experts; OSS projects don't have access to these kind of people, and therefore can never be truly usable.

    This is like saying all developers care only about performance, and all manager care only about impossible schedules. There are a number of books out there that aim to give developers the skills to design usable interfaces -- in fact some are on Roe's reference list!

    Fitt's law is not the "most basic ... of UI design". Fitt's law has become unreasonably important because UI designers stopped giving users visual cues about keyboard shortcuts. Even my Dad uses the backspace key rather than the back button! Its so much easier. Mouse gestures will also dramatically change the effect of Fitt's law.

    In my experience, the weaknesses of open source UI design are also its strengths: (1) the ability to experiment with new interface metaphores; and (2) the flexibility of the software.

    The more you conform to established metaphores, the more easily you can make your product usable. Creating new metaphores is difficult, and getting them accepted is even more difficult.

    Flexible software typically has a lot of functions and options. The capacity of short term memory [wikipedia.org] is important here: a person at random can remember or concentrate on 7 +/- 2 items at once. At no point should a person be presented with more than 9 items in a selection when one has to be chosen. So there should be at most 9 menus, 9 items per menu, etc. Any more than that and people are operating at less than peak efficiency in order to find the functionality they want.

    • Fitt's law is not the "most basic ... of UI design". Fitt's law has become unreasonably important because UI designers stopped giving users visual cues about keyboard shortcuts. Even my Dad uses the backspace key rather than the back button! Its so much easier. Mouse gestures will also dramatically change the effect of Fitt's law.

      Exactly. Of course, KDE Usability had a big argument about doing exactly that so that people wouldn't have to try so hard to learn short-cut keys.

      What was the proposed solution

      • A good start, but then the question becomes `why is the user hovering the mouse over the refresh button?' The answer is probably `to find out what it does.' Why do they have to do this? Because the icon doesn't make it obvious. Raskin makes a good case for replacing a lot of icons with textual equivalents in `The Humane Interface,' a book that should be required reading for anyone designing something humans have to use.
        • If the argument is that textual equivalents should replace the icons, that just means that the setting in Preferences -> Appearance & Themes -> Style -> Miscellaneous should have 'Text by Application' in addition to 'Icons Only', 'Text Only', and 'Text Under Icons' so that the icons which need it can have it when the others do not.
          • If the argument is that textual equivalents should replace the icons, that just means that the setting in Preferences -> Appearance & Themes -> Style -> Miscellaneous should have 'Text by Application' in addition to 'Icons Only', 'Text Only', and 'Text Under Icons' so that the icons which need it can have it when the others do not.

            Err...read what you've just said, and then reflect on the reason for this article's existance.

            For myself, reading the Apple HCI guidelines in ~1992 has stood me i

            • The point is that, if this new functionality is better, that should be the default. The problem with the article is that it assumes that there is a technical possibility of giving users what they want, which there is not, which is why I cannot abide using a Mac. Apple thought it gave people what they want, and it didn't. I gave a goodly amount of people what they want, but I can't use it. That's why good defaults are key, not just a lack of options.

    • Flexible software typically has a lot of functions and options. The capacity of short term memory is important here: a person at random can remember or concentrate on 7 +/- 2 items at once. At no point should a person be presented with more than 9 items in a selection when one has to be chosen. So there should be at most 9 menus, 9 items per menu, etc. Any more than that and people are operating at less than peak efficiency in order to find the functionality they want.

      I've always found this particular pro

    • The capacity of short term memory is important here: a person at random can remember or concentrate on 7 +/- 2 items at once.

      Actually, these days the IA and usability folks are telling us (web designers, at least) to take Miller's rule of seven with a grain of salt [digital-web.com].

  • Blame the egg heads (Score:2, Informative)

    by Anonymous Coward
    "Usable GUI Design showing that good user interfaces are not beyond the means of free and open software development:"

    The problem is that open source is dominated by the uber-geeks, and not enough people who specialize in user experience. So obviously, if more GUI specialists got involved in open source, the better the user experience of open source software. (Need I add a "duh" to this?)
  • Well, first thing I thought when I saw this was this previous article that was listed on ./. the link is here [anandtech.com]. It's really a rather good read, especially if your a big fan of Apple like myself. I found a lot of his suggestions to be good guides toward a better GUI, but a few were also a bit flaming. I do like the idea of simplicity, but I also like to be able to delve as deep as possible, when I can, and understand as much as I can shove into this tiny planet-sized brain of mine. I think that after using a

    • Re:Date with a Macintosh GUI, and simler eXplanati (Score:5, Insightful)

      by Bastian ( 66383 ) on Thursday November 25, 2004 @02:03PM (#10919066)
      The funny thing about all this UI talk is that, while Apple is better than most, Apple also breaks a whole lot of UI design guidelines, especially its own.

      For one, the titlebar pills are really quite small, esp. in comparison to the titlebar itself. I remember when I first got OS X I noticed that these buttons were among the smallest ones I've ever seen on a GUI.

      I'm sure a lot of people will hate to hear it, but Expose tends to be another feature that can be annoying, especially to people who aren't familiar with it. In particular, the option to activate it by moving the mouse cursor to one of the screen corners. It's always a bit annoying to overshoot the down arrow on a scrollbar a little bit only to suddenly have your whole world change without any sort of clicking or anything on your part.
      I've escaped this by turning off the ability to activate Expose by moving the mouse to the corner of the screen (keyboard only for me), but I still find it maddening when I'm working on someone else's Mac. And to someone who doesn't know what Expose is, it's even worse because they don't know how to make all their windows go back. In programing, unexpected side-effects in functions is generally considered to be impolite. I think this applies to UI, too.

      I don't think anything I've seen recently really shines on most of the points TFA is talking about. I think that's why HCI people like stuff like Fitt's Law - it means they will always have something to complain about. But it's also a perfect example of worrying about minutia when there are much bigger problems to deal with.

      The big issues that most folks seem to need to get a handle on w/r/t UI is 1)no surprises 2)everything is discoverable 3)don't keep every single thing you own on the floor of your house and 4)it's polite to answer questions when asked.
      • Taking about Expose, I consider it something along the best invention I have seen in the GUIs on todays computers in the last years. Yes, it can be a bit annoying if you only have a slugish touchpad at hand and trigger it by excident and it might be confusing to new users, since its not obvious how it got triggered in the first place, but after all its off by default so no evil things happen.

        The good thing of Expose is that it gives you one feature that everybody knows from the real world, but which is ext

  • Self-fixing Problem (Score:5, Insightful)

    by zx75 ( 304335 ) on Thursday November 25, 2004 @12:21PM (#10918365) Homepage
    I wasn't able to get to the GUI Design article, but I read The Economist's one. One telling point I thought was referring to people as Analogues, Digital Immigrants, and Natives. These being people who are unfamiliar with new technology and ignorant of how to use it (note, not 'ignorant' in general, just the classification of the lowest-skill computer user if at all), then those that came to technology and adapted to it, and finally people who grew up in the digital world.

    I think most of this problem is simply the rapid pace of change. We're in the first era that has seen a revolutionary invention go from non-existant to an everyday fact of life in such a short span of time that most people were not only alive when it was something rare and required special talent, but they are still working! The change has simply outpaced a lot of people's ability to adapt to it, so much so that it is shocking to those of us in the 'next' generation that the previous one could be so clueless.

    Its not that they are clueless users, its that they have been thrown head-first into a pond that they vaguely knew existed, let alone how to swim. But the upside is that the problems we agonize over, the clueless user, tech support pains, is for the most part a self-fixing problem. In 30 years the older generation will have retired and moved on, while those of us who will take over for the most part are native users, we grew up immersed in technology and rapid change. Thus in another couple of decades, the problems of technological ignorance and inability to use modern systems will dwindle away. Not that it will ever disappear, there will always be people unable to grasp these things, but the fact that everyone has grown up with this knowledge will all but eliminate a lot of the problems we're dealing with today.

    There will always be bad interfaces, unusable technology, its a given. But if this rate of rapid change continues, in a generation's time everyone will have been born and raised in an environment of rapid change and cutting edge technology. It will be commonplace, and I think that the issue of entire segments of the population being unable to adapt will no longer exist.
  • The article gives an example of enlarging the back button as this is most used by users. I think a better improvment would be move the buttons to the right hand side of the screen (you can do this in Firefox!) so they are near the sroll bar which is the widget that I probablyu used second-most-of-all ! In fact, just drag the back button over and it's easy to hit as nothing else is there!

  • flying colors (Score:3, Insightful)

    by Doc Ruby ( 173196 ) on Thursday November 25, 2004 @12:30PM (#10918410) Homepage Journal
    UI-centric design makes sense for the UI layer. For the logic and data layers, the equivalent design consideration is API design, which is not as compelling as functional design, including maintenance features. Dictating the whole application's design by the UI is like flying not just on one wing, but on no wings, or engine, just the cockpit dashboard. This balance is one reason to have one UI-centric person develop the UI, a data person develop the data layer, and someone with knowledge of the actual business executed by the application designing the logic layer that ties them together. We don't make one engineer design all the devices in a 747 or F16 - they'd crash, even if they looked great going down.

    • Re:flying colors (Score:3, Interesting)

      by MikeBabcock ( 65886 )
      There was a really good (TLC?) episode about designing modern jet fighter aircraft. They spoke of two things: making it fly, and making pilots able to fly it.

      It seemed that with all the control surfaces necessary to make this plane (new F-16?) fly, it would be impossible for the pilot to successfully fly the plane in combat (or at all?).

      Instead, they engineered the plane the way they wanted, essentially ignoring the pilot's limitations and then wrote a software interface between the pilot's usual tools (
  • and the links on the bottom lead to all the right places, so how come there are still so many bad GUIs around? My last project involved building a GUI except for other things, and I can tell you, a shift in paradigm in the right direction can really do wonders. You can have a bunch of text boxes with pixel offsets, if you want to allow user to do layout of some graphical box with some text on top of the screen (text overlay on a video output,) or you can give the user a scaled representation of the screen
  • Personally, when I hit the edge of the screen it changes to the next active desktop. It's a very useable setup and I personally think that once we finally get people to realize the power of virtual desktops then that's the future of minipulating them.

    So his statement that it's easy to hit a 1-pixel button on the edge of the screen is very inaccurate. In fact, please keep the scrollbars 1 pixel away so we don't constantly have people ramming their pointer into the sides of the screen, it will be damaging

  • Trival widget issues (Score:3, Informative)

    by bburdette ( 556965 ) on Thursday November 25, 2004 @12:32PM (#10918424)
    I think most of the issues the author raises are pretty minor. Saving a mouse click here or there is convenient, yes, but its trivial compared to real usability issues like how do I use this application without reading a manual? Large, well placed, and convenient buttons are useless if the user doesn't know what to do with them. Having a good help system that explains the purpose of the different elements of an app is essential. There's nothing worse that being stuck in a completely opaque application with no clue as to how to proceed, and the help system has no answers. For me this kind of program is CAD or (at first) the GIMP. For some users this opaque program is mozilla or outlook. From what I've seen these programs don't really cater to the beginning user that well, there's nothing to really explain the basics like what is email, the difference bewteen a browser and the internet, what is a scroll bar, etc.

    Which brings me to the topic of widgets. Why can't you help-click on anything in your gui and have it explain itself? One obvious problem with such an elaborate help system like that is that the infrastructure for it is a lot of work to build. Why should I have to explain what a scroll bar is to some noob, I'm trying to write an email client here! That's why the widgets should have help built in to them.

    The other thing is that a lot of the author's issues are with widgets, like scroll bars that don't go to the edge of the screen. Like most developers have control over that! 99% of developers will never bother to develop their own scroll bars to get that extra pixel. And if they did, every application would have different widgets, and that would suck too.

    All that said, I do like the point about only showing the user what is really needed. Lately as the app I've been working on has grown, the menus and toolbars have begun to look more and more intimidating. Its much better to keep what the user can see down to a small set of frequently used items, and tuck the esoterica away. Otherwise they end up having to ask themselves whether they are supposed to know what every obscure menu item does, and its a lot of work to know what is important and what may be safely ignored. And that's what I want to minimize: the amount of knowledge the user needs to know to get the job done.
    • Oooh, scroll bars. I hate scroll bars. That is to say, I love them telling me where I am in a document and how big the document is compared to what I'm looking at (thank-you Microsoft for the variable-sized scroll region), but most people don't even know how it works (really).

      I know, I know, scroll mouse.

      Here's an idea: the user moves their cursor near the bottom of the screen and *isn't* highlighting, etc. and doesn't jerk the mouse back up (indicating the following wasn't what they expected), scroll d
    • One of my big beefs with a lot of 'user-friendly' design is the very tucking away of esoterica, mostly because its done so badly.

      A clean, easy-to use, visible options design shouldn't do its best to hide the advanced functionality from ever being seen. Too often I have spent looking for a piece of functionality that I know exists in a program, only to spend 20 minutes clicking through dozens of Options, Advanced Options, Preferences, Other Preferences, Misc.. etc menus before I find what I'm looking for (i

  • My pet UI peeve (Score:3, Insightful)

    by LarsWestergren ( 9033 ) on Thursday November 25, 2004 @12:32PM (#10918429) Homepage Journal
    The UI design failure that annoys me the most is media players that the developers obviously have spent a long time getting the user interface to look like a panel for an expensive car stereo or DVD player.

    Why tiny little buttons jammed close together that are hard to see and click correctly? Sure, in a car dashboard space is expensive, but when you are looking at a film on your computer screen you are going to use fullscreen and have the controls hidden most of the time, so when the users wants to see them, why not make them big with clear lables?

    Especially gratuitous is when a player has new controls that are specific to a DVD player, such as a subtitle/audio selector or a click/draggable progress bar. The developers often don't integrate this with the main controller (cause there is no analogy in a car radio, which appearently makes them confused) but instead the player opens other windows with a totally different look and feel. Or if they DO include it, it is often also tiny, squeezed in between the play button and the usually useless "eject" button for instance. This is especially bad with the progress bar or volume bar where you might want to have fine selection resolution. Why not put these controls along the lower edge of the film screen where they can be stretched out? (I think Quicktime and *yech* Windows Media Player gets this right. Haven't used them in a while though, I might be wrong.)

    Xine, mplayer to mention two have this problem of suffering from the Car Stereo look for controllers. Lots of mp3 players the same. Ok, they can be skinned differently... but why such as bad default, and why do all have to have their own format for skins?

    (On a related topic, while I'm stil whining, I have yet to find a media player under Linux that allows you to select smoothly with a scrollbar where in the film you want to jump down to seconds. Xine for instance jumps 1 minute back or forth when you use the arrow keys to skip. When you drag the scrollbar it doesn't show where in the film you are, and it has a minimum resolution of something like 30 seconds, so it snaps to the closest 30 second segment start when you let go. I think mplayer is similar.)

    Now, all this said, I do appreciate the great work people put in in making open source players that I can enjoy. If you are one of these developers, feel free to flame me for complaining instead of contributing.
    • Something about multimedia seems to drive programmers insane. Skins are great, but there is a default user interface for a given OS and programs should fricking use that interface by default. There is a way that buttons, menus, and the screen controls are supposed to look, and nothing is more annoying than opening an application that has tried so hard to look cute that you can't figure out how to close it because all the controls are hidden as hot spots in some clever bitmap image.
  • The Fine Article, in its point 0, says that the user isn't trying to use the program, they're trying to get their work done. That's correct. Think of your program as a screwdriver. What's the user interface on a screwdriver? A handle. When's the last time you had to think about the handle on a screwdriver? That's a good interface.

    (I don't want to get sidetracked with tool analogies, so I won't talk about why a Leatherman is good while a Swiss Army Knife is bad. Ok, I will: it's easy to access all of

  • This is what I do (Score:5, Informative)

    by localroger ( 258128 ) on Thursday November 25, 2004 @12:42PM (#10918470) Homepage
    My job is to write software for industrial controllers. Most of the people who do what I do are not "programmers." We started out as technicians or engineers, and cracked the manual the day a "programmable" device arrived on our bench.

    Poor user interface design is the second biggest failure of this kind of software. (The first is failure to plan for failure, but that's a different problem.) The problem isn't that guys like me don't understand how to design a user interface; it's that we don't even think about it because we tend to be thinking in terms of the process or machine rather than the human user.

    There are no universal guidelines for how to lay out a user interface. The only sure method is to code it, then try using it and see if it feels natural. Often an interface that "follows the rules" will feel clunky in use, and when that happens you should rewrite it and try again until it is intuitive. When you've gotten it to feel right yourself, you should put it in front of the people who will use it all day long and see how they like it. And you should be willing to rearrange it until they find it natural and intuitive.

    One reason those field-programmable controllers have become so popular is that people like me, working in the field, can do this. If a manufacturer builds, say, a batch process controller, it must implement every possible function that any process might ever need. This usually results in a bewildering user interface since most actual processes will only use a fraction of the controller's functions. By writing a custom controller in a programmable device, I can give the user just the controls he needs to do his job.

    It used to be a once a month occurrence for us to get a service call along the lines of "our scale is only weighing about half what we put on it," because a user accidentally switched from pounds to kilograms. Newer devices let us turn off modes the end user will never use, and the result is less friction all around.

    It goes without saying of course that you put the most-used controls where they are easiest to find and most obvious, you only put controls that are used constantly where they are always visible. You always provide keyboard shortcuts for EVERYTHING. Especially in the workplace, day-in day-out users will learn all those shortcuts, but the temp timer needs the GUI. Both are absolutely necessary. Not putting in keyboard shortcuts is the single biggest screw-up in industrial GUI's I have used.

    The art comes in determining what controls are really used most often, and when things like confirmation dialogs shift from being a useful safeguard to an annoyance. I can't begin to count the times when I've installed a relatively simple system only to find that some control I'd buried in a deep menu is used much more often than I'd realized. Usage patterns are often radically different in simulation than they are with a real machine connected to real processes. The job isn't done when you close the build file and put field installation on your calendar; you will almost always have to refactor at least once based on end user feedback. If you don't plan for this and budget for it, it's a big, big mistake.

  • Toolbar buttons require a lot of work from the user- You have to memorize them, or take time reading the tooltip to learn what they are for. Usually it is much better to put commands into menus with regular text since you can tell what they do by their text.

    However, sometimes a command is used so frequently that it is worth forcing the user to learn to use a toolbar button, because toolbar buttons have some important advantages:

    1. They take up less space and because of that can be left on the screen all the time
    2. The human eye is great at recognizing toolbar icon once they're meaning has been learned

    But usually, making a toolbar button for a command is a bad idea, unless you know otherwise. Look at Firefox: It only has 5 buttons on its basic toolbar and places everything else into the menus- Great design!
    • ### Toolbar buttons require a lot of work from the user-

      I kind of disagree, there is nothing that I find more frustrating then an app where I have to dig through deep menus, while the toolbar is esentially 80% pure white space, which is of course completly useless. Buttons in the toolbar should however be well grouped and have good visible clues on what they do (ie. not all blue circles with tiny white things in it like in KDE), so if I don't use them I should be able to simple ignore them. Sure with Firef
  • As programmers we know that to optimize something
    we have to have a way to measure it.

    I think that a good user interface should be easy to learn and very productive.
    But in most cases is easy to use (GUI's) not very productive
    and very productive (like vi) is not easy to use.

    So, for a ui the is tree thing to measure.

    1) usability.
    2) productivity.
    3) the users transit time from newbie to expert.

    A way to measure this would be to make a test
    where you asked a user to make many similar excises.

    Then the usability

  • Fitt's law stupidity (Score:5, Insightful)

    by jeif1k ( 809151 ) on Thursday November 25, 2004 @01:09PM (#10918671)
    Often, when people talk about good GUI design, Fitt's law gets dragged up. Fitt's law is, at best, a footnote to good GUI design. I think UI designers hold on to it so tightly because it's one of the few scientific-seeming "laws" they have and because the improvement is easy to measure.

    Fitt's law tells you what you need to do so that people can hit your buttons faster with a mouse (well, it's more general than that, but you get the idea). But most of the time, the time users "save" is so slight that it makes no difference to the overall efficiency with which users can use the application. The few areas where it does matter have already been encapsulated (context menus and pie menus are a good thing because of Fitt's law, but your framework already provides them for you).

    People who design GUIs based on Fitt's law may often do the right thing by accident. For example, putting a button with a 1 pixel wide inactive border at the edge of the screen is not a good thing to do. Fitt's law says, in effect, that if the button is not at the edge, you have to slow down and hit it directly, whereas with the button at the edge, you can just slam into the edge with the mouse and hit it. But that's not the main reason it's bad to put buttons one pixel away from the edge; the main reason is that doing so confuses the hell out of users who simply don't see the border and wonder why nothing is happening when they think they "are pushing the button".

    At other times, Fitt's law misleads you. Making the "Back" button bigger on Firefox, as the article suggests, probably doesn't save you any significant amount of time (anybody who really cares is using gestures or pie menues anyway), but it does make the UI look ugly to users and they'll like it less.

    Erase Fitt's law from your mind. To the degree that it matters, it will be obvious to you anyway. And in subtle cases, it's a treacherous guide.

    What you should focus on is making your UIs intuitive, unobtrusive, internally consistent, unsurprising, and pleasant to look at. Fitt's law doesn't help you with any of that.

  • Good Article and well worth reading (Score:2, Insightful)

    by Anonymous Coward
    Unlike most /.ers, this guy did more than just whine, complain and bitch. He took some well known examples and showed us where they fall short. Wether we agree with every single point is irrelevant.

    I found this article to be well written, well laid out, and quite informative. Definitely things to keep in mind.

    And I totally agree with point 0 - the user is not using our application, so it should be as unobtrusive, and helpful as we can make it.
    • Like most /.ers, this guy committed the cardinal sin of research. He took a few of his own personal preferences with respect to UI design and generalised them to the population at large, paying no attention to whether there was any evidence that this was valid.

      He then passed these prejudices off as insight, and research.

  • I think the most fundamental point is.. (Score:3, Interesting)

    by hyphz ( 179185 ) * on Thursday November 25, 2004 @01:43PM (#10918934)
    For your application to be user friendly, it has to actually be friendly to the user.

    This means that:

    - There is no way to create, let's say, a user-friendly interface for product activation because activation is in itself a distrustful, user-hostile goal.

    - If you want to avoid describing to the user what the computer is doing, whether that's because it's something underhand or because you are an insufficiently skilled explainer to be able to describe it in understandable terms, then no matter how many windows and buttons and fancy animations you include it will be obvious that you are treating the user as stupid, which is not friendly.

    - If you cannot give the user useful information because it is not technically possible to do so, then do not think that giving them some information using a component from a user interfacing handbook will make your app friendly. As an example, just because it is not possible for a web-browser to provide a true time-based progress bar (which rises at constant rate and completes immediately when full) does not mean that's OK to slap in a progress bar that displays a relatively meaningless value. (What is the average user supposed to do with the knowledge of how many parts of the network download and typesetting task have been completed, especially when the parts are decided arbitrarily by the system designer and never explained?)

  • #1 rule of GUI (Score:2, Interesting)

    by Anonymous Coward
    GUI's should be extreamly thin clients that wrap other functionality that is also available in another form.

    GUI's should be modeled like opening a book. If you close the book everything that you wrote in that book is still there.

    Decoupling the GUI from the actual application is the mark of an experienced programmer.

    I find that an application should have multiple ways to access it. I like to have things running in the background and have the GUI be spawned later.

    This would be for use with industrial co

  • Which button should be bigger? (Score:5, Insightful)

    by MagikSlinger ( 259969 ) on Thursday November 25, 2004 @01:54PM (#10919013) Homepage Journal
    I like the one point the author brought up: most used buttons should be bigger and easier to find. Good point! "It should be the back button" BAD point!

    I think everyone is different in how they use their applications. E.g., I prefer alt-right to go back or use the drop down list (it's position matters not to me) if I use the button at all. So what might be most common for one user isn't for the other. And having your most used button ("Stop" in my case) smaller than the buttons you don't use is really, really annoying!

    SOLUTION:

    Most used buttons become automagically bigger. So as an application learns how a user works, it will optimize the user interface for them. Most use buttons get shifted to the left (or right) and made larger. Toolbox panels that percolate up most used features to the top so the top half is the most used features in a larger hit box, and the bottom half is the "usual" layout.

    • Re:Which button should be bigger? (Score:2, Insightful)

      by Anonymous Coward
      PROBLEM:

      UIs that mutate are annoying as hell and harder to learn as things keep changing.

      Windows tries this with its menus hiding uncommon ones, which makes it impossible to find them when you do want them.

  • Complexity (Score:2, Insightful)

    by starfishsystems ( 834319 )
    To summarize the piece in the Economist:

    Computers are complex.

    That makes them difficult to use.

    We don't like that.

    Fix it now.

    The underlying theme is very much a mark of our times. There is no doubt that it has genuine resonance for many people as they deal with an overwhelmingly complex world. On the other hand, it is a position fundamentally based on ignorance, and thus there is not much hope of reasoning with it.

    It's not as if the issue of complexity has never been investigated. We knew from the

    • Re:Complexity (Score:3, Insightful)

      by Johnathon_Dough ( 719310 )
      Probably the simplest artifact in common use is the knife. Yet given our resources and technology, it's appalling what passes for a knife in most people's kitchens.

      More oftne than not though, this is not out of the knife making industry's fault as a whole, it is the knife owners inability to justify spending the money for a "good" knife. The same could be said for a hammer, I had an ex-gf who routinely used a high heel shoe to hammer in nails for picture frames. When asked why she did not just buy a hamme

  • Free and Open-Source Software actually has an advantage over proprietary software where user interfaces are concerned: it can be the best thing to all people.

    There is no single user interface that is best for everybody. You know that too: some people prefer CLI, others prefer GUI. This means that the optimal solution is for a program to have multiple user interfaces, one for each class of user.

    Having multiple user interfaces for a single piece of software is easier for open-source software than for closed

  • User-interface isn't the real problem (Score:3, Insightful)

    by c0d3h4x0r ( 604141 ) on Thursday November 25, 2004 @02:43PM (#10919353) Homepage Journal
    The real problem with most FOSS is that it is too complex and inconsistent architecturally. No matter how pretty or usable a GUI you slap on top of it, if the underlying system is too complex and inconsistent, it won't be accessible to normal people.

    Example: someone writes a niffty GUI wizard for Linux for setting up a printer. The wizard itself follows all the usability guidelines and is quite nice. But the problem is that the wizard is just a front-end for CUPS or some other nastily-complicated printer driver system. When the back-end chokes in some unexpected way the front-end isn't expecting, the user has to comletely sidestep the wizard, go the command line, and whip out Linux-fu magic to fix the problem. The problem here isn't the front-end GUI wizard; the problem is that the architecture of the underlying printer driver system is overly complicated and completely blows, and there's no tight integration between the back-end and the front-end so that the user can use the wizard to easily fix any possible problem that may arise.

    You see this over and over again in the Linux/BSD worlds. Slapping a pretty GUI on top of a shit architecture does not make thing easier to use.

  • Different UIs for different users (Score:3, Insightful)

    by tootlemonde ( 579170 ) on Thursday November 25, 2004 @03:18PM (#10919583)

    The most basic point in all computer UI design is that the user does not want to use your application. They want to get their work done as quickly and easily as possible, and the application is simply a tool aiding that.

    There is also a class of user, more common that one might expect, that does not want to get his work done quickly, although he may say he does. UIs designed for the lowest common denominator are often dedicated to trying to get this user to do something he's not inclined ever to do. As a result they fail to satisfy this user as well as the other type who really does wants to get his job done quickly and easily.

    Among the quickly-and-easily crowd, there are two types of the users: those who use the product a little and those who use it a lot. You can argue about what is most intuitive for the use-it-a-little segment, but keyboard shortcuts are usually what experienced users prefer. If you really want to get your work done quickly and easily, keyboard shortcuts are what you want.

    As a result, for people who use the product the most, an intuitive interface may not be all that important except as a learning tool.

  • Konqueror, a bad example to pick (Score:4, Interesting)

    by advocate_one ( 662832 ) on Thursday November 25, 2004 @04:43PM (#10920114)
    for showing us how badly a browser can be designed... yes... except that Konqueror's primary function is as a filesystem browser, where the UP button makes perfect sense in it's location...

  • It's conceptual people (Score:3, Interesting)

    by owlstead ( 636356 ) on Thursday November 25, 2004 @06:40PM (#10920660)
    Lots of mistakes are made in UI design on a conceptual level. The article touches that slightly by explaining the importance of only showing the information/controls important to the user. But it goes much further.

    To show some examples from firefox: there are many settings to control privacy/security. Many users do like these settings, but not for each site. If they trust a site, they don't mind popups, images from other servers etc. But firefox does not place the site central, but the control. That's simply not how a user _thinks_.

    I've got a lot of other grieves, but I'll let that pass for now. Normally I only comment on programs that I find of great use to me, also because I try not to use the others at all. The screen real estate that firefox leaves me is for instance fantastic, and it is very uncluttered.

Slashdot Top Deals

I have hardly ever known a mathematician who was capable of reasoning. -- Plato

Close