Design Resources

Design Resources : Flash Website Nightmares

Furthermore, if a Flash project is created with elements from an imported Shockwave file, upon publishing the project, the graphics and sound are recompressed to even lower quality. If the original Shockwave file was fully optimized for the smallest file sizes first time round, the graphics and sound cannot be recompressed upon subsequent publishing without terrible artifacts marring their presentation.

Sometimes Flash sites are developed in such a way that textual, image or multimedia content is separate from the Shockwave files. This 'separated content' may be stored in a database or folder as regular text and image files. This functionality is usually incorporated into a Flash site for ease of updating and bypassing the need to reopen the native flash files to make an update and re-publish the modifications to new Shockwave files.

You can now appreciate the limitations of being stuck with only the Shockwave files for your web site. Legally, there is no way around this. However thirds party programs, called Flash Decompilers, do exist on the market and are used to decrypt the Shockwave files so that the programming can be accessed and the media contained in the file can be exported to other file formats. A few Flash SWF decompilers even claim to be able to convert Shockwave files back to original native Flash files.

Macromedia maintains that decompiling Shockwave files is a breach of the end user license agreement of their software (See paragraph 3b of the EULA). This is for obvious reasons; clients and their developers do not appreciate giving their hard work away to anyone with a decompiler. But in some extreme circumstances, the use of a decompiler to regain your own intellectual property can be justified. You just have to be aware that taking the decompiling route is currently seen as shady, much like pirating software.

In regards to decompiling Shockwave files for the purpose of creating fresh native Flash project files, there are several hoops that have to be jumped through to get the end result;

• The Shockwave files have to be decompiled into unencrypted source and reworked into a usable, native Flash file.
• The fundamental structure of the Flash website and underlying programming solutions has to be studied in order to understand it enough to modify it successfully.
• If graphical elements have suffered quality degradation due to the publishing process, then they have to be substituted for copies of the original, uncompressed graphic files so that upon publishing a subsequent Shockwave file, the quality is OK.

These hoops have to be jumped through for each end every Shockwave file that you wish to be updated and usually a Flash Website is made up of many separate Shockwave files!

This process will be most expensive for each page's first update. Subsequent updates will be cheaper because of the software acquisition, Shockwave conversion and the time spent in becoming familiar with the site's programming. However in the long term, this overhead to accomplish simple updates will not be economically viable. It will be more cost effective to redesign the site from scratch with development structures in place that will enable simple and cheap website updates.