Last month, we spoke of arcane wonders. We learned what XML-based web content syndication is, how it works, and a few ways in which webcomic creators might make use of it. In this installment, we’re going to expand on the possibilities raised briefly in the last article, and hopefully correct some misperceptions about how syndicated feeds are used by readers.Last month, we spoke of arcane wonders. We learned what XML-based web content syndication is, how it works, and a few ways in which webcomic creators might make use of it. In this installment, we’re going to expand on the possibilities raised briefly in the last article, and hopefully correct some misperceptions about how syndicated feeds are used by readers.
Your Potential Audience
An alarmingly popular misconception is that people who don’t just bookmark a comic site and check it manually for updates, or follow communities or whatnot for update notifications, aren’t "real" fans. They’re lazy, they’re demanding, they’re ungrateful for their free content, et cetera.
The bottom line is, people generally don’t have time to keep up with a myriad of update notifications, embarrassed apologies, message boards, communities, and status bars. They’re making a quick sweep over their bookmarks in their free time, which can be quite limited if they read from school or work. They don’t love your work any less for wanting to read it in an expedient, efficient, and frankly convenient fashion. It’s the same mindset which drives one to a TiVo: with only so much time in a day for beloved, stress-relieving entertainment, tools which make the best use of that time become increasingly important.
Every introductory article on making webcomics will tell you that frequent, regular updates will attract readership. This strategy still depends on your readers keeping track of your schedule and incorporating it into their routine. The forgetful reader, pressed for time, can be enticed into reading your content as it appears if something is around to remind them of it. When offering a feed for your webcomic site, you make it easier for the casual reader to transform themselves into a regular one. The presence of a feed is a great adjunct to the usual bookmark exhortation, particularly when a fortuitous outside link sends new readers to you when you’re just getting your bearings. Popular news, weblog, magazine and business sites cultivate and maintain reader bases this way. Why should comics be any different?
Heavy Site, Light Feed
A combination of time constraints and physical resources might be more pressing to some of your readers.
They could be reading your comic using any manner of devices, running web clients which don’t take kindly to complicated layouts, over any manner of connections, some of which are undoubtedly going to be slow. Don’t trust your logs here; browser spoofing – the practice of having a browser pretend to be something completely different – can skew your results enough to make them misrepresentative.
Let’s look at popular gaming comic Mac Hall, which has no advertised official feed. The comic page for 8 March 2004 brings together 39 separate files to download, totaling 327.95K. That’s close to a third of a Meg; no small potatoes. Of that, 166K is the comic image itself. 33.5K is the HTML and the rant content, 4K of which is the rant content itself with some presentational tags; 48.3K is the ad banner. This leaves 80.15K of graphical assets serving only to decorate the page, plus 29.5K of layout markup, links to non-content material, and navigation.
Mac Hall doesn’t have a regular or frequent update schedule, nor a sanctioned status notification method other than the rants on the front page. Since a browser can’t necessarily be relied upon to have kept static page elements in cache, readers will often find themselves fetching the same content over and over. Over a dialup connection, and/or on a slower machine, this can be a somewhat painful process, and one assumes it must put some strain on the comic creator’s co-located server over time as well.
A headline-only or rant-only feed of Mac Hall would notify the user when new content was available, and only demand that they fetch the full page in that case. A full content feed (pretending, for the moment, that advertising isn’t a consideration) very nearly halves the amount of data served for the same amount of new stuff. A feed might, under these circumstances, seem quite attractive to the reader.
Not every webcomic’s site is this resource-intensive by a long shot (Mac Hall illustrates the point by being unusually heavy), but the underlying message remains. Your readers are almost certainly coming for the content, not the layout; if the method you offer for getting at your content is in any way cumbersome, and they find themselves presented with one less so, they will take the other method.
And here’s the rub, really: every day, more and more "scraped" feeds and dedicated aggregators for webcomics are popping up, authorized or not. A creator can work to have them taken down, but the demand is still there, waiting to be filled. It may well be time for you to take control, and make your feed be what you want it to be. (Or, at the very least, it’s time to make public your wishes and reasons if you do not want your webcomic to be read outside of your website under any circumstances.)
Considerations and Options
Of course, it’s your site, and you’ve got your own matters to consider. If your priority isn’t getting the material out there uber alles, syndication might not seem like a priority. There are some compelling reasons for certain creators to think very carefully before making a decision.
Feed aggregators can poll for new content quite frequently (a common default for desktop aggregators is 15 minutes; LiveJournal does so hourly), and so can become bandwidth-intensive if your webcomic is popular. At that point, it’s worth checking your logs, if you can, to see how many of your pageviews come from unique visitors, and how many are the same people reloading over and over until you throw up something new. If you generate your pages on the fly, you might also consider whether trading increased feed hits for fewer database connections might be easier on you in the long run.
If you know that much of your fanbase makes use of a service that also serves as a feed aggregator, and they do so in the name of your comic, take advantage of that. The aforementioned LiveJournal is a really good example. Creators may already make use of an LJ community or journal to post updates or full comics.
If the community is heavily trafficked, however, an RSS feed with an associated LJ syndicated account is a great way to reach those readers who don’t have time to track that community, or aren’t comfortable participating in it. Also, remember that public posts to a journal or community will be available in associated RSS and Atom feeds, so you can kill two birds with one stone if need be.
You might depend on adviews to offset your bandwidth costs. Again, take into account how many of those views are coming from the same people, again and again, particularly if your ads rotate relatively infrequently. Also have a look at how many of them are clicking through and supporting the sponsor. In the short term, repeat visits mean lots of adviews, but the extended benefit is going to be somewhat limited. A reader who’s just checking for updates and getting the heck out may be loading the ads, but not necessarily noticing them.
Also, should you decide to take up a full or partial content feed, then consider the use of discreet, minimalist advertising embedded in the feed itself rather than simply offering headlines. Consider the Google AdWords example: the practice is not without its detractors, and may be incorrectly viewed as spamming, but is indeed catching on, enough to merit its own ad network. A one-line link at the top or bottom, along the lines of "sponsored by foo," is still something. If you tend towards merchandising alongside or in place of advertising, there is absolutely nothing stopping you from mentioning that in your feed.
Simple is best here. Tracking the clickthroughs might be a bit problematic; one approach might be to have the ads linked to special redirect URLs going through your site, and keep track of how often those are employed. You can track how many unique sites grab your feed each day, and how many people subscribe to its associated LJ account if it has one, and give those stats to potential advertisers along with the traditional ones.
If your non-comic content is a major component of your site (as with Penny Arcade, for example) you might want to look into multiple feeds. This could be particularly useful if your other content updates at a different pace to your comic. Feeds can be redundant with one another to serve various purposes. Penny Arcade only has one RSS feed, which offers headlines for news items and links for comics as they’re posted. By way of comparison, the unofficial feed through Tapestry gathers up the comic and a link to the day’s news in one convenient post, and that may be all a reader particularly wants. Have a look at Utne Magazine‘s example. Imagination is the only limit here; just remember to link to relevant archive pages in the process.
(An aside: your concern might not be the impact of daily pageviews so much as the big dent in your bandwidth that people reading the archives can cause. A combination of RSS and BitTorrent may help alleviate this burden in the weeks and months to come, although this is very much a new thing. There’s absolutely no reason, however, why webcomics can’t get there before big media!)
A webcomic’s readership springs from an increasingly busy, data-saturated environment. Catching the reader’s attention and maintaining it is paramount. Still, it’s vitally important to tailor your approach to your personal situation as well as theirs. If you’re worried that others will fill a demand for syndication in a fashion you find undesirable, now is the time to move.
So, you’ve looked at your options, thought about what kind of feed might be right for your site, and are ready to move forward. Next time, we’ll focus on the nuts and bolts: how to roll a feed for your site by hand. With examples.
Keenspace.com has had automated rss.xml file generation since september 8 2003, however it’s subject to the author putting xml markup in the description which prevents the rss.xml file from being read.
The RSS file links to the “daily” archive file for the most current, which is usually lighter than the main page, however not always. If there is bonus content on the front page (like rants or navigational material) then it’s not seen. The RSS feeds work with Livejournal (in fact were designed specificly to work with Livejournal’s syndication feature.)
ALL keenspace sites support it if they are are manually or automatically updating. The RSS has a to-the-second update time for the comic. So it will only show up in your LJ friends list or syndication when actually updated.
Comments are closed.