I’ve spent the last few days getting my puzzle Gadget to work in Internet Explorer. In order to make the Gadget work in IE, I had to avoid one questionable practice, and code in one outrageous hack. Today, I’d like to talk about both.
I’ve been using the crossbrowsertesting.com web service to debug my IE Gadget woes. CBT.com offers browser-based (Java) VNC connections to virtual(?) machines featuring a wide variety of OSes and browsers. You can use try out the service for free (although you are restricted to 5 minute sessions). I’ve only used it a little, but it seems to work well.
“Showstopper” bugs – bugs which demand your attention, which hold up forward progress – aren’t terribly common. Most things can be put off, worked around, “featurized”, or discarded if you don’t want to deal with them right away. Every now and then, though, you get something special.
A quick recommendation for you: Cool Text is a nice little web tool that you can use to create buttons for your site. Its only real downside is that it has 1200 fonts available, many of which are awful; you can spend a lot of time picking one out. Once you get past that, however, you can use it to produce just about any button art you might need.
Following up on yesterday’s “design that makes me happy” theme, let me briefly mention my keyboard. I’ve got one of Apple’s ulta-thin aluminum keyboards – specifically the USB version w/ numeric keypad. It’s a joy to use. It feels great, it looks great, and it doesn’t collect nearly as much dirt as a normal keyboard. I love the little green LED in the caps lock key.
The thing is, this is a $50 keyboard in a market filled with perfectly fine keyboards in the sub-$10 price range. Why spend the extra $40? Because it makes me happy. That’s good design, and the fact that it’s a cliche to point this sort of thing out when it comes to Apple products makes it no less true.
Something unambiguously positive today: I’ve got a Canon Pixma MP610 printer that makes me very happy. The MP610 is, in most respects, a typical and serviceable all-in-one inkjet photoprinter. It does its thing well enough – I’m not enough of a printer geek to get into its specs – but its real greatness lies in its design.
(more…)
Over the past few days I’ve talked about the process of converting my puzzle site from a webapp into a Google Gadget. A few twists and turns aside, the centerpiece of the effort was eliminating the page reloads that I’d used to navigate between puzzles, and editing my markup slightly to created a gadget XML spec from my existing HTML code. This seems to have been the Right Way to do things, but today I want to look at a different issue: “What’s the fastest, dumbest way to convert an existing web site into a Google Gadget?”
I’ve dropped the first version of my widget, available here. (I don’t have any nice “click here to add” functionality yet; that’s for tomorrow.) I’ve collected a few more random observations while getting it out the door, which might be of interest to you.
In order to convert my puzzles to work with Google Gadgets, I’ve shifted from a page-reload mechanic to an AJAX-y XHR-driven one. As a result I’ve discovered first-hand that the new thing isn’t always better. I’m sure that this has been covered before, but here are a few ways in which an AJAX approach is inferior to a more explicitly REST-ful one.
I’ve been working on widgetizing my puzzles as Google Gadgets. The biggest change has involved converting from a page-reload mechanism for navigating between puzzles to something more AJAX-y. This conversion has gone well, but along the way I’ve found a number of non-obvious characteristics of Gadgets that I’d like to talk about here.
