Studio Widgets - Musings on Software Development

There were some freely available pixel-art flags available here about a week ago.  They have moved.

Click below to get ‘em.

3 comments

Widget development is tough work.

World Clock Pro has gone through many stages of development, but its third incarnation has by far been the trickiest to build. You see, when you create a Widget that tops the download charts for years at a time, you have to be very careful when you screw with the recipe. How do you follow up a version that’s gotten downloaded by nearly half a million people? Your users expect a lot from you with each update. And, so far, every update since the beginning of 2005 has been rather mediocre.

World Clock Pro’s last major version was released two and a half years ago, and in that time it’s been passed up by better, smarter Widgets which tell time in new, interesting ways, or just do a better job of laying out information and giving complete control to the user. Admittedly, a lot of these newer world clocks are much better than the current version of World Clock Pro which is available to the public.

I’ve struggled to update World Clock Pro for a couple of years now, mainly because over that time period, my skills with Photoshop and JavaScript have developed past my ability to employ them. That is to say, whenever I would start coding an update to World Clock Pro to bring it up to version 3, I’d get sick of what I designed or what I wrote in code during development. Even the latest version, written just a year ago, isn’t up to the coding standards I’ve set for myself today.

The other problem is I release things way before they’re ready for mass consumption. Whenever I release a preview of something, that usually dooms it to failure. Two versions of World Clock Pro 3 have died off this way, as well as a fairly interesting weather Widget (though there were other reasons for the latter’s demise).

So, I’ve decided to take an entirely new approach with World Clock Pro 3, version 3 (Yes, I am aware of the irony!).

First, my coding skill has reached the point where I’m deep into object-oriented programming and loving it. Writing World Clock Pro 3 using object-oriented code should enable me to make changes easily should I ever change my mind during the development process.

Second, I have a solid idea of what I want the clock to look like. I’ve been tossing around ideas in my head for the past couple of weeks. I like what I did with the last incarnation of the clock for the face’s graphics, but the preference inspector will be changing dramatically – more on that later.

Third, I won’t be releasing feature-incomplete betas of the Widget. This is what got me into trouble the last few times, and it’s not going to happen once again.

Fourth, I have a very solid idea of what I want version 3’s feature set to be. Which brings me neatly around to the title of this post – Tracing Africa.

Now, why in God’s name am I tracing all the countries on this continent? There are plenty of shapefiles available online for the different countries of the world, as well as all the major time zones. You must be screaming, “RICKY SERIOUSLY WHAT ARE YOU DOING DITHERING ABOUT WITH VECTOR GRAPHICS WHEN YOU COULD BE CODING MY WIDGET ARRRRGH”

It’s simple! I am coding your Widget.

Back to the shapefile issue. The reason I’m not using any premade shapefiles is twofold:

1.) I like having control over my own content, but more importantly,

2.) There are no shapefiles corresponding to the different Zoneinfo database names.

“WHAT IS THIS GOBBLEDEEGOOK YOU’RE SPEWING OVER ZONEINFO DATASET BASERULES,” I hear you screaming at your monitor. Well, let’s go over this in a little more detail.

“Zoneinfo,” also known as tz, is the de-facto standard for time zone and daylight saving time information. The tz database is what all the major players use to plug proper time zone and daylight saving time support into their applications and operating systems.

Zoneinfo uses names such as “America/New_York” or “Europe/Ljubljana” to get its job done. These different names have different time zone and daylight saving time information attached to them in the database. For example, “America/New_York” has a base time offset of -5:00 associated with it in the tz database, as well as a rule that tells the app to start Daylight Saving Time on the second Sunday in March and end on the first Sunday in November as of 2007.

Right now, World Clock Pro uses some funky code to work with this written by a talented chap named Harry Whitfield. However, it doesn’t read directly from the Zoneinfo database; it uses a version that is massaged for the Widget along with some predefined locations.

World Clock Pro 3 will do the right thing and use a compacted version of this Zoneinfo database, and will even update it independently of the Widget itself to avoid problems when a stupid random US Government change fucks everything up. But, we’re still left with this “predefined locations” problem.

You see, when World Clock Pro 1.5 was released, we had a lot of complaints that it didn’t have city X in its options. So, in version 2, Harry and I added the ability to create custom locations for each clock. However, this required the user to know the latitude, longitude, time zone, and daylight saving time rules of the location in question. The nicest thing I can say about that approach is that it’s counterintuitive.

Ideally, what we want to be able to have happen is the user types in the location that they want, and we know exactly what to do with it.

The cool thing is, there are already services that allow this. Mapping services. Just go to Yahoo! or Google Maps and type in an address, and BAM, you’re all set. It finds exactly where you are on Earth. Even searching for a city or country name just works. The awesome thing is, World Clock Pro can plug into this great functionality, with a little help!

The best way for me to describe this is with a picture.

What happens with the latest preview database is something more like this:

Why does this happen? Because I don’t have sophisticated search algorithms, but Yahoo! does. Yahoo! knows what you’re talking about when you type in “New York.”

And, as an added bonus, I don’t need to maintain a needlessly complicated database, yet I get the benefit of geocoding, which effectively gives the Widget millions of locations.

So, back to tracing countries.

No comments