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.
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.
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!