Posts Tagged ‘themejam’

How I Won a Free iPad!

by Brian Casel  ·  5.17.2010  ·  Bits

My shipment of my shiny new 64 Gig 3G model iPad finally arrived this weekend.  It’s awesome.  Like, really awesome.  But I’ll get to my in-depth review in a later post.  Today, I’d like to share the back-story of how I won this beautiful device for free : )

A very special thank you goes out to Mojo Themes.  They are a new themes and templates marketplace where designers/developers can upload and sell their digital products.  Mojo launched around the same time that I launched ThemeJam.  As part of their launch, they held the March Padness contest, where they gave away iPads to 3 designers who uploaded the most products to their new marketplace.

You may (or may not) remember that when I first launched ThemeJam, I wasn’t selling only WordPress themes.  I was also offering matching HTML and Email templates as lower priced or packaged alternatives.  While offering “themes across multiple platforms” helped to create a unique selling point for ThemeJam, these byproducts weren’t selling nearly as much as the WordPress themes.  To a certain extent, I expected this would be the case.

Read more

Tracking Sales vs. Creating Sales

by Brian Casel  ·  5.10.2010  ·  Business

As a first-timer when it comes to running a product-based business (ThemeJam), I’m doing my fair share of experimenting and learning on the job.  A lot of that is in the marketing/advertising/tracking department.

I’ve got all the basics down, like running Google Analytics, setting up “Goals”, advertising with Adwords and tracking conversions.  E-Junkie (the shopping cart/downloads service that I use) offers a few more guidelines for properly tracking conversions, which I’ve implemented.  All of this tracking, analyzing, tweaking, and optimizing really takes a lot of time and focused energy to get the most the out of it.

But the truth of the matter is that I’m not all that interested in it.  I don’t particularly enjoy combing over the numbers, referring sites, keyword performance metrics, and whatnot.  It’s one of those things that once you open it up, you get sucked into and before you know it you’ve spent your entire morning on it when you could have been getting much more productive work done.

I personally believe the best tactic for increasing sales is to focus that analyzing, tweaking, optimizing, perfecting on your products and not your stats.  There are always ways to improve your product.  Maybe it’s adding a new feature or removing an unnecessary one.  Maybe it’s improving your documentation or fixing bugs.  Perhaps it’s time to design a new release for your product line.  These are ways of being truly productive, and they’re all things I really enjoy doing.  I don’t care (and often don’t even notice) the amount of time I spend on these tasks.

Now that I’m 3 months in on ThemeJam, I can look back and assess a very clear picture:  The first 1-2 months had relatively low sales, and I believe it’s because I spent too much time stressing over keyword tracking and traffic analysis.  In April I took a “set it and forget it” approach and saw a significant increase in revenue.  I also worked the hardest in April, churning out new themes, improving the others, and offering support.

I must note that I don’t completely ignore the stats or ways to improve my site’s performance.  I do check in on my analytics roughly once per week for about 30 minutes.  This amount of time commitment allows me to keep my finger on the pulse, notice any red flags, and make minor improvements over time.  It also gives me the freedom to focus my efforts on the stuff I really want to be doing:  Designing, coding, and serving customers.

It’s all about striking a balance that works for you and allows you to do your job with as much enjoyment as possible.  That’s the real recipe for a successful business.

How do you strike the balance between production work and promotion/analysis?

Launching a Commercial WordPress Theme

by Brian Casel  ·  4.21.2010  ·  Business, Education

This is the third and final part of my mini-series detailing my WordPress theme development process, which includes:

  1. WordPress Theme Design Process
  2. WordPress Theme Development Process
  3. Releasing the WordPress theme on ThemeJam.com (read on…)

So the theme has been fully tested (and tested, and tested again) and is now deemed ready for release into the wild.  Here is my process for prepping, releasing, and promoting a commercial WordPress theme on ThemeJam.

Prepare the Theme Demo

The functional demo should already be up and running at this point, because I created it during development.  Of course, there weren’t any links pointing to it yet, so it hasn’t actually been set “live” yet.

But I haven’t set up the iframed demo for this theme yet.  What I’m referring to is setting up the theme switcher navigation bar across the top of all the demos on ThemeJam.  This allows easy switching between themes, switching between stylesheets for each theme, and links to purchase.

Setting up the iframe is pretty simple.  It’s just a matter of duplicating a folder, changing some values and path names, and we’re all set.  Though we’re still not live at this point…

Write Theme Documentation

This is a super-important step.  As I mentioned in my reflections on ThemeJam two months in, I believe that thorough documentation is the best method of pre-emptive customer support (if you will).  I try and go above and beyond and provide as much detail as possible in my instructions and explanations.

Currently, the theme documentation is created as a PDF document.  I plan to overhaul and create a web-based version of theme docs, hopefully in the coming months.

I should also mention that I include quite detailed instructions and notes throughout the theme options panel built into the theme.  Every option has it’s own sentence or two describing what it does.

Prepare the Download Package, Upload to E-Junkie

As you may know, all ThemeJam themes come packaged with the layered Photoshop design files (PSDs).  We don’t have separate “developer” packages as most theme companies do.  Every package would be considered the “developer” package.  Before zipping the theme, I go through all the PSDs and tidy up the layers and groups.

Once the zip package is all set, I create the product in E-Junkie, which is the service I use for issuing downloads and handling the checkout process.  I set it up so that affiliates can easily link directly to the product and earn money promoting ThemeJam products.

Push live on ThemeJam.com

This step involves several things:

  • Cutting screenshots and thumbnail images for the home page, gallery page, and detail page.
  • Writing copy to describe the theme on the detail page.
  • Input the various pieces of info (copy, price, demo link, purchase link, callouts, etc.) in WordPress (I set this up using quite a few custom write panels).
  • Add the theme image and link on the ThemeJam home page carousel.

Notes on Promotion

Here are a few things I do to build awareness of the new theme, both before and after pushing it live:

  • Release teaser images showing screenshots of an upcoming design.  I do this while I’m in the design phase to build awareness of what’s coming up next, and ask for feedback.  If I were a dribbble member, I’d do this much more often.  Anyone have an invite for me? :)
  • Blog about it. I always post about it on the themejam blog, and I plan to blog in a lot more detail here on briancasel.com for upcoming themes.
  • Videos. I’ve been using screenr to create quick screencast videos showing how the back-end functionality works.

And that concludes my series on how I go about creating and releasing a commercial WordPress theme.  Please share any feedback and/or questions in the comments below and if you haven’t already, check out the current selection of WordPress themes at ThemeJam.com.

Secretly Awesome Custom Service

by Brian Casel  ·  4.19.2010  ·  Business

When it comes to customer support for premium WordPress themes and plugins (and many other web-based products), there seems to be a pretty standard set of policies shared by most companies:

  • No telephone support.
  • Little if any direct email support.
  • Forums are the primary method of support, sometimes restricted to paid customers.
  • Specified hours for support forum responses (usually weekdays only).
  • No support for customizations / modifications to their product.
  • No guaranteed compatibility / support for other 3rd party software.
  • No support for free products.

There are valid and obvious reasons behind these policies.  A heavily promoted and popular site will never be able to handle the volume and deploy the resources necessary to offer phone support, free customizations, and other things on this list.

It’s important to spell out these policies clearly on your website so that customers don’t get the wrong idea.  They must know what the limitations are going in.  Otherwise, you risk making your customers angry and frustrated when they feel they’re not getting what they paid for.

You also don’t want to offer everything on day 1, then slowly cut out those benefits as your customer-base grows.  This will only turn off those customers who were with you from the start, who are likely the best promoters of your product/service.

Unofficially Awesome Customer Support

All of that being said… I still offer most if not all of the things on that list.  I just don’t make it known on the policy pages of ThemeJam.com.  I don’t guarantee these “extras”.  But I do offer them to those that inquire.

I respond to every email I receive through ThemeJam.  That has included:

  • Answering pre-sales questions, sometimes lasting up to a week of back and forth and not resulting in a sale.
  • Lengthy customer support for users of the free Gadget theme (which officially doesn’t come with support).
  • Help with theme installation and general WordPress questions.
  • Customer support for paid themes, despite the fact we have a dedicated forum for this.

Why?

I just can’t help myself :)

No, really.  Why not?  These extra support requests are opportunities to develop real relationships with potential customers.  If the customer comes away with a surprisingly positive experience, it increases the chances of them recommending ThemeJam products to their network (either through blogging, twitter, or simple word of mouth).

As I’ve said in the past, the key to success is to build a strong network of referrals.  In that post, I was talking about freelancing.  But it’s the same thing when building a customer-base for your products.  I’d say my biggest marketing goal for ThemeJam would be to boost word-of-mouth sales.  This is probably something I won’t be able to accurately measure, but still well-worth the effort.

Once again, I’m capitalizing on the fact that I’m still a small guy in a crowded marketplace.  The fact that my customer-base is still relatively small means I have the time and resources available to provide exceptional customer support that exceeds expectations and goes above and beyond what most companies offer.  This comes back to the idea that scaling your business can work both ways.

Over to you

Your thoughts?  I’m interested to hear about your experiences – positive and negative – dealing with customer support for online products.

WordPress Theme Development Process

by Brian Casel  ·  4.13.2010  ·  Education, Opinion

In the first part of this series about my WordPress theme design process, I covered how I go about the concept and design phase.

This post covers my process for developing a WordPress theme.  That is, after the PSD mockup is complete, this is how I go about coding and preparing to release it as commercial theme on ThemeJam.

NOTE: This is not meant to be a tutorial, but rather me sharing my personal style and process.  I mention many technical aspects of web development here.  If you’re unclear or interested in more detail on anything discussed here, let me know in the comments and maybe I’ll post an in-depth post about it!

First, the markup.

Panic Coda has been my coding application of choice for the past 2 years or so.  A few months back I gave MacRabbit Espresso a try, but it didn’t stick with me.  Coda has everything I need:  A clean interface, user-defined keyboard shortcuts & snippets, and a built-in seamless FTP client.

I start by coding the main templates in valid XHTML and CSS.  I’ve never been one to use a CSS framework or pre-built template created by others (like the 960.gs).  I prefer to make every line of code my own to ensure that every bit is optimized for this particular theme, with nothing leftover that I don’t need.

That said, I have crafted my own “new theme” template, or set of files/folders if you will.  I’ve been tweaking and improving this set of templates over time.  It to speed up the process at the very beginning by covering all the items that I always put in every theme.  My starter template consists of:

  • Index.html – blank-slate HTML doc, including the doc type, basic HTML page structure, and a call to the stylesheet.
  • reset.css – Created by Eric Meyer, with a few of my own tweaks.  I haven’t always used this in the past, but recently I do.  It’s good for making things consistent across all browsers from the very beginning.
  • style.css – This has all of the basic elements of a typical WordPress theme stylesheet, including the theme info declaration at the top.  It includes the clearfix method, basic styles and margins set on the common elements like P, H1-h6, UL, OL, etc.  It also has a few WordPress-specific styles that I know I’ll need later such as some basic comments styles, .alignleft, .alignright, .aligncenter, blockquote, and a few other things.
  • Scripts folder – I always include jQuery here.  I realize that WordPress has jQuery built in, but I’m first starting with the static HTML templates, so I’ll need my own copy of it.  I also have the jQuery cycle script here because I use it so often.

With my starter template fired up in Coda, and my finished mockup open in Photoshop, I get to work on slicing and coding up the static HTML template.  My goal here is to get as much of the site structure and details coded as I can.  The things I want to have coded at this stage are:

  • Overall structure and layout.
  • Typography, including implementation of Cufon (my choice for font-replacement in commercial themes.  For other sites, I go with TypeKit).
  • jQuery enhancements.  This includes dropdown menus, featured posts sliders (though I use static content for now), etc.
  • Widget styling.  Again, using static content now, but styling the markup to be used later in WordPress.

Most of the time, I’ll do a home page (index.html) and generic interior page (page.html).  Sometimes I’ll create an additional blog page if blog posts will have a unique layout or something.  Usually in website development I would implement a system of includes, like a global header and footer.  However, since WordPress will have it’s own include/template system, I don’t bother creating includes for the static HTML templates.

Browser Testing & Validation

When it comes to browser testing, I always say test early and test often.  Some folks don’t even look at IE until they’re done coding everything.  This is a bad idea, because more often than not, IE requires you to re-think your (perfectly logical) code and you’ll end up wasting time to go back and re-code.

I prefer to test all browsers as I go along, especially as each major piece is implemented.  For example, I’ll get my featured posts slider working perfectly across all browsers before moving onto the rest of the site.

To finish off the static HTML phase, I put my pages through the W3C validator until that refreshing green light appears.

Alternate Colors

Most of the time I implement alternate color stylesheets after doing the static HTML templates, but before integrating WordPress.  I do this so that I can release the static HTML templates as their own product, with multiple color options built in.

The way I do this is simply by creating additional stylesheets, which override specific styles and colors found in the main stylesheet.  Basically, I commit the main stylesheet to being the “default” color scheme, and use additional stylesheets for the other options.  I take very special care in picking alternate colors.  Sometimes I’ll go so far as to pick and implement a color scheme, only to trash it later because I feel it’s not good enough for release.

Time to integrate WordPress

Finally, the real fun begins…

I create a fresh installation of the latest version of WordPress within the ThemeJam demo section (this particular demo is not live yet).  Then I import some basic blog content.  WPCandy has a great “test content” import file you can download and use to quickly fire up a new demo site.  I have created my own version of this, which I think works better to showcase my themes on ThemeJam.

Then I begin creating the theme.  For this, I have created my own personal starter template, which I have named “FrameJam” (Framework + ThemeJam, get it?).  It’s not meant to be a WordPress Framework in the common sense of the word.  Really just a starting point for my own personal use.  Included are a few things I like to have across all my themes:

  • The ThemeJam Options panel – with basic options included.  I’ll add more options specific to this theme a bit later.
  • Various SEO markup and template tag enhancements.
  • Some PHP functions I always use – like images and thumbnail handling, registering widgets, a custom widget template, custom comments markup, custom excerpts, etc.

I duplicate FrameJam and rename it to the new theme name.  Then I overwrite the entire style.css file with the one I created earlier for the static HTML templates.  Now we have basic styling, but the markup isn’t together yet.

I go line-by-line integrating WordPress tags and functions with the markup I already created earlier.  It’s just a matter of pasting chunks of markup from the static HTML templates into the WordPress templates.  I start this process by setting up header.php, index.php, and footer.php as these 3 templates will basically create a full page from top to bottom.  Then I’ll fill in the rest of the template files.

Now is a good time to re-test everything across all browsers.

The last phase of WordPress integration is to implement all of the theme options.  This adds an additional layer of template tweaks, turning static things into variables, adding inputs and sets of inputs to the Theme Options page, and whatnot.

Then of course, there is testing, testing, and more testing.  TIP: Test at night, but test again in the morning when you’ve had a good nights sleep.  You’d be surprised how many things you miss when you’re bleary eyed.  There are so many little things that go into a WordPress theme, it can take a whole week just to tie up all the loose ends.

That wraps up the wordpress development phase.  If you have any questions for me, or if you have a different approach you’d like to share, please leave your thoughts in the comments.

Next up…

In the final post in this series, I’ll cover how I go about preparing my finished theme for release on ThemeJam.  Stay tuned…

Page 1 of 3123