Curated for content, computing, and digital experience professionals

Category: Content creation and design (Page 56 of 60)

Technologies and strategies for authoring and editing, including word processors, structured editors, web and page layout and formatting, content conversion and migration, multichannel content, structured and unstructured  data integration, and metadata creation. 

Office Documents and eXtensibility

Jon Udell wrote yesterday that we should really be getting beyond the office document format debate swirling around the Massachusetts decision, because all heavy footprint authoring applications are headed for oblivion in our increasingly net-software-as-service world. (David Berlind also weighs in on the death of fat clients apps.) Tim Bray is skeptical because “… authoring software is hard.” While my view of the ODF debate is much closer to Jon’s than Tim’s, I agree with Tim’s caution here. While my coding skills were never in the league of either of these guys I have spent a lot of time working on authoring software, and more importantly, collecting requirements from users. Admittedly this was well before the Web existed, but what hasn’t changed one bit, is the need for authoring software to meet a staggering array of complex user requirements. Authoring software has to be flexible and extendable to meet the always unanticipated user needs. Authoring software is hard, and differing formatting and integration requirements will keep it that way.
Note that extending software functionality is not unrelated to extending the encoding of the content, which reminds me that…
Ironically, the reason I agree with Tim here is exactly why I disagree with the ODF decision: extensibility should be the first requirement of a government decision on an open document standard, and ODF looks uncomfortably like a limited implementation. From a practical point of view, scope is critical, but as Jon says, “In theory, governments should mandate standards, not implementations.” Perhaps the way to think about it is that governments should mandate standards (XML) but adopt implementations (form OASIS and Microsoft and perhaps others). Realistically there will be multiple versions (implementations) of each anyway, so a single implementation will never be enough.

KeyContent.org

If you haven’t yet visited KeyContent.org, check it out. It is quickly becoming an incredibly useful wiki on issues related to technical communication, information architecture, and web design. Directors Bill Albing, Rick Sapir, and Sherry Steward got the ball rolling.

DITA and the Beatles

CM Professionals founding director and all-around great guy Bob Doyle has a cute take on DITA in the current EContent Magazine newsletter. Bob makes a lot of very good points, and also offers perhaps the best plain-English explanation of DITA’s value to implementers I have read:

While it is doubtful that out of the box DITA will find widespread use without customization (called specialization in DITA speak), the ready-made generic topic, and three “information-typed” specializations called concept, task, and reference, will get documentation teams producing very quickly. These documents will also be easily exchangeable with others. Because specializations inherit (thus the Darwinian name) properties from the general topics, their default behaviors–like printing, conversion to PDF, or XHTML Web pages–will produce decent results when transformed by default DITA XSLT style sheets.

One detail deserves mention though in Bob’s writeup. He refers to a “rumor” that Adobe recently used DITA to produce documentation. We know this rumor to be true, and have written about how Adobe used DITA to produce localized documentation for the recent release of Creative Suite 2. And, to all of Bob’s positive points we can add this one–at least two major companies (Adobe and Autodesk) have already used DITA to produce major documentation releases. Interestlingly, both Adobe and Autodesk used the same core technology to work with DITA–FrameMaker on the authoring side and Idiom World Server for content management and localization.

Ajax

If you have been hearing about Ajax technology and are curious, you might want to check out this pretty cool dictionary site. The developer offers a helpful explanation of how it works, including some potential risks and tradeoffs. Up until now, Google Suggest has been kind of the canonical example of Ajax for this kind of application, but I think I like this one better. Some of the bloggers over at ZDNet have been doing a nice job of explaining Ajax and other such technologies and how they will impact traditional applications such as Microsoft Office. I think there are all kinds of implications for content management, with authoring and search interfaces only the beginning.

FrameMaker 7.2 and DITA

FrameMaker 7.2 was announced this week (see our news here and Adobe’s home page for the product here). Our news story touches on many of the new product features, but a few things are worth highlighting. Overall, the release is a significant step forward for FrameMaker, and should be seen as very welcome news for organizations that rely on the product for technical publishing.

  • The new release adds XML schema support. While Karl Matthews, Adobe’s Group Product Manager for FrameMaker, was careful to point out to me that the schema support does not extend to data typing, I think this is sufficient for the kinds of publishing applications FrameMaker users would develop.
  • The product now includes XSLT support. XSLT transformations can be invoked at the time a structured FrameMaker document is opened or saved. This will enable, for example, a “save as” function that could invoke an XSLT transformation on an XML document to create other content sets, metadata extractions, and so on. This is a clever addition to the product, and gets FrameMaker developers away from being reliant on the FrameMaker SDK.
  • The product comes with a starter application for DITA. This is also welcome news, as there is a groundswell of support for DITA, and an independent group had been working on a separate FrameMaker application for DITA. This gives FrameMaker users a DITA application supported by Adobe. Moreover, the FrameMaker DITA application reflects a great deal of work Adobe had done in-house using FrameMaker to produce the documentation set for Adobe Creative Suite 2. (For Adobe’s own case study of how they used FrameMaker for this project, you can download this pdf. A related case study at Idiom’s web site describes how FrameMaker was used with Idiom’s WorldServer technology to manage the localization of the documentation into many languages.)
  • The new version also adds some additional features and functionality for migrating unstructured FrameMaker content to XML. They have a pretty useful Migration Guide here (pdf).

On the whole, I was impressed with what I learned about the new release. It has some important new structural features (schema, XSLT), and the DITA application is timely and useful to a growing number of potential users. The strength of this release should quiet some of the feelings among users that Adobe is not fully committed to FrameMaker. Moreover, at a list price of $699, FrameMaker continues to provide a great deal of value for its user community by combining XML editing, high-quality print publishing, well integrated support for Adobe PDF, and support for multichannel publishing.

Microsoft does the right thing with Office & XML

Microsoft announced that XML will be the default file format for Office 12. I’ll look more at the details and what this means to OpenOffice etc. when I get a chance, but this is certainly great news and another major step forward for XML in general and Microsoft’s support for it. It looks like Microsoft has addressed (full Microsoft press release) the main concerns that critics exposed during the OpenOffice debate we have been covering here and in our conferences. Tim is impressed!
Update: Dan Farber has some additional info from Microsoft.
Update 2: Dan points to info from Rick Schaut on Office 12 Mac XML support.

Microsoft to Make XML Default File Format in Office 12

Microsoft Corp. announced that it is adopting XML technology for the default file formats in the next version of Microsoft Office editions, currently code-named “Office 12.” The new file formats, called Microsoft Office Open XML Formats, will become the defaults for the “Office 12” versions of Microsoft Office Word, Excel and PowerPoint, which are expected to be released in the second half of 2006. The interoperability capabilities of the Microsoft Office Open XML Formats enable Microsoft Office applications to directly access data stored in systems outside those applications, such as server-based line-of-business applications. These third-party applications, in turn, can access data stored in the new Office file formats. Microsoft Office Open XML Formats are fully documented file formats with a royalty-free license. Anyone can integrate them directly into their servers, applications and business processes, without financial consideration to Microsoft. People using Office 2000, Office XP and Office 2003 will be able to open, edit and save files using the new formats, thanks to a free update available as a download from Microsoft that enables those older Office versions to work with the new formats. Documents created with the current binary file formats in Office also will be fully compatible with “Office 12” applications. So workers can save documents to their current formats and exchange those documents with people using “Office 12” — and when they upgrade to “Office 12,” they can continue to use their existing binary documents. Microsoft will provide further technical information about the Microsoft Office Open XML Formats, including draft versions of the schemas, to help ensure that developers and IT professionals can be prepared to take advantage of the formats before product shipment. People interested in the new file formats and the next version of Office can get additional information beginning Monday, June 6 at a preview site, http://www.microsoft.com/office/preview

« Older posts Newer posts »

© 2024 The Gilbane Advisor

Theme by Anders NorenUp ↑