Google Sites 3: Using Google Sites to Simplify Processes

I had a lively conversation recently with Karol Markosky (part of which I discussed in the last post). She works at the Council of Senior Centers and Services of New York City (CSCS) and attended a presentation I did last May at NPower NY: “Could a Wiki Help Your Organization?” In the interim she has helped structure and launch various wikis for the small non-profit she works for. She showed me one of them.

Coordinating a Cross-Agency Project
She herself runs the HIV Older Adults Initiative and partners with a number of different organizations. They needed a more seamless way to communicate: 1) to track the trainings that her program coordinates; 2) to track the program goal of covering each of NYC’s 51 City Council districts each year and 3) to share up-to-date training materials and a calendar.

Using Google Sites "Pages"
After looking at a few different wiki platforms, Karol played around with Google Sites. As she did it became clear how she might simplify her work by using some of the types of pages Google Sites offers.

As noted a few posts ago, the blank page of a wiki offers a lot of flexibility, but not always a lot of functionality and structure, or direction for the user.

While other wikis offer page templates when you create a page (for example PBWiki and Socialtext), Google Sites has gone a step further. When you click “Create New Page,” it offers, what I would call, different "types" of page.

(Note: Click on images for a full screen view.)

Using a "List" Page
To fulfill the goal of covering each of NYC’s 51 City Council districts, Karol wanted an easy way to assess which council districts had already had trainings.

This is what she came up with:

Now at a glance Karol can answer such questions as “Are we a ¼ of the way done?”

How’d she do it?

She chose to create a custom list page but she also could have chosen one of the three list page templates that Google offers.

1. Action Items—“Keep track of action items from a project or meeting”
   
2. Issue List—“Track your project’s open issues”
3. Unit Status—“Track the status of individual units in your project”
   

Participants who have been added to the site as a “collaborator” or “owner” can add to and edit the list (“viewers” can simply look at it) via a simple dialogue box that pops up when you either “Add item” or click a pre-existing item to edit it. Agency partners have the responsibility to add the information as the trainings happen.

Using the "File Cabinet"


So that the project could get away from the often confusing practice of repeatedly emailing the latest version of updated paperwork such as registration forms, case studies, and other training materials, Karol used Google Site’s File Cabinet page which allows you to upload documents into folders and supports version control.


Embedding Google Docs and Calendar
When creating a page in Google Sites, if you don’t pick one of the preformatted types of pages such as a List page, or a File Cabinet page and simply pick the “webpage” (a blank wiki page), one of the things you can do is embed Google Documents and calendars in it. Karol took great advantage of this and embedded a Google Form.

Here’s why she used a form:

In their work of setting up trainings there was a “massive data collection issue.”

• Each person used to send an email to the master spreadsheet holder
• ...with information on the over 20 fields to keep track of
  
• The master spreadsheet holder would manually enter the data
• ...and then the spreadsheet would be sent around via email to be shared.
  

Now the form Karol created allows each person to add their own data and the administrators can download the spreadsheet that is automatically populated with the form data. Here’s a screenshot of the first few fields of the form.


You create the form in Google Docs and then simply hit insert on your Google Sites webpage, and it is embedded.

Blogging on Google Sites
While Karol isn’t using the blog functionality yet on this specific site, you can create as many blogs as you want inside your Google Site. One of the preformatted page types is called “Announcements,” and works exactly like a blog, with dated posts.

Putting it All Together

Finally, here’s the homepage as it stands today.
Karol used one of the “themes” Google offers and then customized it further via “Colors and Fonts” choices. She said, “Data entry is not always happy - you need a happy color.”

Nate Nash of BearingPoint, in one of my favorite case study webinars, talked about the "sheer mechanical advantage" of editing a wiki page as opposed to getting a spreadsheet in an email, downloading it, editing it, and then resending or uploading it.

It's a similar advantage in large organizations like BearingPoint or in smaller organizations like CSCS. Via list pages, a file cabinet, and a centralized, viewable form for data entry, it seems to me CSCS has streamlined some of their daily chores, allowing them to concentrate on delivering services. I'll check in with Karol in some months and see how their wiki experiment has evolved. (And actually, soon I will re-report on their sign-in issues.)

---

More About CSCS’s Google Sites

Business Issues That Gave Rise to Use of Google Sites

• Coordinating many trainings across organizational boundaries
• Initial success with simply sharing a Google Calendar raised the question: “What more could we simplify?”
• Need for a way to deal with constantly re-edited documents—internally and externally- making it easier to find the latest version of a document

Caveats

• Gadgets (widgets) that one can embed are mostly “fluff,” not necessarily appropriate for a business site; “the ones that weren’t fluff were kind of funky”

How have the wiki sites been received?

• “Mix of excitement and what do I do with this?”
• First time Karol sent a link to a form-response “This is very cool—we need to do this.”
• Gradually getting used to it; it usually takes time for a change
• One colleague said, “I check it every day. Once I start setting pieces up, I can’t wait to use it.”

Lessons Learned

• Find a way to back up data you are storing on a free hosted site, in case the worst happens and you lose your data or lose access to your data
  
• Play with each piece of functionality and you’ll get ideas how you might be able to use it: “I played with the List page and an idea formed in my head.”
• Keep it simple so new users won’t be overwhelmed
• Find a way to back up data you are storing on a free hosted site
  

Looking Forward To:

• If, and when, Google adds page permissioning. (Currently users get permissions to view, collaborate, or own the whole site.)

Google Sites 2: A Sign-In Issue

One of the reasons why the ad for Google Sites caught my eye on Google’s home page was that I had just had a conversation with Karol Markosky who had built some wikis on Google Sites. She works at the Council of Senior Centers and Services of New York City (CSCS).

Before we looked at one of her wikis together, she told me a story that has still not come to its conclusion.

Some staff members are having sign-in problems and are unable to access some of the wikis they have created. Their hypothesis is that somehow their domain name cscs-ny.org is “wrapped” into Google Apps. But they had never signed up for Google Apps.

“It’s almost like 2 accounts were created under the same email address and sometimes when you type in your email address you get account A—which will let you sign in-- and sometimes account B—which won’t.”

CSCS has been trying to understand and rectify this for three months--but using a free service with Google (Google Sites) has meant, so far, there is little recourse. (Having never signed up for Google Apps means they do not qualify for the free phone support for "critical issues" that Steve Backman mentions when discussing being blocked from Gmail in one of his posts on the Idealware blog).

Through a colleague of a colleague, they have reached a human at Google, but not a human who knows anything about the issue. CSCS thinks it is possible they will have to abandon a few of the wikis they created since the administrator and the majority of participants cannot access them.

I will update this when I hear more, though if anyone can shed light, please do.

I suppose considering CSCS may have to abandon one of the inaccessible wikis, they are lucky that both for simplicity’s sake and because Google Sites doesn't currently allow page level permissioning, they chose to create a series of wikis for different users and projects, instead of one large wiki.

Google Sites 1: A Wiki is Just a Website

On January 28th I noticed that Google was advertising what I think of as their wiki product, Google Sites, on their homepage at google.com. (It was gone by the 29th.) “New! Get your own website on Google Sites. It’s free and easy.” If you clicked through, here was the screen you got:

The word “wiki” was nowhere in sight.

And, indeed, a hosted wiki is a “free and easy way to create and share webpages.”

I’m not a student of Google but I guess that their brand is about simplifying to drive mass adoption. Perhaps that's a good lesson in how to be very clear and simple when explaining the what and how of collaborative software.

On the other hand, it's likely that Google knows that everyone wants a website and only a small percentage of people are really clamoring for a wiki. Yet, it's the same thing (in many ways) but I don't think I have fully internalized this myself.

Successful Social Software Launches: Marketing vs. IT

I sat in on a good webinar sponsored by social software vendor Jive, maker of Clearspace in December. One of their users, a member of the Business Sales Team at T-Mobile who has been instrumental in setting up and managing a departmental implementation of Clearspace, presented. As I listened to Jenny Moran, Channel Manager, talk about the community they created, MagentaNation, it occurred to me: If marketing people launch and drive adoption of social software, is it on the whole likely to be more successful than if IT people deploy it?

I thought about this because this is what Jenny talked about:

• “Pull not push: “We did not push the site on people or force trainings”

• “Building excitement:” such as a very brief launch call, involving managers, and launching “exclusive” content here first

• “Maintaining excitement” by engaging users, for example, by posting videos and allowing anyone to post videos, by showing users how to make their own customized dashboard…

• “For the people, by the people:” a phrase she used more than once meaning that users helped design MagentaNation, seed it with content, and will continue to be actively consulted about usage.

All of this was marketing language, and more importantly was indicative of thinking about people’s behavior.

And driving adoption is all about thinking about behavior.

When I talked to Jenny in person and suggested that a marketing social software deployment might be more successful than an IT one, she seemed to agree but articulated it a bit differently. She felt that because Business Sales Support approached it from the user perspective, not the IT perspective, they were more flexible and they "let the community create itself." This is, I suppose, the number one marketing principle: “Give the customer what they want.”

It turns out that there is some data about user satisfaction with implementations by business (referred to below as LoB-Line of Business) users vs. IT implementations. Ross Mayfield of Socialtext recently posted this:

“According to this year's McKinsey survey on Building the Web 2.0 Enterprise, IT-driven implementations had 60% user dissatisfaction, whereas LoB-driven had 74% satisfaction."

---

About MagentaNation

Business issues that gave rise to creation of MagentaNation:

• Dissatisfaction in Business Sales with non-relevant content being pushed at them
• Lack of connection with other Business Sales members
• Need for vehicle for continuous learning and sharing of best practices

How the community created itself:

1. T-Mobile had a one month pilot in January ‘08, before they signed a contract, consisting of 15-20 people from different groups and levels in Business Sales Support, using the site and creating content.
   
2. Expanded outwards to 50 people, for a second month-long pilot.
   
3. Then each of those people invited one or two people, so 150-200 people were using the site and creating content.
   
4. In May, they launched to the Business Sales population of 700.
   

Usage statistics (from mid-May launch to beginning of December)

• 46,790 visits
• 275,243 pageviews
• 6+ minutes average time spent on site
• @6 page views per visit
• 97% of the Business Sales group is registered
• Now, over 90% of Business Sales members log on at least once a month
• Stats for 2 random days: Friday: 10 posts, Monday (by 11:30 a.m.): 7 posts

Customizations

• Leadership widget showing picture of leader and latest activity
• Video widget for latest videos posted
• Scrolling ticker with important news

What do the two people who manage the community do?

• Help drive engagement within the community
• Review site content, moderate (rarely have needed to "moderate," occasionally coach users, Jenny repeatedly stressed that the community was for users so moderation with the lightest touch possible was key)
• Help answer questions
• Administrate

How many hours do the managers work on MagentaNation?

• Channel Manager: Approximately 20 hours per week
• Q&A counterpart: Approximately 10-15 hours per week

Looking forward to...

• Live chat, which Jive should release next year
  

For two screenshots of the site, see slides 10 and 11 of the presentation.

What’s the “Best” Wiki?

When I show people my introductory presentation on wikis often the first question I’m asked is. Well, then, what wiki should I get? What’s the “best” wiki?

In the Winter of 2008/9 there is no such thing as the “best” wiki or the “best” "collaborative software suite." Each platform offers different capabilities and appears to have different strengths.

What’s important is to match your organization’s requirements with a platform.

• You could think about what collaborative software capabilities are of most importance to you, and then figure out which platforms have them. I list the most obvious ones in the post before this one.

But there are lots of other things to consider as well, which ultimately may be more important.

• Beyond your tech requirements (which can include simple things like we want a platform that is installed on our server, or more specific issues like programming language, security features) there are dozens of features you’ll want to look at: things like what level of permissioning you need, notification functionality, document versioning, ease of use, quality and type of support, tagging capability, export capability—the list can be very long.

• Wikimatrix is a good place to start to narrow down options. You can perform a customized search on attributes critical to your organization. Just know that not all information on Wikimatrix is up-to-date or accurate—check out particulars on the vendors’ websites. (Potential inaccuracies create the hazard that a wiki might be the right one for you but not show up in your Wikimatrix customized search short list.)

And once you have narrowed your list, it’s important to know that there are key functionality gaps in every product, and they may not be immediately apparent when you just read about the platform.

For example:

• Search is important for every wiki. Test it and try to talk to users to see what they think of that product’s search functionality. Does it return useful results?

• If tables or spreadsheets are important to you, test out that platform’s tables/spreadsheets.

• With repeated use you are likely to find that none of the WYSIWIG editors act exactly as you would like; developers are still working on this. Play with some so you know what you are getting.

• You may also find that notification systems are lacking. Be sure to test these and any other functionality important to you.

The bottom line is before deciding on a platform: test it and try to talk to other users. Then pilot it before signing on the dotted line. (Migrating from one wiki to another, though doable, is often not a pretty picture.)

A Funny Thing Happened on the Way to the Wiki

With this blog, I have finally gotten around to publishing some thoughts about wikis.

And just as I have gotten around to it, the trend is for the wiki-as-wiki to bow out in deference to the "collaboration suite" (platforms that have wikis plus other collaborative or social capability).

The blank page of a wiki offers a lot of flexibility, but not always a lot of functionality and structure, or direction for the user.

So in the past year, as adoption of various forms of social software has accelerated, leading wiki platforms have added greater functionality.

Some vendors have added modules such as social networking or a Twitter-like micro-blogging ability. (In addition to adding social software capabilities some have made their wiki functionality stronger and deeper with a better editor, better user interface, more widgets, better extensions, or improved document management.)

Recently when I made a chart comparing eight (mostly) wiki-centric platforms I was able to compare them on these capabilities--because so many of them now had them.

• wiki
• blog
• discussion forums
• rich profile (profile which shows your "activity stream" i.e. contributions you have made)
• social networking
• document storage/search
• Twitter-like micro-blogging
• personal dashboard

Of the platforms I follow most closely, Traction TeamPage currently has all of the above capabilities except social networking, Jive Clearspace, all of the above except microblogging and Socialtext, in a re-designed website as of mid-December, touts all of the above, except forums. Atlassian’s Confluence comes out of the box with enterprise quality wiki and document functionality. I would guess a tech savvy user could build the rest in Confluence--except for microblogging and social networking--using plugins, macros and more. (See this very good webinar for tips on how a discussion forum was built in management and technology consulting firm Bearing Point’s wiki.)

It was in the last half of 2008 that Traction introduced micro-blogging, Socialtext, social networking and a personal dashboard, and Atlassian, the Office Connector which allows you to save Office documents directly into the wiki.

Wiki-centric platforms are evolving fast. Right now, as they add capablities, it looks like they are converging. I wonder, in this tumultuous climate, what we’ll be seeing at the end of 2009.

Collaborative Document Creation: Volunteer School Committee Drafts a 300 Page Report

I sent an email to my management school list serv asking for examples of wiki usage. One of the replies was from Sanjay Patel who worked on a committee in his local school district tasked with visioning "The School of the Future."

He was enthusiastic about how the wiki had worked for them. He laughingly characterized the group as "middle-aged not technically savvy people."

"The Visioning Committee tasked with writing a report on the School of the Future was made up of middle aged not technically-savvy people. We were a diverse group: teachers, administrators, parents, business and industry representatives, companies who hired locally. The tech coordinator for our school system suggested we use a wiki to log our research and pull together the multi-hundred page document we were to create. And it worked.

The wiki built on wikispaces allowed us to work on the report at a significantly faster rate than emailing back and forth. We also used the wiki to invite students in to read and contribute. We could post when we wanted, read, and respond to others."

They surprised themselves about how well and easily it worked:

"In one hour we were trained and we structured the wiki. Our school system's tech coordinator held an hour long training/workshop. There were 20 of us. We whiteboarded the structure and learned how to use the wiki. At the beginning, people were uncomfortable with editing other people's work. They would just write something underneath another person's writing. Then a couple of us decided, 'Let's get it done,' and started commenting in the text itself and editing. Others joined in. One of the things I liked best was that I could make an important contribution to the project without attending every meeting."

He explained they used the wiki for logging research and drafting the document, then used Word to finalize it.

"It evolved that people specialized on topics or sections of the document—researching an area and then drafting content. Two or three people would work on a section.

In the end, the tech coordinator, copied everything by section out of the wiki and edited and formatted it in Word to create the final deliverable report which we submitted to the School Board."

Some of the reasons it's likely that the wiki worked so well for them was that it fulfilled a real need--easing the process of collaborative document creation, and had at least one person, the school tech coordinator, who helped guide the wiki.