Microsoft Office Live and OneNote (reprise) and Live Mesh

Well, I think I've managed to mix myself up again. How unusual...

I blogged back in January about how great Office Live is but how I wish it would handle OneNote files.

Exploring further, I found that Office Live isn't everything I'd thought / hoped and have probably gotten mixed up with what it does now and what is forthcoming when the new version of Office is released (probably late this year or early next year).

For now, Office Live will allow you to edit Notes online but you can only view Word docs (I'm not sure about Excel or PowerPoint files as I hardly use either).

Not having the ability to handle OneNote files isn't a real concern at present as I am not sharing with other people. For me, I only use Office Live to save documents for my own use.

To be able to share OneNote files, I'm using Live Mesh. The thing that really impresses me about Live Mesh is that a copy of a folder that is part of my mesh is kept on my local machine - very handy for when I'm disconnected from the Internet. The sync is pretty easy too and means that files I create at home can be used at work as well.

I'm using Mesh extensively with my new ASUS netbook as it affords me some cheap backup in the event of failure or theft. Mesh also means I can use EndNote (bibliographic software - I study part time) on several machines and keep my databases in a Mesh folder, so I now get the same databases no matter which machine I'm using.

As for Office Live - I say bring on full online authoring capabilities! It will leave Google Apps for dead as far as I'm concerned. While Google Apps is great for online document editing, it doesn't integrate well with Office and doesn't have any sort of OneNote like functionality. While I do also use EverNote (yep - another product name ending in "NOTE" and I've mentioned all three of them in this post) I use this for other note taking like tasks such as recording receipts. OneNote doesn't really fit this bill and I mainly use it for professional / study tasks.

Enterprise portals vs CMSes

Note: Initially I was going to call this post "Project Managing Enterprise Portals" but somewhere along the line the post morphed into its current form. I expect this is a topic that I will want to revisit again soon...

In my rather limited experience, I'm finding that SharePoint is often compared against products such as DotNetNuke. I've done it myself. However, the more I'm working with SharePoint, I'm realising that this is a wrong comparison.

Products like DotNetNuke are Content Management Systems (CMSes). They excel at producing web sites that have a distributed content management infrastructure built-in. ie. an administrator can configure certain areas so that business users can readily add content - typically by using a built in text editor (of varying quality) or uploading documents and pictures to a list or library. The content is also typically provided by one person for consumption by many.

While SharePoint certainly does have CMS features, it's wrong to say that it's a CMS. SharePoint and its peers (of which there are only a handful and include SAP and Oracle) fall into a category of its own that could be called enterprise portals. At least this is what SAP calls its portal module (EP - for Enterprise Portal).

Enterprise portals include features to integrate data from a variety of data sources, will have some form of document management service, and will probably have other features as well, including some CMS functionality. Their nature is far more collaborative (many people contributing to the same content) than CMSes are.

Enterprise portals are enterprise systems, on par with applications such as ERP (Enterprise Resource Planning), CRM (Customer Relationship Management) and SCM (Supply Chain Management). It is wrong to compare them to CMSes (as both Bill Simser and Shaun Walker - admittedly in response to Simser - have done).

Enterprise portals are important to a business as they affect the usability of these core systems (eg. ERP, CRM). They allow internal or external users to interact with the core systems without them having to have direct access to it. By not requiring this direct access, security of the core system is maintained. For external users, this means that they can interact with the business without needing to have a specialised client installed on a local computer. They are able to use a web browser and rely on HTTP and SSL to carry and encrypt their data. Additionally, for the business, user support is more contained as custom software does not need to be installed (and supported) on external machines.

The nature of the data usage should also be different in an EP than in a CMS. As stated earlier, in a CMS, the content is created by one person for consumption by many. In an EP, data usage is often also collaborative - ie content is produced collaboratively by many people. The lines between the two categories of product certainly blur: CMSes can do some EP tasks and vice versa but I think there is a difference to be made. Consequently, I also think that the project management infrastructure surrounding them need to be different.

However, I think also that enterprise portals tend not to have the kind of project management infrastructure surrounding them as other ES implementations have, possibly for a couple of reasons:

• They're perceived as just being web sites so can't be that hard to build.
• That they are edge systems, rather than being the core systems that provide the business rules and store the data.

For the reasons above, I cannot say that this is a wise decision. Portal design may often follow a similar process to website design but I'm not convinced that this is sufficiently heavyweight for this class of application. However, project management methodology for an EP is a topic for another post.