Hello,
We are contemplating a move from ePublisher to Flare.
Note: For some time we would continue to author in FM and use Flare to generate online help.
Please could you share your experiences about the following:
1) the leaning curve involved.
2) advantages/disadvantages of ePublisher/Flare.
3) how easy/difficult is it to design templates in Flare.
4) is the FM to Flare import truely seamless as it is claimed.
5) how easy/difficult is it to implement context sensitive help.
6) does Flare work with Perforce (source control tool).
7) any peculiar problem areas.
Thanks in advance.
Kind Regards,
Prashant
Planning to migrate from ePublisher to Flare
Re: Planning to migrate from ePublisher to Flare
I started using Flare almost a year ago, and have mostly abandoned it and gone back to WebWorks. The main reason was that WebWorks Help would not work on our production web servers due to the way they are configured - something we didn't find out until we completed our first project in Flare. Based on my experience:
1. The learning curve is pretty steep if you haven't used a real help authoring tool before. Flare's interface is also very complicated (much too complicated, I think). Get a copy of Five Steps to MadCap Flare or register for one of their training courses. You'll need it. You also better be very comfortable with CSS. Don't even think about using Flare unless you or somebody on your team is competent in CSS.
2. Flare is much better than Frame/WWeP if you want to reuse information. Otherwise, I found WWeP much easier to work with. But I've been using it for years.
3. Template design in Flare is pretty easy, as long as you know CSS. Some things (PDF output) have frustraing limitations that are hard to work around. If you need PDFs with complex formatting as well as online formats, stick with Frame/WWeP.
4. Frame import is not seamless. It took us a long time and several tries to get it right. It will also depend on how clean your files are - having good templates and rigorously following them will cut down on the work.
I can't comment on 5 and 6.
As for problem areas, PDF output would be one. The interface is too complex.
OTOH, there are features I would kill to have with FrameMaker (Analyser, for example).
I may yet go back to it, but if I do it'll be on a project that I can start from scratch instead of having to import content.
--Keith
1. The learning curve is pretty steep if you haven't used a real help authoring tool before. Flare's interface is also very complicated (much too complicated, I think). Get a copy of Five Steps to MadCap Flare or register for one of their training courses. You'll need it. You also better be very comfortable with CSS. Don't even think about using Flare unless you or somebody on your team is competent in CSS.
2. Flare is much better than Frame/WWeP if you want to reuse information. Otherwise, I found WWeP much easier to work with. But I've been using it for years.
3. Template design in Flare is pretty easy, as long as you know CSS. Some things (PDF output) have frustraing limitations that are hard to work around. If you need PDFs with complex formatting as well as online formats, stick with Frame/WWeP.
4. Frame import is not seamless. It took us a long time and several tries to get it right. It will also depend on how clean your files are - having good templates and rigorously following them will cut down on the work.
I can't comment on 5 and 6.
As for problem areas, PDF output would be one. The interface is too complex.
OTOH, there are features I would kill to have with FrameMaker (Analyser, for example).
I may yet go back to it, but if I do it'll be on a project that I can start from scratch instead of having to import content.
--Keith
-
lacastle
- Propellus Maximus
- Posts: 1028
- Joined: Thu Apr 12, 2007 7:28 am
- Location: Wilmington, DE
- Contact:
Re: Planning to migrate from ePublisher to Flare
1) there is definitely a learning curve for Flare, but it is less if you know xhtml and css.
2) i don't know epublisher
3) what do you mean by "templates?" sample topics that you use to create new ones? maybe you mean skins and stylesheets. if so, they both take time to get right and lots of trial and error.
4) the FM to Flare import is acceptable if you have an import file set up that connects your FM styles to your Flare styles. there was a webinar about this last week that you could listen to - http://www.madcapsoftware.com/demos/pla ... a&f=gtm588 . i'm not an expert FM users, so this didn't work for me, but i figured out a way to get all my FM files into Flare (but i will not be authoring in FM anymore) - http://forums.madcapsoftware.com/viewto ... 598#p66197
5) i don't know csh, but it's all over the forums if you search for that
6) i don't know perforce, but i think it's been mentioned in the forums
7) problem areas in flare? the learning curve if you don't know xhtml and css is a problem for basic users if they want to make any modifications. if you set up a great project with everything defined and working, then adding content is the easy part. another problem would be expecting flare to do everything that epublisher and FM do. you may be able to get the same results, but the way to get there is most likely going to be very different.
2) i don't know epublisher
3) what do you mean by "templates?" sample topics that you use to create new ones? maybe you mean skins and stylesheets. if so, they both take time to get right and lots of trial and error.
4) the FM to Flare import is acceptable if you have an import file set up that connects your FM styles to your Flare styles. there was a webinar about this last week that you could listen to - http://www.madcapsoftware.com/demos/pla ... a&f=gtm588 . i'm not an expert FM users, so this didn't work for me, but i figured out a way to get all my FM files into Flare (but i will not be authoring in FM anymore) - http://forums.madcapsoftware.com/viewto ... 598#p66197
5) i don't know csh, but it's all over the forums if you search for that
6) i don't know perforce, but i think it's been mentioned in the forums
7) problem areas in flare? the learning curve if you don't know xhtml and css is a problem for basic users if they want to make any modifications. if you set up a great project with everything defined and working, then adding content is the easy part. another problem would be expecting flare to do everything that epublisher and FM do. you may be able to get the same results, but the way to get there is most likely going to be very different.
Laura A. Castle
http://www.lauracastle.com
http://www.lauracastle.com
-
wclass
- Propellus Maximus
- Posts: 1238
- Joined: Mon Feb 27, 2006 5:56 am
- Location: Melbourne, Australia
Re: Planning to migrate from ePublisher to Flare
5) Implementing context sensitive help is straight forward, but if you're new to CSH then you will have to do a lot of reading. The interface lets you import window/map ids from an application, or you can generate the IDs and map your topics from Flare. It provides help on calling topics using the map ids, or you can bypass that and make calls directly using the URL and topic name. We have CSH working with HTML Help (CHMs), with webhelp attached to web applications, and for standalone webhelp that is used as a knowledge base.
And I agree with the other comments - you need to know CSS.
We've struck problems getting good quality print output, but as we mostly want online output Flare is the best tool for us. I use/import Word rather than FM - I get the impression that has a similar number of problems.
And I agree with the other comments - you need to know CSS.
We've struck problems getting good quality print output, but as we mostly want online output Flare is the best tool for us. I use/import Word rather than FM - I get the impression that has a similar number of problems.
Margaret Hassall - Melbourne
-
GregStenhouse
- Sr. Propeller Head
- Posts: 330
- Joined: Tue May 13, 2008 3:27 pm
- Location: Christchurch, New Zealand
Re: Planning to migrate from ePublisher to Flare
1. There is a learning curve, but if you have one expert who sets it all up, others in the team can follow a set number of steps and import or produce output fairly easily. And the support materials, free webinars, and paid training via madskills are very very good.
2. I haven't used ePublisher, but used to use WebWorks Publisher (v6). Comparing those two tools I would suggest they are much the same, they just do some things differently (e.g. TOCs, conditions etc). Mapping styles is much the same though.
3. Templates are easy to create, you pick a project you like and save the project as a template. Of course getting that project to a suitable stage can involve a fair bit of tweaking to things like "skins", master pages, stylesheets, and target settings.
4. Not exactly seamless, but generally there is a workaround to most problems you come across. As long as your frame files are clean (no paragraph or character overrides).
5. When importing from FrameMaker, Flare wants to add its own value to TopicAlias markers (1000, 1001 etc). There is no easy way to define your own numeric value in Frame and have that imported.
6. You may have trouble with 'binding' to perforce, but you can always manage source control outside of Flare if necessary.
7. Images don't look the best if Flare generates them (e.g. you use callouts in anchored frames). If this is important, best to stick with a single gif/jpg/png in an anchored frame so Flare doesn't regenerate them. If you use conditional text, sometimes that causes a bit of a mess in your Flare topics, and in worst case scenarios, the condition applied in Frame is not applied in Flare. Tables can be tricky to format, as the import process adds a lot of local formatting. Use the Reimport button to reimport from Framemaker (not the auto-generate when building option, as this causes topic duplicates).
HTH
Cheers
Greg
2. I haven't used ePublisher, but used to use WebWorks Publisher (v6). Comparing those two tools I would suggest they are much the same, they just do some things differently (e.g. TOCs, conditions etc). Mapping styles is much the same though.
3. Templates are easy to create, you pick a project you like and save the project as a template. Of course getting that project to a suitable stage can involve a fair bit of tweaking to things like "skins", master pages, stylesheets, and target settings.
4. Not exactly seamless, but generally there is a workaround to most problems you come across. As long as your frame files are clean (no paragraph or character overrides).
5. When importing from FrameMaker, Flare wants to add its own value to TopicAlias markers (1000, 1001 etc). There is no easy way to define your own numeric value in Frame and have that imported.
6. You may have trouble with 'binding' to perforce, but you can always manage source control outside of Flare if necessary.
7. Images don't look the best if Flare generates them (e.g. you use callouts in anchored frames). If this is important, best to stick with a single gif/jpg/png in an anchored frame so Flare doesn't regenerate them. If you use conditional text, sometimes that causes a bit of a mess in your Flare topics, and in worst case scenarios, the condition applied in Frame is not applied in Flare. Tables can be tricky to format, as the import process adds a lot of local formatting. Use the Reimport button to reimport from Framemaker (not the auto-generate when building option, as this causes topic duplicates).
HTH
Cheers
Greg
Re: Planning to migrate from ePublisher to Flare
We use a combination of both ePublisher and Flare with FrameMaker. Flare is used on projects that Open Toolkit choked on. The folks at Webworks looked at the issue in depth and pretty much determined that they would have to rewrite a part of the OT dealing with tables that simply was very inefficient.
Here is my take on the two processes.
I'm not sure I would say thing are "seamless", but with proper setup, they can work very well together with minimal issues.
The real advantage (also a disadvantage) is that information developers can edit within Flare. Obviously in Webworks, you can't do that. But that's also a weakness depending on your workflow. The whole idea of Webworks is that your content is firm, and you are simply publishing your content. You can use Flare like this (I do in some situations where I have scripts producing my DITA content), but you do have to have a person pushing buttons in Flare, where in Webworks you can have the publishing end automated.
Both tools have their strengths and weakness and I find that both developer's are pretty responsive to issues, although Webworks gets a huge leg up on fixing issues quicker (I still haven't seen a single one of my verified bugs fixed in any of the Flare updates v5 or v6).
Wayne
Here is my take on the two processes.
- Both tools have a learning curve. There is no way around this.
- Both use css, so you should be able to bring most of your css over without any problems. You will have to redesign the output template (PDF), but you can use a lot of the settings you have in your current stationary to achieve that fairly easily.
I'm not sure I would say thing are "seamless", but with proper setup, they can work very well together with minimal issues.
The real advantage (also a disadvantage) is that information developers can edit within Flare. Obviously in Webworks, you can't do that. But that's also a weakness depending on your workflow. The whole idea of Webworks is that your content is firm, and you are simply publishing your content. You can use Flare like this (I do in some situations where I have scripts producing my DITA content), but you do have to have a person pushing buttons in Flare, where in Webworks you can have the publishing end automated.
Both tools have their strengths and weakness and I find that both developer's are pretty responsive to issues, although Webworks gets a huge leg up on fixing issues quicker (I still haven't seen a single one of my verified bugs fixed in any of the Flare updates v5 or v6).
Wayne
Re: Planning to migrate from ePublisher to Flare
Hello,
Thank you all for responding and sharing your experiences.
I truly appreciate it.
Your inputs are indeed valuable.
Kind Regards,
Prashant
Thank you all for responding and sharing your experiences.
I truly appreciate it.
Your inputs are indeed valuable.
Kind Regards,
Prashant