Archive for March 2007

User search for MSG

I’ve written an extra service to search for users in MSG and implemented an interface for it on the MSG presence maps. All seems to be working quite well, it will search on the user name or jid and clicked on a returned result will pan the map to the marker for that user and show the information balloon for that marker.

The service will also return users for whom we don’t hold lcoation information (in which case the map would be unable to pan) – as I wanted the search to be generic for MSG, rather than only for use with the maps.

I hope to have this implemented on the server sometime in the next day or so, so you can try it out and let me know what you think 😉

Embedding MSG maps in LabSpace – more thoughts

Been thinking more about what to ‘do’ about embedding Google maps into the MSG block in LabSpace and what should be shown depending on whether the user is currently logged in to LabSpace. Now we’re thinking that the map should be displayed whether or not the user is logged in and it should display markers for all of the currently logged in users.

As these users might not be in your contacts list we’d only be able to display the location, no presence, name or any other information – so we’d need to use another colour marker (I think) to indicate their presence/personal details are unavailable to you.

The only difference (in the block map) between logged in and not logged in users, would be the fact that logged in users would have a link out to their ‘real’ presence map. This does seem to be quite restrictive for logged in users (as we do actually have the other data that’s displayed on the actual presence map) but I’m wary about making the LabSpace page too JavaScript heavy – which would be required to make the map embedded in the block monitor all the users/presence changes.

Any other suggestions/possibilities welcome as to how the embedded maps should function for logged in vs logged out users 😉

Embedding MSG maps in LabSpace Moodle

Fixed quite a few little bugs and other things we needed to get sorted out this week, for example transferring the Moodle MSG block so that it uses the MSG API that we’ve developed. That required a few changes to be made to how the API worked – though only additions rather than changing how it worked originally.

We also released the latest version of the MSGAlert tool (v2.1 – more info) which now includes a link to the MSG presence map. Currently this is only available for the server (and not, but that’s coming soon). Marc has been demonstrating (amongst other things!) our MSG maps implementation as the EleGI project review meeting this week. This gives a good cohort of users from across Europe to test out the maps and find if there are other remaining bugs or things we could improve.

This morning I also started to look at embedding the maps within the Moodle MSG block, my thinking at the moment is to put a very small Goolge map with in the block (if you are logged in) and the map would centre on your location and put a marker there of you online, but then to view all the other users you would need to click on a link (or on the map) to launch the full MSG presence map. So somthing like…

In fact this is already up and working on my development server. Just not sure that the map isn’t a little too big? Another quesion I’ve got is what to do when users aren’t logged in? I want to show somthing of the map – to try and “entice” people to sign in, rather than just a text link or nothing at all. Maybe it should show a short demo video of how to use the maps – something which I ought to produce anyway? Any other suggestions gratefully received 😉

In case you are wondering, I’m not planning on having all the users contacts displayed on the embedded block map, users will have to go to the actual MSG Presence Map page for this. The reason being that it’s potentially to heavy to have all this javascript going on in the background all the time, especially when there may be other block and content doing JavaScript ‘stuff’ too.

Floating point hell…!

I updated the map grids so they are divided equally, and all appears to be working in that the markers divided and combined in an expected way. However I did find there were quite a few little bugs etc with the reclustering algorithm which were all related to floating points and the number of decimal places.

The problems appear to be due to rounding errors when I’m storing the coordinates in the database. For example, when I think I’m storing say “51.2”, actually “51.2000000000001” gets stored in the database, so then when I look up all the points matching 51.2 the database doesn’t return anything!

I have found a way around this, though I’m not sure how much of a hack it is! The solution seemed to be to treat the coordinates as strings when adding them to the prepared statement for updating and querying on. So instead of using:

String sql ="SELECT * FROM mytable WHERE lat = ?";
Connection conn = conn.getConnection();
PreparedStatement pstmt = conn.prepareStatement(sql);

I’m using:

String sql ="SELECT * FROM mytable WHERE lat = ?";
Connection conn = conn.getConnection();
PreparedStatement pstmt = conn.prepareStatement(sql);
DecimalFormat f = new DecimalFormat("#.000000000000");

This all appears to be working for storing/retrieving the correct values/records – note that the values are still stored as datatype decimal(18,15). My only concern is that I’ve only tested it against a MySQL database and I’m not sure whether other rdbmss would accept decimals/floats passed in string format.

Another possible solution that was suggested to me was to multiply up the coordinates so they are stored as integers in the database – but as this would be a fairly significant change at this stage (and may introduce more bugs!!), I’ll stick with the solution I’ve implemented for now 😉

Making the maps more efficient

The maps seem to be running much more smoothly now I have tidied up the JavaScript quite a lot and tried to make it more efficient, it seems to run much better now (with around 400 users) than it was previously, when it could fell very sluggish. With only 10s of users it is far quicker than before. Using the firebug plugin to narrow down the bottlenecks really helped. I’ve also added the number of user who are on/off line for each group – as you get with the normal MSG client.

Have now run into another problem with the clustering though. We noticed that sometimes you could get (on a wide view) two different markers displayed, then when you zoom in one level these combine into one, zoom in yet further and they go back to being 2 different points. The reason (I think) is to do with the size of the grids not being exact multiples of each other, so on a wide view the 2 points could be in different grids (hence the 2 markers), then on the next zoom in they’re actually in the same grid square – hence just the one marker. This looks a bit odd as you would imagine the the makers to only divide out as you zoom in (only combining when you zoom out). So the solution will be to have the grids for each zoom levels exact multiples of each other. So I’m looking into this now 😉

Auto seeding of lat/lng

I’ve added a new function to BuddyXML so that users who have never logged in to the maps (or MSG) still get their latitude and longitude recorded in the Wildfire database. Previously only users who had visited the maps page and had confirmed their location who appear as markers on the map. This means that for the first few users, very few people would appear on the map. To get around this I’ve updated the replication script so when a new user is added to Wildfire (during the process which replicates with the Moodle database) the Geonames webservice is called to try and determine their lat/lng based on the town and country entered in Moodle.

This appears to be working quite well, I have a list (anonymised) of the ‘real’ locations users have entered in OpenLearn and have tested seeding the Wildfire database with these and getting their lat/lngs. I know it’s not going to be 100% accurate, for example, if there is more than one result for a given location, then my script will just pick the first one – but users can always update their location when they log in if it’s incorrect.

I tested this by adding a few hundred users to my test courses then logging in to my MSG maps page – it all ran ok-ish (i.e. got the seeded locations for users where possible) but the main problem was the page running really slowly – due to the number of users. So I’m going to need to look again at how to make my javascript more efficient, I found this page which seems to have some good tips and I’m going to get to grips with how Firebug can track bottlenecks in javascript code – I’m assuming that it can!

Future of Web Apps presentations

The mp3s and pdfs of the presentations are up on the FOWA website now: see:

The ones I’m going to be listening to again are: Bradley Horowitz, Tara Hunt, Rasmus Lerdorf, Matthew Ogle & Anil Bawa Cavia, Simon Willison and Werner Vogels.