Goodbye TV.HWDSB, Hello HWDSB.TV (or, third time is a charm)

I’m not sure how many people — outside of the 21CL team — are privy to the ongoing video platform saga here at HWDSB. Back in 2013 we recognized the need for a centralized video platform within the board. I think we are one of the few K12 school boards in Ontario with such a platform. As a medium, we found that video was a more effective way to assist teachers than the practice of authoring long screen-shot laden documents. We also recognized deficiencies in the way that Desire2Learn handled video, offloading the processing of video to the browser, and browser add-ons, rather than providing server-side transcoding. What this meant in practice was that videos that would play on a laptop wouldn’t play on an iPad because of missing browser plugins. (Nerdy aside: WordPress solves this by including Mediaelement.js as part of their codebase.)

At the time there was really only one video platform integrated into D2L, a service called Kaltura. On the surface this looked like a perfect fit. They offered both a Software as a Service (SAAS) package, along with what looked to be a vibrant open source community that might allow us to host the service on our own servers in the future. There was a plugin that worked to add video comments on a blog that looked like it might give us voicethread-like abilities on our blogs (this didn’t ever work in a Multisite environment in the way we envisioned, and we were never able to turn it on: I still think video comments would be a cool idea). Within the year we were on the hunt for a new platform. The strikes against them:

  • They were incredibly expensive
  • They weren’t interested in fixing their WordPress Plugin
  • The connection to our Active Directory broke in May, and wasn’t fixed until well into June, leaving students without access to video review materials necessary for exams
  • Their admin platform was incredibly cumbersome, and required their help desk every time we attempted to make changes

So over the Summer of 2014, we migrated over to Mediacore, a small Canadian (yea!) company that seemed to cover most of our needs. For the next year, we worked along with this company as they grew and adapted to the needs of education. They were incredibly responsive to our requirements, and their development roadmap echoed many of our needs. Then in October of 2015 we received word that they had been acquired by a company called Workday, and would be shutting down their education sector services.

That was a huge punch to the gut.

We started looking at other video providers, but having been stung twice, the prospect of adopting another third party video platform, that may also fold, or change, or otherwise lead to triggering what seemed to be suddenly becoming a cycle of migration, was not something we took lightly. Couple that with the fact that the video platform market is saturated with small companies we had never heard of, all vying for edu-dollars, all possibly on the brink of acquisition, made the hunt for a new home a pretty depressing activity. The falling state of the Canadian dollar also meant that the expensive edu-video platform market (geared more towards post secondary pockets) was starting to look like it might be beyond our budgetary reach.

The power of the video platform is in its ability to feature published content from around the board, fostering collaboration, creating windows into classroom practice, and sharing in a safe, advertisment-free/data-mining-free environment. We weren’t ready to abandon that vision.

We started thinking seriously about just hosting everything in Google Drive, but that would mean losing the centralized video repository. It would mean going back to the siloed collections, embedded in various other spaces, or merely distributed via email, requiring manual intervention every time someone was searching for something. The power of the video platform is in its ability to feature published content from around the board, fostering collaboration, creating windows into classroom practice, and sharing in a safe, advertisement-free/data-mining-free environment. We weren’t ready to abandon that vision.

We also had a difficult time finding platforms that met the needs of a student-centred K-12 program. Most platforms seemed to allow for a select group of administrators to upload content, while students merely view and consume. Others were focused on lecture capture, a style of teaching we wouldn’t want to promote within our inquiry-based classrooms. We needed a space where students could author their own content, and where related videos were other HWDSB creations. We needed a place that empowered students to be publishers, while allowing us to administrate and flag things that are perhaps inappropriate, in a safe space to learn about how and what to share online. We needed a space that integrated with our existing platforms: the Commons and the HUB.

So we decided to build out own platform (such a small sentence: such a huge undertaking). And for the rest of the year, started working with our developer-extraordinaire Ray Hoh on what it might look like.

11 months, 4 Github Repositories, 11260 lines of code, 64 Github Issues created (hundreds of posts within these issues), and 164 code commits later, we migrated 13 000+ videos from Mediacore over to our own video platform. Eventually we hope to open source most of this code so others can take advantage of this epic undertaking.

Building our own platform meets all of our requirements, and guarantees that we won’t have to move again due to poor customer service, corporate takeover, changing RFPs or any other number of issues that we risk when using commercial tools that we don’t own. This has been the basis behind the HWDSB Commons, and we have used those lessons to complete this project. Once we open source the project, I’ll get into more of the detail about how it all works, but basically we are leveraging Vimeo as the video streaming service in the backend (we don’t expect them to go anywhere anytime soon, so you can trust we won’t have to migrate again), and WordPress blog on the front-end to house the video contributions. We have developed this so that your videos will never appear on vimeo.com, and our branding and sharing settings will always be the only mechanism available to distribute your video. With Vimeo taking care of the transcoding and performance of our videos though, we can focus on building out new custom features that meet the needs of HWDSB (hosting video on your own server is hard).

We are incredibly excited about this new platform, and hope that you will help us make it a vibrant community of sharing and collaboration. You can find it at HWDSB.TV. We hope you like it. We are incredibly pleased with the results.

SSL Everywhere

Warning; technical details ahead: Over the weekend, the entirety of the Commons was switched over to the HTTPS protocol. This has been in the works for a few months now, and took a few key steps.

We first needed to secure all of the content that you share on your site. We accomplished this by shifting all our media content to be served up using an S3 Offloads plugin developed by a company from Nova Scotia named Delicious Brains. For the most part all 200 000+ media items made the shift over to their new home. You might find you need to add your header back to the top of you blog, or if you manually referenced an image or file in a widget on your sidebar, you may need to grab the URL again now that it’s being served from a different server.

The next step was to procure certificates for all our our custom domains. Most of the sites on the site are covered under a wildcard certificate: *.commons.hwdsb.on.ca, but users who have opted for a custom URL aren’t covered by this certificate. We leveraged an exciting new initiative called Let’s Encrypt to secure sites like mrpuley.ca, suedunlop.ca, adunsiger.com, and mrjarbenne.ca. Although these sites comprise a small subsection of the 7097 sites hosted on the Commons, I’m inspired by the work of the Domain of One’s Own project, and would love to eventually see our work extend out to allow students to being building out their own digital cloud, as referenced in that linked article from Wired Magazine:

“Writing for EDUCAUSE Review in 2009, Gardner Campbell took the argument a step further. In A Personal Cyberinfrastructure he argued that learning to build and operate a personal cloud was a life skill students would need and should be taught”

If you don’t see the green lock at the top of the browser bar, you might have “mixed content”. A picture of a browser bar, with the green link indicating an SSL connection.This is caused by elements on the page that aren’t secured, and are still being delivered via http, and not https. In many cases, you can navigate to the post in question, and just add an “s” to the end of the “http” portion of the URL in the embed code (most sites that offer embedded content are secured by SSL. If you use a service that isn’t secure, reach out to them on Twitter and ask them to secure their embeddable content). Mixed content has been an “issue” within the HUB (Desire2Learn/Brightspace) for a few years now, so users who navigate that space will be aware of the issue. There is a movement to secure the web that we heartily support.

We couldn’t have done this without the help of our web-host and WordPress security specialist @boreal321.

As always, if you run into issues, don’t hesitate to comment below, or reach out to your 21CL Consultant via email.

The Commons Experiment

Picture of the Commons in 2011

5 years ago, around this time of the year, we sat in the Memorial Building in Ancaster, feeling like perhaps it was too late, and that maybe we should wait to launch until Semester Two. What would become the Commons had just been brought to life on a small server. Most of the summer was spent to ensure we would be ready for September, knowing that if we lost a Semester, we would loose the year.

Today, we accepted our 30 000 user into that “little” blogging community, where we provide a stage for students to publish their work; a window into the classroom so that parents can peer inside; a space for professional dialogue. We provide a means of connecting learners across the board with other learners, with colleagues and parents, and with expertise out in our community.

And somehow through all of that, my avatar looks younger ;).

Here’s to five more years of sharing.

Charity Begins at Home

I’ve been using Github for a couple of years now to connect with our developer on the HWDSB Commons. We post a lot of code there, sharing it with the rest of the WordPress and BuddyPress community. For those of you unfamiliar with Github, this is how they describe their platform:

GitHub is how people build software. With a community of more than 14 million people, developers can discover, use, and contribute to over 35 million projects using a powerful collaborative development workflow.

When we look at trying to do real things in the classroom, and providing students Professortocat_v2with authentic tasks, I think Github has a role to play, particularly in secondary Computer Science classrooms. Github is where many international corporations share their work (Vimeo, Facebook, Twitter, Netflix, Apple, Microsoft, and Google, among others). I don’t think there is another segment of industry that works so transparently, and allows the public to look in on the process of how their product is built. Github also flattens the hierarchy, eliminates corporate silos, and allows anyone with a username to contribute to projects, or fork (create your own copy) and hack/remix existing code projects. A Github profile is now being used out in the software development community to gain employment: it’s more powerful than a resume.

Github offers an educational package, and repositories to help teachers use Github in the classroom. If teachers want to teach Computer Science in authentic ways, they should be investigating Github to share code within their classroom. But using it in the classroom is only the first step. The real learning happens when the students begin to see themselves as contributing members of the software community:

As an example, Bootstrap (a theme initially created at Twitter) is available here on Github. There are just under 400 issues that are open on that repository, and the community around the project is quite active. A student could take on one of those issues by forking (copying) the repository and attempting a fix, and then create a pull request to have their contribution pulled into the main repository (a pull request is a request you make to the author of the code, to have your changes “pulled” into the main repository). React, Angular, jQuery, Nodejs: the projects that run the internet are all available and being collaboratively built on Github. When contributors post code, others comment and help to make that code better: they teach each other. How many expectations within a Computer Science class could be assessed by students solving authentic problems on important open source repositories. Even if they don’t get a pull request accepted, watching developers contribute to projects is a rich learning experience every student interested in coding should be exposed to.

The title of this blog post is Charity Begins at Home, because I think that we can help promote contributing to important projects by having our students — with the ability to code — contribute back locally in ways that can make our infrastructure within the board stronger. Our students potentially have a role to play to help create apps they can use in their classes. They see first hand the problems they might be able to solve collaboratively by building software. They can help build apps to support their own learning, or to help teach students in elementary. They could solve authentic problems that exist within our organization. There is a thriving Hamilton Software community that we have partnered with through the Hamilton Code Clubs initiative. The mentors who are visiting our elementary schools could help to audit code created by secondary students.  Think about how rich the learning is when students are tasked with solving authentic problems, have an authentic audience for their products, can see them being used, and can iterate on their development through user feedback.

What better way for a fledgling coder to say Hello World.

Broadcast Posts

We are deploying a new functionality on the Commons called Broadcast. The Broadcast box at the bottom right of the post edit page will allow you to take a post and cross-post/duplicate/broadcast the post to another blog.

Historically we have always felt that students should have one main blog, on which the post all of their work. We recognize that classrooms and initiatives set up group blogs for a variety of purposes, but we didn’t want students to have numerous blogs established for one grade or one course that would have one or two posts on them, and then would be abandoned, when one of the key features of blogging is the ongoing portfolio of work it provides for a student to look back on. We have attempted to endorse the idea that students could use categories to properly categorize their work, much like I do on my blog, with topics like technology, pedagogy, and the Commons.  This is fine, but it can make it difficult — particularly in secondary (in elementary we find the teacher is usually responsible for multiple subjects and can just Follow the blog) — for a teacher to locate the posts a student has written for History, and Science, and English, if they are using the blog for multiple courses during the same semester.

Broadcast is our attempt to attend to this. If the English teacher creates a group blog for the course (using the Hub Sync functionality to add their students as Authors), then the students can broadcast their posts to that central blog using the new broadcast function. This provides a central location for students to see the work of their classmates. Currently comments left on the group blog sync to the student’s individual blog. The students can set it up so that the links on on the group blog will redirect back to the parent permalink (back to the student’s blog where the post was initially created.)

We are still crushing some bugs, but would love some classrooms to test out this functionality and either email me or comment below with feedback and commentary.

I’ve Broadcast this post over to my personal blog (so meta).

Innovation vs Consistency

I wrote a post recently about the different tools we have available in the school board. You can read it here:

The Complexity of Choice

This is a popular conversation in the 21CL team here at HWDSB, and it is happening with renewed vigor as I redesign a landing page for the HUB (the HUB is the name of our instance of the Ministry-provisioned virtual learning environment). The HUB is our Learning Management System (occasionally referred to by Desire2Learn/Brightspace as an Integration Management System: a distinction we will examine further)

This is still just a draft as we continue to iterate. You can follow along on the development over here on Github.

As we build out the “integrations” tab, the conversation invariably turns to the plethora of tools we offer at HWDSB:

  • Do some of them cannibalize on adoption of the HUB’s internal tools?
  • Do we end up creating silos with too many tools?
  • Do they eliminate the ability for neighbours to help each other with adoption?
  • Do we need to concern ourselves with the rogue?

It’s this last point I get a bit stuck on. I am a self-professed “rogue”. I like shiny new things, and tried to foster an environment where my students understood the need for agility when it came to our use of digital tools: what Alan Levine would call a “de-centralist” approach, of small tools, loosely joined. What one might consider doing within a Discussion Forum in an LMS, we would select an appropriate web 2.0 tool for the brief moment we needed it, and then move on to the next space. This dipity timeline assignment is a good example of that type of thinking, loosely joined through our classroom blogs.

So the question becomes, how can system supports like the 21CL team enable a “de-centralist” approach, without creating an environment where users feel overwhelmed by choice? (I use the word “enable” with intention here, rather than “promote”) Should we turn off Google Classroom because it cannibalizes on HUB adoption? Should we turn on the OneNote Classroom Notebook that could act as a content delivery system, when we already have a few different ways to do this (because it might meet some teacher needs)? Is the HUB a learning management system, or is it an integration management system: A pass-through that allows for “small tools, loosely joined”. Can we concern ourselves with trying to serve the rogue, or will they shirk our offerings on principle. And where do you draw a line? Example: the use of Seesaw in the board is concerning because the content doesn’t easily travel beyond the school year, and one of the great features of an ePortfolio is the ability to look back on a previous year’s work and reflect on growth. Using the ePortfolio tool in the HUB (although admittedly less engaging from a User Interface perspective) would allow for students to carry their artifacts from year-to-year, school-to-school, and around the province while they attend publicly funded schools, and then beyond via myDesire2Learn. Can we be hard-nosed about some tools, while offering choice in others, without creating chaos.

How do we differentiate responsibly?