The Other Brian Whitmer

Instructure's Acquisition is Not What I'm Worried About

2020-02-07T15:18:00.001-08:00

It's interesting how quickly and how slowly the world of edtech moves. I left Instructure at the beginning of 2015 to work on speech-generating software for people with disabilities. Some people tell me I shouldn't care anymore, or that I don't deserve to have an opinion anymore. That's cool, I get that, I just can't seem to stop worrying about what happens to this Little Company that Could. So here we are. There are probably, like, five of you reading this. I hope you had a pleasant week :-).

Growing Up Edu

I was injected with a healthy dose of edu idealism when Devlin Daley and I, fresh out of college, met with CIOs and instructional technologists from around 20 universities and community colleges, and I like to think it's done a lot to shape my mentality around technology. If nothing else, it's been incorporated into this weird mashup of I-don't-know-much and here's-how-awesome-it-should-be that realtors, contractors and consultants all stopped bothering trying to wrap their heads around eventually. I'm kind of a mess :-).

I believe that technologists should find and implement interesting and valuable solutions to existing problems, and that there should be compensation available for their work. It's pretty simple and naive, but it's how I think things should work. Not all good ideas get compensated, and not all problems are well-defined, but there you have it.

I believe that that's what we shot for when we started Instructure. There were clear problems with the LMS, and we had the right timing, background and lack of baggage to introduce a compelling solution. People were willing to pay for that solution because they believed it would improve their effectiveness or productivity.

Spinning Plates Don't Stay Up on Their Own

Neither Devlin or I wanted to actually run the company, so we brought in others at different levels who did, which was undoubtedly a good idea. Some of our new business-heads had different motivations, which is fine, but it meant that as the company grew we had people in leadership roles who never really understood what it was that got people excited about Canvas. They knew people thought it was a game-changer, but they didn't understand or didn't care about the intricacies of the edtech market. Software-company-as-a-generic-machine is a mentality that starts with investors and trickles its way down into all the seams. Sales is sales, support is support, you plug in the right pieces and out comes the revenue.

For us, it seemed like the only place where this broke down was around product strategy. We couldn't seem to empower the product team enough to drive a strong strategy and ended up chasing revenue or headlines. We won some great deals (and headlines) early on, so it's not like it was a complete loss, and it'd be easy to blame our shifting tides of product focus things on the edtech market and its idealism or lack of savvy or privacy-mindedness or corporate sensitivity, but I was over product in those days so, you know, my bad.

I believe that this product problem was part of an issue that's still showing up today with Instructure, and it affects the company strategy in general. It has to do with bolt-on acquisitions and not-invented-here syndrome. It has to do with chasing the dollar instead of earning the dollar. It has to do with forgetting to strategically ignore ROI. It has to do with how nobody gets fired for following the Silicon Valley playbook.

Finding the Right Playbook

The hard truth is that when you bring on an institutional investor, they don't really care what you're already doing, they're only looking at upside because they're there to optimize their return going forward. Some investors do this hyper-short-term, and mess up their companies down the line. Some apply healthy pressure and are more patient as long as they're still confident they can beat the return they'd get from other investment strategies. Either way, they see each company as a revenue opportunity, not a feel-good story to tell their grandchildren.

This isn't inherently bad. They get their money after the company makes money, and the company makes money when people are excited enough about it to give it new money. So investors look for patterns of behavior that worked well in other situations and apply them once again. Accelerate revenue by entering a new market or increasing walletshare for existing customers. Improve margins by paring down R&D and shifting resources away from established product lines. Bring in an executive layer that already has experience handling issues at the upcoming stage of the company's growth. It's a sort of standard operating procedure you can start from to make sure you're not accidentally veering off in a weird direction. Sometimes you may want to veer, but if not then it's the "safe" route because it's so well-trodden. Once companies get big enough you don't need investors suggesting this stuff anymore because the corporate executive team has already been trained in how it all works.

Except it doesn't all just work. Personally I'm not a huge fan of any of the above strategies, but that's ok, they're really just business decisions. They can succeed or not based on what happens underneath and around them. That's where I think Instructure has been struggling, though. It's not that the broad strokes are all wrong-headed, but they won't succeed just because they're what you're supposed to do. At a high level things at Instructure don't seem particularly deliberate or concerted so much as just, what you're supposed to be doing, and I think people are starting to notice.

Unfortunately, I think this has been going on a lot longer than people realize. Before I left there was already hand-wringing around "why can't we just build the next SpeedGrader?" ironically mixed with "let's shift resources over to new projects" and "we have too many bugs so we're going to pause new development for a while and address stability". It's hard not to fall into a routine of medium-term hype-chasing and putting out fires, which I think comes from that business-for-business'-sake mentality. I'm way too much of a product person so I never actually think a product is "done" (it's a personal problem :-)), but it's especially hard for me to see untapped potential in a product -- even one that doesn't have justifiable revenue upside.

I believe that Instructure worked so well in the early days because we accidentally instilled in everyone an urgency and empowerment to think of ways to make things better, even if it was less efficient. Some people come by it naturally, some focus on their own little domain, but the outliers were the ones there to just "do my job". We drove home how much we needed top to bottom ears to the ground, and we absorbed and obsessed over all that feedback so we could throw all sorts of unique ideas against the wall and build the ones that stuck. I've watched that kind of whittle away over time as people got roasted for sticking their necks out, and deadlines and parity and we-can-build-and-sell-one-of-those started trumping that's-interesting-how-could-we-improve-that.

Keep Canvas Weird

Look, none of this is particularly ground-breaking. "Founder says company needs to stop being all corporatey and focus on what made them great in the good old days. Nothing to see here, move along." You could say I'm just drawing from the playbook of what founders did in the past, we all play our part and the pattern repeats itself. I won't get my feelings hurt, I'll just chalk this post up to catharsis or something. I just can't not say something so long as I think my saying something has a chance to turn at least a couple heads back toward the idea of solving interesting problems.

It's not like nothing good has happened. The Canvas API has solidified, mastery-based courses can grow into something cool, and I'm interested to see how the new Analytics views develop. But Canvas can do a lot more. Did you know the original version of Canvas has a feed reader where students could register their personal blogs and then submit homework to their classes just by posting with the right hashtag? Or that we originally had an embed code you could drop in your HTML to allow access to grades, homework submissions and discussion boards from an arbitrary web site? Or that we mostly-completed a heuristic-based tool that would highlight outlier students based on activity and participation in that specific class? Or that we half-wrote a tool for auto-assigning students to groups based on same- or different-mindedness based on a teacher-created survey?

I can tell you exactly why none of those projects stuck, and maybe they all sound like terrible ideas to you. But as Instructure has become more streamlined and optimized, it's harder for me to envision where in the company those types of ideas can even germinate. When business pressures are applied, everything naturally moves toward the well-trodden path, where it will see less resistance. This is a big part of why most big companies just copy each other's features, or end up buying their way to innovation, there's literally nowhere left for the interesting solutions to get enough oxygen.

Typically innovation still happens at large companies only when someone high up has gained enough social capital to just do what they want, or when the company makes a deliberate decision to shield some groups from the business scrutiny of optimization. I'm not confident that Instructure has been set up to accomplish that kind of innovation for quite a while. Even back when I was wrapping up my time, the teams that had enough freedom to do anything more than incremental development and refactoring were pretty minimal. I would be surprised if things have improved on the Canvas side.

What Now?

I don't believe Instructure has lost its soul. I think people still get jazzed about working there. I think customers are still generally happy with Canvas. I think Canvas is a valuable contribution to education. But I don't think customers are looking to Instructure anymore for the Next Cool Thing. And I do worry the company's open floor plan is shifting from "I can walk info wherever it needs to go" to "I have a great view outside but it's kind of noisy in here". I worry that Canvas is about as good as it's going to get, which bums me out since we never managed to tweak things enough to convert the edupunks (personal problem again). There are a lot of forces tugging on the company anymore, and it's hard for me to see how adding another return-focused investor is going to do anything to improve the existing product (indeed, Michael Feldstein argues that Instructure's problem is that it needs more breadth, not more Canvas Cowbell). But those are primarily business decisions, they can end up good or bad depending on how you handle them. For me (and, I would argue, for edtech customers), I care much less about percent ownerships or the size of Instructure's product portfolio than I do about the current (not historical) impact of the products in that portfolio.

Again, I'm not here proclaiming all is lost, woe is my old company. I think there's a course correction in order, but nothing terribly drastic. There are still great people at Instructure trying to make good things happen for educators and learners, and there are great customers who want to share their insights to keep improving on a strong foundation. But nobody asked for SpeedGrader, it showed up because we had the latitude to throw it against the wall. If there were a way to shift back to that old style, where business-heads make sure things stay smooth and maintained, but while also letting enough people get all weird solving compelling problems for educators and learners, I think you'd see a "next SpeedGrader" show up of its own accord. And maybe the portfolio would grow too, who knows? But it wouldn't be expansion for revenue's sake, it would be building interesting things and figuring out how the industry is willing to compensate for them. My druthers would be allocating resources based on social impact as opposed to revenue, but I understand if that's a (ahem) bridge too far.

It's true that growth is slowing for Canvas, so from a business perspective that means there's less value to be had investing there. Unless, of course, people become dissatisfied or disillusioned and move to a different product -- but frankly there's not anyone doing drastically better in the space so the current risk is small. Canvas wouldn't be the first LMS to fester all fat and happy, though, and you can't ramp down and up R&D and expect it to remain effective. There are interesting problems I wish Canvas already had solutions implemented for. Some of them have been sitting in the Feature Request queue for years. There are going to be new problems that Canvas could grow to solve. I wish I was more confident people inside the company will be empowered to create the solutions.

I hope Instructure can find a way to keep solving interesting problems in education, I still don't see anybody else in a better position to provide a major influence on educational technology. I'm confident that the industry will continue to compensate them for their work as long as they do.

Dear Instructure: Please Don't Become the Next Blackboard

2018-07-17T12:55:00.001-07:00

I was classically trained on the five-paragraph essay and took my fair share of AP classes, so "compare and contrast" is like a reflex for me. When I read Michael Feldstein's article on Canvas taking Blackboard's spot on the LMS totem pole, it got my gears spinning. If Instructure is finally taking top shelf, what are we going to do to not become exactly what we set out to fix in the first place?

Instructure is working on new leadership in marketing, sales, product, operations -- oh, and we've also got a new President. Maybe a little history lesson isn't such a bad idea (here's quick refresher of how we got started). My goal here is to say, "hey, here's a list of things we should all keep an eye on so we don't go all you-didn't-learn-anything-President-Coin-from-Hunger-Games." Back in the day I used to take some time in every onboarding helping new hires to catch the vision of why we were different and to understand the Instructure Way. So if you like you can consider this your old-school onboarding indoctrination session.

(It's probably worth noting that I can't help but say "we" even though I'm not at all involved in Instructure anymore, other than the occasional lunch with my old coworkers. It's hard to let go, I guess. see: footnote)

1. Focus on the User, not the Dollar (It's Okay, the Dollar Will Still Show Up)

We showed up on the edtech scene in 2008, and people were more than happy to not just give us the time of day, but to unload their frustrations with Blackboard -- and ideas for new hotness they were afraid they'd never see. Blackboard was really stinking it up from what we could tell. We crashed their user's conference in Vegas after a few years and told everybody we were the anti-Blackboard. We didn't need a better value prop than that. Just "not Blackboard" and a bunch of t-shirts was enough to get people excited.

Mind you, we had a lot more than that going for us. Blackboard and D2L have continually had a hard time figuring out what makes us better. That's probably partly because *we* had a hard time explaining what made us better. All the "easy to use", "end-user-oriented" claims felt like hackneyed platitudes. The truth is what we built was a fresh take on the LMS, starting with students and teachers and grand instructional design ideas instead of with administration and management. Devlin Daley and I were fresh out of college, we felt the pain on the student side and as TAs, and we picked the brains of every teacher we could find.

What was so different about Instructure is that we said "teaching and learning is hard enough without technology getting in the way" and we meant it. There were a hundred little fibbly bits that we coded into the product, not because they were on the top of someone's feature list or because they'd close a deal, but because they were the right thing to do. We gave teachers permission to make their own content public, we gave students ownership over any files they uploaded, we made sure that there was a rational way to get to any piece of course content, we let people set their own email addresses, etc. etc. Sometimes this caused problems because we still had customers pushing from the management side, but almost always we fenagled a workaround that didn't compromise on "making teaching and learning easier". And even though nobody calls out those little finishes in their "why we chose Instructure" blog posts, they are a major part of our "different" approach, and they help close deals.

So yeah, that's gotcha number one. Are we still the student/teacher advocate? Nobody pays us to do that, and plenty of decision-makers push us to give it up, but we've got this in our DNA and we can keep it up. The edubloggers that would function as our checks and balances have mostly written off the LMS entirely, so that leaves it on us. Keep an eye on it or you'll find people getting less excited about our products, but without a clear reason why.

2. Keep Solving Interesting Problems

Blackboard's user conferences had a reputation when we showed up. They threw a great party, everyone said so. But people also said that they made a lot of noise to hide the fact that nothing interesting was actually going on with the product. Merging Blackboard and WebCT into a single company could not have been fun or easy, so they had a valid excuse, but at the end of the day interesting things just weren't happening.

Instructure is also known for throwing a great party. InstructureCon has always been a blast, with great swag, surprise performances, and a fun theme (I better see some Greatest Showman references this year or I'll be sorely disappointed). But it's also been a place to grow a strong community and to introduce people to the latest and greatest in Canvas.

Innovation isn't easy, and it doesn't come just at an annual user's conference. You can't just suddenly show up and say, "look! Innovation!" which plenty of people got at Instructure. Devlin and I made a great combo getting this stone rolling because we weren't straight execution (despite my misplaced best efforts) and we weren't just grand ideas, we had room for both, and it was awesome to see that keep going. You have to be deliberate about allowing new ideas to develop or you'll end up too demand-driven. Nobody asked for SpeedGrader, or a fully-public API, or an LTI app ecosystem. We have a great head-start with our strategy of openness, but watching some other companies, I'm surprised with how quickly "open" can die on the vine if you don't keep on it.

3. Don't Rob the Cash Cow to Pay the Pied Piper (And Don't Mix Metaphors)

When we talked to schools about their beefs with Blackboard, people kept saying Blackboard was focusing on too many things. Multiple times we heard "I mean, they're even running on-campus payment systems and swipe cards! It's no wonder they're not doing anything new with their LMS." Me, I'm more pragmatic. I get that you need multiple revenue sources, especially if you want to grow. Sometimes they don't make much sense to outsiders.

Instructure has had the Canvas product for a lot of years. After a bit we tweaked it for K-12. Then we did some work to get it ready for international. Then we introduced Bridge and Arc. Then we bought Practice and added Gauge. Then we started expanding our HCM suite. That's a lot of pots to stir, so you have to pay close attention if you want to do it right.

Investors ask a lot about the breakdown of our R&D and marketing investments. Are we putting everything into Bridge and ignoring Canvas? Are we giving international the attention it needs? Can we add a new product without jeopardizing our existing product quality? There are plenty of easy, reassuring bizspeak hush puppies, but the questions themselves are worth thinking hard about.

Are we solving interesting problems in all the markets we're going after? If we're not doing anything interesting then what are we doing? We have some great products, and I'm confident we don't need to start milking any of them as a legacy product just to siphon cash off into our next growth target. Maybe that would be a good use of funds, but it's frankly not enough, none of our products are *that* legacy. If we're going to add new products to our repertoire, then let's definitely make them awesome, we've got the ability to keep doing that. If we don't have the bandwidth to keep making all the things awesomer, then we have too many things going on, investor pressures be darned. But hey, the good news is that we have enough employees that people should be able to be innovating just about everywhere.

The red flag for me will be if we don't see innovations being discussed at InstructureCon. It's a bit of a coal-mine-canary for continued investment in our existing customer base. We can sell complementary products for more walletshare, and we can expand into new markets, but we have to be really careful. We don't want to move all the Risk pieces over to Asia and leave Europe covered in little onesies.

This one is particularly tricky, because it'd be easy to justify by saying "we're still investing heavily in Canvas", when really most of that "investment" was just ongoing support and maintenance. I'm more interested in the breakdown of the innovation budget, and, like I said, the best external proxy I can think of is InstructureCon announcements. There's a lot of interesting work we've been a part of, so keep an eye on what makes it to the surface. We've had some great years and some meh years as far as innovation goes. Don't let the conference get all hollow and stuff, and don't pretend to be excited about "innovative" iterative enhancements. People will notice. Customers know when they're being pandered to, and lipservice is transparent and boring. Keep the awesome going, instead.

4. Make Sure People Still Like Hanging Out With Us

This is getting long and a bit rambling, but stay with me. I'll put a cute unicorn at the end. The biggest gotcha, and the one I really don't have any visibility into anymore, is company culture. From the outside, Blackboard of 2008 felt stuffy and overbearing. The D2L lawsuit didn't exactly help that image. People didn't like talking to tech support, they felt like they were getting nickel and dimed on upsells, and nobody would have called them "cool". That's in spite of the pockets of earnestness we early Canvasites saw when we made a surprise visit to Blackboard's new corporate offices. There were people at the company trying to do the right things for the right reasons, but it just wasn't breaking to the surface.

Let's not get to that point, eh? We built an awesome company that didn't take itself too seriously, where everyone was genuine and genuinely trying to make things better. Everyone knew we needed to get to the root issue before crafting a solution, and that every touch point with our customers needed to be an impactful one. We weren't a company that hired young single dudes to squeeze extra work out of them with catered dinners and ultimate frisbee. But we also weren't a company where people took three-hour lunches and tried to beat the commute home. We worked hard because we felt we were doing something important. We had an open floor plan because private office jockeying is a joke. We made our panda pinata be the office receptionist by hooking it up to a speaker with text-to-speech. We came up with goofy meeting room names because it was fun to watch people in expensive suits file into a room called Battletoads. We didn't take all that stuff seriously because we we were too busy trying to make a difference where it mattered.

Obviously you have to grow up along the way (that panda receptionist could be rude), but we never have to lose the passion that draws people to work for Instructure because, hey, it seems like an awesome place where people are doing awesome things. When the new hires I've talked to have still felt that vibe, it made me happy, let's not lose that. We didn't always get everything right (ask Ryan Shaw how many times he had to re-merge master into the SpeedGrader branch before it was ready, or Sunny Washington about inter-departmental lunch invitations), but we did get a lot right. We were extremely lucky with our timing, I'll be the first to tell anybody. But it would be a gross oversimplification to assume that the only reason we're doing a "Canvas:Blackboard" exercise thing right now is because we showed up with cloud-plus-modern-web right at Blackboard's weak point. Who we are bleeds into everything we do.

Keep Doing Awesome

I haven't kept the best count of how many early employees are still at Instructure, it's been ten years and people move on. I like to believe that the culture transfer has been happening seamlessly all along. We've changed offices six times, we've shuffled through plenty of execs, but I hope Instructure is still the awesome place to work that it used to be. I'm actually very confident that with the right energy we can keep doing awesome things all over the place, just like we have in the past. I hope people are emotionally invested and trying to make a difference for education. I hope that people on the ground working their heels off to do the "right" thing in spite of the all inevitable corporate pressures to not bother, can be proud of the end result. If that remains true, then I'd say we've earned our place at the top of the list.

You made it! Here's your reward:

Ooh, bonus gotcha for the road. Blackboard Ultra is still not really a thing. I'm sure there are plenty of internal Instructure jokes about it. But turning a ship that large is hard, and with private equity on your back and ongoing reorgs I get why it's taking so long. It may be asking too much to try to get Canvas through the next technology wave (blockchain-based LMS, anyone?), but please let's don't promise a product years before it's ready. Personally, I don't think you need to promise new features unless they're imminent, just release the things when they're ready to run amok, but that's more an opinion. This market isn't heated enough that you need to get the jump on anybody, just do awesome stuff and share it when it's ready, I say.

Footnote: Somebody somewhere is probably going to call me overly simplistic or naive. That's fair, ex-founders and their rose-colored glasses is probably a meme somewhere. I've seen Instructure change and evolve a lot, and hopefully people will agree that I took the changes in stride, I didn't keep pining for the good old days every time we moved up a rung on the corporatiness ladder, progress means you lose a bit but you gain more. But maybe I'm all negatively nostalgic, I'm obviously not the best judge. I doubt there's a shortage of castaway founders shaking their heads over the grand insights nobody is asking them for anymore. Whatever, this is getting too introspective to actually be productive. Let's focus, here.

Please Don't Bash the Aggregator

2015-03-12T10:59:00.000-07:00

The Internet is made up of a bunch of disaggregated units that we call web sites or apps. Every unit can provide its own diversity of opinion, tone, arguments, activities, etc. Each unit has its own strategy for styling and interaction, its own bugs and awesomeness, its own security policy and often its own terms of use. Each unit can be physically situated anywhere in the network (the idea that we need everything in "the cloud" is really just based on corporate convenience). We typically use one of four popular rendering engines to access the loosely-connected units, and it's all kicked off by typing an obscure code into an empty text box. It's actually kind of a miracle that anything meaningful ever happens there.

Nobody exclusively uses the disaggregated Internet. If you're using browser bookmarks or a feed reader or an LMS or email or a search engine or social network then you're using at least one of what I'm calling an aggregator. Aggregators collect items either automatically, or based on user input, and group them in a way that makes it easier for the user to handle.

Disaggregation Pros and Cons

Disaggregation is an unsung hero of the web.

A completely disaggregated Internet would have every person with their own web site for which you would punch in their unique address to check in with or communicate with them. There is nothing inherently wrong with strong disaggregation, I'm actually a big fan of it. In my mind I envision everyone's home router having a built-in web server with their own Dropbox, Calendar, etc. (I think that'll be the next great evolution of the Internet, but now I'm getting off-topic).

The problem with a completely disaggregated Internet is that, by itself, the motivation to access any one unit is relatively low. I like Bob, but I really don't need to see what's going on in his life or check if he's messaged me all that often, so I'll probably only visit his disaggregated unit of the Internet when he tells me there's something waiting for me there. Now if I lump Bob, Fran and my other coworkers together, the motivation to check for communication with them *as a group* becomes more valuable. So we figure out a way to aggregate all of our interactions into one web site. Many web sites work as internal repositories, collecting items crafted or imported by site users and presenting them for other users to see. These internal aggregators are what I'm calling silos. Silos act primarily on the assumption that what you want is on the current web site, you don't need to go somewhere else to find it (they also typically underserve some percentage of their users by catering to the massive majority).

The LMS vs. Disaggregation

Walled gardens are no fun.

The LMS is traditionally seen as a silo. Instructors build learning resources, start discussions, distribute assessments, etc. inside a single web site. Learners use the web site because they have no choice if they want to graduate, and spend hours learning to navigate an interface that they'll never use again once they're done with school. The inherent bias of "everything important in a single place" discourages discovery outside the LMS and prevents the learner from getting comfortable with the disaggregated power of the Internet. It also discourages experimentation by instructors because they are stuck with whatever features their particular LMS deems valuable. One strong argument for this silo model is its convenience for the institution.

And hey, if you want to bash the LMS as a silo I'm all for it, I'll stand next to you and join in. But we do a disservice if we pretend that the LMS story stops there. We need to look at the alternatives to the LMS as a silo. Some teachers say just ditch the LMS and use your own disaggregated web site with a couple other modern web tools linked up. I ask them about cognitive load for the learner, having to jump around to all those different web sites and logins. Some tell me it hasn't been a problem for their web-native learners. That's cool for them, but the learners I talk to hate -- like really HATE -- jumping around the web trying to remember where their homework or lecture slides are. And maybe if you had only one instructor doing the disaggregate thing it could work, but with a full courseload of web-hopping I'd get stabby too. Learners pine for an aggregator. So do administrators, for very different but justifiable reasons. Instructors do too, it turns out. Learners submitting homework on their personal blogs is great until you have to start pasting URLs and switching tabs to get it all graded with feedback. So we circle back to the LMS silo, as if silo is the only way to get aggregation.

http://www.educause.edu/visuals/shared/er/extras/2014/ReclaimingInnovation/default.html

Learning Aggregation

My favorite aggregator, RIP :-(

Un-siloed aggregation isn't impossible, of course. We need to do a better job of teasing apart the aggregator and the silo, because they don't have to be the same thing even though sometimes they are. Silos are self-referencing, internal aggregators (Facebook, AOL, LMS, etc.) but there are also great external aggregators (feed readers, search engines, etc.) that collect without lock-in. Email is probably the best example of external aggregation. I can host my email on any number of services or run my own, and there's a well-defined protocol for notifying other units of a new item that may be of interest to them (email is slightly different in that the actual item gets passed around, not a link or snippet). An external aggregator is a jumping-off point that gives a higher-level view without trying to force lock-in, and the LMS, it turns out, can be a powerful external aggregator.

When we started Instructure almost seven years ago we'd been thoroughly indoctrinated by David Wiley, Jared Stein and company on the merits of disaggregation. We started our LMS by drawing everything up completely user-centric and disaggregated (e.g. Google Spreadsheets or equivalent for the gradebook, SurveyMonkey or equivalent for the quizzes, etc.), then looking at what made the most sense to pull back in for the sake of user experience. Everything that got folded back in was done in a way that it could be swapped for an alternative if desired. We splattered the site with RSS feeds (and RSS aggregators), notification policies, URL submissions and user-defined connections. We made it easy to pull in or link to other web sites, and when we discovered LTI we kind of went crazy implementing the heck out of it. We built a whole bunch of integration points that, while they weren't showing up on RFPs, were still the right thing to do.

We were trying to build an LMS as an aggregator. A jumping-off point for the rest of the web. A learning platform -- not "platform" the "open"-like buzzword that at this point just means "thing on the Internet", but "platform" the jumping-off point and a place to get an idea of what's going on in at a higher level. I'd say we've had mixed degrees of success making Canvas a learning platform. Some parts of Canvas are still too locked-in for my liking (and I'm excited for the potential of xAPI and Caliper), but in general it's the best example I've come across for learning aggregation.

Incidentally that's also why we've pushed so hard for LTI. LTI is an integration standard, and while the UX of launching third-party apps from a consistent wrapper is nice, the real value is in not having to log in to or paste the URL for another web site as a disruption of the learning flow, and in being able to pass useful information back to the aggregator. Two-way communication, just like the Canvas APIs.

Therefore, What?

This post is like half of a book long at this point so I'll stop. Just know that "LMS" doesn't have to mean "silo." To me, when you say "the LMS is a silo" you're not helping. I'd much rather hear "the LMS is silo but *should be* an aggregator" because it's more productive. I also think it's becoming more of a reality, and though I doubt we'll ever get all the way to the other end of the spectrum, we have plenty more room to move in the aggregator direction. The Internet *needs* aggregators to function, and they provide some serious value that we all benefit from every day. So let's not throw them out with the bathwater that is the LMS silo.

On the Dangers of Prioritization

2014-11-13T12:10:00.000-08:00

So you're running your little software startup, and things are going great. You've got some really happy users who are finding bugs and suggesting new ideas, and more customers are starting to come on board. You've hired some folks to help keep things moving along, and they're excited to help out. You're still stressed out of your mind, but at least there are other people now to help share the load.

Prioritization is hard.

When it comes to developing your product, you've got a pretty good idea of what needs to be built when because you're basically talking to every customer and employee on a regular basis. There's a file somewhere that you half-heartedly maintain and call "the roadmap", but if someone asked you "what should we work on next?" there's a 50% chance your response wouldn't be anywhere on that document, things are moving too quickly.

At some point people start talking about your brain as a single point of failure, and you realize they're right. So you use your bug tracker to document new features, and everyone feels a little better knowing as least the general ideas are written down somewhere. You all agree that this is progress, and part of growing into an actual organization.

What happens next could come from a couple different places. Your sales or support groups start wanting to know when new features are coming. They're probably not so much concerned about specific dates as they are a general order of priority. Or your development group wants to start doing research leading up to the development of new features. Or your customers want to inject their perspective into your timeline. Or one of your early hires thinks you're not giving enough attention to the cool new thing you talked about six months ago. However it happens -- and it will happen because it's a healthy part of your company's growth -- the main point is that someone, somewhere, pressures you to create an ordered, prioritized list of things you will build or fix.

There are all sorts of legitimate concerns with roadmaps, from time commitments to public visibility to levels of granularity, and I'm not talking about those concerns right now. I'm talking about the danger of development prioritization. And specifically, prioritization by algorithm or committee.

Don't misunderstand me, priorities are important and valuable. Someone (probably multiple someones) will sit down and label all your bugs and features with tags like "on fire", "must have", "nice to have", "affects everyone", "customer-specific", etc. Then you're going to say, "clearly we need to start with the emergencies affecting everyone, work through the must-haves, and eventually get to the nice-to-haves." It'll be a huge relief knowing that you've defined a heuristic that others can use to make informed decisions, and that you're no longer the blocker on all development everywhere. Plus, it'll sound perfectly rational to prioritize work based on the number of users affected and the degree of impact it will have on affected users.

It'll also be wrong.

Okay, not wrong, but definitely insufficient. Once you give up control of development to that algorithm or committee, you lose something significant. One of the most important characteristics of a founder is that they have the freedom to build something that few if any other people think is important enough to build. And guess what? You just gave that up without even realizing it. Or maybe you did realize it, but you just don't see how there could be any alternative. Obviously you making all the decisions by the seat of your pants won't scale, and you don't really trust anyone else enough to pass that liberty on unrestricted. What else were you supposed to do?

Well, if you think your product has a sufficient level of disruption already baked in, then I guess you're good to go. If not then you've got a problem. Not only will bugs keep creeping in to (rightly) steal priority, but so will deal-breaking features and incremental enhancements. How can you justify wasting time on a moonshot-maybe when you have concrete evidence that the standard features you're missing are a serious customer acquisition impediment or opportunity? Moonshots don't survive prioritization algorithms.

You can argue that you've got a sufficiently innovative team, and everyone will see and recognize the value of innovation. But the ROI on innovation is hard to quantify, and it's inherently higher-risk, which a growing company is (justifiably) getting less and less excited about. I've seen lots of dev priority lists in lots of different styles, and the only time I've seen them not have this problem is when they were the hazy unmaintainable kind owned by a single individual.

George Bailey makes it look so easy.

There's also a deeper problem. Once you have development priorities, who exactly is going to be out there looking for the innovations? When there was just you, 100% of the company was searching for magic, in a way rather aimlessly. The first couple hires were still after it, but gradually the percentage of energy being put into outside-the-lines ideas will shrink. And the smaller it gets, the more work it is to maintain culturally against the increasingly structured to-do list. You can flex your founder muscles and force some ideas through, but as time goes on that will feel more and more against the grain. Without intervention, at some point you may lift your head and realize you're thinking about this stuff completely differently than the rest of the company.

So what are you supposed to do? This is why 20% time has such a great appeal. Or a separate dev team that works on crazy prototypes. Or the hackathons where developers can spend a couple days on whatever they want. Or a founder that people just leave alone to work on whatever they want. Those are examples of people saying, "our system is flawed but it's not clear how to fix it, so let's just set aside some bandwidth outside of our broken system to try to compensate for its flaws."

And guess what? That's the best I've seen, anyway. We've tried all of those things in one form or another at Instructure, and they've each made their own dent. But if there's a silver bullet for the prioritization-innovation conflict I'd love to hear about it (other than keeping the company small, but that limits your bandwidth for other reasons). Maybe innovation-squashing is just an innate characteristic of prioritization.

The fact is, I don't think truly innovative ideas are the kind that show up on a roadmap. In my experience they've come out of left field when you're working on really important other-stuff, so there's a huge risk of them being brushed off. It's not the kinds of things you find by hunkering down and singularly looking for the next big thing. By the time they show up on a roadmap they probably seem obvious, but they'll never get that way on their own. They start out as little sparks that need some oxygen to become a flame, and then to be identified for what they are and given some attention and kindling to grow. And that just doesn't happen when everyone is busy working on the day-to-day.

You have to figure out a way (that works for your company, because I'm betting it will be unique to your company) to repeatedly jostle your employees out of their routine enough so they think differently, and also feel a desire to bring up their ideas (on-boarding indoctrination is one trick we've used to help calibrate there). Once a quarter won't cut it, it has to be a repeatable thing because it often takes a couple strikes to get lit -- but not too repeatable or it just becomes fake or part of the routine. And it shouldn't be just for developers, ideas come from anyone connected enough to pick up a trend. Then you need product-oriented people who explore these sessions and pull the separate-but-related sparks into the start of a bonfire.

It's not a trivial thing I'm talking about, but it's a big part of why large companies stop innovating, innovation just doesn't get the legitimate air-time it requires. I'm not convinced that scheduling weekly "out-of-the-box time" is the right approach, but I haven't actually seen many other strategies in the wild. I have this hazy vision of monthly "off-kilter pitches" that get approved as incubation projects, but it's not concrete and I've never tried it, so I can't endorse it. You're essentially looking to give everyone both time *and* empowerment, to get the percent of employees working on innovation back up as high as you can get it. So whatever way works best for you. I think that's possible without losing the value of your prioritization, but I also think prioritization will eclipse innovation if you're not actively avoiding that outcome.

Customers Can Ruin Your Vision, But They Don't Have To (Part 2)

2014-06-09T10:22:00.000-07:00

This is a link to Part 1, and probably fits better for earlier-stage companies/products.

Product people, like Jedi masters, play
the long game, they do.

When you get bigger the problems shift. It's been amazing to watch Instructure move from stage to stage, and it was usually very obvious when we'd hit a new stage because the internal dialog adjusted to new topics -- getting the product out there, attracting new customers, building innovative features, fixing bugs to scaling out, etc. all in different amounts at each stage.

Anyway. Once you start to grow your company you're going to be dealing with more customers, which means more opinions and more requests and demands. Thanks to the Internet (thanks, Internet!) it's possible to gather more feedback from your customers and potential customers than you can possibly know what to do with*. And the frustrated ones will happily give it to you in droves.

That's not inherently a bad thing, but it definitely can be. It's really easy to get frustrated when you have a vocal minority of customers demanding a feature or a change that doesn't match your long-term vision. I have another blog post brewing on how product people need to play the long game, but suffice it to say a good product person will hear feature requests that make them nervous about what direction those changes will inevitably take them. Blowing off the requests sounds like a bad idea though, and vision-selling doesn't always work because there are perfectly reasonable (read: not-hypothetical, like you're cute little long-term vision thingy) justifications for the change.

The fact is, once you move beyond the early adopters you're by definition entering a customer base that is less forgiving of you-not-having-what-they're-used-to-having. You'll see increased pressure to implement things that aren't part of your vision. Parity with legacy systems is a really big deal for the less-risk-averse customer majority that is trying to convince their users that migrating to a new system is a good idea, and won't ruin their lives forever. A healthy vision is re-evaluated constantly so go ahead and take those opportunities to stop and re-evaluate. But if it still doesn't match then what do you do?

I've seen a couple things work well for us at Instructure.

The first approach is to go down a level in your discussion. Stepping back and saying "what are you really trying to accomplish" can be super valuable, and should really be the first tool in a product person's belt anyway. Sometimes you can redirect the customer's energy in a more exciting direction (like with BYU-Hawaii in the early days), and other times you can at least find a compromise that you're both ok with.

Wharton, for example, didn't want us to show final grades inside of Canvas because they had another system that kept their official grades and they didn't want students getting confused. But keeping students informed is a major part of our vision, and being able to see how they were faring in their courses throughout the semester felt really important to us. We pushed and they pushed and we were getting nowhere. So we stepped back and discovered that the vocabulary was the real issue. If we could call it something other than "final grade" in the interface then they'd be fine with keeping it. That was loads better than the custom-JavaScript-to-hide-final-grades-just-for-Wharton path that had been proposed before.

The second approach is plain old vision-selling. Ideally you'll be able to sell them on your long-term vision and they'll say "that sounds better, let's do that". Sometimes that's just a short email, but more often it's getting on the phone or (better yet) meeting them in person. The point is to actually convert the person, not to get them to shut up, so make sure you're including them in the decision, giving them a peek at the future. And if you're doing that why not also get their feedback on it? If they feel attached to the future because they had a part in it, there's the chance they'll not only stop pressuring you to change, but even help evangelize for your vision.

We've turned multiple critics into evangelists this way (not in some manipulative way, don't get me wrong. We legitimately included them in the discussion and they legitimately got excited about it), and when it works it tends to work really well. But make sure you're actually going to follow through on what you discussed/promised or you'll be worse than where you started.

The third approach only works if it's a project you intend on doing eventually, and the problem is prioritization. Basically you say, "ok, is this more or less important than X, Y and Z that we're already working on?" Don't ask unless you're willing to adjust your priorities based on the response, but it's ok to make customers think hard about what's most important. It's actually usually pretty insightful to watch that process from the sidelines.

Our client services department had the idea to start maintaining a top-10 request list early-on. This gave us a very helpful point of reference to compare priorities. If you're planning on doing both things eventually, then it seems like a great idea for your customers to help prioritize the things you're building for them, and it has the added benefit of showing them why their new feature isn't getting the attention they'd like it to. Many times the response was, "you're right, X is more important. I'll go help my noisy faculty member understand why we're not doing that."

Internal prioritization is important too. You need to have your whole team on board with the list of things you're going to build, because if a salesperson really wants a certain deal or an executive hears a noisy frustration while visiting a customer, you'll often hear about that need in a disproportionate way. Even your web forums will be skewed and can be used as fodder by the enterprising employee to get their pet feature implemented. But a strong priority lets you rationally step back and say, "ok, but is that really more important than the ability for people to log in?"

Sometimes you just can't come to a resolution. One school wanted to prevent students changing their default email address in order to keep everything on controlled systems. We assured them that their students are coming to their campus with already-established email workflows, and a new address quite often would just be a black hole. Or they'd just forward their emails and the data would leak out anyway. But their legal department wouldn't budge on the requirement. I lost track of that thread and I can't actually remember how that one turned out. Maybe we made a cheat sheet showing the students how to set up email forwarding.

I'm pretty sure this list isn't exhaustive, and these don't always work, but they're some of the ways we've tried to address the conflict between vision and a growing customer base with diverse needs. At the end of the day the product you're building should be something that attracts new customers but also continues to excite your existing customers. If your vision isn't heading straight down that path then it's probably going to be a bumpy ride. But more times than you might think it's possible to get customers on board with your vision one way or another, which ends up being a win for everyone. A good product balances happily between customer-defined and company-defined. Your customers aren't stupid or malicious, but they shouldn't build your product alone -- and neither should you.

* It's worth noting that open discussion forums are tricky things. I highly recommend them because of the insight they can provide, but they need to have a very clear purpose in mind. We implemented a "Feature Request Forum" where we want people to suggest ideas for way to continually improve Canvas. It was a really great idea, and has been super valuable at times. However, we didn't do the best job defining purpose, and since it's significantly easier to suggest a feature than to implement it, the list got huge and started filling up with "why haven't you built this yet, it's been sitting here for three years!" flameage. The goal was never to Build All the Things, so we clearly had a misunderstanding. We wanted a place where we could discuss the best way to implement new features and also hear crazy ideas we might not have thought of. We're gradually reworking our forums to get to that point but it takes a lot longer to transition there than to be explicit and clear from the get-go.

Customers Can Ruin Your Vision, But They Don't Have To (Part 1)

2014-04-22T09:53:00.002-07:00

Hi entrepreneur, I guess this one's for you.

When you take a brand new idea and decide to make it into a reality, just about anything is possible. You have an unadulterated image in your mind of the ideal customer who will love exactly the thing you want to build. Of course your opinions will be seen as visionary and spot-on. How could you not know what you're talking about? (Side note: founder hubris is one of the reasons a Product Validation Tour is so important)

It's important to have a strong vision. Here's hoping
Paul Bettany can pull it off (too obscure a reference?).

Then one day you finally get a real customer (for Instructure it was BYU-Hawaii, and we drank mango nectar and wore leis to celebrate). They're your first customer ever, so you take a picture of their check and you listen very closely to what they have to say. They are well aware of their position of influence and push you hard to implement their pet features because holy cow why wouldn't you?

This is your first big test of vision (second if you count the product validation tour, but if you did that right it wasn't much of a test, more a collaboration). For us, we told our #1 that we were aiming high, and while we were grateful for their business, we needed to make sure we were implementing things that worked for at least 80% of our customers. They cheekily responded that they were 100% of our customers :-P, so what was the big deal? BYU-Hawaii is not the bad guy in this story, by the way. Customers aren't bad guys.

This was the Test of The Special, and it's a tricky one to handle. The Special is the extra feature that doesn't really fit into your vision, but which at least some of your customers are telling you they need in order to do business. If you want to build a consulting gig then embrace the Special. If you want to build scalable software then the Special is very dangerous. Not evil, just dangerous. Especially early-on.

When your product is young it should have a very well-defined trajectory. That whole founder hubris thing, where you know exactly who you're serving and what you're giving them and what features you're going to add when, that's actually kind of important. You make darn sure it's valid and that there are enough early adopters to get some critical mass (ahem, PVT), but then you stick to it. If at this point you're already spinning off into side-projects and Specials, then you've got a vision problem, and you're going to end up wherever someone else pushes you. There's a verse in the Bible that covers this nicely, actually:

"For he that wavereth is like a wave of the sea driven with the wind and tossed." -James 1:6

Adding extra appendages can be dangerous.

Know where you're going. If you build a third arm that you're not excited about but that you think your customer might need to be happy, remember that you're going to be maintaining that arm for the rest of forever. If it glitches, you have to stop working on your laser-guided vision processing chip and go rewire that stupid arm. Maybe you can't get out of building it, because maybe your vision could use some adjusting, and if that's the case then be very clear with everyone (especially internally) that the change you're making is a reshuffling of priorities, and that other things are going to slip but that this is important enough to do it anyway. In the future you'll get big and changing directions will be hard enough on its own, but for now you should introduce a little artificial friction toward change because it will force everyone to stop and say, is this really the right move for us?

If you decide to build it you'd better figure out a way to make it an awesome part of your vision. Because if you're not excited about it, your team won't be either, and it'll be a second-class citizen in your system and your customers will notice and resent you for it and you'll be worse off than if you'd never built it in the first place.

For us, the thing BYU-Hawaii was asking for was a video discussion board. Some other edtech tools would let you create either a text or video/audio board. BYU-Hawaii needed video discussions as part of whatever LMS they were using -- and for good reason, their distance ed program was serving students on different islands, regions, and continents with all sorts of bandwidth constraints and time zones. But we couldn't afford to maintain two different discussion tools, and frankly it felt gross and weird to have multiple tools that served almost the same purpose.

So we had the aforementioned chat with BYU-Hawaii. Sorry, we're not building two discussion systems. We didn't want to blow them off completely, so we talked to them about the plans we had for discussions and also grading. We outlined our vision with them and said, "there's got to be a way we can fold this into our vision that is as exciting for us as it is for you." This was a critical piece of their educational process, so it wasn't something we could lay away for future work, which meant it needed to be something we could get stoked enough about right now that we were willing to delay something else to make it happen.

We batted some ideas around and in the end what we proposed to them was a audio/video widget that could be used to drop media into text-based discussions as well as other parts of the system. After talking to BYU-Hawaii we looked for how we could fold their need into our vision since it wasn't going away, and it turned out we were actually really excited about the prospect of "video-everywhere" to improve the learning experience, it had just been a little farther down the path. Implementing it was going to take longer than they wanted, but they now saw the vision and agreed with it, and there were some feature-parity elements they were willing to let slide to help make it happen, so it worked out nicely for everyone.

If we had just built what BYU-Hawaii was asking for we would have been taking a very large step down the path that we resented other edtech companies for taking. Subpar one-off features is pretty standard fare in edtech, and the whole reason we started Instructure was to not be That Guy. It wouldn't have ruined us as a company I don't think, multiple discussion types would have been a bother and not particularly innovative (video-everywhere, it turns out, is now a huge value proposition for people thinking about switching to Canvas, because it's so tightly integrated and easy to leverage), but we would have survived. Just not with the same vision.

Sometimes the solution is 12 moves away, but it's there.

The point is, you HAVE to start with a strong vision, and think hard about any time you're asked to stray from that vision. It may be ok, but it may not. And you have to get creative. At the end of the day a strong product visionary will look at customer demands and trace out in their mind a variation that could fit in with the existing vision. Maybe it's right there ready to go, maybe it's a few steps down the path. But somebody at your company should bet getting a rush out of trying to find that overlap, and then helping customers see how their needs can serve the "greater good" as you head toward that awesome thing of the future you started out building in the first place. And most of the time you should still probably say "no". Figure out where it might fit, then decide if it's worth it. BYU-Hawaii is one of the examples where we adjusted course, but those were the rare exceptions.

Open is Not an Afterthought

2014-04-02T12:51:00.002-07:00

I will make this one day

Open source, open API, open communication, open content, open platform, open roadmap, open door policy. Open got thrown around as a buzzword pretty hard a few years ago so I can understand if you're turned off by it, but I for one still think it's really important.

If you're a developer, product manager, entrepreneur, etc. wondering if you should make your "thing" more open, yes you should figure out how to open it -- even just a little bit -- right away. You probably should have been thinking about it a year ago. Open (like accessibility, incidentally) isn't really something you tack on after-the-fact, it's a whole lot easier in young projects. And for me it hasn't typically been something that happened naturally. You usually have to fight for it.

Open is great for a lot of reasons. It gives your team something not-hidden that they can feel pride in, it forces you to think about the *real* reasons why you're doing something, and of course it lets others build on top of your stuff. Open is about the unexpected leverage that someone else finds without your help. In my experience those discoveries typically happen later than you expect them to, but obviously not at all unless you first open things up. And in the end they're big success stories for you and your users.

Example time.

Our logo is open in the middle.
Coincidence? Mostly.

The only reason Canvas has an open API is because we decided we should have one. When we started building an iPhone app back in 2011 we decided the app would only use public API endpoints -- if they didn't exist, we'd write them. Later we extended that rule to new features in Canvas proper as well. It didn't provide short-term benefits other than maybe code hygiene and it took more effort to build third-party-consumable endpoints. But now we have somewhere around a million third-party API calls per day from lockdown browsers, portfolio and analytics tools, alternative gradebooks, badging apps, and other neat projects. People enjoy building on top of Canvas because they can just create something cool, no babysitting required.

When we first started building Canvas we really wanted it to be open source. It was important to me and Devlin as developers for many (some admittedly naive) reasons. Every investor we talked to would get hung up on that bullet point, though. How would we make money off people running the codebase locally? Were we going to offer support contracts? Were we a SaaS company or a support company? We eventually conceded, assuming they knew something we didn't, only to circle back and find a business reason for "going" open source in 2011 (side note: our initial commit message was an easter egg that no one ever caught. Too subtle?).

We also have always worked to have an open relationship with our customers and users. Back when we were still piloting with a couple dozen teachers, we decided that we were going to include our customers deeply in product strategy. It made sense to us because it's what we'd already been doing with our Product Validation Tour of a Metro and a slide deck. With every new customer we sat down and talked through problems, sometimes finding creative (read: wonky) workarounds to just get things done. We were straight with them about our shortcomings and our future plans, and expected them to be honest with us about their needs vs. wants. Now it's a foregone conclusion that our client services teams will work *with* customers to find solutions to problems, and I love it.

The "open" bullet point I'm most proud of though is the open architecture we're still building. When I first heard about LTI (an interoperability standard in edtech) I got really really excited about the promise it offered and threw together a Canvas implementation as quick as I could. Nobody really cared back then, and it was obvious pretty quickly that LTI didn't quite hit the dream Devlin and I were talking about back in 2008 (we bandied the idea around with Jon Mott in 2009 too), where LMS components like discussions or gradebook could be replaced with alternatives. So we started extending LTI to get it to where, combined with our open API, you really could swap out whole features in Canvas. Now when edtech startups decide to integrate with an LMS they come to Instructure first because it's the easiest integration (plus our documentation is slick).

Why did he write on his head?

This is starting to sound like a brag-fest, sorry. My point is, every single time Instructure took a step toward openness, it was premeditated. And there were naysayers. And the business value was unclear. And we did it anyway. And in the end it definitely paid off. We've often had to win over new people at Instructure to the value of open, and we still do sometimes. But once they experience it for themselves then they're usually on board after that.

I'm a believer in open because I've seen the difference it's made at Instructure. Frankly, if your company can't get over what might happen should you open up your code/content/API/platform/communication then you either have the wrong kind of competitive advantage or you're not valuing your users as much as you should. People who think lock-in is the same as customer stickiness aren't in it to improve the user experience. Opening up doesn't provide immediate returns. But gradually it wins over a few early adopters, then a few more, and then things really get interesting when you start to find those exciting ideas that someone else came up with. Ideas that make a difference that wouldn't have been possible without being open.

Instructional Design is Not Interface Design

2014-02-04T22:40:00.002-08:00

Note that neither is really about picking good colors.

Designing good interfaces is about finding elegant solutions to problems. It's about understanding what users want to accomplish so intimately that when you show them your solution the beauty goes unnoticed. It's about building an interface that lets the real work can happen unhindered. You shouldn't have to think about the interface you're using, it should get completely out of the way.

Which in educational technology is actually kind of a problem. I didn't realize it was an issue until a few years ago. I used to tell people that instructional design and interface design are at their core the same thing. That was pretty naive on my part, but it was based more on practical observations than graduate-level research, so I don't feel too bad about it. At the end of the day what I saw most instructional designers doing was helping people build learning experiences that were intuitive for learners to work through. Get rid of weird navigation, structure the content with a natural flow, don't use ugly fonts. Stuff like that. Building an intuitive, elegant workflow that doesn't trip people up and lets them focus on what they're trying to accomplish. Learning interface design.

Image searching for "instructional design" is disheartening.

The problem with this perspective didn't become apparent until I had a little more experience under my belt. We were doing a redesign of some components in Canvas, and the designers showed me their ideas, and when I objected to their designs they were legitimately baffled as to why I didn't agree with them. What they were proposing was focused so completely on streamlining the user's (learner's) experience that it was actually going to negatively impact the learning experience.

See, learning is different than learning management (don't get me started on "LMS", it's a term I've always hated but never bothered to change). If you're just managing your learning experience then yes, by all means, focus completely on optimization. Log in, get stuff done and close that browser tab as quickly as possible. But if instead you're trying to facilitate learning then you need to be concerned with more than just saving someone time. Learning requires conflict, it involves running up against differing opinions and joining unexpected discussions and trying to overlay acquired knowledge in new and possibly confusing arenas. None of that is very clean or streamlined.

Good instructional design isn't about getting to the nugget of information and then getting out without too many clicks, even if that is most of what I'd seen early-on working with schools. Really good instructional design would actually try to surface social interactions that would be beneficial for the learner to engage in -- even if they weren't intending to participate in them when they first logged in. Even if they weren't really in the mood. Even if it meant noticing the interface.

Calvin taught me a lot about learning in social settings.

It's not about forcing a learner to post at least once in the discussion board in order to get a grade, but it should be about exposing them to the experiences they mightn't pursue on their own that will help them deepen or solidify their understanding. Maybe in a perfect world all learners would see this as part of their successful learning workflow, in which case you could fall back to arguing that instructional design and interface design have the same goal, but that's not the case today. A good learning interface can't take just the learner's immediate interests into consideration, or it will miss the bigger picture completely.

Anyway, something to think about if you're ever in the business of designing educational technology.

Should Everyone Learn to Code?

2013-12-20T09:25:00.000-08:00

This is a repost of a post I wrote for Instructure's Keep Learning blog. I had a couple other paragraphs that got cut out that I'll slip in here as well. Enjoy!

Should computer programming be standard curriculum? This question seems to come up every few months, and it came up again for me a few weeks ago, so I thought I’d take a crack at it. I’m a programmer by training, and I spent two years in a computer science research lab, so I have some inherent biases, but I’m also a dad who’s very concerned with how my kids are shaped by what they learn in school, so hopefully my input is useful.

On The One Hand …

Of course everyone should learn to code. Just like everyone should learn to change a leaky pipe or a flat tire, and to multiply decimals, and to manage their finances, and to present a compelling argument in front of a group of people. You don’t learn to code just so you can be a professional coder.

To me, learning isn’t so much about developing skills as it is about having the contextual understanding to make sense of the world around you. We try to reduce observed chaos by finding mental models that match reality as closely as possible. When we understand something it’s less scary and more predictable—and predictability is empowering. When our culture can’t function without software, but for most people that software is still a voodoo art, it’s high time we gave more people the context to know what’s going on.

A common argument against everyone learning to program is that there will be more bad programmers in the world. Sure. Just like there are at least five bad, self-declared plumbers on my street. And while they may not know their limits exactly, none of them try to tackle industrial plumbing projects that are clearly out of their league. It’s not the end of the world if newbie programmers cut their teeth on hobby projects and don’t write perfect code.

Programmers have the whole world at their fingertips. A programmer can ply their trade in anything from medicine to finance to farming. As a programmer, I can answer my own questions, almost without fail. I can write a quick script and see if my new idea will really make things more efficient or not. And, just as importantly, I can recognize which of my questions are tractable and which aren’t. That’s hugely empowering, and it means I can be more productive than many other people in similar situations.

On The Other Hand …

Saying everyone needs to code just because every industry needs coders is like saying everyone needs to know accounting or law. People should be able to manage their own finances and understand a basic legal contract on their own, sure, but not much more than that. It’d be great if everyone had all those skill sets, but that’s not reasonable to expect. It’s not such a bad thing if “code” lives in the same realm for most people as “legalese” and “accountant-speak.” There’s a limit to how deep you should need to go into any non-essential subject. Remember, most programmers can’t code in binary or assembly and can’t solder their own circuits. Maybe the typical software user’s expertise can stop at power user rather than armchair coder—which would still be a huge step forward.

There’s also the concern about creating a generation of same-mindedness. Studying computer theory isn’t a trivial endeavor, and quite frankly, ends up rewiring your brain in some very noticeable ways. Most programmers have a very similar perspective on how the world works and how to tackle problems. Maybe they’ve found the optimal mindset, but maybe not. I would be reluctant to raise up an entire generation of students to have that particular perspective without some serious thought first.

Therefore, What?

I want to take this argument, “everyone should learn to code,” and tweak it. The goal of teaching everyone to program shouldn’t be to make everyone a programmer. That’s just silly. I work at a software company, and I’d say that at best one-third of the people in our office would benefit from having coding skills. There are many jobs that will still need to be filled, and just as many skill sets outside of programming that are going to be important for the foreseeable future.

I think everyone deserves a contextual understanding of how the world around them functions. I think everyone should learn to code—a little bit. I don’t think everyone needs to know the ins and outs of JavaScript or Python or Java or whatever. Even more importantly, I don’t think everyone needs to know (or ought to know) decision trees, binary search, complexity classes, or tail recursion. But I think everyone deserves to know:

How the Internet works (and that it’s not the same thing as a web browser)

How to craft a set of instructions that drive a system (for Codecademy, Lego Mindstorms, Scratch, or whatever)

How to tinker and troubleshoot (to help overcome the fear of breaking things, which is a legitimate, but crippling factor in tech adoption)

And also maybe (but maybe not) a couple other things:

How to break down a complex problem into smaller, more manageable sets of problems

How to test the correctness and robustness of a solution to a problem

I guess you could say I think everyone doesn’t need to intimately know how to code, but everyone should learn how coding works, and how to use it to solve the problem at hand.

Where does that need to happen? It doesn’t need to be a full-year class. I’d love to see a mandatory introductory class in high school that covered things like computer programming, electronics (this type of stuff), and other applied STEM topics (sort of a modern shop class). It doesn’t sound unreasonable, and it would be a great jumping-off point for those that do discover a passion for coding or any number of related areas.

The End

Extras: More on why not everyone should learn to code

This is the stuff that got cut out. The concern was that it made the argument against a little too strong and lengthy, but this is something I think about a lot so I've added it here I guess for my own selfish purposes.

As a Computer Science student in college, I had my brain very literally rewired. I can vividly remember walking around campus talking to myself, moving and twisting imaginary figures in front of me as I tried to make sense of finite state machines, …, and …. I’m not sure if I didn’t think the same way after that, or if I always thought a little bit differently, but I came out of that education with a very distinct perspective on how the world works.

There is no doubt in my mind that most programmers have a similar mental model for the world, and a similar approach to tackling projects. Part of it is that sense of empowerment I talked about earlier, but part of comes from seeing everything as a set of differently-sized algorithms with a well-defined problem and a testable, possibly inevitable solution. It comes out in the typical programmer’s style of humor, their language, their approach to meetings, etc. There are TV shows that target nerd culture, and there’s a rising trend in media for the nerd-hero that fits a very distinct persona.

All of these things concern me. I suppose it sounds elitist to say “I don’t want more people in the workforce just like me,” but that’s exactly how I feel. Is the programmer mindset the *right* way to tackle the problems of the future, or is it just *one* way? As a programmer myself I don’t think I’m the best person to be answering that question. One of the problems with a data-driven mindset is that you are inevitably drawn to answer the questions that can be effectively measured, not necessarily the questions that can lead to the right solution.

If we decide it’s worthwhile to train up an entire generation of learners to start thinking a certain way, what does that do to our population’s cognitive diversity? I don’t actually know, but I don’t think we should try it without at least thinking really hard about it first.

A Better YouTube App Using LTI

2013-04-29T10:27:00.000-07:00

K, so I promised to revisit the LTI workflow and how I think it's broken -- also how we fixed it in Canvas. Here's that revisit, as promised.

This is backwards, like LTI. Also like LTI, it's crafty in the middle.

In standard LTI there are two possible workflows:

1. Admin-installed, reusable launch. In this case someone high up installs an LTI app that teachers can use in their courses. The launch URL is generic, so when teachers add links to the app within their course material they then have to launch the app and go through an initial selection process.

This is backwards from what most people want to do. Nobody says, "hey, I want to add YouTube to my course! I'll figure out which video later…" It makes a lot more sense to pick the specific YouTube video you want and add *that* to your content.

Which brings us to…

2. Admin/teacher-installed, specific launch. The alternative is to specify when adding the resource what URL to launch. LTI allows for domain-level matching, so you can still have the admin install the app with a valid key and secret, and then teachers need to insert content-specific links that match this domain.

This is also an awkward workflow, albeit a little better. Essentially this is saying, "hey, I want to add a YouTube video to my course! I'll go over to YouTube, find the right video, copy the link and paste it here". Still not terribly elegant.

Which is why we've built some content extensions to LTI to support The Right Workflow. Using our extensions, the admin installs the app with a key and secret, and when the teacher goes to add a link to content from that app, a selection dialog appears that lets them browse/search content within that app, pick it, and have the linking part automatically taken care of. Now we can say "hey, I want to add a YouTube video to my course! I'll just open up this handy YouTube picker and find the video I want".

Here's how it works.

LTI launches come standard with a parameter I haven't mentioned before called launch_presentation_return_url. Basically when the LTI app has done doing its thing it can redirect the iframe to this URL and the LMS should know at that point that the app is done and do something about it (probably redirect to another page or close down the iframe).

All I've done is define some additional parameters which can be added to this return redirect that will tell the LMS that the user picked some content (we also send over a couple additional parameters to give the app some hints about what the user is expecting). The docs are here, but basically you look for selection_directive, and we have shortcuts for easily embedded links, images, lti launches and iframes, and for everything else it uses oembed.

As far as an implementation goes, we're talking about this:

# Handle POST requests to the endpoint "/lti_launch"
post "/lti_launch" do
  # do magical YouTube-y stuff  
  if params['selection_directive']
    # all the JavaScript needs to know is the redirect URL, it can take care of the rest
    render('selection_specific_page', params['launch_presentation_return_url'])
  else
    return "This app doesn't support standard LTI launches, only content selection launches"
  end
end

for the server. The JavaScript code changes as well to support the selection redirect:

// Remember the return_url so we know where to send the user once selection is complete
var returnUrl = decodeURIComponent(location.href.match(/return_url=([^&#]+)/)[1]);
if(!returnUrl) {
  returnUrl = "http://www.example.com";
  alert("No valid return URL provided! This tool will not work correctly!");
}
    
function returnVideo(video_id) {
  var url = "https://www.youtube.com/watch?v="  + video_id;
  returnUrl = returnUrl + (returnUrl.match(/\?/) ? "&" : "?") + "embed_type=url&title=Video&text=Video&url=" + encodeURIComponent(url);
  location.href = returnUrl;
}

Now it doesn't even require an LTI launch for the student to access the data (which seemed silly for YouTube anyway), just an LTI launch by the teacher at setup-time, then the tool returns a YouTube iframe and the LMS takes care of inserting it in the right place. We use this approach in Canvas to add buttons to the WYSIWYG editor, add options for homework submissions, and as an option in the module builder, but we'll be adding it more places in the future.

You may not have noticed, but we're now ignoring the LTI credentials like we did in the first example. It turns out that if your app only does content selection and doesn't support standard LTI, there's nothing that needs to be persisted to the database, and there's nothing to protect for an open app like a YouTube searcher. If you're still allowing standard LTI launches or if your content is protected, you should definitely still confirm the LTI signature using a preset key and secret.

Sinatra app course code available here.

LTI Authentication

2012-12-28T10:50:00.000-08:00

Last post I wrote a short tutorial on how to build an LTI app, with a YouTube search app as the example. The thing I left out of that example was signature validation. Validating the request's signature is how you can make sure that app launches are happening only from trusted sources, and how you can use LTI for automatically logging in app users. Authentication is important and if you're building a production-worthy LTI app you should definitely include this.

Graphology is the analysis of signatures and handwriting. It tells us that John Hancock had trouble sleeping and liked ponies.

LTI authentication is based on OAuth 1.0's signature validation. LTI is primarily a one-way identity assertion, where the learning platform tells the app details about the current user's identity and context. The learning platform and the app are responsible to come up with a consumer key and shared secret out-of-band (more on that in a minute). The attributes come across as form POST parameters, and the signature is sent across as an additional parameter.

Side note: Wherever possible you should serve your app over https instead of http. Some learning platforms like Canvas render all pages over SSL and users will get security warnings when trying to launch non-SSL apps.

The signature is generated, as with OAuth 1.0, by sorting all the request parameters, adding the consumer key, a timestamp and a nonce, and hashing them together using the shared secret. There are either LTI or OAuth libraries for many common languages, so hopefully you don't have to write this code yourself, but if you do here's a handy page for checking your signature generation. In practice your code will look something like the following (read my last post if this doesn't look familiar):

# Handle POST requests to the endpoint "/lti_launch"
post "/lti_launch" do
  config = find_config(params['oauth_consumer_key'])
  if !config
    return "Invalid launch - no configuration found for that key"
  end
  provider = IMS::LTI::ToolProvider.new(config.key, config.secret, params)
  if !provider.valid_request?(request)
    return "Invalid launch - signature does not match"
  end
  
  # do magical YouTube-y stuff 
end

Side note: there are a few (optional) cases where the app may also pass messages back to the learning platform (grade passback, for example). In these cases the app will use the same signing process as the learning platform.

User data comes across as POST parameters. Some parameters are required, many are optional and can be configured within the learning platform. Here's a list of the expected parameters, though additional custom parameters can also be sent. If your app has its own login system you can use this data to match users up with their existing logins, or to auto-create a user account in your system matching the data provided (some tools ask new users to create a login on first launch before continuing, I encourage people to make that an optional step after-the-fact to make things easier on the end-user). Our YouTube app doesn't care about identity at all, so we can ignore identity for now.

The only trick left is generating a consumer key and shared secret, and sharing them between the app and the learning platform. In practice, the app typically generates the key and secret, and it's the end-user's responsibility to copy the key and secret from a page within the app and paste them into a form within the learning platform. On the learning platform–side the app will be configured by an institution admin, a department admin, or possibly an individual instructor, and the same key will be used to launch the app for any learners or instructors within that unit. Sometimes the key is the user's login or some known identifier, but often it's a large unique string just like the shared secret.

Example of key and secret being provided by the app.

Example of pasting the key and secret within the learning platform's app configuration tool.

Remember: the key is fine to share publicly, but the secret should be protected, since anyone who knows the secret (and key) can impersonate the learning platform to the app. If you're going to do something like hashing the key to generate the secret, it's a very good idea to add some randomness.

Shared secrets should be kept secret. They should be kept safe.

For our YouTube app we'll just add a small command-line script that can be used to generate a new key and secret by hand:

config = generate_config()
print "== New Configuration =="
print "consumer key:  " + config.key
print "shared secret: " + config.secret

The reason you need authentication for LTI should be clear, it's how the app can verify that users are coming from a trusted source into the app, and can be considered an alternative to a username and password–style login. Even for a simple YouTube app like our example, which completely ignores all user information, it's important because each app placement within the learning platform is going to end up persisting information to your datastore once a video is selected, and without signature validation it would be easy for a malicious party to launch and run your app millions of times and stuff your datastore with junk placements. There's a more elegant approach that gets around this issue using an extension to LTI that I built for Canvas, but I'll cover that in another post.

Sinatra app source code available here.

Building a YouTube LTI app

2012-12-08T16:04:00.000-08:00

If you didn't know, I'm a fan of LTI. What is LTI? It's a cross-platform standard in edtech for what essentially amounts to Facebook apps for learning. Like Bejeweled Blitz running within Facebook, you now have Quizlet flashcards running with a course web site. It's pretty slick, and it makes it a lot easier to build apps that work in different learning platforms.

LTI was originally called BLTI, which always made me hungry.

Anyway. I thought I'd start sharing some examples of LTI apps and how they could be built. I'll start with an app to embed YouTube videos within course content. The server code is ruby-esque pseudocode which hopefully is grok-able. I've included an actual ruby app at the end as well for reference.

For this example I'll use the standard LTI workflow (Canvas has what I think is a cleaner workflow, but it's not officially supported right now. I'll cover that in another post). With LTI, the teacher or administrator sets up an LTI app. They specify a launch URL, a consumer key and a shared secret. Then when anyone clicks a link to access the app, it will be loaded in an iframe within the platform. In our case, the teacher would add one or more YouTube App placeholders to their course content. Then the teacher would go to each of these placeholders and specify which YouTube video to associate with each placement. Students who launch the app after it is set up will just see the selected YouTube video.

App "launches" happen when a user accesses the app from its placement within the learning platform. A launch consists of a client-side form post with an iframe or new tab as the form target. A bunch of data gets sent as POST parameters, including an OAuth-style signature derived from the parameters, key and secret. For simplicity (and since we're just dealing with public videos and don't care if the user is actually authenticated) we're going to ignore signature verification this time around. In a production environment I'd add the check or someone could potentially stuff your database with garbage data.

# Handle POST requests to the endpoint "/lti_launch"
post "/lti_launch" do
  # do magical YouTube-y stuff
end

The only values we're going to worry about are resource_link_id and tool_consumer_instance_guid. The combination of these values should give us a globally unique identifier that we can use to remember this "launch". We'll call this the placement_id, and since any launch from the same placement will result in the same placement_id, we can use it to remember which video the teacher picked for this placement. If the teacher adds multiple YouTube App placeholders to their course, each placeholder will launch with a different resource_link_id (tool_consumer_instance_guid is an extra precaution in case platforms use the same link id) and result in a different placement_id.

# Handle POST requests to the endpoint "/lti_launch"
post "/lti_launch" do
  placement_id = params['resource_link_id'] + 
      params['tool_consumer_instance_guid']
  placement = find_placement(placement_id)
  if placement
    redirect_to "https://youtube.com/embed/"  + placement.video_id
  else
    # use a cookie-based session to remember placement permission
    session["can_set_" + placement_id] = true

    # let the user pick the video to use for this placement

    redirect_to ("/youtube_search.html?placement_id=" + placement_id)

  end
end

Now we need to build the YouTube video selection page. I like jQuery, and YouTube supports jsonp, so the querying part is actually pretty easy. For the sake of simplicity we're going to build an "I'm feeling lucky" YouTube searcher that just assumes the first result is the one you want.

<html>
  <body>
  <h1>YouTube Searcher</h1>
  <p>Search for a YouTube video below. The first result
  is what will be shown whenever anyone loads this app.
  </p>
  <form id="form">
    <input type="text" name="query" id="query"/>
    <button type="submit">I'm Feeling Lucky</button>
  </form>
  <script src="//ajax.googleapis.com/ajax/libs/jquery/1.8.3/jquery.min.js"></script>
  <script>
    // Remember the placement_id so we can persist one a video is found
    var placement_id = location.href.match(/placement_id=([^&#]+)/)[1];
    
    // AJAX call to remember the placement for future launches
    function rememberVideo(video_id) {
      $.ajax({
        url: "/set_video",
        type: 'POST',
        data: {
          placement_id: placement_id,
          video_id: video_id
        },
        success: function(data) {
          if(data.success) {
            alert("Video set! Redirecting now...");
            location.href = "https://www.youtube.com/embed/" + video_id;
          } else {
            alert("There was a problem setting the video.");
          }
        },
        dataType: 'json'
      });
    }
    
    // JSONP call to search for YouTube videos
    function findVideo(query) {
      // YouTube API endpoint.
      var url = "https://gdata.youtube.com/feeds/api/videos?v=2&q=";

      url = url + query + "&orderby=relevance&alt=json-in-script";

      $.ajax({
        url: url,
        success: function(data) {
          // Grad the *first* video and use that one.
          // If you wanted to list the videos instead this would be the place to
          // iterate through the results. The attribute names are... different, 
          // but you can find thumbnails, descriptions, durations, etc.
          var video_id = data.feed.entry[0].id['$t'].match(/\w+$/)[0];
          rememberVideo(video_id);
        },
        dataType: 'jsonp'
      });
    }
    
    // When the user submits the search form, trigger the JSONP lookup
    $("#form").submit(function(event) {
      event.preventDefault();
      findVideo($("#query").val());
    });
  </script>
  </body>
</html>

We also need a server-side piece to persist the placement_id-to-video mapping to the db.

# Handle POST requests to the endpoint "/set_video"
post "/set_video" do
  if session["can_set_" + params['placement_id']]
    create_placement(params['placement_id'], params['video_id'])
    return '{"success": true}'

  else

    return '{"success": false}'
  end
end

Now the first person to launch the YouTube app after it's been placed will see the search interface that will let them specify which video to show, and anyone who launches the app after that will get redirected to the selected video.

Sinatra app source code available here.

uninitialized constant Jammit::Routes

2010-08-14T21:17:00.000-07:00

This post is mostly just for me (because I know someday this is going to happen again and I'm going to search for this error string), but maybe somebody else will find it useful too. I just switched ruby environments and I couldn't run my rails project anymore, it failed with the error "uninitialized constant Jammit::Routes".

It routes.rb we've included the line "Jammit::Routes.draw(map)" for jammit routes, and that fails for some reason. Last time it took me forever to figure out why, but eventually I found that (for me, anyway) there was a problem with the closure-compiler-0.3.2 gem. It checks if you're on Windows and if so, it checks if you have ruby 1.9 installed or not. If you do it requires 'open3' and if you don't requires 'win32/open3'. I don't want to deal with all the mess of getting 'win32/open3' into our bundler bundle, and I don't actually need closure-compiler to work since I can't deploy from my box anyway, so I just changed the "lib/closure/popen.rb" file in the gem to not require 'win32/open3' and everything's happy again.

The Story of Instructure

2010-05-21T11:29:00.000-07:00

For the curious at heart, here's a little color around how I ended up co-founding an educational software company called Instructure.

In 2008 I was a grad student at Brigham Young University, just finishing up my Master's in Human-Computer Interaction. One of my last classes was a Software Business class taught through the C.S. department with a visiting professor, and the idea of the class was to pretend like you were doing a startup, do all the market research, put together a plan and "pitch" at the end of the semester. Devlin Daley and myself ended up in a group (we'd taken usability classes together before) and sort of decided not to pretend. Devlin had always been the entrepreneurial type, and I'll confess it didn't take much for me to catch the bug, either. We didn't have to look far for a legitimate opportunity.

BYU used Blackboard as their LMS, and we were so frustrated with the product both as students and as TA's, that we decided to poke around that market a little more. We were baffled when we failed to find anybody that we considered pushing the boundaries of education. Usually in a healthy market you have some one product that's really driving innovation, but in the LMS market we didn't feel like anyone was doing that. Plus, education was something I could really get excited about. I realized I already had tons of ideas for how online learning could be improved, and I started itching to implement them.

So we dug deeper, looked at the size of the market, the way contracts were signed, why innovation seemed to have stagnated, etc. and realized there was a legitimate opportunity for someone to step in and disrupt things.

So we did. We started jotting down what we thought was busted, how we thought the system should look -- and then we did the very hard thing that I think a lot more startups should do. Instead of starting to write code, which both of us loved doing, we took all our ideas and built them into a mocked-up version of the product in PowerPoint. Then we started calling schools. We would cold-call the CTO, CIO or the head of Instructional Design and tell them we were a new company who wanted to show our thoughts on the future of the LMS and get their feedback as well.

We had a very favorable response, and met with eighteen universities over the summer of 2008 including UCLA, Berkeley, UNLV, UVU, Westminster and USC. Everyone loved what we were doing and gave us great feedback. After each school we'd write down a ton of notes, re-work the PowerPoint and go at it again. We learned a TON and ended up with a very compelling product.

After that we found an angel investor who funded us enough to start development and, well, haven't stopped for a breath since then. We now have a team of eight, a few contracts under our belt, and a bunch more on the way. I'm having all sorts of fun integrating with big-name web tools, building new approaches to education problems, and designing simple but effective interactions for teachers and students. It's been a blast, and I don't see that changing in the near future.

Good times :-).

Google's Crowdsourcing the Training Set

2009-11-19T16:30:00.000-08:00

In all the Google news today, one piece that hasn't gotten much attention is the YouTube speech recognition tool. There's a hidden bit of genius in Google's implementation of this easy captioning tool for YouTube videos (which, by the way, will rock for educational accessibility purposes). Right now it's only turned on for a few trusted sites, but Google is looking to beef up its speech recognition classifier even more by gathering auto tracks from all its YouTube videos. This is actually a much richer dataset than the Goog-411 could provide (or even Google Voice voicemails, really).

That's not the genius part, though. The real genius is Google's "automatic caption timing", where you type in the textual version of your video and YouTube will automatically chunk it up into caption blocks based on what it can decipher from the video. Adding captions is now a cakewalk, so why wouldn't you do it?

Let me say that again, another way. Google has found a way to motivate people to, of their own free will, send in textual versions of their audio tracks. An accurate textual representation of the audio a machine learning algorithm is going to try to classify as, well, text. They just won themselves a huge, presumably fairly accurate, training set for speech-to-text translation, donated by some not-insignificant subset of YouTube's giant population who will want captions on their videos.

Google Voice voicemails may actually spit out something legible in the near future.

Ruby ERB and output_buffer

2009-07-28T11:44:00.000-07:00

I just ran into this little frustration and thought others might, too. I have some template files that I need evaluated, and recently I wanted to add in some new functionality similar to the content_for method used in Rails templates, but in my own special way. I don't want them just rendered like Rails controllers because I don't need all that overhead for what are really some pretty small template files.

The funny thing about Rails is that if you try to go off the beaten path, everyone will ask why you're bothering to wander off, and shouldn't you just stay where it's comfortable? Probably 95% of the time they're right (and 3% of the rest of the time you realize six months later that they were probably right), but there are cases where it's useful to do something a little different (I think).

Anyway, most of the posts I saw on using ERB talked about its scary voodoo magic internals that aren't worth delving into. So I didn't. I had what I thought was a pretty basic problem, as follows:

I defined a method my_method that I wanted to call from within the templates which, for starters, I just wanted to assign to an instance variable. So I wrote:

def my_method(name, &block)
 res = yield
 self.instance_variable_set("@value_#{name}".to_sym, res.to_s.strip)
end

def parse!(template)
 b = binding
 self.body = ERB.new(template, 0, "%<>").result(b)
 self.value_a = @value_a
 self.body
end

Looked good to me, pretty simple. But if I passed in the template:

Start Template
 <% my_method :a do %>
 value for a
 <% end %>
End Template

then I'd get:

== value for self.body ==
Start Template
value for a
End Template

== value for self.value_a ==
Start Template
value for a

This is what is generally considered bad, and not correct. I messed around with things for a while and got nowhere. Then I dug into how Rails was evaluating templates and its content_for method. ActionView::Base has an accessor called output_buffer being used by CaptureHelper (where content_for is defined) in a way I couldn't understand at first.

When you call content_for, part of its process is to store the value of output_buffer as old_output_buffer, then call its yield and finally re-set output_buffer to its original value. Weird, but at least it was a start. So I blindly added attr_accessor :output_buffer to my class and hoped for the best.

No love. I dug around a little more and found the rest of the trick. One of the arguments for ERB.new is the name of the local variable to use to store the string buffer used in the ERB evaluation. I'd never used that before because I didn't care, but if I set that value to "@output_buffer" then everything works magically.

So the new code is:

def my_method(name, &block)
 old_buffer, @output_buffer = @output_buffer, ''
 res = yield
 self.instance_variable_set("@value_#{name}".to_sym, res.to_s.strip)
 @output_buffer = old_buffer
end

def parse!(template)
 b = binding
 self.body = ERB.new(template, 0, "%<>", "@output_buffer").result(b)
 self.value_a = @value_a
 self.body
end

And suddenly everything works like a champ. Happy sigh.

Google Wave Limitations

2009-06-04T14:36:00.000-07:00

Don't get me wrong. I dig(g?) the Wave. I think it's got some great potential to really disrupt things in a much-needed way. But I'm still skeptical. I've tried to figure out what I can about Wave given that I don't even have a sandbox account yet, and now I want to share my thoughts. So here's what I think Wave doesn't do:

Wave Will Replace Blogs
If you're interested in Wave, you've probably already seen the Wave video. One of the examples in the video shows embedding waves as blog posts, so you get real-time comments from visitors. The thing they gloss over in the demo is that, as Wave stands right now, anyone who joins that wave has permissions to edit anything -- the original blog post, or anyone else's comments. It's like making your blog a public wiki instead of a set of authored posts. In the extreme case you've got almighty blog spam potential, but even in the realistic case there's potential for editing other people's comments.

You could technically write a "read-only-enforcy" robot that keeps reverting segments of the wave if anyone else edits them, but, well, that smells funny. I expect that someday Wave will add wavelets with limited editability, but that doesn't solve everything.

One issue that will be addressed as this all evolves is how much are users expected to monitor the development of waves they're subscribed to? Is it as important as responding to a new email? How easy is it to recognize and dismiss minor edits? If I'm still part of a wave is it assumed I endorse it? There's some haziness that the system will have to define for itself as it develops.

Wave Will Replace Facebook
Or Twitter, for that matter. This isn't going to happen, because of one simple but significant feature in Wave: the "unread" feature. Facebook's stream and Twitter's feeds are very much about real-time. You don't comment on old tweets, and Facebook doesn't really make it easy to "catch-up" on old items. There's no indication of what you might have missed between visits, and that changes the medium. Things like Email, Feed Readers -- or Wave, for that matter, make sure to highlight any items that have seen activity. I think that implies a sense of importance to each message, and for me anyway, I feel weird clicking any kind of "clear all" button. What did I just dismiss? Whose question did I just unintentionally ignore? In Wave's case, was the latest edit a change in spelling or an important question that needs addressing? I don't feel that urgency at all with Twitter of Facebook. Interesting how taking away that "unread" feature completely changes the nature of the service.

Anyway, I think that because of the way Wave is organized and its coming from an email background, it won't do well replacing services that are more real-time, if only because they actually mark all those changes and encourage you to review them.

Wave Will Replace the LMS
I won't talk much about this, because I think it's been hit already. Michael Feldstein made some good points (especially the part about how it's silly to put much stock in the death-tolls of the LMS from people who aren't even using them anymore). Dr. Chuck adds some other points about authorization and the inherent de-normalization of waves.

For my part I'll just say I think you could write an LMS on top of Wave, but there'd be some serious robottage going on behind the scenes to make everything play nice, and I think the decentralized nature of Waves make it too disjointed on its own. That said, I think a future-looking LMS could seriously benefit from harnessing waves for things like group projects, peer reviews, or maybe even assessment. That's what I'll be working on -- if Google ever gives me my sandbox account, that is.

jQuery UI :tabbable -- what the?

2009-05-12T15:09:00.000-07:00

This week I've been working on adding some basic accessibility tweaks to our site. Instead of starting from scratch, I've been peeking at the jQuery UI code, because I know those guys have been working with the ARIA blokes to "accessibleize" jQuery UI. I think that's greate for everybody, by the way, for specifically this reason. Instead of having just the specs alone, I can study the standards and also look at how some real-world coders have implemented those standards.

Anyway, the trick I wanted to duplicate was the dialog's auto-focus trick. When a jQuery UI dialog pops up it automatically shifts tab focus to the first element in the dialog that can receive focus, which is nice for accessibility because then even a non-visual user's attention is brought to the dialog. I could have thrown together a quick selector that checks for the first anchor, input element or whatever, but like I said, I wanted to see what they'd done.

I snuck into the source, and noticed they're using a selector filter called ":tabbable" to select the elements that, I assumed, was capable of being tabbed to. A quick Google search and I found nothing -- hence this post.

Apparently jQuery UI is adding two very useful (for accessibility purposes, anyway) selector filters to the jQuery selector engine, ":focusable" and ":tabbable". Here's the code:

//Additional selectors
$.extend($.expr[':'], {
  data: function(elem, i, match) {
    return !!$.data(elem, match[3]);
  },

  focusable: function(element) {
    var nodeName = element.nodeName.toLowerCase(),
      tabIndex = $.attr(element, 'tabindex');
    return (/input|select|textarea|button|object/.test(nodeName)
      ? !element.disabled
      : 'a' == nodeName || 'area' == nodeName
        ? element.href || !isNaN(tabIndex)
        : !isNaN(tabIndex))
      // the element and all of its ancestors must be visible
      // the browser may report that the area is hidden
      && !$(element)['area' == nodeName ? 'parents' : 'closest'](':hidden').length;
  },

  tabbable: function(element) {
    var tabIndex = $.attr(element, 'tabindex');
    return (isNaN(tabIndex) || tabIndex >= 0) && $(element).is(':focusable');
  }
});

:focusable selects the list of elements that are inherently focusable, i.e. anchor tags, input elements, form elements that aren't disabled, or elements that have a defined "tabindex" attribute. :tabbable is a subset of this list, only including those :focusable elements that have tabindex >= 0. You can set an element to have tabindex="-1" and it will be focusable, but won't show up anywhere in the page's tab order, hence it's not tabbable.

Anyway, cool stuff. If you use this you'll probably want to check ":visible" as well.

Are rounded corners THAT hard to implement?

2009-01-27T17:00:00.001-08:00

So Microsoft has just announced their first (and probably only) release candidate of Internet Explorer 8. For those in the not-know, release candidates fit somewhere between betas and final releases, most often leaning closer to the final release. It's a last chance to make sure there's nothing seriously wrong before actually releasing the product.

IE8's supposed to add a bunch of new features, while not changing the actual interface much at all. If you look at the list of new features for IE8, it's pretty much a smattering of a bunch of little cool things -- no real direction, just a bunch of little cool things. They have web snippets, some new accessibility events, a safe JSON parser, etc. etc. I'm fine with all that, I'd actually really love for every browser to get a JSON parser and improved accessibility. My beef is what they don't have.

Rounded corners.

Most other major browsers (Firefox, Safari, Chrome) have support for those friendly little curves on the edges of your layout boxes. Microsoft, however, has said they're basically not expanding their CSS support at all, just sticking with the CSS 2.1 that they already complies with. I guess they did say it's "high on the wish list" and to expect it in the next version, but my complaint is, how hard is it really to implement rounded corners? I mean, they could seriously have had one intern working on it for a few months and he probably could have managed rounded corners in CSS.

What's the big deal, you may ask. Who cares about rounded corners anyway? Well. If you were to ask a web designer, what's the most-awkwardly-hacked-on layout feature in today's web pages, they'd almost definitely say it's rounded corners. There are so many "workarounds" for the rounded corner problem it's not even funny. Most of them use tables and CSS -- insert cringe here -- to get around the problem, but that's like using toothpaste to fill the holes in your walls. It technically works, but it's really not the right tool for the job. Not to mention how much it can bork with accessibility and semantic meaning.

Anyway, everyone knows that anywhere from 30-90% of a web site's users are on IE, so until Microsoft implements rounded corners we're stuck in nastyland. I'm a little frustrated with Microsoft over this one, actually. They had the opportunity to save thousands of web sites from code nastification currently happening in the name of aesthetics, and they just didn't bother. I seriously doubt it would have taken THAT much effort, and even an unfinished implementation (say, we only do up to 10 pixel rounding, for example) would have been good enough for me. Honestly, you shouldn't have to make a table or write twenty lines of CSS (or both) just to get some non-square navigation tabs at the top of your page.

jQuery 1.3 delegation

2009-01-02T10:01:00.000-08:00

This post will most likely be useful only to me, but I'm extremely excited about the new version of jQuery that's coming out, and I wanted to put down some of its new features before I forget, and to make sure I understand them completely. If you aren't familiar with javascript event delegation, this probably won't mean a lot to you (here's a quick tutorial).

I went poking around in the jQuery revisions because I haven't found hardly any details on what exactly is changing with the new version (other than speedups and such, but those don't excited me nearly as much as other people -- probably because I tend to write my code for the speed of "right now" instead of for a future version, so if something is changing from slow to fast, I'm probably not using it anyway). There's some good stuff going into this new version.

And more than just Sizzle, which I'm not going to spend any time on.

So I've been using the jQuery event delegation plugin on my most recent project, and it works nicely, but there are a few problems. First is that your selectors have to match on the target of the event, not an ancestor. So if I have a list of "div.child"s inside of a "div.parent", I call:

$("div.parent").delegate('click', 'div.child', function(e) { });

to watch for clicks on any of the div.child's. The problem here is that if I have an image tag inside of the div.child, and the user clicks on the image instead of the whitespace in the div, then the delegation plugin won't trigger the event. I actually did a quick rewrite of the plugin on my own to check against parents as well, changing:


return this.bind(type, function(event) {
   var target = $(event.target);
   if (target.is(delegate)) {
       return handler.apply(target, arguments);
   }
});

to:


return this.bind(type, function(event) {
   var target = $(event.target);
   if (target.is(delegate)) {
       return handler.apply(target, arguments);
   }
   var $container = $(this);
   var $parent_target = null;
   target.parents().each(function() {
       if($(this).is(delegate)) {
           $parent_target = $(this);
           return false;
       }
       if($(this)[0] == $container[0]) {
           return false;
       }
   });
   if($parent_target) {
       return handler.apply($parent_target, arguments);
   }
});

Problem solved -- for me, anyway. But the better news is that jQuery's new delegation mechanism takes care of this for you! It's got a .closest method that matches on the element or its closest matching ancestor. Pretty vital, if you ask me, for any actually usable delegation system. In that case you could replace my code with:


return this.bind(type, function(event) {
   var closest = $(event.target).closest(delegate);
   if (closest.length > 0) {
       return handler.apply(closest, arguments);
   }
});

So that's cool, and it contented me for a while, but then I ran into another problem: bubbling. Normal user events bubble just fine, but jQuery also lets you trigger artificial events using .click, .submit, or .trigger(type) methods -- these don't bubble. At least, they didn't used to. Resig fixed that as well in the new version, for which I am extremely grateful. Hours of conniving workarounds were wasted, but I can handle that.

As it turns out, I may still be using the delegation plugin, as enhanced by the new changes in jQuery 1.3. I wasn't entirely sure how jQuery's new .live and .die functions behaved, so I didn't know how applicable they'd be, but John Resig himself left a nice comment on Ajaxian's post:

We’re not using the name ‘delegate’ because it isn’t normal event delegation (not to mention that there are already a number of delegate plugins using that name). Typically when someone wants to do full delegation they also want to specify the root element - e.g.: $(”#someroot”).delegate(”div”, “click”, someFn); We wanted to provide something that was much simpler than normal delegation but still leave room for people to write their own full delegation code/plugins.

What he means about it not being "normal event delegation" is that jQuery's .live and .die methods don't let you specify who you're delegating to. It's always a the document (root) level. So if I call:

$("div.child").live('click', function(e) { });

(which, by the way, would be the appropriate way to listen for clicks on any div.child's in the document) then it always bubbles all the way up to the document. What if you just want to catch clicks on div.child's that are inside a "div.parent"? Not possible with .live and .die. That's ok, though, because I'm willing to bet most people won't care, and if nothing else this addition offers a great starting point for those new to event delegation. This is a great piece of functionality, and the fact that it handles both inner-element events and triggered-event bubbling makes me a very happy programmer.

As a side note, you can kill all delegated functions of a given type with:

$("div.child").die('click');

or just a specific function with:

$(".div.child").die('click', function_to_stop_calling);

Resig is calling this a livequery/event delegation hybrid, although it's really more delegation than anything. I think the reasoning there is that more people know of and use livequery than the delegation plugins, so it's more familiar, and in fact the syntax is more like livequery than delegation -- although honestly there's not that much difference between the two. Either way, it's a great addition to a great library, and a useful inclusion of a great new feature in web programming.

jQuery events: setting a property that has only a getter

2008-12-15T10:26:00.000-08:00

I ran into a new problem in jQuery the other day, and I couldn't find a good solution for it. Hence, a new post in the hopes of helping out the next individual.

In case you didn't know, I'm working on a modern learning management system for Instructure. Good stuff, but I can't spill too many beans yet. Sorry.

Anyway, as part of that I need a good javascript WYSIWYG editor (love to do just WYSIWYM, but I don't think it's general enough for all faculty) and I've settled on TinyMCE for the time being -- mostly because they've actually got some accessibility functionality baked in. I've written a jQuery wrapper around it for all the features I need to get at (because let's face it, TinyMCE's API is NOT intuitive, and I'd prefer to touch it as little as possible), but I also need to capture key events so I can treat the "escape" key like a cancel click. Sadly, TinyMCE uses iframes and eats up javascript events before you can get to them.

No problem, TinyMCE's API lets you catch key and mouse events and do what you will with them. To make things simple I'm listening for key events on all form text elements, so I just want to take TinyMCE's key event and pretend like it got called on the textarea that TinyMCE replaced. jQuery has a .trigger method that lets you call events as if they happened on the selection, so I just pass the event TinyMCE gives me into jQuery.

Bzzzt! Firefox throws an error, "setting a property that has only a getter". Blast. I futz around with it for a bit, can't solve it, so I finally muster the courage to dive into jQuery code and figure out what the problem is. The error's being thrown because the jQuery trigger method asks you to specify the event type ("keydown", "mouseup", etc.) and then sets the event.type property to make sure it's the right type. Problem is, javascript native events don't let you SET the event type, only get it. Hence the error.

Double-blast. Okay, so now what? I dig a little deeper (like I said before, no good documentation that I could find on this) to see what jQuery's doing with events. When jQuery catches an event, it wraps it in a jQuery event object to make things happy (and you can set the event.type property on this wrapped object to your heart's content). So if I just wrap the event, problem solved. I realized I should probably do this anyway, because while the only error I hit was setting an unsettable property, there's probably other kinks I don't want to deal with.

So how do you wrap events? Turns out it's pretty easy. Instead of:

if(e.type == 'keydown') {
$("selection").trigger(e.type, e);
}

You use:

if(e.type == 'keydown') {
$("selection").trigger(e.type, $.event.fix(e));
}

That's if you have "$" as an alias for jQuery. Otherwise you'd call jQuery.event.fix(e) to get the wrapped object.

Also, I'm actually using triggerHandler instead of trigger. Trigger just fires the event, while triggerHandler triggers everything except the default behavior (that way I'm not initiating a keydown on the textarea and inadvertently adding text).

Problem solved!

Universities and OpenID

2008-11-14T18:48:00.000-08:00

Today's post by Scott Leslie got me thinking about universities and their identity systems. The issue Scott brought up was getting all these web services to play nice with the university's system. Teachers are getting tired of the lack of functionality that's available from their LMS (I have some thoughts on that, too), so they're turning to services elsewhere that provide better features, better interaction and more flexibility. I can't say as I blame them. I heard that at a recent web usability conference the presenter referred to Blackboard as, essentially, the anti-interface. So sure, use the tools that are actually useful, and education actually benefits.

That's great and all, but it leaves the students in a bit of a lurch. That smattering of web services aren't integrated. Like at all. Suddenly a student needs accounts with Blogger, WordPress, the local wiki, Google Docs, etc. etc. etc. And then they have to link up with everyone else to make things work. Day one of class turns into a mass sign-up, sync-up session. That's not a great place to be. Scott put it aptly when he said “those nasty web 2.0 tools won’t single sign-on to my campus login system, so what are we to do?”

Well! OpenID is a pretty cool idea that just might help out. I'm not going to go into specifics, because I'd probably embarass myself if I did, but the basic jist of OpenID is having a common means of authenticating users across multiple sites. In other words, accomplishing a single sign-on, single identity for the whole web. That way when you go to OpenID-enabled site X, instead of having to create a new username and password, you say "dude, I totally already have an account at this OpenID site. I'll just use that account." Then site X says, "oh, my bad. Lemme just go check and make sure," and then "hey OpenID site, you ever heard of this dude?" Your OpenID site finishes up with a "heck yeah" and you're signed in. Once you've signed in once with your OpenID site, you're good to go for that browser session. You can log in at sites X, Y and Z without registering or even putting in your password. Cool beans.

The best news? Sites are actually starting to accept OpenID. You can use Scribd, WordPress, Plaxo, Blogger, Disqus, etc. with a single identifier. Right now.

So here's my thought: Why not make your university an OpenID provider? Schools aren't going to pass their login off to someone else (any time soon, anyway), but I can't think of a reason for them not to share that login at other sites. Let students clump all their school-related accounts into one It would be a great thing for these "edupunk" folks, if nothing else. Besides, I really like the idea of an OpenID account being tied to something more concrete than just a web site somewhere. It... feels... very natural to cluster related accounts around a single global id.

How to use django filters in python code

2008-11-05T16:27:00.000-08:00

Okay, so django is pretty nice. It's a great web framework with a very straightforward templating engine, and I'm sad to be leaving it for Rails-land for the time being. One of the nice things about django is the set of included template tags and variable filters. You can define blocks of code that can then be overwritten by templates that inherit the given template, and you can very easily format your data in view-specific ways. The variable filters in particular come in handy. Very often.

In fact, there are times when it would be nice to be able to use those filters outside of django template code. In the true spirit of DRY, I don't want to recreate django's date filter, file size formatter, slugify tool, etc.

So how do you use django filters in plain old python? Turns out it's pretty easy:


def process_data():
 from django.template import defaultfilters
 page_title = "How to use django filters in python code"
 page_slug = defaultfilters.slugify(page_title)
 # page_slug == "how-to-use-django-filters-in-python-code"

 file_size = 123456789
 file_size_display = defaultfilters.filesizeformat(file_size)
 # file_size_display == "117.7 MB"

And there you have it. Good stuff. If you don't want to keep typing "defaultfilters" you can alias it, of course.


from django.template import defaultfilters as filters
page_slug = filters.slugify(page_title)

You can call any filter from the built-in list this way. The first argument is the value upon which to perform the filter, the second argument is (optionally) the string argument used as additional information for some formats. So


{{ value|date:"D d M Y" }}

becomes


defaultfilters.date(value, "D d M Y")

Pretty straightforward stuff. Obviously this only works for the default filters. If you've added any more filters, you should know already where they're located and how to call them.

Fickle Finances and Software Startups

2008-10-18T10:45:00.000-07:00

Too true, too true. I ran into Paul Graham's post on startups in a bad economy via Phil Windley's blog, and I very much agree with what was said, there:

"The economic situation is apparently so grim that some experts fear we may be in for a stretch as bad as the mid seventies.

"When Microsoft and Apple were founded.

"Someone who thinks 'I better not start a startup now, because the economy is so bad' is making the same mistake as the people who thought during the Bubble 'all I have to do is start a startup, and I'll be rich.'"

On the nose, I'd say! We've been batting this idea around as we talk about eLearning technology. The fact of the matter is, no matter how bad the economy gets, schools are still going to use an LMS because, well, they need it. They can't ask their faculty to go back to paper grading, and they can't suddenly drop their distance learning programs. In some ways it makes our product even more viable because it's a better return on investment. You don't have to keep paying on top for all the plugins and features that make the product actually viable. But in general, web services aren't going to be the first thing to go in a budget cut.

The same vein goes for a lot of web technology. Companies still need software to manage their customers and to mine their data, even with a bad economy. People aren't going to stop using email. They're not going to stop using Facebook or watching movies on Hulu or Netflix online or whatever. They actually might do it more because it's cheaper than going out. I think it's fair to say that in general it would take quite a financial sucker-punch for people to cancel their Internet service altogether. They may even be looking for new opportunities and experiences online. Now, people may be reluctant to add more monthly fees, so in that sense maybe there's an issue. But at the same time, if you really are doing a startup right now then you're probably offering a free beta for the next little while anyway. And products for companies, all you need to do is hit a meaningful ROI and you're home free.

Phil summarized the sentiment quite well, I thought:

"Actually, he doesn't necessarily think starting in bad times is better than good times, just that there's nothing special about good times when it comes to starting high-tech businesses"

Phil and Paul both get the idea pretty clearly. The technology sector is less sensitive to (or maybe just slower at reacting to) financial upheavals. In the end it still boils down to having a good idea and doing a good job putting it forward.

"If we've learned one thing from funding so many startups, it's that they succeed or fail based on the qualities of the founders. The economy has some effect, certainly, but as a predictor of success it's rounding error compared to the founders.

"If you're worried about threats to the survival of your company, don't look for them in the news. Look in the mirror... If you're the right sort of person, you'll win even in a bad economy. And if you're not, a good economy won't save you."

The Mashable One-Stop Shop

2008-08-25T13:55:00.000-07:00

So... interesting meeting yesterday, it really got me thinking. We've been on the road this week talking to a bunch of schools, and one meeting in particular sparked the pontifical juices. It was a rough discussion. Funny how rejection always makes you think harder than success.

See, there's a lot of talk right now about student-centered learning, about putting the student in the driver's seat of their education. The LMS, instead of just dispersing static information, needs to be a springboard to new resources and innovative learning techniques. Great rhetoric, although I find it interesting that we're talking about totally transforming the nature of the LMS when I've yet to see even the most successful LMS's take advantage of basic things like AJAX requests and in-page edits. But that's another story. As is the issue of moderate vs. extreme constructivism. Anyway.

Web 2.0 services keep showing up, and educators are finally starting to take note (well, some of them anyway) of their potential for learning. There's a natural push from the innovators to leverage these new technologies in education, and that means including them in the LMS somehow. Maybe even replacing an established feature of the LMS. That's a big change from how things have worked in the past. Traditional LMS's are a one-stop shop. They have their version of a standard list of features, and that's about it. You can add new functionality with plugins, but replacing say, the discussion board, could only happen by throwing a new link somewhere else in the course structure -- confusing faculty and students in the process. That leaves you stuck with whatever the LMS offers, there's no chance to search for best of breed on your standard feature set.

Solution? The impression I got from yesterday's meeting is that you make the LMS into a mash-up. It becomes a skeleton that doesn't offer the features itself, it links to other services that offer the features. Let the teachers decide for themselves. Taken to the extreme, when the teacher first sets up the course they pick from a drop-down list of discussion boards, group messaging systems, gradebooks, file repositories, content management systems, etc. The LMS just keeps student data secure and brings all the resources into one place. That's really just one step up from what the innovators are doing right now -- WordPress for their announcements, MediaWiki for their assignments, and Google Groups for their discussions. All that plus a single point of entry.

While I do see the utility of heading in that direction (and also the challenge of integrating with all those services), I think there's a bigger jump involved than a lot of instructional techs are acknowledging. It's funny, really, because I've described the future of the LMS in almost exactly the same words that I heard yesterday, although I had a slightly different image in mind. I just don't see the LMS becoming quite that... fleshless. I'm not sure that's the right functionality to offer to or require of the faculty.

It's totally awesome to say the LMS should let faculty use WordPress or Blogger or whatever for their announcements, MediaWiki or DocuWiki or whatever for course content, Google Groups or Disqus or whatever for communication, MicroGrade Online or Google Spreadsheets or whatever for their gradebook, YouTube or TeacherTube or iTunesU for their video, etc. But most teachers aren't savvy enough to have a preference. I'd even go so far as to say they don't want to have to have a preference. They don't want to (or don't have time to) go set up accounts at different sites and manage student permissions for every course. They want to have one option for each feature, they want it to be easy and seamless, and they even want it to look the same as everything else so they don't get confused. And that's actually not a bad thing. Most people just want a single tool that does its job without much fuss or fiddle. It's only the rare power user that wants to tinker. You do have to give the power users freedom to innovate, though, or you'll get left in the dust by the competition.

That's why I think an LMS needs to play both fields: they need to offer flexible options for the power users, but also either integrate deeply with or include their own version of all the major components. Then you can throw in some settings that cover most standard alternatives. For example, students could use the integrated blog, but the LMS could also allow Blogger and WordPress URLs instead. A teacher could export their course calendar to Google Calendar -- or maybe the teacher could even import their Google Calendar into the LMS instead. Or the teacher could just use the standard calendar if they like. Likewise a teacher could use the included wiki and file system to build up a repository of learning objects, or point to some external content management system that housed their objects. It shouldn't matter to the LMS which approach they take. By keeping these sort of approaches in mind, I definitely think it's possible to create a one-stop shop that's also mashable. It lets the evolution happen more gradually (and realistically) while still letting the innovators keep pushing the front edge.

The real trick would be in finding a way to integrate with new services as they appear instead of having to wait for the LMS vendor to catch up and recognize the service themselves. Educational software, though important, doesn't have enough of a commanding presence to motivate new services to integrate with it, so the responsibility will probably stay with the LMS to do the integrating. Again, that's another story.