We are in the process of upgrading our desktop platforms and are having a lot of issues with content not working as a result of these upgrades (java issues etc) How do you mitigate these risks/upgrades in developing and promoting content?
Hm, good question. Java, browser, security models, popup blockers and OS platforms all result in risks. For example, we have content that didn't make the cut from IE6 to IE7, and other content that won't work on Vista/IE7. Now, much of this content was 3rd party content using their own developed tools and templates, rather than content we've developed ourselves.
I think part of the difference is the level of aggressiveness in development. That is, for 3rd party content, they seem to have "pushed the envelope" in terms of using fancy JavaScript tricks, sending data back and forth between JavaScript and Flash, and so forth and so on. While certainly some of that work does go towards making content more flexible and more engaging for the student, there's a difference between using a given technique because it advances the purposes of the content delivery, and using a technique gratuitously or to "show off" technical expertise.
In such cases, designing an implementation of content to a more common denominator in terms of browser standards and minimizing the use of aggressive programming techniques is going to provide a more robust result when it comes to platform changes.
While such approaches may help reduce the occurrence of unexpected problems resulting from platform changes, there's no guarantee of success there. Then, of course, there's testing.
Having a standardized testing methodology, well-structured test plans
and comprehensive test cases can help you find the problems before your students do. Sometimes. In our case, for example, we aren't officially even 'allowed' to install either IE7 or Vista --- makes testing tough, eh?
--
Joe Kyle
--jjkd--
How do you mitigate desktop
Hm, good question. Java, browser, security models, popup blockers and OS platforms all result in risks. For example, we have content that didn't make the cut from IE6 to IE7, and other content that won't work on Vista/IE7. Now, much of this content was 3rd party content using their own developed tools and templates, rather than content we've developed ourselves.
I think part of the difference is the level of aggressiveness in development. That is, for 3rd party content, they seem to have "pushed the envelope" in terms of using fancy JavaScript tricks, sending data back and forth between JavaScript and Flash, and so forth and so on. While certainly some of that work does go towards making content more flexible and more engaging for the student, there's a difference between using a given technique because it advances the purposes of the content delivery, and using a technique gratuitously or to "show off" technical expertise.
In such cases, designing an implementation of content to a more common denominator in terms of browser standards and minimizing the use of aggressive programming techniques is going to provide a more robust result when it comes to platform changes.
While such approaches may help reduce the occurrence of unexpected problems resulting from platform changes, there's no guarantee of success there. Then, of course, there's testing.
Having a standardized testing methodology, well-structured test plans
and comprehensive test cases can help you find the problems before your students do. Sometimes. In our case, for example, we aren't officially even 'allowed' to install either IE7 or Vista --- makes testing tough, eh?
--
Joe Kyle
--jjkd--