Avoid bad HTML

As you may know, you can easily put HTML tags in your editor fields, such as the caption field, or the message field on the home page, or even in the head-tags variable, etc. I always encourage my clients to feel free to use some minimal formatting they may want to include in these fields, because doing so is relatively easy and really shouldn't require hiring a professional to do so. I always tell them also, to be careful with the HTML they put in those fields, and DO hire a professional if they find the need to add more complex HTML - for example, beyond just bolding words, or emphasizing phrases, etc. However, I keep coming across stores where merchant-edited HTML nearly bring the store to its knees. Yes, that actually can be done! Why? Because web pages - therefore Yahoo Store pages - are made up of HTML tags, so if you throw a wrench in there, expect things to break....

Adding simple formatting is harmless. You can easily bold words, change the appearance of fonts, etc. It becomes a problem when the merchant believes that throwing a bunch of random HTML code in a variable will somehow come out correct - and if it seems visually Ok, then they assume they did it right. Here is a partial list of problems I see often:

Unclosed Tags
This is probably the most common mistake I see. They start bolding something with a < b > tag, and forget to close it. In this case, it will just end up bolding most everything on the page starting at the opening < b > tag. But, things can get worse. If you include a tag that actually affects layout, for example an opening < div > tag or < table > tag, that stray tag can potentially break your page's layout completely. And, taking it a step further, if you open a < style > or < script > tag, but don't close them, the page may stop rendering completely (i.e. come up blank.)

Closed tags without opening
This is sort of the opposite of the previous mistake. When you throw in a closing tag without first opening it, you will most likely completely break the layout of your page(s).

Mismatched tags
This is a combination of the previous two. Sometimes people throw in opening tags and closing tags at random, and in random order. If each of your opening tags have closing counterparts but in the wrong order, chances are most modern browsers will figure out what to do, but why make the browser's work miserable? Follow this easy rule of thumb: if you open a tag, such as < b >, when you are done with it, close it. That's really it.

Including main document tags such as < html >, < head > , or < body >
These are not only not necessary because the Yahoo Store templates already put these in the code, they can also break the pages, break JavaScript code, and in extreme cases these extra tags may even cause the search engines to mis-read your pages and not index them correctly.

So if you wanted to write a post-it note for yourself with the most important rules of adding html to your caption fields, write these:

• If you open an HTML tag, always close it, and in reverse order.
• Never use these tags in your store editor fields: < head >, < /head >, < body >, < /body >, < html > and < / html >

Batch-converting Images

I'm helping a friend getting up and running with her brand new Yahoo Store, and we have a ton of high definition, high res product images. Besides the fact that images that are over 3 or 4,000 pixels tall or wide are really not very practical on screen, they are also way over the maximum parameters allowed by the Yahoo Store editor (parameters are: no more than 2,000 pixels in width or height, no more than 2 million pixels total, and no more than 2MB in size).

Luckily, I found a freeware image viewer/batch conversion utility called InFanView. This utility allows you to select a batch of files (or directories) and rename them , resize them, crop them, recolor them, pretty much anything you would ever want to do to product images in bulk.

If you find yourself in a situation where you have to manipulate your product images in bulk, you should definitely give InFanView a try.

Istvan Siposs
Y-Times

Upgrading to Merchant Solutions vs. Upgrading from V2 to V3

I get these questions from time to time about upgrading from legacy store to Merchant Solutions, vs upgrading a V2 template set to V3, so apparently this is still a confusing topic.

The two are two completely separate issues/topics.

First of all, how can you tell if you have a legacy store?

This is pretty easy, when you log into your store manager, it will say "Store" next to your store's name in the upper left corner in the blue band. If you have Merchant Solutions, it will say "Merchant Starter", "Merchant Standard" or "Merchant Professional".

Upgrading to Merchant Solutions

For the most part, this is only a question of money, because there is a different price structure for legacy store vs. the various Merchant Solutions packages. You can see a comparison of the various Merchant Solutions Plans here: http://smallbusiness.yahoo.com/ecommerce/compare-plans

So what do you get with Merchant Solutions that you don't have with legacy store?

Two things mainly, a separate conventional hosting account (typically site.yourdomainname.com) and the option to enable Catalog Manager.

The first thing, a conventional hosting account, may or may not impress you. There are professional hosting packages available from, say, GoDaddy for only a few bucks a month, and I'm sorry to say but Yahoo Web Hosting is lacking considerably in this department. In the name of security they restrict or disable a large number of otherwise standard PHP libraries. And then, there is a "hard" restriction of how many emails per day you can send out from your PHP code (currently 200 or 250), which makes the platform practically useless for many business applications.

The second one, access to Catalog Manager, is more compelling. Catalog Manager is not just another interface to your products, it also offers these advantages:

1) You will automatically have a catalog.xml datafeed which can be used by outside processes (like comparison shopping engines.)

2) You will be able to add, modify, and delete custom fields across your entire product line, something that can only be done one by one in Editor.

3) You let third party developers tap into your catalog via the new Catalog API to add custom functionality to your store.

One thing to note, though, is that you can upgrade to Merchant Solutions, but chose not to enable Catalog Manager.

Will you notice anything in your store editor if you upgrade to Merchant Solutions?

No. The editor will stay exactly the same, none of your data will be altered, so nothing at all will visibly change.

How about editor V2 vs. V3?

You can upgrade from V2 to V3 with or without Merchant Solutions by clicking the Design Wizard link in your store manager. What will the upgrade do? It will delete all of your custom templates, and change all of your pages to use a more up to date template set with a new look, which you select from a number of available templates. This has some very important implications: unless you have a cookie cutter V2 store (using the standard, built-in yahoo store templates), you probably want to think twice before pulling the trigger on this. If you have any kind of custom template work, it will be erased as part of your upgrade to V3. If you do have custom templates, I really don't recommend upgrading to V3. V3 has nothing that cannot be accomplished in V2 also.

Summary:
1) You can upgrade to Merchant Solutions and from V2 to V3 completely independently. One does not depend on the other.

2) You can only have Catalog Manager if you upgrade to Merchant Solutions


Istvan Siposs
Y-Times

Don't publish your catalog

Catalog Manager (for non-legacy Yahoo Stores) provides a nicer, easier to use interface to update your products. You can sort and page through your items, look for items using simple and advanced searches, or edit or delete multiple items at once, tasks that are not very easily done in the store editor.

If you ever work in Catalog Manager, you may also have noticed the "Publish" button there. The inline help says, if you publish your catalog, all the changes will be immediately visible on your site. You may be tempted to use this function particularly if your editor usually takes a long time to publish, however, if your store is an editor-based store, publishing the catalog separately from the editor is not for you.

Catalog Manager was originally created to allow access to the product catalog for stores that are built on the web hosting account using "store tags". Today, of the thousands of Yahoo stores very few use store tags (and I don't recommend it either; read this posts about store tags vs RTML templates: http://www.ytimes.com/yahoo-store-tags-vs-rtml.html). Because store tags fetch information from the catalog whenever a page is requested (displayed), wherever you have a store tag referencing the price of an item for example, that price will always be as current as your last Catalog or Editor publish.

Store editor - or template driven - pages, however, work differently. When you publish your editor-based store, the final, live HTML pages are generated during the publish process, and those pages become static on your published, live site. A price displayed on such a page is simply static text.

So what happens if you have an editor-based store, and you publish only the catalog from Catalog Manager? Chances are your publish process will complete fairly quickly, and you will end up with a published catalog - and possibly an out of date store! Publishing the catalog basically pushes your product database live, but leaves all your static store pages intact, showing the state your EDITOR was last published. So, you can end up with Widget A displaying a price of $10.00 while the actual price of it may now be $12.00. A visitor going to Widget A's page will see the $10.00 price, add the product to the cart, and all of a sudden he or she will see $12.00 for the same product at checkout.

To make sure your live site and catalog are in synch, always publish your editor-based store from the Store Editor.

There is one case, though, when this out of synch behavior may be useful: that is when you have products with MAP pricing or where the manufacturer doesn't allow you to openly advertise a  price lower than the MSRP. In such a case, being able to charge a different dollar amount in the cart vs. the product page itself may be helpful. Here is how this could work:

• Widget A can only be advertised at $10.00
• You want to sell Widget A at $9.00
• You set the price of Widget A to $10.00 and publish your store editor
• Go back to catalog manager, and change the price of Widget A to $9.00
• Publish your CATALOG only.

Now, when you go to the page of Widget A, it will show $10.00, but when you add it to the cart, it will show $9.00. If you use this method, you may also want to put a line of text on the page asking your customers to put the item in the cart for a lower price.

Yahoo Store Incremental Publish being rolled out

As indicated in Yahoo Small Business's recent blog post of upcoming features, the long-awaited "incremental publish" feature is being rolled out this month. They are going server by server, so some merchants will see the change sooner then others.

What is incremental publish?

Incremental publish keeps track of what pages you edited and changed since the last time you published the store. Instead of the single "Publish" button, you will now have two buttons, one that says "Publish All", and the other that says "Publish Changes". "Publish All" does the same as the current "Publish" button, it generates and publishes all pages in the store. "Publish Changes", on the other hand, will only publish the pages that changed.

This can be a huge potential time saver especially for large stores whose publish takes hours normally.

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 event of your add to cart button. This is of course not fool-proof, but this is the only way to prevent the adding of an item to the floating cart. Canceling the submit event does not work with the floating cart.

3) This may be the strangest, but you need to put the following hidden form fields right after the opening FORM tag of the order form, otherwise customer-selected options are not passed on to the floating cart:

multiple-add, allow-zero, vwcatalog, and vwitem0

What screen resolution should I use?

I get this question often. Or variations of it such as "is it safe to expand my site to 1200px now?"

According to W3Scools, as of January of this year, about 13% of all internet users are still on 1024x768, which is a high enough proportion to make me play it safe and set the max width at 980px so that these folks can see the site OK. If you go any higher, these people will have to scroll sideways, which is traditionally a major "no-no" (simply because it's annoying.)

However, you should check your own stats to see what percentage of YOUR visitors have that resolution, because your demographic segment may very well be different from the average.