How much of an impact does a faster application count considering the competition, or does features trump everything? Where is the balance point, and for what type of apps?
-
It depends - if it's a feature they need, then that feature will decide it. Application speed is a feature, after all.
From Richard Franks -
I can't think of a case where you'd want a slow unresponsive application. I also can't think of a situation where you'd tell a client you can't have feature X. As a developer I have always been able to find a way to implement the features the client wanted and still have responsive application.
-
Users buy based on how many features an application has, and will bitch bitterly and endlessly about any features your application lacks that $OTHER_APP has. But if you add so much as a single new button, they will immediately complain about how bloated the app is getting and how much better the old versions were.
This is why you should ignore anything your users ask for. Make a program that you enjoy using. Assuming you're not insane, that will result in an application other people like as well.
From John Millikin -
I think most users use what they're told to use. Acrobat Reader, Word, Internet Explorer, Outlook Express. These experiences are so bad that many users have no confidence in software at all, and they're not likely to try alternative products.
But other users, who are not too jaded to try something else, discover that the grass really is greener. These users will look for a program that not only does what they want, but does it better than another program. And these are the users who download third-party applications like yours.
In other words, yes, the users who are going to bother with your program are going to care about its performance!
I totally don't know this, by the way. This is based on the users I know, myself included.
From Kevin Conner -
Users complain more about full-featured applications being slow than they do about fast applications being limited. That's because not many people use applications that don't do what they want, no matter how quick they are - you don't complain about software you don't use.
From Jim -
IMO, the type of apps will affect the balance you are talikng about. If you are developing software for customer, then you might want to consider the kind of feature your product would have as customer ussually looks for the feature of the product to make a buying decision.
But if you are developing software for your own company e.g internal use then is better to judge how each feature affect the performance during the requirement gathering phase. Highlight to your manager or your audience if they want a certain feature that will affect performance. It will be better for them to bear the consequences rather you take the responsibility when the apps are slow after implementation.
Just my 2 cents.
From smalldream -
I worked on a deathmarch, re-architecting a web application that novice Java "programmers" had mangled which hardly worked at all. About 80% of their code was thrown out, and the 20% or so that did work was kept, because we had a (at least twice!) extended deadline to meet. So, while that 20% code did function properly, it was (and still is) crap and causes the application to run very slowly (for instance, when it pulls from a database, it PULLS from the database...if it says it found 10,000 records, it PULLED (in some cases records may have been created in Java to fill in the blanks) 10,000 records!
I realize this little diatribe may seem off the point of the question at first, but I'm getting to that.
Certain code was shared between three sections of the application. For codenames, we'll call them L, P and E. L encompassed E as E is just a subsection of L, and P used similar data but was not exactly the same. The searching functionality for L, P and E all use the crappy search behavior described above: pulling essentially all those records from the database each time a search is executed.
The requirements stated that a user should have a 30-day window in which to search for L, P and E data. Because L and P were the most important (and you could get to the E data by searching for L), and because of some weird requirement changes/unchanges, the E section was the least priority section of the three.
When all was said and done, the E section functioned somewhat properly...except that the end date was not verified by the validator, meaning that anyone searching for E data could put in a valid begin date, and search the database from that point forward.
The users of E discovered this quickly, and LOVE IT. Despite the fact that it takes tons of time, the users love the additional functionality of being able to search for such a long amount of time, so much so that the application support lead, when being told of the bug, knew that the users liked it so much that they would be very upset if we took this ability away from them.
So, features do tend to overcome speed issues, if they are useful features, which a essentially unlimited database date range lookup is.
From MetroidFan2002 -
Unless you're working on an app for programmers, you're asking the wrong people ;)
Seriously, though, my point is that the best way to find out whether your users value features or speed is by doing user research and usability studies. Usability is often a balance between learnability, efficiency, prevention of errors, etc. Figure out likely use cases and let them guide you, but follow up by watching actual people try to use your app.
From Jason Morrison -
As usual, it depends.
Take web search as implemented by Google as the case for performance is king (I'll let someone else build a case where features at the expense of performance rule the day).
Users expect server response time with those yummy query results within a second or two - this is critical.
Effect of page response time study in 2006:
It found 75% of the 1,058 people asked would not return to websites that took longer than four seconds to load. http://news.bbc.co.uk/1/hi/technology/6131668.stm Now what percentage of Google customer use the Advance search features.
Now, how many people do you think use Advanced Search at all?
Search Usability article:
In our recent search study, the mean query length was 2.0 words. Other studies also show a preponderance of simple searches. Most users cannot use advanced search or Boolean query syntax. http://www.useit.com/alertbox/20010513.html
So one could argue the goal is: Performance that retains user's attention + Fewer, smarter features (not greater quantities of them–get thee back, feature creep!).
From micahwittman -
For the majority of users, neither! Flashy boxes and hype are what sells, most people don't reasearch before they buy.
From William Keller -
Depends on the application.
Sometimes a good UI with a few well organised steps can feel faster then using an application that has faster response but more complicated UI.
It is all about trade offs and the type of users.
From Leah
0 comments:
Post a Comment