Case Study: Sale Books, part 2
After re-reading part 1 I realized I left out the sale book development timeline and examples:
- The first generation started with the searchable catalogs.
- The second generation was the Flash Paper pages.
- The third generation began with the plan to create Flash animated pages.
As you can tell by the dates, the first two were still being implemented until quite recently.
Each of the generations had their quirks in production and functionality. [Mostly the pattern included sacrificing functionality in the name of production speed and better visuals.]
The searchable catalogs took 2-3 days to build and post, rarely offered photos, came packaged with dull graphics, and did not visually represent the as-printed version of the sale books, but had the best features when a user was looking for specific stats and search criteria.
The Flash Paper pages took less time to build, cutting days down to hours, and gave the added bonus of actually seeing the graphics and photos that were in the printed catalogs. However, it gave up the high functionality of the searchables: can only search text, cannot search for specific stats on animals, and took much longer to load. In return the Flash Paper pages were easy to print, easy to zoom in and out of graphics and text, and quickly skipped to any page in the catalog by using the links header.
The Flash animated catalogs took minutes to build, offered high quality presentation and was shown truly “as printed.” No more font issues, no long hours to build a sale book then upload it, and acceptable loading speeds for our 56k users were reached. Unfortunately it also meant no more search features and no more print-friendly versions.
While our customers enjoyed the new look and feel of the Flash animated catalogs, we continued to search for a way to bring back some of the functionality of the older methods. With version 2 we hit the sweet spot – that fine line between functionality and presentation. We created a hybrid of the “as printed” catalog above the fold and reinstated the searchable catalog below it. Not to mention we hit our technological limits as well – our average user has Flash Player 6 and there was very little non-deprecated server-side code available for the searchable catalogs.
Related Posts:
Case Study: Sale Books, part 1
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:
- Take the .pdf and rip it into individual pages.
- Print each page in Flash Paper.
- Build a header linking to each individual page.
- 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:
- Find a faster way to adapt print catalogs for online delivery
- Cut the download times for our 56k customers
- 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:
