Website owners and managers need a simple way to edit the text within their websites. They need to add headings, make bold text, bulleted lists, and so forth. It’s a fundamental need in Content Management implementations, and perhaps the most used feature of any CMS.

In spite of this, the solutions widely available today are horrible. (more…)

We are primarily a design company. The user experience is at the center of every project we take on, every design concept we create. The goals vary widely from client to client. When clients look to us to provide content management, we need a product that is flexible and efficient – one that allows us put the user experience first, without having to reinvent a solution for each project.

Our own CMS delivered in these two areas, but added a problematic maintenance burden to the development cycle. As I mentioned before, we are primarily a design company. Developing and maintaining a content management solution is not our core business.

Two years ago, when a new client asked us to review several open-source CMS products and provide a recommendation, we did some research and suggested Drupal. Since then, more than a dozen Drupal implementations have followed.

Here’s why:

• Drupal provides a presentation layer, via a robust theme engine, for customizing the HTML output of virtually any piece of the application. We can put the user experience first.
• There is an incredibly active Drupal community. The product’s maintenance is distributed across a passionate group of 1000+ developers.
• The Drupal community cares about standards. The generated HTML code is a bit bloated at times, as happens with any generalized solution, but by-and-large its HTML output conforms to modern web standards.
• There are literally thousands of contributed modules providing a vast range of additional functionality.
• Often, the functional requirements for a project can be met without writing a single line of code. Specifically, the out-of-the-box flexibility provided by the Views and CCK modules is amazing.
• Drupal offers a robust application development framework for add-on functionality.
• Drupal is built on PHP with current support for MySQL and PostgreSQL databases, with plans for pluggable database support in version 7. Drupal is built on technologies that are among the most widely used and supported on the web today.

Over the last two years we have deployed solutions using Drupal that range from simple, “brochure-ware” websites; to websites that integrate with enterprise CRM systems and deliver real-time data for hundreds of projects worldwide; to informational websites for educational institutions; to community websites featuring user-generated content for prominent, widely recognized cultural heritage institutions. The applications have varied widely, and the final products have delivered on goals every time.

We’re hooked.

Freelance Position Requirements:

• Extensive ActionScript experience
• Ability to work well in a team setting
• Flexible schedule to permit fluid collaboration with our team
• Ability to work from our office in Denver, CO is preferred but not required

Interested?

Email work@atendesigngroup.com with your portfolio, work experience, and rates.

Aten Design Group has moved. After six years of doing business from an office in Williamsburg, Virginia, we have relocated to Denver, Colorado.

Reasons Why

1. Talent is hard to come by in Williamsburg.
2. Important members of our team are already spread out across the country, with key designers in New York and LA. A more central location better serves them.
3. Our clients are similarly spread out.
4. The rocky mountains are here.
5. There are dozens of other reasons, personal and professional, that also made Denver the right choice.

The New Place

The new office is on Downing and 17th, just a few blocks east of downtown. The office takes up the top two stories of a historic mansion. We love the space and love the location. We still need art on the walls, still need to set up the conference room, and will be making some final (minor) structural modifications, but are very happy to be here - despite the settling dust.

We needed to output a simple date… say, something like:

<div class="date">Saturday, August 18, 2007</div>

Turns out Drupal likes dates a bit fatter:

<div class="field field-type-datestamp field-field-date"> 
  <div class="field-items"> 
    <div class="field-item"> 
      <span class="date-display-single"> Saturday, August 18, 2007 </span> 
    </div> 
  </div> 
</div>

Which led to yet another conversation between myself and Ken regarding Drupal, some of the disconnects between that CMS and our process, and their solutions.

Needless to say, there remains no one-size-fits-all solution. The features offered by Drupal, its vocal and active community, and its highly modular architecture make it an incredibly effective product for a wide range of implementations. On the other hand there are significant sacrifices — for one, ridiculous HTML-bloat. Or, when it’s worth it, there is the time lost trimming that same bloat.

1 - They do business like everybody else.

There are many misconceptions about non-profits, the biggest of which classifies non-profits as non-paying (or little-paying) customers. A couple years ago we posted a note about an open position to a well-known design forum, and mentioned that we do a lot of work for non-profit organizations. One of the replies was something to the effect of, “non-profit = no profit.”

That just isn’t so. We’ve seen no measurable, categorical difference in the budget assumptions made by non-profit organizations as compared to the assumptions made by their for-profit counterparts.

2 - The reasons they get up and go to work in the morning are, by-and-large, amazing.

Most non-profits are inherently driven by greater purpose, vision, and mission. We’ve had the opportunity to be involved in some truly amazing efforts, efforts where our work — connecting clients to their users in meaningful ways — becomes both incredibly important and rewarding.

Over the years we’ve been involved with organizations working to:

• Eradicate poverty housing
• End world hunger
• Elevate the standard of living for children globally
• Preserve history and culture for the benefit of present and future generations
• Provide medical care where it would otherwise be unavailable
• Promote global literacy
• Translate the Bible into mother-tongue languages of the world
• Engage children to be advocates against poverty

What an honor.

Let it all out

Giving feedback can be really hard. Sometimes, the design looks good and the only feedback you have is minor. But often this is not the case. Sometimes you have so much criticism that it feels like you’re punching the designer repeatedly in the gut. You can almost see the tears well up in their eyes. Negative criticism is not bad, it’s part of the process. How you give criticism can be the difference between a constructive meeting that benefits the design and an all-out battle where the designer goes on defense and nothing is gained. Here are a couple guidelines that may help:

1. Make your case
   If your suggestions make sense and have logical benefits to the design, this is the easiest way to help.
2. Pull your punches
   Make sure you say everything you’re thinking — this is vital for the critique to work — but watch out for insulting language. They don’t call it “constructive” criticism for nothing.
3. Don’t make it personal
   There’s a big difference between personal opinion and relevant feedback. No one cares if you don’t like pink, never liked pink, and in fact choked on bubble gum as a child and are traumatized by the color pink. What matters is that the color of the secondary callout is too bright and is stealing the focus from the main callout on the home page which adversely affects the way a user navigates… you get the point.

Take it all in

Design can be a very personal thing. I often get attached to a design and think, “Wow, what a perfect little thing you are. You’re so pretty and functional and you’re going to do great in the world!” Then I get some criticism, and my perfect little thing isn’t so perfect anymore. I get defensive and frustrated and I have to remind myself that this is work, and if there’s something wrong with my work, I need to hear it.

1. Acceptance is the first step
   For a design process to get the best results, you must open your work up to criticism. It’s important to get opinions from everyone — project managers, content specialists, programmers, spouses, friends — not just designers. Then actually listen to what everyone has to say. Don’t get defensive, they aren’t trying to insult you. Remember, you asked for it.
2. A glutton for punishment
   It can be hard enough asking for criticism once. Going back for a second helping almost seems foolish. Do it anyway. Get feedback whenever you reach a good stopping point, make changes, and repeat until there’s nothing else to critique.
3. It’s not your baby
   …it’s your clients’ baby, er, website/brochure/what-have-you. You can be as proud of your design as you want but if it doesn’t work for your client, you’ve failed. Ultimately, it all comes down to what your client thinks and the effect it has on their business.

I can’t stress enough how important criticism is to an effective design process. Incorporating it into key points along the way can really help a design. Whenever you think you’ve completed a milestone, open your work up for criticism and see if everyone else agrees. If not, listen to what they have to say and use their feedback to finish your work. Remember, process is key, and criticism is a key part of the process.

I didn’t have a great answer. I rambled something about goals, about being realistic, and some other things I don’t even remember. They probably don’t remember them either.

In my defense, it’s been a while (seven years) since we hired our first designer, and I haven’t had to think about making that jump for a long time.

Over the last couple weeks, though, I’ve given the matter a little more thought, and now have what I hope is a much more useful answer.

You hire your first employee (or freelancer) when the following two statements are true:

1. You want to.
2. You can afford to.

That’s it pure and simple.

I’ve met plenty of freelancers who aren’t interested in hiring. For these folks, the attraction of freelancing usually has a lot to do with the freedom it brings: the freedom to make your own schedule, choose your own projects, and by-and-large answer to yourself. Hiring imposes new responsibilities that are a lot less “free”. You’ll have to manage someone else’s schedule and priorities, even if not your own. Payday will suddenly be very important. And if you share an office, you’ll probably need to stop going to work in your underwear. Sound bad? Then don’t hire.

Likewise if you can’t afford it, don’t do it. Make absolutely sure that your cash-flow accommodates the new hire. If the cost of bringing someone onboard full-time is daunting, start with part-time or freelance and let the position grow as you earn return on your investment.

So that’s my answer to the “when to jump” question, should I ever be asked it again. The good news is that the answer is simple. Incredibly simple. The bad news is that none of this says anything about how to make the jump, let alone how to do so successfully.

Basically, the site would need:

1. Dynamic portfolio pieces, with the top-most piece published automatically to the home page
2. Static (X)HTML for the about and contact pages
3. A contact form
4. A blog

Initially we considered Drupal, a feature-rich open-source CMS we’ve used in the past with great results. For this case, Drupal seemed too feature rich.

We Opted to Build Instead.

Before the redesign I had a small amount of experience using CodeIgniter for some internal projects. The framework is lightweight, well-structured, and provides a broad sprinkling of functionality via its libraries. I was happy for a chance to use it to build a site from the ground-up, and eager to see just how quick and painless it would prove to be.

Quick and Painless

The results were good. The portfolio came together in a couple of evenings — just a few hours altogether, including an admin section for adding, editing, and ordering the various pieces.

I started coding the blog on the flight back from An Event Apart Boston, and was 90% finished when we touched down on the runway. Once back in the office, I wrapped up the comments functionality.

Along the way, we made several significant changes to the (X)HTML/CSS structure of the site, moving it from a fixed design (1024×768) to a fluid-width design that shrinks nicely to 800×600 screen resolutions. CodeIgniter’s clean view/controller abstraction facilitated those changes perfectly.

Some Helpful Modifications

It’s worth mentioning a few extensions we created that made the job even easier. We coded extensions to:

1. Automatically call the set_fields() validation function when set_rules() is used, to reduce code and increase automation
2. Preload the validation object with field values from any given object - specifically to preload forms with fields from a database select
3. Prep validated POST arrays for database entry by comparing array keys to database table fields
4. Include active-record functionality into the base Model class

We’re happy to provide mentioned extensions if anyone’s interested… just ask us for them using the contact form or by leaving us a comment.

Some Highlights

Think Positive Negative

In his presentation Good vs Great Design, Cameron Moll pitched the idea that design should be problem-focussed, not solution-focussed.

Well put. We’ve spent many critique sessions backpedaling when a design isn’t working, retracing our steps invariably to the original goal, or problem. Now we have a mantra for times like these. Focus on the problem. Or, just like they didn’t tell us growing up, think negative.

Project Managers are Superstars

The conference was largely technical, devoting hours and hours to the methods of implementation. In all that, one point still couldn’t be missed: project managers are invaluable. No problem is truly understood, no goal established, and no solution designed without an effective project manager in the middle. And the middle isn’t always comfortable.

For Best Results, Over-think

Details can be tiny little pitfalls, inviting designer and client alike to pass on by. Not a good idea.

Jason Santa Maria summarized the point perfectly: “Sweat the Small Stuff.” That line was great validation for all times we’ve pulled together a meeting to discuss a font size, a color, the name of a class selector, or an approach to marking up a chunk of content.

Our Senior Designer Knows His Stuff

It’s nothing new, but very exciting all the same. The final session was a site-critique. We didn’t submit anything corporately, but our Senior Designer Ken Woodworth did submit a site he designed for a friend: www.parkviewbaptist.net

It’s the first site that the panel critiqued. Needless to say, Ken was a little nervous.

Usability expert Steve Krug opened the critique by saying that he wasn’t planning on staying for the session, but that www.parkviewbaptist.net is the reason he did. He praised the site from a usability perspective. Eric Meyer complimented the (X)HTML/CSS implementation. Jeffrey Zeldman, Jason Santa Maria, Dan Cederholm, and Cameron Moll complimented the design.

It’s worth stating that amidst the compliments the panel offered some well-placed suggestions. Within a day Ken had followed up on all of them. You might say, ehem, he sweats the small stuff.