Loops & Hoops

The new Loops & Hoops site, www.loopsnhoops.com, opened for business this week. It’s been most of the year in development, and I’m pretty happy to have it live at last.

Loops & Hoops is a custom embroidery company geared to the equestrian market, a one-woman shop run by a local businessperson. Her and her daughters spend a lot of time riding, and she saw a market for barn and horse-show logos, as well as for personalized tack. The store’s mission is to let riders and barn owners personalize saddle pads, as well as shirts, hats and jackets, to highlight their clubs and other connections.

The first decision to be made was which shopping cart to use. The budget didn’t allow for creating one from scratch, and considering the needs of the business it wouldn’t make sense to do that anyway. The off-the-shelf ones did (at first glance) everything we were going to need. I’d had it up to here with CubeCart, which I’d used for another customer, after going through a couple of rounds of finger-pointing between the developers and the hosting company while trying to get support.

After reviewing a couple of options (the web site Taming The Beast was helpful here), we settled on X-Cart, a commercial php/MySQL product. What appealed to us was the tight linkage available between the developers and a set of hosting facilities. We settled on EWD, which offered a steep discount (specifically, free) on the package when signing up for service, full installation, and a limit on how many sites any given box would host.

Developing and Designing for X-Cart

Despite the claims of X-Cart (and in all fairness a lot of other package providers) to be “W3C XHTML 1.0 compliance of X-Cart storefront out of the box,” the sheer complexity of the code locks in certain compromises before you even begin. It’s heavily table dependent, from the overall structure of the page all the way down to tiny details like the shape of a “submit” button. What’s more, the code is contained in hundreds of small template files and they’re not always completely self-contained; the opening of a table tag may be in the module, but the closing may be in its parent. So as I tried to eliminate unnecessary table structures from the bottom up, I hit a few brick walls that convinced me it wasn’t going to be worth it. It would be a nice commercial venture to develop a “skin” that’s completely table-less.

Also, buried deep within the code are chunks that aren’t really as compliant as you might hope. There are inline styles, table row and cell height and padding specs, and even font tags. I guess under XML you can call a tag almost anything you like, even “font.” And they are all classed out, font class=”box”, as opposed to font face=”helvetica”, so even if you change them to “span” it doesn’t make any difference.

The very good news is the Webmaster Mode tool. This lets you do a couple of things. One is, click on any live text and it will pop up a window that lets you change the language entry in the database for that section. Click on a “Welcome To” header, and you can edit it to “Greetings, This Is The Home Of” completely on the fly.

But more importantly, you get a popup window that lists in hierarchical form all the templates for the store page that you’re on. As you move your cursor up and down the list, the section or sections of the page that are generated by that template, and when you find the one you want, it opens for editing in a new tab. Combined with FireFox’s “Web Developer” add-on you can zero in very quickly on the trouble spots — something that would take extensive digging through subdirectories with other programs.

There’s also a separate “edit templates” tool from the admin screen that lets you go into individual modules and work on the CSS and JavaScript files.

All of which is to say, some of the features make designing very difficult, and some make it very easy. But there are limits, and to a certain extent that’s a good thing. Most shopping carts you see on line have a very similar layout with product and store navigation on the left, features and highlights on the right. As Jakob Nielsen would point out, customers spend most of their time on sites that aren’t yours, so it pays to pay attention to what they’re getting used to.

The client wanted something bright and open, with lots of white. She’d had a logo designed with two shades of blue and a beige, so that’s what we went with for our color palette. I chose a sympathetic olive green to give some areas a little more contrast. The logo itself is in a version of the Berkeley font, so to boost the brand identity a little I used sIFR to make all the heads and subheads that font as well. sIFR plays a big role a little later on. (I’ve gone over some uses of sIFR before here, and here.)

The Line

After getting the design part right (or at least as close as possible) the biggest chunk of time is blowing in the product line. Besides the very important saddle-pad item, we had several lines of shirts, hats, jackets, and fleece to make available. Each comes in multiple colors and sizes. X-Cart has two different ways of creating and presenting these variations, and it’s a very important distinction that isn’t made clear in the documentation, and is misleadingly labelled in the interface.

One is the Product Variant, the other is the Price Modifier. The misleading part is that you can modify the prices of individual options in either. Originally I’d set up everything to be a Product Variant, because all the colors and sizes, and all the embroidery options, were going to be the same price.

That’s where we went up a blind alley. What happens in the Product Variants is that for each variant the program builds a matrix, mapping every Variant with every other Variant, and turns that into a multidimensional JavaScript array that it sends out to the browser in several different ways. So if you have ten colors of a shirt, in six different sizes, with six different options for an embroidery font and twelve different options for an embroidery color, that’s 10 x 6 x 6 x 12 = 4,320 different configurations. I was finding that a simple product page weighted close to 1MB!

After talking with their (very helpful) tech support we learned that Price Modifiers don’t really have anything to do with the price, and that everything that we didn’t want reflected in the product image view should not be a Product Variant, but a Price Modifier — even though they were going to be the same price. So the only element that’s a Product Variant is the color of the garment, because that’s going to change on the users screen as they pick colors off of the drop-down list.

Anyway, if this page has any helpful information for other developers, that’s it.

Most of the garment vendors had pretty easy-to-use marketing sections, where product images in all the available colors could be had. Some were better than others, but TIFFs or JPGs were available that could be scaled to a consistent 350px size site-wide. There were also model shots available, which we used for the category pages. Both categories and individual products let you assign full-size pictures as well as thumbnails that are used for the index pages. And for each Product Variant you can upload its own individual image in the right color.

The Preview

The client discovered a couple of competitors’ sites that let users build a preview of their embroidery choices. The best was a commercial product using Flash that you could license for around $20,000. Definitely over budget. Others had very simple options, like seeing “ABC” in whatever font you chose.

I decided to use the tools at hand to build something in between, with a level of interactivity that was manageable to develop and use, but still had a small coolness factor. The tools are (as warned about above) sIFR and JavaScript.

Since the product preview already had a JavaScript hook built into it to change the preview image as users switched colors (pick “red” off the list, the red shirt appears; pick “yellow” and it’s replaced with a yellow one), I built off of that to make other things happen. Each color of each product had to be “eyedroppered” to get its correct hex color value. These were put into an array so that when “Forest Green” is chosen a very good match can be generated. We wanted users to be able to specify two lines of text, and pick one of the stock equestrian-themed images on file. I started out by added a “Your Embroidery Preview” box, and setting up a few user text entry fields and a separate Price Modifier for an image selector.

Then I made new functions attached to the existing one that would take the entry in the text field, and sIFR-ize it to the font and color choices that the user made. Also, as different color garments were chosen, the background color was changed to match. Since the sIFR element is transparent, it would seamlessly adapt. The sIFR_rollback function was invaluable here. Whenever any change was made to the text element — the text itself, the color, the font — it rolls back the element and creates a new one.

The images came as bitmaps from the stock house, and I made two versions of each; one was a PNG with an alpha channeland small drop-shadow, which would look nice with whatever background color was chosen. The other was a transparent GIF for browsers that don’t properly support PNG’s multi-level transparency. They’re named the same, and the script has a browser check to add the right suffix when the file is called.

We also wanted to let users put the image at the top, bottom or center. So using the DOM, the script destroys and creates nodes and positions them appropriately when that option is changed.

The Penultimate Hurdle

We wanted to offer quotes on other artwork in an easy way. Say you run a barn with your own logo and want to find out what it would take to get it embroidered. Before it can be emboidered, it has to be digitized to use on the embroidery machines and that costs money depending on its complexity. So we have a free product which we highlight on every page for “Custom Embroidery Quotation.” Using a commercial add on that lets users upload their own images, once a preview is added to the Shopping Cart the user can upload their image at checkout time, which comes over attached to the order.

The Last Hurdle

One serious flaw that had us scratching our heads for the week prior to launch was shipping. The client drops everything with UPS daily, but the UPS quotation interface is severely limited. UPS rates are based not just on weight, but on package dimensions. And this is where things get sticky because X-Cart has no method for specifying dimensions. You can lose your shirt shipping a batch of shirts of the dimensions are such that you’ve billed the customer for a too-low rate. This is a long-standing X-Cart issue that they don’t seem to have any interest in fixing. So we went with free shipping instead, working in an estimated cost to the base price of the product.

Gallery

The other piece is the Gallery, where she can show off work that she’s one. For this, I took a bunch of her photos from various shows, cleaned and resized them, and put them into a Flash application called Slide Show Pro. It works off of an easy to build XML file that specifies image locations and thumbnails. I like it because it does exactly what I need for this site, and doesn’t make me worry about stuff I don’t need.

In Conclusion

Check out the site and play around a little with the Embroidery Preview. Don’t order things you don’t want, this is a live site. But let me know if it works for you.

Update

The proprietess has moved, and we’re waiting for her to get set up in her next home to set up her machine. Until then we’re off-line.