Catch up on stories from the past week (and beyond) at the Slashdot story archive

 



Forgot your password?
typodupeerror
GUI Software

Software, Tools, Or Techniques For UI Review? 246

Comatose51 writes "Does the Slashdot crowd know of any software, tools, or even techniques for reviewing the UI of an application? Right now at our company this is a long and arduous task of looking at slide after slide of pages and menus from our UI, and taking notes and arguing over what should go where or how the UI elements should behave and interact with the user. It takes many, many hours to do this and with all our UI developers involved, it adds up. This has to be a common and recurring problem so there must be a better way to do this. If there is open source software to help, great, but any helpful suggestion would be appreciated."
This discussion has been archived. No new comments can be posted.

Software, Tools, Or Techniques For UI Review?

Comments Filter:
  • by AltGrendel ( 175092 ) <[ag-slashdot] [at] [exit0.us]> on Tuesday July 29, 2008 @03:35PM (#24391365) Homepage

    ...and with all our UI developers involved, it adds up...

    Too many cooks, as it were.

    • by matrix mechanic ( 893601 ) on Tuesday July 29, 2008 @04:00PM (#24391775)
      Also, for all your developers, do you have a designer? UI development = graphic design + industrial/interaction design. Read Magic Ink: Information Software and the Graphical Interface [worrydream.com]
      • by LaskoVortex ( 1153471 ) on Tuesday July 29, 2008 @04:08PM (#24391915)

        Also, for all your developers, do you have a designer? UI development = graphic design + industrial/interaction design.

        There is also the little concept of actually using the software. Here is my plan that I wish every corporation would adopt for near perfect design:

        • Write application.
        • Give to CEO of company to use for day-to-day tasks (make him use it every day or get a new CEO)
        • Fix everything he hates and add what he wants
        • Repeat until he goes about one month without any suggestions or complaints

        Of course this is from a user's perspective and from someone who writes software for myself. Profit may get in the way of a usable product, so I don't expect my plan to get adopted everywhere.

        • by belmolis ( 702863 ) <billposerNO@SPAMalum.mit.edu> on Tuesday July 29, 2008 @04:20PM (#24392079) Homepage

          This is good advice for many consumer products but not for all software since some software is intended for users of whom the CEO is probably not representative. Software for technical people, for example, may trade a longer learning curve for greater efficiency or configurability for experienced users, and software for some tasks assume specialized knowledge of the task that most people won't have.

          Good luck finding a CEO who will let you fire him if he doesn't test your software.

          • by KillerBob ( 217953 ) on Tuesday July 29, 2008 @05:17PM (#24392903)

            I think his point was more that the best way to design a user interface is to let the users actually... y'know... use it. Throw it out to a small but select non-developper beta, and take their suggestions about usability to heart.

            A group of engineers sitting around, arguing about what should be where is just going to obfuscate things, and unless they get really lucky, it isn't going to result in something that's usable. Also... keep in mind the idea that nothing should be more than 3 clicks away, unless it's obscure. More than that, and users won't remember it. If it's something that they use frequently, it should be 1 click away. All about keeping the application efficient, but not cluttered.

            My first thought, when I read TFS, was that he's out to lunch. He's looking for software to accomplish a task that, to my mind, should be a completely organic process. You can't write software to design your user interface for you, because people don't think like computers. You need to go through revisions and iterations until you get something that works. Oh, and sitting around watching slides is absolutely the wrong way to get a feel for how it's going to work, too. They should be presented with the actual user interface, or a mock-up if that's not possible, and actually go use it for a few days before coming back and talking about what was good and what was bad, and what needed improvement. And keep doing that until enough people are happy that you'd be comfortable unleashing it on the world.

            • by lorenzo.boccaccia ( 1263310 ) on Tuesday July 29, 2008 @06:40PM (#24393873)
              and when you test, measure, measure, measure.
              don't take a single word of the user reports without some sort of usage pattern logs. users tend to concentrate on the latest bad experience they have had. measure time spent on windows, time spent on similar tasks, undo per windows and a lot of other metrics, as time between clicks on button, and filter the user reports trough the application log (and vice versa) most of the bad experience could be just automated away, hidden completely or better represented by some sort of flow management (as wizards).
        • Re: (Score:2, Informative)

          by Anonymous Coward

          I wouldn't expect your plan to get adopted anywhere. The art in delivering software is providing a useable solution within tight budget, time and quality constraints. You're looking only at quality and usability without any consideration for time and budget.

          No project would ever finish if you kept asking the users what else they'd like to change.

        • Why not one of your customers instead of your CEO?

          I worked QA for a small time software company and they had a special relationship with one large scale customer who elected to be a beta. Actually, they really weren't the beta at first, but they requested several features and offered to pay big money for it.

          It turned out the special features they requested were popular with the regular customers and the developers started to include some of the features with the regular builds.

        • Re: (Score:3, Insightful)

          by erroneus ( 253617 )

          This is also supposing that a given CEO actually KNOWS the business he leads. Too often, it's marketing and sales people that end up in the top positions of many businesses. This often means that they have little or no appreciation or understanding of the usage or applications, products or services this company may offer. Companies lead by sales and marketing types often have little respect or regard for what they offer and concern themselves only with the numbers. The is a terrible trend as quality oft

        • One better (Score:3, Interesting)

          Also have the programmer themselves have to use the application for 'a day', in a real-world example - the guy who knows the UI in and out, so training is not a problem.

          But as a programmer he/she will see what doesn't work when they have to enter data live (i.e. entering client data with client sitting across the desk) - and they will get a pretty good idea of what needs fixing and how to get it done. For more complex concepts they may have to be the keyboard pilot with an expert telling them what they wa

        • Isnt that what microsoft did when they had gates?

        • Re: (Score:2, Insightful)

          I've worked in a similar situation to that and let me tell you, it's a nightmare.

          The software gets horribly warped to the individual flights of fancy of the CEO who is such a bizarrely unrepresentative user that their input is almost useless.

          They also expect that anything they say should be implemented at the drop of a hat so you drop everything and do stupid useless hacks that just to keep the idiot CEO happy.

          The only people to give you feedback on your product are it's intended users and you must do every

        • by WGR ( 32993 ) on Tuesday July 29, 2008 @08:14PM (#24394637) Journal

          Of course, that is what Apple does with its software. If Steve Jobs doesn't like the user interface, it gets changed.
          Doing this has helped Apple be the leader in user interface design and the stock remark recognized ths when news of his possible illness dropped Apple shares considerably.

        • Play some portal... (Score:3, Interesting)

          by tempest69 ( 572798 )
          Really, honestly.. then listen to the commentary..

          These people really designed a UI that becomes usable after some training. Great take aways...: 1 Use the simplest method possible to control something.

          2. Dont add buttons.. On My Imac there is a small remote 2 buttons, and an outside ring.. This is FAR more powerful than the 50+ button remote for Dad's TV+dvd player remote.

          3. Dont Hide controls too deep.. look at vista.. changing an ip address Start->CP-> network ->Internet properties-

        • by SQLGuru ( 980662 )

          I'd do basically the same thing but instead of the CEO (who doesn't really do much real work), I'd give it to the following people: 1) my mom - who is computer illiterate, 2) the most senior "real" user, and 3) the most novice "real" user.

          If my mom can figure it out, it's solid UI design.
          If the most senior user can use it, it's fully functional.
          If the most novice user can use it, it fits the task.

          If it passes all three of those tests, you're done. Take two weeks off and start your next project.

          Layne

      • by ProppaT ( 557551 ) on Tuesday July 29, 2008 @04:32PM (#24392289) Homepage

        Not in the least. Lord no. Perhaps have them polish up and make things look pretty after the UI is decided upon, sure, but leave the UI design to people with a background in it. That's the equivelant of telling a baker to to cook you a steak. They might both make food, but the thought process is totally different.

        If you have a technical writer working on the project, give him/her a shot at it. Their job is to make the complex simple and to make it fit in as small of a container as possible. They'll also be the ones writing the manual on the stupid thing and, more often than not, many design flaws come out in the process of writing the manual. You'd be surprised what kind of input they might have.

        Other than that, do you have a corporate psychologist or HR person with a background in psychology? They might also have valuable insight.

        Other than that, as far as viewing the UI for a review, have someone make a mock up, clickable UI in Flash or even HTML. It shouldn't take long and will give you a good idea of what the user experience before it's all coded in.

        • Re: (Score:2, Insightful)

          If you think all a graphic designer does is "make things look pretty" you might want to read that article.

          and if you live in a world where you think people still read manuals, you might want to find out what a UI designer actually does.

          Actually I'll tell you. A lot of it is helping a user discover, understand and use features and data without having to read a manual. And coincidentally guiding the way someone discovers and understands visually (like on a computer screen) is graphic design. The use part fall

          • by ProppaT ( 557551 )

            Right, and who better to understand why a person actually has to RTFM than the person who writes TFM.

            From personal experience, when the UI gets thrown to the graphics design team, it looks stunning...however, the depth is usually too short sighted to anticipate all of the required user interactions.

            Frankly, a GUI professional would be optimal, but if your company doesn't have one, the tech writer is going to be the best follow up. If the program looks plain and uninspired, fine, so long as it's easily usab

        • Technical Writers are development's interface to the customer, and as such they are typically the "go to" people for such things in early development phases. Additionally, the technical writers often work in conjunction with (though perhaps not in an "official" capacity) quality assurance as another line of sanity testing.

          While individual developers are tasked with completing certain portions of a project, or maybe tasked to smoke test chunks of code, it is often the technical writers who see the entire pro

      • Yuck! (Score:3, Interesting)

        In this section [worrydream.com] in particular -- past the comic -- there is an example of a redesign.

        Raise your hand if you would rather try to point at a specific location on a map than simply choose it for a list.

        And you know what? By the time you're using this form, you know the date, as text. It's going to be quicker and simpler to enter it via the dropdowns -- even quicker if you can simply type. The calendar widget only helps if it can show me events I've already placed on a calendar -- otherwise, there's no point.

        I

    • by bfizzle ( 836992 ) on Tuesday July 29, 2008 @04:07PM (#24391879)

      Design by committee is a terrible process to endure and very often the outcome is of far less quality then a design done by someone who knows what they are doing.

    • by Xzzy ( 111297 )

      I don't think that's possible when it comes to UI design.

      Any project where it's possible that a large group of people will be using the software, you have to put in a huge amount of effort to make sure the interface can accommodate as large a range of preferences as possible. Everything from the background color to how many times you have to put your hand on the mouse can have a major impact on a user's productivity.

      The downside to this is the only way to know for sure is to make the UI, get some people usi

      • Xzzy has a very good point.

        In that vein, some things I have seen in some Windows programs, as well as in OS/2's WPS GUI are the options of selecting "Beginner, Intermediary, Advanced" for how the menu system is created... Beginner showing the most common choices, while Advanced shows everything including the kitchen sink.

        Without knowing too much more about your software - or what features are insisted upon being easily available, I dont know if that applies.

        • by Saanvik ( 155780 )

          Self-selecting based on skill level is usually a very bad decision. Users cannot properly assess their own levels of skill at a program. A successful method for doing something similar is to offer optimized, or even single-click, paths through common tasks (such as "Convert video for iPod"), while giving users that need or want more functionality alternate ways to configure the flow through the tool.

          Of course, this isn't what the poster is asking about, so I'll shut up now.

    • by electrictroy ( 912290 ) on Tuesday July 29, 2008 @04:42PM (#24392403)

      Give the program to the average secretary & watch where she stumbles or otherwise looks confused.

    • by TheMCP ( 121589 )

      Absolutely, this person's problem is not lack of software, it's too many people. Good UI comes from small groups of no more than two or three people (I try to pair an artist and a programmer), or one true visionary. Big groups with lots of people reviewing it tend to come up with nonsense like this: http://www.youtube.com/watch?v=kU9YeOQm3Y0

      Or the idea of clicking a button labeled "Start" to shut down the computer.

  • Ask the users. (Score:5, Insightful)

    by oahazmatt ( 868057 ) on Tuesday July 29, 2008 @03:36PM (#24391377) Journal
    I'm not a programmer, but I'd still like to offer my opinion.

    Ask the users. The people who will be using this software have certain expectations about where something should and should not be located.

    Of course, that should not be the end-all of your research, but it should be an excellent starting point.
    • Re: (Score:3, Insightful)

      by Threni ( 635302 )

      The users should be doing - or getting someone to do - mock ups. Use vb6/.net, or Access, or Visio, or anything else which lets you knock up some pages full of controls which look similar to what they're after. Doesn't matter what it looks like, as long as you can tell a listbox from a text box etc, and how much data they want per page (ie does it scroll, have next/prev buttons etc). It's not up to developers to either decide or guess.

    • Re:Ask the users. (Score:5, Insightful)

      by hardie ( 716254 ) on Tuesday July 29, 2008 @03:49PM (#24391601)

      Absolutely ask the users. There is no better way of evaluating your UI.

      Have your programmers watch users try the UI. Don't lead the witness--let them make mistakes (and fix that part of the UI).

      You will be surprised what you learn.

      Steve

      • Asking the user is like a cook asking his diners how he should alter his recipe. If he is at that level, then he is not a great cook. If you are still asking your users about what to fix in your interfaces, you are not a great UI architect. This is a good workaround if you do not have one, of course.

        • Yes and no; asking users how to improve the interface is not the right approach because as you point out: users know nothing. However, asking them where they have problems, get lost, slow down, etc while using your interface is an excellent means of narrowing down on what problems your development team can solve. It focuses your attention on things that actually matter instead of on things that you only imagine are necessary.

          Also, pure graphic design photoshop/illustrator producers who think they can desi
    • Re: (Score:2, Insightful)

      by Anonymous Coward

      You often need a starting point prior to asking the users. While the users should be the final arbiters it is more of the case than not that the user can't really describe what is needed because they don't fully understand their own requirements. They can however critique something they've been shown and this will help them drive to requirements.

    • by jhfry ( 829244 )

      I agree, ask the users... depending upon the application will depend on the best way to ask.

      If possible, have multiple teams of users each coupled with a designer... have the designers then sit down with what their teams came up with and find the common elements, these are must haves. Anything that is unique should then be presented back to the other user teams to see if they agree about the need, if so it's also a must have. Finally, the desingers seperate and create simple mockups that include all the m

    • Re: (Score:2, Informative)

      Hi

      I am actualy a Software Developer and i specialise in User Interface Design and Programming (mostly in Java). I have done Userabilty Engineering, this is the study of how a UI will be used, how to evaluate an effective UI and how to compare UIs. It go through how to recruite a sample of users and test their reactions to your UI. Using paper based examples, proto type interfaces and such.

      But the answer boils down to, 'Ask the Users'.

      Also you should remember that most western languages read top,left to bott

      • Re:Ask the users. (Score:5, Interesting)

        by Jupiter Jones ( 584946 ) on Tuesday July 29, 2008 @04:41PM (#24392385)
        You know what's better than asking the users?

        Not asking the user.

        What you really should do is watch the user. If you ask them, they'll tell you what they think they'd do, or what they think you want to hear, or what they think they'd like to see... everything except what is most important: what they really do.

        (And I'm not the only one who thinks so [useit.com].)

        JJ
        • Re: (Score:3, Informative)

          Not to mention users are idiots. They don't know where they want things. What menus they want... etc etc etc... if you ask the users they'll tell you they either "liked it" or "were confused but are sure it wasn't their fault".

          The MOST IMPORTANT thing a UI designer needs to work on is FLOW. The specs tell you what the application needs to do. "Color Correct a Photo", "Remove Zits", "Paint: change brush size, paint, change brush shape..." etc etc etc.

          If you watch your users and see A) What they do most o

    • Add Ribbons (Score:2, Flamebait)

      by kramer2718 ( 598033 )
      [sarcasm] If there's one thing a UI needs it's ribbons [wikipedia.org]. Don't worry whether or not your users like it. A new fancy feature will earn you more money because more people will upgrade. [/sarcasm]
    • Re: (Score:3, Insightful)

      by TheMCP ( 121589 )

      I am a programmer, and would like to offer my opinion.

      DO NOT ASK THE USERS. FOR THE LOVE OF GOD, DO NOT ASK THE USERS.

      Users don't have a damned clue about software design, and will always ask for something stupid. They might ask for something that seems simple to them but is hideously complex or impossible to implement (I once had a user calmly demand I should replace the entire complex app with a box where they could simply specify in english what they want and push the button and it would magically figure

      • Re: (Score:3, Insightful)

        by Ratface ( 21117 )

        IMHO you are only partly right. Asking for goals in functionality is the way to go in the beginning, but getting feedback on useability and design later in the process can be invaluable.

        Sure, users can have unrealistic expectations, but it is the job of a project manager or interaction designer to interpret and manage those expectations.

        Your example of a user who had completely unrealistic expectations actually creates a positive situation. If you had just given that user a finished piece of software it wou

    • Re: (Score:3, Insightful)

      by billnapier ( 33763 )

      In my experience, users usually don't know what they want. Or worse, they'll ask for something, but really want something else.

      This idea works better if you have a professional UI designer work up some designs and present those to the users.

      You should use your users to generate ideas for your interface, and also as a checkpoint for your interface. But giving them too much input will screw up your end results.

    • Re: (Score:3, Insightful)

      "Ask the users."

      To recall Henry Ford: we would be trying to make faster horses instead of cars, then.

  • by Foofoobar ( 318279 ) on Tuesday July 29, 2008 @03:37PM (#24391383)
    Perhaps the most comprehensive guide out there. Not a GUI but if you want a GUI, use Xcode. http://developer.apple.com/documentation/UserExperience/Conceptual/AppleHIGuidelines/XHIGIntro/chapter_1_section_1.html [apple.com]
    • by vimm ( 1300813 ) on Tuesday July 29, 2008 @03:42PM (#24391473)
      The layout of that webpage makes my left eye twitch.. however it was very intuitive and easy to use, and suddenly I crave IPHONE I MUST HAVE IT
    • Only useful for Mac OSX applications.
      For Windows applications follow Microsoft's guidelines (even though they ignore it and it's quite difficult because of the many differences between each Windows version).

      Simple rule: keep the UI consistent with the interfaces of the other applications that run on that system.

      • Considering how well VISTA worked out, I wouldn't even say that Windows guidelines is even good for Windows.
  • Paper Prototyping (Score:4, Insightful)

    by mpapet ( 761907 ) on Tuesday July 29, 2008 @03:38PM (#24391397) Homepage

    http://en.wikipedia.org/wiki/Paper_prototyping [wikipedia.org]

    Now, that may not actually address the problem. UI fights are intractable with **everyone** having an opinion and more than willing to resort to all kinds of dishonorable methods of getting their way.

    The next step of the process should be interviewing as many paying users as possible, face to face, paper and pencil ready. From those interviews see if you can find some similarities and go from there.

    • Paper Prototyping is the way to go.

      NO UI designer is smart enough to know what users will do when they get hold of your designer - because it's not a problem your designer can solve with smarts. You MUST test prototypes with users.

      Sometimes you need domain-SME users (all I'd want if I was doing a medication dispensing system or an Air Traffic Control system).

      For many non-mission-critical things (phone number entry and validation is a perennial...developers always want to screw this way the fsck up for users

  • Just Use It (Score:5, Insightful)

    by The Good Reverend ( 84440 ) <michael@mi[ ]is.com ['chr' in gap]> on Tuesday July 29, 2008 @03:38PM (#24391401) Journal

    Nothing beats using it.

    Years ago in my tech startup days, I remember spending hours just using our about-to-launch web application, doing my best to break it. Things are a bit different when you're not web-based, but doing this on a variety of computers is still a good way to find bugs, note slowdowns, discover any issues with running it concurrently with other software, etc. This is also a nice (and sometimes fun) way to involve ALL of your staff -- not just IT -- because there's going to be a wider variety of user experience levels there.

    • Re:Just Use It (Score:5, Informative)

      by sm62704 ( 957197 ) on Tuesday July 29, 2008 @03:49PM (#24391603) Journal

      useit.com [useit.com], Jacob Nielson's site. Everyone having anything to do with interface design should read the whole thing.

    • I remember spending hours just using our about-to-launch web application, doing my best to break it.

      I don't think the OP is asking about "durability" of the UI, if that term exist for software. I think he/she is asking about how to make it intuitive. The creator of a product always thinks the fruits of his/her labor is intuitive. It's best left up to a third party to determine how intuitive the product is.

  • CUA/CUI specs (Score:5, Informative)

    by RobertM1968 ( 951074 ) on Tuesday July 29, 2008 @03:41PM (#24391451) Homepage Journal

    There are CUA guidelines for various operating systems. You can check out that documentation to determine where what components/options you have should be placed. They are pretty thorough.

    IBM's was written in 1987, and updated since (and followed for the most part in the Windows and OS/2 world).

    Microsoft's has of course recently changed with the advent of Vista and related v2007 programs.

    For broadest use, I would choose the specs used in later versions of Windows for Windows based apps... for Linux, I am not sure where you would check - but am sure some sort of guidelines should exist someplace.

    A place with links and references to IBM's CUA can be found here:

    http://en.wikipedia.org/wiki/Common_User_Access

    From there, or with similar searches, you can find references for related Windows CUA stuff

    • Re:CUA/CUI specs (Score:4, Informative)

      by RobertM1968 ( 951074 ) on Tuesday July 29, 2008 @03:52PM (#24391655) Homepage Journal

      For broadest use, I would choose the specs used in later versions of Windows for Windows based apps...

      Should have read (changes in bold):

      For broadest use under Windows, I would choose the specs used in later non-Vista versions of Windows (such as XP) for Windows based apps...

      and (added)...

      The CUA references should have everything including such things as keyboard shortcuts, etc (as well as main menu placement... ie: always starts with File, Edit, View - and ends with Help).

    • By Chris Espinosa, Joanna Hoffman, et al. The manual was called Inside Macintosh, the draft I received is dated 1983, lovingly daisywheel printed, and apparently it's what the rest cribbed from (Command-Z,X,C,V for Undo, Cut, Copy, Paste was one of the rules established by IM).
  • by matrix mechanic ( 893601 ) on Tuesday July 29, 2008 @03:41PM (#24391457)
    Umm... the only way to know if one way of doing this is better or worse in UI is to try it. Look up the term Guerilla User Testing or read Don't Make Me Think and follow his approach. This is pretty standard practice on the web. Woe to rich client GUI if what you described is standard in that area.
  • Uh... (Score:5, Insightful)

    by SatanicPuppy ( 611928 ) * <Satanicpuppy@@@gmail...com> on Tuesday July 29, 2008 @03:42PM (#24391471) Journal

    Not sure what you're getting at. If your action listeners are screwed up, that's an obvious problem with a straightforward solution, but if your UI just plain sucks, no program is going to tell you that.

    You need to go find someone with aesthetic sense, and a minimum of technical knowledge, and you need to shut up and listen to them whine as they use your UI. When you've fixed enough stuff that they stop whining, bring in a couple more and listen to them whine. Eventually they won't whine, and at that point, you'll know you've got a good interface.

    For gods sake though, don't get a fricking committee involved! They will all want to make a trivial change to put their mark on it, and all those changes will turn your unpolished interface into the sort of steaming crapheap that wouldn't meet the basic user-friendliness of the interface on a piece of stereo equipment.

    So yea; get the users involved, distill their complaints, make changes, NO COMMITTEES. And the simpler the better. I should write a UI testing program that just runs for 10 minutes and then pops up, "Your interface has too many buttons. Simplify it please." The interface can almost always be simpler.

  • by Stormwave0 ( 799614 ) on Tuesday July 29, 2008 @03:42PM (#24391479)
    While it's not a tool, Joel Spolsky has written a long and detailed series of articles on how to correctly design a user interface. It's worth your time to check it out, even if it doesn't speed things up.

    Here's the first chapter [joelonsoftware.com]
  • by sm62704 ( 957197 ) on Tuesday July 29, 2008 @03:43PM (#24391487) Journal

    There's no way software can design or test a user interface. Use smaller design teams, and make sure there is at least one expert in useability.

    It doesn't sound like you're doing too much too wrong.

  • Just because the problem is common and recurring doesn't mean it must have a neat solution. It could be a (np hah!) hard problem. With respect to UI review, I believe this is the case. It's just *hard*. I have not seen very many short cuts work in this area. The best advice I can give you is to listen to your users. Also, UI by committee has not been the easiest path in my experience. We have found that putting someone in charge of the UI, with respect to standards compliance is important, and that t

  • by Thelasko ( 1196535 ) on Tuesday July 29, 2008 @03:47PM (#24391551) Journal
    used the number of mouse clicks to perform any given task as the metric to determine if Office 2007 had a good UI. It seems the impact of that choice is debatable.
    • Depends on who you are trying to make the app more usable for, which depends on what kind of app we are talking about.

      If the app is a web site targeted to the general populace and has lots of new/casual users, then more important than mouse clicks is how easy it is to navigate to various tasks. Watch a few uninitiated users use your application. Give them tasks without telling them how to accomplish the task. See how they perform. I'll bet you'll find your problems that way.

      If the app is for a set of us

    • So by that token, is a huge toolbar with buttons for every possible function more useful than a two-level hierarchy of well-organized menus?

    • Microsoft did more than that. They took the statistical data that they compiled from real-world users who opted in to "make future Office better" and used it to determine what features and functions were used most often, and prioritized their efforts on re-working the interface for those features based on that.

      One of their leads gave a talk recently on the story of the evolution of Office's interface, starting from Word 1.0 through Office 2007. It's worth watching:

      http://msstudios.vo.llnwd.net/o21/mix08/0 [llnwd.net]

  • Windows can be made to quickly reshaped to the Aspect Ratio [wikipedia.org] of the screen.
  • Director (Score:4, Informative)

    by lax-goalie ( 730970 ) on Tuesday July 29, 2008 @03:53PM (#24391677)

    A ton of commercial (and in-house) applications have had their UIs prototyped with Macromedia (now Adobe) Director. Especially with a third-party "xtra" called OSControl (which gives you access to OS-specific, well, controls like menus, tabs, etc.), Director makes building a UI prototype quick and easy.

    Director's a little long in the tooth for real desktop application development. Still, I'm not sure that there's another tool that lets you build "quick and dirty prototypes" (with enough functionality to actually test with users) as rapidly as Director.

    Avoid the latest version (Director 11) like the plague, though. It's an abomination.

    BTW, as a process issue, a "look and feel prototype" is always one of the earliest milestones in our development cycle. The client has to sign off on the interface, and write a check for a progress payment, before we proceed into actual code-slinging. Saves a boat load of headaches to do it this way.

  • Don't let developers do it.
    Hire a professional to give you a framework, build from there.
    Having a common framework will allow you to know when any screen is wrong, and it will be easier for your QA team to find errors.

    • Don't let developers do it.
      Hire a professional to give you a framework, build from there.

      So you're saying that developers aren't professional? Or that developers can't build a framework?

      • by pjt33 ( 739471 )
        I interpreted GP as saying that developers aren't professional GUI designers. In the majority of cases this is true.
  • by Black-Man ( 198831 ) on Tuesday July 29, 2008 @03:58PM (#24391751)

    We hired this company, who $3mill later gave us a wireframe mocked up in Photoshop of what the UI should look like. The execs LOVED IT. One problem... the tools which had already been decided on and purchased couldn't produce anything that looked remotely like the mocked up UI. Guess who got blamed? Management? No. Developers? Yes. Because they couldn't produce a UI that looked as "cool" as the wireframe.

    • Re: (Score:3, Insightful)

      by panaceaa ( 205396 )

      I hope the conclusion you reached is that developers should be involved in UI design from a requirements perspective. At the very least, the consulting firm should have known what your tools were capable of. Secondly, good UI designers can take feedback like "it would be easier to do things this way," for example, if you already have a UI and you're trying to minimize changes. Your development team should have had engineering management on top of it who were aware of the consulting firm and should have i

  • by Light303 ( 1335283 ) on Tuesday July 29, 2008 @04:00PM (#24391771)

    i habe been reading /. for quite a time now and never read the word "usability" ever. (i think most FOSS guys also never heard of it)

    Interface Usability is a whole science. There are plenty of books describing exactly what you are trying to reinvent!

    For a start you might want to check out Jakob Nielsen's Alterbox Website, which is full of small articles regarding common usability problems.

    http://www.useit.com/alertbox/ [useit.com] ... and if you like his style of writing you might also want to buy his book "Usability Engineering" (which is a must-have when you work in the field of usability IMHO)

  • First of all, it sounds like you have way too many people involved in the UI decision-making process. You need the UI architect/lead, the guys who are gonna implement it, and an end-user or two (or maybe QA guy if you don't have any end-users around). That's it. Non-technical bosses don't need to be involved, marketing doesn't need to be involved, technical co-workers who don't have a hand in implementing this don't need to be involved (that includes other UI programmers). Meeting bloat was the biggest headache I had at my old job; we ended up designing our UI essentially by committee, and it sucked.

    As far as a UI overview, again, there's nothing better than testing by actual end-users. Try to convince your boss to let you demo an early-ish prototype to real customers. If you can't, then hallway testing [wikipedia.org] is probably the next best thing. If a random cross-section of people can manage to perform simple tasks through your UI, your customers shouldn't have much trouble doing the same thing.
  • Form follows function.

    You first have to work out the flow of the program (or web site). Which options are on which screens? What's on the list that takes a user to a detail page? Is the delete button on the list or on the detail page?

    For the above, I found the best way is paper, pencil, pushpins, and yarn. Find a big wall in a conference room, and start sketching it out. Quickly draw the data elements and input fields on the paper. Use one piece of paper for each web page. Use pushpins and yarn to show ho
  • Simple is often best (Score:5, Informative)

    by viking80 ( 697716 ) on Tuesday July 29, 2008 @04:16PM (#24392035) Journal

    1. Define what the software should do
    2. Make the UI, even a mockup will do
    3. Invite users to test drive the UI while video taping
    (See (1) and ask the user to do each one(with no help))
    4. Measure the users success (clicks, wrong clicks etc)
    5. Score each screen with the predefined metric from (1) filled inn in (4)

    Done.

    Often the real problem is that nobody really knows (1): what the software should do. Marketing thinks it is "one click purchase" and engineering thinks it is "fully configurable shopping view". So agree on 1 first, and maybe your problems go away.

    • by Speare ( 84249 )

      1. Define what the software should do

      No.

      1. Define what the user's goal is

    • There are about ten million tools you could use now to mock up a UI in almost any language.

      Just being able to press on a button that does nothing tells you more than a screenshot ever can.

      You don't even have to use the mockup in any way in the final product, but let a user or designer be able to sit down with the UI arranged as people think they would like it to start with and then evolve.

  • We trimmed 1/2 of the the stuff they had available. You know what they said? "too busy" People want an app that has capability to do anything imaginable, yet the simplicity to do what they need right now. I say KISS.

    Keep it simple software

    -DW

  • Although some might say he has become much less rigorous on the UI side, Jakob Nielsen has some good ideas on this subject. This book might provide some clues.

    The basis of this book, and of most writing on UI, is that the designer can only do so much. Once a best effort is made, the interface must go into usability testing. The interface decisions then need to be made on the basis of these tests, not on the whis of the designers. p. It also sounds like The Mythical Man Month might be in order, and a d

  • You need an expert (Score:5, Insightful)

    by rossz ( 67331 ) <<ten.rekibkeeg> <ta> <ergo>> on Tuesday July 29, 2008 @04:27PM (#24392199) Homepage Journal

    If your UI has gone beyond the most basic of interfaces, you need to hire someone who has a background in "human factors". Expecting a bunch of programmers to design a good user interface is a very bad idea. Just look at all the crappy interfaces in the open source world.

    Hoping for a program to automate this is as likely as getting your own pet unicorn.

    • Re: (Score:3, Interesting)

      Yes, parent is exactly correct. On a very large project we were running, we actually hired one (maybe it was two) "human factor engineers". As I recall, the woman had a PhD in human factors and was extremely useful in putting things in perspective.

      If you're on a large project with a correspondingly large budget, an HFE will be money saved, in order to free up the time of your developers.

      Human factors is one of the most overlooked aspects of an app, and having a programmer design it is bad for a nu
  • Go ahead. Try it. No matter how hard you rub, no matter what compounds you use, when you try to polish a turd, the net result is a pile of shit.

    If any part of the project is crap, the end result will be the same no matter how much testing and tweaking you do. Good luck.

  • You needs a very small team that understands what the product is supposed to accomplish, not how it is supposed to accomplish it. The user interface flows from there.

    From http://www.counselormagazine.com/content/view/674/55/ [counselormagazine.com]

    It was 1995 and a man was walking around with a wood block in his shirt pocket. Occasionally he would take it out and fiddle with it as if he were checking appointments. Some might have thought him crazy, but he was not.

    The man was Jeff Hawkins, and he would soon revolutionize the technology industry with a device known as a Personal Digital Assistant, or PDA. It would be called the Palm Pilot and sell over one million units in its first 18 months alone. Jeff Hawkins didn't invent the PDA, but his Palm Pilot would be the first to attain widespread acceptance. There were other PDAs before the Palm Pilot: Apple produced one that came to be called the Newton in 1993, but it failed to achieve the success of the Palm Pilot due to its high price and the fact that it was just too large to fit inside a pocket; a Windows-based PDA was introduced around the same time as the Palm Pilot, using a software called Windows CE, which enabled one to open and create Word Documents and Excel Spreadsheets. The interface resembled Windows 95 with the familiar Start menu. Unfortunately, these devices were much more expensive and drained way too much battery power.

    The block of wood in Jeff Hawkin's pocket represented an approach to design that would serve him well. He did not want to just design yet another electronic gadget, but something that was eminently usable; a tool. His experiments with the block of wood helped him to determine the right size for the Palm Pilot -- small enough to fit in a man's shirt pocket.

  • Your code shouldn't have high coupling, neither should the UI. Organized by role/user, by usage, the UI probably doesn't need to let your users do super-cross-functional things in the same bit of screen real-estate. If the UI does need to let your users do super-cross-functional things in the same bit of screen real-estate then the coupling is really just cohesion + complexity, deal with it.

    If you can get rid of UI coupling, you only need subsets of the UI team on the reviews.

    And you'll end up adding in UI

  • by dpbsmith ( 263124 ) on Tuesday July 29, 2008 @06:07PM (#24393489) Homepage

    Use a rapid application development package... Visual Basic is fine for that job, even if I lose all credibility by saying so... and do a mockup.

    Get a few users. They should be people who are not members of your group. They should be vaguely typical of the people who will really be using the real application. They should not be managers or anyone with power to dictate their preferences as requirements.

    Give them absolutely minimal directions. Let them try to use the application. Watch them. Resist the temptation to say anything unless they get so very stuck that there's no longer any hope of learning by watching them; then coach them just enough to get them unstuck.

    See what they do. See what they assume. See where they make mistakes. I guarantee you you'll learn more in ten minutes than in hours of having people familiar with the code review slides. The places where you think they'll get stuck are the places they'll breeze through. The places where they do get stuck will surprise you completely. And you'll suddenly see glaring, obvious, easily fixed goofs in the UI design that you didn't notice in any review.

    If you want to do a big formal megillah with one-way glass and video typing and people with psychology degrees, fine, but that's not important. The important thing is real users really playing with a functioning application.

    Reviewing slides is nuts. Having people who develop the application review slides is nuts. You can't possibly figure out how something is going to work and feel by looking at slides. It's like figuring out whether a car will be fun to drive by looking at a static picture of the dashboard.

    Some years ago someone was showing off an application... one of those GUI-like database applications that ran on character-oriented screens... that his group had done. I was playing with it. He was bragging about the screen refresh, the way they'd implemented scroll bars with characters, and so forth.

    I noticed that three successive screens required me to key in the identical piece of information three time in a row. I also noticed there wasn't even a copy-and-paste function.

    I pointed it out to him. He said, "Yeah, I know." I said "Are you going to fix it?" He said, "No." He whipped out a 3/4" thick spec. He said "It took six months of review to hammer out this spec. It's done. What you saw is what the spec says."

    I said "You mean nobody noticed that problem during the review?" He sighed. "Apparently not."

    "Well," I said, "why not just fix it?"

      "Look," he said, "it took six months to get this spec signed off on, we're not going to open it again or it will take more months, we need to get this through SQA, and what SQA will be doing is checking to make sure we conform to this spec.?

  • You're letting developers write a user interface? Congratulations, your user interface will be riddled with little inconsistencies, bizarre error messages, labels that don't make sense, input that's too permissive or too restrictive, and just plain weird layout.

    If you call them "UI developers", you're just lying to yourself. They are developers. There's nothing UI about them.

    You need to hire a human interface expert. They know how people work with computers. Your developers, on the other hand, know how

  • What, you're not using agile/rapid development tools/techniques??
  • by v(*_*)vvvv ( 233078 ) on Tuesday July 29, 2008 @07:35PM (#24394363)

    A good UI is not cute, cool, or pretty. It is one that makes
    functionality obvious while itself remaining invisible.

    You can make a good UI cute, cool, or pretty, and you may get praises
    for it, but it isn't what makes it usable.

    There is a fundamental paradox is usability testing. If you ask about
    usability, you are asking what people notice. But the best UIs are those
    that are not noticeable. You should never test a UI. You should only
    test the usability of the application, and measure things like confusion
    and task completion speed.

What this country needs is a dime that will buy a good five-cent bagel.

Working...