Posts tagged: google groups

  • Sunday
  • January 22
  • 2012

Integrating Gmail and Google Groups with the Pika CMS

A few weeks back the project team uploaded a complete version 4 code set to the LSNC Google API Project. This latest version is inclusive of four Google Apps core app integrations — Google Calendar, Google Docs, Gmail and Google Groups with the Pika CMS. This is the same project I described during my recent presentation at the 2012 TIG Conference in Albuquerque. As I noted there, we are spending the next few weeks doing expanded beta testing with users across varied positions and office locations within Legal Services of Northern California (LSNC). We expect to deploy all four integrations throughout the organization by the end of February.

In earlier posts I have described how the Google Calendar integration and Google Docs integration work. The short version is that, by exploiting the Google Apps APIs for Google Calendar and Google Docs, we have been able to implement a seamless synchronization between the Pika CMS calendar and document posting functions with Google Calendar and Google Docs. Pika CMS users need do nothing differently than what they are already doing to have tickler calendar events show up in their Google Calendars, or have case-related files uploaded to Pika show up in a case-specific shared collection in Google Docs.

The new Gmail integration in version 4 is arguably the most important of the four integrations. The basic user problem has been this: Everyone within LSNC — like most everyone else on professional planet Earth — day-in and day-out relies on email to accomplish their work. In our case, advocates regularly communicate with clients, co-counsel, opposing counsel, public and private individuals and entities and, of course, other LSNC staffers. But how are they to get those Gmail messages into case-related case notes in Pika? At the moment, what they do is cut-n-paste, again and again and again without end. The Gmail integration is designed to simplify that process so that users, from within a Gmail message or the entire conversation, can seamlessly post the content of Gmail messages to a client-specific case record automatically, without the need to open Pika.

To accomplish this, we have embedded a new Gmail widget that displays at the bottom of every Gmail message. Below is a screenshot of a developer version of the integration, with the gadget labeled as “TKLAPP Staging Pika – Attach to Case Notes.”

The default behavior of this gadget is to automatically copy the currently viewed Gmail message to the case notes in the selected client case record. To trigger that functionality, users toggle the gadget to display a dialog with a search option to locate any currently open client case record in Pika. Two tabs are available, one to search the user’s assigned active (open) cases and the other to search more broadly all cases active (open) throughout the organization. Once users select a case record, they have two check-box options: one to save any files attached to the Gmail message, which are automatically uploaded to the Pika case record and simultaneously synchronized to the user’s Google Docs account; the other to copy the entire Gmail conversation (Google’s name for an email message thread). Users can then simply click the “Attach to Case” button to seamlessly copy the Gmail message to the case record.

But wait… there’s more!

The gadget also offers an alternate input button allowing the user to “Edit and Attach to Case.” Clicking that button invokes a pop-up window with the Gmail message copied over to Google Docs for editing before the content is posted to Pika. The user can edit the single Gmail message or conversation as is their wont and then click on “Attach to Case” in the editing window to post the edited content to Pika. Done. Without ever having opened Pika.

The Google Groups integration works on the same premise as the Gmail integration, with the approach being to enable users to automatically copy a Groups discussion automatically to a Pika case record. The Groups solution is less elegant, however. Going into this project we made the mistaken assumption that, like the other Google Apps core applications, there was a Google API for Groups, but there is not. Google Groups has no exposed web API. So we did a workaround. The Google Groups integration with Pika requires the user add a custom bookmarklet to the browser bookmarks toolbar. Once that is set up, the user can go to a Business Groups discussion within our domain, click on the bookmarklet and trigger a set of dialogs directly analogous to how the Gmail integration works, with the ability to search for a specific client case record and then “attach” or “edit and attach” the content of the discussion message. (Google Groups no longer allows file attachments to discussion group messages, so there is no option to attach files.)

For those interested in this code set, you can anticipate there will be some minor updates to the code set over the next month or two as we fix quirks that emerge from our further beta testing. There is also an updated guide to installation coming soon.

Thanks again to everyone who attended the TIG presentation. It was encouraging to see how much interest there was within the larger legal services community in this project. My prediction is that within a few years we will all look back at this coding project as somewhat quaint, only a first step in many to come as we all increasingly rely on the Google Apps platform and work more with the Google API to take full advantage of it.

  • Friday
  • May 21
  • 2010

Groking Groups in Google Apps

What now seems like eons ago, and well before “Google Apps” even existed, LSNC relied on Yahoo! Groups for its first foray into email discussion lists. That relationship did not last long. In early 2006, LSNC made its first institutional move toward the Google-centric work style with adoption of Google Groups. The initial cluster of LSNC Google Groups included substantive discussion groups for housing, welfare, health and education, plus two announcement-type lists, one for all advocates and the other for all employees. We started with an opt-out approach for users, with the only exception being what we still call the “LSNC All” list, which was mandatory because of the importance of getting certain types of messages to everyone in the organization. At that stage LSNC still maintained its own mail server and spam was a growing problem.

Then later in 2006 came the standard edition of Google Apps, followed by more specificly marketed premium, business and education editions, as well as the non-profit edition adopted by LSNC. All editions offered the promise of practical integration of a basic complement of web applications: Gmail, Google Calendar and Google Docs. For LSNC the biggest initial advantage we saw with the Google Apps platform was the promise of Gmail on two counts: First, we could offer all staff universally web-accessible email; and second, based on the experiences of several staff who had long relied on their personal Gmail accounts, we were confident that Gmail’s preternatural ability to deal with email spam would solve that problem for us. It did. The switch over to Gmail also relieved LSNC of the need to maintain a mail server, much less all the security and spam filtering requirements that went with it. The larger institutional transition to Gmail was all but instantaneous and overall pretty painless. Google Calendar and Google Docs were actively promoted within LSNC, yet user transition toward those apps was slower, if steady. Use of Google Calendar within its first year of adoption became the norm and then eventually became an institutional requirement for all shared calendaring, such as local office and program-wide calendaring. It is now required for all individual calendaring within the organization.

But I digress. Back to Google Groups. Eventually LSNC made membership in most organizational discussion groups mandatory. For example, all advocates are required to be part of all LSNC substantive discussion groups, all office managers must be part of the special discussion groups created for office administrative matters and the separate list on technology issues, and so on.

Google Apps marches on! Last December Google Apps added Google Groups, and LSNC is just now laying its plans to transition users from the consumer version of Google Groups we have relied on for years, to this newer Google Apps corporate version. Broadly speaking, the Google Apps version of Google Groups looks and behaves pretty much like the other version. There are no real surprises in terms of user design here. But there are several significant differences below the surface, most of which relate to how Google Groups is intended to integrate with the larger Google Apps platform, as opposed to being a free-standing web app like the consumer version.

Three biggies come to mind:

1. Google Apps Google Group makes it enormously easier to manage multiple groups than does the consumer version. How so? Let’s say you want to create a discussion group or an announcement list for everyone within your organization. With Google Apps Google Groups you don’t have to do that manually. All you have to do is check a box to add all users within your domain. OK, say you have multiple substantive advocacy groups, like the ones described above. Within your domain you can now add or nest one discussion group membership list within another. For example, LSNC is creating one “master” list for all advocates, and that is the control point for assuring the membership list is correct and current. Then for other advocate-related lists, all we need to do is add the master advocate group address to the members list of the housing group or welfare group, and so on, with no need to update those membership lists because they are just nested versions of the advocate master list.

2. We’re talking user-managed groups now. If enabled this feature not only allows your users to create their own groups for discussion but perhaps just for ease of Gmail message distribution among a self-selected group of users. But it also does another important thing: It enables the owner of the group created to permit persons from outside the domain to participate in the group. For example, within LSNC there are small clusters of staffers who for organizational reasons use an entirely different domain for their Gmail. No problema. They can be added individually and directly to any of our domain’s Google Groups using this feature.

3. Finally, there is the Google Apps integration thing. The interface for the consumer version of Google Groups has sections for group “Pages” and uploaded “Files.” But you won’t find those in the corporate version of Google Groups. What’s with that? Well, if you need to create pages or upload files, then you need to do that with Google Docs and/or Google Sites and do a share to the group. I’m not saying that’s optimal. I’m saying that is the reality.

And as of this writing, there is a long unresolved bug in the corporate version of Google Groups affecting file attachments to email messages sent to the group. Yes, you can attach a file to an email message and it will appear linked within the group site. But, inexplicably, the content of any group message that has a file attachment does not get indexed and therefore is not searchable from within the group site. (File attachments themselves have never been searchable within any version of Google Groups. In contrast, files uploaded to Google Sites are.)

Then again, maybe that problem will get resolved once Google Apps implements unified search, which would be total Aces.