2009 In Retrospect

As we’re now getting a bit more touchy and feely about 2010, I’ll give a short update on the blog itself like I did at the last day of 2008 (and even the title has been recycled! again! The big trend of 2009!).

Key statistics (last year’s number in paranthesis) (2008 was the first year I blogged, so 2009 is the first complete year of data):

  • Posts: 54 (161)
  • Comments: 81 (89)
  • Hits: 399084 (242781)
  • Unique: 30561 (18882) (since the start)
  • Spam caught by akismet: 11828 (2596)
  • Most spammed month: May, 4123 (November)
  • Technorati Authority: 99 (13)
  • Technorati Rank: 78.215 (454.532)
  • Reactions registered on Technorati: no idea how to find this now! (51)
  • Incoming links (to e-mats.org) on Google: 187 (29)
  • Incoming links (to e-mats.org) on Google Blogsearch: 30 (23)

Most popular referers:

  1. google.com
  2. search.live.com
  3. google.co.uk
  4. google.de
  5. google.co.in
  6. google.ca
  7. google.fr
  8. en.blog.wordpress.com
  9. google.nl
  10. google.com.au
  11. google.pl
  12. google.se

At least two weren’t Google!

Stats I didn’t include last year, but decided to include this year (the numbers for last year in paranthesis as above) from Google Analytics:

  • Page Views: 49.403 (21.997) (+125%)
  • Visits: 38.537 (16.082) (+139%)
  • Search Engine Referers: 85.4% (70.8%) (+20%)

Most popular search terms (and some of the most popular posts):

  1. solrj
  2. svn external
  3. ssh_exchange_identification: connection timed out
  4. solrj example
  5. tortoise svn externals

And then we look ahead for the same post in 2011. Keep your pants on!

Resolutions Be Gone!

(Haha! Thanks to the wonderful internet, I’m on vacation .. and still posting things in my blog .. that I wrote BEFORE we left! How’s that for TIME TRAVEL???)

We should really stop using the resolution information in our statistics scripts for anything. It’s nothing other than curiousity, and it should never be used for making any decisions regarding how a page should be structured. Most people probably stopped reading halfway through and thought that I’m going completely nutters. What do you mean? But .. how can we know how many pixels we can use for our design?

You’re out of luck! Hopefully I’m not singing Lady Madonna and strolling around somewhere in Europe wearing a pink tubetop just yet, and I still have my sanity. Instead of basing our decisions on resolution, we should start paying more attention to actual browser window size. This is interesting from a usability perspective, as it considers the size that we actually can use without demanding that our users start resizing their active browsing window. The desktops I use actively are usually running in 1920×1200, but my browser window is considerably smaller. If a page suddenly would require me to use 1920×1200, I’d be annoyed (and yes, that includes those of you who still think your content is SOOOOO important you should open up windows in fullscreen mode, and still only use 50% of it for content..), even though I actually have a resolution that supports that kind of content.

Since this means that we’d see a lot more sizes than the regular 1024×768, 1280×1024, etc, we’d simply create intervals of “acceptable sizes” instead. We’d have (640-800), (801-980), (981-1099) instead, and we’d be able to give an estimate of how much content we could actually show a certain percentage of our users within their first view of our information. Even though people have 1024×768 as their resolution, we have no idea about how much content they actually see. I have no idea if that means that the majority of people see 500 pixels of content, 300 pixels of content, etc (and that would of course also change based on font size, but .. stay on track with me here), which is actually the useful information to base your decisions on.

So, anyone with me? How about support for this metric in Google Analytics? Anyone know of any existing statistics project that has added support for the actual viewport instead of the screen resolution?

Memcache Stats

Harun Yayli has a post up about a PHP application for retrieving and presenting memcache stats from several servers. The interface is built on the familiar apc.php which is included with APC (Alternative PHP Cache, a PHP bytecode / shared memory storage cache), and should be easy to navigate for anyone who have used apc.php. The stats shown in the application includes total space available, memcache usage, hits, misses, uptime and other interesting information.