Posts tagged ‘presence maps’

MSG Netvibes widget update

I’ve just updated the MSG Netvibes widget to include a link to the MSG Presence maps page so you can launch the map without having to go through the MSG client first.

Preparing for launch…

Have been pretty busy last couple of weeks (hence no postings) and had few days off work here and there too! Much of my time has just been getting MSG ready and installed on our acceptance test servers, ready for the launch of MSG Presence Maps on LabSpace and LearningSpace on 17th May. All seems to be running fine now after a bit of fiddling around.

Have now started to think what we do to get more information into MSG from users’ OpenLearn profiles and what would be the most relevant infomation to show to try and get people chatting to each other. One of the problems I think we’re having with people not using MSG that much is because it’s essentially just a list of names, there’s no way of knowing about that person & whether they’re ‘worth'(!) chatting to or not. So … my thoughts on the aspects we could include…

  1. biography info – getting the info/biography info users can enter in Moodle
  2. courses in common – using the fact that you are enrolled on the same, say, 5 courses as user X means you’re more likely to want to chat with them than someone who only has one course enrolment in common with you?
  3. forum/learning journal postings – finding the number and ratings of other users forums postings to discover their reputation, eg if their forums posting are rated highly you are more likely to want to chat to them?
  4. photos – just grab users photo (if they’ve submitted one) from Moodle to show within MSG.

Much of this is guesswork and supposition, until we give it a go we’re not really likely to know what’s going to work. These are based on what may be currently available form the OpenLearn system (rather than things we’d need to first build into Moodle). Also, still not sure whether to just focus on a subset of these or all would be needed to create a useful system.

Any thoughts/comments/suggestions welcome as to whether including and or all of these would be good (or bad!) – or if I’ve missed anything I ought to include 🙂

Maps going live…

We’ve now fixed when the maps will be available on the LabSpace site – they’re going to be ready made live for the end of April – barring any hiccups! Also the MSG block along with the other KMi tools (Knowledge Mapping & FlashMeeting) are going to be added to the LearningSpace website in the coming couple of months. This is really good news for us as it means the MSG block should get a lot more visibility and hence usage – this will include the maps developments that I’ve been doing too.

I’ve created a short video (screencast) of how to use the MSG presence maps and the functionality provided, at the momnet it’s still a large .avi file so once I’ve got it compressed to a reasonable size/quality I’ll post a link up 🙂

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 msg.open.ac.uk server (and not msg-openlearn.open.ac.uk, 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);
pstmt.setDouble(1,51.2);

I’m using:

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

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!

Maps… sneak preview…

Here’s a screenshot of where I’ve got to with the maps….

You can see the green and grey markers on the map, signifying where users are on or offline. The balloon shows all the users located at one of the markers, and gives a link to chat to those who are online.