The magazine I’ve been talking about has two ‘problems’ that need to be solved. The first is the content, but that is something that can be handled later. The more immediate ‘problem’ is delivery and platform. I’ve already mentioned that I’m going for a phone solution here; a solution that can be scaled up to websites, and hard-copy if need be.

smartphonemediaIn a long mail to my teacher, the one who is on the board of the charity that is supposed to be the ‘client’ for this magazine, I described that I wanted the platform to be a phone thing because it is a shared characteristic of the audience that they all have phones.

It is likely, but less so, that they have their own computer. Maybe sixty per cent, or seventy, do. But that leaves a large minority that are consigned to using the family computer that’s in the living room, and I want the content to be what decides the audience rather than the technology.

I would say that ninety-five per cent, if not ninety-nine per cent, have phones. From simpler mobile phones to smartphones. What both types of phones have in common is access to the internet. And they can use apps. And apps can go on the internet and grab data. And that data should be the magazine, provided they sign up for the magazine.

digitalmediaBut distribution is a problem I’ll work on later. I just want to get the technology in order here first. I’m not the most amazingly technical person, more average than not, when it comes to these kinds of things. But what I see here is that the ‘app’ goes online to fetch an XML file that contains all the articles and the text. No other media.

The XML file is then interpreted into headlines, summaries, lead-ins and article bodies. Only when selected does the ‘app’ go and fetch pictures and images and video. Even then the data access has to be strictly and granularly controlled and configurable by even non-technical people.

This is because phone companies are price gouging vampire suck-masters that know just how to draw the heart-blood out of your veins with ‘data plans’. It has to be text, and it has to be XML, and it has to do with only a few kilobytes of data-fetching at a time. No more than that. And it has to be beautiful too.

cssrefIn order to make things beautiful, the ‘app’ has to be CSS aware, and that means it has to use some form of browser engine, like the open source web-kit that is in Chrome and Safari. So even a simple solution has its implications, like this.

I think there is a wider point here that is reinforced. In publishing, whether it is magazines or newspapers or books, it is not the container that costs a lot of money to produce. The actual book costs less than a pound, each copy of a magazine costs maybe 25-30 p. An e-book is nearly free. But it is these incidentals around that make the costs mount up.

The cost is never for the container, but the content and the logistics for producing the content is. Now, with the email sent, I have done my part for now. All that remains is for them to decide whether they can do this or not; whether they’ll have a budget for it, or not; and whether my plans are just so much pie in the sky, or not.

Maybe they’ll just get back and say ‘do this the usual way’. That’s fine too. Before I start to pester Mark to write me an Android/IOS program that will do all these things, I think I should stop here for now, and wait for that answer. My enthusiasm must be reined in by reality, after all. Right?