Bill's blog

Because I'm old, I still participate in that old person's technology, the listserv. On one of these lists, the question of if/how technology supports cheating came up. I've seen this question in various forms over the years; in this specific instance, it came up in response to a pilot program with Google Docs.

There are lots of excellent reasons not to use Google docs in your school, but cheating isn't one of them.

As people were responding within the list, some people recommended using TurnItIn.com as a deterrent to cheating.

And given that using TurnItIn.com is really bad advice, I felt compelled to offer some alternatives.

Teach writing as a process

Teach writing as a process. If all you see from a student is a final draft, you will have a hard time knowing how that final draft came to be, and you will be less effective at helping a writer improve. If you teach writing as a process, and see pieces of work from initial conception (this is my thesis), through notes, through a first draft, a second (and subsequent) drafts, through to the "final" paper, you will be able to give more targeted feedback. Using a working portfolio (aka, a blog) is a great tool for teaching process.

Students are honest

Approach your subject from the perspective that your students are honest. I know, crazy talk here. But people will generally rise to the expectations you set for them. Nothing says "you are not worthy of trust" better than using a system like TurnItIn.

Know style, and teach style

Know style, and teach style. People should know how to spot (and when to use) active verbs and passive verbs. People should know that a simple technique like scanning a paper for overuse of "to be" verbs will do wonders for their sentence structure.

People should know the different sentence structures, and when a simple sentence is a better choice than a compound-complex sentence. They should know how to analyze their own writing for variability within sentence types, and the effects it has on pacing. They should be able to spot repetitive patterns within their paragraphs, and either fix it or use it to their best rhetorical advantage.

People should know to examine their word choice, and the advantages and disadvantages of using words that are latinate versus anglo-saxon in origin. They should know to look for average sentence length, average paragraph length, and the average word length within a representative section of their writing.

Every writer has a distinct style. When you begin looking at writing and analyzing style, words written on a page become as distinct as the sound of a person's voice.

Technology Does Not Have Agency

Making the claim that using Google Docs (or a word processor, or a typewriter, or a printing press, or a hired scribe) makes it more likely that students will cheat misses the point. You know who is doing work by talking with them about that work. The technology is a means to getting work done; imbuing it with the agency to support cheating is a profound misunderstanding of both technology, and of what motivates people to do their best work.

Using a system like turnitin.com is a great way to tell your students "I don't trust you, and I'm not willing to take the time to know how you think."

Cheating is not a technological issue. To minimize incidents of cheating:

• Provide challenging, stimulating assignments;
• Check and provide feedback on in-progress milestones;
• Talk with your students;
• Teach style; and
• Be clear with your guidelines and your expectations. The more direct and clear you are with your students, the more direct and clear they will be with you.

This is the general cell phone policy I'd love to see schools adopt - short, simple, and sweet.

Mobile/Cell Phone Policy

During the school day, cell phones can be used. During class time, cell phones can be used in ways that support the teaching and learning process.

Cell phones may not be used in any way that detracts from the learning environment of the school. For more details on these expectations, see the "Classroom Expectations and Maintaining a Healthy Learning" environment section of the handbook on page X.

Cell phones may not be used to harass, intimidate, or bully anyone, at any time. Our school does not support harassment, intimidation, or bullying of any person for any reason. For more details on school expectations, see the "We Do Not Tolerate Bullying" section of the handbook on page Y.

And...

On a semi-related note, if a school is looking for a good resource on bullying, check out Bullied from Teaching Tolerance.

• 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.

Last weekend, the Los Angeles Times had an article of dubious worth on value added assessment, in which they pointed fingers and named names. I had something to say about it, as did many others.

But, from a post and thread on John Merrow's blog, it seems that many of the people that used to be known as the leaders are wildly out of touch. In particular, Grant Wiggins makes a stunning cameo, which could actually be a good lead in to a new program named "Misunderstanding By Design." Joe Bowers keeps a pretty good scorecard.

Against this rhetorical backdrop, Will Richardson sends us a nearly-elegiac prose postcard about the role of leadership in fomenting educational change. In it, he talks about how many people outside the echo chamber of online communities are not aware of the changes looming on the horizon - but in his piece, he also alludes to people having an alternative vision about what people should be learning:

(T)hey go back to their conversation. “It’s the schools that should be doin’ that,” one is saying, and all of a sudden, I’m tuned in, listening over my shoulder as I reach for a pack of Dentyne Ice from the candy shelf beneath the counter. “They’re just not teaching it as much as they should be.” I step away from the counter, buy a little time by pretending to look closely at the chocolate bars down below, wonder what the system is so deficient in, wondering, maybe…

“These kids just don’t know nothin’ about managing money,” he says, and I hear various sounds of assent from the others.

When I first read the Merrow post linked above, I was incredibly depressed - it was disheartening to see the extent of the disagreements between people who have been working for decades on improving education. But it slowly began to dawn on me: if this is what passes for vision, then we have a vacuum to fill. And while it would be nice to have a Secretary of Education who could do better than this, we need to play the hand we're dealt.

So, cue the music:

	Elvis Presley - A Little Less Conversation
	Found at skreemr.org

One thing we have going for us: virtually no one want the status quo (the only real exception here are, of course, companies that have a business model that depends on the status quo *cough cough textbook/test prep/testing companies cough cough*, but even they need to mouth the rhetoric of change, because the pace of change is a construct that will hold its value over time).

So, given that most of us want change, we need to listen to the changes people want. There are bound to be some good ideas in there, even among people with whom there appear to be broad disagreements. While "managing money" might not seem like a "21st century skill" people still need to know how to do it - and with minimal effort, I can think of a half-dozen project based lessons that could develop that skill.

More importantly, though, we need to act. How are you showing the value of the informal learning in which you engage? How does this make you a better educator? More importantly, how can this contribute to a better classroom, a better learning experience for students, and/or a better school? If we can't articulate and demonstrate these things - and, more importantly, if we don't make the time to enact and articulate these advantages - why should anyone take us at our word?

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.