Archive

Archive for January, 2012

SOPA, the copyright anarchists, and the future of content

January 18th, 2012

If I steal a brick from you, you no longer have the brick. But if I make a digital copy of a song on your hard drive, we both have it.

Some people think that makes all the difference, and that copying digital information is an entirely different thing from taking a tangible thing. I don’t agree, but I realize I am biased because my career has been based on the production and sale of copyrighted material. Allowing people to download it for free completely ruins the business.

SOPA is an attempt to rein in some of this copyright infringement because, as we all know, people in the information business rely on copyright protection.

I don’t know if SOPA will pass, and even if it does, I don’t know if it will solve the problem. I tend to doubt it. It may curb it somewhat, but it won’t solve it. People will find new ways to “share” copyrighted information.

If you ask the anti-SOPA crowd how people who rely on the sale of content are supposed to survive in that kind of environment, they say we have to come up with new business models.

So, what kind of a business model can work in a world where you can’t sell your content because everybody downloads it for free?

Well … you could put advertising right in the middle of your content. I don’t mean a little space add over on the side, or an ad on page 4 of a 6-page report. Those things can be removed. I mean that the advertising is built into the content in such a way that it’s inseparable.

Here’s a ridiculous example that occurred to me this morning …

Yesterday all my truffles seemed so far away,
But Fed-Ex delivered them in a day ….

Or, in the next Jason Bourne movie, he’ll be wearing a Coca Cola hat, and he’ll give us a little discourse on why he prefers Smith and Wesson handguns. And in the next piece of fiction you read, the main character will not only remove his shirt, but tell you wear he got it and why he prefers that brand.

Hey … make your choice. Either pay for content, and protect the rights of the people who sell it, or expect all content to become a commercial.

Not that this is a complete solution, by the way. It may work to some extent for consumer products, but what kind of product marketing are you going to do in high-end, expensive legal and compliance services?

Anyway, that’s where we’re headed. If the producers of content can’t rely on sales for revenue, they’ll have to go to an all-advertising format, and it’s going to be more invasive and annoying than commercials. (At least at first. It’s possible that some people will learn to do it well.)

Greg Krehbiel Uncategorized

Designing account numbers for “convenience”

January 5th, 2012

If you make a payment over the telephone, the guy on the other end will usually give you a “confirmation number” that’s something like this.

1H779301-0104725367489-C7283S

I often joke that such a “number” is precise enough to define any particle in the known universe, but I’m exaggerating a little.

It seems absurd that the numbers are so long, but we all know how this works. Different positions in the code mean different things. E.g., the 2 digits before the first dash indicate the 2-digit year, and the 4 digits after the dash are the month and day.

This is supposed to be more “convenient” for somebody. They can look at the code and tell you which effort it was, or which phone operator, or whatever.

But who is it convenient for? It’s certainly not convenient for the customer.

This will become an increasingly important issue for publishers as we try to link the online and the print world.

For example, we may print customer numbers on mailing labels and ask the subscriber to enter that customer number somewhere online — to synch up the print and digital subscriptions.

If the customer has to enter 1H779301-0104725367489-C7283S he’s not going to be happy. Especially if it’s case sensitive.

So when your operations people argue for reserving positions X, Y and Z to mean A, B and C, just say no. Make your customer numbers (or equivalent) as short as you can.

Unfortunately, some of us are stuck with legacy systems and these awful, long, complex numbers are built into our data. You may or may not be able to fix that, but going forward, don’t make the problem any worse. Focus on short, simple codes that customers can use.

And while I’m on that topic, if you mix letters and numbers in your codes, you should probably set up the system so you never use zeroes or o’s, l’s or ones, etc. That is, don’t use characters that can be easily confused.

Greg Krehbiel Uncategorized