Focusing in on blurry pages

With all of the digital publication conversion options out there today, it can be difficult to distinguish one product from the next.  When we began development on what would become ingage Publication 4.0, we set out to do more than just create a product that would differentiate ourselves from the competition, but also to create a fun, fast, easy and functional experience that all ingage Publication users could enjoy. 

 

Note: The following applies to ingage Publication 4.5.6 or ingage Publication 4.6 with “fast” page load option.

One of many ways to identify an ingage Publication from the plethora of other publications out there is the unique page-flipping functionality we introduced in version 4.0.  When you flip from one page to the next you will notice that the publication pages go out of focus, flip, and then come back into focus.  So why do we choose to turn pages this way when so many other page-turning publications do something completely
different?  There are four major reasons, of which I will go into detail:

 

• Page Quality
• Load Time
• Usability
• Performance    

   

    

Page Quality

When we launched ingage Publication 4.0, very few, if any, digital publications on the market displayed full screen.  This meant that users would most likely have no choice but to zoom in, in order to read most text.  One of our goals for ingage Publication is to make it possible for user to read as much text as possible without having to use the zoom feature.   If we could take advantage of the user’s entire screen, maybe, we thought, it would be possible for the page to be large enough that it could be read, in some circumstances, without having to zoom in. 

 

Up to this point we, like all of the other digital publications at this time, were using raster files (jpegs to be precise) for our pages.  Before we decided to go full screen, this was no problem, because we controlled the size at which the publication would be displayed.  Now all bets were off.  The major challenge with going full screen was the pixilation that would occur for users with screens that were uncommon sizes (either smaller or larger than average).  When you stretch or zoom in on a raster image, the pixels become quite noticeable.  The more you stretch or zoom, the more noticeable they would become. (See the ingage clearText example for an interactive experience.) ingage Publication users on large monitors, or very high screen resolutions would likely receive a very blurry, pixilated, perhaps unreadable experience.  Continuing to use rasters was no longer an option. 

 

When Adobe (then Macromedia) released Flash 8, it finally became possible for ingage Publication to stop using raster pages and transition to vector pages instead.  Unlike raster images, which use a fixed number of pixels to display image content, vector images use mathematical instructions to tell the computer how to draw the image using lines and curves.  Since these lines and curves are not dependent on a fixed number of pixels, they will be crisp and sharp at any size, no matter how far in you zoom.  There is a trade-off, however.  Since the computer has to constantly perform computations in order to display the vector data, pages with a lot of data (such as text or complex shapes) would cause a great performance burden that would slow all but the best computers to a screeching halt.  With the release of Flash 8, and the added bitmap data functionality it provided, specifically (I am about to let the cat out of the bag here) the cacheAsBitmap property, we were finally able to use vector pages to provide ingage Publication users a full-screen, crisp, clear, readable experience.  This also meant we could do a standing, real time zoom without having to load an external high-resolution file. Switching to this scheme meant we could trim an average of 30% off the total file size for a typical publication.      

 

The catch

There is always a catch.  In this instance the catch is page flipping.  The cacheAsBitmap property provides no performance benefits to vector data if the data is being rotated.  Without cacheAsBitmap, the computer has to continually process all the instructions to constantly redraw the vector data.  Along with doing the work necessary to perform the page turn (full screen, mind you), most, if not all, computers will choke trying to keep up with all the calculations necessary to display a page flip with even a small amount of text.  Thus, it is not very practical to flip the actual vector page, so we had to come up with another solution. 

 

Combined with the other three major reasons, which we will get to below, we chose to display an extremely low resolution raster (jpeg) version of the page while the page turn is happening and display a vector, clearText version while the page is standing or being zoomed in upon.

 

Very few publications out there, even today, use vector files for their publication pages, theoretically, for this very reason.  Of those that do, some do not flip pages.  This avoids the problem all together; however, ingage Publication was developed to mimic the look and feel of a real magazine, catalog, newsletter, book, etc.  Eliminating the page turn feature seems counter to that end.

 

 

Load Time

Managing load time has been a balancing act that web content producers have had to perform since it was possible to post graphic data to the Internet.  One would assume now that connection speeds and processing ability have increased so dramatically, we wouldn’t really need to make these considerations.  This may be true, except that along with increased performance, comes increased expectation and increased richness in content.  It seems as though there will always be some new technology out there that will push the boundaries of bandwidth and processing, so the struggle continues.

 

When we developed the current version of  ingage Publication, we needed to decide how to distribute load time.  It is a given the data must be transferred at some point.  The question simply is: what is acceptable to the end user?  Should the whole publication be preloaded into cache, so the user sees only one load screen, at the beginning of the session?  Our research and internal debates led us to the conclusion that this option left the door open for too many users, especially on slower connections or slower computers, to abandon viewing the publication because of prolonged load time.  We decided that the best route to take was to only preload the minimum amount of data required to view something on the screen and leave the loading of the high-resolution pages to be done on a page by page basis, as the user sees fit.

 

This technique allows even the publication with very high page counts to load extremely fast and allows the user to quickly begin flipping pages and using the publication as they would a non-digital, hard copy.

 

This ties directly to usability.

 

Usability

ingage Publication is used by many of our clients to spice up their magazines, catalogs, brochures and other print materials.  If you think about the last time you read a magazine, or flipped through a product catalog, it’s doubtful that began reading at the front cover and read straight through all the pages in sequence.  Most likely you either flipped through the magazine or catalog, looking for something that would catch your eye, or perhaps you headed to the table of contents for guidance.  It’s no surprise that we have noticed similar patterns with ingage Publication users.  Often users will flip through, looking for a specific article or item.  Having the low resolution placeholder -the blurry page- available provides the user feedback as to what will be on the page once it finishes loading, which may be quickly or slowly depending on his or her connection speed.  This type of feedback is impossible to achieve when the page is blank. 

 

Consider a scenario where a user has begun reading an ingage Publication then is called away in the middle of an article and must close the publication.  Sometime later he comes back to his magazine, not knowing exactly which page he stopped reading.  As he flips through the publication he vaguely recalls passing a full-page advertisement for a car and knows that he left off on a page containing mostly text.  Since ingage Publication uses low resolution pages in place while the high resolution pages are loading, the user can flip through as many pages as he would like, quickly, and gauge whether he is on the page which he left off without having to wait for the high resolution pages to load for all the previous pages.  Depending on the length (in pages) of the magazine or catalog, and how deeply into the content the user is, the load time savings can be substantial, even on a high speed connection.  Since this user was approaching his use of ingage Publication as he would a traditional paper publication, it was instinctual just to flip through the pages in search of his place in the content.

 

 

Performance

There is at least one publication out there that indeed uses vector pages and performs page flipping without using low-resolution files.  They achieve this by creating a new BitmapData object, in Flash, using the vector page once it loads, while zooming, displaying the newly created bitmap at the 100% size and storing it in memory for later use.  When the page flips, the BitmapData object is flipped to the next page, thus avoiding the vector-rotation issue.  The problem with this scheme is two-fold.  One, the BitmapData object cannot be made until the vector page has loaded and is rendered, this means that flipping the page before it is loaded causes a blank page to be flipped.  Secondly, and most importantly, the BitmapData object used to flip each of the pages must be stored in RAM, ready to be displayed at any time after its creation.  Essentially, a bitmap image the size of the page is stored in RAM for each page in the publication the user has visited and allowed to load completely.  This may not be a problem for publications with smaller page counts, but for many of our ingage Publication clients, it is not uncommon to have 300 or more pages per publication.  Storing that quantity of data in RAM could get painful, especially for users on older computers, or multi-tasking users with several programs running at the same time.

 

One of the considerations we made when developing the latest version of ingage Publication, was limiting the RAM footprint left by our software.  If you’re on a PC, open Task Manager and look at the Mem Usage stats for a publication.  As you read more and more pages of a publication, if the usage continually increases, depending on the length of the publication, this could cause performance problems to arise for some users.  ingage Publication avoids that possibility by page-flipping low-resolution raster files, and using only the RAM it currently needs and releasing the memory when it is no longer required.