Whence the Widget?

Just added a new widget to my sidebar. It’s a red-letter day because I’m the one who just finished programming this widget, and it was just released today by the company where I work, Kachingle.

The new one does the same thing as the other one that was there already; it just looks different. (Sorry I haven’t had a chance to say much here about what these widgets are for; maybe that will be another post. But mouse over one of them and you’ll be on your way to finding out…)

In retrospect, it’s eye-opening for me to have seen what goes into creating something like this. We had a widget (the “Kachingle Medallion”) with two different display styles for our users to choose from, and we simply wanted to create a third design. Easy, right? It’s just a bit of art. But it took a long time!

Originally, there was just one Medallion style. I’ve added one of those originals to the footer of this blog for comparison. It’s pretty big, so the company created a second, narrower version of it that could fit more easily in sidebars (the similar-looking one in my sidebar over there…). When I joined the company, that was the status.

As I became involved with maintaining and developing the Javascript code behind the Medallion, I learned that it loaded two entirely different Javascript files for the two different designs. Any time I modified the function of the Medallion, I had to make the change in two places. And the only difference between them was a few hard-coded details of the dimensions. (Not even the layout itself, which is handled on the server side; only the dimensions of the iframe and its containing div are handled by the Javascript.) It was obvious that this should have been coded into a single script accessing a small table of style-specific parameters. Not only would it simplify development and maintenance of the code in general, it would also make it trivial (uh… hah!) to add additional styles, if we wished. So I did that. Back then I don’t think I fully anticipated where it would lead, I just knew it would make my life easier, and encourage creative thinking about the possibilities. But it was the first step toward today’s release, and that was back in March.

Then somebody came up with the idea of the “mini-Medallion”, and the associated “overlay” that pops up when you mouse over it. (Go ahead, give it a try, I’ll wait…) In those days, all the user controls appeared as a drop-down when you moused over. The wide Medallion, with the drop-down showing, looked exactly like (strangely enough!) the pop-up overlay you see here. The narrow Medallion had a similar drop-down, but fitting the same text and links into a narrower layout to match the width of the Medallion itself. The new idea was to have a new, still smaller, more fun and modern-looking Medallion. It made a lot more sense to switch to an overlay approach than to redesign that drop-down. This also has advantages from a marketing perspective because it frees the old drop-down section from the size constraints of the Medallion, and we can put more interesting content in it (something we’re working on now). So a major project for me was to redesign the Javascript to pop up an overlay instead of a drop-down. That had its own tricky issues and took some time.

Ready to make a mini-Medallion yet? Nope! Part of the point of a mini-Medallion is to make it easier to incorporate into a page layout on mobile devices. In the sidebar, it would often be eliminated entirely when a page was viewed on mobile; the small size of the mini would facilitate including it within the body of each post instead. But that required other changes, not just small size.

Being included in each post means the Medallion needs to appear multiple times on a page. The original design was only allowed to appear once, and contained HTML that prevented more (id attribute), as well as overly simple Javascript that couldn’t handle more. So another project along the way was to generalize the code to allow multiple instances on a page. And without causing the older version to break, since it was already installed on our users’ sites.

Furthermore, the Medallions are activated by mouseover, and there’s no such thing as a mouseover in a mobile browser! (The stopgap solution had been to leave the drop-down always open on mobile instead of being activated by the user. But this made the Medallions even bigger! And the new mini-Medallion we were designing didn’t even have such a drop-down.) So I had to make the Medallion clickable.

This turned out to be non-trivial. For one thing, because it’s an iframe, the host page can’t see the clicks. (In a non-mobile browser it can see a mouseover as you cross the edge of the iframe or surrounding div. But a click inside the iframe is completely hidden.) That was a head-scratcher for me for awhile until I figured out how to get around that problem. (Tip of the day: a transparent div absolutely positioned in front of the iframe does the job nicely, thanks!)

And yet, it still didn’t work on mobile! Some crazy subtleties in the event models (yeah, plural; of course they aren’t all the same!) of mobile browsers were at fault. This was my introduction to programming for mobile, and solving this one didn’t just involve scratching my head, but pulling out a lot of my hair! I’m happy to say that it now seems to work well in Mobile Safari for iPhone, in the native Android browser, and in Opera Mini on both platforms.

And all of the above is only the part I worked on myself. There was also all the work by other people — several graphic designers involved in creating prototypes, preparing the final artwork (in several versions since the Medallion that finally appears is color-coded according to the status of the visitor to the site), and wrapping it all up with some HTML and CSS. I then incorporated their work into the PHP templates used by our server to deliver the right version to the visitor.

Five months! Just for that little thing! I had other projects along the way, so it wasn’t a full-time five months, but it has all been a major part of what I’ve done since I joined the company back in February. I find it striking when I look back on it. Today at Kachingle we’re celebrating!

This entry was posted in Web development and tagged , , , , , , , . Bookmark the permalink.

Comments are closed.