Balance Blog

May 19, 2012
Posted by Carrie Hane Dennison | in Web Content | Comments (2)

I am fortunate to have just returned from the 2012 edition of Confab– The Content Strategy Conference. At times it was hard to choose between the sessions, but luckily there were plenty of tweets (#confab12) coming out of all the sessions to get good nuggets from them all.

The main theme in the new and fast-growing field of content strategy is to start small, prove success, and grow from there. This applies whether you are an agency trying to sell content strategy as a service or in-house trying to get buy-in for content strategy. Two other themes were strong throughout: governance and structured content.

Start Small, Claim Success

Shelly Bowen talked about the "Magic Layer" – when company needs and audience needs come together in the form of clear communication, discovery, and shared goals. When this happens, you get more connections, more opportunities, meaningful experiences, and partnerships.

Colleen Jones continued this theme with discussion of the science of content strategy. She sent a message to the rest of the world: You are throwing away money if you are spending more on design and development than on content. The digital universe thrives on content. The options to communicate are greater than ever before. Therefore, you have to find a way to break through with content that sells, describes, is findable, and educates. Bottom line is that our ability to deliver the right content to the right people at the right time is greater now than ever before.

One problem many of us face is selling content strategy as a service. Melissa Rach of Brain Traffic (with the help of Johnny Cash) helped us understand that content strategy is in essence decision making and discussion making is hard, scary, and not cheap. People go for what is familiar and safe. So we content strategy advocates need to use numbers to reduce the uncertainty. This means we need to sell and scope in ways that business people understand. The basic formula for putting dollar amounts on a service like content strategy is

Value = Benefits – Cost

It wouldn't be a complete conference about content strategy without bringing context into the picture. Danial Eizans used neuroscience to help us understand what is going on in people's brains when they use the Internet. Context leads to engagement. It can be self-directed, situational or preferential. And when users achieve success, they are satisfied. When that satisfaction is aligned with business objectives, everyone wins.

Structured Content

We can't continue to think about "web pages" but about content that is delivered to multiple types of devices and through various channels in different circumstances. Usually this need is realized when an organization has to go digital or try to meet a mobile need.

Mark Stahura of Augsburg Fortress Publishers presented a case study of how his company literally turned a stack of paper books and documents into a one-stop, digital location for resources for the Lutheran Church. The solution was to break down the information into useable pieces. This was achieved with a combination of basic structure through workflow and applying metadata to content. Using metadata and tagging, you can "train" your content to be valuable to the end user.

Karen McGrane finished the conference with an inspiring talk about adaptive content. We can use mobile as a wedge. It is waking people up to see that content has multiple sizes and meaningful metadata and needs to be written for reuse. When this comes together, structure is expressed through styling. Because of this, content people need to work more closely with designers to make things happen. We need to think about how we are in the content publishing business, one in which we can account for all devices, even those not invented yet.

Governance, Governance, Governance

Content strategy does no good if you don't keep it up. Ann Rockley summed it up best when she said that companies are happy to pay for a new website over and over, but they are not willing to pay a little extra to do it right the first time. Why? Because doing it right is hard. Governance defines who does what, when, why, and how. It needs ongoing resources and attention. She used the garden analogy to help others understand content and governance. If you plant a garden in the spring, it looks really nice for a little while. But if you don't water it or weed it, soon it is overgrown and ugly. Same thing happens on a website.

Perhaps one of the best presentations was on specific governance of Voice and Tone by Kate Kiefer Lee at MailChimp. Content doesn't just make people do things, it makes them feel things. So finding your voice is critical. But also mind your tone. Think of dogs and babies – they don't understand what you say, but they understand your tone and react accordingly. And always be honest. If you voice or tone are false, users will see through it.

Erin Kissane forced us to think beyond today. Her message: Be a raccoon. Steal whatever you can. Charles Eames was right when he said, "Innovate as a last resort." There are always new problems, but there are not always new solutions. There are other fields of study we can borrow/steal from, there are new uses for old tools.

My favorite was the call to arms for all content people to LEARN CODE. Yes, we need to take a step back into the stone age of web development when everyone had to know some code to create a web page. We're coming back around to that (see structured content, minus the WYSIWYG), so break out that old tool and sharpen it up!

May 16, 2012
Posted by Krystee Dryer | in CMS, in Technical Consulting, in Web Development | Comments (0)

One of the biggest criticisms of using Drupal is that most of the code is kept in the database. This inherent structure makes version control a nightmare. Luckily, the Features and Strongarm Modules have come to the rescue.

The Features module allows us to “package” the exportable pieces like content types, views, panels, menus, etc in code form and creates each into its own module. Strongarm extends this to the variable table as well. Features and Strongarm together give us the ability to have version control on all of these elements that previously resided only in the database.

This is a really great for most items, but we started running into an issue with content and menus. In our server setup, we had Dev, Staging, and Production servers. All development was done on our local machines and then when done, pushed up to the Dev server. It was tested and then pushed up to Staging for final testing. After all testing was completed, it was finally pushed to Production.

However, all content was entered on Staging and then pushed to Production (not on Dev). We couldn’t use the Drupal menu system effectively since the content really didn’t appear on Dev unless we pushed the database down to Dev (which we do occasionally). Since Drupal menus want node IDs and the actually content nodes were not located on Dev, we ran into an issue with bundling our menus with other features. When we pushed the whole feature up to staging, the menus located on Dev didn’t play well in Staging, and we had to do some workarounds.

To make things easier, we decided to bundle our features as follows:

  • Content type – naming convention: contenttype_name (ex. contenttype_pressrelease). The content types will have all pieces of the content type, permissions, contexts, input formats, variables, and image styles.
  • Primary Section – naming convention: section_primename (such as section_pressroom) – All views, contexts, blocks, panels, image styles, permissions, variables, and dependencies for that section or landing page.
  • Secondary Section (and below)– naming convention: section_primename_secname (such as section_pressroom_pressreleases – All views, context, blocks, panels, image styles, permissions, variables, and dependencies for those secondary and below sections.
  • Menus – naming convention: menu_menuname (such as menu_main) – Each menu has its own feature.
  • Views – naming convention: views_viewsname (such as views_homecallout) – Miscellaneous views that didn’t belong in other places, were bundled in their own feature.
  • System – naming convention: system_name (such as system_sitewide). – All contexts, variables, permissions, etc for sitewide or other system level pages.

Most of this is a pretty normal way of using Features, but the main difference is that we decided to pull out menus from other features so we can keep them separated. Using this method allowed us to push changes to the Staging server without moving the menus with them. The developers left menus pretty much alone unless we move the database to Dev as well.

May 14, 2012
Posted by Rosemary Sallee | in Web Trends | Comments (0)

We've heard about “PCI Compliance,” but what does that mean to your organization?  Here are a list of questions to get you started thinking about how your organization can assess and address PCI Compliance issues.  PCI-DSS refers to Payment Card Industry Data Security Standard, in short, this is the set of standards by which credit card companies evaluate the security of ecommerce operations on the Internet.

Q: Do PCI standards apply to our organization?
A: PCI applies to ALL organizations or merchants--regardless of size or number of transactions--that accept, transmit or store any cardholder data.  Thinking about it another way, if any customer of that organization ever pays for anything using a credit card or debit card, then the PCI DSS requirements apply.

Q:  If my company is not compliant, are we breaking the law? 

A:  No, but there could be other serious and unpleasant business consequences – litigation, fines, etc – if any customers are harmed by the theft or loss of data on your web site.

Q:  We have an SSL – or we use a third-party payment processor such as PayPal.  Are we automatically compliant? 
A:  Not necessarily.  To achieve PCI compliance, your organization needs to address how data is handled both on- and offline.  Here is a list of the goals and requirements: 

Goal:  Build and Maintain a Secure Network
1. Install and maintain a firewall configuration to protect cardholder data
2. Do not use vendor-supplied defaults for system passwords and other security parameters

Goal:  Protect Cardholder Data
3. Protect stored cardholder data
4. Encrypt transmission of cardholder data across open, public networks

Goal:  Maintain a Vulnerability Management Program
5. Use and regularly update anti-virus software on all systems commonly affected by malware
6. Develop and maintain secure systems and applications

Goal:  Implement Strong Access Control Measures
7. Restrict access to cardholder data by business need-to-know
8. Assign a unique ID to each person with computer access
9. Restrict physical access to cardholder data

Goal:  Regularly Monitor and Test Networks
10. Track and monitor all access to network resources and cardholder data
11. Regularly test security systems and processes

Goal:  Maintain an Information Security Policy
12. Maintain a policy that addresses information security

Q:  Sensitive data – what is it?
A: Not all the data that appears on a credit card is considered sensitive.  Anything on the back side of a card, including the security code or CID, must not be stored.  Any data that IS stored must be for a good business reason, and that data must be protected.  Here is a great visual of the data you need to be most concerned with:

How to get started?  Go to Self-assessment questionnaire:

The PCI Security Standards Council is an open forum, launched in 2006, that is responsible for the development, management, education, and awareness of PCI Security issues.  The website has a questionnaire that can help you evaluate whether your organization is PCI compliant, and what you may need to do to help move toward that goal. 

May 4, 2012
Posted by Krystee Dryer | in CMS, in Web Development | Comments (0)

Most of our website redesign projects entail some level of integration with an a third-party system, and usually in our projects this is an association management system (AMS). These integrations differ in scope and requirements, but always follow the same process on the development side. Our development plan for the integration follows the outlined steps.


To determine the scope and budget of the integration, we ask these questions:

  • Will there be one login form to authenticate both systems (i.e. single sign on)?
  • What roles will users be assigned in the CMS and AMS?
  • Are there other types of groups or membership types that have special functionality? 
  • Will users be able to edit their profile?
  • Will users be able to sign up for or renew their memberships online?
  • Will there be online event registration?
  • Will there be e-commerce functionality (shopping cart, payment processors, etc)?
  • Will the CMS have role-oriented content?

Once the questions are answered – and we know exactly what needs to be integrated – we research our integration options.

Integration Options

The integration options largely depend on the APIs from the third-party system and the access options to the system: 

  • Does the CMS have an existing module/plugin available for the AMS integration?
  • Is there a web service available?
  • Are we authenticating against a remote database?
  • What other options are available for single sign on?
  • Is there a development installation of the AMS for testing purposes?

Authentication Scenarios

Based on the scope and options available for the integration, we then decide how a user will connect.

  • Will the user login to the CMS (which will authenticate against the AMS and return with the necessary information to the CMS) or will the user login to the AMS (and then add login token to their user session in the CMS)?
  • How do we provide the reverse authentication scenario if the login is performed in a non-standard way?
  • What information is available to the CMS (from the AMS) to use for personalization?

Build and Test

Once all of the decisions have been made, we develop our user stories to cover all scenarios of user interaction between the CMS and AMS. Those user stories are used in our build phase and translated into our testing plan with test users to fit each story. Once build is done for each user story, our QA team tests each scenario and reports findings and any issues found.

Single sign on can be simple or complex, but using this plan makes it very organized to build, easy to test, and provides our clients with a functional single sign on process to fit their needs and budget.