Rewrite Fullwise

I'd rather Facebook manage my Personal Health Record

On a second thought, I'd rather talk about this on my personal blog :)

How to Improve Long Warning Messages

Warning messages sometimes have to contain a lot of words - sometimes, it's paragraphs of explanatory text. If that's the case, not all is lost, people can still process them with little to no pain.

Let's take an example of an annoyingly long message. How does the user (me, in this case) process it?

I see two buttons that give me the choice of "Yes" and "No" - the most natural thing to do now is to look for the question. However, I'm first presented with 2 sentences explaining why I'm seeing the question, with the first of them stating the obvious and not seeming like an issue. Then, the question follows.

Here's what I really want to see:

Do you want to continue?

If you continue, you will lose any changes you made to the attachment "XYZ.pptx" from the message "ABC". The attachment is open or in use by another application.

CONTINUE - or - CANCEL

Improvements: 

1. As the question first.
2. Put the most important information next (that little bit about losing changes).
3. Don't offer Yes/No choices. It's "Do you want to Continue or Cancel?"

Cheers.

Does your field also not get set?

This was a pain to debug. Basically, for reasons I'm not going to get into, we have a field in one of our classes that is not encapsulated. At some point, a bug was introduced (by me) where this field was modified essentially inside of another property (let's call it Name).

What made this confusing to debug was the fact that we provide a ToString() implementation that accesses both properties. If you put a breakpoint in Name, it won't get hit when it's called inside ToString(), which is called to display the value of the class in the Locals window and elsewhere.

Check out this screenshot below:

• CultureInfo.CurrentCulture.LCID is 1099 (Kannada, India)
• I'm setting NoSnappers.Lcid to 1041 (Japanese, Japan)
• Now look at the state of the program in the Locals window right after 1041 was assigned to this.info.Lcid

The fix was ridiculously simple (remove the line in Name that changes the Lcid), yet I spent a while reading about various possible reasons why setting a field of a struct could possibly fail. It just hasn't occurred to me that the field WAS in fact getting set, and then reset back to its original value somewhere else.