Drop what you're doing and help us test!

When we originally released the new Clicky a few weeks ago, we had programmed in support for detecting small screens (1024 or less) and moving the sidebar to the top instead, so that you don't have to scroll sideways. However, there was apparently a serious bug with it and some of you were getting this forced small screen mode even if your browser window was large and in charge.

Well, we think we finally fixed it. However, since we never saw the bug in action ourselves, we need you to help us test this change before making it live. To help test, please visit beta.getclicky.com and tell us if you see it (by leaving a comment here). Don't just test once though - after you login and view a few reports, completely close your browser and re-open it and see if it continues to happen. Maybe try making your browser window small so "small site" mode goes into action, then close that tab, make your screen full size again, then re-open beta.getclicky.com. We think that may have been part of the problem, the screen size wasn't being checked properly if next time you viewed the site it was small instead of large or vice versa.

Thanks for your help and in particular if you were one of the ones experiencing this problem with the initial release, your feedback is appreciated!

UPDATE: To clarify, we know that it always works if your browser window is actually small. What we're looking for here is to make sure that the code does not mistakenly put you into "small site" mode when your browser is at least 1100px wide.

UPDATE: Test is over! All seems well. Thanks for your help!
33 comments |   Oct 27 2010 4:02pm

Google ad clicks and ajax searches

Out of nowhere, everyone has been clambering for us to add support for google.com/aclk referrers. Something must have changed on Google's end recently because these didn't used to be that common but they are now. Many people have told us that the original search is included in the referrer string and sent us examples. So we finally just added support for this. However, based on our limited testing, when clicking on ads on google.com we don't see the "q" variable (that contains the search) in the string. So, we're guessing it's only there sometimes. What would cause it to be there or not is beyond us. Anyways, if the "q" variable is there, the search will now be displayed, and either way, the visitor will always be classified as "advertising" now.

Also, a few months ago, we wrote a post about Google and Ajax searches. We said when we saw these referrers we were just going to ignore them, because otherwise they showed up as normal "links" from google.com and that was causing confusion - but you all hated that idea, so we disabled it. We've just updated it now so that it will no longer show up in your links report, and the visitor will be classified as a "search" in traffic sources. And the referrer will be manually changed to "google.com/search" with no query in your visitors report. We wanted to add some link to click on to explain why the search was blank but decided against that.

And finally, we're frantically working to fix some outstanding bugs with the new Clicky that we were unable to fix last week because of travel plans, including the "small site" bug. We'll keep you updated.

Update: Some of you may see some [unknown] searches from Google. This was a bug when we first uploaded the new code but was fixed within about 20 minutes.
11 comments |   Oct 27 2010 12:39pm

Reasoning and motivation for change

Hi. Regarding our new interface. We've been blogging and tweeting about it and had it publicly available to all users for over a month, because we value your feedback and we care about you. If you care about Clicky, we feel it is your responsibility to monitor these communication channels that we use on a very regular basis. We are very open and transparent about everything we do. Some would say too transparent, although I would disagree.

During the beta period, we had many thousands of people use it and the vast majority of the feedback was very positive. Just go look at the old blog posts yourself to see the comments people were leaving. The only consistent complaint we got was that it's not centered, but otherwise most people loved it. Based on that much feedback from that many people, we knew we were going in the right direction.

I have a theory regarding why the beta testers were so much more positive compared to the comments that have been left here. If you're willing to test beta software, you are open to change already. You know things will be new and different and hence you will more accepting of them, especially because the old Clicky was still available. But even with thousands of testers, I would guess that only 5-10% of our users at the very most saw the beta. The rest of you had no idea it was coming, so it was a shock. But again, we tried to be as open about this as possible and got a ton of feedback before making it live. (So please, if you're not already, subscribe to our blog or follow us on Twitter).

People are resistant to change. If it ain't broke, don't fix it. Well, Clicky wasn't "broken" per se, but it was starting to feel dated. Sexy competitors like Chartbeat and Woopra have popped up and while we feel that our product is much more feature complete than either of them, people rave about their interfaces all the time. We get plenty of compliments on our (old) interface too, because of its simplicity and ease of use, but the difference is that Clicky felt like a web site, while the others feel like web apps. (And in the case of Woopra, it is literally a desktop app, although they offer a web version now as well).

We wanted to feel like an app too. It's the way the web is moving and we were feeling left out. Hence, the navigational changes - fixed sidebar navigation, everything loading via Ajax, page loading animations, auto-updating reports, etc.

This isn't change just for the sake of change. The new Clicky has been floating around in my head for close to a year, but I wasn't sure exactly what I wanted it to do. Over the summer my vision became clear and in mid-August I decided it was time to act. Two months later, here we are. This is the longest I've ever spent on developing a new "feature" for Clicky. I'm very proud of it, but that makes the negative comments hurt that much more.

Please give the new Clicky a chance to grow on you. I promise that it will for most of you, once the initial shock wears off. I'm a huge believer in UI and UX, and believe this is one of the major reasons for our success. I'd like to think I know what I'm doing, so please place your trust in me to deliver you the best analytics experience possible.

One last thing. Please keep your criticisms constructive. If you don't like, don't just say "it sucks". That doesn't help. Tell us specifically why you don't like it. We will adjust things based on your feedback over the coming weeks and months. We are listening to what you have to say.
73 comments |   Oct 17 2010 10:05am

The New Clicky

After nearly 2 months of development, the new Clicky is now live. Here's what it looks like:




If you haven't been following our blog, we've had a public beta of our new interface available since September 16. (Hint: this is a good reason to read our blog. We announce important things on it!). The vast majority of the feedback has been very positive, which is remarkable for such a big change.

This is still the same Clicky you know and love, the main difference is the navigation. The goal here was to make it faster to get to other pages, and to load them faster too. We also wanted the entire site to feel like a true "app" instead of just a web site.

So, we created a fixed sidebar that stays with you as you scroll up and down the page (as long as your browser window is at least ~700px tall), and literally everything loads via Ajax, including form submissions (unless you're using Internet Explorer, which has WAY too many problems to support this functionality). However, this new interface is a bit wider than the standard 1024 that most sites aim for. So if we detect that your browser window is less than 1100px wide, the sidebar moves back to the top of the window so it works fairly similar to the old design with the tabs on top. The tabs aren't quite as stylized as they used to be, because we have more of them now so we need to conserve space:




Update: Some users are experiencing bugs with "small site" mode being enabled even when their browser window is plenty big. We've temporarily disabled this until we get it figured out.

To learn more about everything that's new, please read the previous posts we've made about the beta:

Sep 16: Help test the new Clicky beta
Sep 21: Beta updates
Sep 24: More beta updates

If you've been following the beta this whole time, here's what has changed since the last release:

  • Aforementioned 1024 support
  • We detect mouse movement now and keep track of the last time you were active, so if you were away and then come back to Clicky, whatever report you are viewing will automatically refresh so that it's up to date with live data. This only happens if you're viewing reports for "today" though.
  • When a page would load via Ajax, we used to replace the entire "main" area with a loading graphic. We found it somewhat annoying to have everything be blank essentially until the next page loaded, so instead we now overlay a semi-transparent box over the entire area so you can still see stuff (but not click anything), and the loading graphic is now fixed in the top right corner of the page (so if you scroll up and down while a page is loading, it's always visible).
  • We investigated replacing the flash graphs with a native javascript solution, spent almost a week on it in fact, but none of the libraries are quite there yet. They all have at least one super annoying limitation or bug, typically having to do with tooltips or the axis/grid. We tried highcharts, flot, and dygraphs. We also looked at other options like raphael, but none of then had the functionality we needed. I'll probably write a blog post in the future about the state of javascript graphing, but that's for another time. So for now, we're staying with flash.
  • Spy fixed for MSIE (turned out to be some weird conflict with jQuery 1.4.2, so we've gone back to 1.4.1. 1.4.3 just came out today but the problem remains. We'll have to dig deeper).
  • The biggest complaint we have received is that it's no longer centered. We played around with this quite a bit but ultimately were not satisfied with how it looked centered with a sidebar. Even with a fairly big screen (mine is 1900px wide), I still think it looks good. Just give it a chance to grow on you, ok?


We've had an average of 1,000 people using this every day, even without posting any updates for a couple of weeks. So we know people are loving it, but we also know that we have almost 200,000 users so a lot of you haven't seen it yet. If there's something you don't like about it, please read through the previous posts linked above. There has been a lot of discussion between us and our beta testers about why things work a certain way or the reasoning behind certain design decisions.

But based on the feedback so far, we know that most of you will appreciate the changes we made.

Oh, and if you're a white label customer - it will be about another month before this change is pushed to the white label. This is because there are a number of changes to our layout and CSS, and we want to give you a chance to update everything you need to before it goes live. We'll be emailing you soon with more details.
82 comments |   Oct 16 2010 3:28pm

Advice on moving to the cloud?

From day 1 we've managed our own physical servers. We buy them and build them and configure Linux on them and throw them in the data center ourselves. This allows us to configure things exactly as needed, and is quite cost efficient. But man are we getting sick of it. So much time is spent dealing with servers!

People have often asked us why we don't use a cloud environment, such as Amazon. There's two main reasons. First of all, bandwidth - our load balancers are pumping almost 4,000 requests per second through them during peak hours, and a total of about 250,000,000 requests per day (which is almost 300GB of data - per day). Last I checked, Amazon only includes 5,000,000 requests per month, and you have to pay overages for extra. I don't know what the overage price is but considering we'll be over our limit 30 minutes into any given month, this is a big concern.

The second reason is reliability. Cloud servers are not really guaranteed from what I understand and they can pop offline at any time. This is a very big deal when it comes to large database being stored on this type of service. Some of our database servers have over 300GB of data, although the average is closer to 100GB. And we have almost 40 database servers. If our databases were in a cloud environment and one of them popped offline, it's going to need repairs done on it before coming back online, since it would not have been shut down properly. Not something I want to deal with.

So... do any of you have experience running high bandwidth services in a cloud environment? Doesn't have to be Amazon. If so, how do you find the pricing? Also, any experience with running a large database in the cloud? How have you found the reliability? Any advice from people with experience with either of these scenarios is much appreciated.

We're not necessarily going to do this. It's just under consideration. We just want some input first!

Update: The overall consensus is that we're insane to consider this, so it's unlikely to happen. It was just an option we were thinking about. Thanks for your advice.

One thing I was thinking about is what if someone like Google decided to move to a hosted cloud environment. Obviously they're 10000x bigger than us but still - that'd be insane right? To run a high bandwidth and huge I/O service, you need to go old school.
46 comments |   Oct 07 2010 9:23pm

Next Page »




Copyright © 2018, Roxr Software Ltd     Blog home   |   Clicky home   |   RSS