Zazzle Blog

Trudging Across The Tundra

Sometimes, you have to take a step back and look at where you are before you are able to move forward in any reasonable way. When you have your head down, trudging across the tundra, mile after mile, you forget to look up every so often to see if you are moving in the right direction. Well, we just looked up. And we noticed that there were many places we could optimize in our code…from CSS to HTML to JavaScript.

In this latest incarnation of the Zazzle website, there are more behind the scenes changes than there are…well, things that there are a lot of. We took the time to essentially restructure our pages for performance and scalability, by doing a few simple things: organize page elements to load in a specific order, remove huge chunks of now redundant CSS, and implement a new design that allows us to use less images and HTML.

If You Build It Right, It Will Come Faster

Our first task was to take a look at the overall structure of our pages. This includes everything from what’s in the HEAD section, to where we load in our JavaScript. The important thing to note about this is that by structuring our pages in a consistent way throughout our site, we could now make better decisions about what external files need to be loaded, and where. This also allowed us to make the decision to load most, if not all, of our JavaScript at the very bottom of every document.

So what, you ask? In our old site, we would load in a default CSS file for all pages, and if anything on that page needed special stylings, we would override them with styles from another file specific to that page. Ok, makes sense. And we still actually do that.

But the big difference is that now that the pages are structured in a consistent manner, it’s a lot easier to NOT have to do an override of an override of an override to achieve a particular look since we are only loading in the CSS files that are needed. There were many cases before where we had many CSS files loaded for a page, each performing overrides.

On top of that, the CSS itself has been optimized in many places, mostly due to the simplified HTML markup that makes up the page. Simpler markup means simpler CSS…which leads to much less code. How much less? We estimate that there is approximately 50% LESS CSS than before, and with a much cleaner user interface. Win-win baby!

Loading JavaScript at the bottom of each page also serves two purposes. One, the page HTML loads and displays to the user while downloading instead of waiting for JavaScript to download. Second, it allows us to easily “wire up” scripted elements on the page once the page is complete. The advantage there is that at this point we are certain all elements exist and the JavaScript can run unfettered.

Rounded Corners Are So 2003

There are some things HTML/CSS just doesn’t do well. Rounded corners are one of those things. Our old design used many rounded corners all over the place, which caused us to create something we called a “zBox”. What is a zBox? It’s basically a bunch of HTML and CSS that would render a box container with rounded corners. We made it so easy for us to use that whenever we needed to add a new container to our page, we’d simply call our zBox component.

The only problem was that a zBox contained a significant amount of HTML and CSS, not to mention images that needed to be loaded for the corners. It was not unheard of to have a page with half a dozen or more zBoxes.

With our redesign, we decided to simplify…not only the code, but the entire look of the site. This meant getting rid of the ubiquitous zBox. By simply replacing zBoxes with single DIV containers, we were able to remove huge amounts of markup and images, making each page that much lighter to load.

Here’s an example piece of code for a zBox:

<div class=”zBox” id=”divId”>
<div class=”zBoxTop”>
<div class=”zBoxTopDiv1″></div>
<div class=”zBoxTopDiv2″></div>
</div>
<div class=”zBoxMiddle”>
<div class=”zBoxContentWrapper”>
<div class=”zBoxContent clearfix” id=”innerDivId”>
##content##
</div>
</div>
<div class=”zBoxContentDiv1″></div>
<div class=”zBoxContentDiv2″></div>
</div>
<div class=”zBoxBottom”>
<div class=”zBoxBottomDiv1″></div>
<div class=”zBoxBottomDiv2″></div>
</div>
</div>

And here’s that same container without using zBox:

<div class=”myClass“ id=”divId”>
##content##
</div>

And that’s not even including the CSS and images that are needed! So needless to say, with our new simplified design, we were able to cut tons of unneeded code from the site. It’s like Zazzle went on a diet and looks great!

Even The Skin is Low Fat

With our svelte new design and our consistent page structure, we are now able to provide room for future growth. And where do growths usually occur? Well, on the skin, of course! Yes, gross analogy aside, we will be able to offer the ability to skin parts of our site!

We already provide themes for contributors to skin their entire galleries. This helps contributors create a brand and experience tied to their art and designs. The steps we’re taking with our website technology move towards deep level customizations. Imagine being able to skin the gallery with even more control (like custom CSS!) – just like we’ve started to on Zazzle. The possibilities will be endless!

When we started our LicensePlateShirts gallery on Zazzle, we actually used the Zazzle API to create an external website where customers could choose a state, then type whatever text they want to appear on that state’s license plate. They would then click over to Zazzle’s design tool with the license plate and custom text already loaded. (See http://www.license-plate-shirts.com/)

This approach works well, but contains a few drawbacks. First, there is a huge time commitment in designing and coding up a website. Even if you already have a website, you’ll need to write some code to add your products. Also, once the user lands on Zazzle, they are dealing with a single product design, and how to change to a different design (another license plate, for example) is not obvious.

Show Me the Buffet
So how do we make it easier for both contributors and customers? For contributors, we need to remove the difficult barrier of writing web code. And customers need to be able to customize an entire buffet of products at once, without jumping through hoops.

Enter project “Template Buffet”…the internal code name for this new feature. Here’s how it works:

1. A contributor creates a set of template products (see documentation)

2. The contributor creates a new gallery product line and publishes these template products in that category.

3. From the Create-a-Product API page, the contributor selects to create a category link. In three easy steps, the contributor generates a web address to this product line. (Visit LicensePlateShirt’s category link)

4. Navigating to this address takes customers to a simple page that shows all the products, and allows easy customization.

No programming needed by the contributor, and no back and forth by the customer to get the right design on the right product. Dinner is served.

Overheard in a Zazzle internal email thread about new button objects. Had to share…

Annette: What's a better unambiguous name for z2 Buttons?

Ed: How about HTMLButton (since that's really all it is)

Chris: How about ButtonButton, since it uses a BUTTON tag?

Ben: How about BenButton since I'm so vain?

Annette: BenButton.GetLint()

Ben: That would return Lint.Empty  

Rich: if (aBenButton.GetLint() != Lint.Empty)

          throw up;

Ben:if (aBenButton.GetLint() != Lint.Empty) {

          aBenButton.NeedsToBathe = true;

          throw up;

        }

Cool and easy…that perfectly describes a new feature we would like you to check out in our latest SNEAK PEEK!. We call it “maize”…oops, sorry, we call it “EZ Templates”.

“EZ Templates? Why, that sounds like fun!”

Why yes, it is, Bobby! Here’s a scenario: You are browsing through Zazzle and find that perfect greeting card you want to get for your little sister’s birthday, if only the image on the front was a cat instead of a dog. And also, you want to add her name to the card.

Luckily, the card is a template that allows you to change these things directly from its’ product page on Zazzle! You don’t need to load up our design tool and fiddle with the overall layout anymore…all you have to do is click the “change image” button on the product page to choose your own image, and fill out a simple text field to totally personalize this card! Add it to your cart and voila! One perfect birthday card, no muss, no fuss! Plus, you get to say “voila” and sound all smart.

This feature makes it simple for customers of your products to personalize and buy on the spot, without having to use our more advanced design tool. This means more sales, and more sales means…well…you…sell more of your stuff. Yup. Stuff sellin’. That’s what it’s all about. Mmm hmm.

Just look at the screenshot below to get an idea of how it all works. Oh, and by the way, EZ stands for Eat Zucchinis. Long story.

Read more and discuss this new feature in our forums!

This is a very cool implementation of our creation API! Says-It.com let’s you choose from various people, backgrounds, etc, and add your own pearls of wisdom.

Then choose from a list of Zazzle products, like mousepads, t-shirts, mugs, keychains and more. Easy…breezy…beautiful!

For more info on our creation API, check my previous post.

Howdy Zazzle tech geeks! I know it’s been a while since we’ve posted on the tech blog, but you know how it is when we have a major release to work on (can anyone say new print design tool?)

Well, I just thought I’d chime in quickly here and remind some of you about our cool API tools. With these tools, you can create links from your own websites to customized versions of your own products. So, for example, you can create a template of a greeting card, with a nice border, frilly graphics, and cute accents, and someone can come to YOUR website and enter some text (or an image), and voila! They will be taken to the greeting card design with their info filled in! YAY!

Think of the possibilities, my friends.  Check out our API documentation and start thinking way outside the box!

[CUE MUSIC CRESCENDO]

Narrator: Firefox vs. IE. It’s Browser Wars 2.0….this time it’s personal.

[PAUSE]

Narrator: Well…OK, maybe not “personal” per se, but it’s at least a little heated. Isn’t it? No? Fine.

[CUE MUSIC CRESCENDO]

Narrator: Firefox vs. IE. It’s Browser Wars 2.0. This time it’s EASIER! Yes, if you are a developer, it seems like there is a lot less browser sniffing going on. That’s the good news. The bad news is…

[MUSICAL CLIMAX]

The two big browsers are still not totally compatible. There are times when the exact same CSS renders differently between browsers. What’s a developer to do? Simple. There is a quirk that Internet Explorer has that helps us make conditional CSS declarations within the style sheet itself. It’s the “underscore hack”.

IE apparently reads a style declaration with an underscore normally, where Firefox ignores them. For example:

.myClass {
     width:100px;
     _width:105px;
}

In the above example, the width of class myClass is set to 100 pixels for Firefox, and 105 pixels for IE. Neat, huh? IE reads both declarations, but since the one with the underscore is last, that’s the one that takes. It treats “width” and “_width” as the same thing.

Firefox ignores the declaration with the underscore because technically “_width” is an invalid CSS construct. So it uses the first one…100 pixels.

So this way we can have little IE overrides inside CSS files without having to use complex browser sniffing code.

[CUE APPLAUSE]
[CUE END TITLE AND CREDITS]
[FADE TO BLACK]