Post #235,881
11/24/05 11:42:38 AM
|
Simple example
If the application saves files, and the file exists, and the default action is to ask the user if they really want to overwrite the file, should there be an option that allows the user to turn the "are you sure" prompt off?
|
Post #235,903
11/24/05 4:16:18 PM
|
Re: Simple example
And there should be an option somewhere else to turn that warning back on later if desired. And maybe there should be an "I know what I'm doing" option to turn on and off similar warnings throughout the app. And since such a warning is common among all file saving apps, maybe there should be a global option in the DE's control center to manage such warnings. And since people installing the DE from the tarballs likely "know what they are doing", we should include it in the "personalizer" wizard that runs on first startup so that knowledgeable users can apply their favorite settings immediately in a few quick steps.
-- Chris Altmann
|
Post #235,905
11/24/05 4:34:58 PM
|
Hey
No extending the example until he bites!
|
Post #236,606
11/30/05 2:28:25 PM
|
No.
Because an operation which destroys data should never occur without the user being notified.
--\r\nYou cooin' with my bird? \r\n[link|http://www.shtuff.us/|shtuff]
|
Post #236,630
11/30/05 3:40:11 PM
|
Batch process. Automation. Piss off.
===
Purveyor of Doc Hope's [link|http://DocHope.com|fresh-baked dog biscuits and pet treats]. [link|http://DocHope.com|http://DocHope.com]
|
Post #236,634
11/30/05 3:47:25 PM
|
It's probably a database permissions problem.
*flees*
Peter [link|http://www.no2id.net/|Don't Let The Terrorists Win] [link|http://www.kuro5hin.org|There is no K5 Cabal] [link|http://guildenstern.dyndns.org|Home] Use P2P for legitimate purposes!
|
Post #236,636
11/30/05 3:48:25 PM
|
Now that twitch in my left eye is back
===
Purveyor of Doc Hope's [link|http://DocHope.com|fresh-baked dog biscuits and pet treats]. [link|http://DocHope.com|http://DocHope.com]
|
Post #236,665
11/30/05 5:27:04 PM
|
mickeysoft berk
rm -r * should take place upon hitting the enter key, if you didnt want to do that get a mscie thanx, bill
"the reason people don't buy conspiracy theories is that they think conspiracy means everyone is on the same program. Thats not how it works. Everybody has a different program. They just all want the same guy dead. Socrates was a gadfly, but I bet he took time out to screw somebodies wife" Gus Vitelli
Any opinions expressed by me are mine alone, posted from my home computer, on my own time as a free american and do not reflect the opinions of any person or company that I have had professional relations with in the past 49 years. meep questions, help? [link|mailto:pappas@catholic.org|email pappas at catholic.org]
|
Post #236,727
12/1/05 8:11:53 AM
|
You've made it plain
You have no advanced users in your world.
You will always choose to slow people down, and not even give them the option to take any responsibility for their decisions.
I'm glad it is unlikely that I'll ever use any app you designed.
|
Post #236,822
12/2/05 12:24:39 AM
|
You've made it plain
That you have no interest in extracting your head from your ass and having a serious discussion, which is why you always come back to a response like that in the end. \r\n\r\n I'm glad I don't have to deal with people like you unless I choose to.
--\r\nYou cooin' with my bird? \r\n[link|http://www.shtuff.us/|shtuff]
|
Post #236,823
12/2/05 12:56:19 AM
|
Reality check
You just said as a universal rule that any step that destroys data must require user notification
You said it to a guy who spends a good deal of his life automating batch data processing for very large amounts of data.
And you think he is out of line to say that he doesn't ever want to rely on any application that you've designed the UI for.
I am far more sympathetic to Barry's position than yours. Like him, I've also had to automate stuff. And I can say from personal experience that if any step has to use a UI designed to make it impossible to avoid notifying the user about critical steps, that step will become the bottleneck that becomes a permanent PITA.
Some day I hope that you have to do some serious batch processing. And learn in detail how wrong you were, one failed job at a time. Hopefully with associated midnight wakeups from your pager.
In the meantime, try to digest the following clue: there are people whose needs are different than you anticipate. The best way to figure out what those needs are is to listen to them and try to figure out why they are saying what they are saying. That means that you let them tell you their needs, instead of you trying to tell them.
Regards, Ben
I have come to believe that idealism without discipline is a quick road to disaster, while discipline without idealism is pointless. -- Aaron Ward (my brother)
|
Post #236,847
12/2/05 9:30:19 AM
|
The statement that highlights the fundamental disconnect
That means that you let them tell you their needs, instead of you trying to tell them. Most here are on one side of this statement, one here is on the other.
If you push something hard enough, it will fall over. Fudd's First Law of Opposition
[link|mailto:bepatient@aol.com|BePatient]
|
Post #236,906
12/2/05 8:52:21 PM
|
Devil's advocate mode
He believes that he can interview and observe his user population to achieve a true set of requirements. This true set will be the absolute minimum required to do the job. No bells and whistles, minimum flexibility or configurability. Bet there will be a lot of hardcoded values and embedded assumptions.
And if those requirements change, then he feels it is OK to start over, and if not start over, change the current code to match the new set of requirements.
So, at best he's naive. And at worst, it is a matter of job protection.
Either way, it ends up with the same result.
A crappy program and an asshole programmer you have to argue with to make changes.
|
Post #236,930
12/3/05 8:33:40 AM
|
You CAN always leave means to override the default behaviour
In the Box example, an admin can globally alias rm="rm -i" which means that rm -rf * will still prompt for deletions. If you really want to blindly kill everyting you have to /bin/rm -rf * Similarly GUI based programs can have command line arguements that cause them to run completely silently. In general, you build your program to suit your clients needs and put in exceptions if you have clients with varying needs. Make it easiest for the majority. This isn't that complicated once analysis has determined who the clients are and what their needs are.
|
Post #236,971
12/4/05 12:43:16 AM
|
No, it can be very complicated
What if you don't know exactly who your customers are going to be and what they are going to need?
For example, let's say you're building a semi-standard product that has to be customized for each customer's product. It has to fit into their assembly lines and match with their standards (for data collection, safety, interface, etc). And the customers are always dreaming up new applications that can be quite different from the original customer. But it's unaffordable to do a separate software control program for each customer.
I'll just say there's a reason I like scripting languages.
Tony
|
Post #236,989
12/4/05 8:10:02 AM
|
That's true.
Everything for everybody programs are a nightmare that seldom work. As with everything, there are different approachs. Scripting can be good, as can loadable sub programs that can be added or modified later. Being able to modify your program's interface with a configuration file can also work. All have good points and bad points depending on what you are trying to accomplish. There are a lot of ways to skin that cat, and the cat hates them all...
|
Post #237,023
12/4/05 2:20:13 PM
|
ICLRPD (new thread)
Created as new thread #237022 titled [link|/forums/render/content/show?contentid=237022|ICLRPD]
===
Purveyor of Doc Hope's [link|http://DocHope.com|fresh-baked dog biscuits and pet treats]. [link|http://DocHope.com|http://DocHope.com]
|