Archives

color schemes
   rss feed:
28 Nov 2010

Prometheus reborn – A week or so back, when I first started writing here again after a long hiatus, I mentioned a big project that had been completed, with a promise that I would talk about it soon. I had a few things to get out of my system before that, but my plate is clear now, so I guess it’s time to live up to that promise.

“The only reason I start some projects is because I have no idea what I’m getting myself into...”

Some of you may remember a note I posted here last year about my brother Brian’s business, where he sells handmade candles. Last year’s note was just a quick plug of the newly-launched website, along with a mention that I wrote the “Story of Prometheus” text on the “about us” page. Well, this original website, as impressive as it was, is now no more. I present to you the new and improved Promethean Candle Boutique, purveyor of fine handmade candles.

Now I must warn you: today’s entry is very long. Most of it—the next 3,500 words, in fact—is a general discussion of the design process from my perspective. If you have no interest in web design or coding, if acronyms like HTML, CSS, and PHP give you hives, and if you’d just rather look at pretty pictures of some lovely candles, you may want to skip ahead to that part. It’s OK, I don’t mind.

While my part in the original website was limited to writing a bit of copy, I played a much larger role in the design of the new website. “Design” is a rather ambiguous word, though, and in the sense that most people think of when they hear it—that is, planning the form and structure—I didn’t have much to do with the site design other than as a sounding board for some of Brian’s ideas. In terms of the functionality, though, I did a lot. Brian needed things done dynamically both client-side (in the browser) and server-side (before the page even gets to the browser), and while he’s fairly handy with markup like HTML and CSS, he’s not really a coder. Dynamic pages require scripting languages like Javascript (for the client-side stuff) and PHP (for the server-side stuff), and that’s where I came in.

As anyone who has read my background story will know, I started out in university with the intention of being a computer science major. I ended up graduating as an English Lit major, of course, primarily because Comp Sci requires a lot of advanced mathematics and math is possibly my least favorite subject. My adventures in computer science were not a total wash, though, and there were two aspects of the field that I really did enjoy: logic design and programming. The former isn’t really that useful outside of the field of computer science, but programming has been something I have kept up with as a hobby. This very website was built from the ground up in PHP, for example. Granted, it’s a seven-year-old PHP website that is now held together with shoestring and bubble gum and desperately needs a complete rebuild, but it’s still my code.

So when Brian started talking about some of the things he wanted the new website to do, I was interested. I don’t do web design for hire—I tried that once, many years ago, and that was enough. As a translator, I’m now quite used to working with clients, and I have enough clout by this point that I can reason with my clients and they will generally listen to me. But I’m not a professional web designer and never have been—I was a hobbyist who agreed to take on the project because the client didn’t want to hire a more expensive professional. I won’t go into the details, but let’s just say that after that project I decided I would never do web design for hire again. So I suppose it’s fortunate that this project was done pro bono.

I honestly don’t remember when we started working on the redesign, but I do remember that our original goal was to finish and launch the site by the end of June. How innocent we were. Needless to say, June came and went, along with numerous other “deadlines.” After a whirlwind week at the beginning of this month, though, we were finally able to go ahead with the launch. This was a huge project for both of us, so I thought I would talk a little about what it was like and then end with a look at some of Brian’s candles, including some brand new products that I’m pretty fond of.

The original site served its purpose and Brian did receive a lot of compliments on it, but when it came down to actually ordering candles, it was rather unwieldy. Because Brian pours his candles to order, there are a lot of variables that need to be considered every time a customer creates a custom candle. For example, depending on the type of candle, there can be nearly twenty different sizes to choose from. Then you have different types of wax (up to four), a choice of nearly fifty different colors and almost as many fragrances, not to mention other options like inclusions and essential oils. If that sounds complicated, it’s because it is. Unfortunately, all of the order forms on the original site were simply static HTML forms, so it was impossible to reflect all of the ways the different variables interacted with each other. The only way around this problem was to have different forms for each type of wax (regular paraffin, mottled paraffin, palm, and soy), multiplied by the number of layers in the candle. The long and short of it was that I think he had twelve different order forms for pillar candles alone, and the whole site was somewhere in the range of eighty static pages, with most of those dedicated to order forms.

Reducing the number of pages (and particularly the number of order forms) was a high priority for the redesign, so the first thing I did was design a dynamic order form for the pillar candles, which are the most complex (they have the greatest number of variables). In fact, this was originally the only thing I was going to be doing—I was just supposed to design some order forms and that was it. Even after the project ballooned far beyond that, even on the day that we finally launched the site, the folder on my system that held all of the relevant files was still called “order forms.” It wasn’t until after the relaunch that I decided to rename the folder, since it did in fact contain the entire site.

Like I said above, the pillar candles order form is the most complex of the eight different product forms. There are 19 sizes and shapes, four waxes, 45 colors, and 43 different fragrances (including unscented). The number of permutations for all of these variables measures in the billions (I actually did figure out exactly how many unique candles could be produced, but I’ll talk more about that later).

Thinking back on it now, we didn’t really go about things the right way. Ideally, you want to have a finalized design document that you can code from—you want to have everything there in front of you so you can see the big picture. The problem is that I don’t think Brian knew what we were getting into either, and the only way we could learn what the pitfalls were going to be was by marching forward and plunging headlong into them.

If you haven’t done so already, I would encourage you to check out one of the order forms, as that will make it a lot easier to understand what I’m talking about in terms of the challenges we faced. Go through the form step by step and build your own candle—let’s say, for example, you wanted to build a soy pillar candle—just for the fun of it. You don’t have to actually order it, of course (although I’m sure Brian wouldn’t mind if you did). If you play around with the form for a little while, you’ll see that there is an interplay of variables. Both fragrance and quantity are completely independent—that is, the choices there don’t affect any of the other steps, and none of the other steps affect them—but the first three variables are intertwined. For example, two-inch wide candles are only available in one color, and three-inch high candles are available in a maximum of three colors. Palm wax candles, due to the nature of the wax itself, are only available in one color no matter what the size. Now, that may not seem too bad, but when you have to code all of those conditions into the form, things can get very complicated very quickly.

One of the big things we struggled with in building this form was figuring out how the interface should behave when a user did something that wasn’t allowed. For example, what if the user went to Step 3 first (even though the steps are numbered, you can actually do them in any order), chose five layers, and then went into Step 2 and chose palm wax? We ultimately decided on a Javascript alert box to warn the user of the conflict and give them the choice: did they want to erase their additional layer choices, or did they want to cancel the wax choice? Simple in theory, but it required a bit of thinking to get everything working properly, and we went through a number of possible solutions before we arrived at this one.

Probably the biggest headache was Step 3 itself. If you’ve used the form, you’ve probably already seen something I’m very proud of: the color preview. As you select layers, the colored box on the right changes to give you a rough graphic representation of what your candle will look like (without, of course, diagonally tilted layers—that would have been a whole other ball of wax, no pun intended). It took me a while to build that, but I think it gives the form that extra special something. In addition to the color preview, there is also a large chunk of code that decides how many layers to display depending on the variables mentioned above (size and wax type). You’ll also notice that, when you click “Add layers,” all the dropdown menus but the one for the first layer are grayed out. You actually have to select a color for the first layer before the second layer will become selectable, and so on. Likewise, if for whatever reason you deselected a layer (set it back to “none”), the next layer will gray out again—and the form won’t let you deselect any but the last layer selected. Looking at it now, it seems pretty obvious, but it took us a long time to get to that point. Originally we had a lot of “fool-proofing” code that would try to handle all of the different ways a user could screw up an order—for example, what did we do if the user selected the first, second, and fourth layer, but left the third layer blank?—but we got to the point where the code was threatening to collapse under its own weight. Ultimately we decided that the best way to handle possible problems was to not let the user do anything that might screw things up in the first place. Thus the grayed out dropdown menus, among other features. Most users will never even trigger most of the code I wrote, but you have to cover every possibility.

As I mentioned above, we didn’t really have a solid design document when I began designing the form. We did have a list of things that the form needed to do, but this list changed and evolved as time went on. Brian and I spent a lot of time voice chatting over ICQ, and I learned to dread one particular five word phrase: “I’ve got an idea.” Whenever Brian had an idea, I prepared for pain and suffering. It got to the point where I would physically flinch whenever he said that—and he said it a lot. In the end, though, the form is as nifty and easy to use as it is because Brian had all those ideas.

I had ideas, too, of course, and we shared those ideas over many, many voice chatting sessions. Obviously our relationship was significantly different from the usual client-coder relationship. For one, Brian is not your typical client. Most clients know little about what they are hiring other people to do (which is usually why they hire those people in the first place). Like I mentioned above, Brian handled much of the redesign himself. Not only did he do most of the markup, but he handled all of the graphic design elements as well. So we were more like a design team than a client and a coder. And of course he’s my brother, so I could say to him, “I really don’t think that’s a good idea”—and he would actually listen. I always told him that he had the final word, but I will admit that if I really thought something was a bad idea I also pushed hard to change his mind. But we never reached any real impasses. There were times when I wanted to do something one way and he wanted to do it another, but we were always able to come to some sort of compromise. In fact, I think Brian came up with most of these compromises—I tended to be so deep in the code that I often had a hard time seeing the bigger picture, and Brian was able to take a step back and find another approach. We never had any real disagreements, which is good, because it’s hard to threaten someone with violence when you’re halfway around the world from them.

When we finally got the pillar candles form working the way we wanted it, the next step was to adapt this form for use with the other product types. In addition to the pillar candles, there are also essential oil candles, jar candles, inclusion candles, hanji candles, Himalayan salt candles, body oils, and bath salts (I’ll talk in more detail about some of these products later). The jar candles are the most similar to the pillar candles, so I adapted the form to the jar candles first, and then I worked my way from most to least complicated. And then I was done—or so I thought.

At this point, what we had were eight beautiful, easy-to-use forms, but they weren’t hooked up to anything. That is, you could create your own custom candle, but hitting the “Add to Cart” button just brought you to a sparse PHP page that displayed the contents of the form. What we needed was a shopping cart that would handle this input and eventually allow the user to check out. Brian had found something called ZenCart, and after a quick glance at it I assumed that it would fit our needs. Once we got everything else done and sat down to tackle the shopping cart, though, we realized that ZenCart was not what we needed. It is, in fact, a complete e-commerce solution, which means that the program takes care of everything for you, from the storefront itself to the shopping cart. The problem is that we already had a perfectly functional storefront—one that was, to be perfectly honest, significantly better than anything you could produce with ZenCart. For us, using ZenCart would have been like reinventing 90% of the wheel.

As Brian looked around for other options, I began to get a sinking feeling in the pit of my stomach. Soon it became apparent that I was going to have to build the back end of the website as well. I must admit I freaked out a bit at this prospect—I had told Brian from the very beginning that I had no experience building back ends for online commerce sites and that I had no faith in my ability to learn on short notice. But there we were, out of options, and it was either take the plunge or leave my brother hanging. For all my misgivings, it was never really a question of whether I would do it, just how much I would kick and scream along the way.

What we needed as far as the back end went can be broken up into two parts: the shopping cart itself and the code required to accept payments via credit card, etc. The shopping cart part wasn’t really that hard. I had all the necessary knowledge of PHP to build a shopping cart that would store orders for the user until they were ready to checkout. It was the accepting of credit card information and handling the transactions that freaked me out. Fortunately, Brian already had a PayPal merchant account that would handle the nitty gritty details of actually charging the credit cards. He called up PayPal support and asked them what he needed to do to hook up our shopping cart to PayPal’s innards, and the support tech gave him a link and said, “Show this to your developer.” Brian relayed his message to me and said, “I guess that means you.” It was funny, because never once during the project did I consider myself a “web developer,” and I still don’t. I’m just this guy, you know? A guy who happens to know a little bit about web coding and who is helping out his brother.

I won’t go into the details of the PayPal system, as that would probably bore most of you to tears—if you’re not weeping already, that is—but suffice it to say that they have a sandbox environment set up so that you can test your application without having to deal with live credit card information and actual charges. There are two ways that checkout can be accomplished. One way is the direct payment method, where you use the PayPal servers but build your own interface to collect the necessary information. This way, the user never actually leaves the site, even though PayPal handles the actual transaction. The second way is to direct the user to the PayPal site so that they can check out with their PayPal account. I decided to do the direct payment method first, because I figured it would be more difficult, and then do the PayPal checkout later.

There were a few things that I did have to learn for the direct payment method, but mostly it was PHP that I was already familiar with. There was a lot of trial and error, but thanks to the sandbox environment I was able to work out all the kinks in advance. Unfortunately, the PayPal checkout method turned out to be more complicated than I had expected. In some ways, I think it might actually be more complicated, since you have to keep track of more variables—or maybe it was just because I was running up against a deadline and my mind was already frazzled. Unlike our previous “deadlines,” though, this deadline was one that had to be kept—things were about to get very busy for me at school, and if we hadn’t put the site up then, it probably still wouldn’t be up and I wouldn’t be writing this now. So, with a couple of hours to go before the deadline (which was in the middle of the night back in the States), we had to make a decision. Anything that was “not mission critical” (a label that we attached to more and more things as the deadline drew closer) would just have to wait, and I would work on them when I got the chance. The PayPal checkout was one of those things, and if you go all the way through the order process to the checkout stage, you’ll notice that it’s still not there. Fortunately the direct payment method works like a charm.

When it came time to launch the website, both of us were feeling very nervous. After all the work we had done and all the snags along the way, I think we both expected something to go terribly wrong. Had a flock of disoriented geese crashed through my window and impaled themselves in my hard drive, for example, I probably wouldn’t have been all that surprised. The PayPal API documentation claimed that launching a live version was a fairly simple operation—and amazingly enough they turned out to be right. There were a few hiccups in other areas of the site that were caused by last minute changes that affected things in ways we had not foreseen, but the things that had worried us the most turned out to be non-issues. Over the next few days we fixed a number of issues, some minor and some not so minor. The site has been up and running for the past couple of weeks now, and orders have been coming in.

I think it’s safe to say that neither of us had any idea what we were getting into when we started this redesign. As we neared launch, I told Brian that if I had known how insane it was going to be, I might have never have agreed to do it. Even if someone had told me exactly how insane it was going to be, though, I probably would have done it anyway, simply because I’m an optimist—I wouldn’t have believed that it could be as time-consuming and brain-numbing as it turned out to be. But I’ve found that most of the things worth doing in life are like that. The only reason I start some projects is because I have no idea what I’m getting myself into, and at a certain point the only thing that keeps me going is willpower and an extreme distaste for failure. Once I’m done and I look back on it, I’m glad I’ve done it, but there’s no way I would ever do it again. At least, this is what I tell myself until the next big thing comes along and I go through the process all over again. It’s probably a good thing I have this mental handicap, though, because I suspect that otherwise I would never achieve anything worthwhile.

If you’re just joining us from the top of today’s entry, rest assured that there will be no talk of coding or design from here on out. Instead, I want to talk a little about the candles that Brian makes. I talked about the pillar candles in the design discussion above, but for those of you who weren’t here for that, I think what makes these candles special is the sheer depth of choice. You can get pillar candles in all sorts of places, but I don’t know of any candle shop that allows you to design your own candle with so many choices. I was curious about how many possible candles there would be if you figured in size and shape, color, wax type, and fragrance, so I sat down and did some calculations. It turns out that the number of unique pillar candles is 94,962,559,7254. That’s nearly 100 billion (note: my original calculations were a bit off— these figures, and those that follow, are correct). Enough so that if Brian made all of them, he could give every single person on earth 14 candles, and every one of those candles would be unique. Of course, if he were able to make one candle every hour (which is not possible, but just for the sake of argument), it would take him almost 11 million years to make them all. If you were really quick with the order form and could order a candle once every ten seconds, it would still take you over over 30,000 years to get through them all. That, my friends, is a lot of candles.

While these handmade soy candles and other pillar candles offer many opportunities for customization, Brian sells a lot of other interesting products as well. There are the essential oil candles, which aren’t so much for decoration (as they all use white soy wax, they all look basically the same) as they are for aromatherapy—each candle is impregnated with essential oils like tea tree oil, lavender oil, and even exotic oils like frankincense and myrrh. My personal favorites, though, are the “lantern-style” candles: the inclusion candles, hanji candles, and Himalayan salt candles. Inclusion candles are soy candles encased in hard paraffin shells, and various materials are included in these shells, thus the name. Most of these included materials are glass, but there are also stones, moss, and even coffee beans. These candles really need to be seen to be appreciated, though, so here is a photo.

This candle is one of a series called “Luminous Window,” and this is the “Multi” version. Because the paraffin shell has a much higher melt point than the soy pillar on the inside, the shell remains intact as the inner candle burns down. Once the inner candle has completely burned away, you can place tea lights inside the shell to light it up.

The hanji candles are another type of lantern candle. “Hanji” is the Korean word for Korean paper, and the paraffin shells of these candles have Korean paper in them rather than inclusions. These candles were actually Hyunjin’s idea, so we have to give her credit. I think these may be my favorite candles of all, but then again I might be a little biased. Here are some photos of a few of the hanji candles.

This model is called “quail egg,” mainly because this paper has always reminded me of the pattern you see on quail eggs.

Here you can see the interior of the candle and how the inner pillar burns down, leaving the paraffin shell. This candle is called “spring.”

Here is a fully lit candle—you can see why I call them “lantern-style candles.” This particular candle is known as “hanja,” which is the Korean term for Chinese characters. There is another model with “hangul,” or the Korean alphabet.

The third type of lantern-style candle is the Himalayan salt candle. These are palm or soy candles inside vessels made from Himalayan salt. Salt lamps seem to be fairly popular these days, and these candles are an all-natural version of these lamps.

These are just a few of the candle photos Brian has up on the site. If you want to see more, the gallery page currently has 195 photographs of products, and he plans to add more in the future.

In addition to working on the new website, I have watched as Brian has built his business from the ground up. We definitely share a perfectionist streak, and feel that there’s no point in doing something unless you’re going to do it properly. When we were in the States last, I watched Brian make a number of candles, and I was really impressed with how thorough he was. I was also there for the birth of the hanji candle, when Brian perfected his top-secret method of forming the paper/paraffin shell (actually, I don’t know if it’s top-secret, but I don’t want to inadvertently give away any trade secrets). So if today’s entry seems like one really long advertisement, you’ll have to forgive me. For as crazy as things got at times, I was glad to be a part of the design process for the new site, and I’m very proud of my brother and the artisan spirit he brings to his candle making. I worked very hard on the site, but Brian has worked a lot harder for years to create this business out of nothing, and I just wanted to take the time to acknowledge that.

color schemes
   rss feed: