WebedtecH

Docs Faceoff: Microsoft Office vs. Google Docs.

One of the challenges we face with the implementation of collaborative workspaces is maintaining the fine balance between functionality and simplicity.  We have all watched a site go horribly awry due to a focus on specific, deep details without maintaining a holistic view of the experience.  SharePoint, Google Apps, etc. – the platform does not matter; the symptoms are the same.  The effort comes in prevention and mitigation.

Walk a thousand miles

As site developers and solution providers it is easy to lose sight of the people who need to use the wonders we build and force them into change that is unnecessary and burdensome.  We spend a great deal of time with our creations becoming intimately familiar with them.  We know their navigation structures like the back of our own hands; the order makes perfect sense to us.  It is that very familiarity that blinds us to the experience a fresh pair of eyes will have when they visit our site for the first time.

Evaluate your site design with this litmus test.  When you go to a page is the purpose of the page obvious or do you have to “know” where, how, and why things work?  If you need prior knowledge about a site or tool to understand what it does and what is expected of you then your design fails.  I will always take the position there is great value to a simplified interface and information flow if for no other reason than it frees the user’s mind to concentrate on the important aspects of the task at hand.

Design to be forgotten

If you create a solution architecture that requires your users to retain an understanding of the site/tool operation between uses your design fails.  In some cases it can be months between application uses and the information on the application’s operation will be lost from your users within days.  Your options are to create pages of help documentation or design your site so it can be “relearned” each time it is accessed.   Be warned however this is a tricky balance to maintain; ease of use without being repetitive for frequent visitors.

Avoid creating blind spots

When working on a web site there is always an inclination to put information we deem important on the home page.  The trap this creates is the production of “blind spots” on the page.  For example, it’s popular to put a list of the team members working on a project on the home page of a site.  When you visit the site for the first time it’s interesting information.  When you visit the site for the fifth time it’s a waste of space on the page.  Pages that will be heavily trafficked by design need to avoid blind spots whenever possible.  Information must be relevant, timely, and concise.

Moving forward

Think carefully about the sites you visit and the things you like and don’t like.  Design simply.  Once you finish your design wait a couple of days then go back and remove anything that doesn’t absolutely need to be there.  Remember you can always entice a user with something new but when they’ve seen everything at once there’s no surprises.

Let’s set the stage.  We have an organization (XYZ) that is building it’s intranet on Google Apps.  They are planning the following:

Main Site
—– Administrative Team
———- Policies and Procedures
—– Human Resources Team
———- Policies and Procedures
—– Forms and Files
———- HR Forms
———- Sales and Marketing Forms
—– Sales and Marketing
———- Contact Information
—– Information Technology
———- Technical References
———- Help Desk
———- IT Team Site

You can see already that there’s overlap in some needs and segmentation in others when it comes to planning the sites.  The biggest challenge arises withe the realization that security in Google Apps is tied to the site level currently rather than the content level as is the case with most other collaborative platforms.  So how to get around this?

Step one – The World is Flat

Rather than having a site hierarchy that is tree like in structure (which most people are used to) I recommend you use as flat a structure as possible.  Create a main site that you will use as the home for your intranet and then add to it links that navigate to all the “sub-sites” for your intranet.  They aren’t actually under the main but your end users won’t know the difference.  This way you only need to add one link to every sub-site to take you back to the home site for navigation.

Step Two – Security by Obscurity

Google Apps doesn’t provide a great deal of security modeling and control so the easiest way to manage this is by creating sites around each security “bubble” you need to have.  For example if you have an Administration site and you want a section just for Executives you’ll need to create an Executive site and grant access that site just to the Executives.  You’ll most likely place a link on the Administration site to the Executive site, but unauthorized people will receive a warning when they try to follow it.  If you want a “highly secure” (I use the term loosely) site, just keep it out of your navigation menus.  If people don’t know it’s there they can’t try to access it in the first place.

Step Three – Locking the File Cabinet

If you have a need to isolate a section of a site, for example administrative HR forms from regular files, you’ll need to create another site and make it the file cabinet since you will be able to control the security on that site separately.

The rule of thumb for Google Apps is if you need to secure it, put it into a site.

Part four – Designing pages for your users

So you think you’ve finished all the planning for your new intranet and you’re ready to get to the building part.  Not so fast there…there’s still more thinking to come.

Concentrating on the problem solving

You have identified the specific needs you have to meet for your intranet to be successful, but now you have to figure how to accomplish those objectives with the tools at hand.  Personally this is one of the reasons why I love these types of browser based tools.  They force you to think creatively rather than running the code to just make it do whatever you want.

Let’s start reviewing some of the functionality you are likely to address in building out your site:

• Document management
• Lists of information
• Reference materials
• Discussions
• Links

There are a lot more that we’ll address later but this is a good list of things to get us going.

Document management

Generating documents is part of the lifeblood of most organizations and I’m sure yours is no different.  The challenge comes with keeping everyone on the same page when working with documents as part of the team.  There’s two main parts to this: editing documents and accessing documents.  Editing documents collaboratively online is the strength of Google Apps for documents and spreadsheets.  I’ll leave the focus on how to do that work there.  The strength of Google Sites when it comes to documents is the File Cabinet feature and embedding documents.

File Cabinets in Google Apps give you a place to upload documents to and organize them within folders.  Unfortunately there is little security there beyond the site level security.  In one of my later articles you’ll see that security in Google Apps is dependent on creating lots of small, targeted sites and weaving them together.

When planning your File Cabinets, think topically. You can only create one level of folders in each cabinet, so plan around a cabinet holding one topic area of information. It will make it easier for your users to recognize what is in the cabinet right away. For example a cabinet labeled “Forms” should hold only that, various forms broken down into folders. It’s fine to have a number of filing cabinets in your site, or even have sites that are nothing more than filing cabinets. Another example is if you wanted to have HR forms all in one place setting them up as their own site with read only access for most users is an effective solution rather than trying to manage them as part of a larger site.

Lists of information

There are a couple of ways to handle lists of information in Google Apps. One is to use the List page in Google Apps to create a basic structure of sortable fields. If you need a quick and dirty list of things such as to-do items or a phone directory this is a good way to go. If you need something more robust I suggest you create your list in Google Apps spreadsheet and embed the spreadsheet into your site. It is much more powerful and versatile than the built in list function.

Reference Materials

This is one of the times I recommend using the internal functions of the site over an outside application. Google Apps do not have a wiki function, but the Pages can be tied together in a way to make them very user friendly. Procedural documentation, policies, guidelines, anything that may need to be updated easily are good candidates to be a Page in a Google Apps intranet. One of the larger advantages is the ability to attach files and comments to the pages, making them truly living documents.

Discussions

Email is a critical part of our operations and instant messaging services such as Google Talk and Twiter are becoming just as valuable. Discussions in Google Apps take this to another level by making the conversation public to all the site members. Unfortunately, unlike other systems there aren’t any “discussion lists” within Google Apps. What’s a site administrator to do? Use the Announcements option instead, of course.

By using the Announcements option each new announcement becomes the beginning of a message thread and the comments are the responses. It’s a great way to leverage a feature in Google Apps for something different than it was designed for while still meeting a significant need. An example of this is using an Announcements list for a Q&A section in your site where users post their questions as announcements and your answers are the comments. You can subscribe to the list and always be in the loop on what your users need to know.

Links

By using the List page template you can create indexes of links for your users that act as supplementary navigation, reference lists, tables of contents, and more. If you are going to have a number of links in a list (20 or more) I suggest adding a category field that you can sort by so people can find the links they are looking for quickly and easily.

We’ve covered some of the basic components your intranet may need. Next is one of the more complicated aspects of Google Apps sites…navigation within a site and across multiple sites.

Do your teachers and staff have the tools necessary to work together as a team?  Considering building an intranet?  That’s what we’re doing and I’ll explain how.  The amount of power and functionality that a school has access to through a system such as Google Apps gives a great opportunity to build a collaborative workspace for teachers and staff with virtually no cost.  However the idea isn’t without it’s challenges.  When planning any sort of collaborative web effort, I recommend starting with three key questions:

1. What do you NEED to do?
2. What do you WANT to do?
3. HOW do you want to do it?

The first question is without a doubt the most important.  The second and third will change, even be discarded, if they don’t meet the requirements of the first one.  Our needs right now are simple:

1. A central location for forms and reference materials that can be accessed by any staff member on or off the network.
2. A shared location for policies and procedures (currently we use a network drive)
3. A simple way to keep said policies and procedures current for everyone needing access

Now this set of needs could be served by any number of solutions so we’re still at an impass.  On to question 2…what do we WANT?

1. A system that is easy to use
2. Integrated with our current email system
3. Available from anywhere
4. Reliable
5. Adaptable
6. Minimal (no) cost

Not much more specific, but it does point out some key requirements in narrowing the field.  For example, “integrated with our current email system” points towards Google Apps since it is what we have been using for email for two years very successfully.    Also, “available from everywhere” eliminates most network centric solutions and points us back to the cloud.

Finally we come to the HOW.  This can be a tough one since by this point you still have a couple of options left on the table and you need to do a critical analysis, cost-benefit comparison, etc.  For us this was made a great deal simpler by the last WANT…minimal (no) cost.  Looks like we’ll be building our intranet with Google Sites and Google Apps.

Next…functional requirements.