Follow-Up to Yesterday's Post About AIR
If you read yesterday's post when it went up, be sure to go back and look at the comments section. Two very useful comments from consultant Peter Grainge and AIR Product Manager Rob Christensen.
Saturday, June 21, 2008
Friday, June 20, 2008
Adobe AIR
Since Adobe introduced AIR, there’s been a lot of discussion about what it is and why to use it. I’ve also been asked how it applies to RoboHelp specifically. The Adobe web site describes AIR, but I think the discussion is aimed a bit too much at developers and not enough at RoboHelp authors, so here’s my short initial take on what AIR is in general and for RoboHelp specifically.
In general…
AIR, Adobe Integrated Runtime, is an output format with characteristics of both web-based and desktop applications. It’s web-aware but doesn’t run in a browser. Instead, it runs like a desktop application, which lets it take advantage of desktop features like local file storage. Yet because it’s web-aware, it can search the web for updates if users have an internet connection and update itself as needed. Adobe has stated that it plans to implement AIR across its product line, essentially creating a new output format.
For RoboHelp…
The Microsoft HTML Help output format (CHM) is an old (pre-‘97) and increasingly constrained format that looks increasingly antiquated in an increasingly webby world. It will be around for a long time, just as WinHelp has been around since it was unofficially put to sleep in ‘97, but I consider it a dying format.
However, HTML Help has one great attribute – it’s compiled. No matter whether a project contains one topic or a thousand, they’ll all be encapsulated into one distributable CHM file. IT managers like this because they only have to distribute one file. That one-file model is increasingly out of place in a web-oriented world, but its simplicity is a virtue.
In contrast, WebHelp, created by eHelp (original vendor of RoboHelp) in ‘97/’98, is not compiled. If a project contains a thousand topics, you have to distribute one thousand files – slightly more counting the control files. (This sounds difficult but it’s easy since RoboHelp puts all the files in one WebHelp folder. You just distribute that folder.) This makes WebHelp more efficient for web-based distribution because it acts like a web site. If users call for one topic, they get that one topic rather than all one thousand as they would with the CHM. However, IT managers often don’t like having to upload those thousand-plus files to a server.
The RoboHelp Packager for Adobe AIR tries to get the best of both formats. (To download beta 2, see http://labs.adobe.com/technologies/robohelp/.)
Like HTML Help, the Packager encapsulates all the distributable files in one AIR file. This means IT only has to deal with one file rather than hundreds or thousands as it does with WebHelp. (Even though those files are contained in a single WebHelp folder, they still have to be distributed.) For many IT managers, that’s a big benefit by itself.
Once you output to AIR, you get several other options as well.
You can apply skins, a la WebHelp. However, the skins are more flexible. For example, you can add a Resources button on the toolbar with links to other web pages. If you select one of those links, the target page opens in the AIR window in its own tab. This lets users keep the help file and other web pages open at the same time and access them quickly by just selecting the desired tab.
The output should look consistent on different platforms and operating systems. (I’d want to see a greater base of experience about this before accepting the idea wholeheartedly since different platforms and operating systems often have odd twists. However, since the output is not running in a browser, the browser display differences that we often see shouldn’t be an issue.
You can give users the ability to comment on the output, lending a Web 2.0 air to RoboHelp for the first time.
What do we have to do to make AIR work on users’ PCs? According to the AIR help, users must have the Adobe AIR runtime environment installed on their PCs. This seems like a straightforward download and installation. However, compared to the simple Flash Viewer installation procedure that many users are accustomed to, the AIR runtime installation is going to look more difficult and may slow acceptance of AIR until the runtime installation gets simpler.
I’ll add more as the RoboHelp Packager for Adobe AIR firms up.
Since Adobe introduced AIR, there’s been a lot of discussion about what it is and why to use it. I’ve also been asked how it applies to RoboHelp specifically. The Adobe web site describes AIR, but I think the discussion is aimed a bit too much at developers and not enough at RoboHelp authors, so here’s my short initial take on what AIR is in general and for RoboHelp specifically.
In general…
AIR, Adobe Integrated Runtime, is an output format with characteristics of both web-based and desktop applications. It’s web-aware but doesn’t run in a browser. Instead, it runs like a desktop application, which lets it take advantage of desktop features like local file storage. Yet because it’s web-aware, it can search the web for updates if users have an internet connection and update itself as needed. Adobe has stated that it plans to implement AIR across its product line, essentially creating a new output format.
For RoboHelp…
The Microsoft HTML Help output format (CHM) is an old (pre-‘97) and increasingly constrained format that looks increasingly antiquated in an increasingly webby world. It will be around for a long time, just as WinHelp has been around since it was unofficially put to sleep in ‘97, but I consider it a dying format.
However, HTML Help has one great attribute – it’s compiled. No matter whether a project contains one topic or a thousand, they’ll all be encapsulated into one distributable CHM file. IT managers like this because they only have to distribute one file. That one-file model is increasingly out of place in a web-oriented world, but its simplicity is a virtue.
In contrast, WebHelp, created by eHelp (original vendor of RoboHelp) in ‘97/’98, is not compiled. If a project contains a thousand topics, you have to distribute one thousand files – slightly more counting the control files. (This sounds difficult but it’s easy since RoboHelp puts all the files in one WebHelp folder. You just distribute that folder.) This makes WebHelp more efficient for web-based distribution because it acts like a web site. If users call for one topic, they get that one topic rather than all one thousand as they would with the CHM. However, IT managers often don’t like having to upload those thousand-plus files to a server.
The RoboHelp Packager for Adobe AIR tries to get the best of both formats. (To download beta 2, see http://labs.adobe.com/technologies/robohelp/.)
Like HTML Help, the Packager encapsulates all the distributable files in one AIR file. This means IT only has to deal with one file rather than hundreds or thousands as it does with WebHelp. (Even though those files are contained in a single WebHelp folder, they still have to be distributed.) For many IT managers, that’s a big benefit by itself.
Once you output to AIR, you get several other options as well.
You can apply skins, a la WebHelp. However, the skins are more flexible. For example, you can add a Resources button on the toolbar with links to other web pages. If you select one of those links, the target page opens in the AIR window in its own tab. This lets users keep the help file and other web pages open at the same time and access them quickly by just selecting the desired tab.
The output should look consistent on different platforms and operating systems. (I’d want to see a greater base of experience about this before accepting the idea wholeheartedly since different platforms and operating systems often have odd twists. However, since the output is not running in a browser, the browser display differences that we often see shouldn’t be an issue.
You can give users the ability to comment on the output, lending a Web 2.0 air to RoboHelp for the first time.
What do we have to do to make AIR work on users’ PCs? According to the AIR help, users must have the Adobe AIR runtime environment installed on their PCs. This seems like a straightforward download and installation. However, compared to the simple Flash Viewer installation procedure that many users are accustomed to, the AIR runtime installation is going to look more difficult and may slow acceptance of AIR until the runtime installation gets simpler.
I’ll add more as the RoboHelp Packager for Adobe AIR firms up.
Subscribe to:
Posts (Atom)