All posts in Drupal

In the past, we have talked a fair amount about open content. Done correctly, open content has the potential to support meaningful change within education. A significant amount of open content exists on the web; much of this content, however, is not immediately reusable.

In this post and the accompanying screencast, we break down a system that can be used for authoring, redistributing, remixing, and collaborating on open content. The site is customized on top of VoiceBox, and all of the components used to build it are freely available. I'll be presenting on this topic in more detail at Educon in a couple weeks.

This system has several differences from other systems that support open content, but one major difference merits additional notice: it is designed to be porous, and it is designed to be installed and run by the people or organization creating the content. It can be as public or as private as you want it to be, but that decision is left up to individual content authors, as opposed to the people building the content silo.

Overview

Within the site, people can:

• Create and join groups; groups are workspaces that can be fully or partially private.
• Author notes; notes are the main form of content within the site. A person creating a lesson would build it by creating notes.
• Start discussions; discussions occur within groups, and provide a means to discuss areas of general interest, or to discuss a specific note.
• Offer feedback; feedback is private between the person receiving and the person offering feedback.

Notes can be created as individual pages, or organized hierarchically into multiple page books. Each book can be accessed in print-friendly format, and each book generates its own RSS feed that can be used to import the book outside the site.

In conjunction with a service like BookBrewer, this site can be used by schools or other organizations to create, distribute, and sell eBooks. Also, given that this site is built on Drupal, we just might write some code that allows Views to output content in ePub format.

Video Breakdown, Education Version

Use the minute marks to skip around the video to find the sections that interest you most.

Creating Notes | 0:15

The opening section breaks down how to create notes, and how to shift pages within a book. Notes can contain a variety of different media, and in this section we talk briefly about embedding images, audio, video, and other files within your notes.

Groups | 4:15

This section describes how to use groups to work collaboratively. It shows how to track activity that has occurred within groups, provides an overview of group home pages, and shows the different ways that users can choose to share their content.

To see an example of how to create a group, skip ahead to the 15:00 mark of the video.

Discussions | 7:10

This section shows how to use discussions to collaborate within the site. Discussions can be tied to a specific note, or more general within groups.

Feedback | 9:30

Feedback is a private communication between a reviewer and an author. For example, a teacher can provide private feedback to a student, or a department head can provide feedback and evaluation to an instructor in their department.

Moving and Copying Content | 12:30

In this section, we show how people can work with other people within the site, and how work can be distributed outside of the site. We highlight how to access the RSS feed, and print-friendly format of each book.

For people working in the site, we cover how to copy books between groups to allow people to derive copies and remix content without disturbing the work of their peers

Video Breakdown, Drupal Version

This breakdown gives a high-level overview of how the functionality was created. As mentioned earlier, the site build is based on VoiceBox. The main additions within the Open Content site include the ability to create multiple page books (leveraging core Book module and the contrib Book Manager) and the ability to form working groups (using Organic Groups).

Creating Notes | 0:15

Notes are created using CCK, and the Filefield, Imagefield, and Embedded Media Field modules. With the exception of the embedded media field, this setup is identical to what we are using on VoiceBox. Audio and video nodes are formatted using SWF Tools, and images are displayed using LightBox2. We will likely be switching to ColorBox in Drupal 7.

Groups | 4:15

The groups functionality is created using Organic Groups. The additional access control options for groups are created using the OG Access Roles module.

Discussions | 7:10

Discussions are structurally identical to Notes, with the exception of a nodereference that allows a discussion to refer back to a specific note. The nodereference field is populated using the Node Reference URL Widget module, and the link to create the actual discussion is created via Views.

Feedback | 9:30

Like discussions, feedback nodes use a nodereference to point back to a specific note. Additionally, feedback nodes make use of the Node Access User Reference module to control access to the feedback node.

Moving and Copying Content | 12:30

The ability to copy books is done via the Book Copy module.

Additionally, when books are placed into a group, the group affiliation and the level of access control is kept in synch throughout the book tree via the Book Manager module.

The RSS feeds for books are generated via the Views module, and the print-friendly format comes from the core Book module.

Conclusion

If there any follow up questions, please feel free to ask them in the comments.

A few weeks back, we wrote about our thought process for building features, and how we wanted to make sure that the features achieved two goals:

• Be part of a fully functioning install profile that "just worked"
• Be as reusable as possible within VoiceBox variants, or within other sites.

As part of achieving these goals, we created an option within our install profile that allows a user to select the Full or the Minimal install. The full install runs through the complete install, and creates a fully functioning site.

The minimal install, however, runs through the install profile, and then allows the site builder to enable the selected features they want.

Features are modules; this allows us to set dependencies between features. However, as we built out features based on our site configuration, we realized that the User Interface elements created the largest set of dependencies - and this makes sense, because a good UI collects up the various sets of functionality and presents them to users in an intuitive, coherent way. To account for this, we split out our UI into separate features, so someone doing a minimal install can choose to use these defaults, or build their own UI.

A graph of the dependencies shows this better than words can explain it:

• Dependency tree of VoiceBox without any UI (click the image to see a full-size version):

  

• Dependency tree of VoiceBox with the UI features included (click the image to see a full-size version):

  

  The elements pictured in blue are the UI-related features; within the site, they expose functionality to end users - this is also known as "making things useful or usable."

  Within the features, UI elements create a higher level of interdependence.

We are running through the last few rounds of testing here, and barring any nasty last-minute surprises, we should have a release of VoiceBox by tomorrow. Our features server, which will be launched with the site, will allow people to get the entire install as a package, or the bundled features individually.

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.