Saturday, August 30, 2008

If It Looks Like Crap...

It never ceases to amaze me what a difference "presentation" makes.

Pizza Hut is airing a commercial around here about their "Tuscani" menu. In the commercial, they show people doing the old "Surprise! Your coffee is Folgers Crystals!" trick in a fancy restaurant, except they're serving Pizza Hut food in an "Olive Garden"-style venue.

It clearly shows my point, and that the point applies to anything... books, food, appliances, vehicles, and software, just to name the first few things that pop to mind. You can have the greatest product in the world... it exceeds expectations in every functional way... but any adjective that is instantly applied to the visual presentation (including the environment it's presented in) will be applied to the content.

If it looks like crap, that's what people will think of it.

(Of course, there are two sides to the coin... What really kills me are the times when a really polished application really IS crap... it's UI is very appealing, but not thought out. It crashes at every click. But it looks BEAUTIFUL. And so people love it, at least enough to be sucked into buying it.)

Good engineers don't go for the adage "It's better to look good than to be good." We know far better than that. You can't judge the power of a car by its steering wheel. Granite countertops look great, but they're typically hard to keep sanitary.

When it comes to application user interfaces, engineers tend to make it function great... it gives you the ability to control every nuance of the solution without allowing invalid input... but if it looks kludgy, cheap, complex, or gives hard-to-resolve error messages, you get those adjectives applied to the whole system.

So what I'm talking about, really, is a risk... and it's a significant risk to any project. For that reason, appearance litterally becomes a business risk.

For any non-trivial application, a significant risk is end-user rejection. The application can do exactly what it's designed to do, but if it is not presented well in the UI, the user will typically tend to reject the application sumarily.

That's one thing that I was always happy about with the ISIS project. (I've blogged about our use of XAML and WPF tools in it, before.) The project was solid, AND it presented well. Part of it was that the users loved the interface. Using Windows Presentation Foundation, it was easy to add just enough chrome to impress the customers without adding undo complexity.

Monday, August 25, 2008

I blew it...

While working on the site, I accidentally deleted a core portion of the Jimmy Sudoku 2.5 puzzle generator web service. (Don't ask me how... it was apparently so bone-headed that it took me a while to realize I'd done it.)

I've exhausted all my backup options... the backups were either too new (and therefore producing the wrong content format), or so old that the backup itself was corrupt.


The good news is 2.5 supported local game generation if the service was on the fritz. I guess that means its covered.


Anyway, if you send me proof of purchase of any rev prior to 3.0, I'll send the fresh bits along.


Send it to me in email to jimmysoftware (at) kataire.com, and I'll reply with a copy. (Your order number & date will probably suffice...)

Sunday, August 17, 2008

Compromise & Capitulation

There's three different flavors of Windows Mobile in the 6.x line. Standard, Classic, and Professional.

Standard = Smart Phone, no touchscreen
Classic = PDA w/touchscreen
Professional = PDA / Phone with Touchscreen

One of the other interesting little gotchas is that the .Net Compact Framework 2.0 compiles the same for all three editions. Unfortunately, once in a while, you get a "NotSupportedException" out of the Standard edition.

A few days ago, in order to get my sudoku program published, I decided to simply avoid a problem I had with the Standard edition's lack of a SaveFileDialog and OpenFileDialog. My avoidance manifested in a "not supported" message of my own, if the user tried to save / load a file in that environment.

Today, I capitulated... I implemented an alternative file save/load functionality which kicks in automatically when the program gets a "NotSupportedException" on the common dialogs.

It's in 3.0.3, which I've re-published on PocketGear.

Friday, August 15, 2008

Jimmy SuDoku 3.0 Released

Those of you who have worked with me on a project in the past few years probably know of my hobby project. It's an implementation of SuDoku. It's made for Windows Mobile devices (cell phones, etc.), but it also runs on Windows XP (et al).

The old version, 2.5, had been published on PocketGear. This last update was published in January, 2007, just before I started with Edgewater.

I've been hacking at it here & there since then, but the project suffered from lots of maladies... most significantly lack of time.

So after more than a year and a half, I'm happy to finally announce Jimmy SuDoku 3.0!

3.0 has a whole new game state model, based on CLR classes rather than an XML DOM. This means the puzzle generator's fast enough on hand-held devices that it doesn't need a web service to do the work for it. Another side-effect of this change is a smaller run-time memory footprint, though I'm not sure by exactly how much.

I also figured out how to leverage the hardware controls on WM6.0 & 6.1 devices so that non-touchscreen devices can play, too.