Growing Venture Solutions - GVS - Planet Drupal

GVS, Drupal Scout, acquired by industry leader Acquia

Team GVS — Tue, 16 Aug 2011 20:02:10 +0000

We're excited to announce that Growing Venture Solutions and Drupal Scout have been acquired by Acquia. As a leading provider of cloud and support services for Drupal, it was clear that Acquia provides a unique complement of infrastructure and scalability to Drupal Scout. Following discussions about how best to work together, we decided to join the Acquia team. As a result, several GVS brands and the core GVS team are now part of Acquia. We are really excited for this opportunity.

Plans for GVS brands

In addition to the expert Drupal consulting, security training, security review services that we'll be taking to Acquia, GVS has several spinoff brands, many—but not all—of which are now part of Acquia.

Mastering Drupal: screencasts and e-books for learning Drupal. The Mastering Drupal brand and content are a great complement to the existing Acquia Library and Acquia training
UseCOD.com: Branding for the Conference Organizing Distribution. COD will remain a community distribution, and Ezra plans to continue as the project's maintainer. Moving the brand lets us put more marketing muscle behind it for increasing adoption of the platform and Drupal. We've got more details about the future of COD on that site's blog.

In contrast to those projects/brands:

Certified to Rock will remain an independent project. We are working to establish a broad team of Drupal community members to manage the service. The current CTR team will continue to play a big role in the project. If you are interested in helping to run CTR, read more about the CTR groupie program.

Plans for GVS team

The core GVS team will be joining Acquia.

Greg and Ben will help grow Acquia's security offerings, with Greg as the Director of Security Services and Ben as a Senior Engineer focusing on products for Drupal security.
Ezra is bringing his experience as a distribution maintainer to the Acquia Commons distribution, where he'll be working as a Senior Engineer.
Continuing her focus on user experience, Lisa will be working on a range of Acquia products as a Usability Specialist.
Instead of joining the rest of the team at Acquia, Carl will continue to work as an independent consultant and trainer in the Denver area.

We're so grateful to our clients and to the amazing Drupal community who helped to make this possible!

For now we will all be staying in the same locations. You can expect to see us at events in New York and Colorado just like always.

As individuals we may make the time to blog about why we joined Acquia and our time at GVS. Greg did already.

Selecting conference session proposals: popular vote? selection committee?

Greg — Wed, 03 Aug 2011 22:32:43 +0000

I was on the "Ecosystem" track session selection team for Drupalcon London, which motivated me to finally do some more analysis on the traditional pre-selection session voting. Specifically, I wanted to compare the votes a session receives against the evaluations submitted after the conference.

By the way, if you have the opportunity, I highly suggest going to a Drupalcon; they are always great events.

Here are some conclusions based on analysis of the evaluation and voting data from DrupalCon Chicago:

Voting was not a useful predictor of high quality sessions!
The pre-selected sessions did not fare better in terms of evaluation than the other sessions (though they may have served a secondary goal of getting attendees to sign up earlier).
We should re-evaluate how we do panels. They tend to get lower scores in the evaluation.
The number of evaluations submitted increased 10% compared to San Francisco, which seems great (Larry Garfield theorizes it is related to the mobile app, I think there are a lot of factors involved)

Is voting a good way to judge conference session submissions?

Drupalcon has historically used a voting and committee system for session selection that is pretty common. This is also the default workflow for sites based on the Conference Organizing Distribution.

Typical system:

Users register on the site
They propose sessions (and usually there is a session submission cutoff date before voting)
Voting begins: people (sometimes registered users, sometimes limited to attendees) can vote on their favorite sessions
During steps 2 and 3, a session selection committee is encouraging submissions and contacting the session proposers to improve their session descriptions
Selection begins: Voting closes and the session selection committee does their best to choose the right sessions based on factors like appropriateness of content to the audience, the number of votes, their knowledge of the presenter's skill, diversity of ideas
???
Profit

Drupalcon Chicago (the event I'm basing this analysis on) had a few changes to that model. They pre-selected some sessions from the people they knew would submit sessions and get accepted (see their blog post on that and the faq). This allows us to see whether pre-selecting actually brought in sessions that were more valuable to people which seems like a decent proxy for whether or not the committee's choices are right.

The pre-conference voting had 5 stars with the following labels:

I have no interest in this session
I would probably not attend this session
I might attend this session
I would probably attend this session
I totally want to see this session

The post-session evaluations had 5 stars with the following criteria:

Overall evaluation of this session
Speaker's ability to control discussions and keep session moving
Speaker's knowledge of topic
Speaker's presentation skills
Content of speaker's slides/visual aids

I've previously looked at the percent of the attendee population that actually gets to vote and the distribution of votes (1 to 5) to see if that was actually used in a meaningful way in Chicago (that analysis is on groups.drupal.org). Given the distribution of votes in Chicago across the entire 1 to 5 spectrum, I believe it is useful to use a 5 star system as a rating on a session. However, I don't think the resulting value is directly useful by the session selection committee when they choose individual sessions (more on that later).

My analysis method was to create a nice spreadsheet with the average and count of votes on sessions from the pre-conference period where votes were used to help determine which sessions to include. Then I added in the votes (from 1 to 5 stars) which covered several categories.

I graphed the pre-conference votes compared to the post-conference evaluations and used the "correl" function to see how correlated the data is. I expect a straight line correlation: the higher the average votes, the higher the post-conference evaluation scores. In fact, there was basically no correlation.

What I found was that there is basically no correlation between the pre-conference voting and the post-session evaluations. Here is a table that shows the axis (i.e. one of those 5 elements above) and the correlation between that axis and pre-conference session votes.

Axis	Correlation (r)
overall	-0.00615455064217481
control	0.0528419859853818
knowledge	0.0907826506020892
presentation	0.00493457701973411
visuals	-0.0216904506593498

As a graph, the overall data looks like:

This data is not correlated. Just look at it, spaghetti soup!

I graphed it along with a random line that has a correlation value of .95. As you can see, the overall evaluation is not at all correlated to the outcome evaluations.

It isn't surprising that votes don't correlate to session quality. Voting tends to be done by a minority of event attendees who are "insiders" to the event. They are likely to be swayed by friendships, employers, and social media campaigns.

Comparing pre-selected sessions to regular sessions

I also took an average of the evaluation scores across non-pre-selected-sessions and the pre-selected sessions. The average overall evaluation score for non-pre-selected sessions was 80.9 vs. 80.7 for pre-selected sessions. The other axes show similar results except for knowledge and visuals, though it's not clear if those are statistically significant.

Axis	Pre-selected average evaluation score	Non-pre-selected average evaluation score
overall	81	81
control	83	83
knowledge	93	91
presentation	80	81
visuals	78	75

So, we can see that regularly selected sessions got very similar scores to the pre-selected ones. I'm not suggesting that pre-selecting is flawed (it didn't produce lower results, anyway), but I do think we should carefully consider who we pre-select.

The third bit of analysis I did was to look at overall score, and the number of presenters for that session. Here's the average per decile where decile 1 is the 9 sessions that were ranked highest. Seems like a pretty clear trend from nearly 1 person for the top rated sessions to 2.5 people for the bottom rated sessions.

Average # of presenters	Decile
1.11	1
1.67	2
1.89	3
1.44	4
1.67	5
2.33	6
2.00	7
2.00	8
2.44	9
2.50	10

I believe there are two big reasons for this. First, panel presentations are rarely done in a well-coordinated manner and the panel members usually don't take time to practice as a group (our distributed community makes that hard). Second, Drupalcon session selection committees often suggest similar topics get merged into one panel. I think we should stop merging independent presenters. The result is often that people who may not have the same story to tell end up putting 45 minutes of information into one-half or one-third of the time.

What can we do to improve session quality and session selection?

One of the great tools for session selection committee members at Drupalcon London was the availability of evaluation data from previous conferences. If a proposed session got a lot of votes (perhaps due to a campaign on twitter or within a large company) but the presenter had horrible evaluations from a previous conference then the evaluator has an easy job: just say "no thanks".

The only problem with using previous conference evaluations to judge sessions is that it can lead to stagnation among the presenters. Part of the value of a conference is in hearing new ideas. This can be reduced by having free-for-all BOF sessions, but I think in the Drupal world that part of the solution is to use Drupalcamps as a ramp into Drupalcon: presenters should give their session at a camp and mention that (and any evaluations from the camp, any video from the camp) in their session proposal. With approval from presenters, Drupalcamp Colorado published our evaluations - we hope this helps other camps and that they will do the same. It's not surprise that some feature requests for COD will help make the process of gathering this information and getting it to the right people much easier.

See also a great discussion on groups.drupal.org: On popular voting and merit-based selection of sessions.

What else can improve session quality?

So far I've talked about identifying good sessions, but I think the nature is more complex. It's also about encouraging and inspiring the presenters to do great work on their sessions. We can tell them "please practice it 10 times" but nobody will do it if they aren't motivated. Sending reminder mails to presenters like "we expect 3,000 attendees including key decision makers from companies like Humongo Inc." could help. There's also the possibility of compensating presenters. Drupalcon Chicago gave a mix of cash and non-cash benefits (massage chair, faster check-in line).

Scott Berkun gives some tips on how to improve the presenter experience at a conference in An open letter to conference organizers. He recommends a lot of things including sharing the results of the evaluation data. I'm in favor of that as well...(provide default terms of attendance).

Extra note: Want to see your evaluations from Chicago? Just needs more code

There were evaluations in Chicago, but the speakers have not seen this data. I got access to it as part of my role on the London session selection team and my work on the infrastructure team/Chicago sites.

However, the fact that presenters can't see it is a result of a bug in software that you can help fix. The organizers of Drupalcon want to share that information, but the code to do that isn't fully working. If you can help make it work then all session presenters will be able to see their evaluations.

COD Beta1 Released, Packed with Features

Ezra — Wed, 13 Jul 2011 18:27:06 +0000

We're excited to announce that COD Beta1 has been released and is loaded with great new features, including:

Enhanced conference administration menu
Automated sponsorship sales
Birds of a Feather scheduling tool
Automated speaker confirmation and contact
More granular control over the event registration workflow
Ability to collect profile information for free events
Session editing for multiple speakers
Improved attendee check-in
Better Ubercart reporting for purchased registrations
Integration with RegOnline and Etouches

Voting, Profiles & Hot content: Tools to help the Drupal community scale

Greg — Tue, 24 May 2011 22:12:10 +0000

Drupal is growing in complexity and growing simply in sheer numbers. We need more tools to help people manage the information overload and find the best voices in our community quickly. We should build dynamic tools to empower community members to join in and share their voices (if those voices are valuable) rather than walled gardens that keep people out. I believe voting, richer profiles, and the hot content are steps to help enable that vision. That said, the implementation has to match the community values. Below I've laid out the story of how some improvements to Groups.Drupal.org were made, provide data behind some of those improvements, and ask some questions so we can keep refining them.

At Drupalcon San Francisco there was a sprint for groups.drupal.org features where Josh Koenig and Brian Gilbert helped out add some new features. In particular we added voting on nodes & comments and we added a "hot" page which incorporates several elements to determine which content on the site is interesting in the last week.

I wanted to look back on the past year to think about these changes and whether or not they are an improvement.

Hot Content: G.d.o is a differentiated piece of $#!@$&

Randy Fay recently wrote about how Drupal.org doesn't differentiate in quality of content and he's absolutely right about a lot of the site. The only way to know what posts/comments are good is if you've been around enough to get a sense of people's reputation and maybe have a perspective on their content. For drupal.org, my colleague Lisa is working on a Content Strategy, which is what we ultimately need. I don't agree with all of Randy's ideas, but one of them I agree with is that we need better ways for the community to find the best content. Groups has that!

The hot content on groups.drupal.org helps feed people's desire for great content. According to Google Analytics this page is in the top thousand or so for most popular with a bounce rate of just 23% For comparison, Jobs is perpetually one of the top pages on the site and has solid value as a guide to content useful to visitors, it also has a comparatively low bounce rate of 29% which is a bit higher than the hot content. That makes the Hot page a pretty solid resource on the site for finding content, especially considering it's just a year old and has no primary navigation linking to it.

Voting on content & comments

Groups.drupal.org is using the Vote Up Down tool which has both up/down AND the ability to do just Up voting (my thanks to Marco Villegas for his help with the module). My feeling was that this tool would provide a simple way for folks to say "I agree" or "I disagree" without having to get into a long debate about exactly why. It helps bridge the gap for users who want to provide feedback to the conversation but don't want to fully invest in a comment, or don't want to create an e-mail notification for their action.

Below is a graph that shows a breakdown of the sum of votes on content (both nodes and comments):

This graph shows that of the 12,117 pieces of content that are rated, more than half of it ends up with a +1 total score (6,810 items). Almost 9,000 items end up with a positive score while about 2,400 items have a negative score (about 750 items had a net zero score).

Looking at individual voting habits, 7,400 people have placed a vote. Among those, there are 2,960 who placed a down vote and 5,630 who placed an up vote.

The sum of votes for individuals shows whether on whole they are more in agreement or disagreement: a person with 2 up votes and 1 down vote would have a sum of 1. The data shows that the sum is a negative number for about 1,800 people and a positive total for over 4,600 people. These two items show that most people use votes to be positive in whole even if they periodically have a down vote.

My hope was that voting would help reduce tension among groups on the site. In the time I've co-managed the site since Drupalcon Paris we have had 3 regional groups in particular that had a large number of disagreements that rose to the level where concerned group members needed to ask for outside help. Those disagreements led not only to me instituting this voting tool, but also to Moshe creating the Drupal Code of Conduct. Has voting or the DCOC helped those groups to interact more civilly? It's hard to say.

I personally find both up and down votes of other users to be valuable as I read a thread. It helps me get a sense of what other people on the site think.

What do you think? Is voting useful on g.d.o? Should we remove the option to downvote? Should we make it possible to see who did which votes?

Improved user profiles:

A few months ago my colleague Ben added some fields to user profiles. Now the site displays a mix of user entered data AND automatically generated information.

It's now possible to take a quick glance and see a user's level of interaction on the site from posting content, to voting, to events organized and groups organized.

Groups has long used avatars, a feature which is valuable to help reputation/recognition when scanning a page. Try looking at a forum post with a lot of comments on d.o and quickly identify comments by people you know. Now try it on g.d.o. See?

Voting and reputation are something that's particularly interesting to me since it relates to the session selection process in conference sites we build and the Certified to Rock system. I'll be writing more about voting on sessions as it relates to Drupalcon in the next few weeks.

What else can we do to improve the day to day interactions with these sites? How can we elevate the conversations?

You should come to Drupalcamp Colorado June 11-12 2011

Greg — Mon, 16 May 2011 23:25:23 +0000

Drupalcamp Colorado 2011, co-hosted with Commerce Camp, is shaping up to be another amazing event.

In 2010 we had 312 people registered, delicious breakfast and lunches, 2 parties, all for less than $50 in attendance fee. For 2011, we have all that and more. You may consider registering before reading the rest...but if you still need to be convinced:

Drupal Camp Colorado: An Amazing Value in 2011

Session submission is closed and session selection is under way, but BOFs will be managed online in the lovely Conference Organizing Distribution based BOF manager which was used for Drupalcon Chicago and is being enhanced as it makes it's way into COD.

And the sessions accepted are looking amazing. There's a good mix of the best-of Drupalcon Chicago combined with what will certainly become favorites at Drupalcon London.

The content team has made sure that we cover all skill levels this year. Some particularly new user friendly options include:

Pre-camp training on Friday the 10th from Lullabot and Chapter 3 will give you a 1 day trip forward a few levels in your Drupal journey.
Getting started with Drupal will show off the basics and fields. Follow that up with Introduction to Views and then Setting up a Drupal Development Environment on Windows before heading off to Introduction to Theming and Introduction to Module Development. That takes a solid programmer from newbie to rockstar in a day!

And if you're looking for socializing then there are both formal and informal activities to keep you busy. Friday and Saturday nights we'll have official parties at nearby venues with subsidized refreshments.

Amazing Attendees for Drupal Camp Colorado 2011

For 2011 we currently have 185 attendees registered about a month before the camp begins and we have space for up to 500. Among the people planning to come are:

Approximately 25 total Drupal 7 core contributors will be at the camp including some amazingly profilic ones like Damien Tournoud, Károly Négyesi (chx), Dave Reid, Larry Garfield, Bojhan, Nathan Haug (quicksketch) and Randy Fay who combined were responsible for approximately 13% of the code changes in Drupal 7. These are the people who are largely responsible for the new Database API, Image handling in core, automated testing and CCK in core among many other things.
Amazing Drupal contributed module maintainers like Earl Miles (merlinofchaos) of Views, Panels, and Nodequeue fame (Nodeque being co-maintained by GVS team member Ezra Barnett Gildesgame).
Nathan Haug who maintained many of the image related modules in Drupal 6 and who maintains the Webform, Flag and Fivestar modules (Fivestar being co-maintained by GVS team member Ezra Barnett Gildesgame).
Ryan Szrama of Ubercart/Commerce fame who will be here for a whole week in advance of the camp working with the broader Drupal Commerce team for a sprint.
Dave Reid, who along with me, helps maintain the Pathauto and Token modules. Dave also maintains Path Redirect and about 100 modules total!
A few Drupal 8 initiative owners will be using this as a time for a sprint. Greg Dunlap, David Strauss, and Earl Miles are planning to attend and work on configuration management. Larry Garfield will be there to work on Web services/Context.
From Aten Design Group we have Scott Reynen who has been tearing up the project application queue, Ken Woodworth who is primarily responsible for the amazing Drupalcon Denver design work.
TopNotchThemes will be here with Steph, Chris, and Sheena bringing their usual fun and solid theming skills.

If you ever wanted a time to chat with these folks without fighting with 3,000 other people for their attention, Denver is that time.

Sold? Great: Register now!

Content inventory and content audit with Views

lisa — Sun, 10 Apr 2011 06:36:00 +0000

Do you know the exact state of the content in your large Drupal site? Thinking of revamping, redesigning or upgrading your site? If you answered 'no!' to the first question or 'yes!' to the second question, it's time for content audit.

In this blog post, I cover the what, why, who, when, where and how's of content audits. I've conducted a few small content audits, and I'm leading a much bigger one, on Drupal.org.

What the heck is a content audit?

The idea behind a content inventory is to determine what content you have and where it lives (the quantitative survey). The content audit is qualitative, where you assess whether it's any good or not, and what needs to change to improve it.

Traditionally, content inventories are compiled manually, one page of your site at a time, in some sort of spreadsheet. The content inventory should also include PDFs, images, videos, and utility pages such as checkout and log in pages. Content should be inventoried regardless of whether it's hosted on your site or externally. If it's seen or heard within in your content, it needs to be held accountable.

Sites with 5000+ nodes could be auditing using a sampling of nodes that represent each content type, but what if you miss some glaring errors? In those instances, you could provide a small link to all site visitors who can flag the page as needing work (this can be done easily enough in Drupal, using a variety of approaches).

Newsflash! Content audits aren't fun and exciting (unless you're a content geek like I am). They can be really boring.

Disc Inventory X for Mac audits the contents and space of your hard drive, displaying the contents as colored squares to represent each file type, and how much space those file types consume. Wouldn't it be great to get this sort of clarity on your site content?

Why you should audit your content

Primarily, because it's impossible to be sure of the content quality in large sites, especially those with multiple contributors. When a site is audited, all sorts of oddities will be found, such as unfinished blog posts, unpublished nodes, outdated or inaccurate content, redundancies, content in the wrong place, or content that doesn't meet the organization's style standards/guidelines. (You do have style guidelines, right?). You might also find gaps in your content, e.g. discover that Product A, Product B and Product D was covered extensively, but Product C's listing doesn't include target audience and Product E's description was never written.

In Content Strategy for the Web, Kristina Halvorson writes

"If you don't know what content you have now, you can't make smart decisions about what needs to happen next."

If you want even more reasons why you should conduct a content inventory/audit, the books listed at the bottom of the post give reasons, and more in-depth advice.

Who should do a content audit?

A person who cares about the quality of your site's content, or a content strategist. Sometimes the person who cares becomes the content strategist.

It's tempting to ask an intern or a random person in the organization who has free time to do, but it means the job may never get done, or done haphazardly, especially if they think they know the content really well. As with QA and user testing, content auditing is often better done with fresh eyes; someone outside the organization.

When to do a content audit

Ideally, you'll complete the audit before:

Reorganizing your current site structure
Upgrading to a new version of Drupal or (oh noes!) migrating to a different CMS
Adding new content types
Making content decisions based on your site's SEO performance

If a site were migrating to Drupal, a content audit could be performed after the migration, but before key decisions about site architecture, IA/hierarchy, navigation/menus and publishing workflows are finalized.

Like any website project, the more organized and informed you are, the more likely your project will be a success.

Where to do a content audit

I don't mean, "Should I be in the 3rd floor conference room, or should I be at my desk?" I mean, where should you store the content audit's data?

The probem with constructing your content audit in a spreadsheet is that when the content audit is revisited 6 months later, it's going to be out of date—what a drag!

The standard Drupal administrative content overview page at admin/content/node/overview doesn't allow you to add more columns or sort by column heading; the overview page alone isn't sufficient.

Roll your own inventory with Views

Here's a recipe, using Views 2 in Drupal 6 to (mostly) painlessly create your content inventory.

The content inventory will be a like a spreadsheet, with columns listing information for each of your nodes.

Preparation for the content audit

Ensure Views 2 is installed and enabled
Enable core Statistics module (optional)
You may want an administrative theme enabled; the table view of the View is going to get wide, and you don't want to try to decipher squished columns. Otherwise, just ensure the blocks or other page elements don't display on the inventory page.
You can use the Annotate module to store editorial or "what needs doing" notes about each node.
You can use flags to flag notes as needing a particular type of work.

I'll cover annotations and flags in depth, in a future blog post about the Content Audit module, which will package a content audit View and other tools for quicker inventories.

Building the view

First, create a new View and call it something like 'node_content_inventory'.

Basic settings

Title: [Your site name] Node Content Inventory
Style: Table
Access: administer nodes (or perhaps you want to use your Admin role for access)

Having long pages is desirable once you start resorting and filtering. If you have a couple hundred nodes, you can avoid using pagers, so set it to 'No' with Items per page as Unlimited.

Otherwise, display 200 items or so per page and enable the full pager.

In the Table styles options, ensure every field is marked as sortable. Unfortunately, you can't sort by path.

(If you're using Book content, you should include the depth too! But unfortunately, there isn't a default way to display the parent of each book node.)

Fields to display

Node: Nid Nid
Node: Title Title
Node: Path Path
Node: Type Type
Node: Published Published
Node: Updated date Updated date
Node: Post date Post date
User: Name Author
Node statistics: Total views Total views
Book: Depth Depth

These will produce the site's basic content inventory. The above are just suggestions; feel free to add more if you want to evaluate different fields.

Create a Page display and give it a path such as 'node-content-inventory'.

Filters

Next, you'll want to filter out content that isn't relevant to your content inventory. Let's say you want to audit everything on your conference site apart from Room and Time slot nodes.

Create a Node: Type filter, only including the content you want to audit. Then expose the node Type filter. You may want to create and expose other filters, depending on your needs.

A manually-constructed content audit would include which section the site is in. So, if your site's sections are generated by taxonomy term, you should also include this taxonomy field in its own sortable column in the View.

Ideally, the node paths would be sortable with an exposed filter, but that will require writing a Views handler. It's on the To Do list!

In the header text, include the date and month the content will be reviewed, and update it each time you re-evaluate your content. (Every 6 months, right?)

Finally, save the view (actually, you should probably be saving as you're constructing it).

Evaluating the content

Look at your page at node-content-inventory. It's a giant list of all your nodes.

Now what? You have options.

Option A (Export): export this view to CSV and manage your content audit in spreadsheet software or Google Docs. The Views Bonus Pack module will let you export the view as a CVS file.
Pro: Less data to store in your database
Con: Your inventory is almost immediately outdated; will be extra time-consuming to update on a regular basis
Option B (Flags): 'Flag' content that needs to be updated using the Flag module. You can adjust the flag settings so that only certain roles can use this flag, and then set which content types can be flagged (or set it as global). You can then add the Flag to the content audit view, and/or create a separate view of nodes that have been flagged. However, marking something as "needs work" doesn't provide enough detail, so you'll want to record notes somehow (see Option C). You can create additional flags for each type of action to be taken, e.g. "needs style review" or "redundant", without the casual visitor even knowing, while keeping your content team in the loop.
Option C: Keep 'audit notes' field on each content type in Drupal site database with the Annotate module or by creating a field on the nodes.
Option D: Use the Content Audit feature module, which constructs the View, and will soon have configured Annotation (this hasn't been built yet).
Option E: Create another node type called Audit notes, and once filled in, then nodereference the node it covers. Then, it's easy to build a view of the Audit notes (I'm also wondering whether this could be a custom bit of code to automagically do this, then include in the Content Audit module).

Option C and D are great, because you're not reinventing the wheel every time you review your content inventory.

Content inventory for files and other non-node content

For files, such as images or PDFs attached to nodes, you might want to create a separate View and call it file_content_inventory. You could combine it with your primary node content audit, but the headings are different.

Other non-node content, such as landing pages created with Panels, Views, tpl.php or things like login pages need to be audited manually.

1, 2, 3... Audit!

Now the fun begins. Read existing content and check the following (and you may want to include extra instructions for your reviewers, if it isn't you doing the work).

Does it contain redundant info (is this content covered elsewhere? note down the node ID where it is covered)
Is it in the wrong place (does another page make more sense?)
Does the content need restructuring? Provide examples.
Is it inaccurate? Don't spend time researching the inaccuracies, but if you think the content is inaccurate, let's say so.
Is it useful? Does it add value? Or just wasting people's time? Just because it exists, doesn't mean it should be kept around.
Does it need language (grammar, spelling etc) improvements?
Does the tone and style meet the guidelines? http://drupal.org/contribute/documentation/guide/style
Is it written for the right audience?
Is there any key information that's missing?
Does the url path not make sense? As a top level or important page, does it need it's own path?
Could the content be supported by an image or illustration? If yes, what?

This process could take weeks or months, depending on many factors.

Summary

Content audits. They're important. Do them.
If you don't want to do the audit yourself, find someone who can. Hire an information architect or content strategist.
Take the time to improve your content based on the audit. People come to your site for the great content.

Content audit process: Start > Decide what needs auditing > Configure tools for auditing > Evaluate content > ??? > Profit!!

The '???' is where you (or your content strategist and writers) do the magic of identifying and fixing content problems. After that, your site will reap the benefits.

Now, I'm interested if anyone has done content audits using Views or other modules, and what your experiences it it were! Please drop some knowledge in the comments below.

Additional Reading

Content Strategy for the Web, by Kristina Halvorson, particularly Chapters 4 and 12

The Elements of Content Strategy by Erin Kissane

Information Architecture for the World Wide Web by Peter Morville and Louis Rosenfeld

A Project Guide to UX Design by Russ Unger and Carolyn Chandler

Mediacurrent Interviewed about COD on UseCod.com

Ezra — Wed, 06 Apr 2011 20:42:05 +0000

Dave Terry from Drupal development shop Mediacurrent spoke to GVS about Mediacurrent's latest Conference Organizing Distribution site implementation for the Pegaworld 2011 conference. You can read the whole interview at UseCod.com.

Branding Exercise Leaves Fish Dead, Owl Satisfied, Drupalers sad

Ezra — Fri, 01 Apr 2011 15:24:20 +0000

A routine branding exercise went awry early Friday in Brooklyn when Growing Venture Solutions performed a "mind map" exercise to aid in the creation of logos for two of their flagship products, the Scout hosted sercurity review service and COD, the Conference Organizing Distribution for Drupal.

"Connecting to the unintellectualized, visceral, gut responses we get from each logo helps us maximize branding potential so that we can produce marketing collateral that's sure to engage members of our target market segments, helping them to connect to each brand at an emotional level, which results in increased conversions" said social media expert Robert H. McJellyPants. He added, "Tachyon converter beam subspace electron resonance tuning."

Unfortunately, while exercise participants were discussing their friendly, communal associations with schools of smiling fish in the COD logo, as well as some of the more stern, defensive associations evoked by the Scout owl logo, the owl took flight and picked up the fish, instantly crushing the fish's vital internal organs with its beak.

Illustration by Carl Wiedemann.

Needless to say, participants were horrified at the sudden attack by the owl but impressed by its swift, decisive action in the face of what the owl saw as a potential security risk to its personal website, SupercuteCatsWearingWigsandSmallDressesTailoredEspciallyforCatsNoThisisnotajoke.com/website.

McJellypants expressed concern, saying "This is highly unusual for a branding exercise, and the attack could be a step in the wrong direction for both brands. It may cause people to construe the owl as reckless and aggressive, rather than defensive and wise." He pointed out that "[i]t makes the COD logo more similar to the previous one, which was also a dead fish," referring to the public domain image of an Atlantic cod that previously represented the Conference Organizing Distribution.

COD has been used to power many feature-rich conference websites for DrupalCamps, the recent DrupalCon Chicago conference, as well as non-Drupal events in the United States, India and Australia.

When asked to justify the attack, the owl provided participants with helpful information about the specific security vulnerability it claimed was presented by the fish. However, for more information, it directed them to its "Scout Automated Plus" and "Scout Enterprise" solutions, where Drupal security experts explain potential vulnerabilities on specific sites—and the steps to mediate them—in great detail.

Despite having clear expertise in Drupal security, it was reported in several tweets on Friday that the owl's personal site had the full HTML input format enabled for anonymous commenters early Friday morning. The issue appears to be resolved as of the publication of this article, though one comment on the site by "IttyBittyPrettyWittyKittyCommitteeinNewYorkCitySingingaDitty36" appeared to show a properly escaped cross-site scripting attack probe, and read, <script>alert('XSS Vulnerable Meeeeow');</script>

When reached for comment, the owl tried to bite off my face.

Two of the mind-map exercise attendees posted a re-enactment of the event to YouTube. Note: the mind map was done on a boat.

Drupal 7 release parties and December sprints

Team GVS — Tue, 18 Jan 2011 23:03:53 +0000

GVS has had a busy December and great start to 2011!

NYC and Denver Drupal 7 release parties

The NYC Drupal 7 Launch Party, hosted by Growing Venture Solutions, Treehouse Agency, and ThinkDrop took place on January 7, 2011.

We were delighted at the turnout and enthusiasm for Drupal 7!

Happy crowd!

The speakers were Rob Purdie (Economist), Todd Ricker (New York Stock Exchange) and Thomas Turnbull (Zagat). The organizers were Lisa Rex, Claudina Sarahe, Ezra Gildesgame, Amy Cham and Ben Jeavons.

We did a video link up with the Boston party. Oh look, it's Dries Buytaert!

And then we did a video link up with the Denver and Austin parties. Everyone say hi to Greggles and Kevin Bridges!

And Jacob Redding wore his Drupal suit and tie!

We gave away raffle prizes from Lullabot, Packt Publishing and Mastering Drupal, and there was some additional sponsorship support from CivicActions and Bluestocking Collective.

The official photographer for the NYC Drupal 7 party was Matt Cham. Additional d7rp_nyc party photos are on Flickr.

GVS also co-hosted the Denver party, with Greg Knaddison in attendance. The next three photos are by Keith Stansell.

Dano Manion, Andrea, Aaron Nott, Greg Knaddison and Justin Christoffersen. I'm holding up a nice Certified to Rock sticker ;)

Andy Packard and Matthew Saunders from the team at Examiner.com.

Jason Yee making Drupal 7 and Seven.

GVS <3 sprints

GVS and Treehouse sponsored a D7CX code sprint at the offices of GVS neighbor HUGE in Brooklyn, NY.
Progress made at the sprint included working automated tests for the Nodequeue module, a stable Drupal 7 release of the Security review module, amongst other work.

Ezra, Vikram Yelanadu, Thomas Turnbull, Andrew Morton, Steven Merrill

Meanwhile, Lisa participated in the Drupal Docs sprint weekend in Vancouver where the core documentation team hashed out directions and problems the Docs team face (see issues tagged docsyvr2010 for things that were raised during the meeting). On Saturday, there was a Docs team sprint with special guests chx, dmitrig01, and webchick!

http://www.flickr.com/photos/arianek/5253327904/sizes/m/in/set-721576255...

Module owners: How to make your module description useful

lisa — Mon, 13 Dec 2010 14:34:09 +0000

Here's the scenario: Someone semi-familiar with Drupal is building a site. They need to find a module to meet one of the site's requirements. Since there are over 5000 modules for Drupal 6, it must exist, right?

Let's assume they don't know who to ask, so they start researching. To evaluate contributed Drupal modules, the first resource they will use is the module's project node on Drupal.org.

Most important elements of Drupal project pages

What are site builders looking for when evaluating a module? I asked Drupallers via Twitter what they look at specifically and got the following:

Who the maintainers are.
Date of last commit.
How recent the recommended version is.
Date of last release.
Number of open issues.
Number of commits.
Usage stats.
Issue follow-up rate.
What does the module do?
Why was the module created?
What problem is the module trying to solve?
Is the module generic enough to apply to other problems?
Is there any documentation?
Will there be a Drupal 7 version soon?

Notice that items 1-7 are provided automatically by the Drupal.org Project module. And items 9-12 are details that only the module maintainers can provide within the project's Full description field.

The above details tell a site builder about the activeness and awareness of the maintainer(s), whether the module can be considered reputable because of the names of the maintainers behind the module and hopefully, give them enough info to know whether they should use the module.

The folks that responded to my (very non-scientific) survey are all Drupal-savvy. What about the less-than-savvy? The maintainer names won't be meaningful and neither will some of the stats. The emphasis is now on making your module description more useful. Here's a few ideas...

Useful description idea #1: use subheadings

Subheadings make your description more easily scannable. In an ideal world, Drupal module maintainers would adopt a standard for subheading text and sizes. I've seen h2, h3 and strong. Which is the right one?

Here's a list of subheadings that would be awesome. I'll describe them fully below.

Overview
Features
Requirements
Known problems
Tutorials
Pledges
Credits
Recommended modules
Similar projects

Useful description idea #2: Write a good overview

Try to answer the following questions in 5 sentences or less: What does your module do? What's it trying to solve? Who is the module for/who is the audience? This reduces time wasted and also, if you can confidently tell someone this module is for them, they're more likely to use it and support it. And if it's easier to describe with pictures, go for it (see Idea #7).

Greggles likes to include version notices too, e.g. "Version 6.x-2.x dev is not stable and probably won't be for a year or more. It is the home of new experimentation and crazy new features. Version 7.x-1.x-dev is a direct port of the 6.x-2.x-dev and will be the stable version for Drupal 7. There will be no direct port of 6.x-1.x-dev" etc.

It's all about managing expectations!

Useful description idea #3: Summarize features

This should be a bulleted list of features to help people quickly figure out if it's useful to them. Keywords will also be useful when folks are searching. Both FileField and IMCE module do the feature list well.

Useful description idea #4: Include requirements

Include module or library dependencies as well as any other technology requirements, e.g. PHP5. FileField does this. Why? Because like any recipe, it helps to know what ingredients you need upfront, before you're waist-deep!

Useful description idea #5: Share known problems

If there are conflicts, incompatibilities, extremely common bugs, or gotchas that are easy to miss, be upfront about it. Briefly describe the problem, link to the issue (so others can contribute), and you should see a reduction on the number of duplicate issues that are created.

Useful description idea #6: Credit sponsors and maintainers

If any organization in some way sponsored work on the module, link them! It extends credibility, and it furthers the notion that modules can be sponsored. Imagine how great it would be to have more of your module work sponsored (that is, your time is compensated in some way). If organizations see the benefit of sponsoring, in the form of free advertising and community karma, especially as a module's popularity grows, they'll be more inclined to sponsor future projects, and can endorse sponsoring to other companies.

Also, let's not forget co-maintainers. Since "ownership" of modules usually changes over time, co-maintainers names and other history are useful to have recorded here.

Useful description idea #7: Create and list tutorials

In addition to the Documentation link provided by the Project node, a list of blog posts, demos, screencasts, screenshots, reviews, and any other resources should be listed here. Smaller projects probably won't be written up in blog posts, but having a list of the ways one can learn how to use your module is very helpful, especially at a time when they're getting frustrated.

You can help a newbie a ton if you create a short screencast showing the typical usage and configuration. If you're not up for making a screencast, provide embedded (or linked) screenshots of the module configuration and module in action.

Useful description idea #8: Pledges

If you've taken the D7CX, D7AX and any other pledges, list them.

Useful description idea #9: Acknowledge other projects

Yes, the Pivots already lists Related projects, but it's not quite the same as Recommended modules. If your module works particularly well with other modules, list them here.

Likewise, if you're aware of modules similar to yours, feel free to add them or link to a node in the Similar Module Review group or this issue on the myriad Tabs and Slideshow modules.

Oh noes! This description is too long!

Of course, if your project page is too long, you risk overwhelming readers and/or losing their interest. If you have a lot to say, consider linking to your detailed README.txt in addition to creating module documentation. Module documentation guidelines are provided in the Drupal.org handbook.

People will love you forever if you provide awesome documentation in the form of screenshots, screencasts and a well-written Documentation node.

What next?

If you think it's a nice, considerate gesture to not waste people's time by clarifying your module's benefits, requirements and current issues, let us know.

We're interested in hearing what others think. Is this something we can encourage on Drupal.org? What other info and subheadings should be included?

The end goal is for me to create a Documentation node drupal.org to describe these best practices for module descriptions.

Many thanks to @arianesays, @decibelplaces, @deviantintegral, @dmitrig01, @joelfarris, @jpoesen, @stevenmerrill, @greggles, @ezrabg and @benswords for contributing to this post via Twitter!

P.S. If this sounds good to you...

Use this handy cut and paste skeleton to flesh out your project description!

<h2>Overview</h2>

<h2>Features</h2>

<h2>Requirements</h2>

<h2>Known problems</h2>

<h2>Tutorials</h2>

<h2>Pledges</h2>

<h2>Credits</h2>

<h2>Recommended modules</h2>

<h2>Similar projects</h2>