I'll jump in Peter - our company looked at AIR Help briefly because it was one of the few help outputs that didn't look dated. However, we decided to go the WebHelp route (for now) on our clients' servers because of the hassle of having to install AIR on each terminal. I also thought initially that AIR required a security certificate to create/install & that we weren't prepared to invest money in getting that (I've been disabused of this notion through other forum posts). I've never heard of browser-based AIR so I'll have to revisit AIR Help as an option for us in the future.
At my company we're moving towards Web help only as we most run our software product off servers and also it's a well proven format. Although it can mean large numbers of files if this is installed to a folder I have no issue with that.
I don't favour CHM format mainly becuase of the issue about it only working locally but also it's given us more problems than web help. I know that elsewhere in the company Air help is used but I'm not sure why.
In general I need help formats that are simple, reliable and robust. Also they need to be able to withstand updates from microsoft going on in the background all the time. I've found RoboHELP 8 to be particulary poor in this respect of late usually around the time of a release!
Thanks for starting this interesting thread Peter.
We have traditionally been a CHM site with the vast majority of our help output being in this format. What isn’t in this format is in hardcopy (Word/PDF) format. However that is all changing, albeit gradually because of the amount of legacy projects we have to maintain.
We have just completed a year-long project to rewrite one of our major product suites. This implemented the first phase of our documentation model which includes outputting to the RoboHelp Server application (therefore using WebHelp Pro output) but also a locally installed CHMS as a backup – our user base are often moving around locations so are prone to having weak or no internet signals. Phase two will involve the replacement of the CHMs with another solution.
Prior to AirHelp, there would probably be no phase two. We’d have accepted the status quo. Now we are looking seriously at locally installed AirHelp and all it can offer. Our initial impressions are positive and that it will indeed replace our CHMs. It’s still early days for us but it’s ability to look modern, fresh and clean straight out of a RoboHelp project is a big reason for wanting to use it, as is the level of customization over CHMs. To us it has many of the advantages of both WebHelp and CHM output.
We have two main product suites, each comprising of approximately 12 merged projects. We have one other merged project of two projects and a half dozen more stand alone projects. All will eventually deploy WebHelp Pro on the RoboHelp Server and (unless the pilot goes belly up) AirHelp installed locally. Busy times ahead ;-)
Good idea to start this thread now that AIRHelp is staring to develop some traction. Thanks
For the last 6 momths I have been on contract to McKesson (#12 Fortune 100, largest Phama dist in US). My team supports the technical side of McKesson's eCommerce business. They must deal with a number of systems and devices in a very dynamic, fast changing environment.
I started using RH to update the customer facing webhlp files for several of the systems related to McKesson's ordering system. The original work was in-house developed HTML help so moving to RH 8 was a big step forward here. I have no history with chm so I will leave that area to those who are expert there.
In a meeting called by My manager whiich included several other departments, we discussed developing collaborative, community based help systems. Our VP for E-Commerce Marketing expressed a wish for "a wiki like help system that would provide feedback to management". I replied that with the new Adobe AIR help output format, we could do just that. This occured in early October while I was still working on the primary systems conversion. Less than 2 months later in early Dec. we rolled out the Knowledge Base project in AIRHelp format.
The response has been simply super. We have processed well over 100 comments, added topics from 4 other modules and reviised the system over 30 times as of this date!
AIRHelp filles a very important gap in help systems. When users need current information that may change at any time AND they are supporting end users where time is critical, AIRHelp is a very robust solution. The full text search clearly saves time when the application is on the desktop. A few secs here and there may not seem like much, but with customer's on hold waiting for help, any time shaved is a big plus.
External users will likely remain on Webhelp for the forseable future, but other departments are looking at AIRHelp to support systems and knowledgebases. The real beauty of RH AIR is apparent when community feedback is important in "fine tuning" the systems. My team is very engaged with the new capabilities at their fingertips. My manager is smiling a lot lately as well!
Recently, we began to add some Captivate Sims to the RH-AIR output. the pic I am uploading is if the KBase opened to a new sim topic. I developed this sim for some other training delivered with the sim in a .pdf. I was really easy to load the sim into RH for the AIRHelp output
KBASE-KWSearch.png 38.0 K
We deliver WebHelp from our company website and have convinced upper management to allow us to include an AIR file as well, just as an option for customers to try and provide feedback. We're hoping it takes off as we do like the single file delivery, auto-update, live link to the Web, and (for real this time) true cross-platform support where we no longer have to try and make WebHelp appear/work the same in several different browsers. A major drawback is the lack of customization. A simple color picker in the AIR Output dialog box for changing the color of the skins, at the very least, should have been part of the RH8 package.
We have also looked at AIR Help. The benefits of feedback, comments and an automatic prompt to update looked great. However, the fact that when you print out a topic the print-quality is lousy and that you have next to no control over the look of the application ruled it out for us for the moment. We're continuing to use CHMs for Windows desktop applications and webhelp for server-based applications for now - a pity.
Thanks, Peter for generating this thread. For RoboHelpers going to the WritersUA in Seattle March 21-24, you will want to drop by the Peer Showcase to see Becky Williams' demonstration of RoboHelp's AIR Help that she uses with a .NET Web Application for Harris Corporation.
AIR Help is still new and its deployment will surely grow as authors discover it as a solution.
Adobe Certified RoboHelp and Captivate Instructor
Peter, I'm glad you started this thread.
At my company we have started by using locally installed AIR help versions of a couple of documents, and distributing them only internally. I think this is an important step so that we can get routines in place for handling updates, managing user comments, etc., before going big.
We have also implemented browser-based AIR help in a new release of a web-based product that previously used WebHelp. We did this primarily because of the updated look, the better Favorites functionality, the tabbed browsing (ability to open two or more help topics simultaneously), and above all as a "test" in implementing and working with AIR Help before jumping in with both feet.
Most of our products (but not the ones we have started using AIR help for) are translated into around 5-6 languages, so reuse is very important to us. I'm very concerned about how to translate AIR Help. Recently we've been using Sisulizer, which can be used to compare two English CHMs (for example) and pick out the new & updated strings before a new release, so that only additions and changes need be translated. (We had massive problems with this after upgrading from RH7 to RH8.) Now I'm not sure how we'll go about translating after switching to AIR. You can get HTM files out of AIR and probably even use that tool to compare them, but I'm not sure how to get them back into AIR. Also I'm unsure whether the HTM files we get out of AIR will be comparable in format to the HTM we got out of decompiled CHM, or how the TOC and index will look. I plan on testing this in the near future, but at the moment I don't see how this could be accomplished. Doing an all-new translations because of a switch to AIR Help would be prohibitively expensive.
Right now I would answer your questions like this:
- Yes, I see locally installed AIR help as the successor to CHMs. However, I think we need some updates before this can become a widespread reality. Some of the functionality is buggy, we have to make translation manageable, we need tools for managing user comments, and the search functionality is IMO quirky at best (which is really a shame since users are now searching rather than using indexes or contents).
- While there are advantages to browser-based AIR help over CHM, IMO AIR's biggest perk by far is the commenting feature. Without the commenting feature (which as you know isn't available in the browser-based AIR help), to me it's not worth the trouble. The commenting feature will get us close to users. We can take advantage of people's new Internet habits and interact with them, to our mutual benefit.
- (Can't answer third bullet.)
- We will use it for application help, at least initially.
- Although we are using AIR, I can state my primary concerns again: translation issues and comment management issues (particularly if we are getting comments in eight different languages). I'm also unhappy with the search functionality, but I don't see this is a show-stopper.
Thanks again for this thread. It is interesting reading others' comments, as well.
Just adding to my earlier post, there has been a bit of discussion on this in the wider Technical Authoring community. Yes there really are people out there who don't use RoboHelp ;-) Obviously Adobe are attempting to style the march over its rivals with AirHelp but it should be recognised that there will be plenty of tech authors who will be unwilling/unable to even consider using AirHelp.
Another consideration is that AIR is a proprietary Adobe format, while HTML is free. Some of us have been burned in the past by proprietary formats. On the other hand, PDF was (and is) an Adobe format but it is widely accepted.
Will Adobe permit third-party tools to create/edit AIR files?
Just my $0.02,
We use WebHelp where I work.
Previously there was nothing in place to manage documentation so management etc had no idea where to go or how to distribute it, everything was online PDFs over 100 pages....not exactly usable.
I presented a case by case basis for various products, and various output formats.
We we're, and I was very interested in using AIR as our platform for delivery but there were simply to many drawbacks. The biggest being installation rights of users, because it requires users with admin rights it is not very easy to implement. Many of our users will not have permissions to install applications in anyway, this includes having to install flash if they do not have it already. forcing this on the IT depts of our clients was seen as a big drawback, especially when they will have to do it everytime a product update is released - which is about every 6-8 weeks!
Because we operate a secure web based application with over 70,000 visitors a day, it seemed only natural to host our help file online as well making it easily accessible.
We haven't made the plunge inot RH Server yet as we are still in the baby steps of implementing and distributing our help system, and of course the $$.
I have however insisted that AIR be used internally, I've had it setup as our review tool, allowing SMEs etc to review my work before it is published online. This has made it quite a valuable tool, allowing for quick comments and updates often leading to discussions around particular topics and information which is always useful.
There have been comments about customisation of AIR, and it is a fair point, even with the browser based air help, you are very limtied by what can be cahnged. With many of our clients wanting custom skinned help files it is a huge draw backto using it.
CHMs were ignored entirely, as if we we're to distribute stand alone help we would have chosen AIR as it simplty offers more functionality and is a lot nicer on the eyes.
This is a great initiative. I started using it (of course for unofficial purposes) of AIR first time on DreamWeaver and then of late with both RoboHelp X5 and 8 versions.
I find it great. But there is plenty of room for growth and desirable features to be added.
It doesn't works well with merged projects (with my little experience). May be some one had tested it and it works for them. Eager to know that too.
Our organization at present issues a .exe tool for customers to install multiple PDFs, webhelp outputs, and other docs such as excel, word, etc. all put together on a single landing .htm page. The exe extracts all these files under a single location and the customers gets all his docs and help at one location. All s/he has to do is to click open the .htm and click access the links to various docs and files, which are already extracted to a local folder.
Found AIR could be used instead of going through this entire process of generating a .exe. So that even Tech Writer's can start using this tool.
There are couple of issues with AIR output during the process of imitiating the same .exe appearance. It is not pulling multiple webhelp output, yet. At least in my case.
Otherwise, it is a great tool, but still a long way to go with more added features and functionalities.
I haven't looked at AIR since last February, when I ran the Packager against a 42-project merged WebHelp, and it appears that not much has been done with the product since then.
The results were OK, but not complete. As already mentioned here, the customization is lacking. For example, I lost all my user-defined toolbar buttons (including my custom Search button for the Zoom search files).
- We need full toolbar and TOC customization through a skin UI (which is also lacking in the RH product).
- We need to understand in what conditions the user comments can be put to use; that is, we provide our WebHelp to run on our product's middle tier server, thereby making it available to all users through their site's intranet. How can user comments be gathered and exported to us?
- Since the SSL and AIR file version concepts are fairly complex, much discussion (with examples) should precede any procedural topics for generating the AIR output.
- More discussion is needed about the differences between the use of the Packager and the RH AIR layout. That is, if we generated and published all 42 projects into a merged system exactly as we currently do with merged WebHelp, how will that be different from running the Packager against the merged WebHelp output? And can that even be done?
Thank you so much to everyone who has responded to my post.
We too have stayed with WebHelp for our main applications for precisely the same reasons
- The hassle of installing on individual PCs
- The lack of commenting with browser AIR Help
At the moment we are working on local AIR Help for an application that is installed locally.
As above, we have taken the same view generally.
I haven't found any issues with Microsoft updates affecting RoboHelp 8 but if you have any outstanding, then no doubt you will raise them in a new thread.
Sounds like browser AIR Help would interest you too.
In your second thread you mention AIR Help being limited to RoboHelp. I haven't seen the Flare offering but it is one of their layouts, or targets as they call them.
It's taken until now to work out that is Ed something something who has a PHD! Duh!
Sounds like comment moderation would really help you and that auto updating is a great feature for you.
Where you say external users will likely remain with Webhelp it sounds like that's because browser AIR Help lacks the commenting. Whilst the additional features it has are nice, they are just not compelling enough but commenting would clinch it.
I can but agree the ability to customise is needed.
"Print quality is lousy" - yes that does need to be addressed.
See above re control of the appearance.
Oh how I wish I could be at Writers UA to see the Peer Showcase!!
Good to see someone using browser AIR Help
Translation is not my scene but are the issues any different than with other outputs? It might be interesting to start a separate thread on that.
Bugs - I know you know how to report them.
I agree commenting is a key reason and needs to be in browser AIR Help as well.
As above, MadCap Flare is producing AIR Help so the answer has to be that Adobe do permit third party tools to produce AIR files.
Yes installation on sites with a large user base is a real issue and that is why I would like browser AIR Help to match the functionality of the local version.
So effectively you are using it to create a knowledge base. Nice.
See www.grainge.org for RoboHelp and Authoring tips
All of our customers are sticking with either Webhelp or the CHM (and a few use Javahelp). Air Help has not been seen as an alternative yet, due to various reasons many of which have been already pointed out. Also do not forget the branding aspect. After installing software X from company Y, the end user is prompted to accept the terms of usage of Adobe Air just to view the documentation. What happens if the end user does not or cannot comply? Also I have seen some technical issues.
I think Adobe is missing a great opportunity not to invest further developement into the WebHelp system. A new API could allow for integration directly into the user interface. Also the growing share of browser-based client applications is an ideal market for Webhelp. The already broad implementation would justify to focus efforts on improving usability rather than divert to yet another platform.
Just to give an example, in one of our projects we integrated the WebHelp into a browser-based UI. Above each dialog the short description of the linked topic is displayed together with a "?" button that opens up the corresponding help topic if clicked. A simple-to-use control that can be integrated into web sites which provides this or related functions would be a great improvement.
Concerning the benefits of Air Help, I would like to add that most users I talked to thought that the online updating function was a main opportunity.
Following on from my other recent posts, I now need to add my 2p to this discussion.
(BTW many thanks for initiating this).
My situation is thus:
Up to now (decision made before my time) we have been deploying browser based help (Webhelp) installed locally with application software.
We have both PC and Mac users, so presumably this decision was taken for the cross platform audience.
When Chrome came along, we noticed that Webhelp failed in Chrome due to the "no scripting by default" situation.
Initially we just declared that our help was not compatible with Chrome. However now that Chrome has become so popular, this clearly is not good enough.
So time to change format.
I initially wanted to go with compiled AIR (for cross platform compatibility).
But then I started to think browser AIR would be better due to the need to install so much stuff to run compiled AIR
There are technical considerations here (eg size of deployment + what if a user does not have admin rights to be able to install things?).
However, it now appears that browser AIR is not going to work for us since it has to be deployed to a server.
Also I was having other issues with browser AIR (text search not working + TOC tooltips not displaying correctly), so now I'm going to liaise with our developers re using compiled AIR.
So unless there is another option that I have overlooked so far, it looks like I'm back on the compiled AIR path.
Any considered wisdomm on this would be hugely appreciated.
Cheers + thanks in advance,
Mind you, I think WebHelp needs a severe looking at as well :-)
I take it the H&M2GO solution with webhelp is not an option for your Mac users.
I don't recall the detail of your issues but cross topic links work and the two links below should work. One going to the default topic and one opening the help with a specific topic.
I'm guessing that your app had to call CSH in some other way.
See www.grainge.org for RoboHelp and Authoring tips
>> H&M2GO solution
Ok, you've got me there. What's that?
Is this some fancy new feature in RH9 by any chance? (currently using RH8 - apologies for not mentioning that in my previous post).
He's referring to one of the 2 ways to get around the Chrome/WebHelp issue - either configure the Chrome launching shortcut to enable a local file access mode on the target command line; or install a (free) "fake" webserver provided by Help & Manual to trick Chrome into thinking it's launching the help on a webserver.
Thank you Jeff. Plenty of scope to try a few things there. I shall endeavour to get back into the sandbox with a friendly techie and report back.
In your thread at http://forums.adobe.com/thread/1018293 I referred you to Items 2 and 3 at http://www.grainge.org/pages/snippets/snippets.htm#browsers
The H&M2GO solution is explained there but I don't know if it will work on a Mac.
See www.grainge.org for RoboHelp and Authoring tips
Many thanks again. I've got both methods to work - excellent.
One thing I still don't understand. From your snippet on this:
"(You do not need to install HM2GO on user PCs)"
I'm not clear about what one has to deploy therefore in order to ensure local Webhelp works on user PCs.