Drupal

• August 2007: Sexism in IRC
• March, 2009: Design choices for DrupalCon Paris. Related reading: Is Drupal Full of Sexist Pigs and The where-are-all-the-women question, this time in open source.
• April, 2010: DrupalCon SF card game; the response from the creators of the game
• June, 2010: Sexism, harassment, and threats in the NYC group. There have actually been several other discussions over the years in the NYC group, but they appear to have been deleted from the group.
• August, 2010: Responses to events at DrupalCon Copenhagen; Sexism: It's Still Relevant; and a blog post with the video of the keynote in multiple sections.

So here's the thing. I'm proud to be a member of this community. The Drupal community contains some of the smartest, kindest, most generous people I have ever had the privilege of meeting. I don't think I'm overstating anything to say that my involvement in the Drupal community has altered the trajectory of my life. I have learned more in my six years of work within and around this community than at any other period of my life. It's an amazing place.

And that is why I'd like to see us do better. We can always rationalize away the things we don't like, or find ways to justify things that are distasteful.

But if you see something that feels wrong, stop and ask questions. Realize that you will need to have the same conversation, repeatedly. Realize that people will get mad at you and blame you for bringing it up. Realize that in the process of having conversations, you will learn about things that you misunderstand as well. But don't stop having the conversation, because that's how change occurs: one awkward, uncomfortable, unwanted conversation at a time.

When we originally set out to build a set of Features to support the install profile of our Knight Drupal Initiative work, we figured we would use Context to drive the creation of these features.

And this almost worked. Almost.

The Challenge

The challenge we faced in working with features involved sorting out the way Features manages dependencies. When you're setting up a feature, and especially when you're setting up a feature based on a context, the dependencies are automatically brought in and generated for you. So, most of the things that the context relies upon are automatically made a part of your feature (and Strongarm can generally grab the rest). This is great if every single one of your contexts is a completely standalone item. But, if anything in your context contains (for example) a UI element that connects over and exposes functionality that is contained within another context, then you will have two features with overlapping dependencies, and this creates conflicts.

The Goals

At the outset, we had four main goals in setting up our install profile, and the related features used within the profile.

• Create a site that someone could install and start using;
• For site maintainers/non-developer admins, make features easy and intuitive to use by creating a logical set of dependencies; aka, features should contain modular sets of functionality, and be as small and as lightweight as possible;
• Retain the ability to use features to track changes in site config over time. One of the huge benefits of Features is the ability to track changes that you make in config; using the Diff module brings more of the awesomesauce, and here at FunnyMonkey we are serious about the awesomesauce;
• Make features that are as reusable as possible.

Some Other Things That Didn't Work

Briefly, we contemplated shipping an install profile with one enormous feature. Technically, this works, and the install would have been simple, but the maintainability of this arrangement could potentially get complicated over time. Additionally, one feature that holds everything is not particularly reusable, and it doesn't reveal a clean site architecture through a set of clearly defined and managed dependencies. So, while this would have worked, and is a viable approach in some use cases, it didn't align with our goals.

The next option we considered was to use Features to define functionality, and document how to use the Context module to control block visibility and create a coherent UI to connect the various corners of the site. This would have achieved our goal of making reusable features, but it would have required non-technical users to interact with the Context UI in order to get the most from the site. Given that one of the goals of the entire Knight Drupal Initiative is lowering the barrier to entry for newer or novice users, this approach didn't seem viable either.

Hey! You Put Your Feature In My Module!

One of the many cool things about features is that it pushes config to code; to put it another way, it creates a module from config options. Like modules, features can declare dependencies. So, with this in mind, we exported some initial features that contained the overlapping dependencies as defined above. Then, we edited the exported features so that they contained just the components we wanted them to have - this process included removing the overlaps, and maintaining dependencies on both modules and other features. This allowed us to create some base features that contain the central keys to delivering the functionality - things like content types, imagecache settings, fields, etc. Then, we created some extras features that contain - for example - various views, flags, and other mechanisms used to organize information on the site. Finally, we created UI features that contain the contexts and the reactions that display specific blocks on specific pages.

As we worked on the initial site build - and the subsequent revisions of that build prior to building out features - we also paid careful attention to tags, and to maintaining some consistency with how we tagged and organized our views and contexts. This meta-organization of the building blocks within the site helped us as we got down to organizing the build into features and an install profile.

To get a sense of how this comes together, look at the screenshot below.

This page is pulled together via multiple different features, and they are tied together with a final UI feature.

Using this approach, we are able to meet all of our goals as defined above. Additionally, by separating the functionality from the UI that exposes that functionality, we provide more flexibility for people to use whatever means they want to display content. On our site, we use Context to control block visibility and other display settings. However, someone else could just as easily leave our UI features turned off and use Panels, and/or Drupal's core block visibility settings.

For another example, the home page of the site ships with a slide show, and content displayed within vertical tabs (the base theme we are using for this site is Hexagon; there is some real loveliness in there, but that's a topic for another post). This homepage is generated via a UI feature; if someone wants this UI, they can turn it on. Or, people can build out swappable home page UI features that build on the underlying components, and manage these changes via the features UI.

The down side of this approach, of course, is that you can't use the Features UI to build your feature, and the process of defining dependencies manually requires some quality time with Strongarm and the variables table.

Ideally, we could control or manually override dependencies using the Features UI, but patching Features to provide manual overrides of dependencies is no small task, and would likely come at the expense of usability.

By treating features like the modules they are, and by setting up dependencies between them, we can create small, reusable building blocks that retain the maintainability of features created via the standard Features UI. We are getting ready to release our install profile that incorporates this method of building and maintaining features; we still have some testing to do to make sure that we haven't missed or overlooked anything. And with that said, there are likely other ways of solving this, and we would love to hear about them.

The push for open data from government has been gaining momentum over the last few years. This has taken concrete shape in the form of data being released in more usable formats, including websites that are especially designed to release general data and educational data at the federal level. Some local governments are following suit.

As more datasets become accessible - and this includes comparable datasets released over multiple years - we're interested in helping these datasets bridge the chasm between data and information. It's one thing to be able to map crime incidents in a specific area between two dates. It's another thing to be able to look at some performance indicators of schools within these same areas. It's still another to be able to look at a low performing school and high performing school, and compare student to teacher ratios, the percentage of students eligible for free and reduced lunch, the number of crime reports in the neighborhood, the median income, the number of liquor licenses, and the percentage of owners to renters. By leveraging open datasets, we will enable more precise questions about how people learn, and the factors that affect learning.

In the upcoming days, weeks, and months, we will begin to document and release the beginnings of a toolkit designed to simplify building and maintaining web sites that use and display open data as it relates to education and learning. Drupal already has much of the functionality in place to support using open data, and the Drupal community can play a leading role in pushing the use of open data.

Our initial three targets include:

• Datasets: we will identify existing datasets, and document any needed steps required to prepare them for more widespread use.
• Map tiles: much of this data can be represented geographically, at the country level, the state level, or the local level. We will identify existing map data that can be used when developing location-based visualizations, and document the process of creating new map tiles. Any new map tiles we create will be released out under a Creative Commons license.
• Search and Visualization techniques: As we develop tools to import and manipulate datasets, we will need to search and filter this information, and make it comprehensible. This will likely result in new code that integrates various pre-existing open source visualization tools with the Views module. Any new code we develop will be released back onto Drupal.org

We hope that the process of looking at information related to learning will help people more effectively discover, understand, and explain the connections between student learning, school performance, the role of the teacher, and the relationship between all of these factors and the socioeconomic milieu in which they occur.

We also want more people to get involved. Toward that end, we have created a working group to discuss strategies and approaches for using open data - if you want to get started working in the space, join the group. Many hands make light work, and much of this work requires research and familiarity with how educational data is structured, as opposed to any hardcore coding or site building expertise.

Within the next few days, I'll have another post out that defines what we see as a starting point for the toolkit, and identify some of the tools that already exist that move us toward that point.

The combination of Mailhandler and MIME Router allows you to set up your site to take posts via email, and to route attachments into filefields.

MIME Router integrates cleanly with Filefield, Imagefield and SWF Tools. File paths can be set via the Token module. To use MIME Router, just upload it into your modules directory and enable it; the module uses the allowed filetypes in Filefield's user interface. Aside from adding fields to your content types, no additional config is needed to use MIME Router.

Using this setup, images, video, and audio can be sent to your site via email. This also supports posting to the site from handheld devices that support emailing files. So, if you have ever been in a situation where you used a handheld device to take a picture, video, or audio recording, and wanted to post it to your own (or your organization's) web presence, this functionality is for you. This functionality can also be used to support eyewitness information on local news sites, real-time reporting for school newspapers, and other situations where you want to get fresh information live quickly.

The MIME Router module was written and released as part of our work for the Knight Drupal Initiative.

Notes

Mailhandler settings

• Defaults: admin/settings/mailhandler
• Adding mailboxes: admin/content/mailhandler

MIME Router config

• Nothing!: it uses CCK/Filefield admin settings. Nothing to see here.

Other modules used in the screencast

• CCK
• Filefield
• Lightbox2
• Imagefield
• Imagecache and Image API
• Token (used to create dynamic paths for uploaded files)
• SWF Tools
• Mimedetect

Today at Open Source Bridge, Amye Scavarda and I co-presented a session on Thinking Like a Pirate (aka creating solid requirements docs, and how requirements docs help projects succeed).

Our slides are available here:

(As an aside, for those of you who don't know about Open Source Bridge, I'm glad you asked! It's an awesome, open source focused conference that occurs yearly in Portland, Oregon. Read more on their site.)

In our session, we fielded a question about some of the specific tools we use to build requirements docs. One of the things we use is an intake survey focused on design-related topics, and a participant asked if we'd be willing to share it out, to which I replied, "Sure!"

Which in turn meant I needed to make it pretty.

Intake surveys are incredibly useful tools. We generally use them as a way to start communication rolling on a project, and as a way of accomplishing some or all of the following goals:

• Learn about the organization's design aesthetic and needs;
• Begin to define a common vocabulary for web design and development;
• Start the conversations about the relationship between design, site architecture, and user experience;
• Begin to create the relationship between the communication leads for both stakeholders;
• Get a sense of the level of research that has gone into the project prior to beginning development; and
• Get a sense of how the organization responds to requests for information.

Below, I have included the general questions and structure of our intake survey. We vary the questions depending on the nature of the project; for example, if there is no desire to incorporate content rating, we don't ask the client to look at sites that feature content rating.