My name is Gordon Meyer. I work in Apple's Instructional Products group. Instructional Products makes the on-screen help and the printed manuals that come with Apple products. And in this session, we're going to be talking about Apple Help. You know, it was five years ago at WWDC that Apple Help was first introduced. For back in Mac OS 8.5, it was. So I see some people who have been with us all along from the very beginning and developing for it.

Thank you. Today we're going to have some changes to announce that I think you'll be very pleased about. You've certainly been very patient waiting for them. And I see a lot of new faces, too. So I hope you're here to find out what Apple Help is all about. If you're waiting on the fence to see if we're serious about an HTML help system, well, you can keep waiting another five years or come on in. The water's fine. We'll talk about how you actually generate your content. You'll see how easy it is to hook things up.

Now I'm the kind of guy who likes to eat dessert first, so we're going to start with a demo. And the demo is where all the exciting stuff is, and so we'll do that first. And in fact, there are so many changes to Apple Help, so I'm going to start with a demo.

I think you've reached the hood in the last year that you might say, "My goodness, you've changed everything." Well, we've changed a lot. But you don't have to worry. If you've been developing for Apple Help for a while, your stuff still works. So in that sense, we've changed nothing.

From then, we're going to talk about how to develop for Apple Help. You'll see how simple and easy it is to get your book in the help system and running under the system. And then finally, we're going to wrap up with some tips about how to optimize your help system and how to take advantage of some of the unique features that Apple Help presents.

So I'll let you in on a secret. We're actually going to finish early today. We don't have the full time allotted. That's not because there isn't a lot to cover, because there is, and there's lots of things to say. You'll get to listen to me blab for several minutes. But it's really a short presentation because Apple Help is so simple and straightforward. We've worked really hard to make sure that you can deploy your help content quickly and easily. But enough of that. Let's get to the demo.

So, to get started here, I'm going to open up the Help Viewer. This is Panther that you all have in your registration kits. Wow! Look at that. That was fast, wasn't it? In fact, I almost don't believe it wasn't running. Let's try it again. About two and a half seconds. Yeah. Sure. You know, I saw you in the back of the room. I said I was going to open up the help, and you got up to go to Jamba Juice. Figured you could make it back in time before I was ready to talk again.

It's much faster in Panther. We've done a lot of things to really improve it, and I know that was a much-needed improvement. We certainly are aware of that and have heard it loud and clear from all of you. But that's not all. You'll notice as I mouse over this sample page here, we're getting some text decoration, and that's being accomplished. The links are underlining. That's being accomplished with CSS.

There's a style sheet here that specifies this text decoration. So Help Viewer now works with cascading style sheets and HTML4. In fact, it works so well with web standards that you can now go out to the Internet and find a site that generates content for you, creates HTML templates, and use them yourself.

Just to prove the point, I went out and found such a site and asked it to create a couple of dummy help pages for me. Now, I don't necessarily recommend these as great help layouts, but they do serve a really interesting point. I'm going to show you how to create a style sheet for your Mac OS X.

This is HTML 4.0 with a style sheet. As I click these buttons here, you'll notice that I'm getting some nice rollover effects, and lots of colors are changing, and content is rearranging itself on the page. That's all accomplished through CSS with the same body text appearing in each one of these styles.

This turns out to be really powerful not just for web development, but for help development, too. Because the more you can do to separate style and decoration from the content, the easier time you have developing your content. So finally, you can do that with Help Viewer. Another thing we support is JavaScript. So this is a very simple JavaScript demonstration downloaded from another website and just dropped into Help Viewer. You'll notice that the time is incrementing as I talk here.

There are lots of things you can do with JavaScript in the Help, and luckily they all just seem to work. I'll stop the timer there and start it. This go-back button isn't a hard link to the previous page, but rather a JavaScript function that tells the viewer to go back in its history, to go back in time. And that works in Help Viewer just as you'd expect it to. So finally, web standard support and help viewer for Panther. Let's go back to slides.

So how did we accomplish this? Well, it's no secret if you've read your program or have been attending other sessions, Help Viewer is now a client of WebKit. We're using the Safari technology to support all of our HTML display. This gives us a lot of speed and a whole lot of standards. Help Viewer now supports HTML 4.0.1. That includes frames and tables and forms, something you couldn't do in Help Viewer before. Cascading Style Sheets Levels 1, 2, and 3, such as it is so far. JavaScript 1.4. DOM Levels 0, 1, and 2, including some Microsoft DOM extensions.

and support for Netscape Cookies, Netscape-style plugins, Java applets, more character sets than you can shake a stick at, bidirectional text, and contextual letter forms, whatever those are. Seriously, I probably don't even have the complete list. What you should do, since you're help authors, is go to the session noted there.

It's session 411, Web Standards. It's 10.30 tomorrow morning. You'll hear from the Safari team, from the people who implement WebKit, and all of the stuff they talk about. It works in Help now, and you can use it when you deploy Apple Help. And while you're there, say, thank you for me.

But there actually is more to Help Viewer. We've done more than just implement WebKit. We've made a number of changes that make it so much faster and easier to use. We've updated and standardized our download policy. Now, Help Viewer uses the Internet to retrieve remote content. It wasn't very fast at that. And in fact, sometimes we retrieve content when it wasn't necessary.

What we do now is we use the cache more as you'd expect, and we check the user's network connection. If the user has a network connection and has a good network connection, meaning that the servers are responding quickly, then we will ask the server if there is anything newer.

And if there is something newer, we download it and put it in the cache. If there isn't something newer, then we show what we have on the machine already, that being either the cached copy or the local copy that you installed with your help system. This is a good change. It really speeds things up.

So you might say that we've changed everything. We certainly have made everything faster. And we've adopted a lot of standards underneath the hood. Another thing that we've done is we've improved launch time by changing the way that index files are loaded. Now in Apple Help, books are indexed for searching. That's how we get our searching capability.

And we're going to talk more about searching in a few minutes. One change for Panther is that the Help Viewer expects to find the index for the book in the location where the indexing tool put it. And it expects it to have the name that the indexing tool created for it.

So please don't change the name of your index file. And don't change its location. Now if you do, Help Viewer will still find it. It'll go traipsing through your book and find what it needs. But as you can imagine, that slows it down. So you can help all of us keep Help Viewer faster by leaving your index file as it was created by the indexing tool.

Now what I'd like to do is talk about how to deploy Apple Help. Now the main point is that all of your existing content continues to work. A book created for Apple Help in Mac OS 8.5 works today. One thing you do want to do, though, is look at your content using the help viewer you have on your Panther CD. The renderer is different, and every HTML renderer has slightly different ideas about font metrics and sizing and placement and that sort of thing.

So I'm very confident that what you have is going to look good, but it might look a little different than it does under previous incarnations of the help viewer. So it would be a good idea to look at it and see if you're happy with it and maybe make any HTML adjustments you feel are necessary.

You'll also want to look at your QuickTime movies. If you have QuickTime movies in your Help, they're still going to work. But previously, Help Viewer played QuickTime files natively. Now, Help Viewer uses the QuickTime plugin. This is a good thing because it gives you lots more parameters you can use with the embed command.

The QuickTime plugin supports all sorts of interesting options. You might want to take a look at those. Those are documented in QuickTime Help. And see if there are any you want to take advantage of now with Panther. If you don't change anything, you can expect your QuickTime movies to behave as they did before.

So that covers the changes to Apple Help for Panther. Let's spend the next few minutes talking about what Apple Help is, why you might want to use it, and what you can do when you deploy your help book to take advantage of some of its unique features. So what is Apple Help? Well, Apple Help is the help system for Mac OS X.

It's built in, and sort of the most visible component of that, the thing that users interact with, the thing that we all see, is the Help Viewer. The Help Viewer is an optimized, lightweight HTML browser, and it's optimized for help delivery. What we've done is we've built in a lot of features and a lot of careful attention to the UI to make sure that it's good for delivering help and it provides a consistent user experience. If you went to John Glensy's Adopting Aqua session yesterday, you might remember that he talked about Apple Help as one of the key components of Aqua and one of the checklist points for ensuring that you're providing a good Aqua experience.

One of the reasons for that is that users turn to help when they're the most frustrated with their computer. Most users don't read the help just for fun. They do it to find out an answer to a question. They're trying to accomplish something. They've reached an impasse. They're trying to use your UI or they have another question and they don't know how to proceed. So at that point, they come to the help. By coming to the help viewer, they have a consistent user interface, one that they've seen before, that behaves the way they expect, that provides lots of features, one of which is full text searching.

Our searching is relevancy ranked, so when you type in your question, you get a nice list of results back. And the presentation of those results is similar to what users experience in other searching throughout the system, such as the Finder and Sherlock and Mail. It's not a part of the user interface that people have to figure out because it's different in help than it is anywhere else.

Now our search engine is really fast, and it's really pretty good. It supports natural language query, so while you can type in "burn CD" or "fire bad" if you're the Hulk, I guess, it's better to type in something like "how do I make a CD? How do I record a CD?" The Help Viewer will parse that correctly and give you the results in a nice relevancy-ranked way.

Another feature of HelpViewer is AppleScript-based automation. We have special help colon URLs that can trigger an AppleScript. So if your application is AppleScriptable, you can provide links within your help that automate actions for users. This is a great way to speed users back into using the interface and getting a problem solved.

You can automate things like changing preferences, opening preference dialogues, completing tasks for the user and so your instructions are shorter, so they're less complicated, and you just have a better experience with the help in your product. It's another great reason to make your application AppleScriptable because you can take advantage of it yourself in your help system.

We've talked a little bit about the display of multimedia content. Help Viewer does that. It now uses plug-ins. QuickTime and Flash are built-in because they're distributed automatically with WebKit, but as additional plug-ins are loaded into WebKit, they become available for use in Help Viewer. This opens up a lot of interesting doors, particularly if you're documenting a high-end application and you need a specialized plug-in to display parts of your help content, now you can do it.

Gordon Meyer HelpViewer also supports remote and local content. This is a somewhat hidden feature of the help, but it's very powerful as a software developer. This allows you to ship your application's help with your product and then continue to maintain that help on the internet as you discover what kinds of questions people are having, as you discover mistakes in the documentation, or other enhancements you can make.

You make these available to your customers simply by updating the copy of the help that's on your internet server. HelpViewer retrieves it for you and displays it for the user when they have a good network connection. We're going to talk a little bit later how to best take advantage of this feature of help.

And finally, the last and perhaps most important advantage of using Apple Help is that there are system-wide APIs for calling it. Certainly that's how the Help menu works, which we're going to talk about in a little bit, but there are also other ways to talk to Help Viewer that allow you to provide a good help experience for your users using things like Help buttons and so on.

So, maybe I've sold you. You say, wow, Gordon, that's great. How do I make my Apple Help book? How do I get started? Well, It's really very easy, and there are only four steps. So let's go over them. Step one is develop your help content. Write your HTML.

Now, you can do this in whatever authoring tool you normally use-- BB Edit, Dreamweaver, GoLive. And now, because we use WebKit and support web standards, you can even use tools on other platforms that create help. I know that a lot of you use things like RoboHelp and so on. You can get them to output in a format that supports web standards and will now work in Help Viewer.

So the only thing special you have to do to your HTML, over and above writing it like you normally would, is to add one meta tag. It's the Apple title meta tag, and the value of the tag is the name of your help book. Now, this is a really important value. You put this in the start page of your book, your home page, whatever page it is that you want users to see when they open Help Viewer. viewer.

Add this tag, and it provides the name of your book to the system, and as we talk about some of the other things that you need to do, you'll see why this Apple title tag is so important. The nice thing about this, because meta is a standard HTML tag, you can go ahead and add it to your content, and even if you deploy that content elsewhere, such as on your website, it won't interfere with anything. Browser is all expected, and just ignore it.

So after you've authored your HTML and added that meta tag, step number two is to index your help for searching. Our search engine works because Help content is pre-indexed. To do this, you use the Apple Help indexing tool, which you already have. It's installed in developer applications. There are a few preferences you want to look at and decide to set. One is to enter a remote route for your content. If you're going to put Help on the Internet and you want it updated, then you enter an HTTP path in the indexing tool preferences.

You want to select a tokenizer for your language, particularly if you're not using English, which is the default. And you want to turn on anchor indexing. Now, anchor indexing is a very unique way for the help viewer to find content within your help book. We're going to talk about it in a couple of minutes, but basically it allows you to call an individual page in help without having to know what file it appears in.

So after you've set your preferences, you take your folder full of your HTML content, and you drop it on the indexing tool. The indexing tool scans it all and writes out an index file that's used by the search engine. Now remember, it puts that index file in the place where Help Viewer is going to expect to find it, and it gives it a name. The name is derived from the folder-- the name of the folder that you dropped on it.

Help Viewer is going to look for that file by that name when it loads. So please just leave it as the index tool creates it, and performance will be better. If you do change it, your help will still work. It will just open a little bit slower than we'd like it to. Step number three, that's a short one. After you've added the Apple meta tag and you've indexed your content, then you put your content inside your applications bundle. If it's a localized resource, you want to add it in the correct Lproj directory.

Step number four, this is hooking up your Help menu. Now, this is different between Cocoa and Carbon. If you're a Cocoa application, you add two keys to your info P list. CFBundle Help Book Folder, which is the name of the help folder, the name of the folder that you dropped on the indexing tool when you did the index.

And the other key is CFBundle Help Book Name. This matches the Apple title that you put in the start page of your help way back in step one. This is how the help viewer associates the name of your book with your application and the name that you use in the APIs. It's pretty simple, just add those two tags. Next, a cosmetic point, but an important one. In Interface Builder, you want to change the item in the Help menu to match your application, instead of the generic name that Interface Builder gives you automatically.

Now, if you're a Carbon app, you do it slightly different. You also add the two keys to your info.p list that we just discussed, and then in your code, after you're initialized, call ahRegisterHelpBook, and point to the bundle that contains your help. This lets the help viewer and the help system know about your book and associate it with your application. On Carbon, this call is taken care of automatically. In Cocoa, it's taken care of automatically. Carbon, you make this call.

Now the details and some sample code about how to do this are in the Apple Help tutorial. Rather than talk you through the code, I want to refer you to there because it covers all of these steps, and it gives you some additional information on the code. And you already have that tutorial. It's installed in developer documentation on your systems. Gordon Meyer So to summarize, four steps. Create your content and add an Apple Help, an Apple title meta tag. Index your help so it can be searched. Install it in your applications bundle. And then hook up your help menu.

And believe it or not, you're done at that point. You have a full working help system. When you choose help from your applications help menu, help viewer will open, display your content, and people will be able to search it. You can maybe even go home early that day.

But I hope you won't, because there's a few things you can do to optimize your help and make it a little bit better. So let's spend a little bit of time on that. So one thing you can do to provide a really good help experience is to optimize your content for searching. As Scott Forstall mentioned in his talk on Monday, searching is really becoming a ubiquitous way of accessing information. There's a lot of search language in the interface and a lot of consistent searching experiences that counts for help.

And when users are frustrated and they're coming to help to find an answer to the question, they know what it is they're looking for, typing in a few words gets them to the answer in the most quickest way possible. But that puts the requirement on you as the help author to make sure that people can find your content by searching. There are a few things you can think about doing, one of which is to use the robots meta tag.

Robots is a standard meta tag used by lots of search engines, not just ours. You can add it to your pages and it will work if you also put your help content on the Internet for people to look at in their browser. Probably the most useful value for this is the "noindex" robots tag. "Noindex" tells the search engine to not index any content in that page, to make this page invisible for searching. So why would you want to do that? Well, a couple of key reasons. One is you probably want to make your Table of Contents page not searchable.

It has a whole lot of words on it, because it's your Table of Contents, it covers your entire helpbook, and if people search and find that, it's not particularly helpful, it just has a bunch more links and it might not be clear which one of those triggered the search result. So make your Table of Contents noindex. Another time you might want to do this is if you have a series of pages that you have people click through. Maybe you have four steps and each step is on a separate page.

When people are searching, they might come into step two on page two, or step three on page three, come in in the middle of the procedure and be lost, and not really kind of say, well, I don't understand what's going on here. So in that case, you might want to add the no index tag to pages two, three, and four, making sure that when people search, they only find page one, and they get started on the right step. There are some other values that you can provide in robots, and those are keywords and anchors.

So let's talk about those. Keywords are really important because when people come and enter search queries, they're representing the task as they see it. So you need to think about how are users going to phrase questions, what types of words are they going to type in to look for this particular help content.

This is a way you can provide that on the page in an invisible way. Keywords don't appear to the user on the page. They're not rendered by the HTML, but they're picked up by the search engine, and they're given the equal weight of the rest of the content. So keywords aren't weighted more heavily. They're just treated as if they appear on the page normally. But of course, they don't appear on the page. And one of the most common uses for this is misspelling or a synonym.

Particularly in the technology world, there's lots of technologies that real people, regular people don't really know how to spell. And even something like rendezvous can be challenging to spell for an English-speaking user. So we try and keyword for a misspelling for that. Also think about things like disk and disks, right? Hominems, users might not be thinking of that one, of what the correct form of the spelling is when they're looking for something related to that. Think about the range of users you serve, someone phrasing in a question from an expert's point of view, or from a very novice point of view. You might want to include something like silver round thingy for CDs, which is what my father-in-law calls them.

So, keywords are important things to add to your pages. You just add them in there and do it once or twice. They stay there for the entire life of your content and they're picked up by the search engine automatically. Now, earlier I mentioned an example of where you might have four pages and you've no indexed pages two, three and four, so they don't show up and only page one shows up.

Well, that's a good strategy, but you do have to think about what was on those three pages you just blocked from the search engine and are those words, do those pages contain words that users are going to want to search for because they won't find them if you've no indexed them. You want to take some of those key phrases and use them as keywords on that first page and that way people will find that first page very easily.

Another step you can do to make your help work really well in a search environment is to add page summaries. Now, page summaries are provided with the description meta tag. And again, it's a standard HTML thing. Lots of search engines use description, and so does Help Viewer. And in Help Viewer's case, the description shows up in the search results when the user clicks the result. You see a little preview of what it is you might get when you click that page. This helps users decide if they've gotten the right hit, if that's the page that appears to answer their question, if that's one they want to look at.

So these are easy to add. They do become searchable content as well, so they'll generate hits. So again, think about how users might be looking for your page, and think about an appropriate summary that might give them the answer they need without having to actually visit the entire page itself. And by combining those two approaches, you can make sure that the search results work really well.

So let's change gears a little bit and talk about how to further connect your application to the help system. We talked about how to hook up your help menu, and that's the minimum you should do. That works really well. You choose help from your applications menu, and you have the help viewer with your content. But there are other things you can do to make sure that users get the type of content they're looking for depending upon the situation they're in.

Now, there are basically three ways you can call Help Viewer directly from your app or from other places. You can use a help: URL. You can do this in any HTML anywhere. When the user clicks it, Help Viewer will launch and handle the URL that you asked for. You could use an Apple script, tell Help Viewer to do something. And of course, there are C APIs that trigger things to happen in the help.

So what kind of things can you do when you call the help? Well, you can perform a search, give it a search string, a phrase to look for, and you can specify what book to look in, whether it's your own book, somebody else's if you think it will be installed, such as Mac Help, or all of the books that the help viewer knows about. You can also open a help book. It's a very simple call, and when you do that, the help viewer opens to the page that has your Apple title tag, your start page.

Gordon Meyer And you can display a specific page in Help. So let's talk about that one. This is typically what you would want to do from a Help button, as you see in the little illustration there, a little round button with a question mark. You use this to provide contextual help. This might appear on a dialog or a preference pane, and when the user clicks it, they should see content that's specific to what it is they're looking at, content that's targeted to the condition that they're in. So you can do that by specifically calling a page.

The best way to do that in Help Viewer is to use an anchor. Now if you're an HTML author, you're used to anchors being A specific location on a specific page. Help Viewer treats them a little bit differently. To help viewer, an anchor is a thing that appears on a page in your help book. You specify them using a standard anchor syntax like you see there.

When you index your content and turn on anchor indexing, these are noted by the indexing tool, and Help Viewer resolves the locations at that time, saying, ah, anchor foo appears on page 123 HTML. Then, when your application tells the help viewer, "Hey, display the page with anchor foo," it knows it's on 123 and displays the page for you. You make this call using ahlookup anchor.

So one of the advantages of this is that you don't have to think about what page, what physical page in the file system that anchor appears on. Those people who are authoring the help can move the anchor from page to page. Even if that's you, you can put on your other hat and move the anchor from page to page without ever having to go back and change the application to point to a different file. Gordon Meyer Another advantage this gives you is that Help Viewer resolves this anchor in the correct language. So if you've localized your book and the user is running in Spanish, when you ask for this anchor, the Help Viewer will display the Spanish page that has this anchor.

Let's shift gears again and talk about remote and local content. I've mentioned that we've optimized Panther a number of ways to make this work a lot better. Users no longer have to wait for content to be downloaded from the Internet, and that's a good thing. We've moved all the downloading off into the background. So what does Help Viewer do in this regard? It's even more invisible now. Well, there's basically two things that happen.

One is that if you have provided a remote route for your help book, and again, a remote route is just an HTTP location somewhere on the Internet. If the user is connected to the Internet and they have a good network connection, then Help Viewer is going to look at your remote route, and see if there's a newer index file for your book. If there is a newer index, then it brings that index down and caches it for the user.

What this allows you to do is continue to change and refine your help content over time. You can remove pages, and to do that, you re-index your, you remove the HTML file from your help book, re-index the book, and then put that new index file out on the Internet. When users pull it down, because all searching is done through the index, that page is now essentially invisible to your users.

Gordon Meyer More likely you can add pages. If there are pages you didn't have done or you didn't think of, or you want to improve, you can put those on the internet at your remote route, re-index your help content, put the new index on the internet, help viewer will retrieve it automatically for users who can get to it, and those new pages become available to the user. They now show up in search results. Now those new pages are on the internet and they do have to be connected to view them. But when they do view them, they'll be cached and saved for the user for future reference.

So that's automatic index updating and how it works and the benefit it provides. Another level of Internet support in Help Viewer is called Internet Primary. This is different than index updating. When you turn on the Internet Primary checkbox for your book, and you do this in the indexing tool, there's a preference for it, This tells the help viewer to prefer the content you have at your remote root over the local content.

When the user requests a page, when they click on a link, help viewer will check to see if they have a good network connection, and if they do, it will check on the server to see if the page they're looking at is newer on the server, and if it is, then that page will be displayed. If they're not connected, or they don't have a good connection, then it looks in the cache to see if it has a copy that it previously got, or it defaults to the local content that is installed inside your applications bundle.

This is a really interesting feature of HelpViewer, and it's one that's quite powerful, although I found in talking to lots of developers over the last year since we've added this to HelpViewer that it kind of requires a little shift in mindset in terms of thinking about having content done and shipped with the product and then continue to maintain it over time.

But it's nice because it allows your help content to be as fresh and as up-to-date and as correct as people expect from the web, but here they're actually experiencing it directly from your application instead of having to go off on a website and visit your support site to get the latest info.

Now if you're going to do remote content, there's a couple things to keep in mind. It's really good to think about organizing your content so it's a single topic per page. Now this is really good for searching too, because remember in search results, what the user sees in the results list is the title of the page. If you have several topics on that page, that puts a lot of burden on the title of the page to kind of convey to the user what all is included there.

If you break it up, then it's easier to write a good title and so people understand what it is they're looking at and whether or not they want to view the page. Well, short pages with a single topic are good for remote content, too, because they're shorter and they download faster.

Another thing you can do is to set your cache periods. Now previously, Help Viewer would delete items from the cache after three days unless they specified a cache retention period using the cache meta tag. And the cache meta tag provides an expiration date. It's kind of like the date on a carton of milk.

It tells Help Viewer when this page is bad and should be discarded. Now caching works a little bit differently. Since caching is handled through WebKit and the other changes in the system, cached pages stick around when there's space. And if space needs to be created, then pages that specified expiration dates are removed first.

So if you want a page that you want to make sure sticks around and doesn't get deleted because space is needed, you don't have to think in terms of three days anymore. You just have to think of, I want this page to stick around, so I'm going to give it an expiration date in the future.

It's okay to do that because in an Internet primary situation, we'll still do a compare of the page to the server, and if there's a newer one, we'll still get the newer page if it exists. Otherwise, we'll use the one in the cache. There's also some other cache directives, and these are standard HTML things.

You can tell it to never cache a page, which might be appropriate on a late-breaking news page or something that you want to get out to users temporarily, but you think you're going to get rid of later. You can also tell it to keep a page nearly indefinitely by changing the cache expiration date to something very far in the future.

Finally, if you're going to use remote content, think about the graphics that you're using. You ship a large graphic that displays in Help just fine with local content but in an Internet primary situation, if you have modified that graphic on your web server, HelpViewer is going to see that it's newer and it's going to want to download it and of course, if it's a big graphic, then it will take longer to download. Just something to keep in mind in regards to Internet primary that eventually, if you maintain it on the Internet, as you've planned, you will be triggering downloads for people and you might want to think about how big those are.

So, in summary, we've made a lot of changes to Help Viewer. Most of them have been very long sought after and are very exciting. It's now much faster than it ever has been before. It uses HTML standards, which opens up a lot of new doors for content development, makes it much easier to deploy your Apple Help because you can use authoring tools that understand and create HTML that was invented after 1996, and it's smarter about Internet usage.

In addition, if you've been thinking about using Apple Help and you weren't really sure what it was all about, I hope you've seen that it provides a nice, consistent user experience, has a lot of interesting help features that are optimized for delivering content, and it's very easy to author and implement. It's essentially four steps to deployment.

Now some of the details I've glossed over a little bit, but that's because you already have them available to you and they're very straightforward. You have documentation installed in your system under Developer Documentation. You should also visit the Apple Help website, which is at ADC, under User Experience. There's a lot of references there, some additional documentation, and some pointers.

And if you do have questions and comments, here's how you can get a hold of the Apple Help Engineering team. Apple Help comments at group.apple.com. It's a group mailing address, and so we all read it. We can't promise a reply, but I do promise that we read them all and take them seriously. And you can visit the Help Authoring Mailing List. This is a public list. It's very low traffic. Go to list.apple.com and sign up for it. There are a lot of Apple Help authors on there who have tried various things and know lots of ways to deliver help.

Post a question, and you'll probably get an answer. If you don't post anything, you may think the list isn't working because there's not a lot of traffic on it, but generally people who use it get what they need. And several members of the engineering team monitor that list. John Galenzi, who is off busily preparing for the spectacular Apple Design Awards, which take place this evening, is our contact person. Information about your needs in Apple Help and future directions that you'd like to see should be emailed to him.