Bill |
Ralph
Walden, the development lead for HTML Help has retired. This causes a
lot of questions about possible changes to HTML Help and to a degree, a
sense of insecurity about the future direction of the technology. What
will be the biggest change from the perspective help community? |
Peter |
I
think the biggest change for Help Authoring community is really the
change to their interactive environment. For years there was a visible
Microsoft representative, Ralph Walden, on newsgroups, forums and at
conferences. His presence built up a comfort level for people, and an
expectation of having access to the lead developer of the technology,
which in many ways was unique. If you look at other technology areas
within Microsoft, you don't see that kind of interaction of the lead
developer with user community.
With Ralph's retirement, not only is there a natural concern over the
future progress of HTML Help but there is a reaction to the loss of
that intimate communication channel into the development process, into
Microsoft, and back to the community to acknowledge their concerns. |
Bill |
It
may not be widely known that Ralph's evolvement was at his own
initiative and not, as you pointed out, normally done by Microsoft
development leads or program architects? |
Peter |
That's
true. If you look at other products, such as Visual Basic, the
development team depends more on a carefully selected group of people
to create a limited beta environment. This group is chosen based on use
of technology and products, particularly pre-release products, in order
to get a broad but comprehensive set of focused feedback. Working with
a small but highly effective group lowers the impact on the development
team.
HTML Help was somewhat unique in that it had a large public beta very
early on, with the development lead generally accessible to the entire
user community. That was an extremely demanding situation that Ralph
was uniquely able to manage. |
Bill |
What was unique about HTML Help that caused it to go in such a public direction?
|
Peter |
Since
HTML Help started out as a port of WinHelp to HTML and the Internet, it
was natural to simply continue operating very publicly as we had with
WinHelp. The concerns and requirements of WinHelp were already well
understood by Microsoft and the help community, making the initial
demands pretty straightforward; however, the focus soon changed. |
Bill |
How So? |
Peter |
New
functionality was added. Information types and embedded help
capabilities were conceptually different than for WinHelp. HTML Help
quickly became strategically significant in ways that WinHelp never
was. It became part of the browser competition, as well as requiring
input and interaction with standards bodies such as the W3C.
|
Bill |
So
with the stakes so large and the issues somewhat public already with
the W3C involved, Ralph began to solicit feedback from the Help
community. What kinds of useful feedback did you get? |
Peter |
Several
things came through loud and clear. One was the priority of compiled
HTML. Authors and users did not want to deal with the Web model of
thousands of individual files for distribution and maintenance. They
liked the compiled WinHelp authoring and distribution model. |
Bill |
But
didn't this create a problem relating to standards and the W3C, since
compiled HTML used in Windows will be a pervasive technology? |
Peter |
You
bet. There is a very interesting dynamic about the evolution of
anything relating to HTML and Microsoft's commitment to the process.
First, we design and implement something internally that we believe
meets some needs we have identified. We make sure we’re on target by
having some "early adopters" use it, and then we submit to W3C a
specification that reflects that functional technology. |
Bill |
This
is different than designing a specification, trying to get that
accepted, and then building something that reflects the accepted
specification. Instead, you want to get a technology working that meets
specific needs and then submit that technology for acceptance. |
Peter |
Exactly.
We propose to W3C any HTML-related technology we have produced for
possible inclusion in the evolving standards. Our approach is to prove
the value of a technology before submitting it, rather than submitting
something that may not prove to be valuable. This saves investing in a
protracted standards discussion over what may prove to be a dead end. |
Bill |
Is it your hope that this will speed up the process of technology advancement and incorporation into the HTML standards process. |
Peter |
Correct.
While it does indeed speed up the process, it also introduces a risk
factor in the sense that the W3C may decline to accept the standard or
it may be altered in the process. |
Bill |
Let's
take an example that help authors can relate to: compiled HTML. How has
compiled HTML worked its way through the standards process thus far? |
Peter |
That's
a very interesting situation since it is not yet clear that the
compiled HTML format is something the W3C wants to be involved in. You
could make a case that compiled HTML is a platform specific service.
|
Bill |
Couldn't
you argue that if HTML is truly universal it can't be a platform
specific service? Should that file structure be capable of being
recognized by any OS, not just a Windows-based environment? |
Peter |
Correct,
and that’s why we’ve worked hard to ensure HTML Help content can be
viewed on any platform. The way we implemented compile HTML, we tried
to segment the creation process so that the compiling step was separate
from creating the HTML Help content itself. This did not tie the
content to only the compiled model as in WinHelp. |
Bill |
If
you look at the history of hypertext, you see a progression over the
years from file-based hypertext to compiled hypertext. Early DOS and
Unix-based systems used file-based information systems but soon the
demand for compiled hypertext was met by systems like Folio, HyperCard,
and WinHelp. The web is moving in the same direction. Won't this issue
have to be resolved by the W3C? |
Peter |
There
are couple of different paths the W3C could take. One path is to
specify a binary file format that is portable across multiple
platforms, as they’ve done with PNG, the Platform Neutral Graphics
format, but that is not the typical domain the W3C normally operates
in. They usually deal with source-level specifications rather than
binary specifications. Another path would be to specify the URL syntax
for compressed HTML files. |
Bill |
Wouldn't
that [a new URL syntax] solve the problem since it would allow anyone
to get at the information with a plug-in for the specific environment,
but the path for access to that information would be open and available? |
Peter |
You're
right. That way the compression algorithms and binary formats being
used are irrelevant, since the information is delivered in uncompressed
HTML and the server is responsible for dealing with the translation
issues. This allow the best technology available to be used behind the
server wall, but the user gets what they need in a standardized HTML
format. |
Bill |
Isn't that consistent with what we already see with database driven
sites that are using a proprietary storage format to deliver HTML pages
on the fly?
|
Peter |
Yes.
The server takes over the responsibility for a consistent addressing
mechanism and a consistent data presentation mechanism.
|
Bill |
We don't have that for compiled HTML yet. Is that going to be a problem for the future? |
Peter |
That
process is still under discussion. What I do know is that Internet
Explorer on Unix and the Macintosh, as well as Windows, will support
the same URL syntax and protocol to access compiled HTML.
|
Bill |
Where
does leave other vendors and environments such as Sun and other Unix
vendors who may want to access a compiled HTML file from within their
programs or environments? |
Peter |
For
the platforms we’ve ported Internet Explorer technologies to, which
includes Solaris, the technology is in place and documented for anyone
to use. The underlying "structured storage" technology used for
compiled HTML was given to Active Group, one of several organizations
under Open Group, along with other COM technology. I believe the
information necessary for writing a structured storage implementation
on another platform, including reference source code, is available. So
is the information needed to implement a custom protocol for accessing
that "structured storage" data.
A different question is whether the information necessary to implement
the same "pluggable protocol" infrastructure that’s part of the
Internet Explorer technologies, on a different platform, is available.
That’s hard to say. It certainly requires a very flexible design for
the platform’s underlying networking architecture, and that’s a pretty
broad question.
|
Bill |
Ok.
Let's look at another issue surrounding compiled HTML: network access.
WinHelp, when accessed on a server, only supplied the single topic
requested to the WinHelp viewer on the client. Doesn't compiled HTML
Help send the entire CHM file across the network for a single page
access? |
Peter |
In
the current implementation the entire CHM file is downloaded into the
client's browser cache. As individual topics are accessed they are
pulled out locally. The ability to use HTTP to access a single page
from a server-based CHM file is planned for a future release. This is a
very important and high priority feature I might add. |
Bill |
So, this is not available in the version of HTML Help released with Windows 98? |
Peter |
No.
It requires substantial work on the server to access an individual
topic within a CHM and deliver it over HTTP. We’re talking to the web
server team about implementing that, but don’t have a firm schedule to
announce yet. |
Bill |
Is this scheduled for the 2.0 release, toward the end of this year? |
Peter |
We've
stepped back from using release numbers as a way of expressing time, so
I can't give you a forecast on the time frame or what to call the next
release at this point. |
Bill |
As
we approach the release of Windows 98, the original target for the new
help paradigm, do you see the attempt to retrofit HTML on previous OS
versions as a mistake? |
Peter |
I
think the original notion was of HTML Help as an HTML version of
WinHelp with just one file and a ubiquitous viewer. Looking back, I
think we all see now that the context for HTML Help was vastly more
complex than the context for WinHelp. You have demands for multiple
viewers from multiple vendors and a stunning array of related
technologies that introduce complex dependencies. For example, what if
the file format changes to introduce better compression, either of the
text or the graphics? How do you include the various plug ins available
into the compiled system? Are they always external to the compiled file?
|
Bill |
Yes, the complexity gets scary and the distribution problems grow exponentially. |
Peter |
Correct.
How do I distribute a Help system into a user community when I don't
know what viewer they have installed? This is one reason why help has
always been seen as an operating system function, to make sure the
functionality for Help is always available to the user. |
Bill |
So,
was it mistake to release HTML Help separate from the new operating
system? This scenario is similar to having released the WinHelp 3.1
viewer before Windows 3.1 was shipped. |
Peter |
The
original idea was to have HTML Help as part of Windows 98 so that the
first time the technology would be shipped would be concurrent with the
release of Windows 98. We found that we had version of HTML Help that
was usable long before the operating system would ship, so we released
it on its own. In looking at the various challenges that have come up
from the decision to release HTML Help, from the earliest previews
through version 1.1, you could make an interesting case that it might
have been easier on all of us, both Microsoft and the help authoring
community, to have held off releasing the technology until it was in a
more complete form. |
Bill |
Why didn't you wait until the release of Windows 98? |
Peter |
In
the beginning we didn't fully understand the expanding scope of HTML
Help beyond the framework of WinHelp. It quickly called into play many
more technology areas and dependencies than initially expected, and as
a result it moved beyond areas supportable by a basic viewer. Life
became much more complex than we anticipated. |
Bill |
So,
you had a problem. A technology originally planned as a Windows Help
system has mutated into an end all, be all, cross-platform demand. |
Peter |
With
WinHelp there were few cross platform issues, and never a real
expectation that Microsoft would supply a cross platform viewer. Even
when someone created a WinHelp viewer for another platform, such as for
Unix or the Mac [Bristol's HyperHelp and Altura's QuickHelp], they
didn't try to view the existing .HLP file. Instead they created their
own compiler that used the RTF source files and their own viewer that
understood their compiled format.
This has not been true with the evolving HTML Help. Since it was based
on HTML, it was automatically expected to be cross platform, with the
expectation Microsoft would supply the complete cross platform
solution. That wasn't Microsoft's expectation for HTML Help in the
beginning.
Many of the complexities and issues we have seen develop over the life
of HTML Help were not obvious to us in the beginning and revealed
themselves in a stepwise fashion. We would implement a technology and
it would complicate the process in unforeseen ways. |
Bill |
So HTML Help has been similar to a Pandora's box. |
Peter |
In
a way. We would open a doorway and then expose a hallway with many
additional doors, which would go on and on. So we’ve gotten to a point
on Windows where we can deliver a robust set of features, with nearly
all of the features of WinHelp, plus the additions that HTML allows. We
then have to decide whether to deliver a subset of functions that runs
on any browser and on any platform, or deliver the full functionality
that only runs on platforms where we’ve implemented the Internet
Explorer technologies.
|
Bill |
Why
not do what the user community expected and deliver an installable
viewer that doesn't register itself as a browser? Sure, it may be 95%
of IE, but it is invisible to user and leaves their Netscape
installation alone. |
Peter |
We
have always had the intention of delivering exactly that. However,
there are a number of remarkably complex licensing issues involved. I
have personally spent a great deal of time trying to navigate through
those issues to get that product to the help community. The goal is to
not impose the IE browser interface on the HTML Help interface. |
Bill |
Do you mean issues like having an independent favorites list linked only to your HTML Help? |
Peter |
That
is one of many such issues. We have been committed to making this
viewer available for those cases where your customer doesn't have a
viewer capable of displaying your help system. The install of this
system should not interfere with your user's preferred browser
settings, whether that’s Netscape Navigator or Internet Explorer. |
Bill |
You
originally proposed a product called HHRUN to meet that need, to be
available through the HTML Help distribution site. HHRUN now appears to
have been consolidated into the general distribution process through
the IEAK site. |
Peter |
You
are correct. We have decided to consolidate the distribution of all
Internet Explorer components through one location. We’ll be making
available the Internet Explorer 4 minimum install for free
redistribution, under a license agreement that requires the use of the
"silent install" facility. This "minimum install" package is the
smallest collection of components that are capable of rendering the
baseline HTML for a help system. Combined with the HHUPD package, which
contains the latest HTML Help components and also installs silently, a
help author can redistribute a fullfeatured HTML Help viewer that
doesn’t interfere with a user’s browser configuration. The license agreement
that enables this should be live on the Microsoft web site when this
interview is published. [ Note: You will need to register to properly
access the site. After clicking ISV License click Registered and enter
your information ]
We’ve encouraged help authoring tool vendors to wrap this IE minimum
install in a setup package that includes the latest HTML Help
components, and would be redistributable with your help project. |
Bill |
But, in the File Types association, it registers itself to display the CHM extension. |
Peter |
Precisely.
We essentially are installing the guts of the browser, the "Internet
Explorer technologies" to enable viewing CHM files, without actually
doing a "browser" install.
|
Bill |
How
is this "silent install" license going to different from the licenses
available today from the Internet Explorer Administration Kit (IEAK)
web site? |
Peter |
The IEAK licenses are designed for people who want to distribute the
browser with their own customization. For example, they can build a
customized version that can include components they’ve developed
themselves, pre-loaded Favorites, etc. These customizations are seen as
valuable in themselves, in addition to the value of the browser, and
there are various marketing and reporting requirements included in
those licenses.
The "component license" is different. There are no reporting or
marketing requirements, despite what people may have heard or seen in
earlier licenses on the IEAK web site. This is analogous to a software
developer redistributing the grid control that comes with VB. |
Bill |
The
long wait to release the minimum install package was not caused by the
current situation with the DOJ but by internal licensing issues inside
Microsoft? |
Peter |
That
is correct. It has absolutely nothing to do with the DOJ, except that
the DOJ is keeping our lawyers pretty busy. It’s been hard to keep them
focused on this matter. |
Bill |
Do
you have any idea when this "component license" install will be
available? There is an ongoing and immediate need in the help community
for its release. |
Peter |
It is available now. Help authors should go to Microsoft's web site at
http://ieak.microsoft.com/isvlicense.asp to review a new license
agreement that enables them to redistribute the Microsoft Internet
Explorer Operating System Components with their help system or
application.
Remember, there is no license fee or royalty associated with this
license, nor are there reporting or marketing requirements as required
by the IEAK licenses.
After accepting the license agreement, they'll be taken to a web page
with detailed download and setup instructions, which are referenced by
the license agreement and must be followed, including the "passive" or
"silent" install of these components. Note that all files downloaded
according to the download instructions must be redistributed with your
application, no files can be removed.
|
Bill |
Let's go back to the "complexity-and-Pandora's-box" issues. Where they evident before the 1.0 release? |
Peter |
Yes
they were. As all the elements came together, it became apparent that
this was considerably more complex and interdependent than anyone had
considered. Items such as Alink and Klink introduce a dependency on
compiled HTML, which meant that Full Text Search would also be
dependent on compiled HTML. Each step created an ever expanding web of
complex dependencies.
|
Bill |
Some of this complexity obviously created management issues? |
Peter |
Yes
it did. We started off with Ralph and a small group of people who had
worked on a variety of help systems. A little over a year ago Kate
Harper joined the HTML Help team as the first program manager. Now we
have at least three program managers overseeing different aspects of
HTML Help, and many groups around the company contributing technology.
In addition, Help went from being a small backwater at Microsoft, to
being a technology that Bill Gates discussed during his recent
testimony before the Senate Judiciary committee. There was a tremendous
increase in pressure and demands. Certainly that brought a lot of
change to the group work environment. |
Bill |
So you went from Ralph, to Ralph and Kate, to multi-project manager administered project. |
Peter |
Yes.
We now have a complex product spanning multiple technologies, multiple
product groups, administered by multiple managers. As HTML Help moved
into this broader and more complex process and the new development
organization took ownership, the feedback both from the user community
and our own internal user education people was that HTML Help was not
as stable as they required.
Since this technology is both an operating system core technology, and
a technology that all Microsoft product lines depend on for their
documentation, this had to be corrected. The HTML Help team has largely
stopped working on new features, and is focused on fixes.
The team talked to a number of internal customers such as Windows 98,
Microsoft Office, Windows NT, and others. We’re confident that by
meeting the needs of those disparate internal customers, we’ll be
meeting the needs of the rest of the Help community.
As a result, we have solid plans for fixing specific bugs in specific
time frames, doing some feature completion work, and making a series of
technology releases during 1998 and beyond. You’ll be able to get these
releases from the HTML Help web site.
|
Bill |
Do you feel you have gotten a good handle on the situation so that you can now move forward in confidence? |
Peter |
Yes. |
Bill |
Windows
98 has a version of HTML Help that is different from version 1.1. Are
you going to release a version of HTML Help that is equivalent to the
Windows 98 release? |
Peter |
Yes, HTML Help Version 1.1a
is available on the HTML Help web site. We meant for it to be posted
June 25th, the same day Windows 98 was available, but the web site
folks have been extremely busy so there was a few days’ delay.
|
Bill |
How are you going to handle communication in this post-Ralph era? |
Peter |
Although
we don't have a replacement for Ralph and his direct contact with the
community, a number of the program managers are monitoring the
newsgroup and CompuServe forum for hot issues or concerns.
We’re also looking to the HTML Help MVPs as a conduit for interaction,
support, and feedback. The MVP program has been around for quite some
time, starting in the Visual Basic CompuServe forum as I recall. We
have an initial set of MVPs, but we expect HTML Help community, like
the other communities served by the MVP program, to nominate the people
they’d like to see as their MVPs. The official MVP Referral Form is at:
http://support.microsoft.com/support/supportnet/mvp/mvpref.asp
Everyone is welcome to nominate the people they consider MVPs. General info on the program can be found at:
http://www.microsoft.com/supportnet/SupportPartners/MVPs/BrochureGeneral.htm
|
Bill |
So the MVPs are expected to take on a pivotal role in support and communication for HTML Help. |
Peter |
Absolutely.
We’ve started a series of "MVP Summits" to talk about our plans, get
feedback, and address issues, to make sure there’s good communication
between the HTML Help team and the MVPs. |
Bill |
I, and I am sure we, the Help community would like to thank you, Peter, for making yourself available for this interview. |
Peter |
You're welcome. |