Collaboration and Content Strategies Blog

Getting Started With Web Conferencing

Blogger: Mike Gotta

For those that might be new to web conferencing, there are few key items to consider before leaping to specific vendor solutions or before you go too far down the road of requirements gathering. Understanding some of these concepts below will enable you to better frame your effort and ask more specific questions re: business needs.

• Market structure
• Usage models
• Pricing models
• Convergence trends

Understand the market structure

It's important to understand some of the industry dynamics influencing how web conferencing technology is evolving. There are a variety of ways to segment players in this market. Some might even argue that web conferencing is not a distinct market structure. And I would not strongly disagree with that perspective - it's a debate on timing. As communication and collaboration services become components within a larger platform, it's difficult to see how web conferencing as something that has a distinct market boundary. However, if you are relatively new to this space and do not have a clear knowledge of its history, then some type of market / vendor segmentation can be helpful. As background, my coverage of web conferencing began in 1996. Below is one way to look at how vendors are positioned:

Conferencing Service Providers: CSP's are vendors whose business framework is premised on a SaaS delivery model where web conferencing is the primary focus. It is likely that a CSP will offer additional capabilities in terms of audio, video, integration with instant messaging systems and mobile support. Vendors in this category include: Adobe, Cisco (WebEx) Citrix, Genesys Conferencing, IBM (WebDialogs), InterCall (Raindance), and Microsoft. It is important to note that a CSP might represent one business unit for a vendor that also delivers solutions in other market segments. For instance, Adobe, Cisco, IBM, and Microsoft all deliver on-premises solutions for web conferencing in addition to a business area that behaves as a CSP.

Communication Carriers: Telecommunication companies often repackage technology from one or more CSP vendors under their own brand. The repackaging often includes a customized front-end and a unified back-end administration and billing system that integrates with what the carrier is offering to its customers as part of an overall voice/data solution. AT&T for instance is an example of a vendor that resells services from both Cisco (WebEx) and Microsoft but also sells its own solution based on its acquisition of Interwise.

Enterprise Software Vendors: On-premises web conferencing is also offered by large-scale vendors that deliver collaboration platforms. Vendors such as Adobe, IBM (Sametime), Microsoft (Office Communications Server), Novell (Sitescape), and Oracle fall into this category.

Communication & Networking Vendors: Vendors that primarily focus on telephony, audio conferencing and video conferencing also typically offer web conferencing systems as well. Vendors such as Avaya, Cisco (Latitude), Nortel and Polycom are examples of players in this category.

Specialists: There are vendors in the market that focus on specific solutions that generally fall into the web conferencing domain but might emphasize a particular function, such as screen/desktop sharing or application sharing or remote control. A vendor like Glance Networks would fall into this category. There are also best of breed vendors that (although they try to play in the general market) seem to concentrate in certain verticals. I would place a vendors such as iLinc and Elluminate in this category (I find them often used in distance learning situations). Even a large vendor can have an offshoot effort that is specialized. At this point, Microsoft with its SharedView beta is somewhat specialized (disconnected in many ways from its Live Meeting and OCS efforts).

Open Source Projects: There are also vendors that are leveraging open source efforts to deliver web conferencing technology. DimDim is an example of an open source effort for web conferencing.

Understand usage models ("use case scenarios")

Another important consideration if you need to make some decisions regarding web conferencing technology is to know about the type of applications a vendor supports. Web conferencing vendors can supply additional capabilities beyond "online meetings". Many offer conferencing-enabled applications for marketing, sales, customer service training and so on. The outline below is one way to think about the types of basic and advanced capabilities that might be needed when looking at vendors:

Online Meeting: The basic use case for web conferencing is simply to display a presentation or other type of document (e.g., project charts, spread sheets) to a remote audience. Often, the number of participants is low (less than 20) and the user experience is informal. The meeting might be scheduled or conducted on an ad-hoc basis (where the meeting space is created right away). There are a variety of features that might be needed (I'll cover those in another post) but the basics include the ability to display files in various formats (presentation, document, spread sheet, graphics, PDF), transfer files to other participants, chat with other participants, share a whiteboard, a specific applications or a desktop, and be able to conduct some type of question/answer or poll participants. 

Marketing Events: There can also be the need to have a web conference event for a larger number of participants. There may be an additional need for different roles (a moderator vs. a speaker). There may be a need to support a larger number of participants (perhaps hundreds) with a record-playback capability. The application will likely need to support some type of event management feature (registration functions) and include the ability to mute or eject participants. The web conferencing could be part of a marketing campaign of some type so there may be additional integration with other systems and the need for post-event analytics and reporting. 

Virtual Classroom: If the web conferencing system is targeted for an instructional environment, then there may be a need for integration with learning management systems or some type of course scheduling/registration application. There may need to be additional features for a student/teacher interaction model (raising a hand). The need for record-playback will likely come up as well. Integration with survey tools might also be needed if there are any type of testing requirements.

Customer Service: If the web conferencing system is intended to support a customer service scenario, there may be a greater need for remote control capabilities that allow support resources to "take over" a remote machine or the ability to co-browse (where a service agent guides another user's browser to a particular page on a web site).

Sales Support: If the solution is intended to support a sales environment, then it might be a core requirement for a web conferencing system to support features such as application sharing, whiteboard, co-browsing and a shared desktop since sales people will perhaps need more capabilities to allow them to demonstrate products and services.

Understand pricing models

Pricing models for web conferencing are more art than science. In fact, it's probably the most confusing aspect of this market (making it difficult at times to compare vendors on an equal basis).

• Subscribe "By The Minute"
• Subscribe "By The Port" (a shared resource, not named)
• Subscribe "By The Room" (a persistent space that anyone can use or attend)
• User Licensing (e.g., named users, guests, moderator-pays-attendees-free)

Since the "buyer" of web conferencing can be someone from different parts of an organization (business as well as IT), vendors have come up with different ways to purchase solutions. If they decision-maker is someone from a a communications or network background, then "by the minute" pricing is often presented since that model makes sense to someone in charge of audio/voice systems. If the decision-maker comes from an application background, a vendor might want to present a model that mimics enterprise software. You might see port pricing where you are buying some number of seats that can be used by anyone. Or, you might see something more creative where there are named users, guest accounts or even situations where only moderators and presenters pay but attendees are "free". More advanced discussions might result in a web conferencing "room" being purchased. This might reflect some type of bundled offer and might be appropriate for marketing events, sales demo spaces or a virtual classroom of some type since there is a regular schedule of sessions with a revolving audience.

Understand convergence trends

The above three concepts do not cover every aspect of "getting started" - I avoided any lengthy discussion of business requirements gathering in this particular post - but they are the some of the re-occurring issues I've come across over the years where people become confused in some way. Another future post will look at collecting requirements for web conferencing systems.

One last important item to remember is the overall trend of convergence. Web conferencing is a component of where the market is heading in terms of unified communications. It's important to keep in mind that a web conferencing decision should be made in context of other technologies that are strongly related such as:

• Instant messaging & presence
• VoIP/IP telephony
• Audio and video conferencing
• Facilities (room systems)
• Mobile
• Compliance (e.g., record/playback, audit)
• Security (e.g., SSL, AES) and identity (directory integration)
• Federation with external systems (including perimeter design)
• Application integration (e.g., e-mail and calendar systems)
• Peripherals (e.g., cameras, USB devices for phones, speakers, etc.)

Economic Concerns Will Renew Interest In Web Conferencing

Blogger: Mike Gotta

Every so often, economic downturns, health-related outbreaks or acts of terrorism cause organizations to prioritize alternatives for corporate travel. Given growing energy costs and recession concerns, decision-makers are likely to "dust off" prior programs aimed at streamlining travel budgets. While there may not be as much waste in current travel programs, I suspect that we will see an upswing in web conferencing over the next several months. The leaders in the web conferencing space remains relatively unchanged. Cisco/WebEx and Microsoft Office Live Meeting are the dominant options for most large enterprises. But there are many alternatives. The last time I counted, there are well over 50 vendors in this space that offer hosted or on-premises solutions. There are open source alternatives as well. The hosted vendors I come across most often (in addition to Cisco and Microsoft) are:

• Adobe Acrobat Connect
• Citrix GoToMeeting
• IBM Lotus Sametime Unyte (formerly WebDialogs)

There are many others AT&T (acquired Interwise), Genesys Conferencing, InterCall (acquired Raindance), Yugma (which offers Skype integration) and so on. Some strategists may be encouraged to leverage business interest in travel-related cost reduction as justification to pursue standardization efforts (e.g., select a single vendor) or perhaps as part of a broader rationalization for an on-premises deployment (where Cisco, IBM, and Microsoft include web conferencing as a component in their respective unified communications solution). 

So pull out those old project plans ... time to update them.

Business Week: Companies curtailing travel budgets

So far, travel bookings are holding up. But corporate travel managers are taking a more active role in keeping on-the-road spending in check:

- Employees are increasingly being asked to provide an economic rationale for their trips.

- Rules that require employees to book the lowest fare, stay in pre-approved hotels or double-up in cars and rooms are being enforced more strictly.

- Executives are pushing alternatives to face-to-face meetings, including phone- and Web-conferencing.

...

Faced with rising fuel costs, airlines increased business- and first-class fares by 12.4 percent during the first half of February compared with last year, according to Sabre Travel Networks. Economy fares climbed 6.2 percent.

Airport rental-car rates have jumped at least 20 percent each week this month compared with a year ago, according to Abrams Consulting Group. And hotel room rates jumped 5.9 percent in 2007, according to Smith Travel Research.

Companies curtailing travel budgets

When will they learn?

Blogged by: Karen Hobert

I recently finished reading "Where Have All the EMails Gone?" by David Gewirtz, Editor-in-Chief at Zatz Publishing. Like Pete Seeger, who asked a bunch (pun intended) of questions about missing flowers, Mr. Gewirtz asks a lot of questions about missing White House e-mails; a fact that was brought to the national attention in April 2007 during the Supreme Court justice firing inquiries. In his book, Mr. Gewirtz doesn't ask his questions to promote a political platform, rather he asks the questions as an information technologist, wondering what actually happened. He plays Internet domain sleuth and explains how he uncovered information about the Republican National Committee (RNC.org) and GWB34.com e-mail accounts that were used in lieu of White House (EOP.gov) e-mail. He also explores the policies that directed White House staffers to use non-White House communication channels for certain types of activity. Using publicly available testimony and press conference transcripts, he investigates how e-mail from the White House may have disappeared. Mr. Gewirtz also speculates on the potential dangers of these policies and practices which, at times, may seem borderline hysterical unless you've had to deal with securing e-mail content and seen some of shenanigans that go on.

Politics aside, "Where Have All the EMails Gone?" is an good case study of what not to do if you want to keep e-mail secure, auditable, and recoverable. The book is an easy read and is peppered with repeated disclaimers of political bias by proving that this problem is non-partisan having started in a Democratic White House and has come to our attention in a Republican White House.

The most important lesson is detailed in Chapter 13 - that a sound e-mail system is about technology and policies:

There are, however, technical issues and concerns, plus security issues and concerns that blast through the political rhetoric and even party affiliation.

Many of the questions posed in this chapter could be asked about any e-mail environment and is not exclusive to the White House or its policies. If you're in charge of managing an e-mail platform, I recommend that you read this book. Mr. Gewirtz adds value to his book by offering additional material (e.g., interviews, article links, and resource links) where readers can go to find out more about e-mail technology, practices, and policies.

By the way, this is an ongoing story, and you can keep up with the latest installments via a RSS feed link on the "Where Have All the EMails Gone?" web site.

Part 4: What IT Can and Should Do About Content Globalization

Blogger: Craig Roth

This is the final blog companion for my 4 part podcast series on “What IT needs to know about content globalization, localization, and translation”. I previously posted part 1, part 2, and part 3.

Audio URL: Download Content Globalization Part 4 (10 minutes)

1. Open lines of communication with the business about globalization
   • Don’t wait. Take the initiative by setting up a presentation for interested business partners and marketing to find out what their globalization plans are and talk about how IT can help
2. Determine your Content Globalization Maturity

   

3. Look Beyond Paragraph Text When Planning Localization
   • Metadata around the content components
   • Graphics often have text embedded and pictures may need to be changed to match the locale
   • Audio in music or spoken mp3s or video
   • Data such as conversion of currency, English/metric measurements, date/time formats
   • Descriptions of processes such as support
   • Style sheets and graphical layout (including colors, whitespace)
4. Build Globalization into the ECM Process
   • This model shows how globalization extends the ECM model we published back in 2006 in The Copernican Revolution in Content
5. Move Localization from the End of the Content Process to the Beginning
   • Make globalization a forethought, not an afterthought

I welcome your feedback! Please provide feedback on this podcast and blog series by clicking on “comments”

Microsoft's Vision for FAST Search

Blogger: Guy Creese

I'm currently attending the FAST Search user conference (FASTforward 08), and yesterday Jared Spataro from Microsoft explained Microsoft's reasoning for buying FAST. (The shareholders have approved the deal, but it has not yet been completed.) He noted that the questions he gets always fall into three categories. Here are my notes from his speech:

• What’s in it for Microsoft: 18 months ago, Microsoft thought search was a set of features. Microsoft finally got religion during the SharePoint 2007 project. Consequently, a specialized team was formed to target search, and was made part of the SharePoint team. FAST came up to Microsoft right after FASTforward 2007 and demoed their capabilities. So Microsoft has been aware of FAST and its capabilities for over a year. Microsoft saw three differentiators with FAST--vision, people, technology—which is why it bought FAST rather than other vendors.
• What’s in it for FAST: Combine FAST’s depth (visionary innovations, passionate people, best-in-class technologies) and Microsoft's breadth (SharePoint momentum, complementary infrastructure technologies, sales and marketing engine) to gain faster adoption of FAST’s technologies.
• What’s in it for customers: FAST will continue to pursue both monetization (customer-facing, revenue-producing search applications) and enterprise (employee-facing, productivity-enhancing applications) segments. Customer-led innovation will continue. Customers can expect cross-platform support and innovation to continue.

I thought the most interesting part was the last bullet: Microsoft's comments that it does not plan to disrupt FAST's current segmentation strategy, that high-touch customer engagement will continue, and that it will support and extend search running on non-Windows platforms.

Blogger: Guy Creese

I'm currently attending the FAST Search user conference (FASTforward 08), and yesterday Jared Spataro from Microsoft explained Microsoft's reasoning for buying FAST. (The shareholders have approved the deal, but it has not yet been completed.) He noted that the questions he gets always fall into three categories. Here are my notes from his speech:

• What’s in it for Microsoft: 18 months ago, Microsoft thought search was a set of features. Microsoft finally got religion during the SharePoint 2007 project. Consequently, a specialized team was formed to target search, and was made part of the SharePoint team. FAST came up to Microsoft right after FASTforward 2007 and demoed their capabilities. So Microsoft has been aware of FAST and its capabilities for over a year. Microsoft saw three differentiators with FAST--vision, people, technology—which is why it bought FAST rather than other vendors.
• What’s in it for FAST: Combine FAST’s depth (visionary innovations, passionate people, best-in-class technologies) and Microsoft's breadth (SharePoint momentum, complementary infrastructure technologies, sales and marketing engine) to gain faster adoption of FAST’s technologies.
• What’s in it for customers: FAST will continue to pursue both monetization (customer-facing, revenue-producing search applications) and enterprise (employee-facing, productivity-enhancing applications) segments. Customer-led innovation will continue. Customers can expect cross-platform support and innovation to continue.

I thought the most interesting part was the last bullet: Microsoft's comments that it does not plan to disrupt FAST's current segmentation strategy, that high-touch customer engagement will continue, and that it will support and extend search running on non-Windows platforms.

Part 3: Content Globalization: Do the Big Vendors Care?

Blogger: Craig Roth

This is the blog companion for part three of my 4 part podcast series on “What IT needs to know about content globalization, localization, and translation”. I previously posted part 1 and part 2.

Audio URL: Download Content Globalization Part 3 (17 minutes)

• Vendor segmentation
  • Look beyond internationalization (e.g., can they support other languages) to include localization assistance such as support for translation memory, translation workflows, and integration with language service providers
  • Content Globalization Value Chain (Note: the podcast lists sample vendors in each space)

    

    • Authoring: Content creation tools have a part to play in globalization, mostly through plug-ins that add localization assistance and XML-based authoring tools that create content in componentized form and allow a content designer to apply rules and structure to their content
    • Enterprise Content Management: Standard features in ECMs help with globalization, but ECMs specifically built to help with localization (such as by supporting XML content components or out-of-the-box integration to globalization management systems and language service providers) can help even more
    • Globalization Management Systems (aka Translation Management Systems): A GMS handles the translation process with features like project management, localization workflows, costing, and adapters between ECM and language service providers. Terminology management and translation memory tools are sometimes part of a GMS suite
    • Translation: Divides into human (the largest segment; provided by Language Service Providers) and machine translation
    • Assembly: Dynamic assembly such as portals can leverage personalization and the capability to dynamically determine which version of content to display
  • Some larger players (Microsoft, IBM) haven’t woken up to content globalization yet
  • One reason is that customers haven’t demanded they respond yet since the need is currently felt outside IT and the LSPs and GMSs have been addressing the problem
  • Innovation has been coming from smaller vendors, many of them European
  • The value chain will get tighter over time and acquisitions are likely, especially in the GMS space
• Buyer segmentation
  • Some types of industries and roles are more affected by the increase in content globalization
    • International organizations that attempt to maintain a single global brand image (i.e., hospitality, transportation, travel, automotive, and pharmaceutical) tend to change content frequently and need consistency and timeliness in localization
    • Industries that write lots of technical or service manuals (i.e., medical devices, technical manufacturing, and discrete manufacturing) need to translate complex documents and are more likely to use and benefit from componentized content creation
  • Roles: Many people may never get involved in globalized content creation if they work only on low visibility, internal documents. But for other roles, content globalization is an issue
    • Professional, technical writer
    • Line of business content owner
    • Local website owner
    • Marketing communications
    • Web designer
    • Programmer

Part 2: Content Globalization 101 in Twenty Minutes

Blogger: Craig Roth

Here’s the blog companion for part two of my 4 part podcast series on “What IT needs to know about content globalization, localization, and translation”. If you missed part 1, you can find it here.

Audio URL: Download Globalization Part 2 (19 minutes, 6.6MB)

• This part contains background information on globalization that can be handy for people coming up to speed on globalization or looking for rationale for the analysis, but can be skipped if not needed
• Definitions
  • Content globalization (numeronym: g11n) is a strategy to convey information in the cultural, linguistic, and business context of target audiences.
  • Localization (L10n) is adapting content to a particular locale
  • Internationalization (i18n) is the work you do enable localization (prep work for localization)
  • Transliteration (t13n) is using characters from one language to represent another
• Resources to create a statement of trends for a particular business
  • Internet World Stats to show the prevalence of the languages you want to translate into or the growth or overall percentage of users in a particular language
    • English still #1 with 365 million users, 184 million for #2 Chinese
    • Growth trends: between 2000 and 2007 for Arabic (+941%), Portuguese (+525%), and Chinese (+470%)
    • Internet usage outside of North America dwarfs usage within it: 20% north America, 37% Asia, 27% Europe
  • Ethnologue to show number of countries speaking a language or what weight a content-creating organization should place on localization issues given the makeup of a specific country being targeted
    • The Ethnologue can also show linguistic diversity in countries to demonstrate how heterogeneous a country is. It lists the probability that any two people in the country chosen at random will speak different native languages
• Dialects
  • The Portuguese spoken in Brazil and Portugal are much different and can lead to misunderstandings or make a reader feel the author doesn’t truly understand them
  • Corporate English is a dialect
    • See sample courses from CorporateEnglish and ELT
• Code Internationalization
  • Wikipedia: “The current prevailing practice is for applications to place text in resource strings which are loaded during program execution as needed. These strings, stored in resource files, are relatively easy to translate. Programs are often built to reference resource libraries depending on the selected locale data.”
  • As with content globalization, localization concerns should be moved to the beginning of the planning process from the end and businesses need to treat globalization as a first-order imperative
  • Examples of system development guidelines
    • Mozilla
    • IBM
• Standards
  • Darwin Information Typing Architecture (DITA)
    • Created for complex documents in multiple formats
    • Not specifically for globalization, but there’s a translation subcommittee
    • DITA enforces a strict structure on content which makes it easier to translate, but interferes with the writing process
    • Probably fine for technical manuals, but not artful content like ads or brochures
    • DITA requires customization before use
  • Internationalization Tag Set
    • Defines the metadata needed content globalization
    • Examples: tags to define the source language, parts that shouldn’t be translated, targeting for a right-to-left language, notes to pass to the translator
    • Still evolving
  • Translation Memory eXchange (TMX)
    • Translation memory is used to keep a record of how certain phrases have been translated in the past so those translations can be used again to save time, leverage the best translations, and ensure consistency
    • Owned by LISA – the Localization Industry Standards Association – which is trying to unify many standards for translation
  • Unicode
    • Unicode is a universal 16 bit code to represent characters in memory and on disc
    • Every language hasn’t been encoded, but most of those in commercial use are
    • Most major software is now Unicode compliant, although that doesn’t mean every language is automatically supported and there are different flavors of Unicode
• The printed report also covers ISO 8601 Date Formats and XLIFF

Globalization Podcast Companion

Blogger: Craig Roth

I’ve posted up a 4 part podcast series on “What IT needs to know about content globalization, localization, and translation”. While the audio stands alone, I figured it would be nice to post up this companion blog entry. This way you can find the URLs for the websites I recommend in the podcast, you don’t have to take as many notes, and you have something to stare at while listening (PowerPoint has corrupted us!). It could also provide some basics for you if you don’t want to listen to the podcast.

I thought about creating PowerPoint slides to follow along, but I think it’s better to just list the bullets in text here. This way the whole series prints on one handy page and you don’t have to download a big file just to get some simple text bullets.

So, here it is. Your Cliff’s Notes for part one of my 4 part podcast series and report.

Part 1: Repeatable content globalization: Ignore it at your peril

Audio URL: Download Globalization Part 1

• IT needs to get more involved in content globalization
  • Currently IT is often not involved since a marketing or product team just creates content (e.g., web site, technical manual), throws it over the wall to translators, and gets a pack of translated versions back
  • This process works, but content owners are going to be feeling a lot more pain soon if they don’t prepare for an increase in globalization needs
• Decisions about content globalization are business decisions with large potential impacts on customers, employees, and brands. A poor content globalization strategy can hamstring those efforts
• IMF data: growth for the G7 major advanced economies has been about 2-3% while various measures of new markets (such as newly industrialized Asian economies, emerging and developing countries, and central and eastern Europe) have grown at 5% or more
  • For statistics on growth in specific countries or regions, go to the IMF’s website (http://www.imf.org), click on “data and statistics”, and (if desired) “by country groups”
• According to comScore “the U.S. share of the world's online population has fallen from 65 percent to less than 25 percent in the last 10 years"
  • comScore (www.comscore.com) tracks measurements about consumer behavior on their internet
• Localization applies even to U.S.-centric organizations.
  • 2000 U.S. Census: 17% of households speak another language at home (8% speak English less than “very well”)
  • Some states have high proportions of non-English speakers: in California, 21.0% of respondents reported they speak English less than “very well”
  • Check U.S. census trends (www.census.gov)
• When you make quantum leap in the number of locales supported, you need a subsequent increase in the level of sophistication with which content globalization needs to be addressed
• Drivers:
  • Increased complexity
  • Poor governance
  • Timing and responsiveness
  • Safeguarding brand image
  • Containing or reducing costs
  • Consistency
• These drivers have been around a long time. Why change now?
  • The pace of globalization is increasing rapidly, therefore ensnaring more and more organizations (see IMF, comScore, and census information above)
  • Improvements on the technological front
  • XML and related Standards, and Meta-data
    • XML is great for content globalization since it encourages dividing documents into content components, supports any linguistic encoding including right-to-left (RTL) languages, and enables creation of meta-data
  • Component-Oriented Content
    • Analogous to service-oriented architecture (SOA) in that it relies on the value of dividing up work into components that are independent, managed, and assembled into composite applications
    • Component-oriented content systems can handle content components that are decoupled from a specific document
    • Component-oriented content can help as there is an increase in
      • The number of localized variants the content will be translated into
      • The number of formats the content will be distributed in
      • How granular the translations need to be if it’s not the whole document or website at once
      • How frequently the content will change
    • See the CCS document “Content Reuse: DITA, XML, and Other Ways to Keep from Reinventing the Content”
• Repeatable processes for content globalization are going to be essential for helping the business to meet globalization goals. You only ignore the processes and new technologies that can help at your peril!

Burton Group's Response to the ODF Alliance (Part 3)

Blogger: Guy Creese

What follows is part 3 of Burton Group’s response to the ODF Alliance’s response to our “What’s Up .DOC?” overview report on ODF and OOXML. This post covers points 13-18. Points 1-6 are covered in Part 1 (which includes a short preamble); points 7-12 are covered in Part 2. To make it easier for readers, we’ve listed the ODF Alliance comments in italics, followed by the Burton Group replies in a non-italicized font.

Point 13

At the bottom of page 17, the authors present a list of prior protocol and API disputes with Microsoft, such as VIM, IDAPI, OpenDoc, etc., and suggest, “In these and other earlier encounters, when Microsoft's competitors sought to collectively compete with Microsoft by leveraging standards, the everybody-but-Microsoft standards have generally failed to achieve significant market momentum.” 

The examples given are ancient history. Also, note that VIM (1993), IDAPI (1992) and OpenDoc (1992) were not formal standards. The report fails to note that the market has evolved in the past 15 years and that that customers are better educated in the liabilities of vendor lock-in, and are now more aware of the important role that open standards play in ensuring interoperability. Whereas 15 years ago, it was enough to require the use of COTS software, today procurement is increasingly requiring the use of open standards. 

In our opinion, it would be far better to look at the example of Internet and web standards to see how Microsoft's competitors, and Microsoft itself, have succeeded. ODF has the potential to be the same competitive force for office productivity applications, using the same standards-based approach. 

We believe earlier attempts by groups of Microsoft competitors to establish control in key domains through consortium standards are pertinent to the ODF/OOXML debate. In our experience, enterprises spend money to embrace standards only when they feel that proprietary formats significantly constrain business action. With Microsoft Office’s large market share, the constraints are minimal, as virtually every partner that an enterprise would do business with can read and write Microsoft’s longtime binary formats, and increasingly its OOXML formats as well. In short, many enterprises do not see the need to move to ODF to gain interoperability, as in their view they already have it (albeit by using a de facto standard). That said, some organizations are worried about depending on a de facto standard, and so are demanding standards-compliant solutions, of which both ODF (ISO) and OOXML (Ecma) are options. 

In general, it would be helpful to see more information from the ODF community on why ODF is a better fit for customer requirements, and less positioning based on the assumption that Microsoft will invariably seek to inappropriately or illegally subvert standards processes. 

Point 14

On page 18 the authors introduce a section by saying, “If productivity application evolution had peaked around the feature set of Office 97, and if there weren't exabytes of files captured in earlier Microsoft Office file formats, it's possible that ODF could have succeeded as a global standard for productivity application file formats.” 

This point is not argued, it is just asserted, without any supporting evidence. We suspect that many of the arguments being made today in the report for Microsoft and against ODF would also have been made in 1997 had we been in that situation then. The network effects were smaller, but they were big for the time. 

Projections are by definition subjective; we stand by this projection in question, and believe there is ample room for innovation in productivity applications. 

Point 15

Later on page 18 the authors state, “OOXML will be more pervasive than ODF for several reasons. It's a better form-follows-function fit for most productivity application usage patterns”. 

This is a bold claim without argument or analysis to back it up, as far as we understand it. On what basis is the assertion that more than 50% (“most”) uses of documents cannot be represented in ODF? We believe, for example, that the entire Burton Group report could be represented in ODF without any loss in fidelity. Do the authors believe that more than 50% of the documents in use, today and legacy, are more complex than their 37 page report? 

We clearly established the context for our projections and recommendations – Burton Group’s customer audience, which is primarily composed of large commercial, government, and higher-education organizations. We believe these large organizations do indeed routinely exploit beyond-the-basics capabilities in word processor, spreadsheet, and presentation applications. The context for Burton Group’s overview, incidentally, is a good example of a non-revisable, print-oriented context, one we believe is well suited to the PDF file format. 

Point 16

Further on page 18, the authors note, “OOXML will gain market momentum as vendors such as Altova and Mindjet introduce products that support OOXML. Altova, the leading vendor of tools for XML-focused developers and designers, added OOXML to its XMLSpy product line in 2007.” 

This statement misrepresents market momentum by citing niche application support. While they may be fine products, will it really be the case that an XML programmer's editor and mind map software will drive the adoption of an XML office document format like OOXML? Will someone in a university or a business office adopt OOXML as a word processor format because they can edit it in Altova? That would be remarkable, considering the relatively small percentage of all end users who edit XML at that level. MindJet already supports the legacy binary Office formats. By what mechanism does MindJet supporting OOXML cause someone to move to OOXML? Certainly, if a user wants to move to OOXML, having this support removes a potential obstacle to migration. But it alone can do nothing to cause market momentum. We believe, in fact, that many users will simply stay with the .doc, .xls, and .ppt formats if they wish to use Microsoft formats, as was recommended by the recent Becta report in the UK. 

We did not say these applications would “drive the adoption” (be the main force); we said they would increase market momentum (add speed to an already moving body). Our point was to note the power of a surrounding ecosystem that is OOXML-compliant. The presence of Office 2007 has already started the creation of OOXML documents; the ability of many tools to accept or generate OOXML files will make the use of OOXML more attractive, especially as enterprises recognize that XML formats allow them to programmatically work with documents much more easily than they could in the past. That’s why we don’t believe enterprises will stay with the legacy .doc, .xls, and .ppt formats—XML-based formats (whether ODF or OOXML) are intrinsically more useful than their binary counterparts. 

In the initial stage of adoption, both ODF and OOXML are on a level playing field, by dint of being XML formats. However, over time, if complementary applications—whether they’re an XML editor, a mind-mapping tool, a report generator, etc.—support OOXML and do not support ODF, then the network effect starts to take over and OOXML will gain market momentum as enterprises decide that the OOXML ecosystem is larger—that their interoperability and programming options are less limited. While there are more office suites that are ODF-compliant than OOXML-compliant, OOXML seems to be winning the ecosystem battle, because these ecosystem vendors (characterized as niche vendors by the ODF Alliance) are implementing OOXML support (and postponing ODF support) based on customer demand. (As a rough comparison, here is a list of OOXML-compliant products; here is a list of ODF-compliant products.) In talks with us, Altova co-founder and CEO Alexander Falk noted that Altova had not seen customer demand for ODF; Gareth Horton of Datawatch noted the same thing in a comment on a blog post: “There was no interest from our users. In the future, that may well change, and we will duly implement ODF. Until that becomes a decision we can make on a sound financial basis, we can't expend development time on it.” 

Point 17

Page 19 says that “ODF represents laudable design and standards work. It's a clean and useful design, but it's appropriate mostly for relatively unusual scenarios in which full Microsoft Office file format fidelity isn't a requirement.” 

The authors here contradict their own argument. On page 8 they stated, “In many cases, the productivity application file is ephemeral, used only to present and capture user actions for business transactions that are ultimately captured in enterprise systems rather than stand-alone productivity application files (that is, the files are destroyed when the transaction is complete and captured in other systems of record).” We believe, and follow the practice of, authoring a document in ODF and publishing it as a PDF file. For us this is a not an “unusual scenario” nor does it necessarily involve “full Microsoft Office file format fidelity,” 

Further, what does “full Microsoft Office file format fidelity” even mean? This seems like a circular argument, that ODF is only useful in cases where you are not using Microsoft Office file formats. 

We are working to compile a detailed list of interoperability issues, but for now reiterate the context we established for the report: large enterprise organizations that routinely engage in workflow scenarios that entail sharing Office file formats both inside and outside the company. Because most organizations are using Microsoft Office (and hence OOXML in the long run), we view using ODF (and hence introducing OOXML to ODF and ODF to OOXML translation processes) as a needless step that may introduce information loss. Examples of potential information loss in going from OOXML to ODF within a word processing document include the loss of image rotation, text wrapping in tables, and text watermarks. Examples of potential information loss in going from ODF to OOXML within a word processing document include the loss of hidden sections, text blinking, and table columns (ODF supports up to 8, 192 columns; OOXML supports up to 63). For a more detailed list of translation issues, see the Known Issues page on the Open XML/ODF Translator Add-ins for Office web site. 

Point 18

On page 21, the authors claim, “Even Adobe's own Buzzword service will likely add support for OOXML—again, if only for Office 2007 file compatibility.” 

This tells only half the story, again. Adobe has stated publicly that it plans on adding ODF support. The cherry-picking of statements, ignoring positive facts about ODF, while speculating on positive futures for OOXML, is puzzling and goes against the paper's claimed position of objectivity and vendor neutrality. 

This was an inadvertent omission on our part. Adobe is well known as an ODF advocate—it serves on the OASIS OpenDocument Technical Committee—and in the course of writing this section we assumed Adobe would be supporting ODF. We should have made that assumption explicit. Because ODF support was a given to us, that’s the reason for the phrasing, “Even Adobe’s own Buzzword service will likely add support for OOXML…”. We thought it notable that a vendor strongly identified with ODF and PDF would also be supporting OOXML. 

In fact, a test version of Buzzword (Preview 7) already supports OOXML, according to a thread in the the Buzzword Discussion Forum. While Adobe has officially announced that Buzzword will support ODF, it doesn’t appear that such support is in the product yet. 

Closing Comments

There are also issues not raised that cause concerns. For instance, why is there no discussion on accessibility issues raised by the disability community with respect to office documents? These issues have raised worldwide consciousness of the impact of information technology decisions and standards on the lives of people with disabilities. We hope it is not because the authors did not wish to acknowledge either (1) the issue's importance, or (2) that ODF v1.1 has established a new high water mark for document formats, a high water mark that should not be allowed to recede with the acceptance of anything less from any other office document format. 

For accessibility concerns, we also believe Microsoft’s recent success with the DAISY Consortium (see, e.g., http://www.disabilitycoordinationoffice.com.au/content/view/881/295/) is a useful example of how OOXML can be used to advance accessibility for all productivity application users. We certainly didn’t mean to discount the importance of accessibility.

 

Burton Group's Response to the ODF Alliance (Part 2)

Blogger: Guy Creese

What follows is part 2 of Burton Group’s response to the ODF Alliance’s response to our “What’s Up .DOC?” overview report on ODF and OOXML. This post covers points 7-12. Points 1-6 are covered in Part 1 (which includes a short preamble); points 13-18 are covered in Part 3. To make it easier for readers, we’ve listed the ODF Alliance comments in italics, followed by the Burton Group replies in a non-italicized font.

Point 7

Page 13 says, “In terms of productivity application model concerns, ODF is primarily focused on content and presentation domains, and it is far less useful for scenarios requiring advanced structure and behavior capabilities. For example, ODF (currently in a 1.1 revision) supports a single table type for use within document, spreadsheet, and presentation applications.” The authors fail to make a convincing argument here, in our opinion. Taking a benefit of ODF and declaring that it is a liability, but without any argument, is puzzling. Most experts would say that, structurally, a table in a word processing document, a spreadsheet and a presentation share a number of factors in common that express their “tableness” such as an addressing mode by row and column, the ability to adjust row heights and column widths, the ability to have background colors, text content, etc. Good analysis and and elegant design, (an art not a science, but still one with established norms) calls for common abstractions to be commonly represented. So the fact that ODF has a single table model is a virtue of the format, not a liability. Note that there is nothing that requires the application to make a table in the user interface appear the same in all three applications. ODF is only defining the underlying storage model, and a table is a table is a table. There is no need for making this more complicated than necessary. Conversely, examining why a single standard unnecessarily includes redundant representations of the same basic concept in three different areas would be very useful, if it can be justified. It would lend balance to the arguments presented. Such redundancy would tend to make a standard much longer than expected and increase the development complexity, unless you already happen to have an implementation. 

The table issue is a subjective architectural call; we do not believe there is one and only one model for tables used in word processing, spreadsheet, and presentation productivity application domains. While there are baseline capabilities common to all styles of tables, a table within a word processor typically has less functionality (e.g., basic formatting, rudimentary summation) than a set of cells within a spreadsheet application (more sophisticated formatting, complex formulas that generate the numbers displayed). Given the different expectations that users have of tables (depending on which application they’re using), we believe argues for separating the underlying designs. In our view, the overriding goal is to support the way people work—largely driven by habits developed when using Microsoft Office, like it or not—rather than have a design that suboptimizes expected behavior or overcomplicates the file format. 

To take an example, let’s assume that word processor table complexity is a 5, spreadsheet table complexity is a 10, and presentation table complexity is a 3. For a universal architecture to effectively work across all three applications, the specification needs to support a 10 score—adding needless complexity to the word processing and presentation formats. An alternative is to support a 5 score—which then shortchanges functionality within the spreadsheet application. Separating out the table specification for these three applications strikes us as an effective way to achieve “form follows function”: avoiding needless complexity within the file format specification while at the same time delivering sophisticated enough payloads that will support expected application behavior. We also believe ODF’s model will eventually evolve to be specialized for the different domains to a point at which it’s not very useful to point to a simple root table. 

Point 8

Further on page 13 the authors state, “...it's essentially impossible to get ODF proposals approved if they're not also supported in OpenOffice.org, and further noted that Sun closely controls OpenOffice.org (much as it also holds control over Java).” 

This is demonstrably false, and the use of unnamed “vendors” as sources does not eliminate the need for doing basic fact checking on such claims. Rumors and innuendo do not objective analysis make. 

First, on the control aspect, note that ODF 1.0, the standard, is owned and controlled by OASIS, a standards consortium of over 600 member organizations. Sun is just one company among many members. Indeed, for most of the development of ODF, Microsoft was on the Board of Directors of OASIS. 

Second, OASIS is a corporation. It is legally bound to its Bylaws. There is no arbitrary control by member corporations. 

The ODF TC is co-chaired by an IBM employee and a Sun employee, and is regulated by the OASIS TC Process document, which is publicly readable by all 8 and has clear rules of procedure and appeal. 

The ODF TC has three subcommittees. The Accessibility SC is co-chaired by IBM and Sun, while the Formula Subcommittee and the Metadata Subcommittee are each chaired by individual members of OASIS who are not affiliated with any large corporations. 

Voting rights in the ODF TC, for accepting or rejecting features, is currently as follows:

• Sun – 3 voting      members
• IBM – 4 voting      members
• Individuals – 3      voting members 

This can easily be verified at the OASIS ODF TC website. 

Is sharing the chair position on the TC and on 1 of 3 subcommittees considered “closely controlling”? Is having 30% of the votes considered “closely controlling”? 

As for proposals being accepted into ODF, we note that all three major features for ODF 1.2, RDF metadata, OpenFormula, and enhanced accessibility, are new proposals which have not been yet implemented in OpenOffice. Moreover, the ODF TC is currently processing a set of features requested by the KOffice open source project. So the assertion that it is “essentially impossible” to get new features into ODF if they are not already supported by OpenOffice is not true. This error is unfortunate and needs correcting through rigorous fact checking, as do the others, in our opinion. 

Oddly enough, this particular error occurs in several places. A search of the report for the word “control” shows it used six times, once in reference to “Chinese communists” and five times in reference to Sun Microsystems. Note, however, that no mention is ever made of the strong direct control Microsoft asserts over OOXML, its having sole chairmanship of the Ecma TC45, and its having secured a committee charter that prevents any changes to OOXML that are not compatible with Microsoft Office. 

Again, we're puzzled by the inaccuracy on one hand and the lack of balance on the other. 

We were not expecting to be told that Sun had significant sway over the standard, but several people told us that (spread across more than one ODF-oriented vendor), which is why we noted it in the report. As the ODF Alliance notes, IBM and Sun—two of Microsoft’s most powerful productivity application archrivals today (as well as partners to Microsoft in myriad other domains, e.g., Web services-related standards initiatives)—collectively control 70% of the votes in the ODF TC which determines if proposals will be accepted or rejected. This suggests there is ample opportunity for conflicts of interest. 

Point 9

On page 14 the authors state, “Note that it wasn't possible for Microsoft to embrace ODF during this period, as Microsoft's investment in XML file formats was long underway before ODF became an OASIS standard in 2005 (and because of Microsoft's need to maintain compatibility with earlier Microsoft file formats).” 

This contradicts the author's own presented timeline. The ODF Technical Committee was created in OASIS back in 2002. There was clearly ample opportunity for Microsoft to join and influence the evolution of ODF. Since Microsoft was on the OASIS Board of Directors, they had significant opportunity to both know about and participate in what was happening in the development of ODF. It's unfortunate that they chose not to lend their expertise to this industry community effort. 

Probably a better phrasing on our part would have been, “Note that it wasn’t possible for Microsoft to embrace the ODF standard during this period, as Microsoft's investment in XML file formats was long underway before ODF became an OASIS standard in 2005. After the ODF standard was approved, Microsoft didn’t embrace it due to its desire to maintain compatibility with earlier Microsoft file formats.” 

So the possible adoption of ODF by Microsoft splits into two phases. Microsoft’s first XML features in Office appeared in Office 2000, a vast development project that was underway (1998) four years before Sun released OpenOffice (2002), the productivity suite that contained the file formats that became the genesis of ODF. Put another way, ODF as a standard didn’t exist even as a gleam in someone’s eye until November 2002—and ODF didn’t become an OASIS standard for another two and a half years (May 2005). Therefore, it was impossible for Microsoft to include ODF support in Office 2000, Office XP, or Office 2003, since ODF didn’t exist at the time. The first opportunity for Microsoft to include ODF in one of its office suites was in Office 2007—and it didn’t do so at that time because it felt ODF didn’t contain the necessary payloads to support the Office functionality that its large installed base expected. 

Point 10

Page 16, says “Since ODF is less compatible with the earlier binary Microsoft file formats than OOXML, file format translations involving ODF can result in the loss of file fidelity, a constraint that limits ODF's utility for organizations that need to support file-based workflow involving Microsoft and non-Microsoft applications.” 

The statement that ODF cannot represent the contents of legacy documents with full fidelity is false. Further, it ascribes a fault to ODF as a format that is really an application issue. 

ODF, using the defined extensibility mechanisms in the ODF standard, can represent everything in Microsoft's legacy binary formats. What in practice makes this difficult is that the proprietary legacy document formats are poorly documented and have been historically withheld from competitors. On the other hand, OOXML itself cannot represent all legacy formats without extensions. Extensions are required for features such as scripts, macros, DRM, etc., as the authors point out earlier in the report in reference to .XLSM documents. But if ODF can use extensions, it is just as capable of representing legacy binary formats as OOXML is. 

Information loss because of file translation can be due to inadequate payloads in the file formats, as well as due to application issues. However, no matter what the underlying engineering reason, organizations still hate to look at Document B (a translation from Document A) and recognize that something was lost in the translation—or even worse, suspect that something was lost. And as of today, there can be information loss when translating between the two formats (see the Known Issues page on the Open XML/ODF Translator Add-ins for Office web site). 

Specifications for Microsoft’s binary file formats have been available for free since 2006 (as long as the requester was willing to send an e-mail to Microsoft; see KB 840817). With Microsoft moving towards putting them up as a download, that will make the process even easier, and we expect that higher fidelity adapters/translators will be available in the future. 

By definition, models are abstractions of complex things. A model’s core capabilities—note we said “core”—are described by what’s in the model, not by what is possible through extensions. While extensibility is good and desired, this is typically reserved for optional or less important features. 

For example, a pilot can take an airplane not designed for taking off and landing on water and modify it to fulfill that need by removing its wheels and putting on pontoons. However, that modification would be time-consuming and probably expensive. We would claim that a seaplane (that includes both wheels and pontoons in its design, and the ability to select one or the other) is a richer model for flying around landscapes dotted with lakes. So, while it’s true that both planes can handle the requirement, we suspect that a pilot flying hunting parties around in Minnesota would view the seaplane as the better design for his specific needs. 

While we appreciate that extensions make ODF more capable of handling Microsoft’s binary formats, we would contend that OOXML is better designed—from the beginning—for that need. 

In reference to the comment about scripts and macros, those capabilities became extensions in Office 2007 and OOXML because Microsoft deprecated them due to security concerns. 

Point 11

Page 17 says of the OpenDocument Foundation, that “It was unable to successfully address requirements for capabilities related to workflows with Microsoft Office applications, however, and parted ways with the OASIS ODF-TC after it failed to gain approval for several proposals designed to make ODF more capable for addressing full-fidelity file format operations involving Office clients.” 

This statement is misguided in its omissions. First, the authors failed to note that the ODF TC evaluated the Foundation's proposals at great length, and were not persuaded that these changes would in fact bring the fidelity benefits claimed by the Foundation. Second, even some former Foundation members, when put to a vote, disapproved the proposal. Third, the vote was not against interoperability. It was an evaluation by the technical experts on the TC that the proposal would not work. 

This was clearly a controversial issue. Why was only one side presented? Where was the balance? Where was the confirmation from multiple independent experts? 

It would have been interesting for the report to give a historical examination of compatibility of Microsoft's legacy document formats between the various implementations of Microsoft's own software. Have users always had full-fidelity compatibility between these releases? Also of interest might be an analysis of what happened to users who decided to employ Microsoft's Office 2003 XML format, now deprecated. 

We did not suggest the parties then representing the OpenDocument Foundation were unable to have a review of their proposals; we simply noted that they were disappointed to fail to gain approval for their proposals. Also, it is not the case that only one side was represented in our analysis; we spoke with several ODF advocates, and incorporated extensive feedback we received from vendors including IBM, Novell, and Sun before publishing the final document. 

Point 12

On page 17, the report says, “Despite all of the debate and controversy surrounding ODF and OOXML, it's important to recognize that the standards organizations are working as designed, and that both the standards and the organizations are constructively evolving as a result.” And later on that same page, “It's likely ISO will revise its procedures to prevent similar disruptions in the future, so in some respects the OOXML episode will produce some useful stimulus/response improvements within ISO.” 

This statement misses the point. The question is not whether the organizations' procedures are perfect or not. No matter how well intentioned a process is, loopholes can always be found. Sometimes they are small, sometimes they are huge, but in all cases exploiting those loopholes is nothing less than contradicting the spirit of the process. The authors fail to consider the numerous articles highlighting how those loopholes have been exploited, and the spirit of the process subverted by stacking committees, by offering marketing consideration to business partner members who voted in favor of OOXML, and by overloading fast track processes with proposals that are of extraordinary and unsuitable length. 

The statement that this is all useful and constructive because it will be a stimulus to improvement within ISO is patronizing of ISO. It ignores the basic issue: wouldn't it have been better to have avoided the extreme exploitation of process loopholes and followed the path of previous interpretations of the spirit of the processes as others have done in the past? Also see the article “Sweden's SIS Declares OOXML Vote Invalid - Will Change Vote from Yes to Abstain – Updated.” 

We noted the Swedish Microsoft employee incident in the overview, and we don’t believe the actions of a single Microsoft employee operating outside Microsoft corporate policies is reason to conclude Microsoft’s overall intentions for OOXML are somehow inappropriate. On loopholes, that’s another subjective call, but since Microsoft competitors managed to establish control over a standards initiative with potentially dire consequences for one of Microsoft’s most important business domains, we are not surprised that Microsoft (legitimately, albeit with what some consider to be poor standards etiquette) exploited the loopholes. As we noted, we assume ISO will update its procedures to eliminate the loopholes in the future.