Marc Olson's Groove 2007 Blog

With general availability of Office 2007 next week, I wanted to give a short note on the conversion process from Trial to Groove Live (or full retail).  We've had over 30,000 downloads of the Groove trial since it went live in early December and I hope that trend continues.

One slight 'gotcha' in the activation process for Groove has to do with the need to restart Groove after you enter the Trial key.  After Groove is downloaded and installed, during the initial configuration run you're asked for your product key (which arrives in e-mail).  After you enter the key you're asked to restart Groove.  To do this successfully you have to close the Groove window AND right click on the Groove icon in the system bar on the bottom right of your screen and choose Exit.

Once Groove restarts, the Trial key will be read and the full capabilities of Groove 2007 will be available.  Once the Trial expires and you purchase either a Groove Live subscription or Groove 2007 at retail, you'll need to enter the new key you get with that purchase and restart Groove using the same process.

Fixing this so that entering the key forces the restart is something we're looking to fix in a future release.

More information can be found here:  http://support.microsoft.com/kb/925838

In my last post, I talked about the new 2007 Microsoft Office system, and the Microsoft Office Groove 2007 offerings for enterprise customers.  Today I want to spend some time discussing our new offering for small businesses and workgroups: Microsoft Office Live Groove.

As I’ve talked about in the past, Groove was designed from the bottom up to address the ‘new world of work’, where workgroups and teams more often than not include members from multiple organizations.  That helps explain why Groove has quickly been adopted internally here at Microsoft.  The most common ‘success story’ within Microsoft for how teams are using Groove is enabling them to connect with external customers and partners.

Part of what makes Groove so easy to extend to third-party organizations is its built-in trial process.  With Groove v3.1 today, new users from any organization – large or small – can easily gain access to the product and join workspaces through the use of a free trial.  The process of inviting a new user to a workspace is simple, requiring only an email address.  Once the user is up and running on the trial version, they can easily upgrade to a paid version. 

We have preserved this valuable model of ‘viral adoption’ with Groove 2007.  Office Live Groove will be the ‘full product’ available for small businesses and workgroups – essentially anyone whose organization does not purchase Microsoft software under a volume license or enterprise agreement.  Just like today, small businesses and workgroups will be able to download the Live Groove trial and start collaborating in minutes.  We haven’t finalized the trial mechanism yet, but it will be similar to the current model for OneNote. With this program you download the software and are issued a product key which ‘expires’ at the end of the trial period.  Once expired, the application enters a reduced functionality mode until you purchase the full product and enter a new product key.  You don't have to download additional software, just 're-activate' using the new key.

The key difference between the paid version of Office Live Groove and today’s Groove v3.1 offerings is that Office Live Groove will be a subscription offering sold on an annual basis.  The subscription includes the client software as well as access to the Microsoft hosted Groove relay service and directory.  The subscription model lowers the initial purchase price and includes product upgrades made available during the subscription term.

Office Live Groove users and Office Groove 2007 users will be able to work together without limitation.  Both client offerings are identical in terms of features and functionality, and will include all the new capabilities including localization and integration with other Office system applications.  The only difference between the products is the way they are purchased, deployed and managed.

Many customers have already asked me about the relationship between Office Live Groove and the other Office Live offerings.  While I don’t have anything specific to share today, over time, you can expect to see Office Live Groove becoming part of the broader offerings of Microsoft Office Live Services. 

More information about Office Live Groove can be found here.

This week we announced the packaging and naming plan for Office 12. This is the point in the project where the internal discussions start to shift from ‘what are we going to build’ to ‘how are we going to sell it.’ If you’ve read my earlier blog posts about Groove 12 it should come as no surprise that from the beginning of the release we knew that if we were to achieve a breakthrough in Groove adoption that it had to appeal to our Enterprise customers.

Microsoft Office Enterprise 2007 is a new offering that builds on the capabilities of Office Professional Plus 2007, extending the collaboration and mobility scenarios by including Office Groove 2007 and Office OneNote 2007. In addition, Groove 2007 will also be available as a standalone offering.

Office Groove Server 2007 combines the previously separate Management, Relay and Data Bridge servers into a single product, giving organizations more flexibility about when and how they deploy the Groove servers. Organizations can decide which components they wish to license based on their needs.

Groove Enterprise Services provides Microsoft-hosted management and relay services for smaller deployments and as for pilot projects as part of a larger enterprise evaluation.

The integration with the rest of Office, detailed in my previous blog posts, reinforces the long term value we see in Groove as an enabler for a new set of scenarios around collaboration. If you think back to when Outlook was first included in Office, it came at a time when email wasn’t a standard part of the IW desktop, and most collaboration was document based. Now email is ubiquitous, and Outlook is at the center of many individual information worker’s day. With Groove we hope to transform the ways that teams work together, using the workspace as the framework for efficient collaboration, and providing another place and tools for work to happen. Groove will help solve the ‘inbox overload’ problem by moving some activities out of the inbox where information can get lost and into workspaces where the information and people can gather to focus on the shared deliverables.

In support of our enterprise offering for Groove, we invested in lowering the barriers to adoption and deployment. In addition to simplifying the server installations, the desktop software deployment and management process has been streamlined to ensure that Groove can become part of a standard desktop deployment. One of the challenges with Groove today is that you don’t know whether someone else is using Groove until you’re in your first workspace with them. The current distribution model helps to solve that by making free trials available, but within an enterprise, managed desktops often prevent non-approved software installations, so getting Groove deployed along with the rest of Office will make it easier for people to ‘Groove’ together.

As we look to the upcoming Beta 2 milestone, we’re excited to be delivering a compelling set of new features, including a set of investments intended to make Groove a world-class enterprise application, ready for deployment worldwide. We recognize that this is just the beginning of realizing the potential of the shared workspace as an information worker tool, and we look forward to your continued feedback as we launch Beta 2 and over the coming year as we get ready for the final release.

I’ve received several questions about the future of the current Groove APIs in Groove 12. The plan is to continue to support the same set of integration and customizations APIs built on Web Services and Groove Forms that exist for 3.1, with a few exceptions.

The Groove Forms tool is intended for lightweight team collaboration solutions, with the primary scenario involving data input in a common environment for the team (sales leads, customer information) which is then exported out of Groove for use in other tools. In Groove 12 you can use the new InfoPath Forms Tool to host InfoPath as the UI for this type of solution as well.

Here’s a summary comparison of the two forms solutions:

The Groove 12 Forms Tool has been improved in two key ways over the version that ships with Groove 3.1 with the goal of increasing performance for large solutions. The first improvement is to change the way that forms records are stored so that each form in the tool has its own records definition with just the fields used on that form (rather than each form knowing about all of the fields used in the entire tool). This change to the data definition required an update to a new version of the tool that isn’t backwards compatible with version 3.1. The other change was in the forms designer where an updated version of the tree control was used which works better for forms that contain a large number of fields.

Two Forms script APIs have been deprecated in Groove 12: SendEmail and SendInvitationToChat will no longer function in either new or existing solutions.

The introduction of the new version of the forms tool means that new forms solutions created in Groove 12 will not run on Groove 3.1. In Beta 2 you’ll be able to migrate existing forms solutions to the new format by saving the tool in Groove 3.1 as a Tool Archive and then opening it into Groove 12. Groove Workspace Archives that contain forms will preserve the Version 3.1 format when loaded into Groove 12.

Groove Web Services capabilities (including the Groove Data Bridge Server) remain largely the same with some updates to reflect the new capabilities of Groove 12. The first update is to add support for the capabilities of the new Forms tool, and in particular the creation of GrooveForms2, a new service that gives access to V12 forms tools in a workspace. The significant update here is that the RecordDataSet schema may now contain multiple record definitions, each bound to a particular form in the tool. The GrooveFiles service was updated to work with the new SharePoint Files tool.

Two services (GrooveDiscussion and GrooveFilesDIME) are deprecated in Groove 12 but will still continue to work for 3.1 solutions opened in Groove 12. SendInvitationToChat is deprecated and will not function in Web Services in Groove 12.

A more detailed overview of developing Groove 12 solutions as well as access to the Groove 12 SDK can be found here.  The documentation and SDK here are in beta form, so expect updates to both during the Beta 2 timeframe.

Most of this discussion so far has been about the Groove client and client features.  Today let’s take a quick look at the plans for some of the Groove infrastructure components.

While it’s true that Groove operates primarily as a peer-to-peer replication system, for many scenarios (such as firewall traversal), peer-to-peer alone isn’t sufficient to provide the type of seamless replication that people expect.  The Groove Relay operates either as a service (for individual or hosted use) or as a server (for enterprise use) that provides store and forward capabilities for data updates to members who are offline, as well as a rendezvous point for devices that are behind firewalls.

These capabilities, of course, remain a key part of Groove 12.  The primary investment for the relay server in Groove 12 is in the area of scalability, for both the hosted and enterprise environment.  For the hosted environment this resulted in the creation of a ‘Deployment Unit’ that can be scaled out easily through the addition of additional DUs to the data center as the number of customers grows.  The first DU went live at the new MSN data center on the East Coast in November and is the relay that’s servicing Beta 1 customers.

For the Enterprise Relay, the scalability improvements were achieved by switching to a 64-bit implementation as the only supported configuration for Groove 12.  While the final recommended configuration and capacity planning numbers are still being developed, in the lab the standalone 64-bit relay has sustained nearly 50,000 simultaneous connections, up from 20,000 in Groove 3.1.  We’ll of course publish final performance data and deployment planning guides as we get closer to Beta 2 and the final release.

As I mentioned in my earlier post, one of the areas for integration (and rationalization) for Groove in Office 12 is how to thing about Groove Messaging as it relates to Instant Messaging and E-mail.  Groove Messaging (GM) in many ways is a hybrid of email and IM; like mail, it doesn't require a synchronous connection to the recipient.  But, like IM, the capabilities are intended for short messages to a single person, outside of the context of a particular workspace.  Groove Messaging also uses the Groove infrastructure for secure message delivery, enabling direct peer-to-peer delivery or staged delivery through the relay server.

In Groove 12 the existing messaging capabilities remain, but we're adding integration with Windows Messenger (and Office Communicator) that will allow Groove users to take advantages of those parallel communication channels from within the Groove client experience.  If you are using Windows Messenger or Office Communicator, Groove 12 will detect that on install and look on your buddy list for Groove users and offer to add them to your contact list in Groove.  This, for the new Groove user, jump starts the set of people who they can easily Groove with.  Groove will look on the local network segment for active Groove users, in your 'known Groove users' list if you've already run Groove, in your domain director and in the Public Groove directory to match your buddy list (via email address).

For all contacts who are on your buddy list, Groove will show enhanced presence within Groove for each contact.  In this example, Eric is online (but idle) in Groove, but not in Messenger:

In this example, Ken is online in both Groove and in Messenger (but Groove picks up his 'Busy' state from WM):

You can also see from these screenshots that Groove has adopted the same 'Presence' icons as Office Communicator, with the same look and colors visible in Groove and in Communicator.

The other benefit of doing this integration with Windows Messenger is that you can take advantage of other messaging protocols supported by WM or Office Communicator from within Groove.  You can IM any Groove user who's on your buddy list from within Groove, regardless of their IM service provider.  By abstracting the IM implementation behind Windows Messenger, Groove will be able to take advantage of future enhancements to Office Communicator or Messenger to support new messaging protocols.

In addition to IM support from within Groove, we also get to the ability to initiate other forms of communication available to the WM or Office Communicator user, such as VoIP, telephony integration and additional 'verbs' that get exposed over time.  In the example below you can see that I can direct dial Ken Moore, right from within Groove:

Over time you'll see this list of verbs and extended presence information grow as we continue to work with the Office Communicator team on making it easy to transition between asynchronous and synchronous forms of collaboration.

In addition, your buddy list will also be a search source for invitations to workspaces, so if you're adding someone to a space, the typeahead capability will include people on your buddy list who may not yet be Groove users.  If you add them to a space, they will receive an invitation via e-mail which will include a link for where to download Groove as well as the invitation itself (both as a file and as a downloadable link).

In my previous post on Enterprise Ready I didn’t get a chance to talk about Improving User Success and Supportability in Groove 12.  Since Groove 12 will be the ‘first’ Microsoft release of Groove, it will be the first version of Groove to follow the Microsoft support policies and guidelines.  While there are a wide range of support options, the simplest way to think about this commitment is that Groove 12 will have a support timeline of 10 years from initial release, just like the other Microsoft Office applications.  In addition to supporting the product, we’ll also do necessary updates for security, Watson or other issues discovered by customers through sustaining engineering efforts.  The transition from Groove 3.1 to Groove 12 gives us a ‘one time’ opportunity to step back and look at the existing capabilities in 3.1 and decide which areas of the product should be carried forward and which should be deprecated, at least in the initial Groove 12 release.

The decision to not ship a feature is not one that we take lightly, as existing customers will be impacted.  However, when weighing the utility of an existing feature against the dual costs of adapting it for localization and needing to do maintenance for 10 years, we made decisions to remove some capabilities to enable us to focus on the core value and deliver the highest quality release possible.

One feature that I’ve already discussed  is the Groove Mobile Workspace for SharePoint template, which will be replaced by a new set of capabilities around WSS 3.0 and the new SharePoint Files Tool.  This was a case where we felt that the integration model needed to be different and chose to take the feature in a different direction.

We’re introducing a new workspace format with Groove 12 that will require all members of new workspaces to be running Groove 12.  Groove 12 users will still be able to accept invitations from other users who are running earlier versions of Groove and load existing workspaces and tools, but all new workspaces will be created in the new format.  One of the implications of this, of course, is that during the migration to Groove 12 where people are using mixed versions of the client that the initial creation will either need to be from a workspace template saved from Version 3.x, or that the space manager will need to be running Groove 3.x.  The key reason for this decision is that there are older tools that we don’t want to continue supporting in Groove 12, such as older versions of the Forms tool, so all new workspaces need to be built on the workspace format and tool versions that ship with Groove 12.

The question of which tools to carry forward also needed to be considered.  One decision that we made was to re-write some tools (discussion and meetings) based on the Forms tool; this means that the old tools, while still supported in 3.x workspaces, won’t be available for addition to Groove 12 workspaces.  So, same capabilities as before, but built on a better foundation for future enhancements. 

There are some tools that we are not carrying forward in any fashion for Groove 12.  These include Web Links, Document Review, Welcome Page, Outliner, Tic-Tac-Toe, and the Family Groove and Amateur Sports toolset.  The Groove 12 Beta 1 Help file contains a complete list of the deprecated tools.  Of these tools, the Document Review tool is the hardest one to not ship in the initial release, but in analyzing the work needed to respond to existing customer feedback about the usability of the tool and the work to make the tool work worldwide, we decided to defer shipping this tool (or replacement capabilities) until a later release.

Other features that have been removed are the on-ramp and synchronization between Outlook and Groove.  These features will likely surface in a future release as we look at a different integration mechanism as the scenarios of moving context and information from e-mail (or other tools) into a Groove workspace are important.

Another change which has implications for how people move their Groove information from machine to machine is the ability to ‘save’ account information to the Groove unmanaged hosted services.  In Groove 12 we’re eliminating this feature in favor of using a locally saved account file which the user moves from machine to machine to enable that same account on multiple machines.  The ability to do account backup and restore does remain as a feature of the paid-hosted or self-hosted Groove Management Server.

One area where we’ve removed features in favor of a different implementation is in the area of Real-time Communications.  By moving to a tighter integration model with Windows Messenger and Microsoft Office Communicator, we’ve decided to discontinue direct support for Lite Chat and XMPP (Jabber).  I’ll talk in more detail about our work in this area next week.

While the lack of some of these capabilities will be a near-term challenge, we’re committed to listening to feedback about these changes as well as the other new capabilities in Groove 12.

My first face-to-face meeting with the Groove development managers occurred two days after the acquisition closed.  We'd talked on the phone in the last week or so leading up to that date as I tried to learn about how to start my new job and we tried to learn a bit about what it was going to be like to work together, with me in Redmond and Eric Patey and Ken Moore at the Groove facility in Beverly, MA. 

Where did we meet?  Of all places, at a restaurant in Dublin, Ireland over dinner with another Groove engineer, David McCall.

Why Dublin?  Well, partly it was because our new boss, Steven Sinofsky, was going to be there visiting the R&D team there that is responsible for the localization of Office.  It's also about the same distance from Boston to Dublin as it is from Boston to Seattle.  Besides, the Guinness is better there.

The real reason was that a top goal for Groove 12 was to ship worldwide in the local languages of the major markets for Office.  We were in Dublin to learn from the experts about the challenges of shipping Groove worldwide with local language support.  The Microsoft team in Dublin has been instrumental in making it possible for Office to be translated efficiently utilizing a standard set of development tools and practices.  They oversee an army of vendors who do the actual translation of the strings and User Interface of the product.  They've also driven the advancement of the features in the products and our supporting development tools which make it possible for multi-national organizations to work more effectively across language and country boundaries. There's a great description of these capabilities in Office that you can find here.  Being able to reach workgroups around the world in the local language will be an important part of the value of Groove 12.

In Dublin we had a chance to learn about the best practices and tools and begin the planning for the work needed to plug Groove into the Microsoft Office Globalization machine.  Fortunately, it had been a goal to translate Groove for use worldwide, so most of the code architecture (things like Unicode and separation of string resources) were already in place.  Much of what remained was adapting that implementation to match the tools provided by the Microsoft team in Dublin and doing the actual testing work to make sure that Groove worked correctly in a language other than English.

We use several techniques to help keep the Office products localizable throughout the engineering process.  One of the more interesting is to do a translation of the product into a fictional language that we call PsuedoLoc.  What it does is generate a string of random characters from multiple character sets for each localizable string, but keeps around enough of the English so that you can effectively 'read' the UI.  Here are some examples of what Groove looks like running the PsuedoLoc build:

Logon Screen:

Launchbar:

Workspace:

Notifier:

"Are you sure you want to exit?" alert:

You can see from these examples that the human mind can adapt pretty well to the new patterns and enable you to continue to read the UI and navigate.  The benefit of this approach is that it allows the engineering team to run full-time in a non-English language build without having to be able to read a particular non-English language.  Very helpful in preventing 'accidental' hard-coded UI from creeping in to the code, as well as validating the correct handling of UI strings that contain Unicode text.

Another tool that's very useful in the localization process is called Dialog Auto Layout, or DAL.  DAL-enabled dialogs are Win32 dialogs that are implemented as one of the shared utilities in MSO.DLL.  DAL dynamically sizes the dialogs at run-time so that there's no fixed dialog sizes embedded in the code.  This means that the localization can be done just an an exercise of string translation, rather than having to both translate the strings and update the dialog templates with a new layout.  This approach means that the localization vendors don't have to touch the dialog templates, which are effectively 'code'; it both reduces the work for them and minimizes the chance for errors.

Being able to switch between languages is a feature that's been in Office since XP and is documented above; DAL is an essential part of being able to support the Multilingual User Interface Pack.  MUI lets you easily switch between different language versions without having to re-install the application.  It also lets you switch between different grammar and spell checkers 'on the fly'.

The Groove 12 Beta 1 release only shipped in English, but we'll have several additional languages, including Japanese, available for download and testing for Beta 2.

During the initial planning for Groove 12 we discussed three areas of possible integration with other Office 12 initiatives. I’ve already covered the plans around SharePoint. The other two investment areas that we decided on were support for InfoPath as it related to Forms based solutions, and better integration with Microsoft Communicator.

The Groove Forms Tool is used in Groove 3.1 as an easy way for non-programmers to build custom data entry solutions and can be extended with scripting to make fairly sophisticated solutions. For Groove 12 we’re adding another version of the Forms tool that uses InfoPath as the design surface and data entry UI but utilizes the underlying database from the core Forms tool for record storage and replication.

Since its introduction in Office 2003, InfoPath has become the forms solution for many Office scenarios, and by adding InfoPath support we enable an organization to build a single InfoPath solution and be able to utilize Groove as another place where employees and team can use the same data entry mechanism that they use in other environments.

Let's look at the process for getting from a new workspace to having a functioning InfoPath form running inside of Groove.  To use these new capabilities, you add the InfoPath Forms Tool to a workspace, and then import the solution that you’ve already created in IP into this tool.

Once imported, you have the chance to create any additional Groove-specific design objects (Groove Forms Views, Macros) that you want to associate with the solution in Groove.

The form is then saved into the Groove tool where you can create the overall Groove options for the form.

At this point you need to define the Forms Tool view you want to have show in Groove in list view.

Once saved, you’re done and can now create new records in the tool.

Not all InfoPath solutions will be supported in Groove. On import Groove will check for attributes of the solution that are either not recommended or that will cause an error and will flag those during import.

There are some requirements that have to be met as well as some recommended ‘best practices’ when designing an InfoPath solution that will be hosted in Groove.

Required:
• The form must be configured to “submit to host environment”. This is a feature of InfoPath 12, so Groove will only support InfoPath solutions that have been created or saved with InfoPath 12.
• Trust Model: The Infopath solution must be “sandboxed” (restricted), not Domain Trust or Full Trust.
• Every promoted field must be one of the xsd types that map to a Forms field type in Groove. Not all InfoPath field types will be supported for promotion.

Recommended:
• The form should include at least one designer-defined set of fields for promotion to column view.
• Secondary UI (taskpane, menu, menuarea, or toolbar integration) is not supported
• Custom Validation. Groove cannot guarantee the integrity of data maintained using custom validation.
• Using external data adapters should be carefully considered as Groove functions fine in disconnected or offline scenarios, and solutions which require a connection to a data source to function won’t work while the rest of Groove will.support for using any data adapter (HWS, Sharepoint, etc) from within Groove [I’d also remove this. Forgot exactly what I said in the spec, but its not so much that we don’t support this; its more that data adapters like this require connectivity, and Groove solutions shou;d nt depend on being online].
• Since the forms tool has it’s own UI for “submit behavior” (create another, etc), Groove will override the onAfterSubmit behavior defined in the solution.
• The form should be robust to online, offline, austere, and occasionally connected environments, just like other Groove tools.

Once the InfoPath solution is imported and saved into the tool, the solution is synchronized to all members of the workspace. Each user of the IP tool will be required to have InfoPath installed in order to use the tool (there’s no InfoPath run-time distributed automatically to the desktop).

A designer can choose to make updates to an existing solution that has already been imported into Groove. The “InfoPath Forms” tool will have a “Re-Import” button. A browse dialog will be presented to allow the designer to select the updated solution file. On import Groove will:

• Verify that the solution being re-imported is an updated version of the solution previously selected. The solution URN is the identifier for this check. If it is not, the re-import will fail.
• Groove will reconcile the list of promoted fields with the list of fields already in the Forms Tool.

InfoPath has built in functionality to perform an “upgrade” when a document is first opened with a new version of a solution. On solution re-import, the Forms Tool will not attempt to revisit and update any existing records/documents in the Forms Tool. When a user on any endpoint navigates to the record created with the old version of the solution, it will be updated; when the user saves it, the updated document will then be saved back into the tool. This means that existing records will not get updated until they are manually opened in IP and resaved; all new records will conform to the updated form design.

Data in the InfoPath Forms tool can be accessed using Groove Web Services. In addition to accessing the promoted field values in Forms Tool records, the underlying InfoPath (XML) document can also be accessed using Web Service as a file attachment to the data record.

The schema(s) for InfoPath documents will not be accessible through the Web Service. The Form design name can be used by Web Services to discriminate between different forms solutions. In addition, a Web Services application can inspect the PI in an InfoPath document to determine the unique solution URN that generated that document.



 

One of the initial discussion points when we were planning Groove 12 was the question of what does it take for Groove to be increasingly ‘Enterprise Ready.’  Of course the initial vision of Groove was to enable teams to work together seamlessly despite IT, so the free trial, web download of the software and the ability to just ‘create’ your own identity and account are all features that are in tension with the legitimate need for enterprise IT to manage their information assets.  Groove 3.1 already contains a number of features intended to enable the deployment of Groove in an enterprise environment, such as the Management Server, which can set policy for Groove usage and automatically provision Groove accounts and identities based on Active Directory or other LDAP directories.

As we discussed this question and the corollary of ‘Being Office’, there emerged a long list of capabilities and requirements that we had to consider.  I was part of the first ‘shared engineering’ team in Office 2000 where we explicitly created the first version of the MSO.DLL, a place for features that we wanted to be in every application.  This has grown to be a considerable part the code in Office, and includes capabilities around common UI, spelling and grammar checking, Open/Save dialogs, Installation and Licensing, and Watson and SQM and Digital Rights Management (to name a few) along with numerous lower level shared routines.  Despite the shared code nature, there’s still an integration cost associated with adding these capabilities to a particular application; our internal rule of thumb is that when a shared team creates a feature intended for all of Office, then they also do the integration work to make it work in every application.  This ensures that the design takes into account the particular requirements and needs of all of the applications.  Of course there are negotiated partnerships where the shared teams and the application teams work together on features, particularly when the integration represents a fundamental change to the product.  Jensen talks about this kind of partnership extensively in his ‘New UI’ blog.

For Groove 12, given the timing of the acquisition and the number of calendar days until Beta 1, we approached the analysis not based on some fixed checklist of requirements, but rather one that let the engineering team balance the benefit of making a change vs. the opportunity cost of doing a particular ‘Office Tax’ feature.  The watchword from Steven Sinofsky was ‘let’s be pragmatic…but not too pragmatic.’  So, there had to be room for new features as well as time to do some rework for capabilities, such as Setup, which were already functioning in Groove 3.1.

One of the decisions that came early in the process was that Groove would definitely integrate MSO.DLL into the product.  It became apparent that there were obvious benefits of making that transition, even if we didn’t integrate all of the available features in the first release.  Once this decision was made, it lowered the barrier to doing additional integration work.

In the end, we decided on the following features that would fall into the bucket of ‘Enterprise Readiness’:

• Use of the Office installer and activation process
• Spell and Grammar checking
• Integration with Watson and SQM for feedback reporting
• Global reach and scale
• Raise the bar on initial product quality at RTM
• Improve User Success and Supportability

Setup is an area of product development that is frequently under-invested and often becomes the barrier to deployment if the installer capabilities don’t match the customization or deployment needs of the organization.  In Office XP we devoted a significant percentage of the release to reducing TCO, streamlining deployment and enabling long term manageability of Office.  The Groove 3.1 installer was initially built for web download and individual installation rather than enterprise deployment, and the version that was adapted for use in the enterprise environment was difficult to customize and maintain.  So while there was an installer, very early in the discussions the decision was made to move to the Office installer and benefit from the consistency and capabilities that would come once that work was completed.  This was a significant investment, larger than I think we initially thought, but now that it’s complete it should reduce the internal maintenance issues and open up a wide range of install and deployment scenarios, such as the ability to do binary patch updates of Groove instead of updates requiring a download and install of an entire new version.

Spell and Grammar checking was an easy choice as it let us ship Groove using the same tools as the rest of Office and benefit from that licensed code that already ships with Office.  Doing this work also set the stage for the Globalization effort for Groove since we could pick up spellers and grammar tools in all of the languages supported by Office.

Watson and SQM are important feedback loop mechanisms that we rely heavily on for sustaining engineering work as well as evaluating overall customer satisfaction.  Chris Pratley does a great job of describing this in his blog, so I won’t go into any more detail here.  This investment was another case where we migrated from a Groove specific system for crash reporting and monitoring to the Microsoft version.

Regarding product stability at RTM, one of the realities of a small software company is that as you’re acquiring customers and validating scenarios and features you need to be able to respond quickly to feedback.  This typically means rapid product updates, measured in weeks and months.  For Office, as part of our push for more predictable TCO, we’ve made our product release and update process match the pace at which customers can absorb both new releases and updates.  Steven’s recent blog entry covers the history of this very well.  So for Groove 12, the goal is to spend additional time in Beta prior to release to raise the level of quality and stability, hopefully to the same level or greater than the current 3.1 release has achieved after several iterations.  I hope that many of you will join us in the Beta program and we look forward to your feedback.

I’ll cover Globalization and Improving User Success and Supportability in a subsequent post.

One of the first questions I get from customers is 'Tell me about the relationship between Groove and SharePoint.  Aren't they just the same thing?'  They are certainly related, both being intended for team collaboration, but there are a number of differences and we think that the two tools are complementary, today, and even more so over time.

So what is Groove, anyway?  Here’s an overview:

Groove 12 is a collaboration system that allows teams to securely share information and work together on project activities, from simple document collaboration to custom solutions integrated with business processes.  Teams using Groove work inside collaborative workspaces, which put all team members, tools and information in context and make it easier to organize and find information.  Using peer-to-peer replication, Groove workspaces keep teams up to date automatically and efficiently, and let them work anywhere, anytime, with anyone, so they spend less time coordinating and more time working.  There are five core elements to Groove:

1. Launchbar—a single starting point for the information worker to monitor all Groove elements including workspaces, contacts, presence, and alerts, and to execute basic functions such as creating new workspaces and communicating with or inviting users.
2. Workspaces—containers created by information workers to share information and work together on team projects.  Workspaces are kept up-to-date between members through peer-to-peer replication that happens automatically as members make changes to workspace content.
3. Presence and Communications—built-in presence awareness, chat and messaging.
4. Alerts—text and audible notifications that inform workers of events and changes in ongoing projects.
5. Tools—applications added to workspaces by team members for the purposes of sharing and working together on information, both structured (for example, forms) and unstructured (for example, files).

Groove 12 includes the following tools: Discussion, Files, SharePoint Files, Meetings, Calendar, Forms, InfoPath Forms, Issue Tracking, Notepad, Pictures, and Sketchpad.

Those of you familiar with Groove won’t see much of a change between Groove 3.1 and Groove 12.  That’s intentional, as we’re largely keeping the product the same and adding Office focused enhancements.  The description above can largely be applied to any ‘collaboration system’ for teams, so you might imagine the discussions we’re having about the relationship between Groove and Windows Sharepoint Services (WSS) team sites. 

So, let’s talk about that a bit.  As Mike pointed out around the time of the acquisition, the ‘cached mode’ nature of Groove provides the same benefits that it does for work done with Exchange and Outlook.  However, for WSS, it’s unlikely that there’s a strict model where you need to bring your entire team site with you all the time.  In Groove 3.1, the integration with WSS used that model.  For Groove 12, we’ve taken a different approach that we think matches more closely how we think people work as well as being more in-line with the long term direction for WSS and Groove. 

Most of the work done in Groove is ‘project focused’ in nature.  A subset of a team goes off to update a presentation or create a report, and then they publish it out to the rest of the team.  With Groove and WSS, this describes a natural extension of the team site as the hub for all activities, with some of the ‘work’ happening in a Groove workspaces, to be ‘shared’ (when ready for publication or review) with the team in WSS.  Taken further, you can see the role that the SharePoint portal plays in rolling up information across teams to give the broader organization a view of activity happening elsewhere in the company. 

To this end, we’re deprecating the current Mobile Workspace for SharePoint template that ships in Groove 3.1 and changing the model to be more focused on bringing the subset of important information from WSS into Groove.  In Groove the team uses the workspace to ‘get the work done’, and then that is shared with the team by updating the information back in WSS.  The model shifts from ‘site replication’ to ‘list replication’.

For Groove 12 we are introducing a new SharePoint Files Tool that lets you bring a particular document library or a folder from a document library into Groove.  The ability to just synchronize against a particular folder (and it’s sub-folders) is important for sites where there may be one single, large document library for the whole site.  If the doc library is organized using folders that map to activities or project teams within the group, it makes for a natural mapping for those teams to be able to bring their content into Groove and work with it locally.

Once the synchronization relationship is established, content is then shared among the other members of the Groove workspace, even if they don’t have access to the WSS site.  Files can be ‘checked out’ from Groove against the WSS document library to ensure that the ‘project team’ can lock the document against updates on the server while they are working in the Groove space.  Further, files and folders can be added in Groove and those are added to the WSS document library when the workspace is synchronized with the source document library.  When you sync, updated content from WSS is also brought automatically into Groove.

This synchronization is either an intentional, manual publishing process, but can also be set up so that the Groove workspace synchronizes at regular intervals with the WSS site. 

As you might imagine, it’s our goal over time to introduce additional tools that map to other WSS list types, as well as strengthen the features in Groove that make it a great place for teams to 'work together' using all of the benefits of 'cached mode', with updates automatically pushed to their machine, as well as the affordances of the rich client environment.

Welcome!  My name is Marc Olson, and I'm the Group Program Manager for Groove Integration, based in Redmond.  I've been with Microsoft since 1989, and most recently was the Group Program Manager for Outlook 2003 and Outlook "12".  In early April, Steven Sinofsky stopped by my office in building 36 and asked me if I would consider joining the Groove team.  His goal:  help make Groove an integral part of Office 12, and be the 'guy in Redmond' who could work with the team based in Beverly, MA on how, exactly to get that done.  After a few questions ("Do I have to move to Boston?"), I said yes, not really knowing what exactly this new role would entail.

Here we are, some seven months later, on the verge of releasing Office "12" and Groove "12" to beta, and I'm glad that I chose to join the team and look forward to sharing with you my side of the Groove "12" story.

So what's the Groove team been up to since March?  This blog will tell you about our plans for Groove in Office 12 as well as some perspectives on the longer term role that Groove will play in Office and at Microsoft.  We had a very aggressive schedule, so we set some clear priorities around what was important to do for the 'first' release of Groove as part of the Office family.  In a sentence, Groove 12 needed to be enterprise ready, able to ship worldwide, and also integrate with Office 12 in a meaningful way.  We also wanted to join the Office 12 engineering wave by Beta 1, which meant doing several milestones worth of work 'out of sync' with the other Office teams, but then being coordinated from that point forward in the project.

Over the coming weeks I'll detail the investments we've made and what you can look forward to seeing in Beta 1 and beyond.