On ExpressionEngine vs. WordPress

Several years ago I decided to take a look at the popular web-based content management systems available, choose two of them and focus my website development efforts around them.

It was time. I had been a strong proponent of Adobe Contribute for years as it made managing websites for non-HTML savvy folks very, very easy. But I saw value in web-based products versus buying an app that needed to be installed on a computer.

The Analysis

So, I looked at Drupal, ExpressionEngine, Joomla! and WordPress. I know there are others, but these are the ones that jumped out and appeared to have a strong, committed developer base.

Truthfully, my review was not scientific, but the biggest factors in my assessment were:

  • Aesthetics of the product’s website and admin,
  • The commitment of the teams responsible for updating and upgrading the product,
  • The apparent size of the product’s developer base,
  • Availability of documentation,
  • The price, and
  • How quickly I felt comfortable creating a site using the product.

The Winners

WordPress was an instant winner. The price tag was right, the commitment of not only its creator but also of the core team made was evident and documentation abounds. Also, the admin area for entering and managing content was—and remains—beautiful. It was a natural choice.

At the same time, I kept hearing of this product called ExpressionEngine. I didn’t know much about it, except that it was used by some high-traffic, high-profile websites. And that impressed me. The product was in transition moving from a very solid version one-dot-something to version two. They had a beta of version two available, so I downloaded it, found a book about it and got busy. Out of the box, EE is powerful and incredibly customizable. I was initially a bit overwhelmed by the granularity of the settings, options and capabilities, but I was impressed by a clean admin interface, a very strong and responsive support forum and the commitment of the community behind the product.

So there were my two winners: WordPress and ExpressionEngine.

The Ones Who Didn’t Win

It’s unfair to call Drupal and Joomla! “losers” because they didn’t lose. To say they “lost” implies that the products did not meet any of my very non-scientific criteria. They both do have strong developer bases and committed teams to improving and updating the products. Documentation abounds and they’re both free. And they each have an incredible global installed base.

But I just did not feel comfortable using them. And that’s the non-scientific part of it, really.

Why brettro.com is WordPress

Shortly after choosing both WordPress and ExpressionEngine, I had a major project where EE was the perfect choice. I still manage that website today, use EE daily and absolutely love it. (I wish I could tell you what that website is, but I am ethically bound not to.)

Because I was already using EE on a daily basis, I felt that I needed to use WordPress on a website that I would also manage daily so that I would become equally as familiar with it. And so I chose WordPress to be the CMS as I began to redo brettro.com.

So there it is. My reasons for choosing and using the web-based content management systems I do.

What CMS’s do you use? And why?

 

Submitting to Subversion

This is the first in a four-part series about how Brettro integrated Subversion into its workflow. Part two will discuss the products Brettro uses to manage its SVN repositories, part three will discuss how Brettro uses SVN with ExpressionEngine and part four will talk about how Brettro uses SVN with WordPress.

About a year ago I tackled the task of integrating version control into my coding practices. I had spent a frustrating amount of time either recreating my code base as I started on new projects or backtracking and rewriting code when I would get a flash of inspiration to try something new. Also, I have both an iMac and a MacBook Pro and I use them interchangeably and wanted to be able to have the most up-to-date code on both of machine. Plus, it seemed all the pros were doing it—and since I consider myself one—I should join the gang.

Why Subversion?

Usually I do quite a bit of research, compare features and discover the value of one product over another. In choosing SVN, however, all I knew was that the WordPress Core Team used it. That, in and of itself, was a strong enough testimonial for me to dive right in.

Getting Started

When I know nothing about a topic, I buy a book, which is the first thing I did. I picked up Apress’s Practical Subversion, second edition, plopped down and started reading. I read chapters one, two and six completely as they provided an overview of version control in general, a “crash course” in Subversion and best practices in using Subversion. (By the way, Subversion is also known as SVN.)

Although clearly and plainly written, I was still confused as to the best way to get started and the best way to integrate SVN into my current workflow. I asked folks how they used it. I tweeted about my confusion consistently. I read blog entries and articles ad nauseum. I definitely hadn’t had my “ah ha!” moment yet.

Integrating SVN into My Workflow

As it turns out and after some starts, stops and stumbles, I realized that my current workflow wasn’t so much a “workflow” as much as it was a “jumble-of-tasks-that-stumbled-over-themselves” to get a project done. So I began to map out two workflows: one for managing Brettro web properties and one for creating and managing client web properties. This was really helpful as it:

  • Clarified the basic SVN concepts of trunks, tags and branches, and
  • Formalized how I create, produce and maintain website code.

Creating a Foundation: My HTML ‘Codebase’

With a better understanding of the basic SVN terminology and process, I decided to start with a fresh series of HTML, CSS and JavaScript files that would serve as the basis of all my website code from hereon out; and I’d call it my “codebase.” This seemed to be a great time to:

  • Make the switch from HTML 4/XHTML 1.1 to HTML5,
  • Adopt HTML5Boilerplate, a well-maintained framework established to ensure HTML5 code worked fairly well on legacy browsers (like any version of Internet Explorer before IE9),
  • Adopt 960.gs, another well-maintained framework established to ensure CSS consistency across browsers, and
  • Create the Brettro website design style manual.
With my basic HTML5 codebase complete, it was time to venture into the world of SVN. My goals at this point:
  • Be able to modify my HTML5 codebase as necessary for both my purposes and as both HTML5Boilerplate and 960.gs released improvements,
  • Create a branch of this codebase for my ExpressionEngine development,
  • Create a branch of this codebase for my WordPress development.

Repositories, Trunks, Branches, Tags and Working Copies

Let’s get some basic terminology out of the way:

  • Repository: the “repository” (or “repo”) is the container where your SVN-managed code is kept;
  • Trunk: the “trunk” is the main codebase of a project where most of your development will occur;
  • Branch: a “branch” is an offshoot of the trunk (do you see the tree metaphor?) whereby you might want to try out an idea or a feature that may not actually make it into production;
  • Tag: a “tag” is a copy of either the trunk or a branch frozen at a specific point in time, such as a release (the tree metaphor comes to a screeching halt here); a tag is never modified once it’s created;
  • Working Copy: the “working copy” is either the trunk or a branch copied to your computer from the repo to allow you to make changes.

After all this reading, contemplating, starting, stopping, deleting and creating, I settled on a basic structure that works for me. I’d like to think it’s a pretty common structure because it is based on my understanding of how WordPress organizes their SVN repository (and I like to use best practices because there’s no need to reinvent the wheel):

Trunk

This is where I do my “next major version” development. For example, right after I finished my HTML5 codebase, HTML5Boilerplate released version 2 of their product. Rather than integrate those changes into version 1 of my codebase, I’ll integrate them into version 2 and do that development here.

Branches

When I imported my initial HTML5 codebase into my first SVN repo, I immediately created a branch and named it “1.0.” The “1.0” branch is my working copy of my HTML5 codebase code where I squash bugs and make minor fixes, then release them as dot releases. These releases are merged back down to the trunk so that they are included in the next major version codebase release.

Tags

After creating my “1.0” branch, I also created a “1.0” tag. This gives me a complete capture of version 1 of my HTML5 codebase so that I have a stable, working copy to use to create new projects.

Committing to SVN (See what I did there?)

By finally having an understanding of basic SVN techniques, by documenting my SVN structure and practices and by creating my first version controlled codebase, I was ready to take a deeper dive. Next I created branches of my codebase for both my WordPress codebase and my ExpressionEngine codebase. Stay tuned to the next three parts to learn what software I use and what workflow I use to manage sites built with either of these content management systems.

Web Designer vs. Print Designer

I had to provide brief talking points yesterday about the difference in skill sets and knowledge between a web designer versus a print designer. Since the points needed to be brief, I focused mostly on the web designer:

  • Web designers/developers have expertise in using HTML, CSS and JavaScript, which are the markup and programming languages used to create websites, ebooks and apps whereas print designers would not know this;
  • Web designers/developers understand that their “canvas” (the screen) comes in hundreds of combinations of shape, size and density (HD vs. standard definition) and how to create for that whereas print designers understand the limited dimensions of their canvas (paper, banner, ad, boat, etc.)
  • Web designers/developers understand the importance of using the proper HTML markup to provide semantic context and structure to content through multiple delivery mechanisms (e.g. screen, screen reader, etc.) whereas print designers provide the same structure through fixed, visual differentiation in design
  • Most web designers/developers can work in simple print design (e.g. document production, brochures) because it is considered an easier medium after having mastered the complexities of web design and HTML, CSS and JavaScript languages.

While I think I captured the essence, I’d like to hear what you think I forgot or missed. Submit your comments!

Seeing Steve Jobs Everyday for 26 Years

I am more emotional about Steve Jobs’ death than I thought I would be. My first instinct was to quash those emotions because it seemed unnatural to be so moved by the death of someone I did not personally know. But then I realized that his vision, passion, charisma, tenacity, perfectionism and ambition have been present for over two-thirds of my life in the very products I used to discover those very same attributes and desires in myself.

I knew Steve because he put so much of himself in the very machines I used to capture my deepest, scariest, saddest, most ambitious, craziest, looniest, cleverest, funniest, ham-handed-est, ridiculest (yes, I know it’s not a word), dreamiest thoughts, fears, ambitions, goals, concepts, drawings, visions and ideas.

I have owned or had assigned to me somewhere near 20 Macs since the first one arrived at my house on a Friday night in 1985. With those Macs as markers and if referenced by name, I can tell you where I was living, what music I liked, the software I used and owned, the friends and crushes I had, who I was talking to online (or if the Internet even existed) and the things that were going on in my life. That I can do this with a product easily dismissed as “consumer technology” is amazing. I mean, who can do this with a VCR?

That Steve taught me to respect polish and perfection, to look outside of “what everybody else is doing,” to amplify that little voice in my head and to respect how humans interact with technology all through the design and presentation of his products is nothing short of astonishing.

I do not idolize people. I think doing so is unfair to them. But I very much model my business and my professional behavior after Steve. He saw both the value of and opportunity in the personal computer and he knew that if he made the most perfect product possible, then he would truly achieve something.

While I know I am no Steve Jobs, I suspect that he would say, “good, you shouldn’t be. You should be Brett Bearce. And you should work to make insanely great things.”

Brettro Re-Launches brettrospective.com

About nine months after starting this redesign in earnest, I am thrilled to announce the new brettrospective.com!

But nine months?!??

Yep. While it did not take an actual nine months to develop the design, write the code and move the content into WordPress, the Brettro website always took a back seat to both my client work and my full-time job.

The good news is, that in that time period, I really focused on developing better coding practices and on developing a solid codebase from which I can tweak and grow. I have integrated the 960 grid system and the HTML5 Boilerplate frameworks into a very solid HTML5 codebase. For customers, this means fast-loading, search-engine-optimized code. For me, it means quicker development times.

What’s Next?

While I have a solid code foundation and a great look-and-feel, this site is not yet complete. I still have a ton of content left to add. Brettro is not just a web design company, it also does identity, print and video work, plenty of which I have left to add to the Portfolio section. Stay tuned every week for updates.

Looking Back

Truly one of the most fun things about moving forward in any design is taking a look back at what was. So, of course, we’ll do that here. The images below are of the three previous Brettrospective website design. Laugh, smile and enjoy!

The third iteration of brettro.com
The homepage for the second iteration of brettro.com
The homepage for the original brettro.com

Strategory

About nine months ago, I wrote about a strategic shift in the foundational elements Brettro will use to design websites for its customers. The rumblings about HTML5 were becoming louder, I had just finished deploying my first full-scale, medium size website using ExpressionEngine and I had deployed a handful of mediocre (on the coding side) WordPress sites. (They have since become less mediocre.) The benefit of using products with a solid, committed design, developer and fan base behind them, like ExpressionEngine and WordPress, really began to gel with me.

Platforms and Coding

My skill is in coding, my passion is in creating meaningful, usable user experiences and content, my “superhero strength” is managing projects and my “weakest link” is my design chops. Recognizing this, I decided it was time to step up my game and create a plan combining my skill, passion, “superhero strength” and “weakest link” into a functioning business strategy and workflow.

Step one:

  • professionalize my internal processes,
  • document coding standards for Brettro,
  • develop a sustainable platform for client documentation, and
  • really sink my teeth into merging my “mad coding skills” with the best practices for developing websites using both WordPress and ExpressionEngine.

In that time, and largely through Twitter, I have found an incredible and helpful community surrounding both EE and WP. I started more professional code management using Subversion (and an amazing Mac client called Versions). I have launched my HTML5 codebase. I have created nearly 13 WordPress plugins (and, in many cases, had to completely scrap and re-create them as I learned more and more about WP coding best practices).

In short, I’m well on my way to achieving my goals of becoming more familiar with and better at coding for two brilliantly executed, powerhouse web publishing platforms.

But there’s more to do…

Design, Design, Design

If anything has suffered through all this, it is the design of the Brettro web properties. They are certainly not horrible—and definitely don’t rank amongst the legacy 1996-era sites with all the visual appeal of an avocado green refrigerator—but they are my weakest link.

With comfortable knowledge of HTML5, Subversion and WordPress under my belt, it is time to focus on Step Two: creating a visually rich, responsive, usable, compelling interface for our websites. (The Brettro web properties use WordPress, but that’s a different discussion for a different time. Coming soon, though.)

I’m excited by this next step. Design has always been the biggest struggle for me. I understand the basic concepts, but the crippling self-doubt (which apparently plagues most of the design types I follow on Twitter) about the elegance and visual appeal of the concepts I develop keep me from executing my best work. It’s in there. I know it is. I just need to take a deep breath, walk away from time-to-time, and push through the doubt.

Soon enough you’ll see those efforts come to light. And your feedback will be important.

But there’s still more to do…

Content, Education, Engagement

This is the point where I become so overwhelmed by the sheer volume of things I need to do, learn and participate in. But then I recognize how excited I am by all of it! And really, this batch of “more to do”—also known as Step 3–is really best done by intertwining it throughout the other efforts on a day to day basis:

  • Education in this arena never stops. And that’s one thing I absolutely love about it.
  • Strategically writing content for the web is such a compelling activity, especially with advocates (and professional heroes of mine) like Kristina Halvorson and Erin Kissane making such strong showings for its benefits
  • And Washington, DC has some absolutely brilliant programmers and designers with which to engage. I look forward to becoming an active and beneficial part of the community.

So, guess what? It’s time to get busy. Come back to read about and see the progress as it unfolds. It’s going to be exciting!

‘The Big Web Show’ and Todd Dominey

I recently discovered a podcast for web design nerds like me: The Big Web Show. It’s both an audio and a video podcast hosted by Web Standards protagonist, author and professional hero Jeffrey Zeldman and tech entrepreneur and generally-brilliant tech guy Dan Benjamin. A tweet by Todd Dominey–creator of the amazing SlideshowPro–led me to the podcast and to several hours of high nerdery watching the Dominey episode and the Kristina Halvorson episode (another professional hero).

Brettro has been using SlideshowPro for slightly over a year and finds the product to be incredibly polished and incredibly easy for both his clients and him to use. Getting to hear Dominey’s backstory and the genesis of SlideshowPro was incredibly interesting and even a little inspiring. Anyone willing to quit a day job with a solid company to go it on his own has my respect.

If you like people with entrepreneurial spirit, take note of Dominey, Zeldman, Benjamin and Halvorson. Not only are they the embodiment of such a spirit, they are each passionate advocates for best-practice-based, responsible technical and content development for the web.