mindgraffiti

One of the first projects I worked on was building a better way to deliver print content on the web. Angus Productions Inc.’s bread and butter is building sale books for our breeders’ sales. One of the perks to ordering your sale book through API is a complimentary online version, posted to our breeder sale books page and/or on their web site’s sale page as well.

At the time, the current format to deliver as-printed catalogs online was using Flash Paper. The process was rather long and involved:

1. Take the .pdf and rip it into individual pages.
2. Print each page in Flash Paper.
3. Build a header linking to each individual page.
4. Upload the resulting work.

A typical catalog has between 30-110 pages. A large catalog can have as many as 300 pages. Barring any corrupted fonts embedded in the .pdfs, the entire process would take roughly 45 minutes to build and post to the web.

The problem was, corrupted fonts embedded in the .pdfs occured on a regular basis, and could extend the process to four or five hours because Flash Paper insisted on having viable fonts.

The second problem with Flash Paper was download time. The majority of our customers are on 56k modems and basic dialup lines. A single page usually took a whopping 5 minutes to download! While our customers were used to this, I find it unacceptable.

Also, even though Flash Paper offered our customers the greatest amout of flexibility in viewing controls and navigation, our competition was still winning customers over with their slow-loading, poor quality, online deliverables because “it does this really cool page-flipping-thing!”

So this became the list of problems we wanted to solve:

1. Find a faster way to adapt print catalogs for online delivery
2. Cut the download times for our 56k customers
3. Deliver the catalog in a high-presentation format (as in, something a bit flashier than Cattle Mail does it)

The hard part was working with the tools we had. Because the web department’s services are viewed as a ‘bonus feature’ or ‘perk’ by our customers [for doing their print business with API], new tools and technologies are not considered a priority. So our options were: static HTML, Coldfusion (limited to what we could learn on our own), Flash Paper, and any other commonly supported plug-in: a Java applet, shockwave file, or flash file.

Because Flash player was already a required standard to view the catalog pages, it was decided to continue using it to deliver our catalogs. But how to deliver them in a faster, more presentable fashion? Slideshows connected to a database could pull in small jpegs and were easy to build. A proprietary web application modeled off of the links header and Flash Paper might work, but it would take some serious time to develop. Or we could build a slick-looking animation in Flash that turned the catalog pages like a real book.

Since time was precious and we were denied a database (falls in that ‘new technology’ realm from earlier), it was easy to choose building our own Flash-based project. It also gave us the advantage of having a customized, branded look.

Related Posts:

• Case Study: Sale Books, part 2