This week: I’ll be continuing to document the development API, and will create a few other custom metric/variant types to further dogfood the API.

The first example I hope to build is a plugin which encapsulates the workflow of A/B testing different titles on posts, and then automatically selecting the winner, à la Huffington Post.

Over the weekend I’ve thought more about the metric and variant type API’s. Right now my approach has been to require that these “plugins” be object-oriented: defining a class which extends ShrimpTest_Metric and ShrimpTest_Variant, respectively. But the actual mechanism by which these hook into different parts of ShrimpTest are using the WordPress-standard filter/action model. I’m wondering whether, perhaps, instead, I should define some particular method names which, if defined by the class, are called at particular points in the life-cycle of the experiment.

For example, when a new experiment is called, the extra data for its metric from the form is passed through a “shrimptest_save_metric_<metric name>” filter. Instead, perhaps I should check whether the metric has a “save_metric” method, for example, and if there is, calling that method.

If anyone has any thoughts on whether one pattern would be better than the other, I’d love to get such feedback. 🙂