Note: This is rather long post. My 14-year-old son Jason and I have been using Microsoft Student 2006 since the beginning of the current school year with the intent to develop a real-world, in-depth analysis of the benefits it can provide for middle school students preparing for the transition to high school. Given that the holiday season is upon us and we adults are always looking for gift ideas that have a longer duration than current teen fashion trends (which can be just slightly longer than the life span of a Mediterranean fruit fly), we thought right about now would be a good time to publish this review and let you know whether this might be an item for the student in your life (son, daughter, niece, nephew).

Making the transition from middle school to high school can be a pretty traumatic time. I've helped guide one kid through this already and am now on my second (and blessedly last) "bridge year". It's an awkward in-between time of life.

Note: In an early draft of this review, I used the word "tween". Jason says never, ever use the term "tween" if you want to avoid being struck.

This in-between time includes a decided gap in age-appropriate software. Yes, software. Think about it. There's a ton of educational software for grade school aged kids. There are college prep packages for high school students. But what tools exist for the student about to make the leap from middle school to the wilds of high school?

There's a "cool" issue at work here as well. The days where Pajama Sam and The Oregon Trail were engaging diversions are long past. I mean, we're talking role-playing games RPGs, console systems, Dance, Dance Revolution at the arcade, first dates, first cell phones, iPods, and a burgeoning interest in music, games, and movies with slightly out-of-reach ratings.

When I first learned that Microsoft was planning the release of a package called Microsoft Student, I must admit I didn't give it a lot of thought. But, in perusing the press release, I learned that this new package was specifically designed for students at this stage of educational evolution. I figured it could either be a great way to focus some "screen time" on academics rather than RPGs or it would be a total bust - another well-intentioned but ultimately misguided attempt by some marketing sharpie to get into the minds of the youth market.

So I pitched my son Jason on the idea of doing a long-term evaluation of the product. We would both install Microsoft Student on our respective PCs and evaluate it in a real-life way - by using it as a tool for the first part of his eighth grade year. Our criteria for judging the value in the Student suite would be multi-faceted but would come down to a real bottom-line measure - did it help improve his performance?

Following David Allen's example, I've decided to post the entire e-mail interview I conducted with Robert Andrews about Getting Things Done. We discussed a number of topics that, due to space considerations, din't make it into the online article. After the jump for those interested.

I had the opportunity recently to pose a few questions to Mike Jetter, the founder of Mindjet - makers of MindManager X5 which long-time readers know is one of my favorite applications for the Tablet PC (or any Windows PC truth be told).

Mike's story is compelling and well told in a book he authored with his wife Bettina, The Cancer Code. This inspirational two-person biography (he and Bettina tell the tale in alternating chapters) documents how Mike overcame a long battle with leukemia and developed the early versions of MindManager. From those early days in a hospital room in Germany, Mindjet has grown into a global company now headquartered in Larkspur, California with customers around the world.

In a wide-ranging discussion, Mike talked about how Mindjet has achieved their success and offers some excellent guiding principles for other software developers seeking to provide solutions for their customers.

Michael Kiselman is a Technical Product Manager for the new Information Bridge Framework (IBF) at Microsoft. Introduced at the recent TechEdge Conference in San Diego, IBF provides a framework for connecting disparate sources of enterprise information from back-end systems like ERP and CRM to Office 2003 Professional applications via web services and WinForms. The benefits can be compelling.

Microsoft paints a picture of office workers in sales, customer service, and support having instant access to information about a customer in the familiar environments of Outlook and Word. The elimination of proprietary client software used to access each of these back-end systems reduces licensing, support, and training costs. And the reduction in "context switching" from one application to another to gather, transfer, and manipulate information also provides big potential savings and productivity gains.

I posed a number of questions to Michael about the vision for IBF and how it may impact the way knowledge work is done.

Marc Orchant: IBF seems like a tremendous idea but it feels like it's going to take some time before it really has an impact. Can you address the core requirements, both from an infrastructure and a developer perspective, that are needed to take advantage of IBF in an enterprise setting? Does this "scale down" to SMBs?

Michael Kiselman: IBF requires Office 2003 with .NET Framework 1.1 on the client, Windows Server 2003 with SQL Server 2000 SP3a on the server and VS.NET 2003 for the Metadata Designer development tool. As you see, requirements are not complex and definitely could be afforded by SMBs.

MO: As a follow-up, some of the early documents I've read take a very cautionary tone in talking to developers about how they might use IBF. Charles Maxon (another OfficeZealot), for example, has an introductory article about IBF at MSDN that raises potential red flags for developers. In essence, it says "this is not the pool you're accustomed to swimming in - take another look before you dive in". Does IBF create a new class of developer/consultants like the old Notes Developer community?

MK: IBF definitely has a learning curve, however, you leverage your existing skills in .NET development (WS and WinForms) and gain a tremendous flexibility and extensibility of the Office solutions you are developing. Do we create a new class of developers? We hope not - one of the main benefits of IBF based solution development is an ability to separate back end WS development from the declarative solution development itself. We are hearing from our customers that one of the barriers for development of solutions today is inability by today's Office developer to understand the back end application and all the associated intricacies of access to it. With IBF you overcome that by leveraging skills of people knowing the back end well.

MO: Can you give me a sense of how long it might take to develop a working implementation of the sort of solution being used as an archetype in the IBF documentation Microsoft is making available? Is this a project measured in days, weeks, or months to develop?

MK: We actually observed an interesting trend - when a developer comes to learn IBF - it takes about 1.5-2 weeks to come up to speed and create first solution. The second one takes him/her 3 days and the next only a few hours. Of course, these numbers would depend tremendously on the complexity of the solution.

MO: Does the long-term vision at Microsoft for IBF include a model where service companies (think utilities, phone companies, cable providers, Amazon, etc.) might offer their customers the ability to self-manage their accounts by using IBF to provide an appropriate level of permissions to make changes in the core data about themselves. For example, say I move. It'd be cool to go into my Amazon account, etc. and make the address change myself and know that it was done properly. Seems to me that, if this is possible, it's a win for everyone. I'm certain my account info is correct and Amazon saves money because I did the work for them.
 
MK: This is a great vision for IBF as long as these customers need access and action to these service provider systems while they are in Word, Excel or Outlook.
 
MO: How do you see IBF and SharePoint integrating? That seems like a big potential win but the vision for that is pretty sketchy in the materials I've been able to find so far.

MK: Today, IBF can easily incorporate SharePoint as a source application, as a matter of fact, we will release a sample solution providing developers metadata to do just that in out Resource Kit. The other way around is trickier. We are working with the SharePoint team on defining the roadmap, which will allow IBF to deliver and render Information and actions in IE or other SharePoint UIs.
 
MO: Is IBF the technology that will really breathes life into InfoPath? They seem made for each other. If there's a way to allow me, as an end user knowledge worker, to "snap together" a smart form using pre-built IBF "parts", that's pretty compelling.

MK:  Absolutely, in IBF 1.1, which is slated to be released at the end of the 2004, we are adding support for InfoPath - you will be able to access the same information and action via IBF while filling out a form in InfoPath.

---

I also asked Chris Kunicki of OfficeZealot.com as an independent consultant who specializes in Enterprise use of Microsoft Office what he thought of IBF? Here is what he said:

From early on we knew that enterprises and ISVs would be excited in what they saw with IBF. However, our original estimates were way off. The interest for IBF has been nothing short of phenomenal.  

Why so popular? We think IBF serves as a common intersection point for a number of high impact technologies that companies are investing in: Web services for exposing corporate data resources, .NET for rapid application development and Microsoft Office 2003 as the place where people live and work all day. By themselves each of these technologies bring their own value to the table, but when you fuse them all together you really begin to see a return on investment in the order of multitudes larger than if they individually have to stand on their own.

One common question asked is how large does an organization need to be to make the investment in IBF. Clearly many enterprises and software vendors are already adopting IBF. However adoption of IBF won't be limited to just large organizations. We have already seen interest from small businesses. For example, small legal firms, independent community banks, and healthcare firms that provides in house care services. I have yet to see an executive sponsor watch a demonstration of IBF that doesn't express interest in how they might use it.

Why adopt IBF? The great thing about IBF is that it's not a solution by itself, but typically will compliment and extend existing systems. This means that you don't need to start building a new application from scratch. Most developers will analyze existing systems and plug IBF into them. IBF is just another way to extend the reach of existing systems to more users in the enterprise and to increase the ROI in those systems.

A key concept to understand about IBF is that it functions as glue that binds various data resources with components that let users take meaningful action on that data. As an organization begins to catalog internal data resources and develop actionable components on top of them they begin to build a reusable library of IBF components (similar to the SharePoint Web Part concept) that can be reused in connecting to multiple applications. I imagine in a year or so some companies may have literally a 100 reusable components that can be mixed and matched to create custom IBF solutions for users. Then their investment in IBF pays off even further.

---

OfficeZealot.com has an IBF Zone for those looking for additional information and resources.