At my previous job there wasn’t much need for developing screen shots to show the client because often times I was the client. Or even when I wasn’t the client, the people I was developing for were so happy to have something, that anything I came up with, no matter how clunky, was perceived as the best thing ever.
Recently, I had to develop screen shots for a client to help nail down what their interface looked like and how it would work. We started with a few screens that I thought were a reasonable approximation of what the client needed. The client even thought the screens were pretty close to what they needed. Over the course of a week however, we scrapped almost all of the original screens and created some new screens that didn’t exist before. This wasn’t unexpected, but it did drive home the point that clients don’t know what they want until you show it to them.
Today was an interesting day for debugging.
We’ve developed a flash application for a client that didn’t quite work right in IE6. Today the client called and said this is really going to be a problem as most of the people who will be using the application haven’t upgraded to IE7 and don’t use Firefox (hence they use IE6). So I spent some time trying to track down the problem.
I’d looked at it this before and couldn’t figure it out, so this time I put on my Stubborn Hat and dug in. I knew I had a “screen shot” that worked fine in IE6 while the actual application did not. So the first thing I did was make a static document of the HTML generated by the app. Now what? Should I gradually make the “screen shot” look like the application until the Flash bit stopped working? Or should I gradually change the application’s HTML until the Flash bit suddenly started working? Either way it was going to be a long tedious process. For no conscious reason other than “my gut told me to”, I chose the latter.
Actually, at first I thought it must be some quirk of how IE6 deals with javascript since that’s how we interface with Flash. But after a few minutes exploring that idea, I realized that the “screen shot” and the actual application would have the same quirks as the javascript parts were virtually identical. So, I started in on munging the non-javascript parts of the HTML. After quite a while of carefully removing bits of HTML and not getting the Flash portion of the application to do much of anything I was beginning to despair that I’d picked the wrong strategy. It didn’t seem that I was making any headway against the problem. I’d remove a small div and reload the page, remove a table tag and reload the page, etc. Nothing seemed to make a difference (but on the plus side, I had a much smalled document to deal with :-) Then … finally the Flash app worked in IE6!
And what, pray tell, was the problem? The application had a div tag with an id of ‘left’. Change the id to anything else and the Flash parts work as expected.
Yesterday, we had our first day at SXSW Interactive. Each of us had preselected the web/interactive panels that seemd most interesting to us based on the short descriptions listed on the site. Scott seemed to have found several good/great panels that he found interesting, entertaining, and educational. I was a little disappointed with our first day as most of the panels that I attended either were not very informative or the panelists speaking spent more time plugging their products and very little time actually educating the audience or sharing what they learned during the development of their application/site.
At the end of the day, we realized that this year’s South by Southwest conference is not just about intensive learning sessions and the latest web technologies, but for us as a development team, is more about a renewed excitement and motivation about our own work and current projects. In addition, SXSW seems to be an affirmation that we are doing things right or making effective decisions with respect to most of the successful businesses or applications development companies speaking.
Years ago (that seems kind of funny to say after my seven years in business) when Niall Durham was working with me, we used to talk about spending an afternoon here and there building cool new apps just to test new frameworks, languages, or ideas. But on the planned day, we’d get slammed with phone calls or new business, and our ideas sat on the shelf. For all our planning, we just never got these brainstorm/build sessions started.
Two weeks ago we mapped out a new strategy. Fridays are “fun days.” If support questions or sales calls come in, we’ll temporarily focus our energies on that item. But at the moment the phone call is finished or our client leaves the office, we get back in step with our team project.
Years ago (and this time, I’m talking 20 of them), I worked for an insurance company. The manager, Tom Lindberg, used to instruct us to “Pay yourself first.” This directive referenced putting money into your own savings before you spent on the immediately gratifying things in life. Thunder Data builds software for clients and for our own products, services, and uses. TDS is going to take Tom’s advice these 20 years later and pay ourselves first.
Our dividends will come in a myriad of ways. These are great teambuilding events where we can get excited about bringing an idea to fruition. Implementing new APIs or testing theories in web applications introduces concepts that may take root in other projects. The cool stuff we build may have the wow factor that wins over a new client. And finally, we are creating applications that will add to our bottom line.
With SXSW formally kicking off this Friday night and running through next Tuesday, our old mindset would have placed our creative scheduling on the back burner. Now, we’ll look at the day as an opportunity to gear up for the conference.
