Beta Testing and the New PBS Web Modules October 4, 2006
Posted by ptvGuy. Comments: add a comment
…new web content modules and the need for beta testers…
The recent spate of new web content modules coming out of PBS (and beyond) has me thinking about the need for beta testers. For those of you that may never have given it a try, beta-testing is the process of testing something out before it's ready for release to the general public. It can be quite interesting whether it's software or a new web module. It gives you a chance to not only critique someone else's work, but to sharpen your coding skills and offer suggestions for refinement. It makes you a part of the work. The biggest kick for me, however, is getting to play around with all the newest toys before anyone else even gets to see them.
Testing is a process of executing a program or application in the intent of finding errors. With that in mind, testing can never completely establish the correctness of arbitrary computer software. In other words, testing is criticism or comparison, that is comparing the actual value with an expected one.
–Wikipedia, Software Testing
Basics of Beta-Testing PBS Web Modules
…have noticed the recurring use of common words for CLASS or ID element names…
There are a few important things to remember when beta-testing PBS modules for your station site. The first and most important of these is to test it on a working version of your actual station website as it would run under normal conditions (although in a nonpublic area protected from search bots and perhaps requiring a password to enter.) The idea here is to see how it functions on a real station website. The PBS Interactive in-house alpha testing should have already covered how it works under other conditions.
It must be allowed to interact with your usual station CSS in place on the page. No matter how narrow and focused the CSS for a new module may be, there may still be unforeseen interactions with already existing styles. That's exactly the kind of stuff that PBS Interactive is looking for and needs to learn from your feedback, and that's exactly why they have to have beta testers. I, for instance, have noticed the recurring use of common words (like "description") for CLASS or ID element names which virtually guarantees problematic interactions with already existing styles and script triggers.
…picked their beta testers from a wide selection of stations…
The module should also be tested under the normal coding restrictions (or lack thereof) imposed by your site's primary document type declaration. To make the modules as cross-platform, cross-server, and cross-browser compatible as they can possibly be, they need to be tested under differing document types. Ideally, the people at PBS Interactive should have picked their beta testers from a wide selection of stations representing as many different document types and servers as they possibly could to get the widest possible testing results and thereby eliminate the most possible errors. Therefore, the minimum testing that should be performed from our end is simply to set it up on a regular page of our site. We're, of course, always welcome to test more beyond that.
The Process of Beta Testing
I don't know how others do this–and I'd love to hear–but I generally start out by implementing a new web module in its raw state (no code or style modifications) in the widest possible section of a page. I usually pick a single-column page layout for this (no sidebars) in order to get a good 700 to 740 pixels of width to play in. A site with a non-fixed-width (or "liquid") layout will, of course, have variable outcomes for this. I do this even if the module is actually meant to be narrow sidebar content.
The idea here is twofold; first, to see if the module even works, and second, to see just how wide the module will go. After looking at the results of that–and assuming it works–I check the code and CSS to see if there's anything in place that restricts the module from going even wider. Playing around with the Pre-K Block Module, for instance, shows that it can be used not only as sidebar content as it was originally intended, but also as a variable-width page filler wherever needed. That gives me a nice new tool for balancing out low-content pages.
The next test I do is to implement the module into a narrow, restricted space. The easiest way to do this is by putting it into a table and deliberately setting the width too low (like 10 pixels) and the border to zero. If your CSS has predefined table element padding and margins, then this experiment may require the creation of a specially named CLASS for a non-padded table that will have to be defined in your style sheet.
…followup module states must also be taken into account and planned for…
The point of this test, of course, is to get a minimum width for the module—usually the width of the widest single element like a graphic. I personally think that every web module should have the minimum and maximum widths spelled out in the documentation. It makes it easier to plan layout and placement. Everything after this is just about playing around with the CSS and coding to either fit it in better with your site's style or run further experiments.
My general last step is just to put it into a page with other content, style it to fit, and get an idea of the full visual and content impact of the module and, of course, what it does when a user intereacts with it. Some of the modules take users offsite, some open new content windows, and some (like the TeacherSource Monthly Theme Module and the Schedules Module) open out on the same page from a small space initially into larger pieces of content. These followup module states must also be taken into account and planned for (as many stations discovered after implementing the Schedules Module.)
Some Final Words
…shortages of staff and time are already impacting development of new content…
Although most of the PBS member station websites routinely rely on the content they receive through PBS web modules to fill out their own sites, there is quite often a shortage of station web developers willing to help out in the beta-testing phase of their development. That's too bad since shortages of staff and time at PBS Interactive are already impacting development of new content. It's in our own best interest, if we're to remain relevant in the 21st-century, for us to be a willing part of this important aspect of content development.
Meaghan Zimmerman of PBS Interactive sums it up best:
BETA testing is a vital part of the process of building and launching modules for stations. Our thanks and appreciation go out to those stations who continue to volunteer when asked for their time. The more BETA testers who volunteer, the better the results.
–Meaghan Zimmerman, Senior Associate, Station Services, PBS Interactive
Thank you all, code well, and good night.
