Microsites feature - forums

In my previous post I wrote about my intention to leverage the traffic I get to my online store to start microsites around product groups, such as different bands. I took my first step into that direction by tweaking PhpBB and doing some mod_rewrite trickery to allow me to easily create several forums which appear distinct, but are actually all running on the same software and database. This allows me to maintain only one installation of PhpBB and create a new forum in about 20 minutes instead of a complete new installation.

Obviously a microsite is going to need more than just a forum, but I imagine that for a successful microsite the forum would be the most important part of it. To test out the system I created two forums around two bands whose products I sell, Maruru forum and Antic-cafe forum.

Deciding scope

The reason for starting several small forums instead of one big one is to create a sense of belonging / identity for those using them. People seem to feel stronger attach ment to smaller circles. For example people will feel a connection to those attending the same school as them, at a lesser level to those living in the same city as them, even lesser to those from the same country. I want to find the optimal "circle size" to get people to feel that attachment, while not limiting fruitful conversations that could have happened if those circles were combined.

For example I could have created a "japanese music" forum instead of having "maruru" and "antic-cafe" as separate forums. Perhaps I should have, not sure, still experimenting. Certainly someone who is an enthusiastic fan of Antic Cafe would feel less at home at a generic forum for all Japanese music. Still there clearly has to be some minimum size at which an active forum is still possible, if there wasn't I could create a forum for people from Vatican who like Michael Jackson and are into cross-dressing. It would be a small group, but man would they be into it.

Microsites

I run a webstore, which means that I get very targeted audiences to my website. They will often even specify their interest by doing searches, or by looking at certain items. Mostly they are only looking, not buying, which is fine of course. Lately I have been wondering whether these targeted visitors could not be used to launch "microsites" related to certain products or product groups.

Take for example a person who searches for "dir en grey", then looks at products from the band dir en grey. Clearly they are quote interested in this band. Perhaps I could tell them "hey have you checked this fanpage for the band?". This could be a very relevant thing to say, and when things are relevant they tend to not be irritating. The trick of course would be that these fansites would actually be sites that I have launched myself (perhaps clearly indicated by being a subdomain of my site, say dir-en-grey.bemmu.com). They would become destinations in themselves, possibly growing and sending back more traffic to the webstore than I originally sent to them, also being nice baits for Google to index.

The microsites could contain a standard feature set and customized skin. For example a forum for talking about dir en grey, but with a forum template showing the dir en grey members. Forums have the effect of getting people to come back to check if their posts have been answered. Another good one is quizzes, which tend to be viral since people like to post the results on their homepages or recommend the quizzes to their friends.

Of course this is nothing new, there are plenty of dir en grey fansites out there, but I would like to make the process of launching these microsites very organized. All the sites would actually share one codebase. There might be 100 different microsites for different bands or manga series for example, but only one forum software running, customized to display a different skin for different audiences, but only requiring one login to use any of those sites. Same for the quizzes or possibly other features. The skins might have been outsourced somewhere, quizzes could be created by the users.

This whole idea might be impossible in that a certain amount of manual labor is always required for the maintenance of those sites. Forums need moderators. Quizzes also need moderation, since if they can be freely created by users there can be inappropriate content. Still by being clever I imagine that I could organize the creation of such microsites to be more efficient than the normal work of creating a fansite (of course these would not really be fansites in the traditional sense, but feature-wise they would be the same).

Amazon and other big webstores might be missing a great opportunity when they are only pushing products at the visitors, where they could be pushing communities as well.

eBay API experiences

Lately I have been trying to learn how to use the eBay API to list items and learning exponential representation for complex numbers in Algebra. Using the eBay API is the harder one out of those. Just a minute ago I finally succeeded at listing my very first item by using the XML API, it was a bit more complex than I thought! My mental model for how the API would work was that I would pass my eBay user id and password, along with the item details wrapped in some XML.

Nope, there are several different kinds of keys involved. All in all I currently have NINE different pieces of authentication! I have a DevID, an AppID and a CertID. Then there is the eBayAuthToken and the REST API key (which I admittedly only used once for testing, it is not needed for the XML API). But wait, that's only five? Yes, but you see eBay has two servers -- production and sandbox. The sandbox is for testing, which is useful since listing things on the production server costs money, so you definitely don't want to end up listing ten thousand items by accident. The sandbox and production servers have completely different authentication keys, except the DevID appears to be the same (making it nine different keys total).

The eBay developer site doesn't make this sandbox and production server difference clear. When talking about authentication keys, they casually mention that oh yeah, there is the sandbox server too. But what they don't say (on the intro pages at least) is that you need completely different keys for those. So imagine my frustration at attempting to access the sandbox with my shiny new production keys. With all those different keys I was getting really hopeless and uninformed, mostly reading reddit instead of focusing on the problem.

Somehow after a lot of digging I managed to figure it out. A DevID identifies a developer. A developer may have multiple applications, with each application identified with its own AppID. CertID is a magical entity the purpose of which I don't understand, but things seem to work when I bundle the same CertID that came with the AppID. The eBayAuthToken must be generated on their web page, and generating that requires providing correct DevID, an AppID and a CertID for the server which you are trying to use (sandbox or production). In other words you cannot get an eBayAuthToken for the sandbox server by using the production DevID, an AppID and a CertID + vice versa. The REST key is needed only for... you knew it, making REST calls.

After I finally had my keys I started to read the API reference. I tried to pretend calmness, but actually I was a bit shocked of seeing all the possible method calls and the arguments they take. Huge list. Maybe I'm not enough in the XML camp, but in my mind things work like this: you get a template string of a working XML call, then you change the things which are different from what you want and send that string at the server, which then does something cool. It's pretty difficult to try to come up with something that works by just looking at an API reference if there are 20 different arguments that could go wrong! Luckily, the developer center has very nice examples of using the API, so I was able to get things working by copying and pasting their examples.

Another thing which seemed like a showstopper at first was that they require usage of SSL to access their server. That is an excellent thing of course for security, but complicates things a bit when you are just trying to get a minimal example to work. I was planning on using PHP, but felt a bit intimidated at the thought of figuring out how to get SSL working on it. Just to get acquainted with the API, I decided to stick with Perl as they had some nice Perl examples in the developer center, complete with instructions on how to install SSL support for Perl.

So I had my keys, I had an XML request constructed from the example and I had ActivePerl installed on my box, with LWP and SSL support, aaand... it worked!

Update: After 30 mins of reading some example code I managed to figure out how to make the same request using PHP, HTTPS with cURL! One thing I was worried about was how image uploading would work, but turns out that you can just specify an image URL and eBay's server will go and fetch it -- no need to figure out how to actually upload the data, what a time saver! Just a bit more effort and I'll have this code integrated with my web store.