Adding Tags to articles in Radiant

I have started thinking about generating content on the general site. It's harder than it sounds, mostly because it takes me so long to write things. I hope that through  practice, this will improve.  One of the  things I would like to do is to be able to tag articles and links by Risk Topic, to make them easier to search.With this in mind, I  will compile a list of potential tools to do this (in Radiant, my CMS) here, to help me, but also anyone else working on this problem.

Here are the  options I have so far.

spanner/radiant-taggable-extension
This seems to be an extension of another tag extension with some improvements and a focus on organizing content based on those tags - which sounds good.

(a few weeks later...)

OK, I have tried the taggable extension and found it less than user friendly.  This is most likely because I suck at Radiant and am also pretty bad at Ruby on Rails and there is hardly any documentation for this extension.

But, in trying to figure out how to use Tags to organize my site, I realized that I was using a fundamentally flawed approach.  I was trying to use the standard blogging template, which organizes URLs by date, when I'm not creating a blog at all. I want to create a series of Articles on specific Risk Management related topics and I want to group the articles by topic to make site navigation easier.  Once I realized this and switched off the blog archiving feature, it became a simple task to manage without tags. It's almost the end of 2010 and now that the basic framework for the content site is in place, look for articles to start coming out. My goal is one per week, but this will be hard.

Ciao

Jonathan

No 'Risk' related apps

I just ran a quick search on Google Apps market place and there are no Risk related apps. This means that there is either an opportunity here or absolutely no market for this product at all. 

As I am a pathological optimist, I will choose to believe the former until proven otherwise.

Testing, testing, one, two, three testing ...

It's been some time since I last posted, but I have been quite busy in the last few weeks.  I tend to be the type of person who is very good at starting things, but less good at finishing them. I can do it, it just takes some concentration.  After a bit of distraction (beer brewing sensor/data logger, 2D image to 3D virtual object video processing) my focus is back on PRM.  The goal now is to get the site up and functioning for actual users.  My plan was to start using it myself in my daily Risk Manager job (amazing concept, I know...) but when I tried, a few things were broken due to changes I made elswhere, which affected things that used to work.

I have reasoned that once real user's get on the site, they won't be happy about bugs like these and will most likely not return, so I have taken the  advice of 'Pragmatic Programmer' and started implementing Tests in my code to first tell me when the problems that I have identified are fixed, and second to prevent problems from coming back undetected. It usually takes about 3-4 times more work to implement the test than it does to solve the problem, but I can imagine that the pay-back will be there when later, lots of users will be on the site and it prevents hours or days of down time.  It also just feels right to be doing it this way - almost like a professional.  The time to implement each test is starting to improve as I learn what works and what doesn't and I have to say it is deeply satisfying - almost to the point of being thrilling, to run a series of tests and have no failures or errors.

Giving up on fixtures.

This post is somewhat technical, but this problem has been giving me headaches for some time now, so I want to document my decision.

The problem has to do with setting up the databases with seed data.  Rails has something called fixtures, which allow you to create seed data for testing purposes.  This is ok, but not great for seed data which should be permanently loaded into the testing and production apps.  There is also a seed function, which does exactly this.  Ideally, you would first seed the test or dev databases, then add your fixture data so you can make your tests (test environment) or just play around (dev environment). The problem is that when you load fixtures, it deletes the seed data.  If you try to load fixtures first, then some of the  base data that the objects in the fixtures require is missing, so they are incomplete.

My solution will be to use fixtures, just for testing, which will require duplicating some of the seed data (grrrrr) and just use the seed function  for dev and production.

Choosing a CMS

It's time to start adding content to my site to start driving search traffic.  I envision three content types that will drive search traffic.

I will create a section of evergreen content comprised of articles related to tender risk management principles. This can be added to steadily over time. Obviously we will focus on currency risk in the beginning.  Later, I hope to entice experts to contribute articles as well. It will help them build their personal brands and help me by providing content.

The second type of content will be to post summaries and links to relevant articles on the web.  This will hopefully provide lots of useful content for potential visitors without too much effort. In the future, scanning for articles, writing the summaries and uploading the content could be outsourced, when cash flow allows.

Finally, I would like to have a Q and A forum based on the stack-overflow model.  I have seen that you can use their concept, but I have no idea what it will cost.  Also, I do not know how much effort it requires to administrate.

A content management system (CMS) will be used to streamline the content generation process. After some quick searches and playing around with a few demos, I have settled on Radiant, which is based on rails and aspires to be a relatively basic CMS, which suits me fine.  It also has a decent extensions framework for customization.

Tying the content site to the application is not so simple.  I could run the two sites side by side with some cross linking - easy to set up, but no chance to share user_id's so the content site would really just serve content, no app functionality. I could also migrate the app to the radiant based site, which is theoretically possible, but it would be some effort.

I will choose the first option as I don't even know if this model will make a viable business yet. Lets see if we can get some users on the app before spending a significant amount of energy to make it easy to use.

The evergreen content and the link summaries will be setup first. The forum will have to come later (when we have users/visitors).

Marketing chanels

It would be interesting to have a widget that people could embed in their web pages. The widget could simply calculate provisions for a given conversion/duration. Another variant could ask people if they thought the currency was going to strengthen or weaken and use this to give a forward looking estimate, and not just on historical data.  Actually, we could combine the two.

The widget should provide something useful (as above) and have a link to our article on how we calculate the provision. This would be a great way to bring people back to the site and introduce the complete tool ($$)

Funnel strategy part 2

I am starting to think that there is not much sense in limiting the features of the free trial.  The strategy hinges on the user falling in love with the service, and then realizing that he can't live without it.  It makes no sense to limit the features in the trial period:

1. The user would have less features to get hooked on
2. It would actually be more work for me to disable the features.

I'll give it a few more days thought, but at this point it seems like this way is better.

Funnel strategy

I am reading Patrick McKenzie's excellent blog that describes the process he went through when starting his micro independent software vendor business. In this post, Patrick describes his strategy for converting people looking for bingo cards into paying customers. He wants to give cookies away, then offer milk for free, but sell the pail needed to get the milk home.  It's a great post, so I won't describe the details here but do recommend you read it.

I decided to analyze my intended conversion strategy, which I must say I spent all of ten minutes thinking about - in the shower, against Patrick's successful and well reasoned approach.

My strategy is to:

1. Provide a tool to easily analyze currency risk. The analysis, will be slightly limited due to 'server resources' and therefore, the answer may not be as accurate as a paying customer would get, but still very useful (~90% of the solution). The user can have the analysis from the web page after selecting two currencies and a duration. The key result is single figure representing the safety factor to be used when calculating the price of an offer.  Additionally, if it helps, some eye candy, in the form of supporting graphs can be displayed as well (ab testing goes here...).
2. If the user would like to save this exposure and get weekly updates on the evolution of the risk, then he/she can create a free user account.  The user can log in to see the status of his exposure at any time, he can create additional exposures as well and furthermore, he can select to have weekly status updates mailed to him.  The updates will include links to relevant articles in our knowledge base section as well as a reminder that the risk factor accuracy is slightly limited due to excessive resources that are required for the full analysis and a call to action to sign up and rectify that issue.
3. If the user signs up, he will get the full-bore analysis, which will result in more accurate provisions, which should matter to people using these in actual business cases. The error factor can be from hundreds to thousands of dollars or more, depending on the sum at risk. Also, the user can group exposures for multiple currencies so that the net effect for a single offer can be evaluated. These two features are aimed at reducing risk, the who goal of the exercise, and making it easier to do that task.

When I view this strategy through Patrick's lens we are doing the following:

1. Giving away a sip of milk.
2. Providing some milk and a glass that leaks a bit in return for the effort of creating a user account.
3. Selling chocolate milk and a pail, that makes taking the milk home much easier.

This strategy does not have the same power as Patrick's since many people might be happy to have the regular milk in a leaky glass, which is certainly better than no milk.  In other words, I would be competing against myself.

After the shocking realization that my strategy was flawed, I sat down and tried to improve.  The goal of this tool is to help evaluate the risk of making time based commitments. The longer the duration of the commitment, the greater the financial risk.  With this in mind, I decided to slightly modify level 2 as described in bold below:

1. Provide a tool to easily analyze currency risk. The analysis, will be slightly limited due to 'server resources' and therefore, the answer may not be as accurate as a paying customer would get, but still very useful (~90% of the solution). The user can have the analysis from the web page with just inputting two currencies and a duration number (integer). The key result is single figure representing the safety factor to be used, but if it helps, some eye candy, in the form of supporting graphs can be displayed as well (ab testing goes here...).
   
2. If the user would like to save this exposure and get weekly updates on the evolution of the risk, then he/she can create a free user account.  The user can log in to see the status of his exposure at any time, he can create additional exposures as well and furthermore, he can select to have weekly status updates mailed to him.  The updates will include links to relevant articles in our knowledge base section as well as a reminder that the risk factor accuracy is slightly limited due to excessive resources that are required for the full analysis followed by a call to action to sign up. The duration over which any exposure will be tracked is limited to three weeks, at which point, the user will receive an email notification explaining that due to limited server resources, free account exposure tracking is limited to a maximum of three weeks. The user can manually create a new exposure to continue tracking his risk or sign up for the paid service.
3. If the user signs up, he will get the full-bore analysis, which will result in more accurate provisions, which should matter to people using these in actual business cases (the error factor can be from hundreds to thousands of dollars or more, depending on the sum at risk. Also, the user can group exposure for multiple currencies so that the net effect for a single offer can be evaluated. These two features are aimed at reducing risk, the who goal of the exercise, and making it easier to do that task. 

This small tweak changes the strategy to:

1. Giving away a cookie.
   
2. Providing some milk and paper cups that will dissolve on the way home in return for creating a user account.
   
3. Selling chocolate milk and a pail, that makes taking the milk home much easier.

 The second stage is not nearly as useful to users as before, but it does give the user a solid 'taste' of the milk. 

The short trial should be more effective at converting users to customers since the customers who will benefit most are those with the longer validities.  I think a two week period might even be better (a lot of 30 day offers are made), but I also think that getting three weeks of updates should get the user solidly hooked on the information (AB testing!!!). In this version the user can see how the process would be very useful and can even get hooked on the service, but tracking the exposure for three weeks is basically useless for those who need it most.  Yes, the user can manually recreate the exposure and effectively get the same service, but this is like having to stop every quarter mile and pour the milk from one disintegrating cup into a new one. The user may do this once, but the next time the cup is falling  apart, I think he would pay a small sum to a person standing on the side of the road with a nice pail and some chocolate powder to boot, knowing that he will have to change the cup several more times before he gets home.

Finally, we would have to test the effect of informing the customer that he can renew his exposure manually, or just thanking him form trying our service.

Introduction

For the last several months, I have been working on a simple web app that would make a few of my daily tasks as a risk manager simpler and even done in a better way.  This blog is a place for me to document some of the solutions to problems that I have overcome as well as some of my decisions so that I can recall the logic behind them months later.

I am publicizing this information simply because I have benefited tremendously by others doing the same.