|
"Hey, it doesn't matter if it doesn't work. It's easy to use!"
"Hey, this thing works great! I just have to figure out how to use it!"
Chicken and Egg!
|
|
|
|
|
If it crashes every now and then, then it does matter.
|
|
|
|
|
Simplicity wins. I agree.
At the same time, application must be reliable, otherwise I will look for other application.
Application that is easy to use is likey to have a good UI anyways.
|
|
|
|
|
This poll misses one choice:
the ability to handle the user's needs.
Let's call it 'completeness'
|
|
|
|
|
I believe that would fall under "extensibility" considered the fact that you will NEVER cater for all user's needs in the first or second release...
www.kinkycode.com
[Glossary Manager] [AfterThought Backup Lite]
99 little bugs in the code, 99 little bugs,
Fix 1 bug, recompile....
101 little bugs in the code...
|
|
|
|
|
Just as the title says..
John
|
|
|
|
|
Well, it does depend on the app. Something like a real-time video player really needs more speed than reliability. I don't care if a couple pixels are off on a frame or two, but I do care if the thing takes forever to play and looks like it is in slow motion!
But for many other apps, speed isn't much of an issue compared to reliability.
Remember, even if you win the rat race, you're still a rat.
|
|
|
|
|
If your users don't find your app easy to use, they won't use it, and all the other options are moot.
Sonork 100.11743 Chicken Little
"You're obviously a superstar." - Christian Graus about me - 12 Feb '03
Within you lies the power for good - Use it!
|
|
|
|
|
Qualifier: We are talking about general-public apps. Not apps for us nerds.
I eventually chose that option too but I came very close to choosing reliability. Your app can be dead easy to use but if it falls over every 5 minutes then it is no use either. Of course a reliable but hard to use app is useless as well.
So reliability and ease of use?
regards,
Paul Watson
Bluegrass
South Africa
Christopher Duncan quoted:
"...that would require my explaining Einstein's Fear of Relatives"
Crikey! ain't life grand?
Einstein says...
|
|
|
|
|
But an application that fails and requires a user to restart often, is not easy to use IMHO.
|
|
|
|
|
I was very close to choosing "Ease of use". But it's a chicken and egg thing - how will you know what's easy to use until customers actually see it? You can spend all the time in the world designing a UI that you think is great and easy to use. Then you get it out to the customers, and they use it in a totally different way than you expected. So that's when maintainability comes into play - you'll have to be able to change that program efficiently once you realize you got the interface wrong the first go-around.
Remember, even if you win the rat race, you're still a rat.
|
|
|
|
|
Thing is, I do a lot of work (in my spare time) for several doctor's offices. They each use the same software. Not cause its the best even because they like it. They use it cause its the only piece of software that they can use for their specific notes. Its the only thing. Scary, but it kind of kills the "they have to like it" part.
|
|
|
|
|
|
Slow apps suck.
// Steve McLenithan
Cluelessnes: There are no stupid questions, but there are a lot of inquisitive idiots.
|
|
|
|
|
Steve McLenithan wrote:
Slow apps suck.
What? Somebody mentioning Longhorn?
Remember, even if you win the rat race, you're still a rat.
|
|
|
|
|
Slow machines suck
Perl combines all the worst aspects of C and Lisp: a billion different sublanguages in one monolithic executable. It combines the power of C with the readability of PostScript. -- Jamie Zawinski
|
|
|
|
|
Touche;P
// Steve McLenithan
Cluelessnes: There are no stupid questions, but there are a lot of inquisitive idiots.
|
|
|
|
|
Get a bigger whip for your squirrel.
Software Zen: delete this;
|
|
|
|
|
Extensibility means:
1. I can fix speed problems by adopting new solutions
2. I can improve ease of use problems with new interfaces
3. Reliability can be improved swapping out crappy modules for better ones
4. Maintainability is implied--if it can't be maintained, how the heck can it be extended?
4. Good looking UI's can be added later on
5. Efficent use of resources can be dealt with when we get some usage information.
None of the other options covers all the bases.
Marc
Microsoft MVP, Visual C#
MyXaml
MyXaml Blog
|
|
|
|
|
but you would rather make you app easily extensible than easy to use?
if you clients can not figure out how to use it, and it sucks in their daily workflow, then dont care about extensability, they'll get someone else to make the app.
- Anders
Money talks, but all mine ever says is "Goodbye!"
ShotKeeper, my Photo Album / Organizer Application[^]My Photos[^]
|
|
|
|
|
I guess it depends on your definition of extensible. You are implying extensibility by coding standards - I understood it to mean it could be extended by the user or third parties... e.g., skins that can be changed, plug-in DLLs, stuff like that.
Remember, even if you win the rat race, you're still a rat.
|
|
|
|
|
Wow! I was going to post that exact point. I agree completely. Anyone who doesn't understand that simply has not done much desk top development.
"In the final analysis, secularism is little more than another religion the first amendment should be protecting the American people against."
|
|
|
|
|
Well, as of the time of this posting, I'm the only vote for maintainability. I voted it because... no matter how well you think you konw your users... no matter how many features you put in there... your code WILL change. Period. Fact. And the original coders may or may not still be there to help out. So you have to be able to change it in a way that won't introduce a ton of bugs or totally break everything else.
Remember, even if you win the rat race, you're still a rat.
|
|
|
|
|
Is it possible to start an iterative development process by starting with Maintainability? The "ilities" (Maintability, Scalability, etc.) are considerations that should be addressed throughout the design and development process; with desktop applications though, do you not have to start with what the user sees, in order to get feedback on what the application should do?
What a piece of work is man, how noble in reason, how infinite in faculties, in form and moving how express and admirable . . . and yet to me, what is this quintessence of dust? -- Hamlet, Act II, Scene ii.
|
|
|
|
|
John Kuhn wrote:
with desktop applications though, do you not have to start with what the user sees, in order to get feedback on what the application should do?
No, that should be done before you start coding.
|
|
|
|