Mark Trescowthick - GUI Computing
or... Adventures in Web Development.
"Quick, we need someone to do a small Shockwave streaming audio app for this page...". Now, you'd think that, after the better part of 20 years in this game, I'd have learnt that, in programming as in the army, Never Volunteer is a rule not to be broken. In fact, I do know that. I swear I do. Truly.
Which was probably why I found myself saying "Well, I've not done any Director programming, but I've done heaps of ToolBook - and they're really very similar". And so, all of a sudden, I was thrown into the wonderful world of Director, Shockwave and the Web.
A word on this article before we go any further: it would be foolish if I were to pretend that this is a reasoned or extensive look at Director development for the Web. It isn't. It's the first impressions of someone who thought they should be able to get a small applet going in a short time. Equally, much of what I have to say is just as applicable to any other Web tool - Director just happens to have been the catalyst for this reflection.
My initial thought was that this process would be easy. What we needed was a small applet which, when clicked, would get some streaming audio from a server and play it. Anna had designed a cute little CD player which spun when it was supposed to be 'playing', Macromedia provided an example of how to code and run streaming audio, just a brief look at Lingo showed me that it was, indeed, very similar to ToolBook - I was set. I guessed about two hours to understand what was going on, code it, test and ship... so I gave Anna an estimate of two days <g>.
The first step was to have a look at the Shockwave documentation, of course. "Shock" is right - there isn't any! A trip to the Macromedia site located some documentation after a search more frustrating than it needed to be. This was spread over four or five pages, with no index or search facility I could see. Not ideal, but good enough.
Next step was a look at the example application. At first glance, it seemed pretty straightforward. I was a little concerned at the fact that, here and there, there were pieces commented out which obviously referred to functionality that wasn't yet supported (but which, presumably, was going to be supported when the code was written...).
So, to the app.
First step was to take Anna's animation and paste some of the code from the example into the appropriate spots. That took a while, but seemed pretty easy once I got the hang of it. In fact, in under an hour, I had the code where I thought it "should" go. Obviously, it was going to take a while to test, but I was feeling confident.
Test? Now, how would I go about that? Trying to run the applet (complete with Shockwave extension calls) simply produced errors. And fair enough, too - it was designed for use on the Web. So a quick look at the example HTML supplied and a few minor changes and we were off. Well, not quite. It appears that Director requires that the Shockwave applet be on a Web server somewhere. It simply wouldn't run from my local drive. OK, so I copied it to my personal Web Site area on our server and I was ready.
Open the HTML for test one and... bang! Error! Well, OK, I thought - so it wasn't perfect first time. No real surprise at all (the real surprise would have been if it had worked first time <g>). I'll just do some debugging... Now, let's hunt for the debugging tools. Integrated debugging in the Web environment? No. I didn't think so. Never mind, we'll make do with a few popups of key variables. No, I'm sorry. We won't. Lingo doesn't support them!
This is where I started to get a wee bit annoyed and frustrated. I can see absolutely NO reason why Director / Lingo can't support popups in a Shockwave applet. Other technologies can. And boy, does it make it a painful process to develop! Especially when combined with both IE3's and Netscape 3's "helpful" habit of caching applets - which means shutting down and restarting each time you want to test.
So, my debugging cycle, I now understood, was going to be something like this:
Each of these cycles would take around three minutes - more if you're not sitting on an ISDN link to your Web Server. About the only upside was that it allowed me the time to compose a series of little nonsense rhymes - hence the title of this article.
I was beginning to feel some concern mixing with the 'annoyed and frustrated'. In the end, I stuck a few fields onto the application and fed text into them as a way of at least trying to do some debugging. Of course, that meant either (a) reading very fast in a limited number of fields or (b) adding many fields and keeping track of a lot of names. Either way, it was painful.
It took around 20 cycles to get the application going. Call it four hours, or more, to fix what turned out to be a couple of simple errors.
Then, of course, we decided that, not content with streaming audio, we'd like to parameter drive that audio. By this time, I was very careful not to use the word "Easy", but in all honesty it didn't seem so hard. After all, Lingo's Internet extensions supported a GetNetText function, so I could read in the text file, then break it up into lines which would, in turn, define the track name(s) to be played.
And, yes, that's exactly what I did. And yes, I ran into some problems (specifically, Lingo's NetDone() function seems, at best, inconsistent). And yes, it took forever to debug. I don't even want to think about playing multiple tracks in sequence and how long that took. Just a word to the wise, though - don't! It's almost a guaranteed browser blow up. If you code really carefully, you can ensure the browser only explodes after the user exits, but that's about the size of it.
The Web is a great place, and Director has a heap of nice features (even more when they get the streaming audio working properly). But developing for the Web is, for this little black duck, just too primitive for words.
How I long for Edlin, Teco... or even EMACS.