“Good” Lessons on How To Fail a RIA Project

Posted by Abel Avram on Jul 21, 2009

Sections

Development,

Architecture & Design

Topics

Rich Internet Apps ,

User Interface ,

Rich Client / Desktop ,

Architecture ,

Java ,

Usability

In a presentation called Ten Ways to Ensure RIA Failure, Anthony Franco, president of EffectiveUI, gives 10 pieces of advice to those who want their RIA project to fail. Gerd Waloszek, SAP AG, wrote 18 Golden Rules for Bad User Interfaces.

These are the 10 pieces of anti-advice given by Franco explaining why they should be avoided and what should be done instead:

1. If You Want to Fail, Do Not Understand the End User – 70% of all IT projects fail because of user acceptance.
2. If You Want to Fail, Trust Developers to Make Good Design Decisions. Developers are encouraged to make bad design decision by tracking their work using the number of features completed. When a project is going to miss the deadline, the developers focus on removing features instead of thinking at the end user
3. If You Want to Fail, Hope for a Silver Bullet Design. Great ideas are welcome, but a great feature idea should not replace good, healthy UI design
4. If You Want to Fail, Build for Everyone. “If a company tries to build a product for everybody, it will end up building it for nobody”
5. If You Want to Fail, Launch & Forget. After the launch, the product needs more iterations to be polished and completed.
6. If You Want to Fail, Do Not Define Success. Not defining success means not knowing where one is heading to.
7. If You Want to Fail, Avoid Conflict. Conflict is not necessarily bad, because “there is no progress without conflict.” A red flag should be raised when everyone in the room agrees with an idea.
8. If You Want to Fail, Believe You Should Not Have to Sell Your Ideas. Stakeholders should be looking to sell their idea inside their organization, and do not expect it to be accepted simply because it comes from them. This involves being ready to answer questions like: what is the ROI, what is success for this, why now, what if we do not do it now?
9. If You Want to Fail, Plan for Perfection. One should not be planning all from the beginning and expect it to happen as planned because chances are it won’t.
10. If You Want to Fail, Value Process Over Product. This advice can be rephrased: “If You Want to Fail, Take No Risk.” We may highly value the development process we are using, but “it means nothing to deliver a crappy product in time”, and it is easier to build the desired product with an iterative approach.

Following are Waloszek’s 18 golden rules along with some negative examples that should not be followed:

1. Keep The Users Busy Doing Unnecessary Work - Let users enter data into fields only to tell them afterwards that they cannot enter data there (e.g. an application lets you enter data on holidays or weekends and tells you afterwards that you cannot work on those days).
2. DO NOT OBEY Standards - Do not place menu items into the categories and locations they typically belong to (e.g. place "Save" in the "Edit Menu").
3. Make It Slow - There are nearly unlimited possibilities of making software slow. For example, you can include long lasting checks or roundtrips after each user input. Or you can force users through long chains of dialog boxes.
4. Use Abbreviations Wherever Possible, Particularly Where There Would Be Space Enough For The Complete Term - Use "dat." instead of "date," "TolKy" instead of "Tolerance Key," "NxOb" instead of "Next Object," and many more...
5. Educate Users In Technical Language - Always send URLs as UTF-8 (requires restart) (advanced settings in MS Internet Explorer)
6. Hide Important And Often-Used Functionality From The Users' View - Hide important functions in menus where users would never expect them.
7. Make Your Application Mouse-Only – Do Not Offer Any Keyboard Shortcuts
8. Make Using Your Application A Real Challenge - Do not warn users if actions can have severe consequences.
9. Keep Away From End Users - Many end users have many opinions, you have one. That's far easier and faster to implement.
10. Spread The Message Of Bad Examples And Live It - Just follow any of the other golden rules on this page, that's a perfect start.
11. Take Great Care In Setting Bad Defaults: Contrary To The Users' Expectations, Disastrous, Annoying, Useless – It's Up To You - Set default options in Web forms so that users get unwanted newsletters or offers, have their addresses distributed, etc.
12. Destroy The Work Context After Each System Reaction - Deselect selected screen elements after a system reaction (e.g. a round trip).
13. Leave Out Functionality That Would Make The Users' Life Easier – Let Them Do It The Hard (Cumbersome) Way - When users want to add items to a list, allow them to add items at the end of the list only and let them then move the items to the correct position. That is, do not offer additional functionality for inserting items at their target locations. To add some spice, introduce spurious errors that return items to the bottom when users have already moved them half-way up.
14. Do Not Let Users Interrupt Time-Consuming And/Or Resource-Hungry Processes - Start a backup or indexing process while users are not aware of it. Make this process hard to cancel, that is, let it ignore the users' mouse clicks and key presses.
15. Make It Illogical - Label a button that will only prepare an operation so that users believe that it will already do the operation. Here is a real-word example: In many e-mail applications, the Forward button does not actually forward an e-mail but prepares it only for forwarding (because, for example, the recipient has still to be provided).
16. Add A System Crash From Time To Time Or Let Applications Simply Freeze - Let editors or edit fields freeze at unforeseeable intervals so that users will not fall into the habit of saving their work frequently, which would unnecessarily waste valuable system resources.
17. Block User Input As Often And Long As Possible - Page loading is also an appropriate event for blocking user input. Users may chat with their room mates, read the newspaper, or simply stare at the empty screen during that time.
18. Block User Input Even If It's Not Necessary - Blocking user input in an image browser while it updates the thumbnail images is a good example of this –there is absolutely no reason why users should not be able to scroll, select images, or initiate an action.

Are there other “good” advices on how to fail a RIA project, ones that should be avoided at all costs?

1. Back to top

   Not specific to RIAs

   by Greg Brown

   While these are good (if slightly obvious) suggestions, none of them are specific to RIA projects.

   Reply

2. Back to top

   Earth-shattering

   by Kenny MacLeod

   Should be titled "18 statements of the bleeding obvious"?

   Reply

• Older >