CHROMATIC

Easily Upgrade Your Image Fields for Retina!

chris — Thu, 30 Oct 2014 19:28:15 +0000

Drupal makes it so easy to add image fields to your content types. Fields in core for the win! With image styles in core, its as easy as ever to create multiple image sizes for display in various contexts (thumbnails, full, etc.). But what about providing hi-resolution versions of your rasterized images for retina displays? Out of the box, you don’t really have a lot of good options. You could simply upload high resolution versions and force your users, regardless of display type to download massive file versions, but that’s not exactly the best for performance. You could use some custom field theming and roll your own implementation of the <picture> element, but browser support is basically null at this point. That won’t do. You could do what Apple does and force the browser to download 1x versions of your images then use javascript to detect high resolution displays and then force the browser to download all of the high resolution versions…I think you see my point.

What if you could create hi-resolution versions of these images without a ton of added filesize overhead? What if you could do this all within Drupal? No special coding, no uploading of multiple versions, no special field templates or unnecessary javascript. Just a basic Drupal image field with a special image style defined.

Here’s how you do it:

Create your image field. (In most cases, you’ve probably already got this.)
Download and install the HiRes Images module This module allows you to create an image style at 2x the desired pixel dimensions. If your desired maximum image width is 720 css pixels, your output image would be saved at 1440px.
Download and install the Image Style Quality module This nifty module allows you to define specific image qualities on a per image style basis instead of using Drupal’s global image quality setting.
Add a new image style (or alter an existing)
Add your normal image style presets, like scale, crop etc. If you’re scaling, set your scale to be 2x your desired maximum output in pixels. So if you want an output of 720, set your scale to 1440px.
Add the “Hi-Res (x2)”" effect. This will output you’re image element at half the scale amount above. So we get a max of 720px.
Add the “Quality” effect and set it to something like 60%. This may take some experimenting to find a balance between image quality and file size. In my example, I went with 60% compression. This yielded an image that was still really sharp and a reasonable file size.
Set your display mode to use this new (or altered) image style.
Enjoy your beautiful, high resolution, performant image fields!

Hard to believe this works right? You’d think your retina version would look really crappy with that much compression, but it doesn’t. In fact, in some cases it will look just as sharp and be smaller than a 1x counterpart. See my screenshots below for proof:

Side-by-side comparison:

Network panel output:

So we end up with a high resolution version of our uploaded image that is actually smaller than the original version at 720px! Looks great on retina devices and doesn’t badly penalize users of standard definition displays. WIN!

For a detailed explanation of this technique in broader terms, see Retina Revolution by Daan Jobsis

Converting Drupal Text Formats with Pandoc

adam — Tue, 17 Jun 2014 14:36:19 +0000

Switching the default text format of a field is easy. Manually converting existing content to a different input format is not. What about migrating thousands of nodes to use a different input format? That isn't anyone's idea of fun!

For example, let's say that all of a site's content is currently written in markdown. However, the new editor wants to not only write all future content in the textile format, but also wants all previous content converted to textile as well for a consistent editing experience. Or perhaps you are migrating content from a site that was written in the MediaWiki format, but standard HTML is the desired input format for the new site and all of the content needs to be converted. Either way, there is a lot of tedious work is ahead if an automated solution is not found.

Thankfully there is an amazing command line utility called Pandoc that will help us do just that. Pandoc converts text from one input syntax to another, freeing you to do less mind numbing activities with your time. Let's take a look at how Pandoc can integrate with Drupal to allow you to migrate your content from one input format to another with ease.

After installing it on your environment(s), below is the basic function that provides Pandoc functionality to Drupal. It accepts a string of text to convert, a from format, and a to format. It then returns the re-formatted text. It's that simple.

/**
 * Convert text from one format to another.
 *
 * @param $text
 *  The string of text to convert.
 * @param $from
 *  The current format of the text.
 * @param $to
 *  The format to convert the text to.
 *
 * @return
 *  The re-formatted text.
 */
function text_format_converter_convert_text($text, $from, $to) {
  // Create the command.
  $command = sprintf('pandoc -f %s -t %s --normalize', $from, $to);
  // Build the settings.
  $descriptorspec = array(
    // Create the stdin as a pipe.
    0 => array("pipe", "r"),
    // Create the stdout as a pipe.
    1 => array("pipe", "w"),
  );
  // Set some command settings.
  $cwd = getcwd();
  $env = array();
  // Create the process.
  $process = proc_open($command, $descriptorspec, $pipes, $cwd, $env);
  // Verify that the process was created successfully.
  if (is_resource($process)) {
    // Write the text to stdin.
    fwrite($pipes[0], $text);
    fclose($pipes[0]);
    // Get stdout stream content.
    $text_converted = stream_get_contents($pipes[1]);
    fclose($pipes[1]);
    // Close the process.
    $return_value = proc_close($process);
    // A valid response was returned.
    if ($text_converted) {
      return $text_converted;
    }
    // Invalid response returned.
    return FALSE;
  }
}

We've written a barebones module around that function that makes our conversions much easier. It has a basic administration page that accepts from and to formats, as well as the node type to act upon. It will then run that conversion on the Body field of every node of that type. It should be noted that this module makes no attempt to adjust the input format settings or to ensure that the modules required for parsing the new/old format are even installed on the site. So treat this module as a migration tool, not a seamless production ready solution!

Pandoc has quite a few features and options, so check out the documentation to see how it will best help you. You can also see the powers of Pandoc in action with this online demo. Let us know if you use our module and as always, test any text conversions in a development environment before doing so on a live site! Please note: CHROMATIC nor myself bear any liability for this module's usage.

How to Organize Drupal Features, Reduce Merge Conflicts, and Stay Sane

gus — Thu, 20 Feb 2014 16:59:51 +0000

Features play a significant role in any major Drupal 6 or 7 project. The organization of features is often overlooked, but becomes important as a project grows. Agreeing on an effective organization strategy avoids headaches and reduces merge conflicts. After experiencing just about every strategy on projects of all sizes, we’d love to share what works best for us.

Why is feature organization significant?

The Features project page defines a feature as a collection of reusable components. After all, a feature is a module. A majority of features, however, are only created to get configuration into code. This is understandable, but it remains important to build each feature with a modular approach. It doesn’t matter if there is any intention to reuse them on another project.

What does the opposite approach look like? One feature for each category of component: a Content Types feature, a Views feature, a Strongarm feature, and so on. A developer can update every feature after each round of development and commit their work. Life is good.

This approach becomes a problem as more developers join a project. Each developer can be working on a separate section of the site, but they all must push their Views and Content Types to the same features. Nasty merge conflicts surface. Spider webs of interdependency between features form. A few always report as Overridden no matter how many times they’re updated. Not to mention, the Content Types feature is now huge and that page takes five minutes to load before anything can be added to it.

There has to be a better way.

Creating modular features: how and why?

A modular approach involves basing each feature on a major content type or specific section of the site. Each feature should include relevant content types, views, contexts, panel pages, variables, contrib dependencies, image styles, taxonomy vocabularies, javascript files, hook implementations, and so on. A basic News feature may contain the Article content type, the Recent News view, and the context that adds it to a page.

This may create a larger number of smaller modules, but the tradeoff in maintainability is worth it. Dodging merge conflicts and unmanageable interdependencies is a huge benefit. So is the next developer knowing where to find the preprocess function that alters the Article’s teaser view mode. More on that later.

One size never fits all

What if more than one feature uses a single field base (when reusing fields), image style, view, or bit of custom code? Don’t just pick one feature to add it in. Don’t copy and paste the custom code across both. Instead, try creating a separate, shared feature and list it as a dependency by those that use it.

Some components just don’t belong in the modular features we’ve described above. Menus, menu items, user roles, permissions (debatable), and text/date formats are good examples. Creating one or more site-wide features for these elements can prevent a lot of confusion. Custom code used by most features belongs here as well.

We also like creating a custom Developer feature to store all development-related configuration. All modules that are never enabled on production get listed as a dependency on the Developer feature. This includes modules like Views UI, Fields UI, and Devel. A development environment is ready to go after enabling one module and production stays lean.

A feature is just another custom module

Once upon a time, we kept exported configuration in our features and all custom code in separate custom modules. That is, until we realized we could just add our custom code to the .module files of the relevant feature. We started adding our own include files and javascript files, too. That preprocess function we mentioned earlier can now live in the same module as the exported content type. Don’t worry, these custom pieces aren’t overwritten or lost when updating the feature.

A few more bits worth mentioning

This is less important, but a debatable topic is where to keep features within the modules folder structure. A common approach is to have three directories: contrib, custom, and features. We tend to combine the latter two. A custom module can become a feature with one line of code and with so much custom code in our features, we see little reason to separate them.

Another quick lesson to learn is to add a prefix to all feature names. Find initials or a short version of your site’s name and add it to the module’s machine (xyz_news) and readable (XYZ News) names. This will avoid conflicts with any contrib modules that have the same name.

Finally, no approach will be successful without developers paying attention when updating features. Features is usually aware of what shouldn’t get added, but it isn’t unusual for something to sneak in where it doesn’t belong. To combat this when staging commits, we use a git GUI like Tower or git add -p when working from the command line. This requires deciphering features code, but blind commits can unwind any organization in seconds.

Features: A necessary evil

Drupal 8’s configuration management system will replace the need to export configuration with Features. Until then, Features is a necessary evil and staying organized can help developers stay sane. The organization strategy and other ideas we’ve shared value modularity and avoid merge conflicts. We were fortunate to learn many of these ideas while working with the wonderful folks at Lullabot. We’d love to hear about strategies you’ve found success with or any ideas to improve ours!

Gotchas to Look Out for When Inheriting a Drupal Site

chris — Fri, 07 Feb 2014 17:14:19 +0000

We’ve recently attracted new clients that came with Drupal sites already in tow. New clients is always a good thing, especially when they come with a fondness for Drupal, but it isn’t all peaches and cream. We’ve found the transition hasn’t always been as smooth as we’d expect. Here’s a list of some common gotchas to look out for when inheriting a Drupal site from another developer or Drupal shop.

Before quoting new functionality, upgrades, etc. ask to review the codebase directly

There’s no substitute for actually digging in and directly reviewing the codebase. We strongly recommend doing this before estimating any new features, upgrades, or maintenance. Skipping this can come back to bite you later when a feature that would normally take you one hour takes seven because the previous developer hacked something to bits or built something untenable. Additionally, you’ll see right off the bat whether of not the previous shop followed Drupal best practices regarding code standards, where things should live, etc. This information will speak volumes about what you’re getting yourself into.

Hacked Core?! Hacked Contrib?! GRRRRRRR!

If you are able to get your hands on the codebase and a working copy of the site, do yourself a favor and install and run the Hacked module. This little gem will compare the existing core and contrib modules against their unhacked/pure counterparts. After running this, you’ll see any and everywhere that has been hacked by the previous dev team. Hopefully, this reports that nothing has been hacked. If anything has been hacked, be sure to adjust your estimates accordingly and do some CYA by alerting the client.

Is the site version controlled? Preferably in Git?

All projects should be using version control. The information that a commit log offers is invaluable when inheriting a site. Assuming the commit messages are quality and concise, you can quickly gather an understanding of how the project and code grew to its current state. When debugging, troubleshooting, or otherwise trying to grok how the last dev set things up, git blame is priceless. If the project you’re inheriting isn’t version controlled, consider making it a requirement moving forward with your new client. This is a requirement we rigidly enforce on all of our engagements.

Hosting, SSH Access and Drush

A firm understanding of the existing hosting situation is crucial. We try to have this conversation as soon as possible to get everyone on the same page. If the existing site is hosted on cheap shared hosting without proper SSH access, we try to fix that right away. Gone are the days of FTP deployments and manual database changes. These methods are slow, painful, and risky. This is why we make it a requirement that if we’re to be responsible for deployments to production, we must have SSH access with Drush and Git installed.

Features?

Is the site you’re taking over not using Features to manage configuration in code? Or, if it is using Features, are they overridden? Either of these scenarios are a definite red flag. The last thing you want is to deploy a bunch of fancy new code and accidentally revert features that were previously overridden! When we inherit a site like this, the first thing we do is get all of the features modules to a default state on a dev or staging environment. This way, everyone on our team can be sure they aren’t breaking things on their next features revert via Drush. drush fra -y FTW!

Basic Drupal features being overridden by custom code, modules

This one bit us just the other day. The site we inherited was (seemingly) using the basic search that comes with core. The client was trying to adjust the weight/priority of certain node types in the search and wasn’t able to achieve the results they were looking for. After hours of digging and lot’s of head scratching, we realized the default search page was being overridden by a custom view. DOH! The tricky part here is that there was nothing obvious about this on the default search admin panel. If it were us, we would’ve set some alert on that page to remind users that those settings would not be respected.

Panels vs. Context?

Panels and Context are both great modules…. err… solutions to the page building problem. Chances are the site you’re inheriting is using one or both of these modules. Some site builders are rabid about one tool being better than the other. Here at CHROMATIC we use Context more often than not. It isn’t a deal breaker for us, but it is definitely something to consider when taking on an existing Drupal site. Run for the hills if the site is still using the default block admin panel from D6!

Is the site running Pressflow or another Drupal distribution?

In some cases, you might be taking over a Drupal 6 site that is running Pressflow. This is crucial because it will determine how, when you update Drupal core. If the previous developer used Pressflow, you’d hope it was for a good/obvious reason but we’ve found instances where it wasn’t obvious at first glance. Keep an eye out for this one.

Keep these gotchas in mind next time you inherit a Drupal site. It could save you loads of time and frustration! Leave us your favorite (or not so favorite) gotchas in the comments below. Happy Drupaling!

How to Implement a Content First Workflow

adam — Tue, 14 Jan 2014 16:52:54 +0000

In college I once had an art history class immediately after a class devoted entirely to databases. At the beginning of the semester I thought they couldn’t have less in common, but soon enough I’d realized the combination taught me an important lesson in the web design process: Content precedes design.

Wait. Don’t mockups come first when redesigning a website? We may first pay homage to sketches and wireframes, but clearly mockups come before content. Right? If that’s how your team works, you are not alone. We once worked this way, but haven’t looked back since making the switch. Here are a few articles that state the case for content before design in ways much more elegant than I ever could:

To those of you freshly converted: welcome to the light! To those not converted yet: please reread the articles.

After joining the party, the reality of actually implementing a paradigm shift in your workflow starts to set in. You may ask, “what this will look like for us internally? How are we ever going to lead our clients through the dark without mockups to sign off on?” As with any change, it will require a lot of education to change your workflow internally, as well as expectations from clients who have come to expect the mockup first workflow. Let me tell you how we have handled the transition and hopefully we can help make it easier for you!

Content Audit

First, a content strategist needs to revisit the client’s mission statements, core values, and business goals. Working with the client, they should walk away with the underlying goals and purpose of the website. Without those, we might as well ditch the website, go back to 1999, and put up a Geocities page.

Next comes a full review of all content on the client’s current site (if it exists). It’s important they don’t just rearrange or document the mess that may currently exist. Instead they dig in and try to fully understand what needs to stay, what can be removed, and what needs to be added. I can’t over emphasize the importance of this step. It may seem laborious, but without a solid foundation and understanding of what a website needs to accomplish, everything else is a waste of time.

Content Modeling

Now that you fully understand what you are trying to build, it’s time to begin choosing materials. When doing so, it is important to remember we are trying to not just change our workflow, but also educate the client on this entirely new way of thinking about the content on their website. We often try to destroy the mental model of a “web page” that the client has and replace it with the idea of a node, entity, model, data type, or whatever you want to call it. I’m going to stick with “node”, as we happen to be Drupal fans around here.

We try to avoid Drupal-specific jargon, but we explain the basic concepts of nodes, blocks, views, etc. just enough to get us both using a similar vocabulary. They don’t need to become data architects, but it’s handy if they understand the building blocks enough to imagine solutions to problems on their own. Combining this understand with the treasure trove of institutional knowledge they undoubtably hold puts you well on your way to helping them solve both their existing problems and problems they never knew they had. This makes you look like a genius.

Now that you are speaking the same language, it makes building your data structures much easier. As with most things, there are several way to approach this process. I’m going to run through several of the options that we have either used or tested. There is no one size fits all solution, so it may take some experimenting to figure out what works best for your client’s needs and technical aptitude.

Google Drive Documents

Let’s clear the air and establish that passing around a file made by everyone’s favorite word processing program will not suffice. Having a file named contentStructures6_2-1_final_actual-final-tomorrow.doc is not a solution. You wouldn’t pass around your code without proper version control, so why let the blueprints to your website be passed around without similar controls? Now that we’ve cleared that up, let’s examine the following example of a Service content type that we created for a Library’s new website.

Service

Description
- Used for entering each service and policies/details specific to each service.
Examples
- InterLibrary Loans
- Copying, Printing, Scanning
- Research Help
- Reserves
- Ask a librarian
Fields
- Title
- [FAQ]
  - show all FAQ nodes that reference this Service
- [Resource]
  - show all Resource nodes that reference this Service
- Image
- Description
- Link
- Policy

It would be easy to just skip the Description and Example sections of the content type definition, but we have found them to be extremely valuable. Description forces you to put words to how you see a content type being used, which can then by challenged or reaffirmed by the client. The same goes for Examples. It allows you and the client to have concrete examples of representative nodes of this content type. We have found it useful to put items here that you are unsure about, as then the client will see your assumptions that may be incorrect and point them out sooner than later. This often results in an item being moved to a different content type or even the creation of a new content type.

Google Drive Spreadsheets

Another similar but more structured approach is to use a Google Drive spreadsheet to map out your content types. You can follow the same principles, but with a slightly more structured format. Palantir has an excellent article titled Developing Drupal sites: Plan or Perish where they link to their spreadsheet that they use for this process. If you decide to go this route, Lullabot has created Checksheet, which is a handy tool for monitoring the synchronization of this spreadsheet and your Drupal installation.

Content Creation

Once you’ve fully defined your data structure with the help of your clients, it’s time to ask them to restructure their existing content to fit the new model. This can be done in a document (Google Drive!), a bare bones Drupal installation with not-yet-attractive node forms, or the tool of your choice. The idea is to make it as easy as possible to get into Drupal (or the CMS of choice) once they’re finished. One tool that we’ve looked at is GatherContent, which allows you to create data models, import/create/edit content, and export it to a variety of popular CMSs (including Drupal).

Content Migration

Once we have our content types built and our content gathered, we can begin bringing it into Drupal. This is also a good time to discuss permissions and workflow for content moderation on the site. If you don’t bring it up now, those issues will quickly surface anyway. While you are running migration scripts or your client is manually copying and pasting content over (since their was no previous semblance of structured data), you will quickly begin finding edge cases and discrepancies that your idealized models may not have accounted for. No problem. You can easily change your models and no time was wasted on designs that need to be trashed, as you haven’t even started those yet, right?

We’ll admit, it’s often unrealistic or impossible to expect a client to get 100% of their content imported before you write one line of CSS. There is no magic number or percentage of content to have imported, but we’ve found that more is better. Those last items to make it in often contain some of the worst edge cases that love to derail project timelines and budgets, causing less than ideal fixes to be made to otherwise impeccable code.

Are We There Yet!? (Design)

With most of the content in, it’s much easier to begin building wireframes and quickly transition to the browser, using a solid base theme to get your site to a functional state. This setup (along with some basic responsive styles) also makes the wireframing process much easier, as the client will quickly begin to understand that their content is fluid and modular rather than pixels in a mockup.

It’s safe to say that both you and the client will begin to see the problems that the design will give us the opportunity to solve. This puts these popular quotes into context:

“I’ve been amazed at how often those outside the discipline of design assume that what designers do is decoration—likely because so much bad design simply is decoration. Good design isn’t. Good design is problem solving.”
– The Art & Science of Web Design by Jeffrey Veen

“Lets change the phrase, ‘designing’ in the browser” to ‘deciding in the browser.’”
– Daniel Mall

The Devil is in the Details

When content comes first you are putting the client into the driver seat from the very beginning. This provides a few benefits. It quickly shows you how engaged they are going to be and brings potential issues to light much earlier in the process (saving tons of time later on). This ensures that development isn’t delayed midway as you await the import and creation of content, a process which you can’t fully control. So as you are building contracts and setting deliverables and deadlines, keep that in mind so that expectations can be managed on both sides. This keeps everyone happy!

We have found that clients can be hesitant to sign off on wireframes and/or designs that constantly evolve, as they have been trained to view these deliverables as binding documents that define scope and functionality. Of course, a line has to be drawn that prevents scope creep, but it is important that clients be educated on the effort and process required to pull off a successful responsive design. As developers and designers, we should be aware of how iterative this process this can be and it is our job to educate our client about this.

Below is a rough approximation of how this looks for us. As always, things change from project to project and nothing is set in stone, but hopefully this helps you visualize how this process works.

Take Aways

We clearly have a lot to learn about this new workflow and our clients are no different. It is our job to educate them as we go. Not only does it help them become a more informed and engaged partner, it helps them understand timelines and budgets and improves the final product. This makes you both look good, a win-win situation. So don’t stop making wireframes and mockups, just wake up early enough to go to your database class first!

Leave us a comment and let us know how these techniques have/haven’t worked for you and any similar techniques you have tried to implement!

Additional Resources

Eric Rice

admin — Mon, 16 Dec 2013 02:44:41 +0000

Eric Rice

Applied Motion Products

I was fortunate to find such a talented group of designers and programmers in CHROMATIC. We embarked on a significant undertaking to completely revamp our website. We not only needed a clean, fresh, and professional new look to our site, but we needed some serious functionality in terms of improved tools for finding and comparing our products, displaying related and recommended products, searching our product database, archiving legacy products, and much more. CHROMATIC came through on every facet of the project, from initial concept all the way through to the launch of the site. They showed an excellent ability to understand our functional and aesthetic needs very quickly, and then translate those needs into beautiful looking web pages.

In short, we asked and they delivered, over and over again. And on top of everything, they’re just a great group of people to work with. I can’t say enough good things about them.

Display:

Featured on Home page

Don't just be a vendor, be a partner!

dave — Mon, 21 Oct 2013 17:42:00 +0000

ven·dor noun \ˈven-dər

a person who sells things especially on the street
a business that sells a particular type of product

part·ner noun \ˈpärt-nər

someone’s husband or wife or the person someone has sexual relations with
one of two or more people, businesses, etc., that work together or do business together
someone who participates in an activity or game with another person

In the web design/development/consulting world (and many others), we consistently talk about vendors and the client/vendor relationship. Accounting software uses the terms customers and vendors as well. Is this really how we want to be known? Is this really how we work? And as a client, do you really just want a vendor?

Vending Machines, and what you can get out of them

Most people are familiar with vending machines. Today you can find vending machines for a LOT of different items. The most common things we see in vending machines are soda/pop/soda-pop (for our diverse audience, I wanted to cover you all), chips and candy. The concept is pretty simple really, you put in some money, bills, coins, or credit and press a button or two and out comes whatever you wanted. Well, whatever was available that you settled on.

Unfortunately the vending machine really only works if you have a very specific product. A bottle of Diet Coke, a can of Sprite, a bag of Reese’s Pieces, all of which may or may not be exactly what you were looking for when you approached the machine. Regardless, you take it because it is close enough to whatever drove you to the machine to begin with; thirst, hunger, need for some headphones, etc.

Take a step back and look around at the number of ‘vending machines’ you use every day; the grocery store, the car dealership, Amazon.com, the gas station, Binny’s Beverage Depot and the list could go on forever. You go to these places to get product X, Y or Z and nothing more.

The more I’ve thought about this concept, the more I hate the idea of CHROMATIC being called a vendor!

Website Vending Machines, they do exist

Unfortunately (or fortunately) website vending machines do exist in the market today. For the most part, they are great, but the misconceptions that spill over into our industry are sometime hard to deal with.

Squarespace (http://www.squarespace.com/)
Shopify (http://www.shopify.com/)
Weebly (http://www.weebly.com/)
Facebook (do you really need a link?)

There are hundreds more, but above list are a few of the website vending machines out there. The products dispensed can be exactly what someone needs, but they create a sense that all web design/development/consult is an off the shelf solution / product that can neatly fit into a row and column within a vending machine. Sometimes it can be hard to explain why that isn’t the case.

These vending machines and their products are not evil, and they have place in the market. Even my wife’s website wasn’t built with Drupal and was dispensed from one of the vending machines listed above.

The problem: vending machines just vend

So why do I think the classification vendor is bad? Because that is all they do: vend. A vending machine doesn’t tell you why you might not want to have that third Diet Coke today (Google: caffeine+aspartame) or suggest a healthier alternative, the vending machine just takes your $1.25 and gives you the Diet Coke.

A doctor, lawyer or mechanic are not vendors, and you wouldn’t ever want them to be. If you went to a lawyer and said ‘I want to start a company, give me the “new company product”’ and if the lawyer didn’t say ‘What are you planning to do?’ and just gave you the ‘Main Street Bakery’ company product that probably wouldn’t be what you need or want.

See where I am going with this?

Partners are better than Vendors

In a sense, I don’t think that I need to argue the cause for partners over vendors. But what I think may be helpful is to highlight what you should be getting out of your partnerships (strictly in the professional world).

Partnerships are two ways! Each person or company in the relationship should get something out of the partnership, and that something really needs to be valuable. The value could be financial (getting paid to do the work), the value could be new ideas for your company (getting what you paid for), website or brand, the value could be top tier Drupal development (getting what CHROMATIC delivers). Or it could be something as simple a partner that is always there, always on time and always professional, something that has a value beyond the money (another thing that CHROMATIC delivers).
Partnerships are long term. The goal of a vending machine is to dispense a product and be done. The goal of a partner is to deliver a product with the other partner and grow it, raise it, and nurture it. The success of each partner is impacted by working together over the long haul. The longer a partnership lasts the more intimately the partners can know each other and the better quality work together becomes.
Partnerships are complimentary. Partners should play off of each others strengths. This doesn’t mean that each partner can’t have similar strengths, but where one is weak the other should compliment them with strengths. Within CHROMATIC, Chris will always be a better developer than me and I’m happy about that, I balance him out in other areas.
Partnerships aren’t exclusive, but should be respectful. This point is a bit tougher to explain, but the point is simple, don’t be a partner with two competing organizations in the same industry. There is a lot of grey area around around this and it should be evaluated on a case by case basis. A good example for CHROMATIC would be our partner ATI, we wouldn’t take on a project with Athletico (their direct and exact competitor).

Why you should find a partner for a website

Perhaps I’ve already made the point clear, but a successful website is pretty hard to find in a vending machine. We get calls and contacts all the time that start out the same way: “I need a website.” If we were a vending machine, we’d be able to respond instantly with, “Ok, it will cost $1000 and it will be done on Tuesday,” but no one would be happy with the product they received. This is a website, but my guess is that anyone who says to CHROMATIC, “I need a website,” is looking for something more than that (pun intended!).

This is where CHROMATIC acting as a partner and NOT a vendor really matters. As a partner, the response becomes, “What are you expecting the website to do for your business? Do you currently have a website that you are looking to improve or are you starting from scratch? Do you have specific goals that you’d like to achieve with your website? Have you considered mobile access to your website, if not here is why you should.”, etc. etc. The list (discussion) can go on for hours. This is why we never give a cost on the first call (more on this in a future post), there is no way to know what someone is looking for right off the bat. By establishing a partnership, we are able to provide a better recommendation for both partners, ourselves included.

I hope this makes sense and that you think about this as you look for a partner!

Thoughts? Leave a comment to further the discussion.

Interested in being a Partner with CHROMATIC? Reach us on the Contact page.

CHROMATIC Cares: Giving Back and the Operation Amazon Site Launch

matt — Tue, 09 Jul 2013 16:35:29 +0000

We recently donated our time and expertise to plan, build, and launch a responsive Drupal website for the non-profit organization Operation Amazon. In conjunction with that launch, we’ve created a new section on our website called CHROMATIC Cares, which we will use to convey the many ways that we, both individually and collectively, are giving back, and why we think giving back is so important.

Operation Amazon

Operation Amazon is a unique humanitarian organization with a mission to provide clean water to people in the remote villages of the Amazon by engineering, delivering, and installing life-changing water filters in their homes and villages. These filters make simple, low cost, healthy water a reality.

Responsive website redesign with Drupal and Ubercart

Desktop breakpoint of Operation Amazon’s responsive website

Tablet and Mobile breakpoints of Operation Amazon’s responsive website

During the process, we worked with Operation Amazon’s board to redesign a more modern and usable responsive website (optimized for mobile, tablet, and desktop screens). Additionally, in order to accommodate functional requirements of the site vital to the future growth of the organization, we moved from WordPress to Drupal. Doing so allowed us to build many important features, such as:

An easily manageable interactive map which plots all of the locations where the Operation Amazon filters have been delivered and installed.
Using Ubercart, we created a more flexible and functional site donation system with support for recurring monthly donations. Note: WordPress also has this capability, but it was not used on Operation Amazon’s previous WordPress site.
A more capable content management system (thank you Drupal!) making it extremely easy for the Operation Amazon team to manage their website and grow their organization.

If you have a second, stop by the Operation Amazon website and see if it’s a cause that you’d like to support.

Giving back: what it means for us and why we do it

Since CHROMATIC started, we have made it a priority to give back. It is through our charitable contributions of time, money, and professional expertise to our team’s individual and collective passions that we’re able to feel like we’re doing our part in helping to improve society and the world as a whole. In addition, giving back provides us with an opportunity to express through action our appreciation for the opportunities that we’ve been so fortunate to experience over the years both at CHROMATIC and in life in general.

Aside from lending our time and professional expertise towards building the Operation Amazon website, we’ve also assisted other organizations and supported other causes. In addition, we’ve made it a priority to give back to Drupal and the Drupal community. To read more specific examples about how we’re giving back, visit our CHROMATIC Cares page.

Operation Amazon

adam — Wed, 26 Jun 2013 20:14:12 +0000

http://www.operationamazon.org/

Operation Amazon's mission is to provide clean water to people in the remote villages of the Amazon by constructing, delivering, and installing life-changing water filters in their homes and villages.

Our contribution to Operation Amazon:

Website Redesign

We worked with Operation Amazon's board to redesign a fresher, more modern, more usable website user interface. In addition, to accommodate specific functional requirements of the site, we moved from WordPress to Drupal. In doing so, we were able to build important functional components and provide an easily manageable website, giving OA the necessary tools to grow their organization through the Internet.

Drupal Teaching and Promotion

adam — Wed, 26 Jun 2013 20:12:27 +0000

http://www.drupal.org/

We're interested in giving back to the community by donating our time and knowledge through teaching about, speaking about, and promoting Drupal.

Ways we spread the word about Drupal:

Teaching & Speaking

We've taught classes and given speeches extolling Drupal and its many benefits. If you're interested in having us teach or speak about Drupal, then please contact us.

Promotion

Whether we're speaking with prospective clients or writing a Drupal-related blog post, we're big on spreading the word about Drupal to anyone interested in listening.