http://blogs.msdn.com/chrisnorman/atom.xmlCommunity Server2006-10-22T17:05:41Zhttp://blogs.msdn.com/chrisnorman/archive/2006/12/19/groove-forms-and-groove-infopath-forms-part-3-which-tool-should-i-use.aspx2006-12-19T15:37:45Z2006-12-19T15:37:45ZPart 1 of the series is here. Part 2 of the series is here. In past posts, I've outlined some of the differences between the Groove Forms tool and the Groove InfoPath Forms tool. Armed with that background, we can begin to see the criteria to use when deciding which tool to use for a given application. Some reasons you may want to choose Groove InfoPath Forms: You already have an existing InfoPath Solution that meets Groove requirements ( enumerated here ) or that can easily be modified to meet Groove...(<a href="http://blogs.msdn.com/chrisnorman/archive/2006/12/19/groove-forms-and-groove-infopath-forms-part-3-which-tool-should-i-use.aspx">read more</a>)<img src="http://blogs.msdn.com/aggbug.aspx?PostID=1324658" width="1" height="1">Chris Normanhttp://blogs.msdn.com/members/Chris+Norman.aspxhttp://blogs.msdn.com/chrisnorman/archive/2006/11/26/groove-forms-and-groove-infopath-forms-part-2-infopath-solution-requirements.aspx2006-11-26T21:19:01Z2006-11-26T21:19:01ZPart 1 of the series is here . I want to talk about some of the constrains and requirements that Groove has when using InfoPath. There is one point of potential confusion that is worth addressing up front though, which is the use of the term "view". In Groove Forms terminology, we use the term "view" to describe a custom aggregate list view of a group of form records. InfoPath generally works with a single form, and uses the term "view" to refer to alternative presentations of a single form. I'll...(<a href="http://blogs.msdn.com/chrisnorman/archive/2006/11/26/groove-forms-and-groove-infopath-forms-part-2-infopath-solution-requirements.aspx">read more</a>)<img src="http://blogs.msdn.com/aggbug.aspx?PostID=1154559" width="1" height="1">Chris Normanhttp://blogs.msdn.com/members/Chris+Norman.aspxhttp://blogs.msdn.com/chrisnorman/archive/2006/11/16/groove-forms-and-groove-infopath-forms-part-1-data-storage.aspx2006-11-16T23:38:05Z2006-11-16T23:38:05ZI've had a few conversations lately with solutions developers about the Groove InfoPath Forms tool, and one of the first questions that comes up is how to decide when to use the Groove Forms tool and when to use the InfoPath Forms tool. In order to understand the tradeoffs, it helps to understand the differences in the underlying data storage used by the two tools. Tool Versions Before I get into that, though, we need to talk about tool versions. Groove 2007 ships with several versions of the Forms...(<a href="http://blogs.msdn.com/chrisnorman/archive/2006/11/16/groove-forms-and-groove-infopath-forms-part-1-data-storage.aspx">read more</a>)<img src="http://blogs.msdn.com/aggbug.aspx?PostID=1088626" width="1" height="1">Chris Normanhttp://blogs.msdn.com/members/Chris+Norman.aspxhttp://blogs.msdn.com/chrisnorman/archive/2006/10/22/groove-for-developers.aspx2006-10-23T00:05:41Z2006-10-23T00:05:41ZMy name is Chris Norman, and I'm a dev lead on the Groove team. I've been working on Groove for almost 6 years, and have mostly focused on the Groove APIs, the SDKs, and extensibility. I'm currently working on the Groove Forms tool, the Groove InfoPath Forms tool, Groove Web Services, and the Microsoft Office Groove 2007 SDK . I plan to blog mostly on topics related to Groove development and extensibility. Some topics I have in mind are using the InfoPath and Forms tools, and Groove Web Services...(<a href="http://blogs.msdn.com/chrisnorman/archive/2006/10/22/groove-for-developers.aspx">read more</a>)<img src="http://blogs.msdn.com/aggbug.aspx?PostID=857279" width="1" height="1">Chris Normanhttp://blogs.msdn.com/members/Chris+Norman.aspx