Lessons from the failure of RIA projects

Author Abel Avram translator ben Linders published on July 22, 2009 11:6 A.M. Community Architecture, Java theme Usability, user interface, RIA, rich client/desktop

Anthony Franco, chairman of the Effectiveui company, recently made a speech called "10 ways to fail RIA Projects", providing 10 suggestions for those who want the RIA project to fail. The SAP AG's Gerd Waloszek summarizes the 18 golden rules of the bad user interface.

Here are 10 counter-recommendations provided by Franco and explain why you should avoid them and how to do it: If you want to fail, don't understand that end-user --70% It project failures are due to user acceptability issues. If you want to fail, trust the developer to make the right design decisions . Developers are forced to make bad designs because their workloads are determined by the amount of functionality they have done. When a project is nearing a deadline, developers will focus on removing functionality rather than thinking from the end user's perspective. If you want to fail, expect a silver-bullet design. a good idea is worth affirming, but a great feature recommendation should not replace the excellent healthy UI design. If you want to fail, then meet the needs of all. "If a company tries to create a product for everyone, it won't last for anyone." If you want to fail, start the project and forget about it. after the project is launched, the product needs more iterations to be perfected. If you want to fail, then don't define success. not defining success means not knowing what the goal is. If you want to fail, avoid conflict. conflict is not necessarily a bad thing, because "there is no progress without conflict". When everyone in the room agrees with a certain view, it is necessary to be more vigilant. If you want to fail, believe that you don't need to sell your ideas. stakeholders should try to sell their ideas within the organization, but do not expect to be accepted just because they originate from you. This needs to be prepared to answer questions like the following: What is the return on investment. The advantage is what. Why do you do it now? What happens if you don't do it. If you want to fail, then pursue perfection. you should not plan everything in the first place and expect reality to follow the plan, because change is everywhere. If you want to fail, focus on the process more than the product. This suggestion can be rewritten as: "If you want to fail, don't risk it." We can attach great importance to the development process, but "it makes no sense to produce a bad product on time", and it is easier to build a satisfying product by iterative methods.

The following is a Waloszek summary of the bad user interface 18 Golden rule, which provides a negative example:keep customers busy with unnecessary work--Let the user fill in the data in some controls, and then prompt them not to enter data there (for example, an app lets you fill in data on holidays or weekends, and then suggests that you can't work on those days).non-compliance with standards--Do not place menu items in the usual categories and locations (for example, place the Save button on the Edit menu).make the software run slowly-There are countless possibilities for software to run slowly. For example, you can include long-time validation or switching after each user input. Or you can force users to browse through a series of dialog boxes.use abbreviations whenever possible, especially if there is enough room to display full words--use "dat." Instead of "date", "tolky" instead of "tolerance Key", "Nxob" instead of "Next Object", there's a lot more ...Guide users with technical language--Send URL using UTF-8 format (requires reboot in advanced settings of MS IE)hiding features that are important and common to the user--Hide it in a menu that the user will never find.Let your app support only the mouse--never provide any keyboard shortcuts。use your app to become a challenge--even if the user's actions cause serious consequences, they are not prompted.out of the end user-Many users have a lot of choices, you only provide one. This can be achieved faster and simpler.Advertise a bad example-Just listen to the other golden rules on this page.spend a lot of effort setting bad default parameters: Contrary to user expectations, the default configuration is extremely bad, disgusting, useless-you decide anyway--Default settings on Web Forms allow users to receive unwanted news or ads, distribute their addresses, and so on.destroys the work context after each system Restore--Cancels the selected screen element before the system restarts.ignoring features that make the user more convenient--making them hard--When users need to add entries to the list, only allow them to insert entries at the end of the list, and then let the user move the entries to the correct location. In other words, no additional functionality is provided for inserting entries directly into the target location. To add spice, when the user moves the item directly to the target location, the app prompts for some bogus errors and then inserts the entry at the end.do not allow users to interrupt processes that consume time and/or consume resources--secretly starting a backup or indexing process, making it difficult for users to cancel, that is, ignoring the user's mouse click and keyboard operation.Application Illogical--Add a button to prepare an action that allows the user to confirm that the action can be done. Here's a real example: in many e-mail applications, the "forward" button does not actually perform a forwarding operation, but rather does the preparation before forwarding (because we have to provide the recipient's address).one time or another. System crashes or makes apps zombie--Make the editor or edit domain zombie when the user has not anticipated, so that the user has not had time to save their work results, and frequently saved habits will waste valuable system resources.as much as possible to hinder user input--page loading is also a good opportunity to hinder user input. While waiting, the user may chat with the roommate, read a newspaper, or stare at the empty screen in a daze.block user input, even if not necessary--Preventing users from updating thumbnails in the image browser is a good example-there is no reason to prevent users from scrolling, selecting images, or initiating actions.