Anyway, the "secret" of my implementation is just taking the natural log of the total posts for each tag, then rounding to the nearest integer. I then subtracted that number from 5, and made the resulting number the <hX> number for a header. (With <h1> being the largest size.) (I also used the number 4 as a max for the rounded log result in case it was bigger.)
The log approach was the first idea I had over a year ago for how to implement it, and the results don't look too bad. One downside is that as tag counts approach 33 (about e^3.5), suddenly they'll all start receiving the biggest size of text. To counteract that, one solution is to increase the log base from e to 3 (needing 47 posts to get the biggest font) or even 4 (needing 128). A tiny bit of manual work every so often, it's not bad. There was another solution I thought of but didn't try, but it would keep me from needing to do manual work.
The idea was to compute the mean of the values and the standard deviation. Since I expect a right-skew, that is, most of the tags will have a small number of posts for them, the mean should be fairly low, and so I might set everything at the mean and below to be <h5> and then add a size for each standard deviation away from the mean. This would future-proof me, but I'm not sure the resulting tag cloud would look as good. When I have to adjust the base for my log I'll probably try this idea out and see how it looks.
Logs are great to designate levels like this, I think. It really drives home the notion of order of magnitude, and things undergoing a sizable change at that point. log10(10) is 1, log10(100) is 2, log10(1000) is 3, and so on. Increasing the number/size should be special somehow, especially as the number gets larger, and logs encapsulate that nicely. Yay for uses of logs beyond solving equations of the form a^x = y!
I have no idea how other blogs compute their tag clouds. Is there a really nifty trick that doesn't use logs that everyone else uses that produces something pretty?
Posted on 2011-12-03 by Jach