Slashdot Mirror
Software, Tools, Or Techniques For UI Review?
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."
Too many cooks, as it were.
The simple truth is that interstellar distances will not fit into the human imagination
- Douglas Adams
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.
Those who believe the Internet is private,
find their privates are on the Internet.
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
This is my sig. There are many like it but this one is mine.
http://en.wikipedia.org/wiki/Paper_prototyping
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.
http://www.maxineudall.com/2010/02/should-economists-be-sued-for-malpractice.html
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.
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
StarTrekPhase2 - The Five Year Mission Continues!
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.
ad logicam Claiming a proposition is false because it was presented as the conclusion of a fallacious argument.
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
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.
One of our competitors trademarked the term "hypothesis". From now on, we will call them "boneheaded ideas".
And an app designed to help: http://silverbackapp.com/
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/ ... 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)
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
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:
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.
Just callin' it like I see it.
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.
don't cut it off www.mgmbill.org
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.
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.
-- Will program for bandwidth
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.
Wise men say, "Forgiveness is divine, but never pay full price for late pizza."
Give the program to the average secretary & watch where she stumbles or otherwise looks confused.
The government is not your daddy. Its purpose is not to raid middle-class neighbors' wallets and give it to you.
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.
If you believe everything you read, you'd better not read. - Japanese proverb
Comment removed based on user account deletion