The publishing paradigm is fairly simple: Build an edition, ship an edition, archive an edition. To save on production time you have a style guide and layouts that barely change from each edition. Every now and again you’ll make a change, like the Guardian becoming a tabloid format and it’ll cost you a fortune. So you follow patterns, not for the sake of a love of patterns, but to keep costs down.
But you can keep breaking those little patterns here and there, and you do. You have a special section about the Royal Wedding and you can add ten pages which all have different typography to reflect the special occasion. No problem at all, because in ten years time you’re not going to still be producing copies of that special edition on print. But that leads us to some questions:
How long do you want your content product to last?
- How long will you be serving this content?
- Will you be able to have licenses for the assets until that date? Assets include fonts and stock images, which may have time limited licenses.
- How much will that cost and is there a profit once all that is accounted for?
- If you’re using a third party supplier (ranging from Twitter to mapping platforms), will they still be running for as long as your content is relevant?
- When you change platforms, will you have to recreate that special content? and if not, what does that mean for digital archives?
Of course, if your content has low long term value – gossip, for example, then you may decide the content can die off. We’ve seen customers decide to save money on migrations by throwing away old content.
The same applies to any new feature you add to your website. Let’s go back to the example above with a special Royal Wedding edition. For the occasion custom charts and maps are produced by a really great web service for just £20 a month. After six months or so, you decide the information is no longer needed. So what happens to those old charts? If your website lasts for twenty years, will you pay to support those interactive charts for twenty years?
You could ask your developer to use a content rendering approach, where an image of the chart is stored in your CMS and that’s then replaced using javascript with the interactive chart. But then the original cost of adding those charts goes from adding support for an oEmbed provider (about an hour or two once you account for all the comms, checks, plus the subscription and so on) to creating something that could take days to build.
The price soon increases for what was a ten day special. But then if that ten day special is going to bring you £500k in extra revenue because it’s so special… then it makes perfect sense.
Business models and plans
In software, the business model for publishing software used to be the same as for paper. Once you’d coded, tested and compiled an application you burned it onto thousands of CDs and off they went. Bugs would often remain until the next version, so people were keen to ship bug free code, just like magazines are keen not to print spelling errors.
But the internet, as with print publishing, broke all that. It meant that security and longevity became an increasing problem, so any code, any API, had to remain secure or hackers would attack. Quickly, the software industry knew that it was important to switch users to a subscription model. Customers didn’t really like this—they were used to buying one edition of something and using it for ten years.
Consequently, developers increasingly like to work to tight specifications and standards for core functionality. The problem tends to come when dealing with writing code for people who aren’t used to writing specifications for computer systems. The developer’s job is to try to work out what you really need. And that’s never easy! Especially on a constrained budget.
The big problem is that good software specifications are really really hard to write, and even harder to prove. All good specifications are long, detailed, and have complex test cases to ensure everything works correctly. As an example take a look at the iCalendar specification. The specification only actually covers the presentation of calendar information between pieces of software—nothing about how to store that calendar information in a database. Nothing about how to display it visually in a nice way. It is solely interested in the communication of the information and it’s about 174 pages long. The specification for the Google Calendar program is probably several thousand pages long, if it were to be printed out in one go.
Long life = more time, more effort, more money
If you decide that long life for your content is important, you have to embed this into the business models and culture of both your team and the development team. If you decide the long term life of your content *isn’t* that important, save good money today by not worrying about it and if the requirement changes in the future, well that’s your successor’s problem!
But do make sure to be clear about this. Don’t expect a cheap system to have the most carefully worked out schemas for data storage and management. And don’t even expect an expensive system to have thought of everything, because it’s probably not nearly as expensive as it should be in order to be ‘perfect’. Software is complicated and hard to do. Many many software projects fail, or go over-budget, and it’s down to a list of problems that I’m going to steal from Robert N. Charette’s 2005 essay on the subject:
- Unrealistic or unarticulated project goals
- Inaccurate estimates of needed resources
- Badly defined system requirements
- Poor reporting of the project’s status
- Unmanaged risks
- Poor communication among customers, developers, and users
- Use of immature technology
- Inability to handle the project’s complexity
- Sloppy development practices
- Poor project management
- Stakeholder politics
- Commercial pressures
If you’re instructing a company to code for you and you own the code and the project, then you are now not just a publisher of words and pictures, but also a software company. The unique software you’ve built is your responsibility and the responsibility of your predecessors. Especially if it’s central to the company.
There is a simple answer, however
If you can stick to using an off-the-shelf software product, then a lot of the thoughts and ideas driving it will have been well proven, but it does limit your ability to extend, adjust and change beyond what the software does. It’s also one reason why we decided to build Standfirst—it’s WordPress, which is a very established and well known product, with a series of adjustments and a way of running on infrastructure specifically designed for the publishing industry.
Standfirst can fulfil most publisher business needs very well indeed, whether you’re a large or small publisher. It means that a small publisher can compete effectively with a fast and attractive site that doesn’t break when you get that viral surge. It means that large publishers have the versatility to choose the subscription level that most meets their business needs.
The only element that is, in effect, yours is the styling and presentation, and any custom integrations you may need. For example, a site such as FamCap is kept pretty simple. It still has an effective paywall, uses Stripe to handle subscriptions and does all the things you might expect such a site to do, but it’s on a competitive subscription level and can still be scaled to handle a million visitors a day. This allows this small publishing business to function and grow without worrying too much about software. If you’d like a demo, drop us a line through the form at the bottom of our Standfirst product page.
