Month: December 2008

Posted on

In the beginning were the words, and the words were “It sucks”

In his Tech-Ed session “Why software sucks”, David Platt was explaining why, in fact, software sucks. The reasons were not some mystical ramblings, or some pseudo-scientific best guesses. It was all solid common sense; problem being that, since designers and developers often know the conventions too well, we will often assume, without a second’s thought, that our users know the same conventions. I was sufficiently impressed by the session (Delivered in an hour long chunk of what can be called good stand-up comedy entertainment. Reminded me a little of George Carlin, really 🙂 ), to buy his book.

Do you really want to delete this file? Hmm, no, what I really wanted to do was give it a back massage…

To take one of the examples from “Why software sucks” and give it shape: consider a confirmation box. You know the kind… “Do you really want to …?”. Can’t stand the damn things myself. Platt makes a few well considered arguments against them; the main ones being:

1. If a user clicked the button, he or she REALLY wants to do that action.

2. Unless the button was clicked accidentally, in which case, your user interface design sucks.

I’ve been working on a WordPress contact management plugin recently, and decided to slip this idea in. The delete button for each contact starts off disabled, and it is only enabled while the user holds down the CTRL+D key combination:

delete_contact

And that’s that, once you’ve clicked, it’s deleted with no further confirmation. Once this gets tested for a while, I’ll post any further observations here.

I’ll probably change the delete icon to a more conventional x, since the little guy with a stop sign doesn’t strike me as being an obvious “delete” indicator. Then again, I guess I’ll wait to see what comes out of the test. I’m not my user, so I’ll see what they think first.

Posted on

Is this thing on?

Download sample code here (New window)

There’s been a project knocking around the back of my head for a while. I keep putting it off, doing some work on it now and again but never really settling down to really do it. This long weekend turned out to be one of those occasions; I’ve just finished playing Fallout 3 (Awesome game, the ending left a slightly bitter taste in my mouth though) and ended up with nothing to do. Visual Studio to the rescue…

Now what?

If you ever worked on an application that requires Internet connectivity, you will have had to handle situations where the connection may be unavailable for certain periods of time. Sometimes you can get by that by trapping an exception; I know I have, though I still find that particular solution to be somewhat inelegant. What I wanted was some way to monitor the state of the connection and keep track of it. This way, if you need to send a message for example, you can have your application decide whether it should try to send it right away, or whether it should stash it away till the connection becomes available. This post is about how to determine whether a connection is up or down, and notify the application when the state changes. Continue reading “Is this thing on?”

Posted on

Keep code behind clean

Download the sample code here

Last week, Marlon blogged about how to avoid adding command binding code to code-behind files. The idea is both simple and great, and allows you to keep your code behind nice and clean, and your layers separated. There’s only one (and yes, I’m being very anal here) thing that bugged me with it:

DataContext = new ViewModel(new SampleModel());

or, for that matter, “DataContext = anything”, is still in the code behind class. This can easily be sorted out with some easy data binding and a supporting class. Continue reading “Keep code behind clean”

Posted on

Dynamic proxies using Castle

The sample code can be downloaded here

This week I found myself with some time on my hands, so I knocked up a simple object pool. It’s fairly standard stuff… you call Fetch to get something out of the pool, and Return to put it back. Fairly standard.

The problem

The call to Return felt a bit annoying. If we forget to call that, we end up leaking resources as we create more and more objects, or get an exception thrown at us. Not good. I wanted something like the using (whatever) syntax, which I think is the most awsome thing ever.

To do that, we’d have to ensure that all the items in the pool implement IDisposable, have a reference back to the pool, and call Return in their dispose method. This isn’t really feasible; for starters, it would tightly couple everything with the pool, which is, like, all sorts of bad. A far better approach is, in my opinion, to wrap the object being pooled to add whatever behaviour I need. Not necessarily a great idea if you don’t know what’s going to be pooled beforehand. Continue reading “Dynamic proxies using Castle”