Posts tagged: google sites

  • Sunday
  • March 21
  • 2010

Google Sites: A few features flying below your radar

There’s much to love about Google Apps for non-profits, and any organization that has adopted the Google Apps platform for any length of time has witnessed innumerable changes and improvements as Google cranks up its cluster of cloud apps for businesses, schools and non-profits. And Google has an even bigger push ahead throughout 2010 as it rolls out more changes to Google Apps to add big ticket items like Google Buzz, Google Voice, and Google Wave, plus as many as 200 other additional small features.

At times, keeping up with all these changes seems like a full-time job. To do so, I follow a dozen or so official Google blogs, including what I consider the single most essential of all, the quasi-weekly Google Apps Team official update feed. For organizations that have adopted the Google Apps platform, if you subscribe to one Google feed, that’s the one.

The constant flow of changes, updates and improvements to the Google Apps platform presents another dilemma: What features are you overlooking or underutilizing? To help advance the cause, here’s a few Google Sites features our organization has used that you may have overlooked or forgotten:

Re-purpose a site using “Copy this site”

Go to More actions » Manage Site » Site settings » General, and at the bottom you’ll see options for “Site Actions,” including one to “Copy this site.” Google Sites primarily promotes this feature as a way to copy other sites you are invited to. But, to coin a phrase, think outside the box: Use this feature to repurpose your own sites. Here are two other ways we’ve used this feature:

  • We copied an existing site within our own domain and used the site “copy” to experiment with and apply a visual redesign of the site “original”; once the redesign was completed, we just made the copy the functioning site for our users and deleted the original.
  • We created a site with a load of content that we later decided would work better for users if we broke the site into two sites. No problema. There is no need to re-create the second site manually. Just make a copy of the site, then trim the pages and files from each site that will be used in the other site. Done.

Use “Copy this site” to change the URL for a site within your domain

In an earlier iteration of Google Sites, there was an administrative option for changing a private site URL within your Google Sites domain, but that option has been removed. (Changing public site URLs involves different rubrics. Also users with site editing privileges can still change the URL for individual site pages under More actions » Page settings. But I digress.) You can get around this site URL renaming restriction by simply copying the site and giving it the new URL of your choice. Then just redirect your users to the new URL.

Leveraging the Google Sites template features

It is hard to think of a Google Site feature that is more practical — no, better said, all but indispensible — than the site template and within-site page template features. There is no need to recreate a site design or its page designs from scratch each time. Tweak your overall site design and work out the look and layout for each of its page types, and then save each page design as a page template. Then use the page template options to replicate the design as you add new pages or even change the page template for existing pages.

Google has recently added a slew of spiffy Google Sites templates, and has posted for download some of the Google-designed template image assets; and a template tips page with a helpful visual guide to how to create, edit and change various site page elements.

Applying a Google Site project template to an existing site

One problem with Google Sites templates (as opposed to Google Sites themes) is that they can only be used for newly created sites; you cannot apply a Google Sites template directly to an existing site. There is a work around, although it may require your using Firebug to sleuth out some of the template image elements.

To experiment with this technique, first copy your existing site, as described above. Using the site copy, go to Manage Site » Site appearance » Themes and apply either the default “Iceberg” theme (if you want the design to have a page-edge shadow) or the “Simple” theme (if a flat page design is what you have in mind.) Then select “Colors and fonts” to view those options for changing the site’s appearance. In a separate browser tab create a temporary site using the Google Site template of choice, and then navigate to “Colors and fonts” for that site, as well.

Now all you have to do is duplicate the color and font settings from the Google Sites template to your site copy. When viewing the settings for some background-image elements, you may be able to view the image directly by clicking on the “View image” link which should display the image in a new window. If it does, you can right-click the image and save it to your local desktop, and then upload it to the your site copy. For some templates, particularly for a Google-designed site, you may have to work harder and use something like Firebug to sniff out the path to the background images so you can open them up for viewing in a separate window. In either case, you will likely want to rename the files before you upload them so you can recall which image is which.

Customize your Google Sites search options

The owner of a particular site, as opposed to its viewers, has options to configure site search so users can search only that particular site or any combination of other domain Google Sites and/or public web sites. For example, our organization has configured two of our domain sites — one we call the “Core Content” with official content only, and the other the “Shared Document Repository” where all users can upload shared files by topic — so that users can search either the site they are at, the other site, or both sites, as illustrated here.

To configure the search options for your site, navigate to Manage Site » Site layout and click the “Configure search” button to the right, and go at it. This is a very easy, flexible way to give your users a wider set of search-target options suitable to the particular site.

  • Wednesday
  • May 20
  • 2009

Whoa! What happened to my Google Sites customization?

A few days ago Google pushed code for new features in Google Sites that noticeably affected some individual site customization. It certainly impacted ours, including an intranet-style content area that we customized using a fair amount of background images and inline CSS code styles.

Google has posted a helpful list of notable changes, worth reviewing if you are baffled about the what and why of your broken Google Sites customizations. For example, it states: “When you customize your site in the colors and fonts area this will override your inline html styles. Customized colors and fonts now trump inline styles.” Okay, that’s different as are several other things.

  • Sunday
  • May 17
  • 2009

How we organized our targeted Google Sites content

Since we’re on the subject of revisions and updates today, here’s another about how we finalized our Google Sites content.

As noted earlier, The Findability Project planned integration of select Google Sites content as a GSA target. How we created LSNC’s “official” intranet site with Google Sites was covered (briefly) as part of a recent NTAP presentation.

Since that presentation, we have pretty much completed the migration of all our intranet content over to what LSNC calls its “Shared Private Network” (SPN). For those curious, here is a screenshot of the current site’s home page; and here’s a screenshot of the top levels of the sitemap. As you can see, we have worked to keep the hierarchy simple which means manageable, especially given the number of different folks who have responsibility to maintain its content. Also, we have created a large number of Google Sites file cabinet “upload” pages to make management of those file easier, for the same reasons. So far, so good.

What is great about all this is that the GSA easily targets this selected Google Site, and returns great results from the site. Users can have it both ways, by searching from the GSA frontend but with equal ease from the native search function within the Google Site itself. It’s all good.

  • Wednesday
  • April 22
  • 2009

Using Google Docs shares to propagate tech help

Here’s a simple example of how we use Google Docs within our Google Apps domain to share tech solutions with all staff at LSNC:

Today we felt it was time to let our more ambitious users know how to do a bulk export of their Google Docs to their desktop or other location of choice. So we used Google Docs to create instructions on how to bulk export your Google Docs, with links to the applicable Firefox add-ons and a few basic screen captures to illustrate particular steps. The version of the document linked in this post is shared as a public web page, for illustrative purposes here, but internally what we actually do is simply make the document viewable by all within our domain, and then add a link to it to our endlessly exciting “Team Gizmo Updates” announcement page in Google Sites, plus link it to a special “Google Tools” page, also part of our Google Sites content.

All within our domain can now search for and/or navigate to the solution at our Google Sites. Fewer tech calls on this question. Everyone is happier.

  • Tuesday
  • March 31
  • 2009

Google Apps Redux

Last week I participated in an NTAP webinar offering a quick-hit intro to various Google applications. My segment was Google Apps specific, showing how LSNC now uses Google Sites as its “official” intranet site for what we call our “Secured Private Network.”

As a modest coda, without any accompanying audio but perhaps of interest as an example how easily one can create a presentation using Google Docs and then publish it to the Web, here are the slides I used during the presentation: Google Apps = Google Sites = Intranet. The slide presentation was created entirely within Google Docs. You should see options at the bottom of the viewport for viewing particular slides, and others options for printing the presentation as a PDF or a PPT, the latter being usable in PowerPoint if that is your druthers. Another useful action is the option to create a copy to Google Docs of the slide presentation, a feature that works in both your domain’s Google Apps or your personal Google account.

What are other ways might one use Google Apps? Among current examples I can think of within our organization, staff use Google Apps to do the following:

  • The forms feature in Google Docs is used by the executive office to track compliance by local offices when conducting California State Bar approved MCLE events.
  • Very commonly, individual staff use folders in Google Docs to maintain personal document collections on non-case projects, including originals created or shared within LSNC in Google Docs, as well as imported Word and PDF files from those outside LSNC.
  • Google Docs and Google Sites were used in combination by one office to create individual “workplan” spreadsheets which were then embedded in a Google Site used as the office’s work plan site. As staff updated their individual workplans, changes were displayed in real time at the shared Google Site.
  • Tech staff archive and share among themselves select pieces of reusable code for specific projects, e.g., the custom CSS code used for LSNC’s Secured Private Network site, Google Search Appliance configuration sets and parameters being used for The Findability Project, jQuery and other JavaScript code blocks being used for various LSNC web projects, and so on.
  • Vetting of proposed policies and protocols by doing Google Docs shares rather than using email attachment loops.
  • While LSNC still relies on the superb Basecamp platform for management of large-scale litigation and advocacy projects, advocates are being encouraged and have begun to create individual project management sites using Google Sites, even for projects with outside participants. For example, LSNC’s Race Equity Project has assembled an editorial team using Google Sites to co-ordinate the drafting of an upcoming Clearinghouse Review article on “framing” issues. The site is also used to archive notes and documents for the meetings and presentations that have been conducted as part of that drafting process.
  • Twenty five LSNC staffers, with representatives from all offices, formed their own “LSNC Greening Project.” How do they communicate and share information? They use Google Sites as their home base, in combo with Google Docs to share documents and a private Google Discussion Group to thrash things out. (They could simplify things by using the announcement page feature in Google Sites to conduct discussions, but that’s their call.)
  • Office managers use the forms feature in Google Docs to report changes to IT staff about required changes for personnel listings, Gmail changes, and additions and removals from discussion groups.
  • A pro bono component in one office has created an internal Google Site with multiple list pages for tracking case vignettes, available attorneys, cases assignments, contact information, dates assigned and completed, and so on. Everyone in the office working in support of pro bono cases has access to the site.

Just a few ideas among many in current use at LSNC. If you move to Google Apps, you’ll pretty quickly discover even more uses.

  • Monday
  • March 9
  • 2009

What you get if staff name your intranet

Once Google Sites got added to the Google Apps suite, Legal Services of Northern California (LSNC) almost immediately made the decision to migrate away from an existing MediaWiki installation to Google Sites to host its existing intranet content. Then and now that intranet location has been called the “Shared Private Network.” Within LSNC, everyone pretty much just calls it the SPN.

Since the tech team at LSNC (in-house known as “Team Gizmo”) believes in change you can, uh, believe in, they thought it would be a great idea to give LSNC staffers the opportunity to rename the SPN. And what better way to do it than have a contest (with a grand prize of a $30 Amazon.com gift certificate) open to all staffers, to submit their suggestions for a new name.

Game on!

Over a three-week contest period, Team Gizmo received a total of 47 suggestions for renaming LSNC’s shared network, including a late entry for which the time limit was waived because of the “quality” of the submission. Relying on contest standards that make American Idol look like the Nobel Prize, Team Gizmo brought its best “arbitrary and capricious” A-game to the task of reviewing all submissions.

There’s good news and bad news.

First, the good news: There was a winner, the who and why are explained, below. The bad news: Change is hard. Notwithstanding the number of submissions and the identification of a bona fide winner, the consensus (including the winner herself) was that no one came up with a name and/or acronym better than what has been used for so long, namely, Secured Private Network or SPN.

But, wait, there is the funny news: LSNC staffers largely approached this contest as an opportunity to showcase their sense of humor and delight with acronyms. Among the lessons learned:

  • Some senior managers clearly have too much time on their hands. One of them submitted more nominations than anyone else. We are compelled to acknowledge here his best suggestion: Ecretsay Tuffsay from LSNClay. (Yes, that was his best suggestion.)
  • There were several nominations suggesting some staffers are watching too much television, especially niche or defunct channels, like ION (Inter-Office Network) and UPN (Ultimate Private Network), which no doubt would have been well received if Star Trek Captain Janeway were a member of Team Gizmo. She’s not.
  • Without naming names, the LSNC Auburn Office is apparently busting at the seams with galactic vision, with its suggestions that included CSN (Cosmic Stellar Network), SCN (Stellar Cosmic Network), LSNCU (LSNC Universe) and PLSNC (Planet LSNC). No doubt the Auburn Office will be closed on May 8 for interplanetary repairs.)
  • That only scratches the surface of the many clever acronyms LSNC staffers came up with. Among more serious ones were LINE (LSNC IntraNet Experience), PIN (Private Information Network) and SNAP (Secure Network All Private). But there were a slew of funny ones, as well, including IPHOM (I Pay Homage to the Machine), LOLS (Lots of LSNC Stuff) and a hearty bottoms-up to PILSNER (Private Intranet Legal Services Network Employee Resource).
  • Some of the best submissions weren’t about acronyms, they were just… well, you decide:
    • CASPER, as in the friendly ghost. I have my reasons.
    • www.thisisthegreatestthingihaveeverseenandicouldnotlivewithoutit.com
    • The No SPN Zone
    • … and a personal Team Gizmo favorite: That thingy online where we get all the stuff

The winner? It came from a bookkeeper in the Finance Department, who submitted SPUNK (Super People United as Networked Kin). Are we going to use it? No. That said, it is a funny, clever and catchy acronym that melds notions of intranet purpose and functionality with an empowering sense of organizational esprit de corps, don’t you think?

Bottom line: The best $30 tech investment at LSNC. Ever.

  • Thursday
  • February 26
  • 2009

Comparing Google Sites and GSA search results with release 5.2 in place

All went well with the GSA version 5.2 update. The update itself is a humongous 1.53 GB ISO file that, once burned to a DVD disc and loaded, took about 6 hours to install. As recommended, we did a complete crawl refresh which, in our case, took another 72 hours. Other than this considerable but necessary time investment, we had no real problems with the update process.

As mentioned in an earlier post, the principal attraction of this most recent GSA update was the integration of Google Apps, which enables targeting of domain-hosted Google Docs and Google Sites. In that regard we are pleased to report no problema, as well.

In version GSA 5.2 the administrator now sees a menu option for “Google Apps Integration” with a single field for enabling or disabling one’s Google Apps domain as a GSA target:

With Google Apps targeted generally, then it is a matter of constructing URL patterns to include or exclude more specifically what you want targeted within your Google Apps. In our case, that meant our selection of specific Google Sites now serving as our organization’s intranet content platform. More specifically our search goal was to have the GSA index not just pages within those Google Sites but, as importantly, files uploaded to those Google Sites.

There are differences in how search results display between those performed from within Google Sites and those from a GSA frontend. If a search is done from within Sites, it will find and return a search result for keywords or phrases within an uploaded file, but not display the context of the keywords or phrase. For example, using the search law school+"reimburse me" one gets this specific PDF search result from within Google Sites:

The same search done from our test GSA frontend that returns results from everything targeted by our GSA, yields the same search result while showing the keywords and phrase in context:

So, the basic differences in how search results display are these:

An internal Google Site search will find and return results based on keywords and/or phrase within a file uploaded to Google Sites, display the filetype as an icon (in the above example, with a PDF icon), display the link using the file name, but not display the keywords or phrases in context.

In contrast, the GSA search result will find and return the same result but display the keywords and/or phrase in context, display the filetype as an acronym (e.g., “PDF”), and display the link as what the algorithm discerns as the document’s title (in this example, “Law School Loan Reimbursement Request Form”).

  • Friday
  • January 23
  • 2009

Why we like GSA release 5.2: Google Apps integration

A few weeks ago Google Enterprise issued Release 5.2, the latest software update for model GB-1001, the one we are using on this project.

There are a slew of new features in Release 5.2, but there are a couple that are making for some serious happy on this project. The most significant is that, with the update, the GSA now integrates with Google Apps. For those interested, the Google Code site has a detailed explanation of how that works.

For us this is huge. Our modest non-profit organization two years ago adopted Google Apps as a basic building block for a functional, practical, web-based enterprise environment, something we never really had before. (Hey, there are intranets and then there are intranets.) The Google Sites and Google Docs pieces of the no-cost non-profit Google Apps service are a big part of that. And as part of this project, we have moved pretty much all of our existing intranet content over to Google Sites, and use of shared Google Docs throughout the organization is increasing steadily. (Use of the forms features in Google Docs is especially popular among our office managers.)

Before the Release 5.2 update, we had made valiant stabs at getting the GSA to index our Google Sites content, but with muddled success; and with uploaded files, at best it would only return results with keywords that showed up in uploaded files names, not the file content. Now the GSA integrates directly and we can target any “public” Google Sites or Google Docs content we share with others within our domain. (There is some ambiguity in how Google describes GSA integration about so-called “public Google Sites and Google Docs.” To clarify the point, in this context “public” is a Google term-of-art. If you create a Google Site or Google Docs within your domain’s Google Apps and share it with everyone within your domain, then it is “public.” It is not necessary to make that content public to the world.)

The other Release 5.2 feature we are especially excited about is its enhanced advanced search reporting. Now we have a built-in tool that enables us to analyze user search behavior, with reports that “list every query and click made by every user,” plus whether users are finding what they search for within three clicks, or not at all, and which part of the search interface the users, uh, actually use. Aces!

One caveat we are aware of from GSA groups discussions: Release 5.2 is a significant update with features that may warrant a serious review of one’s existing XSLT modifications, to exploit new GSA feature sets. And we have been advised to do a complete crawl refresh. We’ll report back here how it all goes.

  • Saturday
  • September 13
  • 2008

Migrating away from MediaWiki

With apologies in advance to James Agee, I begin by declaring to all here assembled, “Let us now praise famous wikis.”

And none has been more deserving of regard and praise than MediaWiki, the venerable open-source wiki publishing platform, originally written for and most popularly associated with Wikipedia. LSNC has relied on MediaWiki since 2006 as its principal publishing platform for its private intranet and some public web content, most notably its deservedly popular CalWORKs (TANF) guides and related resources.

But a lot has happened in the world of webware since 2006, much less 2001. In the last few years LSNC has also experimented extensively with the rapidly evolving WordPress web publishing platform, which experience has taught us is a vastly superior choice for web publishing, including collaborative and multi-author publishing. And the final nail in the MediaWiki coffin, for us, is the emergence of Google Sites, part of the Google Apps platform that LSNC has been using for the last several years. (And love. Really, really love.) Prompted in part by the work being done at The Findability Project, which directly impacts how we, as a large, widely dispersed non-profit organization, handle shared content, LSNC is now moving its intranet content that has long been published via MediaWiki to Google Sites, which is not yet optimally but still effectively integrated into our other Google Apps. And all our public web content at LSNC’s varied websites is now being purposely moved over to the WordPress platform, if it has not been done already.

What is our rationale for the shift away from MediaWiki to WordPress as our public face and Google Sites as our private face? Consider the following:

  • Both MediaWiki and WordPress are relatively easy to install and configure, assuming one has the server side of things already in order. It is not a deal-breaker, but I would give a tip o’ the hat to WordPress for its five-minute install. (If you know how to do it already, it is more like 90 seconds or less.)
  • It is not just that WordPress is also open source and free and PHP based. Having worked with both MediaWiki and WordPress, it is WordPress that has the larger, more enthused and arguably more talented development and support community. If you think not, than I assume you are not familiar with the remarkable, really remarkable WordPress Codex or the astounding level of WordPress plugins, among other things.
  • I am pained to say this, as an early supporter of the use of wikis within the legal services community and someone who promoted MediaWiki whenever I had the opportunity to do so … but wiki syntax is a total bust — at least from the non-geek user side, exactly the persons it was intended to help create web pages without knowing HTML. Neither wiki syntax nor HTML (structural markup) can claim to be intuitive. They’re not. But as someone who has worked a lot with both wiki syntax and structural markup, and watched others struggle with creating and editing pages in MediaWiki, here is my conclusion: HTML is actually simpler, easier and undeniably more flexible! Hey, that’s me. Your mileage may differ. (Hey, there’s a reason why wiki platforms like Google Sites use a WYSYSIG interface and avoid using wiki syntax, but do provide access to the underlying HTML.)
  • Edit a page in MediaWiki and one can see the seeds of failure within the wiki syntax model: An editing toolbar that in part apes what one associates with a word processing program. OK. But even with that option, our institutional experience is that non-geek content editors never really got the hang of things, such that one of the resident geeks had to go in and clean things up.
  • Take a look at a current-version WordPress or Google Sites editing toolbar and the advantages from the user side reveal themselves. Really. Take a look at how editing works with those two platforms. Can you say, “zero learning curve”? (See “wiki syntax,” above.)
  • Google Sites is tied in nicely with the basic complement of Google Apps services (Gmail, Google Calendar and Google Docs) that come with the free non-profit package that a lot of legal services field programs have adopted. It makes it very practical for the organization to rely on Google Sites as its intranet and put its users one-click away from other Google Apps they use everyday, or any other purpose the organization wants to put it to. For example, LSNC is currently experimenting with Google Sites as a special project repository for major impact cases. Here’s an example:

  • From a web designer view of things, WordPress is a now a glorious model of PHP and dynamically generated HTML. Don’t take my word for it. Ask what Jeff Zeldman thinks. (Full disclosure: Happy Cog is his design studio, and the new style and design look of WordPress 2.5+ has his fingerprints all over it. But that’s a good thing.) MediaWiki? A singularly big pain in the ass to redesign. MediaWiki out-of-the-box pages validate well enough, but the markup approach is … oh, don’t get me started.
  • But you’re thinking, “Hey, MediaWiki is a true wiki and it saves all the prior versions of the pages you create and change, so you can do the big roll-back, if needed. Yeah, how about that Mister Wiki SmartyPants Webdog, huh?” The answer is that among its many virtues and features, WordPress now supports post and page “revisions”: Install Google Gears, click on the Turbo link in the admin panel, and you’ve got all the roll-back you’ll ever need.
  • Google Sites. Hmmm. Google is famous for its non-standards-compliant markup and there is not a whole lot one can do to unilaterally change the design of pages, other than the customization options built into the Google Sites app. But the built-in stuff is pretty good, actually, and offers enough flexibility that one can add a reasonable number of personal touches to any given site.
  • Google Sites has the usual complement of wiki features, including an array of different types of page templates (“web page, announcements, file cabinet, dashboard and list”)
  • From within Google Sites, the integrated search functions can locate any text anywhere within the site including any files you upload to a given subsite within Google Sites. And you can integrate Google Analytics. And you can target a Google Search Appliance at it as well. It is all Google good, so to speak.
  • Did I mention that Google Sites is integrated into Google Apps?

In summary, let us honor MediaWiki. It taught us the wisdom of the wiki and introduced us to the concept of shared, collaborative publishing on the Web. And for us, that has now largely been better realized by WordPress and Google Sites.