peterbirks (
peterbirks) wrote2005-11-25 08:24 pm
![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png)
Entry tags:
The wheels just keep on turning
Andy Ward is now in St Kitts, and in just over a week I'm outta here to Vegas. Good. I shall try to update from there (yes, I know that I'm on holiday even with pictures .. the things that I do for an audience).
I spent a bit of time at work today trying to work out how to put out my newsletter as an RSS feed. Now, you probably think that this is easy. But, since it's five years since I created a web page, and since I don't even use an aggregator at home (or at work) it wasn't as easy as you think.
Part of the problem was that most of the sites I went to for guidance were starting from the premise that (a) you would give the information away, and that (b) the reason you would do this would be to drive traffic to your web site.
The standard format was "xml page with descriptions, linked to html pages with the full story on your web site"
These assumptions were seriously flawed, in that they were, er, utterly wrong. It's a subscription newsletter, and it has no base web site as such. And the last thing I want is to drive traffic there. I want as little traffic as possible, but for what traffic there is to be paying a lot of money for the information provided.
After I had spent three hours or so getting my head around how the whole thing was put together, I reckoned that I could use the following business model.
1) A "secret" web address (in fact, this already exists, via web space that I have available to me)
2) No html pages, all xml, with one xml page per subscriber. Apart from that, each xml page would be the same, consisting of that day's newsletter.
3) Fiendishly long codes for each xml page, which you supply to your subscribers, one code (i.e., one page) per subscriber.
4) So, when their sub lapses, you just remove that xml page from the web site.
Of course, a subscriber could pass the RSS subscription code (the URL they put into their aggregator) onto someone else, but this would show up in the increase in hits on that xml page (because each subscriber has a unique RSS url). At the moment they can forward the e-mailed newsletter without me having the faintest idea that they are doing so.
I can easily write a macro in Word that will save the newsletter as (say) 100 separately named xml files. So all I need is the software to automatically upload those files as soon as they are saved.
Obviously this doesn't work for a mass circulation publication.
The alternative was to have 12 xml pages, all the same, and with fiendishly long coded addresses, which were allocated according to the month that a company's subscription ran out. This would make uploading easier, but would make checking on cheating harder.
I spent a bit of time at work today trying to work out how to put out my newsletter as an RSS feed. Now, you probably think that this is easy. But, since it's five years since I created a web page, and since I don't even use an aggregator at home (or at work) it wasn't as easy as you think.
Part of the problem was that most of the sites I went to for guidance were starting from the premise that (a) you would give the information away, and that (b) the reason you would do this would be to drive traffic to your web site.
The standard format was "xml page with descriptions, linked to html pages with the full story on your web site"
These assumptions were seriously flawed, in that they were, er, utterly wrong. It's a subscription newsletter, and it has no base web site as such. And the last thing I want is to drive traffic there. I want as little traffic as possible, but for what traffic there is to be paying a lot of money for the information provided.
After I had spent three hours or so getting my head around how the whole thing was put together, I reckoned that I could use the following business model.
1) A "secret" web address (in fact, this already exists, via web space that I have available to me)
2) No html pages, all xml, with one xml page per subscriber. Apart from that, each xml page would be the same, consisting of that day's newsletter.
3) Fiendishly long codes for each xml page, which you supply to your subscribers, one code (i.e., one page) per subscriber.
4) So, when their sub lapses, you just remove that xml page from the web site.
Of course, a subscriber could pass the RSS subscription code (the URL they put into their aggregator) onto someone else, but this would show up in the increase in hits on that xml page (because each subscriber has a unique RSS url). At the moment they can forward the e-mailed newsletter without me having the faintest idea that they are doing so.
I can easily write a macro in Word that will save the newsletter as (say) 100 separately named xml files. So all I need is the software to automatically upload those files as soon as they are saved.
Obviously this doesn't work for a mass circulation publication.
The alternative was to have 12 xml pages, all the same, and with fiendishly long coded addresses, which were allocated according to the month that a company's subscription ran out. This would make uploading easier, but would make checking on cheating harder.
Your Newsletter
(Anonymous) 2005-11-25 11:42 pm (UTC)(link)I used to program a lot and haven't for some time and don't really keep up to speed, however from what I understand, XML is only to manipulate data and not display it, and really is meant to be used in concert with HTML which displays such data. Perhaps you are very familiar with XML and I am telling you something in error or that you already know in which case I apologize.
Since it seems like your main objective here is to prevent cheating, the question is how many of your subscribers know others who would want that info. If your info is used by corporations, and you don't have an enterprise subscription option, then perhaps the likelihood is fairly large. I was also wondering how much if any evidence you might have of such cheating. But it seems that if you were to place too high a focus on security, then the presentation of your newsletter could suffer, unless it is simply raw data to be used/analyzed. In that case, XML would probably be viable. Another point regarding the number of hits on a subscriber's web page would be whether they would ever have a need to ping it multiple times themselves.
If the information you provide is such that it is not raw data that needs to be input regularly in a subscriber's database for analysis, but is actionable in itself, then an option, though doubtless a tedious one, would be to convert the newletter into a graphics image which is placed on one common web page or multiple individual web pages. This prevents users from using cut & paste and if you could somehow limit any fttp priveleges perhaps you could also prevent their downloading the image and be able only to view it. I am not sure about this though.
I have a moderate interest in this topic myself for future reasons of my own and will be interested to see what you ultimately implement. This is indeed a change from the usual topics of the vicissitudes of flat life and poker.
BluffTHIS!
What's your motivation?
The thing with RSS is that it's more of a "pull" technology (or maybe it's more of a protocol) in that the subscriber decides when to go and look for new stuff. It starts to get useful when one has a list of places that one wants to check - I use Newsgator to do this - and one's aggregator goes out and just gets the new stuff, saving you from having to click through a pile of links to sites that haven't changed. Email, which I imagine to be your current transmission medium, is more about "push", in that it goes out when you push it out. And you control the list of addresses.
RSS is also pretty hopeless if you care about form, rather than content, which I suspect is not the case here. I suppose you could embed HTML in the feed, but that wold be missing the point rather - XML is all about structured content, with presentation being a client-side, client-selectable thingy.
Or something like that.
Mike
Re: What's your motivation?
a) Currently we have four subscription licences -- individual user, site licence, country licence and global licence. These range in price from about $2,000 to, well, in the case of GE and McKinsey, quite a lot.
b) What's the gain? A good question. A couple of subscribers have asked whether the newsletter is available in RSS because they want to integrate it into their intranet. I think this answers Mike's point about the "ease of distribution". It eases the distribution within a company that has, say, a global or national licence.
c) What's the business model? Well, initially (although I can see problems at work with this when I propose it!), I'd like to either give the RSS service away to existing national and global licence holders as "added value" that would strengthen my brand, or, at the most, charge a modest sum to supply it. Alternatively, we could add a fifth kind of licence, the "RSS" licence, charged according to the size of the company. But the general gain is that it means companies can put it on their intranet.
d) I don't care about form. The content is all that matters here, as Mike guessed. However, I don't want to split the newsletter into separate stories, partially because this is a hassle, and partially because I retain enough of a "push" mentality to want the newsletter to stand as a single entity, rather than as a collection of separate stories.
e) Why not carry on as before? Mainly, I think, because this could be a dangerous thing to do, long term. Remember Pointcast, anyone? That relied on "push" technology. I'd like to keep the "push" e-mail, but also provide a "semi-pull" option as well. If I can make more money for the newsletter as a result, even better, but it's really a matter of running faster just to keep still.
f) Part of my problem when I come up against the IT people is that I fear that they will come up with Mike's and Bluff's lines -- that RSS is meant to be used in concert with a web page and linked through to HTML. My response that it doesn't have to be that way could well be a little too far out of the envelope for them. Imagination has never been a strong point in IT (well, not in our IT, anyway).
g) XML/RSS gives it away in the coding with the word "channel". The idea is that you (the consumer) have a TV set in the form of an aggregator (any make) and you choose your channels, the volume, style, etc. Now, think of my newsletter as the ultimate niche "channel". It is designed to have only one consumer. For a small distribution newsletter, this is quite feasible. The consumer can still decide on the presentation but, since he is the only viewer on this channel, it is, understandably, an expensive channel to receive.