Group items tagged

The Future of the Open Web You're right that the browser wars do not matter - except for this point of demarcation; browsers that support HTML+ and browser that support 1998 HTML. extensive comment by ~ge~ Not all Web services and applications support HTML+, the rapidly advancing set of technologies that includes HTML5, CSS3, SVG/Canvas, and JavaScript (including the libraries and JSON). Microsoft has chosen to draw the Open Web line at what amounts to 1998-2001 level of HTML/CSS. Above that line, they provision a rich-client / rich-server Web model bound to the .NET-WPF platform where C#, Silverlight, and XAML are very prominent. Noticeably, Open Web standards are for the most part replaced at this richer MSWeb level by proprietary technologies. Through limited support for HTML/CSS, IE8 itself acts to dumb down the Open Web. The effect of this is that business systems and day-to-day workflow processes bound to the ubiquitous and very "rich" MSOffice Productivity Environment have little choice when it comes to transitioning to the Web but to stay on the Microsoft 2010 treadmill. Sure, at some point legacy business processes and systems will be rewritten to the Web. The question is, will it be the Open Web or the MS-Web? The Open Web standards are the dividing line between owning your information and content, or, having that content bound to a Web platform comprised of proprietary Microsoft services, systems and applications. Web designers and developers are still caught up in the browser wars. They worry incessantly as to how to dumb down Web content and services to meet the limited functionality of IE. This sucks. So everyone continues to watch "the browser wars" stats. What they are really watching for though is that magic moment where "combined" HTML+ browser uptake in marketshare signals that they can start to implement highly graphical and collaboratively interactive HTML+ specific content. Meanwhile, the greater Web is a

Well, not quite.  More IBM happy talk about interoperability and easy document interchange.  While i agree with the static versus interactive - collaborative document perspective, it's far more complicated. Today we have a world of "native"  docs and "visual" docs.   Native docs are bound to their authoring productivity environment, and are stubbornly NOT interchangeable.  Even for ODF and OOXML formats. Visual documents are spun from natives, and they are highly interchangeable, but interactively limited.  They lack the direct interaction of native authoring environments.  The Visual document phenomenon starts with PDF and the virtual print driver.  Any authoring application(s) in a productivity environment can print a PDF using the magic of the virtual print driver.   In 2008, when ISO stamped PDF with "accessibility tags", a new, highly interactive version of PDF was offically recognized.  We know this as "Tagged PDF".  And it has led the sweeping revolution of wide implementation of the paperless transaction process. The Visual Document phenomenon doesn't stop there.  The highly mobile WebKit revolution ushered in by the 2008 iPhone phenomenon led to wide acceptance of highly interactive and collaborative, but richly visual versions of SVG and HTML5-CSS3-JSON-JavaScript documents. Today we have SVG-HTML+ type visually immersive documents spun out of Server side publication presses such as FlipBoard, Cognito cComics, QWiki, Needle, Sports Illustrated, Push Pop Press, and TreeSaver to name but a few.   Clearly the visually immersive category of documents is exploding, but not for business - productivity documents.  Adobe has proposed a "CSS Regions" standard for richly immersive layout that might change that.  But mostly i think the problem for business documents, reports and forms is that they are "compound documents" bound to desktop productivity environments and workgroups. The great transition from desktop/workgroup productivity environme

excerpt: The trend in Office development is the migration of solutions away from in-application scripted processing toward more data-centric development. Of course this is a primary purpose of Open XML, and it is great to see the amount of activity in this area. We've seen customers scripting Word in a server environment to batch process / print documents or for other automation tasks. In reality Word isn't built to do that on a large scale, it is better to work directly against the document rather than via the application whenever possible. The Open XML SDK unlocks a "whole nuther" environment for document processing, and gets you out of the business of scripting client apps on servers to do the work of a true server application (not to mention the licensing problems created by installing Office on a server). comment:  Gray makes a very important point here.  The dominance of the desktop based MSOffice Productivity Environment was largely based the embedded logic driving "in-process" documents that was application and platform (Win32 API) specific.  Tear open any of these workgroup-workflow oriented compound documents and you find application specific scripts, macros, OLE, data bindings, security settings and other application specific settings.  These internal components are certain to break whenever these highly interactive and "live" compound documents are converted to another format, or application use.  This is how MSOffice documents and the business processes they represent become "bound" to the MSOffice Productivity Environment. What Gray is pointing to here is that Microsoft is moving the legacy Productivity Environment to an MSWeb based center where OpenXML, Silverlight, CAML, XAML and a number of other .NET-WPF technologies become the workgroup drivers.  The key applications for the MS WebStack are Exchange/SharePoint/SQL Server.  To make this move, documents had to be separated from the legacy desktop Productivity Environment settings. Note th

This commentary concerns the Microsoft Office Productivity Environment and the opportunity presented as Microsoft tries to move that environment to the MS-Web stack of servers and services. The MS-Web is comprised of many server side applications, but the center is that of the Exchange/SharePoint/MOSS juggernaut. With the 2010 series of product and services release, Microsoft will be accelerating this great transition of the Microsoft monopoly base. While there are many Open Web alternatives to specific applications and services found in the 2010 MS-Web stack, few competitors are in position to put their arms around the whole thing. This is after all an ecosystem that has been put in transition. Replacing parts of the MSOffice ecosystem will break the continuity of existing business processes bound to that productivity environment. This is a disruption few businesses are willing to tolerate. Because of the disruptive cost and the difficulty of cracking into existing bound business systems without breaking things, Microsoft is in position to charge a premium for comparatively featureless MS-Web products and services. Given time, this will no doubt change. And because of the impossible barriers to entry, Microsoft has had lots of time. Still, i'm betting on the Open Web. This commentary attempts to explain why...... I also had some fun with Google Docs templates. What a mess :)

Finally! Someone who gets it. For an office suite to be considered as an alternative to MSOffice, it must be designed with multiple levels of compatibility. It's not just that the "feature sets" that must be comparable. The guts of the suite must be compatible at both the file format level, and the environment level. Randall put's it this way; "It's the ecosystem stupid". The reason ODF failed in Massachusetts is that neither OpenOffice nor OpenOffice ODF are designed to be compatible with legacy and existing MSOffice applications, binary formats, and, the MSOffice productivity environment. Instead, OOo and OOo-ODF are designed to be competitively comparable. As an alternative to MSOffice, OpenOffice and OpenOffice ODF cannot fit into existing MSOffice workgroups and producitivity environments. Because it s was not designed to be compatible, OOo demands that the environment be replaced, rebuilt and re-engineered. Making OOo and OOo-ODF costly and disruptive to critical day-to-day business processes. The lesson of Massachusetts is simple; compatibility matters. Conversion of workgroup/workflow documents from the MSOffice productivity environment to OpenOffice ODF will break those documents at two levels: fidelity and embedded "ecosystem" logic. Fidelity is what most end-users point to since that's the aspect of the document conversion they can see. However, it's what they can't see that is the show stopper. The hidden side of workgroup/workflow documents is embedded logic that includes scripts, macros, formulas, OLE, data bindings, security settings, application specific settings, and productivity environment settings. Breaks these aspects of the document, and you stop important business processes bound to the MSOffice productivity environment. There is no such thing as an OpenOffice productivity environment designed to be a compatible alternative to the MSOffice productivity environment. Another lesson from Massach

Custom Document Format Interoperability You may have heard that Office 2007 SP2 will now support editing files in the OpenDocument 1.1 (ODF) format. This document format was added to Office's long list of supported documents formats to give customers more choices for the format they use to save their documents. In addition to allowing you to edit the ODF 1.1 format within Office 2007, SP2 also supports a new External File Format API that can be used to edit other document formats as well. With this API, users can choose to save their documents in any format they want. In this post we will explore how to use the API to enable Office 2007 to edit our own custom document format. We will then use Office 2007 to save our custom format as DOCX, ODT and HTML. Our Custom Document Format For the purpose of this article, we have a company who needs to manage their sales pipeline information. The data is available as XML, but they do not want to spend the money to build a custom editor. They just want to let their users edit the pipeline data in Word, as a table. They give these files an extension of SPLX (i.e. Sales PipeLine Xml) The sales pipeline information is made up of a series of SalesItem tags, each with a unique id that represents the index of the item. They track the name of the customer (CustomerName), how much the deal represents (DealValue) and a percent that represents how confident they are that the sales opportunity will close (ConfidencePercent).

This document discusses the primary reason ODF failed in Massachusetts: compatibility with the MSOffice productivity environment, and, the billions of binary documents in use by MSOffice bound workgroups and the business processes so important to them.

Microsoft has announced the next generation of MSOffice, and it turns out to be SharePoint at the center of the deep connected MSOffice "rich client" desktop productivity environment, and, an online Web version of MSOffice. Who would have guessed that one of the key features to MOSS would be universal accessibility to and collaboration on MSOffice documents - without loss of fidelity? No doubt the embedded logic that drive BBP's (Bound Business Processes) is also perfectly preserved. Excerpt: "Office Web Applications, the online companion to Word, Excel, PowerPoint and OneNote applications, allow you to access documents from anywhere. You can even simultaneously share and work on documents with others online," Microsoft says on its Office 2010 Technical Preview site. "View documents across PCs, mobile phones, and the Web without compromising document fidelity. Create new documents and do basic editing using the familiar Office interface."

Gary Edwards's List: Compatibility matters - The lessons of Massachusetts are many. Application level "compatibility" with existing MSOffice desktops and workgroups is vital. Format level "compatibility" with the legacy of billions of binary documents is vital. And "ecosystem" compatibility with the MSOffice productivity environment.