Dear Educational Publisher/Vendor: We Care About Our Data, Even When You Don’t Seem To

I’ve been in several conversations lately where publishers and vendors have taken an awful casual approach to identity and student data management.  The front end of their new “digital textbook” looks great.  HTML5 and everything.  Plays nicely with an iPad, or a Chromebook or any other screen on any other device.  As they should.  I get excited.  

And then I get a look at the user database or authentication tools they provide for managing accounts and student data for the product.  And again and again and again, I get a little sick to my stomach.  No way to authenticate against our identity databases.  No way to actively manage and/or sync data from our databases to theirs.  Duplicate accounts.  Terrible data management.  Shockingly disappointing attention to issues of privacy or student ownership of the work they do.  

The worst part isn’t that they don’t get it – educational software and publishers are often a little behind cutting edge when it comes to enterprise level technology.  I get it.  Many school districts are behind on this, too.  It’s when we raise questions and express our concern that I get upset.  Because we get one of two types of responses:

1.  This is “the first time anyone’s ever asked these questions,” we’re told.  As if we should be excited that we ask new questions that no one else is asking.  That’s scary.  

2.  “Well, we understand your concerns, but other school districts don’t want these things, and we don’t feel the need to develop them,” I hear.   That’s worse.  

I can’t fathom why publishers and vendors are so willing to play fast and loose with precious data – student personal info, their schoolwork and creations, etc.  But it’s not okay.  And worst thing is when, in spite of our concerns, we hear things like this:

“Well, the front end is so beautiful and high quality.  Would you really allow your concerns over this other stuff to prevent you from giving these amazing resources to your teachers and students to use?”

My answer to that question is always going to be yes.  A pretty thing on the other side of a glass wall of awfulness will keep me walking right on through the universe of options. I’ll pick the resource that’s not as good if I know I can keep my students safe and our data reasonable to manage and protect.  The “it’s only one more account” for a student to learn or use argument is no good when there’re only five or ten or more accounts for folks to actually have to learn in order to do their jobs.  

Let’s do better.  Let’s demand better.  

29 thoughts on “Dear Educational Publisher/Vendor: We Care About Our Data, Even When You Don’t Seem To

  1. Hello, Bud,

    The cynic in me thinks that they do know, and aren’t doing anything about it for (at least) two reasons:

    1. Your data in their app means that they have your data.
    2. They’ve done the math, and the money from lost sales is less than the money required to do it right.

    1. Ugh. Forgot to add the other element here.

      The data and content trap is another form of vendor lock in. Because there is an up-front cost to get started with a system, it also creates a disincentive to change to a different vendors.

  2. There’s no excuse for this (being clueless or cavalier) on the part of a potential vendor. But I’m curious if you’re seeing these more among startups than established education technology companies. I’m constantly encountering startups that are so focused on pretty that they have neglected, or downplay, the importance of the “boring” plumbing. (That said, even established companies can have a blind spot in this area.)

  3. Not sure why my pingback didn’t register here, but I wrote a quick reaction to the issue you raise.

    http://drapestak.es/vendor-trust-competence-edtech-data/

    I think the non-stop vendor calls and emails finally got to me.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.