Back in October we (James and myself) went to the fabulous DrupalCamp Atlanta and taught a session on creating and extending features in Drupal.  At the time, we didn’t have our fancy new website to blog on, so I thought it might be nice to write about that now and provide a quick summary of the high points and some organized notes.

In the session, we created a simple gallery feature as a demonstration of the key concepts.  Thanks to the fabulous features module developed by the magicians over at Development Seed we’re now able to take commonly used functionality, etc. and easily save it all into code for reuse (ex. node types, views, contexts, permissions, dependencies, rules, etc.).  This has saved us a ridiculous amount of time here at Sprocket and allowed us to devote more of our time and energy to making incredibly beautiful user experiences for our features instead of rebuilding the same functionality each time.  Feel free to go to the DrupalCamp Atlanta website and watch the video of the session.  The outline of what was covered includes:

• Outline your feature (node types, views, contexts, permissions, dependencies, rules, etc.)
• Consider your name spaces carefully!
• Build your node types, views, contexts, rules, permissions, etc.
• Create your feature
• Extend your feature with CSS

Outline your feature

When building a feature, it’s always a good idea to first outline its parts.  A great way to approach this is to simply list out all of the following that will be a part of your feature

• node types
  • fields
• views
  • displays
• contexts
• rules
• permissions

Consider your name spaces carefully!

Remember when creating your features that your type names for node types need to be unique.  For example, if you’re creating a gallery feature and your node type is an album, you may not want to use “album” as your type name.  Why?  What if you want to use your gallery feature on a site that is a musician’s site, and you’ve also created another feature to show off their albums and it also has a node type with a type name of “album” in it?  Both features won’t play well together.  A good practice is to prefix in ways that add specificity for your feature.  For example, your gallery feature might have a node type of “gallery_album” and your music artist feature might have a node type of “audio_album” for example.

This same concept also applies to the name spacing of your fields.  Unless you want all the settings on a field to be exactly the same in all features with that field, then you need a unique name space for your field.

This may seem obvious, but this ALSO applies when you get ready to name your Feature itself and give it a machine name.

Build your node types, views, contexts, rules, permissions, etc.

This part is pretty self explanatory if you’re already doing these sorts of thing with Drupal.  The beauty of Features is that once you’ve done these things you can package it all up into a nice and tidy feature module to reuse on another site or for another project.

Create your feature

Before you can begin extending your feature, you need to first create it.  While this can be done by hand, features offers a nice UI that makes it pretty fast and simple for those that don’t have access to Drush.  Remember that you have to actually have the nodes with fields there, the views, the contexts, the permissions etc. before you’ll be able to select them in the features UI.

Extend your feature

This is where I felt the real meat of our DrupalCamp session was.  Once you’ve got a feature, since it’s just a Drupal module, you can extend it in a number of ways beyond what’s currently available via the features UI.  A few examples include:

• Use hook_strongarm to set some variables
• Use hook_init to add CSS that loads with the feature

Add some strongarm settings

Strongarm provides a great way for your feature to enforce some variables.  While some would argue against the obtrusive nature of that, in certain use cases it’s a wonderfully simple solution.  For example, if you want a twitter feature where the feature is already set to work in a specific way (which node types to include, etc.) and the only thing you want to allow/require users to set is their twitter account info, strongarm makes that possible.  This means a user can enable the twitter feature and only have to do one quick task and they’re ready to go.  Another fantastic tool for getting your variables you want to strongarm, check out the variable dump module or use drush vget [variable name].  Once you’ve got some variables you want to strongarm, do the following:

1. Open your features .module file.
2. Use hook_strongarm to add your variables (see example at bottom of post from my fancy_twitter feature).

Add some CSS

In many cases styling is tied more to the theme rather than the functionality itself or the feature.  However, in some cases it’s nice to have some styling already preset for a given feature.  It’s pretty easy to do this as well, simply:

1. Open your features .module file.
2. Use hook_init and drupal_add_css to add your CSS file to your feature module (see example at bottom of post from my fancy_twitter feature).

Note: When updating your feature in the future, features module will continue to include the extended code you’ve added to your .module file, but it will NOT grab your actual CSS file and include it when tarring up your feature module for you.

Example implementation of hook_strongarm()

Adding CSS with hook_init()

Conclusion

There’s a lot more I could go into here, but I’ll leave it at that for now.  James is our Drupal magician here at Sprocket and perhaps soon I can get him to do an advanced blog post on further extending features.

Let me begin with the following disclaimer:  This brain dump is neither exhaustive or heavily researched.  I’m quite certain there are valuable articles already written on this topic, so if you know of any please let us know via comments.  I’ve wrestled with this issue for a while and haven’t yet found many writings on it.  That being said, here’s some thoughts from what we’re learning here at Sprocket.

Neither is first

This is probably stating the obvious, but just to be sure we’re clear, neither design or development comes first.  Site planning is the first step for every custom project we take on.  Whether our client has already done site planning or we’re asked to assist, any way you slice it, you have to do some planning.  Content structure, types of content, roles, features, wire-framing, etc. all need to be fleshed out before you can even begin designing or developing (although in my opinion planning is actually part of design and an essential element - but I digest).

Sprocket’s design priority

At Sprocket, we view ourselves as a design agency that does development along side, and not the other way around.  That’s not to say we feel we’re poor at development - quite the contrary.  Our genesis was as a design agency and I feel we approach problems more from a designer’s vantage point than a developer’s.  That may largely impact our views on this issue from a gut reaction standpoint, but what I’m finding is that it really doesn’t alter the fundamental problems that can arise in our workflow.

What makes a project successful?

To figure out which workflow fits best, I think it’s helpful to first determine what makes a project successful.  If the goal is successful projects, then developing good workflows becomes a strategy for achieving that goal, and specific workflows are tactics to support that strategy (although you could break that down differently I’m sure . . I’m just a designer).  One of the questions I’m trying to ask going into any project is “what are the metrics for success?”  We want to know what the client’s answer to this question is.  However, your client is not the only one with an answer to this.  Here’s a quick list of just a few things that I believe are crucial for Sprocket to deem a project successful.

• profitable - This is pretty self explanatory.
• portfolio-worthy - We want work that we want to show off and can be proud of.
• timely - We don’t want to keep coming back to it forever and never finishing it.
• satisfied client - Our goal is actually to create fans (topic for another article perhaps), so we really want an excited client, but I’ll take satisfied if the other elements for success are there.
• limited miscommunication - This simply means that the client got what they expected, and we didn’t create or allow unrealistic expectations.  Miscommunication is always going to happen at some point between humans, hence “limited” instead of “no.”

Design first: pros & cons

Pros:

• The sky’s the limit - You can design whatever you want.
• Freedom to focus on usability - You need not limit yourself (ex. you need not start from how Views outputs exposed filters by default)
• Get your client excited with pretty pictures - I don’t know about you, but most of our clients are not very wowed by garland or zen classic when shown concepts.

Cons:

• The sky’s the limit - You may design something, get the client to approve it, and then chat with your developer or dev team and find it takes forever or is nearly impossible to build.
• Missing context & use cases - Often, when designing first, there are elements of both content interaction and management that you may forget to consider.  When you develop first you often are in the middle of using and testing which can help you discover all the moving parts.

Develop first: pros & cons

Pros:

• Save dev time - You tend to more tightly hold yourself to the defaults, limitations, and patterns of the technologies you’re using when you develop first.
• Avoid unnecessary and painful design revisions - You avoid having to go back to the client to discuss revising the design based on something you figured out you just couldn’t pull off from a development standpoint. This means you also avoid getting your client excited about an idea that you then find can’t make a reality.

Cons:

• Limit innovation and useability - Let’s face it, there are lots of instances where limiting yourself to drupal’s (or some contrib module’s) defaults or patterns is really NOT the best solution for the problem.
• Client waits longer to see things they’re excited about - (see pros above for design first)

A third option?

I could probably add to these lists, but I’ll leave it at that for now.  That’s enough for you to see why I’ve said this is a journey and something we’ve not found THE answer to.  One of the things we’ve been trying lately here at Sprocket is to tackle the two congruently.  Where we used to be clearly a design first workflow, we’re now working congruently and allowing the two to inform each other in process.  Obviously if you work alone as a free lancer or have one person who does both for you then that becomes pretty difficult.  So far the congruent approach has at least been more effective I think than our design first approach was.  It can be tricky to figure out client approval processes (I think) without design, but it can be tricky to have the confidence of going to a client for design approval without any attempt at development.  As we flesh out this part of our workflow more here at Sprocket, I or James will try to blog a bit more about it.  I’m anxious to hear from others who have insights or creative ideas for how they structure this workflow with their clients and their projects.