Pressure-Testing Google Sites
This week we wrapped up a session in Detroit working with New Paradigm, IBM and an automotive client to help put together Enterprise 2.0 enabled solutions for their enterprise and partners. Leading up to the session, there was a good deal of thought back and forth as to which tools we should use to put together the session deliverables.
About two weeks ago, Google announced the very timely release of Google Sites, the long-awaited retooling of JotSpot as a part of their Google Apps suite. The timing seemed perfect, and I could think of no better time to give the tool a test drive. The results? Well after two days of building the session journal real-time with 30 participants logging in as we built, all during a North America-wide disruption in the Capgemini network, I can say that there were some stressful times, but the results have been positive. I say that, however, with a considerable number of caveats. I thought it would be useful to capture some of the frustrations, highlights and tips here…
Selling Points:
Ease and Access: It was asked by one of the session participants, “Why didn’t you just put this up in SharePoint?” That brings up the first two great things about Google Sites. First, to set up a shared site to allow for collaboration, file sharing and wiki publishing for 50 people from five companies and a group of outside contractors would be a nightmare to set up. Second, how could those relationships and continued collaboration continue on outside the firewall? It took 10 minutes and cost $10 to get the site up and running, and participants from the session have been able to sign in from where ever they are, no matter which company they came from.
Visibility, Tracking and Feedback: Too often we’ve handed over web journals on CDs and wondered, “Does anyone actually look at it?” “What do they use it for?” Google Sites gives you some visibility in site usage, seeing who logged in and when. But better than that, because it’s built as a wiki style site, it’s not so much what they look at that shows up, but what people add and change. While we were building the site, you could see comments popping up with feedback, and new pages appearing with additional content and ideas from the session participants. This leads to…
The Living Document: They’ve done a great job of making this very easy to use. Pages all have a clear “Edit Page” button, which makes it easy for anyone to get in a update things, or add their two cents. The wiki pages are all automatically versioned, with the option to revert to past iterations. The result is a living document. I can’t say this enough: this was very cool to use in a workshop setting. Assignments could all be pushed via the site, participants could view materials, captured outputs and make notes in the site in real-time. Conversations during the session like “Oh, I have a presentation I should show you guys…” resulted in materials being posted for everyone’s benefit after the session.
File Sharing and Embedding: Google’s finally made it possible to share more than just PowerPoints, Docs and Excels…you can attach just about anything, though there are, for now, size restrictions (10MB per file). What’s even cooler is that documents uploaded to Google Docs can be embedded in pages, so that right in the page, you can leaf through a slide deck that’s inline with the page text. YouTube videos are a cinch to integrate, though for any video you don’t want to publish on YouTube, it gets a little trickier.
And the Shortcomings…
Sharing: Yeah, believe it or not, sharing becomes a nightmare. There seem to be some bugs in the sharing function, which only allow you to select 30 users at a time to share a document with, which must be done on a document by document basis. This means that, say, you have 60 users and 10 documents, you need to go through and click individual names on a user list twice for each document, making a long an laborious process. Once you’ve shared all your documents…well, that’s when a new user gets created and you realize you need to go back and share each and every document with that new user, as well. There’s no way of grouping users or documents for doing batches of “share all of these documents with all of these people”. There would also be mysterious sharing problems, where documents shared with everyone wouldn’t be available to some people, especially with attachments within Site pages. Same goes with the “share with everyone” option, which apparently doesn’t actually share with everyone. Hmph…obviously some issues Google needs to work out here.
Speed: Using this requires a fast, stable connection. As more content ends up on the site, people start uploading and downloading more, and it can be painful if the connection is slow. We ended up having a North America wide bandwidth squeeze which hit during the session and our post day, which meant we did part of our post work in a local Starbucks to use their network connection. This was not a Google problem, per se, but was an issue given the circumstances.
Backups: Where is all this stuff? Maybe it’s old fashioned to want a backup or an archive somewhere as opposed to having your data split across a distributed cloud of data centers, but some found it disconcerting not to be able to pull down a consolidated archive of the site. Being able to download it all to a .zip would make people feel better about it, but there’s no option to do that right now.
Google Apps Integration: What’s important to note is that the wiki functionality of Google Sites came in by acquisition, which is evident in the less-than-perfect integration of sites with the rest of the apps, such as docs. We found a very cool feature wherein powerpoint shows, if uploaded to Google Docs, could be embedded directly into one of the wiki pages, and you could cycle through the slides without opening a document. The trouble is, to get it there, you need to open Docs separately, go in and find a little url that you go back and cut-and-paste in; a monotonous and seemingly pointless process which is obviously a workaround until they can fully integrate the products. Also, if the embedded document isn’t shared with everyone, people visiting the page just see an embedded “page cannot be displayed” page…which makes me wonder, if I embedded it in the page, why wouldn’t I want people who have access to the page to see the document?
Look and Feel: To many, the number of options you have in customizing the look of the page is a serious limitation. There are only so many colors to choose from, you can only put the logo in certain places and you don’t have a heck of a lot of font control, particularly in the sidebar. Frankly, I find the functionality far outweighs the shortcomings here, but it’s worth noting that the options on the look and feel are considerably less than if you coded a site in Dreamweaver…though I guess that’s obvious.
These are my first thoughts on the tool…I am planning on putting up two other posts on this; one, a more technical post talking about what we thought up in terms of structure and how it was used in the delivery of the session, and the other a more broad look at how the use of this kind of tool impacted our interaction with the client. Stay tuned…
Hey Aaron,
Thank you for sharing your experience with this. I’m very interested in how it impacted the session. My fear would be that it would put people in front of a computer instead of the white wall and each other. But also if it was a kiosk in the corner that functioned as an information repository, then that is another story…
Another thing might be a tech gap of the participants. Everyone can write (hopefully) not everyone has confidence with a computer. It could be seen as a barrier…
I guess it depends on the client…
Carry on, it’s awesome.
Wyn
I would love to look at it.
Hey Wyn,
You’re exactly right on both points…there is a very real danger that people could disengage and focus solely on the computer. That said, in this case, we found that people were still using the whiteboards, because, at the end of the day, they’re much more fit for the purpose of getting out ideas in a group than a computer; the need dictated the tools.
Another interesting point on this; we would have liked to have flatscreens in the breakouts attached to the laptops (there was one computer per breakout) but in retrospect, the presence of a larger screen probably would have encouraged exactly the same passive, disengaged behavior you’re talking about…so again, it worked out well in that regard.
Finally, what was interesting was that the people who object the loudest about writing out their work on tiles were more than happy to iterate it into the wiki, and many groups took side notes in the wiki as well…it was a good case of offering a variety of tools to accommodate different working and learning styles.
Your point about tech savvy-ness is also bang on; in this case the group were all in IT, and thus took to it very naturally. I found myself wondering how it would be for others who were less technologically inclined. A lot of discretion would be needed in this regard, though, in the context of a session like this, which was focused on web 2.0 technologies, even a less tech savvy crowd could use it as a chance to become familiarized with the tools.
I think the trick is to offer it as a supplement rather than a replacement of hypertiles and printed wallshots, etc, during the event. It’s a huge advantage having them get familiar with their journal before the event is even over, but that shouldn’t blind us to the objective of having an intuitive environment that’s quick and easy to work in.