Welcome to Scribd. Sign in or start your free trial to enjoy unlimited e-books, audiobooks & documents.Find out more
Standard view
Full view
of .
Look up keyword
Like this
0 of .
Results for:
No results containing your search query
P. 1
10 User Expectations for a Software engineer

10 User Expectations for a Software engineer

Ratings: (0)|Views: 269|Likes:
Published by Mohan

More info:

Categories:Types, Brochures
Published by: Mohan on Nov 18, 2009
Copyright:Attribution Non-commercial


Read on Scribd mobile: iPhone, iPad and Android.
download as PDF, TXT or read online from Scribd
See more
See less





Version 1.0May 13, 2009
10 ways developers can meetuser expectations and ease frustrations
By Justin James
It’s no surprise that users have expectations that, if not met, make those users angry and frustrated. User-friendlyapplications are much more likely to generate revenue, from sales of the software, sales enabled by the software,or some other revenue model. Yet for whatever reason, a significant portion of applications don't meet userexpectations in a number of areas. Here are 10 common user expectations and what you can do to meet them sothat you'll have a happy group of users.
Accurate data
Nothing on the planet can set a user off like seeing inaccurate data on the screen. “Inaccurate” covers a hugeamount of ground, in the users’ eyes. For example, if a package has been delivered but the courier’s Web siteshows that it is still 200 miles away, that isn’t “out of date” to the user, it is “inaccurate.” Another winner is whenitem information on an invoice or account history has no resemblance to the product that was ordered; this is sureto generate a few frantic calls to the customer service department.The potential for user pain is limitless within this category. Unfortunately, many of the root causes of inaccuratedata are out of the developer’s hands: user error, insufficient information, failure to follow processes, and so on.But enough of it is within our power to at least make a dent in the problem. Make sure that your applicationvalidates all data, contains rules for performing “sanity checks” whenever possible, requires the right data, anduses atomic transactions instead of batch processing whenever possible.
Responsive UIs
If there's one surefire way to make users angry, it’s to put the dreaded hourglass on their screen. For extra credit,block the main UI thread entirely so it doesn't respond to user input and looks like the application is hung. If theydon’t kill the application completely, they sure will be shocked when it suddenly starts to respond like a ghoulrising from the grave (brain eating optional). If you really want to annoy them, have it suddenly process all of theirfrantic clicks and other inputs. Nothing can cause users to fly off the handle like finding out that their work wasdestroyed by keystrokes sent while the application looked hung.Provide them with the experience they expect and deserve: Perform long-running processes in a separate threadto allow the UI to update, give them a progress indicator that makes it clear that the application is not hung, andoffer them a useful and responsive cancel button if possible.
Easy logins
One of the most frustrating things for users is when they don't use a service often enough to really remember ausername -- and the username they have on that service is hard to remember. For example, I use “jjames” formany Web sites, but sometimes that is not available, so I might end up with “jjames6” or something else, and Iuse site only a few times a year. The frustration comes in when I keep trying passwords with the username“jjames” and I forget that this is a site where I have the unusual name. That’s when I start asking myself if I reallyneed the site at all. You should either have a prominent “forgot your username?” system or just use the e-mailaddress, account number, or some other piece of information that is unique to each user but is not an arbitraryusername.
Consistent input
Some Web developers seem to think that it makes sense for the phone number field to have a different input boxfor each part of the phone number and to make the cursor automatically move to the next part of the phonenumber field when the current one is filled. This does make sense in a way, but it doesn't make too much sense tousers unless all of the fields they encounter behave the same way. Do your users a favor and save yourself somework in the process: leave these fields alone or just have the phone number be one large text input.
Page 1Copyright © 2009 CNET Networks, Inc., a CBS Company. All rights reserved. TechRepublic is a registered trademark of CNET Networks, IncFor more downloads and a free TechRepublic membership, please visithttp://techrepublic.com.com/2001-6240-0.html 
10 ways developers can meet user expectations and ease frustrations 
A long time ago, when people went to stores to purchase software in boxes, it was common to have to spend 15minutes studying the box to determine whether it would run on your system. Now, as long as the application runson your OS, it's hard to find a machine made in the last few years that lacks the physical specs to run the non-game applications out there. Nonetheless, application incompatibility still exists. Ironically, it is most common onthe supposedly platform-independent Internet. With the exception of some “must-have” enterprise classapplication, there is no way that a user or organization is going to jump through hoops to make your applicationrun or your Web site work.So instead of driving away potential users, find and fix the incompatibilities. Obviously, that doesn’t mean that aWindows application needs to be made to run on Linux; but it does mean that a Windows application should workon XP, Vista, the upcoming Windows 7, and possibly even 2000. Likewise, your Web applications should work onInternet Explorer, Firefox, Opera, Safari, and Chrome across OSes without a loss of functionality or significantdifferences in appearance.
Reasonable resource consumption
It really does not make sense that a keyboard needs 200 MB worth of software to be installed to work or that asimple text editor should require 1 GB of RAM to run. Yet it seems that more and more applications are hugeresource hogs. It seems like every minor application out there is nearly as large as Microsoft Office was five yearsago... and Microsoft Office itself is now the size that an operating system was a few years ago! Users expectbetter, and so should you. Cut the bloat. Ask yourself if your application really needs 100 MB of stock images ofpeople using their laptops on the beach or 30 MB of custom sound files. Chances are, it doesn’t.
We all know how much developers dislike writing documentation. So we tell ourselves that the application is soeasy to use, “only an idiot would need a manual.” There are two problems with this thinking. The first is that theworld has plenty of idiots in it. The second is that we are usually wrong about how easy the application is to use. Ifyour organization has a technical writer to create the documentation, involve that person from the get-go; the topcomplaint I hear from technical writers is that they are handed a nearly finished product and told to document it,with little insight into how it actually should be used. If you do not have a technical writer available, you will reallyneed to work hard to make sure that the documentation does not merely state the obvious and is written in a waythat will be helpful to end users who are unfamiliar with your application.
No surprises
Some applications are filled with surprises. Of course, the definition of a “surprise” is that users don't expect it. Butat a higher level, users expect that nothing will come at them from left field, either. This covers a lot of territory.Here are some examples of things your application should not do:
Require additional payments or service fees (including cell phone minutes for mobile applications) thatare not made obvious
the user purchases the software in the first place
Install any advertisement distribution mechanisms
Add any browser toolbars, Outlook plug-ins, or other “helpful applications or add-ons” to the system
Delete or modify user data or system files, including libraries
Send or capture usage data or personal information, for marketing or technical purposes, without theuser’s knowledge and consent
Replace the current default applications for tasks without explicit user confirmationWhile many users probably won’t notice at least a few of these, and many users won’t raise a big stink about it, itis still wrong. Users don't like it. After all, do you like it when applications behave like this?
Page 2Copyright © 2008 CNET Networks, Inc., a CBS Company. All rights reserved. TechRepublic is a registered trademark of CNET Networks, IncFor more downloads and a free TechRepublic membership, please visithttp://techrepublic.com.com/2001-6240-0.html 

Activity (4)

You've already reviewed this. Edit your review.
1 thousand reads
1 hundred reads
manoji liked this
yoshi594 liked this

You're Reading a Free Preview

/*********** DO NOT ALTER ANYTHING BELOW THIS LINE ! ************/ var s_code=s.t();if(s_code)document.write(s_code)//-->