Related
I have a bit of a challenge.
In an earlier version of our product, we had an error message window (last resort, unhandled exception) that showed the exception message, type, stack trace + various bits and pieces of information.
This window was printscreen-friendly, in that if the user simply did a printscreen-capture, and emailed us the screenshot, we had almost everything we needed to start diagnosing the problem.
However, the form was deemed too technical and "scary" for normal users, so it was toned down to a more friendly one, still showing the error message, but not the stack trace and some of the more gory details that I'd still like to get. In addition, the form was added the capabilities of emailing us a text file containing everything we had before + lots of other technical details as well, basically everything we need.
However, users still use PrintScreen to capture the contents of the form and email that back to us, which means I now have a less than optimal amount of information to go on.
So I was wondering. Would it be possible for me to pre-render a bitmap the same size as my form, with everything I need on it, detect that PrintScreen was hit and quickly swap out the form contents with my bitmap before capture, and then back again afterwards?
And before you say "just educate the users", yes, that's not going to work. These are not out users, they're users at our customers place, so we really cannot tell them to wisen up all that much.
Or, barring this, is there a way for me to detect PrintScreen, tell Windows to ignore it, and instead react to it, by dumping the aformentioned prerendered bitmap onto the clipboard ready for placing into an email?
The code is C# 3.0 in .NET 3.5, if it matters, but pointers for something to look at/for is good enough.
Our error-reporting window has these capabilities:
Show a screenshot that was taken when the error occured (contains all the open windows of the program at the time, before the error dialog was shown)
Show a text file containing every gory detail we can think of (but no sensitive stuff)
Save the above two files to disk, for latter attaching to an email or whatnot by the user
Sending the above two files to us by email, either by opening a new support case, or entering an existing support case number to add more information to it
Ignore the problem and hope it goes away (return to app)
Exit the application (last resort)
We still get screenshots from some users. Not all, mind you, so my question is basically how I can make the PrintScreen button help us a bit more for those users that still use it.
One option: Put the stack trace and other scary stuff into the error screen using small, low-contrast type -- e.g. dark gray on light gray -- so that the user doesn't really even see it, but the Print Screen captures it.
But if you want to detect the PrintScreen and do your own thing, this looks like an example of what you want.
Wouldn't it be possible to disable the Print Screen button altogether when the error popup is active? Have it display a message along the lines of "Please use the clearly visible button in the middle of your screen to report the error" I agree it breaks expected functionality, but if your users are really that stupid, what can you do...
Alternatively, have it report errors automatically (or store the data locally, to be fetched later, if you can't send without asking for some reason), without asking the user. If you want to be able to connect print screened screenshots with detailed error data, have it send a unique ID with the data that's also displayed in the corner of the popup.
What about offering them a "Print Screen" button that performs these actions as well as performing the print screen? If you're locked into this method of having your customers send error details, this may be an easier route to take.
Lifted from my comment below for easier reference (looks helpful, perhaps):
codeproject.com/KB/cs/PrintScreen.aspx
This is in theory...the best way to deal with it I would think
Intercept a WM_PRINT message or inject one into your process... see this article here
Install a system-wide keyboard hook and intercept the print-screen key and swap it around with your contents prior to the capture. Now, I can point you to several places for this, here on CodeProject, and here also, keyboard spy, and finally, global Mouse and keyboard hook on CodeProject.
Now, once you intercept the print screen, invoke the WM_PRINT message by capturing the contents that you want to capture.
I know this is brief and short, but I hope this should get you going.
The only solution i came up with was to offer big, large, easy to read toolbar buttons that give the user every opportunity to save the contents of the error dialog:
Save
Copy to clipboard
Send using e-mail
Print
And after all that, i use the Windows function SetWindowDisplayAffinity in order to show the user a black box where the form should be:
This function and GetWindowDisplayAffinity are designed to support the window content protection feature that is new to Windows 7. This feature enables applications to protect their own onscreen window content from being captured or copied through a specific set of public operating system features and APIs. However, it works only when the Desktop Window Manager(DWM) is composing the desktop.
It is important to note that unlike a security feature or an implementation of Digital Rights Management (DRM), there is no guarantee that using SetWindowDisplayAffinity and GetWindowDisplayAffinity, and other necessary functions such as DwmIsCompositionEnabled, will strictly protect windowed content, for example where someone takes a photograph of the screen.
If their screenshots show a big black box, hopefully they'll get the hint.
I did add a defeat, if they hold down shift while clicking "show error details", i don't add the protection during form construction:
//Code released into public domain. No attribution required.
if (!IsShiftKeyPressed())
SetWindowDisplayAffinity(this.Handle, WDA_MONITOR); //Please don't screenshot the form, please e-mail me the contents!
I have this application where the users can change text files and when they forget to save them, a little message pops up reminding them that the changes are not saved and asks them if they want to save the changes or not with two buttons "Yes" and "No". It also has a little checkbox that says "Disable this warning". And as the same says, if the user checks it, the message will never pop up again when the text files have unsaved changes.
A couple of questions:
1) Should the checkbox value (if they checked it) be remembered if the user only selects "Yes", only selects "No" or any of them?
2) Let's assume the user checked the checkbox so is not warned again about unsaved changes. What should be the expected behavior the next time the user forgets to save the changes?
Should I always assume a default action (yes: save changes, no: discard changes) after the user disabled the warning? If so, which action?
Or should I always save the changes or always discard the changes accordingly to the last user action right after the he disabled the warning?
What you're doing is a common UI pattern but IMHO I think it's not a good user experience. Here is an alternative that I think is much better:
New files save automatically every minute or so (vary this by how long it takes to save);
It saves to a temporary file;
If the user saves a file then give it a name and save it to that location;
If the program crashes then the temp file is still there. The program should ask what you want to do with it when you start up;
Closing the program should have a simple checkbox "Save Now?" (Yes/No). None of this "Are you sure you want to..." rubbish. Not saving should leave the file as a temp file;
Getting rid of the temp file requires selecting a Discard action (with confirmation of "Discard Now?");
Opening an existing file has the same save every minute functionality except that the saves are to a temporary file. Never modify the original unless the user explicitly saves the file, at which point copy the temp file over the original.
Temporary files should be visible on a collapsible pane (or equivalent) including the date of the last edit and preferably a preview to remind the user what it is;
There should be no option to disable this behaviour. It's not invasive or intrusive. As Joel says, every time you give a user an option you force them to make a decision. Options are way overused.
To specifically answer your question: you should never discard anything unless the user asks you to.
Controlling Your Environment Makes You Happy is a must-read on usability. Don't Make me Think! is too.
Since the checkbox says "Disable this warning", that's exactly what it should do. Don't be wishy-washy with what you're presenting to the users, just do what you say you're going to do!
If they forget to save their changes and they aren't warned, then they should not have checked the box. You are correct to always discard changes when the warning is disabled.
Make the checkbox say '[ ] And always do this'.
Then it's clear that if they select 'No', and check it, it'll always choose 'No', and vice versa.
Or should I always save the changes or
always discard the changes accordingly
to the last user action right after
the he disabled the warning?
I believe that should be the expected behavior. It would be nice if you had a hint on the screen of the default action that will take place.
I recommend the book About Face 3: The Essentials of Interaction Design for some really good GUI designing ideas.
1) You should also have a “Cancel” button that aborts the exiting, allowing the user to return to the document to see if s/he wants to save it or not.
2) “Disable this warning” is a little too geeky. Try, “Don’t show this warning again.” This tells the user that the warning will not be shown and implies no saving will happen in future cases. That’s probably not a good idea, and you should reconsider providing such a warning-suppression feature at all.
3) Far more often in this situation a user will want to save things than not, so that’s what your app really should do if there’s no warning. The checkbox in that case should be “Always automatically save changes when exiting.” This implies no warning will be shown in future cases.
4) If you do 3, you also need an alternative way for user to recover from totally botching up the file and not wanting to save. It could be an Undo dialog that allows the user to make big jumps backwards or maybe a menu item like “Go back to previous saved version.” Ideally, this feature should be available even after the user exits and re-opens the file.
5) If users can be made aware of 4), consider making 3) the default or sole option --don't have the warning at all.
All this assumes that periodic implicit saving is not an option.
Better option is Auto save the document into drafts. It is possible to do that asynchronously.
I say, always automatically save. Forget the dialog. If they want to exit without saving, make that an explicit action on the file menu.
Think of how often you want to save versus those times you don't. The ratio is probably 100 to 1 or even 1000 to one. You want to inconvenience the user 999 times to protect them once?
It's a longshot that anyone can help with this, but here goes. I inherited a VB6 app with a Janus GridEX control. It iterates through records, and is editable. Problem is, if I edit a cell and hit the button to go to the next record, the change is applied to the next record, not the one I was editing. It's like, I need it to finish up the edit before going to the next record. I've had this sort of problem before in VC++, and sometimes you have to "KillFocus" on the control you're on or something. I just don't know what to do here. I tried sending a carriage return, since if you return out of the edit cell, it works, but sending a carriage return manually doesn't work. What's the secret?
Is your grid bound or unbound?
It's hard to tell from your description, but I imagine that if your are having this problem then it's probably bound.
As the other answer asked, is the button the RecordNavigator that is built into the control or is it a separate button? The reason I bring this up again, is that I have seen issues in the VB6 applications I support where a toolbar will often intercept and interfere with how the JanusGrid should work.
To get around this limitation, I have added the following code in the click handler of any toolbars where there is also a JanusGrid control on the form.
If jsgxYourGridName.EditMode = jgexEditModeOn Then jsgxYourGridName.Update
This way any changes are immediately applied to the current row.
If this does not help, then I have also seen problems where the recordset that is bound to the grid gets out of sync with the internal recordset in the grid. You can check this by comparing the bookmark of the grid to the bookmark of the recordset.
Ie. mrsYourRecordset.Bookmark = jsgxYourGrid.ADORecordset.Bookmark
At one point I may have also used something like this.
jsgxYourGrid.ADORecordset.Bookmark = jsgxYourGrid.RowBookmark(jsgxYourGrid.RowIndex(jsgxYourGrid.Row))
Finally you can try setting a breakpoint in the BeforeUpdate, RowColChange and/or AfterColUpdate events of the grid, to see what record the grid is really on when clicking on the button.
It depends whether the button is internal to Janus GridEX or not. If it internal then just about the only thing you can do is look at the events the control exposes to see if there a sequence that can let you know that this problem occurs. Then you can try to take corrective action by restoring the row you moved to and put the edit in the row you left.
If the button is external to Janus then you can use the debug mode to trace sequence of statement that control the transfer of focus to the next row. It could be something out of order or a side effect of the particular sequence of commands. I have run into both with different controls.
Remember that you can edit while in debug mode so you can try different approaches and test until you find one that works.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
On a web contact form, is the reset button really required? Is it really used by anyone? If I don't put it in a page, is there an usability fail?
10x!
Well, it's very useful to erase that textarea your customer just took the time to write, because they press the wrong button -before they lose it anyway because the session expires, and have to retype-
No, I really don't think it's useful.
It's actually sometimes useful for web forms which will be accessed from public terminals - a good example would be a search form for a public library card catalogue.
Imagine if the search form has a lot of fields (author, year, keywords, topic, publisher, collection, title, series, whatever). This lets you do very specific searches (all books by authors named John published in 1987), but once you've found the result you (or another user) may want to do a new search using a very different set of terms (all books about fish published by Random House. A reset button can help a lot here, because you may otherwise find yourself manually clearing a large number of fields.
(Depending on implementation details, a reset button may also be useful if a user doesn't want the next user to see what they were searching for. Again, this is useful in the context of a library, where privacy is a concern.)
I honestly don't think so in the general case, but you should talk to your users or otherwise examine how they use your system to make sure.
General rule of thumb: If you aren't sure that it's a requirement and you have no way of knowing, don't include it. You can always include it on a later iteration.
The reset button must be the safe winner in any contest measuring a uses/usefulness ratio since it's omnipresent and fully useless.
I think it's a) completely useless to 99% of users; and b) requires far too much work in a typical LOB application. Often business analysts add requirements for the Reset button without giving any thought as to why this feature is required.
add it to the webform and log it whenever a user clicks it. that will provide information for your specific page if it's needed or not. we cannot guess if people want it or not.
just use simple analyzing tools of users need it or not.
I don't think it's necessary in most web-pages. If you're entering information, and you enter it wrong, then you'll need to go through every wrong text-box and re-enter it. The reset button is, at minimum, one extra button click on top of that.
If you don't want to enter information, you just don't click the submit button.
The only time I see a reset button being useful is if you have a multi-page workflow, and need to be able to start from scratch. Even then I would suggest re-designing the workflow.
In my opinion the reset button is completely useless on the majority of forms. I mean think about it... Can you ever imagine a time were you would want to complete remove all of the information you typed in? Not likely. Most users tend to make edits to specific fields not the entire form.
In the case that you have to have such a secondary action like a reset button it's better that that button is a little smaller as well as colored a little differently. Let the user know "this button is different" and apply Fitt's Law to make it a little harder to click on.
Absolutely NOT required. In fact, it's a bad idea to use it if you have a long form and have a RESET button at the bottom because you could make some people really angry if they find out that they accidently hit "RESET" and their data is deleted.
Required. Make sure you swap the position of the reset and submit buttons on some of your forms. Better yet, write code to randomly swap their position once in a blue moon.
In all seriousness, I've never used one. When I removed it from the forms on my school's registrar's site that I was working on when I was a student, nobody said anything. So I say leave it off.
Not only on the contact form. I can't also find the benefit of reset button in any type of HTML form, IMHO. But I tend to put it every time I create a form :)
Only reason I could think of is on a preview & confirm scenario, where a user might modify part of their entry before hitting the big bad send button, and actually decide itt made more sense the first time around
I usually leave out the reset button, because I've never seen anybody use it.
I often use the free space for a cancel button which returns the user to where he came from in the first place (the page linking to the form). Makes much more sense to me.
What if I says it IS useful? But not in every form.
I use it with the "UPDATE" part in a CRUD application sometimes.
Say SO for example, I hit an edit link on a question.... and made some edits and reread it... but then I decided it is not a good edit... I have to reload the page or go back to the last page and hit the edit link again to get the original text.
Whereas, if there is a reset button slapped there, it'd be easy.
And there is always CTRL+Z.. so why not?
There are some good uses but just don't slap it in silly like what most ancient HTML books would teach you to.
It can be useful for clearing radio buttons without using Javascript.
In the form below either zero or one radio button may be selected:
Select any one option for any Item(s):
Option 'A' Option 'B' Option 'C'
Item 1 o o o
Item 2 o o o
Item 3 o o o
Item 4 o o o
If a user changes his mind or accidentally clicks on an item's button he didn't want, a reset button will clear the whole form, which seems to be only way to get rid of the selection without using Javascript.
I guess it depends on how large the form is and how big the chance that you actually want to do this. TBH, i've been developing websites for years and never really added one to forms.
It is useful on a form that repeats your previous information. I have had cases in admin interfaces where the users want what they typed in last time, so they don't have to remember. However, on those occasions when they want the form to reset, they simply press the "clear" (or reset) button.
On a one-time form a reset button would be silly.
A reset button should be used only when there is default information. An example is this form. What if I make changes to most of the values but then would like to get it back to it's original state? I guess I could reload the page as long as it doesn't resend my POST. Or I could just hit a simple reset button. The button was never intended to clear all information entered by the user but to reset preset data.
I would suggest the usability fail will present itself if and when a user or business owner complains about the absence.
Definitely not required as a "standard" feature and usually a very bad idea with the exception of the special cases given above where the functionality seems to add value. However the most of the cases offered as examples above could be dealt with in different (and I would suggest, better) ways than with the, often awful, reset button.
Reset is for use with HTTP status 204 only
Destination of the form can send 204 No Content response, which causes browsers to leave the current page unchanged.
In that situation reset button is most reliable way to reset form to original state (page reload could re-send the form).
However I can't come up with realistic use-case for it anyway.
This is inspired by the question OK-Cancel or Cancel-OK?.
I remember reading somewhere about the concept of switching OK-Cancel/Cancel-OK in certain situations to prevent the user from clicking through information popups or dialog boxes without reading their content. As far as I remember, this also included moving the location of the OK button (horizontally, left to right) to prevent the user from just remembering where to click.
Does this really make sense? Is this a good way to force the user to "think/read first, then click"? Are there any other concepts applicable to this kind of situation?
I am particularly thinking of a safety-related application, where thoughtlessly pressing OK out of habit can result in a potentially dangerous situation whereas Cancel would lead to a safe state.
Please don't do this unless you are really, really, really sure it's absolutely required. This is a case of trying to fix carelessness and stupidity by technological means, and that sort of thing almost never works.
What you could do is use verbs or nouns instead of the typical Windows OK / Cancel button captions. That will give you an instant attention benefit without sacrificing predictability.
NOOOOOOOOOOOO!
In one of our products we have a user option to require Ctrl+Click for safety related commands.
But startling the user with buttons that swap place or move around is bad design in my book.
NO. If you make it harder for the user to click OK by mistake and force them to think, they will still only think harder about how to click OK -- they will not think about the actual thing they're trying to carry out. See usability expert Aza Raskin's article: Never use a warning when you mean Undo. Quote:
What about making the warning
impossible to ignore? If it’s
habituation on the human side that is
causing the problem, why not design
the interface such that we cannot form
a habit. That way we’ll always be
forced to stop and think before
answering the question, so we’ll
always choose the answer we mean.
That’ll solve the problem, right?
This type of thinking is not new: It’s
the
type-the-nth-word-of-this-sentence-to-continue approach. In the game Guild Wars, for
example, deleting a character requires
first clicking a “delete” button and
then typing the name of the character
as confirmation. Unfortunately, it
doesn’t always work. In particular:
It causes us to concentrate on the unhabitual-task at hand and not on
whether we want to be throwing away
our work. Thus, the
impossible-to-ignore warning is little
better than a normal warning: We end
up losing our work either way. This
(losing our work) is the worst
software sin possible.
It is remarkably annoying, and because it always requires our
attention, it necessarily distracts us
from our work (which is the second
worst software sin).
It is always slower and more work-intensive than a standard
warning. Thus, it commits the third
worst sin—requiring more work from us
than is necessary.
[If you want a Microsoftish one, this one by a .NET guy on MSDN says the same thing!]
If you must use a dialog, put descriptive captions on the buttons within the dialog.
For example, instead of OK and Cancel buttons, have them say "Send Invoice" and "Go Back", or whatever is appropriate in the context of your dialog.
That way, the text is right under their cursor and they have a good chance of understanding.
The Apple Human Interface Guideline site is a great reference, and very readable. This page on that site talks about Dialogs.
Here is an example image:
(source: apple.com)
No, it doesn't make sense. You're not going to "make" users read. If the decision is that crucial, then you're better off finding a way to mitigate the danger rather than handing a presumed-careless user a loaded gun.
Making the "safe" button default (triggered by enter/spacebar/etc.) is a good idea regardless, simply because if they surprise the user then a keystroke intended for the expected window won't accidentally trigger the unexpected action. But even in that scenario, you must be aware that by the time the user has realized what they've done, the choice is already gone (along with any explanatory text on the dialog). Again, you're better off finding another way to give them information.
What I've done in some instances was to compare the time of the message box being shown with the time of it being dismissed. If it was less than 'x' amount of seconds, it popped right back up. This forced them, in most cases, to actual read what was on the screen rather than just clicking through it blindly.
Fairly easy to do, as well....
Something like this:
Dim strStart As DateTime = Now
While Now < strStart.AddSeconds(5)
MessageBox.Show("Something just happened", "Pay Attention", MessageBoxButtons.OK)
If Now < strStart.AddSeconds(5) Then strStart = Now Else Exit While
End While
At the end of the day you can't force a user to do something they're unwilling to do... they will always find a way around it
Short cut keys to bypass the requirement to move the mouse to a moving button.
Scrolling down to the bottom of the EULA without reading it to enable to continue.
Starting the software and then going to get their cup of tea while waiting for the nag screen to enable the OK button.
The most reliable way I've seen this done is to give a multiple choice question based on what is written. If they don't get the answer correct, they can't continue... of course after a couple of times, they'll realise that they can just choose each of the answers in turn until the button enables and then click it. Once again meaning they don't read what was written.
You can only go so far before you have to put the responsibility on the user for their actions. Telling the user that their actions are logged will make them more careful - if they're being held accountable, they're more likely to do things right. Especially if there's a carefully crafted message that says something like:
This is being logged and you will be held accountable for any
repercussions of this decision. You have instructed me to delete
the table ALL_CORPORATE_DATA. Doing so will cause the entire company's
database to stop working, thus grinding the whole company to a halt.
You must select the checkbox to state that you accept this responsibility
before you can choose to continue...
And then a checkbox with "Yes, I accept the responsibility for my actions" and two buttons:
"YES, I WANT TO DELETE IT" this button should only be enabled if the checkbox is checked.
"OH CRAP, THAT'S NOT WHAT I MEANT AT ALL" this button can always be enabled.
If they delete the table and the company grids to a halt, they get fired. Then the backup is restored and everyone's happy as Larry [whoever Larry is] again.
Do NOT do it, please. This will have no positive effect: You are trying to AVOID people's clicking OK instead of Cancel, by making them potentially click Cancel instead of OK (okay, they may try again). But! you might as well achieve people's clicking OK when they really want to cancel and that could be a real disaster. It's just no good.
Why not reformulate the UI to make the OK the "safe choice"?
The problem is better solved with a combination of good feedback, communication of a system model and built-in tolerance.
In favor of the confirmation mechanism speaks the simplicity of implementation. From programmer's point of view it's the easiest way of shifting responsibility onto user: "Hey, I've asked you if you really want to shoot yourself into the foot, haven't I? Now there is no one to blame but yourself..."
From user point of view:
There is a productivity penalty of having to confirm operation twice every time even though actual mistakes take up just a fraction of total number of actions, any switching of buttons, breaking the habitual workflow or inserting a pause into confirmation just increases the penalty.
The mechanism doesn't really provide much safety net for frequent users whose reflexes work ahead of the concious mind. Personally I have many times done a complex sequence of actions only to realise a moment later when observing the consequences that my brain somehow took the wrong route!
A better for the user, but more complex (from software development point of view) solution would be:
Where possible communicate in advance what exact affect the action is going to make on the system (for instance Stack Overflow shows message preview above Post Your Answer button).
Give an immediate feedback to confirm once the action took place (SO highlights the freshly submitted answer, gmail displayes a confirmation when a message is sent etc).
Allow to undo or correct possible mistake (i.e. in SO case delete or edit the answer, Windows lets restore a file from recycle bin etc). For certain non-reversible actions it's still possible to give an undo capability but for a limited timeframe only (i.e. letting to cancel or change an online order during the first 10 minutes after its submission, or letting to recall an e-mail during the first 60 seconds after its been "sent", but actually queued in the outbox etc).
Sure, this is much more initial work than inserting a confimation message box, but instead of shifting the responsibility it attempts to solve the problem.
But if the OK/Cancels are not consistent, that might throw off or upset the user.
And don't do like some EULAs where a user is forced to scroll a panel to the bottom before the Agree button becomes clickable. Sometimes you just won't be able to get a user to read everything carefully.
If they really need to read it, maybe a short delay should happen before the buttons appear? This could also potentially be annoying to the user, but if it is a very critical question, it'd be worth it.
Edit: Or require some sort of additional mechanism than just clicking to "accept" the very important decision. A check box, key press, password, etc.
I recommend informing the user that this is a critical operation by using red text and explaining why is this an unsafe operation.
Also, rather than two buttons, have two radio buttons and one "Ok" button, with the "don't continue" radio button selected as default.
This will present the user with an uncommon interface, increasing cognitive load and slowing him down. Which is what you want here.
As always with anything with user interaction, you have a small space between helping the user and being annoying. I don't know you exact requirements but your idea seems OK(pun intended) to me.
It sounds like your user is going through a type of input wizard in the safety app.
Some ideas as alternatives to moving buttons.
Have a final screen to review all input before pressing the final ok.
Have a confirmation box after they hit ok explaining what the result of this action will be.
A disclaimer that require you to agree to it by checking a box before the user could continue.
Don't switch it around - you'll only confuse more than you'll help.
Instead, do like FireFox and not activate the control for 5 sec. - just make sure you include a timer or some sort of indicator that you're giving them a chance to read it over. If they click on it, it cuts off the timer, but requires they click one more time.
Don't know how much better it will be, but it could help.
Just remember, as the man said: You can't fix stupid.
This will give me headache. Especially when I accidentally close the application and forget to save my file :(
I see another good example of forcing user to "read" before click: Firefox always grayed out the button (a.k.a disable) the "OK" button. Therefore the user have to wait around 5 seconds before he can proceed to do anything. I think this is the best effort I have seen in forcing user to read (and think)
Another example I have seen is in "License and Agreements" page of the installer. Some of them required the user to scroll down to the end of the page before he/she can proceed to next step.
Keyboard shortcuts would still behave as before (and you'd be surprised how few people actually use mice (especially in LOB applications).
Vista (and OSX IIRC) have moved towards the idea of using specific verbs for each question (like the "Send"/"Don't send" when an app wants to crash and wants to submit a crashdump to MS)
In my opinion, I like the approach used by Outlook when an app tries to send an email via COM, with a timer before the buttons are allowed to be used (also affects keyboard shortcuts)
If you use Ok and Cancel as your interface you will always be allow the user to just skip your message or screen. If you then rearrange the Ok and Cancel you will just annoy your user.
A solution to this, if your goal is to insure the users understanding, is:
Question the user about the content. If you click Ok you are agreeing to Option 1, or if you click Ok you are agreeing to option 2. If they choose the correct answer, allow the action.
This will annoy the user, so if you can keep track of users, only do it to them once per message.
This is what I responded to Submit/Reset button order question and I think the same principle can be used here. The order does not really matter as far as you make sure the user can distinguish the two buttons. In the past what I have done is used a button for (submit/OK) button and used a link for (reset/cancel) button. The users can instantly tell that these two items are functionally different and hence treat them that way.
I am not really for OK/Cancel. It's overused and requires you to read the babbling in order to say what you are OKing or Canceling. Follow the idea of MacOSX UI: the button contains a simple, easy phrase that is meaningful by itself. Exampleç you change a file extension and a dialog pops up saying:
"Are you sure you want to change the extension from .py to .ps?"
If you perform the change, the document could be opened by a different application.
(Use .ps) (Keep .py)
It is way more communicative than OK/Cancel, and your question becomes almost superfluous, that is, you just need to keep active the rightmost button, which seems to be the standard.
As it concerns the raw question you posed. Never do it. Ever. Not even at gunpoint. Consistency is an important requisite for GUIs. If you are not consistent you will ruin the user experience, and your users will most likely to see this as a bug than a feature (indeed it would be a BUG). Consistency is very important. To break it, you must have very good reason, and there must not be another different, standard way to achieve the same effect.
I wonder if you're thinking about the option that exists in Visual Basic where you can set various prompts and response options; and one option is to allow you to switch Cancel and OK based on which should be the default; so the user could just hit enter and most of the time get the proper action.
If you really want to head in this direction (which I think is a bad idea, and I'm sure you will too after little reflection and reading all the oher posts) it would work even better to include a capcha display for OK.