Last summer I blogged about amplified events and using this blog for engagement, which is a topic I returned to for the recent Web 2.0 guidelines crowdsourcing experiment.  I've not had an opportunity until lately to try putting together an amplified event, but this has now presented itself in the form of the first Google Apps for Education UK User Group meeting.  We're hosting this at Loughborough's Holywell Park Conference Centre next month, back to back with the UCISA Cloud Computing Seminar.

Holywell Park Conference Centre at Loughborough

We have been very successful with our Google Apps domain for students and alumni, which now has over 12,000 regular users of Google Docs, out of our ~18,000 undergraduates and taught course postgraduates - and near ubiquitous usage of Google Mail and Calendar.  This year we will be looking at the potential of the Google tools for staff, where the key questions are around topics such as external collaboration.  I've already had some interesting discussions with academics about using the Google tools for collaborative projects and online surveys.  It's clear that there is also a lot of potential where workshops and conferences are concerned.

So what tricks and techniques can we learn from experienced practitioners such as the IWMW and JISC CETIS folk?  Here are a few that immediately leapt out at me...

• Choose a memorable hash tag for the event - checking that it's not already in widespread use.  In this case I have chosen #guug11, which isn't short for anything specific but resonates nicely.
• Pick an out-of-band communication channel for people to discuss event related stuff.  Right now Twitter is the clear choice for this.
• Use Web 2.0 tools and techniques to ensure that the event website is dynamic and largely "looks after itself", rather than being just a static set of pages reliant on the organizer to update.  Some techniques that I have used for the Google event are detailed below.

I will also look at some of the nuances and wrinkles associated with this approach, as there are some pitfalls and traps for the unwary.

Web 2.0 Widgetry

The website for the Google event is hosted on Google Sites, under our nascent staff Google Apps domain.  Google Sites is a very nice tool in itself, making it trivial to construct impressive websites and pull in live content from elsewhere in the Google ecosystem.

On the site, we have an embedded YouTube video produced by our conference spin-off company imago showing off the venue and also giving delegates an opportunity to familiarise themselves with it from a distance:

We also have the obligatory Google Map showing the key points of interest for the venue.  I have used the "My Maps" feature to create a custom map with key points of interest highlighted:

View #guug11 map in a larger map

In quite prosaic terms the venue photo shown at the top of this post also helps to familiarise delegates with the venue - in the sense that "you'll know it when you see it", as the building and its setting are quite distinctive.  Nothing Web 2.0 about that, of course :-)

A Twitter widget on the site's front page shows the most recent conversations about the event, and also surreptitiously promotes the Twitter back channel:

Tweets with this hash tag are being archived by TwapperKeeper (see Brian Kelly's post about JISC's support for TwapperKeeper). Without this extra step, they would disappear from Twitter after a few days, and no longer be searchable via the #guug11 hash tag.  [As an aside, it's interesting to consider the persistence/permanence of Web 2.0 services and content in the context of the US Government's Wikileaks Twitter Subpoena]

Dipity is being used to produce a timeline view of Twitter discussions about the event:

guug11 on Dipity.

People who chose to appear on the publicly viewable list of delegates have their details automatically extracted via a Google Docs spreadsheet, as shown below (hit reload if you just see "#VALUE!" here - it doesn't always work first time).  The actual event registration is done via a Google Docs form which feeds into a private spreadsheet, as discussed in the final section of this post.

More information from the registration form is used to populate several further spreadsheets of "hot topics", including a word cloud:

A breakdown of delegates' affiliation (HE, FE etc) is constructed automatically:

As is the status of Google Apps at delegates' organizations:

And a breakdown of who is aiming to stay overnight (and interested in meeting up) on the evening before and/or the evening after the event:

The Google Docs spreadsheet magic for this consists of formulae such as

=countif(importrange("tOKXCOkzDzXiRk241EWPu3Q", "Sheet1!M2:M999"), A2)

This tries to total the cells in column "M" from the Google Docs spreadsheet with ID "tOKXCOkzDzXiRk241EWPu3Q" where the cell value is equal to the value of cell A2 in the current spreadsheet, e.g. cell A2 might be "Night of 14th Feb".  The key point to note here is that a publicly viewable spreadsheet is generated from a subset of the data in a private spreadsheet.  As Tony Hirst notes, Google's Visualization API effectively lets you carry out SQL queries using Google Docs spreadsheets as your underlying database.

Finally, it should be noted that all of the above content apart from the Twitter widget is actually embedded "live" into this blog post, rather than being snapshots of the data on the website.  And in the spirit of open data, the underlying Google Docs spreadsheets derived from the registration data (but not the full registration data itself!) are available as a tab on the embedded material above.

What's Next?

Other more or less Web 2.0 techniques that we may try out, depending on the level of interest and time available:

• Live blogging, perhaps through a specialist such as Kirsty Pitkin
• Twitterwall showing postings using the #guug11 hash tag
• Augmenting the site with Vox-pops using handheld cameras
• Live streaming and/or lecture capture of the sessions using Echo 360 and/or Opencast Matterhorn

However, there is a break even point where the amount of effort involved exceeds the benefits - what I've outlined above only had to be done once, after all.  It's not clear to me yet whether this will be a big event with dozens of attendees, or a small but perfectly formed one.  So we'll see about that other stuff :-)

The "Eating Your Own Dogfood" Bit

Whilst Google are providing an excellent set of tools at a bargain price (== free for educational use!), there are inevitably some areas where the cracks show.  I'll outline them here for the benefit of anyone else trying to follow a similar approach - but do be sure to check the datestamp on this post before leaping to any conclusions, as that this is an area that is changing rapidly.  I expect that most if not all of the points that follow will be addressed in the next few months.

So, here goes...

For many purposes we would want to associate a Google Sites website with a "vanity" domain name - this doesn't seem to be possible at present, although you can root your instance of Google Sites under an institutional domain name such as sites.lboro.ac.uk.  I have cheated and created a virtual host on one of our web servers for http://guug11.lboro.ac.uk, that redirects to the Google Sites service.

If you enable SSL for your domain to protect session cookies from sniffers, then it's not possible to use an institutional domain name for your instance of Google Sites, Docs, Calendar etc.  Ideally you would be able to upload your own SSL certificate or buy one through Google, then add the appropriate A records or CNAMEs to your DNS for the Google hosts - as with the unencrypted version of the service.

Enabling SSL is a global setting which is inherited by other services.  Consequently all web content served up by Google Sites will be done via SSL.  For Internet Explorer users (there are still some around) this is likely to result in a warning message about a page which contains a mixture of encrypted and unencrypted content, e.g. embedded Twitter widgets.

Unfortunately the Internet Explorer problem applies to the embedding HTML code generated by Google's own tools, e.g. YouTube video and Google Docs spreadsheets. In some cases the underlying Google service is accessible via SSL simply by changing the URL in the embed code, but this doesn't always apply.

The Google Docs form tool is a truly brilliant creation, but people often want to embed a subset of the form submissions - e.g. in our case we would like to omit responses containing personal information such as email addresses and phone numbers. As described above, it's possible to create a new spreadsheet that includes a subset of the data from an existing one, essentially replicating the summary stats normally gathered by the form. But, the mechanism for doing this is not obvious and it is tricky to get right.

When creating visualizations of spreadsheet data for embedding into web pages etc, one has the option of creating a Google Gadget, but this uses JavaScript and hence is not permissable in Google Sites. However, the visualization chart can be created as a sheet in the Google Docs spreadsheet, the spreadsheet published as public content, and embed code fetched from its sharing options.

Finally, and particularly around the areas of events, online journals, project collaboration etc - it's great that you can share the likes of forms, documents, calendars and websites - and that there are a range of options for sharing them. However, a Google Account (seemingly with a Gmail address associated with it) is required for any sign-in based sharing. Hopefully we will be able to use OpenIDs for sharing soon too, although as Byrne Reese notes, we may need email address based Open IDs for this to really work.

These minor gripes aside, I'm very pleased with the #guug11 amplification project so far.  I'll report back  after the event on how it all worked out...