Business

2021 Revenue Growth Journal: Finding Your Critical Number

Josh Linard — Tue, 12 Jan 2021 20:04:41 +0000

2021 Revenue Growth Journal: Finding Your Critical Number

The Critical Number

So Slack went down last week - what better time to start that revenue growth resource that I was planning, right? Let’s start with the Critical Number: what it is, why it matters, and how to put it into practice for your business.

The concept of the Critical Number had a significant impact on the tremendous growth we experienced in 2020 - despite the pandemic. So, what is it? The Critical Number comes from the Great Game of Business, an open-book management philosophy. It’s the one number that if you fail to achieve or exceed it, there would be a drastic negative impact on your business. Where most organizations make the mistake with Critical Numbers is they look too much towards their Top-Line or Bottom-Line Revenue or Sales goals vs having the Critical Number focus on the activities required to reach those Top-Line and Bottom-Line goals.

You could probably use an analogy, right?

Well, we all want white, healthy teeth. That’s the goal. The Critical Number, however, is making sure you brush 2-3 times daily. Brushing 2-3 times a day is clear, easy to track, and easy to manage. The white teeth are the destination, much like the larger annual goals of a business. In 2021, set out to find your Critical Number and you’ll be amazed at the results. As you begin this climb, keep these best practices in mind:

Best Practices for Critical Numbers

1. Critical Numbers are goals, but goals are not necessarily Critical Numbers.

Here are a few thought starters for Critical Numbers in Revenue Departments that are focused on activities:

Sending X Number of New Business Proposals
Holding Y Number of Prospect Meetings
Speaking and Presenting at 12 Industry Conferences

2. Critical Numbers should be visible to the entire company.

Collaboration across departments has always been important, but even more so now that many of us are working remotely. It’s been great to see how the various departments in our own organization really rallied around each other’s Critical Number.

3. Report on your Critical Number weekly, not monthly.

Since Critical Numbers are focused on the activities required to reach the larger top and bottom-line goals, they can and should be reported on weekly. This helps reinforce the importance of the goal as well as celebrate the success and/or address a major challenge if the goals start to slip away.

I’m happy to share more about Critical Numbers and other great resources from the Great Game of Business. Feel free to reach out. Oh, and brush those teeth!

Josh Linard Tue, 01/12/2021 - 15:04

Persona

Marketer

Tags

Business

How Organizations Can Give Back to Open Source Projects -- and Why They Should

Damien McKenna — Thu, 16 Aug 2018 21:05:45 +0000

How Organizations Can Give Back to Open Source Projects -- and Why They Should

At Mediacurrent, as with many digital and web development agencies, we build projects using a wide variety of open source software (OSS). From our text editors, to our build tools, to our programming languages, to our preferred hosting environments use of Linux, to our preferred content management system, pretty much every step of the way involves open source software. We feel strongly that organizations using OSS should also contribute back. As Community Lead, and a contributor to OSS since 2001, part of my time is spent helping clients and coworkers to learn the ropes, empowering them to help sustain the very software they depend upon.

Let's take a look at why businesses and organizations should consider supporting OSS projects, and then look at some specific ways for them to do so.

Why care about open source software?

After a slow start with the free software movement of the 1970's and 1980's, by the end of the 1990's open open source software was heralded as a revolution in the software world. Now, almost 80% of all businesses use open source software in one way or another, nearly doubling from 2010. As OSS is open for everyone to explore, it levels the playing field for many businesses, organizations and individuals, giving them the chance to improve their tools instead of being limited by a typical product sales cycle.

Many stalwarts of proprietary software have come full circle on OSS. Way back in 1998 Microsoft was confronting the fact that their proprietary software business was seeing intense competition from OSS, stating "that commercial quality can be achieved / exceeded by OSS projects.". Ten years later they were already changing their tune, attempting to woo OSS contributors by providing vast swaths of documentation in an interest to invite interoperability. Ten years later again, in 2018 they took out a giant checkbook and Microsoft bought GitHub, home to most of the world's open source software. Open source hasn't failed, it really has made a massive change to the world's software.

The lifeblood of open source software is contributions from the folks who use it, particularly those working for organizations which use the software. To paraphrase Soylent Green, everyone's favorite post apocalyptic movie about protein shakes - open source software is [made of] people.

Why organizations should contribute to OSS

There are lots of tangible and intangible benefits for organizations to contribute to OSS, let's take a look at some.

1. Improve staff's knowledge and skill

Working with open source software can expose staff to new concepts, new approaches to solving problems, new techniques for completing tasks. Plenty of studies show that people usually learn the best using repetition, practicing the thing they're trying to learn. While a given project for a client or organization will have custom code and functionality, the amount will pale in comparison to the amount available in wider OSS communities - one can't but help find new things.

2. Contribute towards the future stability of the toolsets your business depends upon

A business depends, in part, on the stability of the tools it uses. A taxi business depends upon its vehicles, a bakery depends upon its ovens and appliances, and an online store depends upon its website. A taxi driver would regularly clean out their vehicle, get the oil changed and perform other maintenance to ensure it runs in tip top shape for as long as possible, so shouldn't a site owner put time and finances into ensuring the site's software continues to run in the future?

3. Create new opportunities to innovate

By collaborating with others it is very common to run into new approaches to achieving a shared goal. Furthermore, when more time is available to a task it can allow people to take more risk to try new ideas, to experiment on improved or alternative user experiences, to research better structures for content, etc.

Furthermore, by expanding the array of people contributing ideas to a goal, the greater likelihood that completely new ideas will arise, that accidents might lead to wonderful discoveries, and who knows where inspiration might come from.

4. A chance to steer the ship

When using proprietary tools there is little chance of being able to decide what happens to it over time. Occasionally proprietary software vendors will seek input from their customers, but ultimately customers have little say in how software changes over time.

With open source software companies have a chance to contribute heavily to the direction software takes. As Dries Buytaert, original creator of Drupal, shared recently, the huge pharmaceutical company Pfizer has contributed heavily to Drupal 8's content workflow system because of the unparalleled opportunity to shape one of the world's most powerful content management systems, the tool their many (many!) internal sites were dependent upon.

5. Corporate social responsibility

It is worth noting that using open source software instead of often expensive proprietary alternatives can very often save a business vast amounts of money, and the larger the business the more that could be saved. As an example, it is not unheard of for licensing costs of a proprietary content management system to cost hundreds of thousands of US Dollars for a busy site, if not millions. Obtaining alternative software without the licensing costs can greatly help a business' financial status.

Some might say that companies which are saving such potentially large sums of money by leveraging software they've received for free have a moral obligation to help support that software. In the USA, businesses are legally considered "people" under the law, in that they can benefit from of the same freedoms that a person can; people are considered to have morals and ethics that determine their behavior, so why shouldn't a business also have a moral impetus to help others, in this case by reinvesting some of what it has saved?

It turns out that there's an existing concept for this - corporate social responsibility aka "CSR". Originally defined in the 1960's, this business process has been refined over the years and adopted by so many large organizations that today aspects of it are a near universal practice. Common examples of CSR include fair trade standards for coffee bean and tea suppliers, corporate philanthropy like Apple's donations to natural disasters, and more.

How organizations can contribute to OSS

While there are lots of obvious ways for individuals to contribute to OSS, let's take a look at how an organization as a whole can become better at contributing.

1. Pursue a contrib-first policy

When working with open source software to build a system, e.g. to customize a content management system like Drupal to build a website, there can be lots of improvements, changes and bug fixes needed to the core system to complete the project. The default approach to dealing with this is to build custom fixes and workarounds. This increases the maintenance burden on the project owners, thus increasing the maintenance costs, increasing the knowledge requirements to work on the project, and so on.

The alternative approach is to consider, from the outset of the project, what portions are truly custom, truly proprietary to the project, and what could be possibly reused. Anything that could be reused should then be designed to assume reuse, with unique customizations as an additional layer.

An example of this would be building custom object definitions for schema.org. The open group provides standard methods of describing things, to make hundreds of possible definitions for different types of things - recipes, books, sports, people, etc, so rather than every search service or social network having a different way of describing things, they can all use one standard that website builders work with. From there, many OSS projects which have added support for the standard, e.g. the Schema.org Metag module for Drupal 7 and 8, but because the full standard covers so, so many definitions, only a portion of these definitions are provided out of the box. The maintainers of these OSS projects have provided an initial set of schema definitions to start with, and then extended an invitation for others to submit patches or pull requests to add more as they're needed. Based upon this, if a business decided that it needed to add the Course object definition they could have their staff, or hire consultants or an agency, to build a small plugin to cover this new requirement and upload it for the project maintainers to combine into the next release of the official plugins. From that point on the website's owners are no longer solely responsible for the upkeep of that portion, it is extended across the entire OSS project's community.

2. Provide self-directed time

Starting the ball rolling on a community interaction, providing an initial patch or pull request, or starting some documentation is a great step towards a finished solution. Often times this initial push will be enough to get a group of folk to collaborating on the finished solution, but it's very important to come back and push the work further when time allows.

This is where Google's much-lauded "20% time" can come into play. While Google famously used the time to let their staff create entirely new products, other companies have used the concept to similarly great success. Atlassian, for example, established a policy of allowing 20% of their staff's time to self-directed tasks, and it led to lots of great ideas, blog posts, and more.

As career analyst Daniel Pink has noted, providing time on-the-clock for staff to explore new ideas, perform maintenance work they've never had time to do, to scratch their own itches, can become a tremendous motivator for staff. As staff motivation can be a problem for employers, trying out options like this can be a real boon to employee satisfaction, and retention.

That said, learn from Google's example and focus on allowing staff to maintain the self-directed time - don't force it to become a "120% time" system.

3. Provide training on writing tests

One of the biggest roadblocks to getting improvements and fixes committed to open source projects, especially to major projects like Drupal core, is a lack of test coverage. Ample test coverage helps make sure that proposed bug fixes actually fix the bug, that new functionality works as intended, and requested changes don't inadvertently break something. The overwhelming majority of software projects provide some means of adding test coverage, it's usually just a matter of finding the right point to start, and then incrementally improve.

One of the biggest issues with writing tests is the learning curve. Some test systems, like the Behat system used in many PHP communities or the Cucumber system used with many Ruby projects, provide a very English-like way of writing the tests. While these can lower the technical bar to writing tests so someone doesn't have to be a super skilled developer to work with them, there is still that initial "what am I doing" hand waving part of the learning curve that everyone goes through.

To work around the learning curves it should be possible to find either online materials or even some consultants who could provide training. Something as intricate and, honestly, confusing as test writing is something that should be done as a group exercise where people can learn together. Maybe it'd be worth doing a series of afternoon workshops once per week for a month - tools like Zoom, Google Hangouts, etc can help for folks who work remotely. At the very least, time on the clock and learning materials should be provided to help staff learn what could significantly help improve the team's work quality.

4. Provide time to work on non-coding tasks, e.g. documentation, project triage, regional event attendance / participation / organization

Not everyone writes software, and not everyone needs to. There's far more to software projects, especially open source software projects, than just the code. Likewise, there's more to a business than its website's software.

Consider getting the business' marketing department to help with outreach and targeted marketing campaigns. Consider having designers and UX specialists work to help make the software easier to use. Consider having content strategists, technical writers and trainers improve documentation and plan educational materials. Consider having project managers help others manage their team's responsibilities and identify priorities.

5. Commit to working with contractors / agencies who are active contributors to OSS

There are many contractors, development studios, and digital agencies, like Mediacurrent, which dedicate a portion of their work week to furthering the OSS tools and communities they use and are a part of. Consider making it a requirement that any agencies or consultants hired must have a history of such dedication to supporting the tools their careers depend upon.

6. Invest license savings into contributions

Businesses saving hundreds of thousands or even millions of dollars (or Euro, or ringgits, or..) could look at reinvesting a portion of those savings into supporting the software they're tying their business' future to. If a software product saves $100,000, consider spending $20,000 of additional staff time, or consulting, to help improve the software and its community. If the software saves $1m or more, consider hiring staff members to work exclusively on improving the software. In short, maybe contributing to OSS should be considered a philanthropic endeavor that money can be thrown at?

That's not all, folks!

The above should not by any means considered an exhaustive list. There are lots of other ways for an organization to give their staff time on the clock to help maintain the tools, projects and community the organization depends upon. Likewise, there are lots of other reasons why an organization should do so in the first place.

At this point, ask yourself: how could your organization help? How could you, as an individual in your organization, help?

Addendum

While OSS can be a tremendous boon to a business or organization, every effort should be made to ensure that the business needs in the software are handled inside of standard office hours. Just like it is unfair to push staff to work longer hours for often arbitrary business goals, it is equally unfair to push OSS contribution responsibilities onto staff to work on their own time. While there can obviously be times when the organization needs to limit focus on nice-to-have projects to complete certain business goals, every effort should be made to ensure the overall contribution inertia continues.

Damien McKenna Thu, 08/16/2018 - 17:05

Services

Development

Tags

Business

Friday 5: 5 W's of Business Analysis

Mark Casias — Fri, 04 Aug 2017 15:36:09 +0000

Friday 5: 5 W's of Business Analysis

Happy Friday! This episode we are talking to Sr Business Analyst, Bill Shaouy, to talk to us about the who, what, where, why, and when for preforming business analysis on your website.

Mark Casias Fri, 08/04/2017 - 11:36

Tags

Friday 5

friday5

Business

How to Budget a Drupal Project

Mediacurrent Team — Mon, 10 Oct 2016 21:06:09 +0000

How to Budget a Drupal Project

…(silence)

This is what I hear most often when asking an organization what amount of money, or budget, they have set aside for their website project. Am I surprised? Not really. An enterprise website is a complex piece of technology - a software application. Ten years ago, the complexity of an enterprise website was far less than it is in 2015. If you have ever been involved in buying web development services over the last 2-3 years, you understand this. But, even a buyer who has procured these services once or twice often isn't adept at aligning their organization's digital needs with a reasonable cost for fulfilling them. Why? Web technology and digital marketing constantly evolve and unless you are involved in the procurement process for web services on a monthly basis, it's difficult to know what solutions and approaches are efficient, maintainable, and cost-effective.

RFP - The Best Starting Point?

There are two different approaches I typically see. I’ll start with the approach I observe in about half of our sales discussions and one that rarely works successfully. In an attempt to bracket or gauge what their budget should be, some buyers will issue a Request for Proposals (RFPs) that generally describes the business problems their website needs to resolve, goals for the project, and brief descriptions of functions and features at a high-level. They’ll receive quotes from multiple vendors and isolate how much they think they should spend based on the pricing proposed by each vendor. Seems like a widely adopted process that any average person shopping for a service would take, right?

Here’s the problem: if you cannot describe your vision in a way that’s detailed and representative of the entire website you want designed and built, down to the navigation, buttons, forms and information that will appear on each page, a vendor won’t be able to define an accurate price. Consequently, the final number you establish for your budget will be misinformed. There’s a high likelihood the quotes you receive will be all over the map, ranging widely from low to high. The inherent risk that lies in budgeting via an RFP is you and the vendor may seemingly be “on the same page” with regard to time, effort, and money required to execute the project described in your RFP when the project actually begins. But, after being multiple weeks or months into the project, both you and the vendor realize that the vision described in your RFP simply wasn’t detailed enough and misrepresented the true scope of the project. Consequently, your website may not launch with all the features you would like or your website launches with your desired features but the project goes over-budget.

A Detailed Plan Aligns Everything

A better, less risky approach to establishing a project budget is, as a first step, to plan your vision clearly. Research other websites and mobile apps to determine what features and functionality they use that would also help solve your digital marketing and communications problems. If there are departments in your organization that have a stake in parts of the website, get them involved early in the budget definition process and ask them to clearly articulate their business needs for the website so you can include those needs in your plan. When buying Drupal services specifically, it’s important to understand that Drupal’s true value proposition lies in thousands of modules that have already been programmed to manage content and demonstrate website features. Aligning your vision with popular Drupal modules and their features helps mitigate scope creep and keeps cost lower compared to heavily customizing Drupal.

Keep in mind that your website doesn’t stay the same indefinitely after launch. Content, features and navigation will likely need to evolve along with your organization’s industry vertical and business strategy. The post-launch period is the best time to create and install features that weren’t included in your website’s initial launch. Drupal’s modular architecture is ideal for this type of iterative deployment. Prioritize what’s most important for launch and what should be accomplished after launch. Taking time to clearly describe in written form how you need your website to look and function before establishing a budget will bridge the inevitable money gap that would have a high probability of occurring without a clear, detailed description. The best documentation includes an outline of navigation, descriptions of which audience(s) will use the website, a general explanation of each page’s purpose, and a sketch or wireframe of each type of page with explanations of how users should interact. Furthermore, prioritize the features that are most important.

Here’s an example of a poorly written requirement summarizing how a form feature should work compared to a well-written, detailed requirement:

Poorly Written Requirement	Well-written Requirement
Account registration form.	Account registration form. Anonymous users need the ability register for an account using a web form. User registrations should be validated via email. The web form will contain 3 form fields: E-mail address Password Name E-mail address and Password fields are required.

After you’ve documented your vision in detail, ask vendors for a price range, and only a price range, as opposed to a single price and/or a proposal. Every website project Mediacurrent works on is a unique creation. Some are more similar than others, but in the end each has its own blueprint, like a custom built home. So, accurately estimating the price down to the dollar without detailed documentation for each page and feature of a website is extremely difficult. Once you’ve received price ranges from several vendors, you’ll have enough of a sampling to hone in on a budget number you’re comfortable with.

What if you know you need to change your website or need a new one but don’t know exactly what you want? Engage a Drupal vendor to do pure consulting - no development/programming work. We work with many organizations that do not have the time or the skill set on their team to research and document their vision for their website. A Drupal services vendor can facilitate the research and requirements definition process by educating and guiding an organization’s stakeholder group. It’s not a one-day, two-day or week-long process. In most cases, it takes anywhere from 60 to 200 hours for our team to collaborate with an organization to fully define requirements, digital strategy and the technical architecture that their website will be built on - a process we call Discovery.

To recap, the steps for defining an enterprise web project are:

Research other websites, document layout, features and functionality that are important.
Garner feedback from departmental stakeholders that have a vested interest in the website. Include them in the process early and seek budget from their departments.
Educate yourself on how the open source web development process works - leveraging modules’ out-of-the-box functionality as much as possible, limit custom development work.
Prioritize critical features - what are must-haves and nice-to-haves?
Establish a not-to-exceed number that’s been approved by the CFO and other departmental stakeholders. Include a smaller contingency budget within that number for any unknown requirements or expectations that could crop up during the project.

Tips:

If you don’t have an approved budget, you’re not serious buyer. When you have an approved budget, quotes you receive from web agencies tend to be more accurate and inclusive of solutions that can realistically be delivered within that budget without the risk of the vendor’s billing exceeding the original quote.
If you haven’t established a budget and you don’t have a clear vision for what you want, you aren’t equipping yourself to make the wisest decision on which vendor to select (you’ll end up in the RFP problem mentioned earlier).
Ask others in your organization if they’ve hired an agency to build a website and what they paid. Be sure to find out the level of quality of services the agency delivered.
The more complex your needs and vision are, the more time and money will be required.
Just like anything else you buy, you’ll get what you pay for. Good talent isn’t cheap. Your budget should account for this.

Mediacurrent Team Mon, 10/10/2016 - 17:06

Tags

Drupal 8: The Future is Now

Dave Terry — Wed, 07 Oct 2015 21:48:56 +0000

Drupal 8: The Future is Now

Today, the Drupal community has officially released the first release candidate of Drupal 8, with the final release imminent. This is a historic day for Drupal, the open-source content management system that powers your website as well as millions of other web properties in the world. This release has been 4+ years in the making, had 3000+ code contributors, and represents a huge opportunity for you. We believe your presence on the web is the single greatest marketing tool that exists within your organization. Even if a major site redesign is not on your short-term horizon, we highly recommend educating yourself on what this release means to your organization. Here are some key items of consideration:

1. There are over 200 significant improvements to Drupal 8. These changes include “mobile first” functionality, extensive multilingual capabilities, built-in web services, a robust configuration management system, and WYSIWIG features that are much more authoring friendly for content administrators for "non-technical" users.

2. Drupal 8 leverages the Symfony2 framework and the most proven and scalable technologies available. If you have an in-house team that helps support your Drupal properties, we have already started on custom training programs that will help further assimilate your organization to Drupal 8. This will be particularly critical for retaining developers that want to learn Drupal 8's cutting-edge technologies.

3. Lead the charge for web accessibility. Statistics show that up to 20% of the global population is affected by some form of visual, hearing, cognitive, or motor disability. Now is the time to make your organization’s web presence accessible to all users. Drupal 8 has adopted standards like HTML5 and the Web Accessibility Initiative’s Accessible Rich Internet Applications Suite (WAI ARIA) that are critical for disabled users to have a positive experience.

4. Be an innovator. Open-source software continues to revolutionize the technology industry. Mediacurrent wants to help you stay ahead of your competition, some of whom are still using outdated, legacy based content management platforms that charge licensing fees. Knowledge is power.

5. The future is now with D8. The international Drupal community only supports the two latest releases of Drupal. This means that if your site is on Drupal 6 (or an earlier version) the modules used to maintain your site will eventually be deprecated.

Our team at Mediacurrent has hundreds of years of collective Drupal experience. We are passionate about supporting our customers. Let’s continue the conversation and assess how Drupal 8 aligns with your strategic planning.

Additional Resources
The Great Drupal 8 Debate | eBook
Manhattan Associates Drupal 8 Redesign | Case Study
Intro to Drupal 8 Vocabulary | Blog Post
Drupal for Marketers Part 1 and Part 2 |Blog Post

Dave Terry Wed, 10/07/2015 - 17:48

Tags

Drupal 8

Drupal

Business

Business Models of Drupal Distributions

Mediacurrent Team — Sun, 27 Feb 2011 13:36:28 +0000

Business Models of Drupal Distributions

This blog post is part of a series on Drupal distributions.

If you stay up-to-date in the world of Drupal news, you've probably read that Phase2 Technology has recently acquired Development Seed's Drupal distributions, OpenAtrium and Managing News.

Development Seed is one of the most innovative companies that do Drupal work, and its distributions (especially OpenAtrium) are two of the most widely used. Phase2 is a much larger company, and the primary reason both companies cite for the acquisition is that Phase2's additional resources make it better able to support the distributions.

This change has prompted several troubling questions from the community. Perhaps the most prominent: does this mean that Development Seed is leaving Drupal? And the first one to my mind: does this mean that building Drupal distributions -- a topic heralded as a major component of Drupal's future growth -- is financially impractical for smaller Drupal firms or individuals?

After much consideration and reading, I believe the answer to both questions is "no."

Development Seed, as its president Eric Gundersen is quick to point out, is a "product company." They build products because they want to use them. Their company culture revolves around coming up with innovative ideas and implementing them very effectively. OpenAtrium, for example, was built because the DevSeed team needed an intranet. It just happened to turn out that a lot of other companies did too.

Phase2 is a much bigger company. Phase2 has its product arm which has produced its own innovative distributions like OpenPublish, TattlerApp, and OpenPublic, but it also has the resources to provide serious support for the products it maintains. For example, Phase2 has just announced new support packages for OpenAtrium that Development Seed was simply too small to manage.

So ultimately, it looks like the reason for the sale of DevSeed's properties was that they have matured into full-fledged, production-ready products. DevSeed's work is done. They built amazing products that work really well for lots of people -- but now those people need support, and DevSeed decided not to shift its company's focus in order to provide that. Phase2 already provides comprehensive support. It's simply two different business models: where DevSeed makes money by being paid to work on developing new products or improving existing ones, Phase2 also makes money supporting existing products. One is not better than the other, and they're certainly not mutually exclusive at Phase2; but DevSeed chose to focus on product development over product support. Support is a business model of scale, and Phase2 has scale.

Seen in this light, it seems likely that Development Seed is not done with Drupal; they're simply busy working on other projects at the moment (involving mapping, apparently). I think we can expect more innovation to come from them in the Drupal world if their developers see a need for something new and awesome for which Drupal would be the best solution. In the mean time, the sale of their properties to Phase2 gives them more capital with which to continue developing rather than supporting.

Similarly, the purchase of OpenAtrium and Managing News by Phase2 does not imply that it is financially impractical for smaller Drupal firms to build distributions. It simply shows that different business models work better in different situations. Development-focused firms can get paid for building new distros, while support-focused firms can get paid for supporting them. If you're big enough to have more than one focus (or at least if you're willing to scale), you can do both. (If you're part of a Drupal firm thinking about building a Drupal distribution, start with the documentation.)

Congratulations and good luck to both Development Seed and Phase2. They are both great companies that have played a very positive role in the Drupal community. I look forward to seeing what they're working on next!

Isaac Sukin is a student at the Wharton School at the University of Pennsylvania. He has worked with Drupal since 2007, and is particularly interested in Drupal as a social networking platform. He interned at Mediacurrent during the summer of 2010 and continues to do guest blogging. You can follow him on his blog or on Twitter.

Mediacurrent Team Sun, 02/27/2011 - 08:36

Tags

My (Drupal) Google Summer of Code Experience

Mediacurrent Team — Fri, 27 Aug 2010 13:00:00 +0000

My (Drupal) Google Summer of Code Experience

This summer I was a mentor for the Google Summer of Code program for Drupal. I maintain the Facebook-style Statuses module, which allows users to have a stream of “status updates” on their user profiles and to write messages on other users’ profiles, like Facebook. So when I had the chance to mentor the Facebook-style Micropublisher proposal, which built on Facebook-style Statuses to allow attaching images, links, and video to status updates, I jumped on it.

The result was a resounding success, and I learned a lot during the process. Nitin Gupta, the student driving the project (and better known to some as publicmind) was an extraordinary developer in the true Drupal spirit. He gracefully put up with my pickiness about coding style, thoroughly researched the best code architecture for our purposes, and even identified places where Facebook-style Statuses itself could become more flexible. I truly believe that Nitin will remain committed to the module he created, and that both of us are better Drupal developers as a result of this process.

The Background

Long before the 2010 Google Summer of Code (GSoC) process began, I identified two major areas where Facebook-style Statuses (FBSS) could be improved. The first was abstracting status updates from users to allow creative solutions like FBSS as a replacement for the core comment module or status streams attached to Organic Groups. (Actually, although I had long thought about Organic Groups integration, that level of abstraction was Michelle Cox’s idea.) That effort is currently underway in the form of a new Facebook-style Statuses 3.x branch, since it requires rewriting thousands of lines of code and significant changes to the API and database schema.

The second was attaching data to status updates – links, images, and video, but also audio, files, or anything else within reason. I wanted an extensible system held to very strict stylistic and architectural standards, but I knew that this would also require thousands of lines of code, and I didn’t have the resources in time or funding to get started. Then Thomas Cermak contacted Nitin and me in February to discuss building out this second feature, which we eventually dubbed the “Micropublisher.” Nitin had first worked with FBSS in September 2009 when he had contacted me to ask about how to make some changes to it for a now-deprecated Facebook-style Links extension. At that point he didn’t even know what hook_form_alter() was, although he was a capable programmer outside of Drupal. Now Nitin was to take on the bulk of the work for this new, complex initiative because of my lack of time. We discussed and settled on an outline for development, and then on March 24th Nitin realized that the recently announced GSoC 2010 would be a perfect opportunity to gain support and exposure for the project. He submitted it and invited me to be a mentor, and real development work began soon afterwards.

The Process

Nitin’s skills were immediately apparent. I had an email (or six) from him nearly every day for the first month alone, in addition to commit notifications from the SVN repository where we developed until the project moved to the CVS repository on drupal.org. I reviewed Nitin’s commits every day and gave feedback. We often discussed the best way to implement various features and sometimes I explained new techniques, but usually I just had a list of places where Nitin had neglected to insert whitespace in control structures as recommended by Drupal’s coding standards.

I never had to say “rewrite this part, that code is unreadable…”

That is to say that Nitin made my job as mentor much easier than it could have been. I never had to say “rewrite this part, that code is unreadable” because Nitin researched everything before he acted, although I did try to ask “why did you do that this way?” frequently. I had a list of tasks I wanted Nitin to complete, and he was ticking them off faster than I had anticipated. By mid-June, the fundamentals of the new Facebook-style Micropublisher module, or FBSMP, were stable enough that I could preview its awesomeness in a presentation at Drupalcamp South Carolina / SouthEast LinuxFest. In late June and early July, Nitin took a vacation, having graduated from the prestigious Indian Institute of Technology at Guwahati. This made me nervous. After a prolonged period of frequent communication, we were communicating much less frequently, right in the middle of when most GSoC students are at their most active. The fault was mostly mine; I neglected to check up as often as I should have because it was not something I had had to consciously think about before. It was just something we did. This was also when we transitioned to using Drupal.org for version control, so I wasn’t receiving commit notices any more from the SVN repository, which made it harder to keep up with and review changes. It turned out that I had no need to worry, because Nitin stayed on task and completed everything we had planned. In the end, I was the one who was unable to do everything I had promised, because I didn’t keep track of the GSoC schedule and inadvertently planned a trip to Italy two weeks before it ended. Luckily Nitin had progressed so far by that point that it hardly mattered, and I’m extremely pleased with the end result.

Advice for Future Mentors

Explicitly schedule time at least twice a week to catch up with your student and discuss his or her progress. The more real-time it can be, the better; email is great for expressing complex ideas precisely, but in-person meetings, phone calls, and IRC chatting are better for hashing out problems and getting things done. Unfortunately, because Nitin is in India and I am in the United States, we weren’t able to talk in real time very often.
Choose a project that really excites you. If you are not personally invested in the outcome of the project, it can be difficult to fulfill your end of the deal; you will prioritize daily work-related tasks over reviewing your student’s code, and neither of you will benefit as a result. Since Nitin’s work directly enhanced the value of my own work – and because it achieved one of my two main goals for FBSS – I was very interested in making sure the project not only succeeded, but also met a strict set of goals and standards.
Outline your mutual goals with your student before you begin development, including how and when you plan to accomplish them. Some developers embrace chaos, and that’s fine in some cases, but as a team you need to be able to hold each other accountable. Be realistic, and schedule in time to make mistakes. Before Nitin and I started, I created an outline of the features I wanted completed and the standards by which I wanted them coded. Despite this, I made sure to leave room for flexibility and innovation – too tight a leash wouldn’t have let either of us learn anything.
Clearly establish what role each of you will play. From the beginning, I made it clear that I wouldn’t have time to participate in much of the actual programming, but that I would be setting most of the strategy and reviewing the code as often as possible. Although my contribution on the second point slowly declined over the summer, I think that my approach helped Nitin learn a lot about problem-solving and Drupal.
Write down due dates! I didn’t put them on my calendar, and as a result I ran out of time to do a final, overall review of the module before GSoC officially ended.
The process doesn’t end when the summer is over. Make sure that both you and the student understand that you will have some amount of responsibility to maintain your creation. Have a plan for what will happen when GSoC ends; for example, FBSMP will be folded into FBSS soon after the upcoming FBSS 6.3.x branch is upgraded to Drupal 7.

The Result

To be honest, I wasn’t sure what we were trying to accomplish could be done in a summer – but I am happy to say I was very wrong. I can now say that Drupal has a full Facebook-style Micropublisher, complete with link, image, and video attachments (as well as a thorough API, an extensible plugin system, and documentation for everything). You can see for yourself how cool this is on the demo I set up for the two presentations I’ve given on Social Networking in Drupal. (It’s now possible to build full-featured microblogging platforms like Twitter and Facebook in Drupal!)

It’s now possible to build full-featured microblogging platforms like Twitter and Facebook in Drupal!

Nitin was a pleasure to work with, and I look forward to continuing to work with him as we transition FBSMP to a central part of FBSS in Drupal 7. It is very clear how much he learned about Drupal, and I commend him on his ability to soak up information and come up with creative solutions. I am happy to say that Nitin also seems to have adopted Drupal’s coding style rules as a result of my incessant demands! I’m quite sure that he will continue to be a valuable contributor to Drupal’s ecosystem in the future. As for me, I learned a lot about remote project management, and I also learned some valuable lessons from a number of times when Nitin asked for changes to the FBSS API to make FBSMP development easier. I had never actually had a reason to use my own API in the wild before, since I could just change the source if I needed to. It was fascinating to see my successes and failures in predicting how the API would need to be used. There’s still quite a lot to be done. There are some inconsistencies in FBSMP that should be worked out, a CTools dependency that can probably be removed, some potential UI improvements, and of course the port to Drupal 7. But for a single summer’s work, I couldn’t be happier.

Mediacurrent Team Fri, 08/27/2010 - 09:00

Tags

An Analysis of Acquia's Drupal Commons

Mediacurrent Team — Thu, 19 Aug 2010 13:00:00 +0000

An Analysis of Acquia's Drupal Commons

Drupal Commons (DC) is a Drupal distribution billed as “social business software.” That means that Acquia is distributing Drupal bundled with some other modules preconfigured to work as a company’s interactive user-facing website. The most recent DC update 1.0 was released on August 5th.

What is Drupal Commons?

I talked to Jay Batson (vice president and co-founder of Acquia) while writing this article and he confirmed what Dries Buytaert himself had implied in a blog post: the goal of Drupal Commons is to compete with the likes of Jive SBS and Telligent. Jive and Telligent are expensive software designed to allow easily setting up a business-oriented social website. Acquia started working on DC in response to inquiries from large, multinational companies who were frustrated with the limitations of the proprietary social enterprise software choices. They liked the flexibility of Drupal, and were willing to pay for it – but they weren’t comfortable starting with “just” a framework. They wanted a base on which they could build, something that they could market to their CEOs as “enterprise-ready out of the box” while still being easily extensible. These companies are the target market for DC; they’re the ones who want to pay for the services surrounding it.

…the goal of Drupal Commons is to compete with the likes of Jive SBS and Telligent.

Jive and Telligent have a 4 and 5-year head-start, respectively, and Acquia knows that it will need to keep working on Commons to displace them. But the very existence of DC is enough to make its competitors feel the heat. Unlike Jive and Telligent, Commons is free as in beer. It’s also open-source and (because it’s based on Drupal) has a vast library of extensions that make adding additional functionality almost as easy as clicking a checkbox. Perhaps most importantly, it’s totally extensible. Drupal is a framework; it’s designed so that any part of it can be modified or replaced. According to Jay, much of the enthusiasm Acquia has heard about Commons is from companies ecstatic to be liberated from the restrictions of the very limited APIs that accompany proprietary software. No longer do companies have to be held back by a roadmap of features that will never get written; in the rare case that a Drupal module doesn’t already exist for the purpose, it’s possible to create a new one that does the job. Not so with Jive and Telligent. It’s not as if Commons is lacking in default features, either. Acquia has focused on the right features to meet the needs of very large companies. The result is a solid starting point for large businesses to make the transition to building relationships with their customers over the internet. DC provides a fairly complete business-oriented community structure out of the box. Oh, and did I mention that it’s free? That fact alone dramatically reduces the risk of experimenting. The tech guys can install it on their local computer, test it out, let the manager play with it, and decide if it’s something that could benefit their company. That’s just not possible with Commons’ competitors, whose fees are prohibitively steep.

Social Networking vs. Social Enterprise

Drupal Commons is not designed to be a social network – it is designed to be social enterprise. Here’s the distinction: social enterprise sites are designed to be administered by a privileged group representing a company – a group that moderates posts and answers questions on a website devoted to discussing a brand or products. (Interestingly, Jay told me that Acquia had allowed all users to create and moderate groups until a few days before launch, when a number of beta-testing companies pushed back.) Norton’s Symantec community is a good example of an enterprise social community. In contrast, social networks are designed to be free-for-all sites focused on users and their content. Facebook is the pinnacle of social networks.

So let’s be clear: Drupal Commons is not a social network like Facebook.

The category Commons falls into is clear from the default User Roles alone: in addition to the standard Anonymous and Authenticated users, DC provides a Community Manager and a Content Manager role. On a social networking site, all users would be content managers, and community managers would be global administrators. What concerns me most about Commons is the gap between the audience it was designed for and some of the audience that will actually use it. Acquia is probably the most high-profile company in the Drupal community, so when they advertise a product as “social,” the large (but less lucrative) community of people looking for an easy way to build a user-oriented Facebook-style website will be attracted – and then disappointed. Jay assured me that if Acquia saw a demand at the business-customer level for a traditional social networking site, it would look into developing a solution – and while I believe him, I don’t think either of us really expect that to happen. So let’s be clear: DC is not a social network like Facebook, Twitter, LinkedIn, Flickr, YouTube, Buzz, Digg, Reddit, Care2, or TakingItGlobal. DC is an enterprise social platform like Jive and Telligent, and it’s a fairly good one. There will be people who abuse that distinction, but no one will ever be able to stop people from misusing tools or not reading the documentation. By the way, if you’re looking for a way to build a site like Facebook using Drupal, I can show you how to do it.

Flexible vs. Beautiful

There is a bit of a conceptual conflict inherent in Drupal Commons. Commons is designed to be something usable out of the box – something you can install and show your boss in under 15 minutes. At the same time, the incredible power (and in some cases, complexity) is still available, and that creates some interesting paradoxes. For example, DC includes a custom theme based on the powerful Fusion base theme. It’s not very pretty, but it does have some customizations that make using Commons a little more fluid. According to Jay, the theme was intentionally designed to be flexible rather than beautiful so that companies could easily brand the theme in their own way. That wasn’t an arbitrary decision; it was something they got a lot of feedback on from the large companies testing the product. Some had tried OpenAtrium before (an out-of-the-box intranet based on Drupal) and had trouble customizing its default theme.

Drupal core is supposed to be “flexible rather than beautiful,” while Commons is supposed to be the awesome out-of-the-box experience.

However, it’s an ironic choice. Drupal core is supposed to be “flexible rather than beautiful,” while Commons is supposed to be the awesome out-of-the-box experience. And Fusion is so amazing as a base theme that creating a separate Fusion sub-theme instead of forking the default Commons theme is relatively easy and practical. When I said this to Jay, he responded that I “spoke like a Drupal expert.” If Acquia was building websites using Commons, he said, they would probably create a subtheme of Fusion instead of modifying the Commons default theme. But because of Commons’ target audience, the people who will usually be branding a website’s theme will be the IT department at large multinationals. They will know enough CSS and HTML to play around with the default theme, but they won’t know enough about Drupal to create a new one. If they hire a Drupal company to build the theme, then that company should know enough to build a complete theme. You’re probably beginning to see how much Acquia’s target audience influenced their design decisions. Luckily for smaller companies, and unlike with proprietary software, it’s easy to just switch out the default theme with one of the hundreds available on drupal.org. Another interesting example is the actual decision companies have to make to use the DC install profile rather than the Drupal core install profile. Acquia learned from Red Hat’s approach on this front. Commons, like RHEL, will attract business people – decision makers – because of the marketing language around it. Commons is billed as a Jive and Telligent competitor, which makes sense to executives. It’s presented as an out-of-the-box solution, which sells well to your boss. Acquia supports it, which the I.T. department appreciates. Drupal core doesn’t have that reputation, even though experienced Drupal developers can make any kind of website with it. As a result, the kind of developers that large companies with lots of money might hire might be able to scaffold the exact requirements of the business more quickly if they started from the core install profile instead of dealing with the assumptions DC makes about the use cases of its intended audience. (Either way, companies will be able to build enormously powerful websites that do exactly what they want. It’s just a question of how quickly.) On the other hand, it seems to me that Acquia has pretty much gotten those use cases right, in which case building on top of Commons makes complete sense.

What’s Inside

Drupal Commons revolves around Organic Groups. A Commons-based website essentially consists of a bunch of groups, each of which can have their own forums, wikis, blogs, documents, polls, and activity stream. There are also userpoints, email notifications, bookmarks, user relationships, and a WYSIWYG editor (CKEditor, to be precise). Users and groups have pretty comprehensive dashboards that can be customized by administrators. Basically, these are the right features to have for an interactive corporate site, and they work as advertised. They’re also essentially the same features you would get if you installed the same modules as Commons on another site, albeit with some saner default settings.

These are the right features to have for an interactive corporate site, and they work as advertised.

Moshe Weitzman (the original author of Organic Groups) has a nice post analyzing the choice of modules, and I generally agree with him, although I’d like to reiterate two points. First, Heartbeat was an odd choice over Activity 2.x (and the much lesser-known Message). My theory about Heartbeat is that it was chosen because although Activity 2.x is fairly stable it doesn’t have a stable release. The way Commons uses Heartbeat, it is nearly functional identical to Activity 2.x, with the main difference being that Activity uses historical records while Heartbeat does not (a minor technical detail). I say that Heartbeat was an odd choice mainly because Activity has 5 times as many users and its code is more Drupal-y. They’re both actively developed although the Heartbeat issue queue is more aggressively maintained. My second gripe is with the rules for which passwords are allowed. Weitzman wrote that “Password Policy should be classified as torture” – but this is not true. The DC password rules are torture, yes, but the fault lies wholly with Acquia. Commons configures the password rules during installation to be inhumanly obnoxious. It would have been enough to require that passwords be a minimum of 5 characters long, which the Password Policy module can happily do. Luckily, the Commons defaults are not written in stone. I’d also like to point out that the custom module Acquia wrote to display statistics to group moderators (called Quant, and now available on drupal.org) is pretty sweet. Thanks to my senior-year AP Statistics teacher Jason Smith, I’m fascinated by statistics, and I’ve tried and failed to write a comprehensive, extensible module to collect and display stats about a Drupal installation without writing dozens of complex SQL queries. To whichever Acquia engineer wrote the Quant module, please accept my hearty congratulations. For more about what you’ll get when you install DC (and why you should do it), take a look at the features and benefits Acquia lists. My favorite feature: “Oh, and it’s Drupal.” That implies security, quality, internationalization, extensibility, and scalability. Drupal’s greatest strength is its flexible API and module repository, so it’s easy to build on Commons to add additional functionality as you see fit. My favorite benefit: “Drupal Commons creates the online conditions that permit happy serendipity to emerge from your community members.” Okay, so it’s an arguable point, but “happy serendipity” reminds me of gumdrops and lollipops.

Final Thoughts

Before I got off the phone with Jay Batson, he said, “if there’s one thing I hope that you take away from this conversation, it’s that this is version one.” There were lots of features Acquia considered for inclusion in DC and ultimately they chose to focus on the ones that were most important to their target audience and then get a release out the door. There will naturally be some growing pains, but there is an enormous upside for Acquia, Drupal, and Commons users. Acquia is committed to the continued evolution of DC and the first version is a worthy launching pad. Future features will likely include group hierarchies (basically allowing sub-groups) and user-configurable dashboards. Other possibilities include document hierarchies, contact lists / newsletter ability, and tweaks to the Calendar system.

Companies looking at Drupal Commons for a social enterprise solution can be assured that they will not be left in the dark.

Drupal Commons has a few advantages over its competitors by virtue of being an Acquia product. There’s the technology – Drupal, of course – but there’s also Acquia’s hosting, support, and training services. Acquia will host a DC installation for you, provide support to help you configure and maintain it, and train people in your company to moderate it through partnerships they refer to as the Community Roundtable. As a result, companies looking at DC for a social enterprise solution can be assured that they will not be left in the dark. As large companies embrace Drupal through Commons, the result will help Drupal become a better framework. They will fund features and patches (as they have already done through Acquia during the Commons development process). And these improvements will help the community grow. It’s worth noting that DC is built on Drupal 6. At the time of this writing Drupal 7 was still in alpha, and while the D7CX movement has done admirably well, not enough contributed modules have upgraded to make a Drupal 7 version feasible yet. DC is also designed for stability, and Drupal 7 won’t be officially stable until the full 7.0 release. Contrary to the hopes of some, DC should not be mistaken for a user-focused social network. Instead, Commons is aimed at large companies, and it is a great choice for that audience. I also foresee DC being particularly useful for in-house developers with less Drupal experience and for small- and medium-sized companies looking to use Drupal as a springboard for building better relationships with their users. Acquia’s DC provides a flexible social business platform out of the box. Version 1.0 is a solid foundation for future growth, but there’s plenty to like right now. Unlike its competitors, Commons is free and open-source, which means it’s easily extensible with custom code or the thousands of Drupal modules and themes. Commons is a fantastic contribution to the Drupal space – so go try it out! Many thanks to Jay Batson for taking the time to talk to me about DC and clear up a number of questions I had about it. I’m encouraged by this level of outreach and community participation – in keeping, of course, with the spirit of DC.

Additional Resources:

What is Drupal? | Mediacurrent Video

Maps and Drupal 7 | Mediacurrent Blog Post

Webinar: Services 3.x Module

Mediacurrent Team Thu, 08/19/2010 - 09:00

Tags

Autotrader.com Launches Drupal Car Buying Site

Mediacurrent Team — Thu, 05 Aug 2010 05:30:38 +0000

Autotrader.com Launches Drupal Car Buying Site

DrivenByYou.com represents a new approach to buying cars online. Traditional online car buying guides users to shop for automobiles by selecting a make, model or year as the first step of the buying process. Autotrader.com decided to take lessons learned from shoppers at brick-and-mortar auto dealerships and apply them to an online car buying experience. Realizing that most brick-and-mortar car buyers seek out local dealership offers and specials prior to selecting a make and model, Autotrader.com sought to make online car shopping easier and more intuitive. By applying the same "first step" that car shoppers normally take when shopping local dealerships in person, DrivenByYou.com facilitates a quicker method for buyers to drill down to a vehicle that's within their purchasing budget.

To create this new type of car shopping experience, Autotrader.com partnered with Mediacurrent to build a unique Drupal solution. Drupal was a natural fit for the project because of its highly flexible framework and the project's compressed timeline for site launch. Drivenbyyou.com employs an array of standard Drupal core and contrib modules that allow it to ingest a nightly vehicle inventory feed with over 12,000 records, download thousands of vehicle photo files, and associate promotions with hundreds of vehicles across 40 auto dealerships with a few mouse clicks. Drupal's theming flexible theming layer gave Mediacurrent the ability to integrate a customized clean, modern user interface design with an emphasis on simplicity.

Overall, Drupal was the linchpin in the timely launch of DrivenByYou.com. Its vast number of available modules allowed Mediacurrent to build an extremely complex and feature-rich site quickly. Read the case study to learn how the Mediacurrent team built DrivenByYou.com and let us know what you think!

Mediacurrent Team Thu, 08/05/2010 - 01:30

Tags

Atlanta Drupal User Group

How I Got Involved: Social Networking in Drupal

Mediacurrent Team — Tue, 29 Jun 2010 02:46:15 +0000

How I Got Involved: Social Networking in Drupal

I got involved with Drupal in 2007 when I decided I wanted to build an online community of young people interested in politics in order to encourage their interest and activism. I was in way over my head; I had dabbled with a number of desktop programming languages, but I had never built a website. I got my first hosting account on my dad's recommendation, and it came with an installer for a large number of open-source software in a variety of categories.

I researched each one, and it ultimately came down to Drupal or Joomla! as the only options that could potentially fulfill my vision of vibrant forums, in-depth blogs, stunning image galleries, relevant news, timely events, thorough user profiles, and close-knit groups. I ended up choosing Drupal 5 mainly because, as someone who had no idea what a CMS was, Drupal.org actually explained what Drupal was supposed to do for me. I was also put off by the number of paid add-ons for Joomla!, as my budget was zero.

What I wanted to do was build another Facebook. I wanted to attract young people, to draw them in through the social aspect and then interest them in the content. I instinctively gravitated toward social networking because I knew from experience that it works. (The average Facebook user spends 15 minutes every day on Facebook – by far the most among the top websites in the world.) And I wanted to build a site that was fun, engaging, and ridiculously full-featured.

After several months of struggling and countless moments of enlightenment (for example, I realized that having 200 items in your primary menu is not a good site structure) I got pretty close in the feature department. I had built a website with most of the major features I'd wanted, albeit with a tasteless theme and a terribly clunky UI. And then, like millions of other hapless webdevs before me, I waited, and wondered why people weren't flocking to my site.

The end of this story is that after a lot of work the site hit a peak around the 2008 elections (some 20 active users, 400 page views/day) and then died off a few months later when I stopped having the time to take care of it. But I learned that a site doesn't need all of the zillions of things I wanted to add in order to be awesome. At one point I was running about 80 modules with no end to memory issues and extraordinary amounts of time spent updating them. In the end I cut the site down to a few essential features and only 4 menu items and it did much better.

Out of that project grew what is today the Facebook-style Statuses module for Drupal. In the course of working on my social networking site I realized that users were shying away from blog posts (with their massive, gaping textareas begging for lengthy opinions) and forum posts (because of the intimidating nature of asking questions and writing opinions) and events (because nobody needed them) and groups (because the community was neither large enough nor cohesive enough). I decided the solution was (again) to imitate Facebook by creating status updates. Status updates, it seemed, were neither long, nor intimidating, nor irrelevant; and they were one way to ease in new users and build community. Status updates are so inviting, in fact, that almost everyone who sees a status update box will write something in it just to test it out, and they are often delighted by the result. That's certainly not the case with content types where the expectation is that each post will be a lengthy and well-informed opinion piece.

I explored a few options. I tried using a custom content type, but it was much too awkward and not at all designed for the brief, smooth experience I was hoping for. I looked for modules to help, but there were none. So I set out to build my first Drupal module, aiming for simplicity.

First, I googled how to build forms in HTML. The security issues were over my head and I couldn't figure out how to store the submitted information. Then I searched on drupal.org and discovered the Form API and SQL. (Drupal runs on a database? What a concept!) The Form API, much to my surprise, was relatively easy. MySQL was easy. And more importantly, the documentation for both was very good. That was my first introduction to Drupal as a library rather than Drupal as a platform. In fact, that was my first introduction to PHP (which also has fantastic documentation) and the first time I had really attempted anything serious in a programming language. And I really liked it.

Over the next few months I read a lot of snippets and other modules' code. I read inordinate amounts of documentation and asked dozens of dumb questions in the forums. And in the end, I had a rather pathetic textfield with a submit button and a list of recent status updates that were pulled from the database without using Drupal's API and displayed without escaping dangerous characters. It was awesome.

Within a couple of weeks I was getting almost as many status updates per day as posts of every other type of content (including comments) on my site combined.

Three years and 668 commits later, that module is very stable (and even pretty stylistically accurate). Only 1% of all issues in the queue are not yet fixed. It integrates with over 20 other modules, uses sophisticated AJAX updating, allows #hashtags and @mentions, and supports threaded conversations. And on the over 2000 websites where it's used, it's been a startling success. The demo website alone now often gets almost as much traffic as the social network from which the module grew.

What my social network needed was not to cram in every feature that Facebook had. What it needed was a way to draw in new users with a low entry barrier and maintain relationships between power users with a way to build connections and demonstrate authority and influence. Status updates, with the small, friendly textbox and instant-feedback stream, are the best way to do that. And maybe it's not the best idea to build a Facebook replica, but sites of all other shapes and sizes can similarly benefit from the boost in interest, influence, and fun that short bites of content provide to users. (In fact, I recently gave a presentation on that topic at DrupalCamp South Carolina / SouthEast LinuxFest.)

Facebook-style Statuses is now the base of a Google Summer of Code initiative (which I'm mentoring) to build a Micropublisher that will allow posting images, video, and links into the status stream. Unlike me 3 years ago, you are now able to build the essential features of Facebook in Drupal with no coding, minimal configuration, and equal ease of use. Start now!

This post is part of a series on Social Networking. Isaac has already blogged about the importance of social networking and how to build a social network. He is planning posts on the future of social streams in Drupal, social networking features missing from Drupal (and how we can fix that), Friend/Relationship modules, and integrating the Activity module with Facebook-style Statuses. You can find other posts on social networking on his website.

Mediacurrent Team Mon, 06/28/2010 - 22:46

Tags