Skip to main content

Choosing your image type is now possible

With a recent feature release, Yahoo! Store finally gave us the option to choose the format in which images are generated on the template-based store editor pages. Previously, unless you displayed an image unaltered (meaning in its original size, and without manipulating it with the RENDER or FUSE operator), the Yahoo! Store editor converted images into GIFs no matter what. What is wrong with that? Well, the GIF format, while small in file size, is best for graphics or clip art, and not for photographic images. The reason lies with the fact that GIF can only display up to 256 colors. With the new release, we can now choose among GIF, JPEG, or PNG.

JPEG is generally better for photos, but JPEG uses what is called a "lossy" compression - meaning that in order to reduce file size, the image is compressed by merging like pixels thereby reducing the image quality to varying degrees.

PNG is a relatively new format and is generally far superior to both GIF and JPEG. PNG uses "lossless" compression much like GIF, however, unlike GIF, a PNG image supports millions of colors along with transparency (support for transparency is spotty at best in Internet Explorer prior to 7.0. There are workarounds for earlier version of IE, here is one: http://www.howtocreate.co.uk/alpha.html. )

On the Variables page, you will find two variables that deal with image types:

uploaded-img-default-type: this setting is what controls the images you upload (such as your product images.) Now that we have the option to change this, I routinely set this variable to JPEG. I tried PNG as well, but in all my tests PNG resulted in a larger file than JPEG, and the JPEG version was of good enough quality. You may just have to try it for yourself, and if you find that JPEG doesn't give you as good a quality as PNG, then go with PNG. And while sometimes GIF is ok, because it only supports 256 colors, it will probably hardly ever give you a nice outcome.

generated-img-default-type: this setting controls the generation of other, non-uploaded images such as buttons and text. Because these images are typically not photographic, GIF is a good choice, and since it is the default, you can leave it unchanged.

A Catch...

Here is something I've discovered through trial and error: while all "regular" variables take effect immediately after changing their values (and hitting Update on the Variables page), these two new variables do not... If you change uploaded-img-default-type from GIF to JPEG for example, you can wait in vain if you expect your product shots to change too... Changing these variables only affect images uploaded AFTER you changed the variables' setting. For any of your existing photos you will have to upload them once again to see them change from GIF to JPEG or PNG. For larger stores this may not be feasible unless you have all your existing images available and named by the ID of the corresponding product. In such a case, you can put all the images into a zip file, click on "Controls" in the store editor, and upload them under "Multiple-Image Upolad".

And Another Catch:

If you are using the Version 2 templates and change uploaded-img-default-type to JPEG or PNG, you may notice a gray border by your images on your section pages. This is a minor bug that was introduced by the two new variables. To fix it, you will have to be sure that wherever you use the FUSE or RENDER operator with a margin, you also specify :transparent or white for background. In particular, if in Editor V2, you should edit your copy of the contents-table template, find the only IMAGE expression in it, and change the background-color attribute of the FUSE operator there from transparent to :transparent (notice the missing colon.)

Similarly, in your copy of the inset-image template, change the same transparent value to :transparent.

Comments

Popular posts from this blog

Multi-Add and Yahoo Floating Cart Blues

Although the Yahoo! Floating Cart is considered pretty much bug free by Yahoo (you can look at the official open issues list here http://help.yahoo.com/l/us/yahoo/smallbusiness/store/floatingcart/floatingcart-09.html ) , there are some pretty "interesting" issues still, so since I keep running into them, I decided to post them here along with the work-arounds. The following issues all occur with multi-add forms only. 1) If you have your quantity set up as anything other than a simple text box (for example a drop-down SELECT box), the floating cart will not take the quantity value. It will take vwquantity as a customer-selected option. The workaround: use a text box instead. Nothing else works currently. 2) If you have a script that checks if the shopper made a selection from a drop-down (basically, any kind of an "onsubmit" handler), the floating cart will still receive the item, even if you cancel the submit event. The workaround: put the event handler on the click...

Adding custom Yahoo Store fields - Catalog Manager vs. Store Editor

In a non-legacy Yahoo Store, there are two ways to add custom fields: through Catalog Manager under "Manage my Tables" and through the Store Editor, under "Types" (the Store Editor's "Types" are essentially the same as Catalog Manager's "Tables".) Whether you add custom fields from Catalog Manager or from the Store Editor does make a difference as each has its advantages as well as disadvantages. Catalog Manager To me the main advantages of using Catalog Manager to add custom fields are: 1) You can add multiple fields quicker 2) You can later change the field's name and even type 3) You can delete the field if you no longer need it. 4) All the fields that are available in Catalog Manager are included in the data.csv file if you download your catalog. 5) All the fields that are available in Catalog Manager are also included in the catalog.xml datafeed file, which is used by the comparison shopping engines, for example. (See the Search ...

CPR for a Yahoo Store on Google's Supplemental Index

Recently a client of mine came to me and said that most of his store pages disappeared from Google, and he did not do anything to make this happen. I was a bit skeptical, so I went to Google, did a search on his store, and sure enough, there were only two pages indexed, his home page and his site map (ind.html) page. The rest were in the supplemental results, which means that Google thought the rest of the pages were not much different than these two pages. When I looked at the supplemental results, the little excerpts under each link were exactly the same, and I also noticed that what Google showed under each result was actually text from the ALT tags of the header image. I looked at some of these pages in my client's store, and they were actually different. This was a bit puzzling, but then I thought perhaps Google saw that the header and left navigation was the same throughout the site (which is pretty normal), but that the text that made each page different was too far down ins...