Why did Microsoft decide to support native PDF output in Office applications in its next version, code-named "12" and due out next year? Some analysts claim its a capitulation to Adobes domination of the electronic document space, while others guess its some kind of referendum on Microsofts own Metro or InfoPath technologies.
Turns out the answer is neither of those. Instead, says Microsoft general manager of information worker business strategy Alan Yates, end users drove the initiative.
The feature development process for Office, Yates says, works like this: Microsoft puts some features into Office that no ones yet asking for, but that the company thinks end users will find useful. Others, he says, get written in because customers demand them. PDF support falls into the latter category, to the tune of 120,000 tech support queries per month.
Many users already can make PDFs in Office, using sophisticated plug-ins from third parties such as ScanSoft. Adobe itself offers probably the most feature-rich plug-in suite right in the Acrobat box. Macintosh users get the functionality built into the operating system if theyre using OS X or later. Windows Office users can choose from many free PDF-creation options, too, most of them simple print drivers downloadable from Web sites.
This ecosystem of PDF support for Office has been around for years. Its "101" stuff for many users. Yet the amount of feedback Microsoft gets about PDF, Yates says, shows that the process of using third-party software to export Word files to PDF still confounds a significant number of Office users.
This group would be better served with Office-native support out of the box, the company decided. Feature development started more than a year ago with the Microsoft Publisher team, which began work on supporting PDF 1.4—whose files are well understood by the printing industry—for its next rev. From those efforts grew support for PDF across Office.