Taking the High Value Road: Innovation in Open Practices

Mountain road

Used by (cc) from nicmcphee.

I’ve long believed the open practices we follow in the Sakai community result in more, better, faster functionality, code, security, accessibility, standards-compliance, and innovation generally. But lately, evidence has been mounting to demonstrate the high value and wide acceptance of the open path more clearly than ever.

Today’s announcement of a new partnership between rSmart and SunGard Higher Education (SGHE) to deliver and support Sakai is the latest manifestation of the huge body of valuable work being generated by those of us following the open path: commercial vendors, educational institutions, nonprofit organizations, government entities, and individuals. Valuable work that is having real, positive effects on education.

A key part of rSmart and SGHE’s work together is to extend Sakai’s integration with SGHE’s Banner Student Information System (SIS) platform to follow the latest IMS Learning Information System (LIS) standard. On the face of it, this sounds like a typical outcome of two technology firms working together, but that integration rests on a far larger body of work, produced collaboratively in our open community.

Without even going in to the work of many that went into establishing the IMS LIS standard, rSmart and SGHE’s work with Sakai, Banner, and LIS extends the open-source work initiated by our fellow Sakai commercial affiliates Unicon and Oracle, under the leadership of my fellow Sakai Product councillors John Lewis and Michael Feldstein. This growing body of work promises to simplify and enrich Sakai’s SIS integration not just with SGHE’s Banner and Oracle’s Peoplesoft, but with every SIS platform that supports IMS LIS. Once we have this richer integration between our learning and administrative systems, we can start to explore all the ways shared information can have a real impact on our core mission of education.

Another example of open-source innovation centers around Sakai’s support for another worthy IMS standard: Basic Learning Tools Interoperability (BLTI), which makes it easy to tie different educational technology tools together. Sakai’s BLTI support was an early reference implementation and now ships in Sakai’s core codebase thanks in a large part to the work of long-time Sakai community member Chuck Severance. We are already seeing a wide variety of other open-source and proprietary tools support BLTI, making it easier for us to give users an integrated experience with a richer, varied toolset—and that exactly is the future of all learning platforms.

And while the Sakai community is working together on important standards support like IMS LIS and BLTI, we are also innovating actively on all sorts of other capabilities in both the mature Sakai 2 and the next-generation Sakai 3 platforms. Both Sakai platforms are under development by international, multi-institutional teams, coordinated by formal groups that conduct their business openly and transparently. Just this month we saw the Sakai 2.8 code freeze for the next release and the Sakai 3 0.7 release, both of which demonstrate rich innovation for technologies at very different points in their lifecycles.

What’s more: open innovation is not for code alone. Sakai’s Teaching and Learning working group recently released one of our most valuable artifacts: Sakai Learning Capabilities 1.0 (SLC 1.0).

Representing a full year of collaborative work, SLC 1.0 defines seven general areas of functionality that support teaching, learning, and collaboration. Of course we’ve seen functional checklists before—like Edutools or insert your own list here—and we continue to try to use such checklists to evaluate different learning platforms. That practice is akin to counting the spokes on buggy wheels while ignoring the changing paths we seek to travel, or the fact that not only are horse-drawn carriages obsolete, but even the internal combustion engine has evolved from solution to problem.

SLC 1.0 is an entirely different kind of list. Instead of a mere catalog of isolated tool functions, SLC 1.0 presents seven “lenses,” or perspectives through which a learning platform can and should be viewed. Each of these lenses is not exclusive, but rather views the platform as a whole, in light of a specific group of cross-cutting concerns. Going further, SLC 1.0 is not a vision of what we will settle for—limited by an interpretation of what incremental changes are possible in the technologies we already use—but is instead a vision built by actual practitioners, guided by what we really want to accomplish in real educational situations, with real people who have goals not organized by the buttons already on their toolbars.

I hope to see SLC 1.0 and its subsequent elaborations and extensions forever change the way we judge—and build—not just Sakai, but all educational technologies.

I’ve just begun to scratch the surface of what’s brewing in the growing critical mass of the Sakai community, but one thing is clear: the open road ahead promises to be crowded with new collaborators, good ideas, and real results.

Sakai Fellow, Well Met

Black Ninja SakaigerI was deeply honored to be named a 2010 Sakai Fellow—mostly because fellowship bestows a coveted black “ninja” sakaiger (pictured)—but also because I read my fellowship as evidence that the Sakai community recognizes and values all forms of contribution to our collaborative work.

Three out of 2010’s six Sakai fellows have made their substantial contributions primarily in areas of actual technology development: Oxford‘s Matthew Buckett, Cape Town‘s David Horwitz, and Michigan‘s Gonzalo Silverio. I can’t stress enough the high value and significance of these three fellows’ work.

The other three 2010 Sakai fellows—Indiana‘s David Goodrum, Michigan‘s Steve Lonn, and myself—have made our primary contributions in what might seem “softer” areas of Sakai: coordination, communication, thought-work, and research. The very tangible outcomes of David’s leadership in the formulation of the Sakai Learning Capabilities and Steve’s continued focus on the invaluable research of Sakai’s Multi-Institutional Survey Initiative are far better evidence than any of my own contributions of the value of work outside the Sakai codebase.

Unlike others who suggest a strong difference between what might be called the “write” and “read” communities within Sakai, I see this year’s Sakai fellowships as testimony to my view that such a dichotomy is not so useful. Instead I see read/write activities in open communities as a continuum that generates a virtuous circle of outcomes: new reading generating new writing and vice versa, until the distinction between reading and writing becomes robustly fuzzy.

All of us in the Sakai community are readers and writers at different times, of different texts, inspiring and supporting our whole collaborative endeavor.

Thank you Sakai!

Community Source Evaluation Strategies: Why Commercial Support Is Key

Josh Baron, Director of Academic Technology and eLearning at Marist College and now the new Sakai Foundation Board Chair, recently posted a great article in Campus Technology detailing Marist’s nuanced evaluation of Sakai and its community source provenance: Community Source Evaluation Strategies: Is Sakai Right for Your Institution? The article is a must-read for anyone at an institution considering the adoption of a learning environment—open/community source or proprietary—as all of Josh’s lessons pertain to both options.

I’m especially glad to see Josh include “Functionality Requirements” as only one of Marist’s five important evaluation criteria categories, putting it alongside Support Requirements, Community Health, Reliability/Scalability, and Innovation Drivers. All too often I’ve see institutions focus primarily on functional requirements in their technology choices, often at the expense of wise, strategic decisions that Marist’s other categories take into account. Every system will leave you with functional gaps…it’s the other stuff that will matter most in the end.

Reading through Josh’s piece, I was also struck by how the structures of commercial support for open/community source underlie each of Marist’s evaluation categories, and how well Sakai’s robust commercial ecosystem helps buttress Marist’s case for choosing Sakai. I’ll briefly cover each category below.

Functionality Requirements

Josh points out that Sakai’s functional gaps outlined in Marist’s original evaluation were closed more quickly than expected. Many of the other points in the article explain why innovation and quality move faster in open/community source, filling in functional gaps in record time. The commercial support ecosystem in the Sakai community plays a key role in that process, adding their part to the staggering rate of innovation in the overall community. Commercial firms engage in productive partnerships with learning institutions—like the one between Marist and my employer rSmart that fostered Sakai’s support for the IBM technology stack, or that between Oracle and Unicon that brought us Sakora—and at the same time provide dedicated development resources that harness the collective needs of many clients to push Sakai’s functional breadth and depth.

Support Requirements

Josh references the Sakai commercial support ecosystem head-on in this section. As he writes:

“As Marist concluded research into this area it became clear that running Sakai was like ‘consuming’ any other enterprise level system and that the myth that new development resources would be needed was just that, a myth.”

While the gist of this statement is dead-on, in my reading, it rings true only when one fills the word “consuming” with its full meaning: as an institution consuming commercial support for their open/community source system just like they would with a proprietary system. Maintaining open/community source technologies without commercial support puts different risks and responsibilities onto an institution that can call for extra resources. With commercial support, an institution is consuming Sakai just like “any other enterprise level system,” without dedicating additional technical resources, and usually at substantially less cost than proprietary systems, thanks at least to not having to pay license fees.

Community Health

Josh is spot on again in describing the necessity to evaluate the viability of the community standing behind open/community source technologies. The community you join will bring you the greatest benefits of your open/community source strategy if it’s healthy. If it’s not, your might as well roll your own or pay the big dollars to a proprietary vendor. One element missing from Josh’s otherwise fulsome community health checklist is the existence of a vibrant commercial ecosystem. Sakai is fortunate to mark well in that category as well, which gives Marist—and all the other institutions who might need it—the commercial structures necessary to support their strategic choice.

Reliability/Scalability

Sakai owes the lion’s share of its enterprise performance quality to the many large learning institutions that run it in production and devote substantial resources to its development. For many institutions though, the community’s promise is not enough. They seek out additional guarantees for Sakai’s performance from commercial providers. In response, commercial providers bring additional focus to Sakai’s quality, reliability and scalability. It is through this focus, for example, that rSmart develops its dependable Sakai CLE distribution, upgrades and patches, and maintains our first-rate quality assurance and support programs, freeing users to focus on the more immediate work of their educational mission.

Innovation Drivers

I laud Marist for taking these important, yet seemingly intangible criteria into account in its selection process. Out of the significant innovation drivers Josh lists, the decoupling of code development and support services in open/community source touches most on the role of the commercial sector. The decoupling Josh describes ensures that Sakai commercial providers focus on delivering outstanding support—because after all, the code is libre and gratis. If a provider doesn’t deliver good support, Sakai’s robust commercial ecosystem allows an institution to move to an alternative provider without the costly consequence of leaving their system behind.

Why Sakai Now

The Sakai community is in a special moment. We are celebrating our continued development of a full-featured, world-class, enterprise collaborative learning environment with the release of Sakai 2.6. At the same time, we are extending our early work on a next-generation Sakai 3 platform that will take us to new levels of sophistication in teaching, learning, collaboration, research, and technology.

Simultaneously, outside the community, big events have had profound effects on us. New paradigms of open education and new political winds provide different opportunities and challenges. Continued litigation and consolidation in the proprietary learning technology ecosystem and drastic budget cuts combine to force us to rethink basic assumptions and well-laid plans.

Many inside and outside Sakai are thinking about how best to meet their needs and plan for the future in this special time. How should we support education online? What learning environment should we adopt? How should we allocate resources between maintenance and innovation? How will we manage transitions from one system to another?

I came away from recent Sakai Boston conference thinking that there are two basic facts now more true than ever:

First, our current circumstances prove that technology decisions are best made following long-term strategic vision, not short-term expedience or purely functional and technical criteria.

And second, the best place to work out the answers to our hard questions is as a part of the Sakai community, that is, within Sakai’s practice that follows a community, open source model.

I come to these conclusions based on the following points that I think any institution considering how to balance their resources and ambitions in this special time should carefully consider.

Sakai is Unique

Unlike any other proprietary or open source learning platform, only Sakai provides structured, open and transparent community and governance, powered by a substantial and growing number of institutions of every shape and size from around the world, coordinated by a formal, nonprofit entity, and including a strong and varied commercial ecosystem. We call this combination “community source” and it is open source, only much more.

There is a lot of depth behind that statement, but the upshot is simple. This unique combination of characteristics means that when you choose Sakai, you choose the path with the least long-term risk for change outside your control.

Spending on Sakai Makes More Sense

Institutions around the world are lowering and/or reallocating costs with open source solutions even while they buy guaranteed commercial support to lower their risk. The best part about the open source model is the new control it gives you over where you spend your money. Build in-house support or buy commercial support with vendor independence. Shift costs from proprietary license fees to staffing and activities that have direct effects on the teaching, learning and research that is your core, educational mission.

Any open source technology with a healthy commercial ecosystem gives you these cost advantages, but when I look at the open source online learning landscape right now, I think Sakai has the most robust and varied commercial support offerings, following a model that will enable the healthiest growth.

Sakai Aligns with Your Core Educational Mission

The Sakai community often uses the phrase “by educators, for educators.” It can come across as a marketing slogan, but it conveys a basic truth at the heart of Sakai. When you join the Sakai community, you are taking a huge step toward practices that should be a top priority at every educational organization: aligning your technology strategy with your educational mission. Proprietary technologies may serve educational needs, but their development and distribution are always refracted through the lens of corporate control and profit. Fully aligning your technology strategy with your educational mission is a bigger project than adopting Sakai, but Sakai can be a great first step in the right direction.

Your Work on Sakai Is (Y)Ours

After participating in Sakai Boston and watching the next week’s tweetstream from the Blackboard World 2009 conference, I was struck by how much the activities of these two—sometimes overlapping—communities look the same. But in the end there is a simple, but very important difference: the energy and resources you put into the Sakai community are not owned or controlled by anyone else. I kept finding myself wishing the vibrant Blackboard community was putting all their energy into work that is not only open to all (much of their work is open), but is also not tied to the destiny and control of Blackboard’s proprietary core. Everything you contribute within the Sakai community stays with you, even as you share it freely with other educators working for the same goals.

Are You Ready for Sakai?

Maybe you think your institution does not have sufficient resources to engage in an open source strategy. Stated plainly: there is no institution that is not ready for Sakai.

First, to clear away the most basic concern: quality commercial providers exist for every service you are used to buying from your proprietary provider, usually at lower costs. Need support? Need hosting? Need services? Get three or more bids from commercial firms with strong track records and pick the best fit. Going open source does not mean going it alone.

Second, if you think your institution won’t have the time or energy to engage in an open source community and glean its benefits, think again. Like what I witnessed around the Blackboard conference, consider your engagement with the communities around your proprietary solutions. Do you attend conferences? Exchange best practices and collaborate with other institutions? Engage with support communities? Give feedback on bugs and functional enhancements? Create training and documentation? Integrate with other technologies? You probably participate more than you think.

Your engagement in an open source community will look much the same as your participation in any proprietary community. In both cases, you decide your level of engagement. The only difference is in open source communities, you share full ownership of the value you help generate. Stop paying to give your energy to someone else’s project!

What Should We Do with Sakai Right Now?

Even though Sakai stands now as a fully-capable enterprise collaboration and learning environment, the primary reasons to choose Sakai have always been strategic rather than purely functional or technical. Right now, at this “special moment,” Sakai’s strategic advantages are even more clear.

If you are considering adopting a new online learning system soon, Sakai 2 is your best choice. Adopting Sakai 2 now brings you all of Sakai’s strategic advantages right away, and enables you to better position your institution to follow Sakai’s future and have real effects on what that future will be. You can upgrade to Sakai 3 in a deliberate way when there is a good match between your institutional readiness and Sakai 3’s development.

If you are already using Sakai 2, you are in good company! The large community that has also adopted Sakai 2 is already outlining a variety of transitional upgrade paths. A common pattern for rolling out Sakai 3 capabilities early is the idea of cohabitation with Sakai 2. For example, you might move to a Sakai 3 instance sooner rather than later, integrated with some Sakai 2 tools that provide capabilities not fully developed in Sakai 3. In other scenarios, you might roll out Sakai 3 functionality first for only select uses, like web-enhanced courses, collaboration, or portfolios. At the same time, there is still a lot of room for innovation on both the Sakai 2 and 3 platforms. For example, take a look at what Sakai developer Zach Thomas says about extensibility in Sakai.

If you are concerned about the overhead of working with both Sakai 2 and 3 at the same time, evaluate where your resources will be most effective and farm out the rest. Maybe you’d like to devote your team to addressing online pedagogy or innovating on Sakai 3’s next-generation technology. Hire out the maintenance of your Sakai 2 implementation. Maybe you’re already stabilized on Sakai 2, but want to provide some Sakai 3 capabilities. Hire out the deployment and integration of Sakai 3 or fund the speedy development of Sakai 3 capabilities you must have. Even working with both versions of Sakai with commercial support, you’re still likely to save money over the cost of an enterprise proprietary system.

Whatever your situation, you will be in the best position by joining the community now and moving from Sakai 2 to 3 later rather than waiting on the sidelines until a full Sakai 3 rollout is feasible at your institution.

Thought Experiments for Sakai: Keep It Simple Like Twitter & Draw Good Boundaries Like Drupal

I admit I’ve been lurking in a very slackernly manner in all the discussions in the Sakai community about content authoring, 3akai, UX, K2, Sakai NG and other unpronounceables, so I’m sorry if all this is a day late and a dollar short. Feel free to ignore me if you’re part of Sakai and are way too far gone for any more input. After all, these are just thought experiments ;) If you’re not part of Sakai, you might learn something about Drupal at least, so it may well be worth your time.

I draw some lessons here from Twitter and Drupal not to suggest that Sakai duplicate them, but rather that we hold those models in mind as we move Sakai forward. Even without these experiments, some of these ideas may be in our thinking about Sakai, so if they are familiar, take it as a vote of confidence. But if not, I’d like us to have at least thought through why we would not take them as inspiration or why we would choose another path.

In the lessons I draw from Twitter and Drupal below, I may come off as a bit of a zealot. Frankly, I have a greater appreciation for Twitter and Drupal as tools that I have for Sakai as a tool—my greatest appreciation for Sakai has always been for its community. But I would like to appreciate Sakai-the-tool as much or more than Twitter and Drupal, and I think I could, given the directions I see Sakai heading now.

But why Twitter and Drupal? When I’m thinking about all this Sakai stuff, my first thought is to reach for existing models. And the models I reach for are the handy ones. Why? Because there must be some reason I keep certain tools handy. There are lots of good tools, but the ones that fit so comfortably in my hand are well-worn for a reason. I also know them well—keen edges and ugly nicks—and so can draw the best lessons from them.

For those of you who live under rocks, Twitter is a microblogging and social networking service that has gotten a bit of press lately. A lot of people are using Twitter, and a lot of people don’t get it at all. If you already use Twitter, great. If you don’t get it, that’s OK. You don’t need to “get” Twitter to learn its lesson. There’s only one, it’s pretty big picture, and you won’t have to tweet about doing your laundry or hear about mine just because you read about it.

Drupal is a mature web content management system/application toolkit, currently at version 6.10, with a very vibrant international community and strong commercial ecosystem. About 1,400 people attended the most recent DrupalCon in Washington DC.

Keep It Simple Like Twitter

Keep it simple. Open it up. Let the complexity come from everywhere.

John Ellis has kidded that Twitter has become so popular mostly because it is so easy to make new words that start with “tw”: twavatar, tweeple, tweetup, twistory, etc, and if you haven’t heard them all, check out the twictionary: http://twictionary.com

I think John’s almost right. It’s about the simplicity and what people do with it. I think Twitter’s rise has a lot to do with their focus on keeping it simple: 140 character posts, direct, addressed, or pure statement, public/private, following/followers, search. Twitter keeps it simple and—just as importantly—offers a public API that lets the world layer an almost unfathomable and—to the Twitter team I’m sure—unimagined variety of interfaces, uses and extensions based on Twitter’s simple service.

In other words, Twitter knew what it was doing, but it didn’t expect that what it was doing was all that could be done.

Neither can Sakai. Looking ahead: we should focus, keep it simple, do it well, and open it up, so that everything we can’t yet imagine can hang off our work.

Draw Good Boundaries Like Drupal

One of the most crucial decisions for any information machine is to decide how specific it wants to be and where it will draw boundaries around what it will do.

Every piece of software I’ve been involved with seems to follow the same general development pattern: In the beginning, software is built to meet specific needs in a certain context. As more needs are layered on over time, the software becomes either more cluttered or more generalized—or both—and gets rather messy. No one knows anymore exactly what it is for or where its boundaries are, but we end up tethered to it in all its messy complexity.

Take MS Word, which is both highly generalized (name something you CAN’T do with Word) and overly cluttered (you have to manage the TOOLBARS in Word). At this point, Word is really neither a great word processor nor is it powerful enough to be our main content management interface. And yet we use it for both. We are stuck to this big, messy machine and we can’t get loose (assuredly, there are also some other, non-technical reasons we are stuck to Word).

Sakai also started out meeting specific needs. And over time, Sakai too has become rather cluttered. Now it seems we are clearly at a turning point where we want to generalize. I think our success will depend on where and how we map Sakai’s boundaries as we clean things up. Drupal provides an instructive model in the cartography of information machines.

Caveats: There are other models that might be just as instructive. Drupal is just the piece of software I know best that, in my opinion, matches Sakai’s stature and has done a good job defining itself as an information machine. There are also many valid criticisms of Drupal. For example, I would never argue that Drupal’s user interface is ideal. The lessons I think Sakai can take from Drupal are at a deeper, architectural level.

First, like Twitter, Drupal has done a good job of drawing boundaries around what should be core and what should be left outside. Drupal core is pretty clean, focused on key, common functions. Meanwhile, in Drupal’s contribution space and beyond, it is rather messy. That is exactly as it should be. Good stuff comes out of that mess and some of it makes its way into Drupal core when the time and scope is right. Other stuff outside is fully mature and absolutely essential—for some. And for that reason, it will never become core, which is exactly as it should be. Core should not be defined by maturity, but by generality. There are a lot of ways that the Drupal community works to support both high innovation in the periphery and healthy boundaries at the core. Sakai should think carefully about where we put our borders and how we will support work inside and out.

Second, Drupal has done a good job of generalizing, focusing and simplifying its core functionality, and making core functions easily available to peripheral tools. If you do it right, all you need to build into a Drupal module is the specific functionality you need…everything else is a call to core. This makes it incredibly easy and quick to add functionality to Drupal—which fosters innovation—and also ensures that contributed modules participate fully in the larger Drupal machine. As we collaborate to define and build Sakai’s next generation, we should look to mature models like Drupal that have a head start on clarifying and exposing core functionality.

Those are the general lessons I draw from Twitter and Drupal, so if you’ve had enough, you can stop reading here. Following are some more specific examples I draw from Drupal that relate to some of our recent discussions in Sakai.

Content

Drupal starts with the idea that (almost) everything is a piece of content, starting from the same place on a conceptual and technological level as a “node.” In Drupal, you augment the structure and/or functionality of these generic nodes by “decorating” them with additional structured data fields, workflow, etc. This way, all Drupal core has to concern itself with is the common structure (eg, common metadata like author, creation timestamp, etc) and common functionality (eg, access, CRUD, versioning, validation, input, etc) of nodes. More specific structure and/or functionality gets layered onto the basic node either through generic admin interfaces (eg, the Content Construction Kit, or CCK) or more tailored modules that make specially augmented nodes for specific purposes.

Want to create an event record? Create a new “event” content type, add a timestamp field that uses a mini-cal data entry widget. Click, click, done. Add location? Just decorate your event content type with a location field—oh, and then you’ll have all the magic of a host of map integration modules at your disposal. Click, click, done. Want your events to link to location profiles? Create a separate “location” content type and add a node relation field to your event content type to link each event to a profile of its location. There, you just built a dynamic event web application in 15 minutes without calling your code monkey.

Another key Drupal module—Views—provides a generic query and output service for content. Need a table listing of all content meeting certain parameters, paginated in groups of 25 with sortable columns? Click, click, done. Want to offer that same content as a feed? Click, click, done. Want some completely different bucket of content, organized and presented in some other way? Again, click, click, done—and almost always with no coding required.

By generalizing core content in this way, Drupal handles it all consistently, but at the same time makes it easy to customize content for even the most complex needs—often with no coding required. Is it so easy faculty could do it? Maybe not without training, but you may not want end-users defining new content types willy nilly anyway. What the Drupal model offers is a way to lower the bar for meeting specialized content needs to a level that they can be met in minutes by someone with only a bit of training: a faculty power user, instructional designers, help desk staff, student assistants—crikey, even I can do it. Also, did I mention that Drupal content type definitions are exportable? Yes, you can define, export and share specialized content types.

Drupal understands that content creation and display is a core function, but it doesn’t expect to know what YOUR content needs to be. Sakai would benefit with generalizing its content handling to Drupal’s degree. As educators, we may feel that we are well-placed to define what a syllabus, a quiz, a discussion, a lecture podcast, or a portfolio should be. But as technologists, we will serve all the unforeseen ideas for what educational content might be far better by designing a solid, general framework on which our current—and future—ideas can be made manifest.

Taxonomy

From the start, Drupal anticipated that taxonomy—which is just a fancy word for categorization or tagging—was an essential core function. Drupal enables you to define any number of category vocabularies, each having special characteristics (eg, freetagging, hierarchy, etc), each holding any number of terms, and each related to whatever specific content types you desire. Thus any content in Drupal can be categorized in multiple ways, with highly structured categories or freetag folksonomies—or both—for different purposes. Good stuff is baked into core, like returning content matching various categories by simply including boolean queries in the URL.

Following the model I’ve been stressing of core simplicity enabling unanticipated innovation, Drupal modules make use of the basic, core taxonomy service to do all sorts of unexpected things, like category-based access control, or category-based organic group creation and management. With taxonomy as powerful as Drupal’s baked into core, Sakai too could enable all sorts of things that we may not have yet imagined.

Theming

Drupal’s core presentation layer is the icing on the cake, which is exactly what presentation should be: icing. There’s nothing worse than finding presentation baked into deeper levels of software, where it’s static and hard to change. Drupal handles presentation as the final layer, enabling design to be very flexible and easy to modify. Want every user to be able to choose between three entirely different designs? Just load three themes and let the users choose for themselves. Need to offer a mobile version of your site? A dedicated mobile URL and/or some user agent sniffing can automatically deliver a theme optimized for mobile devices—oh, and there’s a module that does all that for you (something you’ll find again and again in Drupal). Need that new content type you just made to look different than every other piece of content on your site? Drop a custom theme template named for that content type in your theme’s directory and your generic theme gets overridden automatically with your custom design—just for that special case.

The power of this theming model came when Drupal core stopped worrying about what the perfect presentation should look like and instead offered a way to deliver ANY presentation predictably with easy-to-build templates. In Sakai, the same power and flexibility would take us past the question of what Sakai SHOULD look like to the simple answer: Sakai looks like whatever you want it to look like.

Layout

Our next-generation Sakai authoring experiments are delivering some juicy tools to place different pieces of content and widgets in different parts of a page. Drupal offers two models that may help us refine the good work we’re already doing.

Drupal core has long had the concepts of regions and blocks. Regions are areas of a page defined by a theme. A theme can have any number of regions laid out in any way. Blocks are bite-sized content or functionality: anything from a static welcome message, to a listing of recently updated content, to a user log in form. Blocks can be created individually by users or made available programmatically by Drupal core or contributed modules. Drupal core offers tools to map blocks to different page regions, and customize the visibility of blocks based on almost anything: user role, content type, authentication status, URL patterns, etc.

Drupal’s region and block system is very flexible, but it is better suited for site administrators to define global page layouts than it is for individual users to author custom pages with varied content as we have been imagining in Sakai.

Panels is a module outside Drupal core that comes closer to what we’ve been imagining in Sakai: the ability for an individual user to place content and/or widgets exactly where they want on an individual page. Unfortunately, the authoring experience in panels is not anywhere near the kind of intuitive WYSIWYG experience we have been working toward in Sakai. However, Drupal panels offers all the ingredients we might want in a page authoring experience…we just need to cook and serve them differently.

I take several lessons for page authoring in Sakai from what works well in Drupal’s layout tools of regions, blocks and panels. When laying out a page in Sakai, we should be able to choose from:

  • A library of predefined layouts, offering good, commonly-used page structures. Some of these layouts could be merely structural—empty containers waiting for me to fill them—defining something like Drupal’s page regions (eg, a typical three-column layout with header and footer). Others could combine some empty regions for me to fill, along with other regions already filled with existing widgets (eg, a big, empty body region with a sidebar that has calendar, discussion and tagcloud widgets already in place). We should be able to export and import these predefined layouts. I should be able to tag layouts and see/browse tags from other users—but one should be able to tag everything in Sakai, so we don’t ever need to state this requirement again, right?
  • The opportunity to author a new, custom layout, where I can design whatever structure I want. I should be able to tag, export and share my custom layout.
  • A library of widgets—not unlike Drupal blocks—that deliver either content or functionality. I should be able to search and browse global widgets supplied by the system, my own widgets, and ideally, widgets authored by other users I’ve subscribed to. I should be able to tag widgets and see/browse tags from other users.
  • The opportunity to author a new widget on the spot, thereby adding it to both the page I’m authoring right now and my widget library for use elsewhere. Making a new widget might be like making a view in Drupal: the ability to make some selection of content and display it in some form (eg, table, list, feed, etc). Making a new widget might be like something else too. Like Drupal, Sakai should offer new tools the opportunity to supply new widgets—and/or the opportunity for users to author new kinds of widgets.
  • The opportunity to author a piece of content on the spot, thereby adding it to both the page I’m authoring right now and whatever other collections that specific kind of content happens to live within (eg, pages, syllabi, tests, forum topics, etc). Like modules in Drupal, new tools in Sakai that define content should end up offering the chance to author in Sakai’s standard authoring environment.
  • The opportunity to define under what circumstances a given layout/widget/content piece is visible. As in Drupal, I should be able to define who can see something and when they can see it. Default visibility should be baked into predefined layouts, widgets and content. And if I have the right access, I should be able to override default visibility.

Pluggable Authoring Tools & Filters

Drupal offers flexible frameworks for modules to supply different ways to get content in and spit it back out. While Sakai has been wedded to the oft-maligned FCKeditor for some time (yes, all the WYSIWYG tools have their drawbacks), Drupal offers the ability to plug in almost any authoring tool: plain old text, different WYSIWYG/WYSIWYM editors, various markup formats, etc. At the same time, Drupal offers the ability to define output filters that can clean up and/or enhance stored content when it is rendered. Drupal’s filter on output strategy allows the same content (stored raw in the database) to be transformed differently depending on what filters are in use (which can even depend on user role or preference). Want anonymous users to see all your content translated into Pirate talk? Done. Again, Drupal core is not determining how stuff gets in and out, it instead provides a pluggable framework so we can decide for ourselves what we need. So many of Sakai’s usability issues revolve around the rigidity of input and output, we would do well to adopt a pluggable model which opens possibilities beyond what we can anticipate.

URLs

Unfriendly to humans and search engine robots alike, Sakai has some of the ugliest URLs ever. It makes sense for a web application to have canonical URLs and it’s hard to make them friendly, but there’s no reason to show them to the world. Drupal solves the ugly URL problem by offering a core service for URL aliasing, so users themselves can define better URLs for their content. A valuable contributed module—pathauto—allows site administrators to define automatic URL aliasing rules for different canonical URLs, thus saving authors the aliasing task and enabling more structured aliasing patterns. Again, the lesson for Sakai is to fix our problems by offering flexible options rather than trying to bake in the final solution.

Workflow

Drupal core has basic workflow baked in based on triggers and actions, where triggers are set to fire on certain events, in turn generating specific actions. For example, a workflow can be established to email a site owner (an action) every time new content is posted (a trigger). Once again, instead of providing all the ideal workflows we might imagine, Drupal provides a generic tool to build workflows, which we can use to build those we already know we need, as well as those we don’t yet know we need. If only Sakai’s sometimes idiosyncratic workflows were merely defaults, which I could change or replace as easily as I can in Drupal.

Installation Profiles

Many parts of Drupal can be exported/imported (eg, content types, views) or are modular (eg, modules, themes, filters) to allow for easy sharing and migration. One of the Drupal’s most powerful tools is the installation profile: an automatic recipe to build a new Drupal site. Installation profiles set modules, themes and other configuration options when Drupal is first installed so you can distribute a pre-packaged Drupal recipe, optimized for specific purposes. If Sakai had installation profiles like Drupal, I could imagine distributions for different organizational types (K-12, community college, liberal arts college, research university, etc), different usage focuses (collaboration, portfolios, teaching and learning), or different languages, giving new adopters better starting places than a generic Sakai installation. As Sakai generalizes itself, we should also have a way to demonstrate and distribute best practices for specific uses.

Other Stuff

There are many other (smaller) lessons Sakai might take from Drupal. Some that come to mind include:

  • The core form API that lets modules safely offer forms with minimal work and modify others (including core forms) dynamically as needed.
  • The core multisite functionality that allows Drupal to run multiple sites from the same codebase, yet override and/or augment any part of any site as needed.
  • The core comment functionality that lets any piece of content include threaded comments.
  • The core support for automatic feeds.
  • The core menu functionality that allows navigation to be managed as its own kind of content.
  • Core support for OpenID authentication.
  • Sophisticated core caching mechanisms.

Finally, a Shout Out to Portfolios

Oddly enough, the part of Sakai that most reminds me of Drupal’s generality is our portfolio toolset. It’s not surprising that portfolios—maybe the least well-defined practices in teaching and learning—have led to the most generalized tools in Sakai. And yet, the most obvious complaint about Sakai portfolio tools is that they don’t do anything at all. The fact is: Sakai portfolios can do almost anything. What’s missing in portfolios is the easy tools to build them and the portable models to demonstrate their power. Sakai would do well to look inside to its portfolio tools—for inspiration to generalize, but also for caveats about what must be in place to make generalized tools usable and practical.

Drupal 6.1: On Drupal Security

Just noting that I updated my Drupal 6 test site to 6.1 following the security release. The update was painless.

Thanks to Drupal 6’s new update functionality, the site itself checks to see if any updates to core or modules are necessary and let’s you know.

And if you think it’s problematic that 6.0 already had a security patch…I beg to differ: new “dot 0” releases of any software often have bugs, sometimes security related, and Drupal’s quick 6.1 release just demonstrates that Drupal in particular and open source projects in general are often quicker to identify and patch security bugs than proprietary development teams.

Go Drupal security team!

Here’s my first post about what I liked in Drupal 6.