> -----Original Message----- > From: Mickael [mailto:[EMAIL PROTECTED] > Sent: Sunday, March 13, 2005 9:51 AM > To: CF-Talk > Subject: OT - UI problems > > Hello All,
First off you might consider posting this to cf-community - the discussion there could go much farther than here. > My developer and I are working on a CMS for various clients. Our clients > keep coming up with new requirements as the project grow or change. We > are not having any issues meeting these requirement for new functionality > on the website. But in my opinion we are not achieving an elegant and Scope creep without planning will kill an interface very quickly. Any elegant interface can have features nailed on, but doing so will quickly spoil the original plan. > easy to use interface. As I review the interfaces I am finding that they > are very configurable, very scalable yet I feel that they are written for Highly configurable interfaces almost always indicate a poor initial design. In my experience at least people spend way too much time on "skins" and interface customization and not nearly enough on the basic, default interface (which most people will use). An interface that's easy to use but only minimally configurable is vastly preferable to a difficult interface than can be customized. > programmers or people of a technical background which kind of defeats the > purpose of creating a CMS in the first place. I am sure that many people > on this have faced the same issue. Can any one suggest a good resource > for making easy to understand user interfaces, books, sites anything. Oh... there are thousands upon thousands of resources. For many Jakob Neilson's work (his books and the materials at http://www.useit.com/ ) is considered dogma. It's a great place to start, but you do have to climb over his ego to find the good information. ;^) His book "Homepage Usability: 50 Websites Deconstructed" is an excellent "coffee table" book that discusses in brief fifty web home pages. It's not as applicable to application development, but is still fairly applicable to most web application development. An older book of his (recently reissued) may be most useful: "Coordinating User Interfaces for Consistency". It's an excellent book but it is dated (it was first written over 10 years ago). Alan Cooper's book "About Face: The Essentials of User Interface Design" is excellent and presented from a application, rather than web, standpoint. It's very good. Edward Tufte's books on information visualization ARE dogma. Although are not directly related to software usability nearly every word of them are applicable. Steve Krug's "Don't Make Me Think" is short, easy to read but still thought provoking. It focuses on the simplicity of web interfaces and how to maintain that simplicity without losing features. For basic usability materials (mostly focused on accessibility and such) there's no better resource than http://www.Usability.gov. The publications available from the Microsoft Usability team are excellent all-around: http://www.microsoft.com/usability/publications.htm I Macromedia's area was larger, but it's still good: http://www.macromedia.com/devnet/topics/usability.html Finally there is at least one great resource for finding other resources: http://usableweb.com/ > BTW if anyone feels that they are an expert in this field I am also open > to paying for Consulting in this matter. Well... I'm a professional in the field, does that count. ;^) If you want to talk more then I'd be happy to, but for now here are some common issues you might want to consider: +) Consistency is king. Across the board one of the most common problems is that the interface is inconsistent. Inconsistency leads to confusion. Labels should be consistent (and simple) and, if possible, short. They should also be consistent in concept: avoid mixing verbs with nouns for example. Values and widgets should be consistent: text areas, input fields and values (dates, numbers, money values, etc) should all be in the same format. Don't show a pop-up calendar for one date, for example, and not for others. Lastly be consistent with the environment: the OS, the browser, other applications in a suite, etc. There's an old usability adage: Err on the side of consistency unless you can improve usability by more than 100%. In other words a de facto standard, even if wrong, should be adhered to unless you can more than double its effectiveness. +) Context is Queen. Context is the state of the process and the needs to complete it. When doing an "Oil change" process the "drip pan", the "filter wrench" and the "box wrench" are all in context for the process and need to be readily available for the process to go smoothly. Many applications suffer from the lack of context management or bad attempts at context management which leads to inconsistency and interface clutter. The latter is the worst and a personal pet peeve). This happens when somebody says "well... wouldn't they want to do X here?" Often the thoughtless answer is "well, let's put an X button right there". The problem is that X is almost always something that needs to be considered further or is itself compromised by being called in-process. Often the real answer is a serious look at the procedural methods of the application, but since most people leave usability to the last minute this can't be done. You should always be VERY wary of adding controls to designed screens after the fact. The need to do so almost always results from a lack of upfront usability or a client misunderstanding of the designed process (which is generally a result of poor communication). Whenever you hear a client say "we should add a button for that here" it indicates some communication break down. Either in requirements gathering or in design or in a failure to completely prototype. It should throw red-flags up immediately. +) Follow the silly rules of thumb - they're not so silly. The first is "KISS" (Keep It Simple, Stupid). Whenever you consider adding complexity spend some time and consider whether it can be done in some other way. Also don't add "predicative" features (unless their both very easy or can be hidden). By this I mean don't add a feature with the reasoning "they'll love this"; don't predict that something new will used: ask first. The second is "The 80/20 rule" (although I think it should be the 90/10 rule). This rule states that 80% of your user base will use only 20% of the features available. In other words you need to identify those features/processes that are most uses and focus all of your energy there when you have to choose where to focus energy. These processes make up a small segment of the application, but account for most of its use - make sure they shine. Lastly identify early your "One-percenter problems" these are problems, process, challenges, whatever that will be used by a very small number of users ("less than 1%") but can often take inordinate resources to complete. These problems should never be allowed to compromise your main functions or processes. +) You can't successfully do usability after development has begun. Although you can fix many problems with application after the fact it will generally cost more. Usability should be first on the table. Prototypes and wireframes should show the client exactly what the application will look like and do allowing both parties to sign off on completely understood specifications. I here this a lot "we're going live with an application in a week, can you do a usability review of it?" Sure, of course I can! But can they fix any problems found before the release date? +) Make sure (if at all possible) that you're talking to the actual users, not just their business representatives. In other words make sure that people that actually perform the task at hand are reviewing the planned workflow. Even if the business reps are great you're still going to get misinformation simply because it's being channeled through an intermediary. In the worst case scenario you may also find that you're dealing with business reps that feel they know what's "better" - those kind of people can kill a promising project in its tracks. There are, of course, are lot more things to do, but the key is really to know what you're doing, start early and talk to the right people. Sorry for writing a book here. The whole topic is near and dear to my heart. ;^) Jim Davis ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Logware (www.logware.us): a new and convenient web-based time tracking application. Start tracking and documenting hours spent on a project or with a client with Logware today. Try it for free with a 15 day trial account. http://www.houseoffusion.com/banners/view.cfm?bannerid=67 Message: http://www.houseoffusion.com/lists.cfm/link=i:4:198606 Archives: http://www.houseoffusion.com/cf_lists/threads.cfm/4 Subscription: http://www.houseoffusion.com/lists.cfm/link=s:4 Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=11502.10531.4 Donations & Support: http://www.houseoffusion.com/tiny.cfm/54
