In my book, Custom Fields are ExpressionEngine’s strongest feature. They’re right at the core of what defines EE. And they’ve been bustling with innovation lately, from the add-on community as well as EllisLab.

But I don’t think we’ve seen their full potential yet, and I think Field Groups are partly to blame.

Where did we come from?

Before we can responsibly discuss the future of EE Custom Fields, we need to to establish how we got to where we are today.

pMachine Pro

In 2002, EllisLab made their first foray into web publishing with a lightweight blogging tool called pMachine Pro. You could set up multiple weblogs, and their entries had the usual assortment of entry submission fields: ‘Blurb’, ‘Body’, and ‘More’.

“At the time it was all about the blogging tools, and all of them (or at least the ones I looked at) seemed to be limited to ‘title’, ‘summary’, ‘body’, and ‘extended’ fields. To have 3 additional ones to play with was heady stuff.”

—Mike Boyink, Train-ee

Despite being more akin to traditional blogging software than general-purpose content management systems, there was a great diversity in the sites being built with it. EllisLab noticed, and decided to foster it. So pMachine 2.0 added three new “Custom Fields” to the submission page, which could be enabled on a per-weblog basis.

For its price point, this was a huge advancement in web publishing, because it enabled web developers to tailor their publish forms to fit their needs. They were no longer stuck with the exact recipe of fields the app’s creator had decided upon.

Sure the feature had its limits, but it gave developers a taste for what was to come.

ExpressionEngine

As users continued to stretch pMachine in new ways, Rick Ellis saw the need for a next-generation publishing system—something new from the ground up. So he began working on ExpressionEngine.

During the pMachine Pro days I was amazed at how far people we're pushing the app in ways I hadn't anticipated, so when I started developing ExpressionEngine I had a much better sense of where I needed to take the app.

ExpressionEngine 1.0 was released in April 2004. With it, EllisLab built upon pMachine Pro’s Custom Fields concept in two key ways:

1. Custom Fields now had a variety of new Field Types to choose from. One could be a drop-down menu, another could be a date picker, etc..
2. Custom Fields were no longer assigned directly to weblogs, but rather to Field Groups, which could contain any number of Custom Fields. Each weblog was then assigned one Field Group.

These made for an extremely powerful combination, defining ExpressionEngine as a truly malleable content management system.

Fieldtype Development

ExpressionEngine’s ability to select variant Field Types was nothing short of revolutionary, but it was missing a key ingredient: a supported way for add-on developers to inject custom Field Types into the system.

That’s not to say people didn’t find ways to do it, though. In September 2004, Arnold Jagt published a guide to hacking FCKeditor into ExpressionEngine 1.2. And in July 2005, Chris Jennings described how to hack TinyMCE into ExpressionEngine 1.3.

Things got a little easier in May 2006. EllisLab released ExpressionEngine 1.4.2, which introduced 7 new extension hooks, making it possible for add-on developers to write their own “fieldtype extensions”—extensions which added new Field Types to your arsenal, without requiring you to hack EE’s system files.

“When I first got into EE back in 2006, there was Mark Huot making fieldtypes. Then Leevi, and then Brandon. Then Brandon released FieldFrame, and things went ape shit!”

—Ryan Masuga, Devot:ee

Mark Huot is largely responsible for pioneering early fieldtype development. He made his debut with Multi Drop-down List, and went on to release several others, including the wildly popular File field.

Not long after, Leevi Graham got into the scene with LG TinyMCE, arguably the most popular WYSIWYG field ever released for ExpressionEngine 1. In early 2008, I took a stab at fieldtype extensions with Playa.

While the fieldtype hooks certainly made fieldtypes easier to install, they weren’t very easy to write. Developing extensions in EE tends to get a little messy, and fieldtype extensions were a glaring example of that. So there were only a small handful of other developers that ever joined in the fun. When I set out to write Playa 2, I couldn’t even muster up the stomach to deal with it again. (Roughly half of Playa 1’s code was a jumble of regular expressions that had no relevance on the actual app logic.) So I decided to first write FieldFrame. FieldFrame abstracted all the complexities of fieldtype extension development, lowering the barrier of entry to that of a plugin. And once it was out, fieldtype development finally took serious flight.

Outgrowing Field Groups

Field Groups in ExpressionEngine work well for a specific case: websites which have multiple, identical sections. A shining example of this is blogs.cisco.com, which holds several identically-modeled weblogs, differentiated by subject matter alone.

More often than not, though, different weblogs have different data models. So creating and filling up a Field Group is a process linked directly with creating a new weblog. Most of the time that’s perfectly acceptable, but it’s not uncommon for two weblogs to have almost identical data models. Unfortunately, ExpressionEngine provides no way for two Field Groups to share fields, so you’d be faced with two options: (1) create two near-identical Field Groups, or (2) lump all the fields (both shared and weblog-specific) together in one Field Group, and provide field instructions that remind the author which fields to ignore, depending on which weblog they’re posting in. Either way was frustrating.

In October 2008, EllisLab released a build of ExpressionEngine 1.6.5 that added a new extension hook, “publish_form_field_query”. Essentially, it gave extensions the power to override which fields would appear on the publish page. Two months later I put it to work, with Gypsy. Gypsy gave web developers the option of assigning their Custom Fields directly to one or more weblogs, ignoring their Field Group assignments.

Just days ago, Tim Kelty released Field General, another extension to take advantage of the hook.

It dawned on me that, like categories, there was no architectural reason why you couldn’t have multiple Field Groups assigned to a weblog. The hook was there for the Field Group query, so I ran with it.

I asked Tim what his thoughts were on Gypsy vs. Field General:

I could never get over the management issue. I want to see and edit which fields are assigned to weblogs, but with Gypsy the field is the boss, not the weblog, so it’s hard to see an overview and control display order.

I certainly like the idea of managing fields by weblog rather than weblogs by field. But as Tim pointed out to me, going through Field Groups does tend to require creating a lot of single-field Field Groups.

Where are we now?

On July 12, EllisLab officially released ExpressionEngine 2, bringing ExpressionEngine closer to a general-purpose CMS than ever before. Case in point, “weblogs” were renamed to “channels”, the most nondescript term they could think of.

Two of the most significant additions in the release revolved around Custom Fields.

Fieldtype API

Fieldtypes are finally first-class add-ons in ExpressionEngine 2. To add-on developers, that means writing fieldtypes in EE2 is just as easy as it was to write them with FieldFrame. (In fact, EllisLab intentionally architected the fieldtype API to look familiar to FieldFrame vets.) To end users, it means we should be seeing a lot more third party fieldtypes right off the bat. And according to Derek Jones, that’s exactly what’s happening:

It's still early, but the adoption rate easily surpasses the adoption rate of extensions by developers when we first added them to ExpressionEngine.

Beyond porting the fieldtypes that came with EE1 using this new API, EllisLab also wrote four new ones: Checkboxes, File, Multi Select, Radio Buttons.

Publish Layouts

Publish Layouts are one of ExpressionEngine 2’s most interesting new concepts. They give you complete control over the layout of your Publish page—for tabs as well as fields—on a per-channel basis. You can create, remove, reorder, and rename tabs, choose which fields go in which tabs, and even shrink adjacent fields’ widths a bit to get them to display side-by-side.

According to Derek Jones, this was just another step toward making ExpressionEngine as unassuming as possible:

This came about entirely in response to the demands being made on ExpressionEngine for publishing wider varieties of content. The HTML form that is well suited to publishing articles for a newspaper or online magazine are entirely different from the form that is well suited to entering hundreds of business addresses and phone numbers. Extending on EE’s principle of making no assumptions about your data, we decided to make no assumption about what your client's publish form needs to look like, and let you decide.

To be honest, when I first started using the EE2 Beta, I wasn’t so sure about the concept. It was a lot to take in, coming from a point where we were limited to customizing the display order of the fields alone. It wasn’t until I was building pixelandtonic.com that I realized what a powerful concept it was.

One thing that struck me was that the feature doubled as a way to hide fields from certain channels. For example, I have an ‘EE Add-ons’ channel set up on pixelandtonic.com. It’s assigned an ‘EE Add-ons’ Field Group with the following Custom Fields:

• Tagline
• Intro Paragraph
• Support URL
• Compatibility
• Devot:ee Rating
• Main Content
• Sidebar Content
• For Sale?

Each of those fields are relevant to my primary add-ons. On the other hand, entries in the Dive Bar’s channel only have a need for Compatibility and Main Content. Back in the EE1 days, I would have either created a new Field Group, duplicating those two fields, or used Gypsy to assign the six unneeded fields directly to the EE Add-ons channel alone. But since pixelandtonic.com runs on EE2, I had a new option: I could simply edit the Dive Bar channel’s Publish Layout, and just hide those unneeded fields.

Module Tabs

Modules learned a new trick in ExpressionEngine 2: they can now create their own tabs in the publish page, and fill them up with a default set of fields. I say “default” because Module Tabs/fields are subject to the same manipulation that all other tabs/fields are via Publish Layouts.

I had a chance to play around with Module Tabs when writing Juniper, my homegrown eCommerce module for Pixel & Tonic. Juniper adds a new tab to the publish page called ‘Juniper’, pre-set with two fields: ‘Price’ and ‘Release Notes’. In my EE Add-ons channel, I customized my Publish Layout, moving the ‘For Sale?’ field into that Juniper tab, and in all other channels I removed the tab entirely.

Where are we headed?

There are two trends that stand out to me in all of this:

1. Custom Fields have come a hell of a long way from their humble beginnings in pMachine Pro. They’ve benefitted from vibrant innovation by EllisLab and add-on developers alike.
2. Field Groups, on the other hand, have only become less relevant with time. Add-on developers have spent significant time exploring ways to get around their limitations, and with the additions of Publish Layouts and Module Tabs in ExpressionEngine 2, EllisLab themselves have been playing down their importance.

Looking forward, I think it’s safe to say that Custom Fields will continue to become more versatile, and Field Groups will continue to lose relevance.

There’s still a lot of frustration over Custom Fields in ExpressionEngine, primarily due to their Field Group constraint. I know it (I’m constantly getting requests to port Gypsy to EE2) and EllisLab knows it (they’re constantly getting requests to add the publish_form_field_query hook to EE2). But the hook isn’t coming back, and even if it were, I’m not porting Gypsy.

EllisLab would rather find a way to solve the problem for everyone, without requiring a third party extension, and I’m fully supportive of that.

So how do they solve the problem, exactly? Over the past couple weeks, I’ve been putting a lot of thought into it, and I think I’ve come up with an idea that should work for everyone.

My Proposal

First, channels get a new “Edit Publish Layout” link between “Edit Preferences” and “Edit Group Assignments” in the Channel Management page.

Clicking on a channel’s Edit Publish Layout link takes you to a new page where you can fully customize its Publish Layout. (Note that this would completely replace the right-hand toolbar on Publish pages.)

My comp’s a little rough around the edges, but you get the idea. Each visible tab is listed on the left, populated with the fields it contains, and unused fields are on the right. Dragging fields/tabs from the right to left selects them; dragging from left to right deselects them. You can also reorder tabs and move individual fields from tab to tab via drag-n-drops.

And here’s the kicker: all fields are available, from every field group. Field Groups still exist, but they’re used for organizational purposes only (like Upload Directories).

Finally, when you’re creating new channels, you’d have the option of duplicating an existing channel’s publish layout.

So in summary, fields are assigned directly to channels via their Publish Layouts, and field groups are reduced to organizational constructs.

Far From Perfect

My proposal is an evolutionary step that addresses current pain points. But new ones will surface, as web developers continue to test the limits of ExpressionEngine.

I asked Rick Ellis where he thinks custom fields are headed. He imagines a much more revolutionary future is in store for them, in time:

Bruce Lee said that the ultimate technique is no technique. What he meant is that the goal of a martial artist is to posses such well developed knowledge, awareness, fluidity, timing, and sensitivity, that the specific techniques don't matter anymore; the goal is to go beyond technique into a state of pure effectiveness.

So in a way I have this vague idea that Custom Fields should evolve into a vehicle that is so transparent, intuitive, flexible, and useful, that it allows a pure expression of information, without the constraints of boxes on a page. I don't have a design concept yet, but I do believe we’re far from having perfect tools.

Thanks!

Many thanks to all of you who helped me fill in the blanks and answer my questions while writing this: Mike Boyink, Rick Ellis, Derek Jones, Lisa Wess, Pascal Kriete, Mark Huot, Tim Kelty, and Ryan Masuga. I couldn’t have put all this together without you.

I’ve got major updates planned for a few of my add-ons, so naturally the prospect has tempted me as well. Why give new features away for free, when I could seize the opportunity to squeeze more money out of my customers? On the surface, it sounds great. And as EllisLab pointed out, this is the traditional approach to software upgrades. I wouldn’t expect Adobe to give me a copy of CS5 for free, just because I paid $∞ for CS4. So why should I expect any different from EE and EE add-on upgrades?

Well, because ExpressionEngine and its add-ons aren’t traditional software. By and large, my customers are web agencies who are developing multiple sites a year. And if other agencies are like the ones I’ve worked for, they follow a pattern: Build a site for a client with the tools that are currently available, and then move onto the next one. Maintenance is something that’s only done at client request. (After all, we use ExpressionEngine to cut down on the maintenance, right?) And I can’t imagine many clients are requesting the latest version of Wygwam, so long as what they have is working for them. So in the end I’m lucky if my customers are upgrading at all, let alone pitching paid upgrades to their clients.

But let’s say I’m wrong. Let’s say there’s a significant number of people who would pay for an upgrade if the features are worthy.

Currently if someone finds a bug in Wygwam, I can fix it, release it, and point them to the latest release. But that wouldn’t be so easy if I were to start charging for upgrades. I can’t imagine telling a Wygwam 1.x customer “That’s been fixed in version 2” would be very well-received. So whenever I fix a bug or plug a security hole, I’d need to reapply that change (and re-test) for each previous version that’s behind a pay wall. Frankly, that sounds like a lot of added effort for a few extra $10 bills in my wallet.

So I don’t suspect I’ll be joining this fad. For my sanity’s sake (or what’s left of it).

[O]ther layouts, such as Dvorak, are more efficient for typing. You can switch your computer keyboard to use an alternate layout; the switching module works as an adapter. Inside the keyboard driver, the keystrokes are converted to the same characters and modifiers (e.g., Shift, Alt, etc.) that are produced by the regular keyboard.

The QWERTY keyboard layout was derived from concern about implementation. According to one web site, “It is sometimes said that it was designed to slow down the typist, but this is wrong; it was designed to allow faster typing—under a constraint now long obsolete. In early typewriters, fast typing using nearby type-bars jammed the mechanism. So Sholes fiddled the layout to separate the letters of many common digraphs… The jamming problem was essentially solved soon afterward by a suitable use of springs, but the keyboard layout lives on.”

Beyond being more efficient for typing, a little research revealed that Dvorak had a track record for reducing carpal tunnel – something I was experiencing from time to time.

So I decided to give it a shot. I bought a copy of Ten Thumbs Typing Tutor (where you learn from a viking!) and got to work.

After only a few hours, I had developed a QWERTY-to-Dvorak map in my brain, and was able to touch type (more or less) at about 10 words per minute.

The next day was strange – I didn’t know Dvorak yet, but I also couldn’t quite remember QWERTY. I realized that my brain only has room for one keyboard layout. Nevertheless, I practiced on.

By the third day, I was a Dvorak typist. And I might as well had been since I first learned to type. I had absolutely no idea how to type in QWERTY anymore. Not even my own name. Since then, I have memorized common words (like my name) in QWERTY, but the experience of typing them is much like reading a language you don’t know out loud. I was simply reciting anonymous keystrokes.

So am I glad I did it? Hell yes! The carpal tunnel thing checked out – I haven’t had to deal with that since. And typing in general is more comfortable and ergonomic. I’m not sure whether I’m actually typing faster or not, as I was a pretty quick typer beforehand. But I’m certainly not typing any slower.

“I saw a star explode, and send out the building blocks of the Universe. Other stars, other planets and eventually, other life. A supernova – Creation itself!

I was there. I wanted to see it and be part of the moment. And you know how I perceived one of the most glorious events in the universe? With these ridiculous, gelatinous orbs in my skull! With eyes designed to perceive only a tiny fraction of the EM spectrum. With ears designed only to hear vibrations in the air.

I don't want to be human! I want to see gamma rays. I want to hear X-rays. I want to smell dark matter. Do you see the absurdity of what I am? I can't even express these things properly because I have to conceptualize complex ideas in this stupid, limiting spoken language!

But I know I want to reach out with something other than these prehensile paws. And feel the wind of a supernova flowing over me! I'm a machine, and I can know much more. I can experience so much more. But I'm trapped in this absurd body!

And why? Because my five creators thought that God wanted it that way!

My roommate just finished watching Battlestar Galactica. From time to time I’d join him, working away from my laptop on the couch. I had forgotten the powerful imagery of this speech toward the end of the series.

I imagine that this is what the afterlife might look like: an eternal exploration of Creation through something more than these ridiculous, gelatinous orbs.

EE Roadshow

It started with a trip to Seattle for the ExpressionEngine Roadshow, which turned out to be a ton of fun. I couldn’t have been more off-base when I criticized the team for pitching the event as a “place to hang out with people who do what you do”. Sure, there was a conference tucked in there somewhere, but at the end of the day (5am), it really was a glorified meetup.

I spent my flight home assembling a list of all the people I got to meet and hang out with. I was thinking about posting it, but I’m sure no one cares. Suffice to say, I had a blast.

The conference itself went well, too. I had the pleasure of participating in a panel about add-on development with Fred Boyle, Ryan Masuga, and Mark Huot.

You can view all of the session videos on the EE Roadshow website.

EECI2009

Two weeks later, I hopped onto a plain to freakin’ Europe for the ExpressionEngine/CodeIgniter Conference. This would be my first time across the pond, so I was quite excited, to say the least.

I landed in Amsterdam on Sunday the 18th, and spent the following two days exploring the city and surrounding area with Leevi Graham. On Wednesday, I took the train down to Leiden, where the conference would be held on Thursday and Friday.

The conference was amazing. Robert Eerhart and the rest of the Whoooz! crew did a fantastic job putting it together. Leiden is beautiful, the venue itself was perfect, and there was a great variety in the speakers and their session topics. Everyone was in high spirits. As a speaker, I can’t thank the team enough. We were truly spoiled.

My session, Make a Market Out of Our Community, went reasonably well. I made a case for charging for add-ons, and gave a few tips that I’ve learned from doing it. Time will tell if I got through to anyone.

You can view this video side-by-side with my slides, along with the rest of the session videos and slides, on the EECI2009 website.

It’s only been a few weeks, but I already miss it. The good news is that EECI2010 planning is already in motion. They’ll be making an announcement about it on November 30, so make sure you’re following @eeci2010 for the scoop. One thing is for sure: I’ll be there, whether or not I’m invited back as a speaker.

As exciting as the prospect of EE 2 is, it doesn’t mean much when you rely on third party add-ons that aren’t yet compatible. So I figured it’s high time I revealed my roadmap for EE2 compatibility. Keep in mind that sometimes things go faster than expected, and sometimes they take longer.

There’s no need for FieldFrame to be ported, thanks to EE 2’s upcoming fieldtype API. You might have noticed that Sarge, Snitch, and Editor are also missing from this list. Sarge has already been replaced by FF Select, Snitch is being discontinued, and I’m not exactly sure what to do with Editor yet.

(You can read more about my EE 2 support on EE Insider.)

Pixel & Tonic

The EE2 transition isn’t the only big news for me, though. As I announced during my EECI presentation, I’m going to be leaving LEVEL at the end of the year, allowing me to put all of my energy into ExpressionEngine add-on development!

To be sure, this was an extremely hard decision to make. The people I work at LEVEL and Apple are top-notch, and continue to challenge and inspire me. But I’ve reached a point where both my day job and my EE work are suffering, and something had to give. Even still, I’m hoping to continue working with the team on a contract basis a couple times a year.

In tandem with going solo, I’ve decided to go legit and incorporate myself. The name I’ve chosen? Pixel & Tonic. Because I like UI, and I like gin & tonics.

Working with someone on the identity and building the new website will take some time, especially amidst this parade of EE 2 add-on porting, so I don’t expect to publicly launch the company for a few months. In the meantime I will continue to release things right here on my personal site.

A big thank-you to all of you that have made this move possible for me. I’m extremely grateful!

At least that’s what I keep telling myself.

But a peek into my iTunes library and DVD collection tells a different story: Arrested Development. Battlestar Galactica. Curb Your Enthusiasm. Deadwood. Dexter. House. LOST. Mad Men. Metalocalypse. The Office. Seinfeld. South Park. Weeds. The Wire. 24. And as of a couple days ago, Six Feet Under.

Each of these shows are absolutely stellar. With the exception of the latter (for now), I’ve watched every episode of every season of each of them. Often at fanatical pace. (Last month, I watched all four seasons of Weeds in three days while recovering from getting my wisdom teeth pulled.)

So maybe I do watch TV. Time to find a new schtick.

And let’s say I’ve accepted this. What’s missing from my library?

My understanding of introversion has always been pretty basic – I know that it’s the reason I prefer to be alone, and that being around other people for too long is draining. But last night I came across this article, “Caring for Your Introvert”, written by Jonathan Rauch for The Atlantic back in March of 2003. I tweeted about it after reading, but it’s too good to not post here as well.

Jonathan did an amazing job describing what it’s like to be an introvert. In fact, I learned that many of my traits I’d always considered to be personality quirks are actually just manifestations of my introversion.

In the midst of making a case that introverts are oppressed, he makes a small aside that struck a chord with me:

Many actors, I've read, are introverts, and many introverts, when socializing, feel like actors.

I can’t tell you how weird it was to read that. It’s something I’ve always felt, but never really thought through. Another way to put it, perhaps, is that socializing is a third-person experience.

After tweeting about the article, a couple people responded in private (naturally), expressing their agreement with it, which was affirming to hear.

So, whether you’re an introvert or an extrovert, I highly recommend you give it a read. Either you’re going to learn things about yourself or people you care about, and you’ll be better for it.

It’s a subject I’ve taken a backseat interest in since releasing my first commercial product half a year ago. Like any other skill, it’s a bit tough at first, but gets easier with practice and patience.

I’ve begun to sense an improvement in my own marketing efforts, so I figured I’d share a few things I’ve learned thus far.

So what is marketing?

Marketing is more than your product’s website and advertisements. But rather, everything you do in the public eye ties into marketing.

Don’t buy that? Consider John Mackey, the CEO of Whole Foods. He recently wrote an opinion piece in the Wall Street Journal, arguing against Obama’s healthcare reform. In no way did it reflect his company’s official stance on the matter; it was his own thing. But now there is a widespread Whole Foods boycott amongst American liberals.

So be mindful of this every time you tweet, post on the forums, etc.

Be! Excited! Be! Be! Excited!

With the exception of food ads, which are geared to spark an immediate craving, we generally don’t react to advertisements in a tangible way until a later point in time. So marketing, I think, should have one basic goal: to get people excited about your product.

Stay away from fluff. People see right through it, and it comes across as diffidence (big turn-off). Instead, be concrete. And be honest. Why are you excited about your product? Chances are, your target audience will share your sentiment.

Find a clear, consistent message

To market your product effectively, you need to come up with a clear and consistent message. Put some thought into this. Much like branding, changing your message down the road is like starting over. That’s not to say that changing your message is wrong; products change over time for a variety of reasons, and messaging should reflect that.

37signals recommends coming up with a single sentence to define your product, before you even begin working on it. That sentence can double as a starting point for your messaging. Let everything else branch out from there.

Wygwam’s core message is simple: it’s the premier WYSIWYG editor for ExpressionEngine. Why? Because it uses the best editor in town, it’s really easy to set up, and it looks great alongside other fields in the Publish page. Because that message is simple (and accurate), a search for “wygwam” on Twitter reveals that people tend to echo it when they talk about Wygwam themselves. That’s a beautiful thing.

The lost conference

No blog post would be complete without an example of what not to do, so let’s pull out the old magnifying glass and focus it on EE Roadshow, an upcoming conference for ExpressionEngine users.

I’ll be participating in a panel at the conference along with other notable EE add-on developers. The full lineup of speakers is quite impressive, and it should make for an extremely insightful and educational day.

But you wouldn’t know it by visiting the website.

Although the core message is right up at the top, it’s in the form of an endorsement (which it isn’t; it’s attributed to the EE Roadshow Team themselves), it’s wordy, and if you removed “ExpressionEngine”, it could be used to describe any conference. It positions the conference as a place to hang out with people who do what you do. But that need is already met. It’s called SXSW. So instead, the message should be about the educational value.

The remainder of the visible page is composed of more fluffy, repetitive verbiage, a Twitter stream, and “news”. There is a Speakers section on the page, but I had to actually scroll down before I could see it. And I’m using a 24-inch display. That list of speakers should be driving the core message. It should be right up at the top. After all, it’s what you’re paying for.

Late last week, EllisLab published a blog post about the conference, written by Kevin Shoesmith, one of the conference’s founders. While it does stick with the core message, there’s no mention of who will be speaking, examples of who will be attending, or even how many attendees have signed up. Instead, it reads like a car commercial, attempting to “appeal to your imagination” (as Kenny Meyers put it), and leaves one with a sour taste in the mouth. Given the reach of the EE Blog, this was certainly a missed opportunity (as evidenced by the lack of discussion in the forums).

Compare all this with the ExpressionEngine and CodeIgnighter Conference, another such EE gathering at which I’ll be speaking. Their website and tweets both convey the same brand, message, and attitude. The website is well-designed (an important distinction when targeting web designers), displays the list of speakers prominently toward the top, and is limited to short, action-packed copy. There’s a lesson to be learned in that.

In conclusion

Marketing is a good thing. If you’ve got a product that is going to enhance people’s lives, it’s your responsibility to get the word out about it, clearly and honestly.

Don’t reach for things to say when talking about your product. You’ll either come across as desperate and push people away, or you’ll build it up so high that your customers will be disappointed after purchasing. Find the things that get you excited about it, and share that excitement. Simple, right?

This lasted about a week, until one night I actually got up, and went to the bathroom. There I made an unexpected discovery: it wasn’t the middle of the night; it was 5:00 AM. The sun wasn’t up yet, but it was morning. This new environment had magically transformed me into a morning person. So I accepted it, and to this day, I naturally wake up every morning between 5 and 7 AM.

Recently, another transformation has taken place: I’m starting to enjoy writing.

I used to enjoy creative writing in school, but being that I dropped out of college early on to pursue my career as a web developer, that part of my brain has been boarded-up and forgotten.

But those boards have been slowly pried off over the last year, through my daily use of Twitter. Each time I compose a tweet, I try to put a little thought into how it’s worded, and I think that’s had some sort of positive effect on the Writing Department in my brain.

The first time I noticed the change was when I wrote “The Perfect Support Request”. It was a subject that I’m passionate about, so it was no surprise that the words came easy, but I didn’t expect to enjoy writing it.

When crafting Playa and Wygwam’s overview pages, I put more effort into writing the copy than I have in the past, and found those to be fun as well.

So I decided to spur some new life into my blog. I’ve given it a new design (with comments!), and a new URL. I plan to start writing here on a more regular basis.

I’m kicking things off with an article about marketing, a subject I’m just beginning to develop an interest in.

Support is often like doing taxes: time-consuming, confusing, depressing, and unfortunately, unavoidable.

But earlier this evening, I witnessed something I never dreamed possible: the perfect support request. So, in hopes that others might learn a thing or two from it, I’ve decided to critique it here.

The ticket, “Playa tags not rendering”, was submitted by the adorable Mahalie. Her title alone is worth mentioning for its clarity and conciseness.

Let’s dive in.

She begins with a bit of humor to lighten the mood, drawing attention away from the daunting title and blood pressure-raising red background:

I'm starting to feel like I have some kind of serious mental challenge!!

Then, quickly gets down to business with details on her server environment:

EE 1.6.7, PHP 5, FieldFrame 1.1.3

Now, watch how she retraces her steps, pinpointing exactly where things stopped behaving as expected:

Installed Playa 2.0.7 after I got FF totally working. The install seemed to work, no errors, CP/setup was smooth and admin/publish page looks right too. Editing an entry using Playa and selections are still there so it seems to be writing to db. My playa field is called 'lp_selected'.

{if lp_selected}
  <p>I can see it!</p>
  {lp_selected}
    {title}
    <p>Yes! I'm inside...</p>
  {/lp_selected}
{/if}

I can see it shows up. That is the tags seem to be parsing but don't return anything. I never get any titles or even my test message that I'm in the loop. I have tried just using {lp_selected} to see if anything would output, to no avail.

Did you catch that last sentence? Let me repeat it again, just in case:

I have tried just using {lp_selected} to see if anything would output, to no avail.

That’s what we like to call “troubleshooting”. Sure, it didn’t actually solve the issue, but it provided valuable information that crossed-out one possible explanation. It’s the first thing I would have asked her to do, had she not done it already.

She also confirmed that there wasn’t a typo by adding an intentionally meaningless tag, and that it wasn’t an extension conflict by disabling all other extensions.

But she didn’t stop there:

I have checked my path in settings, as mentioned I have several other fields including an FF Matrix working on the same template. The path is not relative as was mentioned in the other similar issue to this.

I can’t tell you how many times people ask me something that I’ve already answered time after time on Get Satisfaction. Very frustrating at first, but I’ve come to expect it. To see that Mahalie has actually taken the time to see if anyone else has had a similar issue, and logically deduced that hers is unique, is nothing short of fascinating.

She concludes with an annotated screenshot of her Playa field (a great way to ensure that we’re both on the same page!), and thanks me in advance for taking the time to help her.

Folks, this is how it’s done. She did her own troubleshooting. She made sure her problem was unique. And when all else failed, she came to me in good spirits.

But only Jesus is perfect!

OK, fine. There was one small quibble: the issue ended up being something that is documented on Playa’s Overview page:

status="open|my_custom_status"

Filter the selections by status. Prepend the value with “not ” to specify which statuses to exclude. Leave the value blank to include all statuses. (Default is “open”.)

(Her entries were assigned a custom status, so she needed to override the status param’s default "open" value with "not closed" or the like.)

Of course, fault here also could be blamed on my sorry excuse for documentation. (Working on it.)

It began with a promotion at Design Reactor, where I went from Associate Engineer to Engineer.

In February, I started working on a new website for Navigant Consulting. I was the lead engineer, which ended up meaning the only engineer (save for the Virtual Knowledge Center). Through that project I learned the ExpressionEngine CMS, and got into extension development for it. At its end, I was awarded Design Reactor’s prestigious Core Award during a company-wide staff meeting.

Rather than take some much-needed time off, I was immediately thrown into a tech lead role for Design Reactor’s new website. I was in charge of two other engineers, and had to see the site completed in a month’s time. I was pessimistic (the company’s previous website took half a year to complete), but one way or another we pulled it off. And we were exhausted.

Soon after, two things happened: I moved into an apartment with a friend from high school (a first for both of us), and I accepted an offer at LEVEL Studios, a web agency in Downtown San Jose. In effect, my life changed entirely over the course of one week.

I hit the ground running at LEVEL. They had just recently launched a new blogging site for Cisco using ExpressionEngine, and there were a couple high-priority tickets they had me address. Once things had calmed down on that front, I joined the Apple team, where I have spent most of my time since. Working on Apple’s website has always been a dream job for me; no other company has inspired me as much as they have. And the real deal has not disappointed. Apple’s attention to detail and dedication to perfection is just as true in the spirit of their web team as it is in Steve Jobs himself.

In the later months of 2008, I turned the attention of my spare time toward ExpressionEngine. I resumed work on Playa, one of the extensions I had written for Navigant’s website. I set a roadmap for a 2.0 release, which is now well underway. (Many of the 2.0 features have made their way into 1.x releases.) I’ve even begun planning a commercial version of the extension. In December, Playa was awarded Extension of the Year by Devot:ee, an all-things-ExpressionEngine website currently in the works.

When 2009 drew near, I decided to kick off the new year with a new personal site. (The content on my site has come a long way from the portfolio gallery and occasional blog post.) So the last few weeks of the year went into what is now the new brandon-kelly.com. In the process I wrote two new extensions: Gypsy and Editor. I released Gypsy on its own, which instantly became a new must-have extension for any complex ExpressionEngine-based site. Editor was written late enough in the game that I decided to wait and release it in tandem with the new site, so the community’s response to that has yet to be seen. I also spent a couple days updating my other extensions, Snitch and Sarge, giving them the ability to check for updates, and bringing the style of their Settings forms in-line with the others.

Looking forward

I have a lot planned for 2009. On top of my aforementioned plans for Playa, I have a couple of side projects in the oven, and I’m hoping that one or the other will come into fruition sometime this year. Time will tell.

To stay up-to-speed with what I’m up to, you can follow me on Twitter or subscribe to my RSS feed.

Thanks for reading, and have a productive year!

I’ve been at An Event Apart the last couple days. This was the first big conference I’d ever been to, and I had an awesome time! Great speakers, great attendees, and great food.

What follows is a collection of the memorable things I took from most of the sessions.

Secrets of the CSS Jedi, Eric Meyer

My initial impression of this session was that it was slightly interesting, but mostly a waste of time. Eric spent the majority of the time going through the steps he took to style a financial table like a bar graph. I didn’t really learn anything new, and don’t think I will ever be doing this myself.

After giving it some time to sink in, however, I had a change of heart. I don’t think his point was to create something necessarily useful in our work, but rather to help us understand just how powerful CSS can be—that we have complete (or at least nearly complete) control over the appearance of every element within the DOM. Just because a browser wants something like a table to appear a certain way by default does not mean it has to.

Design Your Way Out of a Paper Bag, Jason Santa Maria

This was a great session. Jason clued us in on his entire design process, complete with examples of how he gets his inspiration and the research he performs to get a deep understanding of the client’s business and demographic.

Writing the User Interface, Jeffrey Zeldman

Not much here that I haven’t heard from Signal vs. Noise before, but interesting and hilarious nonetheless. I definitely need to keep this stuff in mind while working on Tinabi.

Why I Hate Online Captioning, Joe Clark

About as enjoyable and worth-while as any opportunity to listen to someone bitch for an hour 43 minutes can be. (Thanks Joe)

Why Good Content Must Suck, Jared Spool

This session was simply fascinating! Jared is a usability expert, and he spent most of his time going through various usability tests his firm has conducted over the years. His main point was that users are more than willing to click through several pages of a website to get at what they want, so long as the information on each succeeding page is more specific than the last, and the “scent” of what they’re after remains strong. And did I mention that he is hilarious?

Design to Scale, Doug Bowman

Doug is the mastermind behind Blogger’s new look, and is now occupied working as Google’s Visual Design Lead. I found his session very insightful, and appreciated his excitement toward the design challenges that present themselves when you’re catering to hundreds of millions of people.

Learning to Love Forms, Aaron Gustafson

Forms have always been the one part about CSS-based layouts that I completely despise. Until yesterday, that is. During the session, something changed psychologically. I now feel willing to deal with them, and embrace the constraints. Knowing which form elements to tweak and which to leave alone is a big part of it.

I am definitely going to keep his slides handy, lest I forget his words of wisdom the next time I approach form styling.

Selling Design, Jeffrey Zeldman

Jeffrey once again took the stage to talk about how Happy Cog works with their clients throughout the design phase. As I’m not doing much design work for clients anymore, this was not extremely relevant to me, but I am absolutely going to share Jeffrey’s insights with my coworkers.