Tom McGee's Blog

The new Loops & Hoops site, www​.loop​snhoops​.com, opened for busi­ness this week. It’s been most of the year in devel­op­ment, and I’m pretty happy to have it live at last.

Loops & Hoops is a cus­tom embroi­dery com­pany geared to the eques­trian mar­ket, a one-woman shop run by a local busi­nessper­son. Her and her daugh­ters spend a lot of time rid­ing, and she saw a mar­ket for barn and horse-show logos, as well as for per­son­al­ized tack. The store’s mis­sion is to let rid­ers and barn own­ers per­son­al­ize sad­dle pads, as well as shirts, hats and jack­ets, to high­light their clubs and other connections.

The first deci­sion to be made was which shop­ping cart to use. The bud­get didn’t allow for cre­at­ing one from scratch, and con­sid­er­ing the needs of the busi­ness it wouldn’t make sense to do that any­way. The off-the-shelf ones did (at first glance) every­thing we were going to need. I’d had it up to here with Cube­Cart, which I’d used for another cus­tomer, after going through a cou­ple of rounds of finger-pointing between the devel­op­ers and the host­ing com­pany while try­ing to get support.

After review­ing a cou­ple of options (the web site Tam­ing The Beast was help­ful here), we set­tled on X-Cart, a com­mer­cial php/MySQL prod­uct. What appealed to us was the tight link­age avail­able between the devel­op­ers and a set of host­ing facil­i­ties. We set­tled on EWD, which offered a steep dis­count (specif­i­cally, free) on the pack­age when sign­ing up for ser­vice, full instal­la­tion, and a limit on how many sites any given box would host.

Devel­op­ing and Design­ing for X-Cart

Despite the claims of X-Cart (and in all fair­ness a lot of other pack­age providers) to be “W3C XHTML 1.0 com­pli­ance of X-Cart store­front out of the box,” the sheer com­plex­ity of the code locks in cer­tain com­pro­mises before you even begin. It’s heav­ily table depen­dent, from the over­all struc­ture of the page all the way down to tiny details like the shape of a “sub­mit” but­ton. What’s more, the code is con­tained in hun­dreds of small tem­plate files and they’re not always com­pletely self-contained; the open­ing of a table tag may be in the mod­ule, but the clos­ing may be in its par­ent. So as I tried to elim­i­nate unnec­es­sary table struc­tures from the bot­tom up, I hit a few brick walls that con­vinced me it wasn’t going to be worth it. It would be a nice com­mer­cial ven­ture to develop a “skin” that’s com­pletely table-less.

Also, buried deep within the code are chunks that aren’t really as com­pli­ant 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 any­thing 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 Web­mas­ter Mode tool. This lets you do a cou­ple of things. One is, click on any live text and it will pop up a win­dow that lets you change the lan­guage entry in the data­base for that sec­tion. Click on a “Wel­come To” header, and you can edit it to “Greet­ings, This Is The Home Of” com­pletely on the fly.

But more impor­tantly, you get a popup win­dow that lists in hier­ar­chi­cal form all the tem­plates for the store page that you’re on. As you move your cur­sor up and down the list, the sec­tion or sec­tions of the page that are gen­er­ated by that tem­plate, and when you find the one you want, it opens for edit­ing in a new tab. Com­bined with FireFox’s “Web Devel­oper” add-on you can zero in very quickly on the trou­ble spots — some­thing that would take exten­sive dig­ging through sub­di­rec­to­ries with other programs.

There’s also a sep­a­rate “edit tem­plates” tool from the admin screen that lets you go into indi­vid­ual mod­ules and work on the CSS and JavaScript files.

All of which is to say, some of the fea­tures make design­ing very dif­fi­cult, and some make it very easy. But there are lim­its, and to a cer­tain extent that’s a good thing. Most shop­ping carts you see on line have a very sim­i­lar lay­out with prod­uct and store nav­i­ga­tion on the left, fea­tures and high­lights on the right. As Jakob Nielsen would point out, cus­tomers spend most of their time on sites that aren’t yours, so it pays to pay atten­tion to what they’re get­ting used to.

The client wanted some­thing 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 sym­pa­thetic olive green to give some areas a lit­tle more con­trast. The logo itself is in a ver­sion of the Berke­ley font, so to boost the brand iden­tity a lit­tle I used sIFR to make all the heads and sub­heads that font as well. sIFR plays a big role a lit­tle later on. (I’ve gone over some uses of sIFR before here, and here.)

The Line

After get­ting the design part right (or at least as close as pos­si­ble) the biggest chunk of time is blow­ing in the prod­uct line. Besides the very impor­tant saddle-pad item, we had sev­eral lines of shirts, hats, jack­ets, and fleece to make avail­able. Each comes in mul­ti­ple col­ors and sizes. X-Cart has two dif­fer­ent ways of cre­at­ing and pre­sent­ing these vari­a­tions, and it’s a very impor­tant dis­tinc­tion that isn’t made clear in the doc­u­men­ta­tion, and is mis­lead­ingly labelled in the interface.

One is the Prod­uct Vari­ant, the other is the Price Mod­i­fier. The mis­lead­ing part is that you can mod­ify the prices of indi­vid­ual options in either. Orig­i­nally I’d set up every­thing to be a Prod­uct Vari­ant, because all the col­ors and sizes, and all the embroi­dery options, were going to be the same price.

That’s where we went up a blind alley. What hap­pens in the Prod­uct Vari­ants is that for each vari­ant the pro­gram builds a matrix, map­ping every Vari­ant with every other Vari­ant, and turns that into a mul­ti­di­men­sional JavaScript array that it sends out to the browser in sev­eral dif­fer­ent ways. So if you have ten col­ors of a shirt, in six dif­fer­ent sizes, with six dif­fer­ent options for an embroi­dery font and twelve dif­fer­ent options for an embroi­dery color, that’s 10 x 6 x 6 x 12 = 4,320 dif­fer­ent con­fig­u­ra­tions. I was find­ing that a sim­ple prod­uct page weighted close to 1MB!

After talk­ing with their (very help­ful) tech sup­port we learned that Price Mod­i­fiers don’t really have any­thing to do with the price, and that every­thing that we didn’t want reflected in the prod­uct image view should not be a Prod­uct Vari­ant, but a Price Mod­i­fier — even though they were going to be the same price. So the only ele­ment that’s a Prod­uct Vari­ant is the color of the gar­ment, because that’s going to change on the users screen as they pick col­ors off of the drop-down list.

Any­way, if this page has any help­ful infor­ma­tion for other devel­op­ers, that’s it.

Most of the gar­ment ven­dors had pretty easy-to-use mar­ket­ing sec­tions, where prod­uct images in all the avail­able col­ors could be had. Some were bet­ter than oth­ers, but TIFFs or JPGs were avail­able that could be scaled to a con­sis­tent 350px size site-wide. There were also model shots avail­able, which we used for the cat­e­gory pages. Both cat­e­gories and indi­vid­ual prod­ucts let you assign full-size pic­tures as well as thumb­nails that are used for the index pages. And for each Prod­uct Vari­ant you can upload its own indi­vid­ual image in the right color.

The Pre­view

The client dis­cov­ered a cou­ple of com­peti­tors’ sites that let users build a pre­view of their embroi­dery choices. The best was a com­mer­cial prod­uct using Flash that you could license for around $20,000. Def­i­nitely over bud­get. Oth­ers had very sim­ple options, like see­ing “ABC” in what­ever font you chose.

I decided to use the tools at hand to build some­thing in between, with a level of inter­ac­tiv­ity that was man­age­able to develop and use, but still had a small cool­ness fac­tor. The tools are (as warned about above) sIFR and JavaScript.

Since the prod­uct pre­view already had a JavaScript hook built into it to change the pre­view image as users switched col­ors (pick “red” off the list, the red shirt appears; pick “yel­low” and it’s replaced with a yel­low one), I built off of that to make other things hap­pen. Each color of each prod­uct had to be “eye­drop­pered” to get its cor­rect hex color value. These were put into an array so that when “For­est Green” is cho­sen a very good match can be gen­er­ated. We wanted users to be able to spec­ify two lines of text, and pick one of the stock equestrian-themed images on file. I started out by added a “Your Embroi­dery Pre­view” box, and set­ting up a few user text entry fields and a sep­a­rate Price Mod­i­fier for an image selector.

Then I made new func­tions attached to the exist­ing 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 dif­fer­ent color gar­ments were cho­sen, the back­ground color was changed to match. Since the sIFR ele­ment is trans­par­ent, it would seam­lessly adapt. The sIFR_rollback func­tion was invalu­able here. When­ever any change was made to the text ele­ment — the text itself, the color, the font — it rolls back the ele­ment and cre­ates a new one.

The images came as bitmaps from the stock house, and I made two ver­sions of each; one was a PNG with an alpha chan­neland small drop-shadow, which would look nice with what­ever back­ground color was cho­sen. The other was a trans­par­ent GIF for browsers that don’t prop­erly sup­port PNG’s multi-level trans­parency. They’re named the same, and the script has a browser check to add the right suf­fix when the file is called.

We also wanted to let users put the image at the top, bot­tom or cen­ter. So using the DOM, the script destroys and cre­ates nodes and posi­tions them appro­pri­ately when that option is changed.

The Penul­ti­mate Hurdle

We wanted to offer quotes on other art­work 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 embroi­dered. Before it can be emboi­dered, it has to be dig­i­tized to use on the embroi­dery machines and that costs money depend­ing on its com­plex­ity. So we have a free prod­uct which we high­light on every page for “Cus­tom Embroi­dery Quo­ta­tion.” Using a com­mer­cial add on that lets users upload their own images, once a pre­view is added to the Shop­ping Cart the user can upload their image at check­out time, which comes over attached to the order.

The Last Hurdle

One seri­ous flaw that had us scratch­ing our heads for the week prior to launch was ship­ping. The client drops every­thing with UPS daily, but the UPS quo­ta­tion inter­face is severely lim­ited. UPS rates are based not just on weight, but on pack­age dimen­sions. And this is where things get sticky because X-Cart has no method for spec­i­fy­ing dimen­sions. You can lose your shirt ship­ping a batch of shirts of the dimen­sions are such that you’ve billed the cus­tomer for a too-low rate. This is a long-standing X-Cart issue that they don’t seem to have any inter­est in fix­ing. So we went with free ship­ping instead, work­ing in an esti­mated 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 pho­tos from var­i­ous shows, cleaned and resized them, and put them into a Flash appli­ca­tion called Slide Show Pro. It works off of an easy to build XML file that spec­i­fies image loca­tions and thumb­nails. 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 Con­clu­sion

Check out the site and play around a lit­tle with the Embroi­dery Pre­view. Don’t order things you don’t want, this is a live site. But let me know if it works for you.

Update

The pro­pri­et­ess has moved, and we’re wait­ing for her to get set up in her next home to set up her machine. Until then we’re off-line.