shift and share

This is the second part of my report on using Google Sites in a session last week; the first part was the “what”, the next part is the “why”, but for now, I’m going to confine myself to the almighty “how”.

The first thing to understand is that all of the flavors of Google Apps require a domain name, which you can purchase as part of the sign up process. This is not to be confused with “Google Docs”, which you may have encountered as an add-on to your GMail account. What they’ve done is take a number of their services and mash them together, so you get a single stop for mail, documents and now, sites.

Though we’ve been using Google Apps on a number of domains for experimental purposes, I opted to set up an entirely new domain for this session, which - I think - turned out to be the right thing to do. The reasoning is that, as you’ll see later, a lot of times when you’re sharing, it’s easier to share with everyone who is a part of the domain. By having a separate domain for each client, that means that you won’t run the risk of accidentally cross-sharing documents, pages or other bits of information. Until Google gets a little more sophisticated with the control over sharing, this is the way to go.

Signing Up: You can sign up for a new domain by going to sites.google.com, where there’s the option to “get started”. Enter your email and click the button, and you’re whisked to a page telling you, most likely, that your domain isn’t supported. You’ll see a tab where you can click on “I want to buy a domain name”. Go there, and start hunting for a domain name that works for you. Note that you really shouldn’t bother buying a domain elsewhere in the hopes of using it with Google; the switch over is cumbersome and time consuming, whereas buying it as part of the Google sign up is cheap ($10) and makes the set up instantaneous and seamless (I tried it the other way, and it was long and painful, taking days to become active).

Getting Started: Once you’ve bought your domain, you’ll have to set up your administrator account. You obviously need at least one person who will play the role of the administrator. This is the account you use to set up new users (ie the rest of your team, and ultimately, the participants), set up the site itself and manage things like sharing and access. It’s a good idea to also make the members of the production team administrators, and it would help in the hand-ff to the client at the end if they had someone who could take an administrator account. To set up your first account, you need to choose a username and password.

Setting up your Site: Before delving any further, I should strongly encourage you to get Firefox, if you’re not already using it as your browser. Working in Google Apps for any length of time without “tabs” is quite painful, as you end up with lots of different windows you need to navigate back and forth from. You’ll save yourself a lot of heartache.

Once you log in to your admin account, you’ll be presented with your “dashboard”, which has icons for all of the various services that make up the Google Apps suite. For each, there is the title of the service in blue underlined text, and a green address underneath. Click on the title to view settings for the service, or click on the green links to actually go to the service. If you’re using firefox, clicking on the green will open a new tab, which is great. You can use the “dashboard” as your navigation as you go from one service to another (which you end up having to do more than you might like…more on that later).

For our session, we primarily used “Sites” and “Docs”.

It’s important to understand the difference between these. “Docs” is a service that essentially works like a networked version of Microsoft Office; you can make spreadsheets, documents and presentations which are then hosted on the Google servers so that multiple people can view and edit the same “version”. You can either create files in Google Docs, or you can upload MSOffice files. I find it better to upload Office files, as the interface of Google Docs has a long way to go, but the collaboration functions once you’ve uploaded a file are great.

Google Sites is a different animal, as it more closely represents a Wikipedia style wiki than a document sharing system. It is essentially a password-protected website that any user with access can edit, meaning that you can create a site that visitors can then iterate.

Where the two cross over is that they both live within the same domain, and documents from Docs can be embedded directly in the pages of the “Sites”.

To set up your site, then, you need to click on the green link to the Sites on your dashboard, and create a new site. Here, you’ll have the option of naming the site, as well as choosing the theme, etc, though you’ll have the chance to tweak that later.

Note:  We discovered that using any punctuation or symbols in the site name would create major problems which you’ll only discover after it’s too late (all of the links to attached documents in the wiki will be broken). To be safe, don’t put any symbols or spaces in the site name.

You also use this screen to choose the sharing options for the site (which you can also adjust later). If you’ve set up a whole new domain for the site, I would recommend setting the sharing to “everyone at this domain”, so that you don’t have to go and individually invite each and every user. As you add users, you’ll find it much easier to just share with everyone than it is to have to set permissions for each one.

Once you hit “create site”, you’re done…you’ve just created a site and can begin working…

More on that in the next post…