I think that we are all going to agree that Hotspots 2.0.5 is awesome. In fact Hotspots 2.0 meets the need of 99% of my customers and that makes me really happy. However there is always this 1% that needs more. ( don’t make any analogies with the 99% movement, please! )
Some of you may ask – why do you care about that 1% of your users? The truth is – you never know when you are going to be a 1% user. It can happen today, it can happen tomorrow! The most important thing is to be prepared!
What am I talking about??? Hotspots 2.0 is perfect the way it is! You can get some categories and fill them with some hotspots – job done! Most of you are never going to handle more than 500 hotspots in 1 category. But what happens when you go above that number? The sky will fall down and end of the world is coming! Wow, joking! The only thing that is going to happen is that the application will start to feel sluggish, slow and eventually if you have a lot of hotspots in 1 category the server won’t be able to serve the requests (we don’t want that, do we???)
So, let us first look at the architecture of Hotspots 2.0:
You click on a category and you get all the hotspots in it. If you have 20 Hotspots – then this query is going to be fast, but if you’ve got 500 then it tends to slow down. The returned response has the size of 250kb! If you are on a slow connection – then you will have to wait. Once the browser gets the response it has to interpret it. It will go over all your hotspots, get the location and place them on the map. Google maps api3 is very fast at this! And the new browsers are also very fast at executing javascript. A modern computer can easily handle 1000 hotspots and display them immediately without giving you the feeling that the application is sluggish.
Obviously with this design if we want to improve the speed we can do a very simple trick – reduce the response size! I’ve already done this and the next version of Hotspots will feel really fast because of this.
Now if you want to go beyond the 1000 hotspots limit, then we need other techniques. One of those is a clusterer. Here is a little bit more information about what a clusterer is and different ways to implement them in javascript: http://code.google.com/apis/maps/articles/toomanymarkers.html
If you are not too careful when you look at the above documentation you could think that clustering is a very easy thing to do! You have already js libraries for this! Add 1 line of code and you are ready to go! Well, not exactly! The js marker clusterer may work for 2000 till 5000 markers, but this it won’t work with 10000 or 100 000 or 1 000 000… You cannot send all this data to the user... If you do send all this data, then the user’s browser is simply going to crash. So, we need better solutions! We need a marker clusterer that works on the server, does the calculations and just sends a small amount of the data for the display to the client.
So, I’ve implemented a php clusterer (the one explained in this book ) but I’m not happy with the result. That is why the title of this blog is “Every problem has the right solution” and I have the feeling that clustering might not be the right solution for Hotspots. Don’t get me wrong – I want to be able to handle 1 million markers, but clusters the way we see them implemented on websites doesn’t seem to be the right thing for us. Hotspots is all about showing locations – single locations! So???
You can of course merge several single locations to one big clusterer, but what do you do with the single locations in the menu? On the map you have only clusterers and in the menu you have single hotspots. Ok, we can exclude those single locations from being in the cluster and show them on the map, but then we have situations where – you have a location that falls behind a cluster coordinates. So the clusterer will overlap with the location and this will look ugly!
So, right now I think that clusterers create unnecessary clutter and they don’t seem to be the right tool for the job. Looking at maps.google.com – one can see clearly that google have made a very good decision by not using clusterers. Google is obviously pushing their proprietary thing called fusion tables, but it looks much better than a clusterer. (even at a higher zoom you see clickable locations and not just a spot indicating a lot of locations)
Other map apps have gone a different road – they just show 10 locations at once. Obviously – you have to be very patient if you want to see everything on the map. Generally the trend is:
- 1.figure out the user’s location
- 2.Show him few hotspots in his viewport and let him navigate through the locations.
To be honest I think that this is going to be a much better approach for us than clusterers. I’m currently playing with a code that figures out your location and shows you 10 hotspots with the category icon. Then a second requests take place in the background and we get some more hotspots – maximum 1000 and we put them on the map with just small dots. Obviously this is also not the best solution – if the user zooms out, then he is going to see far less locations on the map as there are in the database (but here in the right menu he will always see a number indicating how many hotspots we have in the current viewport). But is this that big of a problem? We use hotspots to show locations in our city, country… So the user will spend most of his time in a zoomed in position, right?
I know that neither of the approaches is best, but I want to go the road that makes most sense for Hotspots. I cannot make everyone happy, unfortunately…
Happy to hear your opinions!
