Whose help is this anyway?

mikejp · Post by **mikejp** » Tue Nov 28, 2006 2:32 am

I really hope I'm going to embarrass myself here, but here's something that irritates the hell out of me and - if it can't be fixed - may stop DotNet Help in its tracks for us. It's pretty simple: Why the heck is there no obvious way to replace the Viewer window title with the name of my help system, and a way to replace the (or suppress) large \"wait for it\" MadCap logo that appears when the viewer is called?

Yes, MadCap has a great logo but it's also much, much bigger than any of our own.

It seems to me that the Viewer was designed to be analogous to Adobe Reader (hence no CSH in V1?), rather than be a useful and invisible way to get a help system on screen, or be a stepping stone into integrated help. Truth is, if the viewer doesn't cut it, our developers won't go for the embedded API next time around.

I can tell at a glance which tools were used to build a deliverable, so MadCap doesn't need to do this. Everyone else who has seen the viewer is at best dubious, at worst horrified, so these embedded items simply get in the way of adoption.

I believe MadCap has a real philosophical problem here.

I also don't understand why it's taking so long to release a multilingual version of the Viewer. Is this desire for control getting in the way of getting the job done?

Richard Ferrell · Post by **Richard Ferrell** » Tue Nov 28, 2006 7:12 am

I will submit a request to have the ability to turn off the Logo Screen on startup

mikejp · Post by **mikejp** » Tue Nov 28, 2006 7:27 am

Thanks Richard. Do we have any indication of when the next release will be, and what the priorities are? Even something like \"No way before...\" would be helpful...

Post by **RamonS** » Tue Nov 28, 2006 8:19 am

I also recommend to add a \"replace\" function so that one can show a custom logo. I personally opt for increasing startup time and make the \"we need to show something otherwise everyone thinks the app crashed\" issue a moot point.

mikejp · Post by **mikejp** » Mon Dec 04, 2006 4:21 am

Just to emphasise the message:

Our users are serious, paranoid (paid to be) and ever-so-slightly anal (in the sense you'd want them to be). So when a reviewer tells me that seeing that dratted MadCap logo had him wondering about malware I have to take that very seriously.

We're perfectly happy with it on the development platform. I think it's rather cool, and would wear the T-shirt.

But on the viewer, it's way too big and too cheerful to be other than a tad scary. The jury's still out on whether it's acceptable, but I suspect not.

It we must have it, please create a sober-sides alternate.

Richard Ferrell · Post by **Richard Ferrell** » Mon Dec 04, 2006 7:14 am

I will Add your info into the Request, Thanks!

mikejp · Post by **mikejp** » Fri Dec 08, 2006 3:03 am

Today, as I feared/expected, the decision was made NOT to use DotNet Help. Two reasons, one about perception, the other technical.

Perception first: The viewer isn't multilingual, and displays its logo* to our end-users. It's seen as too immature (at version 2!), so doesn't cut it.

Technical: Our developers have an affection for .chm, because they see it as a convenient packaged format. Now they see a large collection of individual files. We know that a single file in an XML format will often be essentially a zipped package of files. Had you considered some method of generating and reading a zipped package containing all the deliverables from Flare, Capture and Mimic?

* Sorry guys, but the words used to describe the logo included brash and cartoonish. Please don't shoot the messenger here, but it predisposed folk to look for other shortcomings...

Richard Ferrell · Post by **Richard Ferrell** » Fri Dec 08, 2006 7:27 am

If you are creating a Dot Net Applciation you can imbed the Help into your Dot Net and you will not have those issues with the Logo, Here is a link to the Help Viewer SDK

http://www.madcapsoftware.com/downloads ... tables.asp

mikejp · Post by **mikejp** » Fri Dec 08, 2006 7:56 am

Agreed, but there's no way I'd have ever gotten that into the schedule. I'd hoped to do that next time, and will try, but it'll be that much more difficult now.

In my experience, you can do radical, or hit a deadline, but doing both requires an intermediate step. Anyhow, Flare is still the development platform. Only the target has shifted.

What grieves me is that the DotNet viewer is so close to being right on the money.

MikeKatz · Post by **MikeKatz** » Tue Jan 16, 2007 5:02 pm

Richard Ferrell wrote:I will Add your info into the Request, Thanks!

Has this not been done yet? I am about to start my first real DotNetHelp application for a generic software package that will sell about 50,000 units. I can tell you for certain that if the company have to have the madcap name and logo on the help viewer, it will not work.

This is a huge issue. As busy as you guys may be, this system as it stands now is just not an option.

Richard Ferrell · Post by **Richard Ferrell** » Wed Jan 17, 2007 7:22 am

I have sent your comments to our Developers, Just a reminder if you embed the Dot Net Help into your Dot Net Application then there will not be the logo or caption

MikeKatz · Post by **MikeKatz** » Wed Jan 17, 2007 7:53 am

Richard Ferrell wrote:I have sent your comments to our Developers, Just a reminder if you embed the Dot Net Help into your Dot Net Application then there will not be the logo or caption

Richard

They do not want to embed the help. Unfortunately the decision is not up to me.

I think madcap understand that in most companies the writer has to do a selling job to get a company and their developers to make changes to help formats and files. Moving from WinHelp to DotNetHelp IS a big selling job - lots of files instead of one file, new ways to call the help, and so on.

In the market that I am in, packaged software, logos and trademarks are everything. Sometimes, when the icon for a new version changes, the tiny icon at the top left of a window changes. I'm expected by their marketing department to re-create each and every screen with the new icon. Third-party logos and trademarks are absolutely unacceptable.

If madcap want to sell lots of products. advertising themselves to my company's users will achieve nothing - they are non-technical, non-writing companies. Rather, allow me to make the help look like its my company's, and then, once there are 50,000 users out there, use this to sell to other writers.

Thanks for your quick response, here and in the forum as a whole. Thanks also for your patience - you are a real asset to madcap!

Post by **RamonS** » Wed Jan 17, 2007 8:57 am

I wonder if anyone wants to embed the help into the project as this makes updating help more difficult (requires release of the entire application).

Developers being scared by many files? LOL! That's a good one. I am sure their source code is split into hundreds of chunks of files...at least I hope so for them and anyone else touching that code. My guess is that they simply didn't want to bother with learning and adding something new that is make work for developers. They have working code for CHMs and CHMs were used in the past. The only way to get them to use something else is Microsoft discontinuing support for CHM in Vista SP27 or a management decision.
I agree that the logo ought to go (in general) in the viewer. It should be as easy as replacing the image with a single pixel image and a recompile, but a better approach is preferred and that was discussed in a different thread.

Yea, the company name and the logo don't work well with non-technical management, but nobody objects to \"Tinyfluff\" errrr....\"Microsoft\" either.

mikejp · Post by **mikejp** » Wed Jan 17, 2007 9:31 am

Sorry Ramon, developers ARE worried by lots of files, especially when they are produced outside their controlled environments and end up dumped in a distributable. Far more comfortable to say \"It's down to the .chm\" and point at \"Tina the TechAuthor\" [(c) Scott Adams.]

Yes, WebHelp generates a lot of files that no-one seems too fussed about, but these are served rather than distributed.

In any case, in an XML world, I see no reason - in principle - why all Flare files destined for consumption via the viewer couldn't be packaged into a neat zip file once I'm done. If its OK to package the resources for an XML doc in what's essentially a zip file, why not a help system? [If you don't believe me, go play with OpenOffice.org formats for 10 mins; M$ does this in exactly the same way].

Remember, selling changes to a skeptical and conservative user base is hard (no one likes hard-earned skills being depreciated by change). Finding barriers that make selling change to developers and marketeers doubly difficult is somewhat less than helpful.

If I say a problem is serious, I mean it.

Post by **RamonS** » Wed Jan 17, 2007 1:16 pm

I distributed WebHelp with great success and anything that was in the \"Help\" folder was my responsibility. So pointing fingers is still easy. And once the developers choose to use .NET they will be faced with a boatload of files that partially are not of their making. OK, many little files generate more overhead, but that is really a technicality that for all practical purposes can be ignored. Besides that, the developers should care less about where files come from. In the end it is the install engineers task to worry about files coming in, being there, and going to the right place.

I am a bit disturbed by a single file, especially when it is a large project. Smart updating will replace only the necessary files and when only the content of three topics changed or only a few images, why deliver the entire package? OOT and WordML are intended to contain a single document, within help it is basically a collection of many documents.

Regardless of all that, I agree that selling a solution is important, but tasks are assigned beforehand. So you as tech writer should be the one selecting the method and format of help content delivery, not the developers. After all, you don't tell them which IDE and coding standard to use. It is difficult enough to convince your boss, so why even try convincing those who really should worry about their own stuff first.

MikeKatz · Post by **MikeKatz** » Wed Jan 17, 2007 1:41 pm

RamonS wrote:Regardless of all that, I agree that selling a solution is important, but tasks are assigned beforehand. So you as tech writer should be the one selecting the method and format of help content delivery, not the developers. After all, you don't tell them which IDE and coding standard to use. It is difficult enough to convince your boss, so why even try convincing those who really should worry about their own stuff first.

It's different when you are distributing standard software to the outside world. When you do, marketing rules. And, in my experience, marketing have NONE of their own stuff.

They don't really understand the product, so the technical writers end up writing the brochure on the pretext that they are there to get the grammar right.

Marketing ride roughshod over development, ensuring the logos, trademarks, and so on, conform to the marketing requirements come what may. And, marketing always have the ability to say NO to anything they feel is critical.

Of course, they want the product before it's ready, and they set the release date. If there are bugs, it's development's fault, because how could marketing possibly have known how badly programmed and/or tested the product was?

I won't ask Richard to comment on how accurate I am as far as MadCap is concerned

.

mikejp · Post by **mikejp** » Thu Jan 18, 2007 2:18 am

(1) If you expect a .chm, a help system IS a single document. Or a single item on a project deliverables checklist.

(2) In a cross-functional team, each member needs team (or at least a team lead) buy-in.

(3) 'Different' = risk.

A different culture may not be good or bad, but may involve different pressure points.

Post by **RamonS** » Thu Jan 18, 2007 6:32 am

mikejp wrote:(2) In a cross-functional team, each member needs team (or at least a team lead) buy-in.

Yes, but a team consists of professionals and experts. Why hire a seasoned tech writer when the developers sideline him or her to be some data entry clerk tellging him or her what to do, how to do it, and rejecting any innovative idea.

Maybe I am just spoiled as I work(ed) in teams that brought me in because I have some experience and skill in an area that the team previously did not have. My personal opinion is that CHM is way at the end of its life and just looks darn ugly. The developers get to use all the new GUI toys that make apps look flashy and polished and we are still supposed to use CHM that consists mostly of battleship gray? Bah! That will fit only if the app looks like something designed for WfW.

mikejp · Post by **mikejp** » Thu Jan 18, 2007 6:49 am

Agreed. So let's storm the barriers to adoption - wherever they are found - together!

MikeKatz · Post by **MikeKatz** » Thu Jan 18, 2007 6:59 am

mikejp wrote:Agreed. So let's storm the barriers to adoption - wherever they are found - together!

Exactly the point. MadCap are creating an unnecessary barrier to adoption, which may not affect some companies, but which does affect others. I understand they want to get their name out there, but in this case they are at best giving it to people who don't have any interest at all, and at worst they are preventing adoption of their format.

By the way, I re-asked about hosting the help in the application. They have tried, but they are using some type of framework which is causing issues. To quote:

"the reason is that the framework requires CMI forms so the developers will need to try to work around that to get the help to work - that's really the issue."

I don't understand, but I have to accept. It's certainly not the writer's place to get involved in technical developer issues.

Diane · Post by **Diane** » Thu Feb 08, 2007 1:21 pm

Is there a way to turn off the Mapcap logo when displaying DotNet Help? My company will not appreciate it either when I finish building the help.

Diane

Richard Ferrell · Post by **Richard Ferrell** » Thu Feb 08, 2007 2:35 pm

Currently its not possible to turn this off if Using the Flare Dot Net Viewer to view the help file. If you embed the Help into your Dot Net Application itself using Our SDK then this issue will not occur.

MikeKatz · Post by **MikeKatz** » Thu Feb 08, 2007 3:05 pm

Richard Ferrell wrote:Currently its not possible to turn this off if Using the Flare Dot Net Viewer to view the help file. If you embed the Help into your Dot Net Application itself using Our SDK then this issue will not occur.

...which is why I am still using RoboHelp, since the development people cannot use Dot Net help within the application. Therefore, we had to stick to HTML Help.

So, why haven't I switched anyway? Because the person I had to tell that you won't make the change is the same person who signed the check to purchase Flare, and I doubt they will do it again. The next check will probably go to Adobe, as much as I don't like it, but it's not my money.

Sometimes, it's the little things that make it all go wrong. For the sake of maybe 30 minutes of a programmer's time at Flare, they lose goodwill and real money. So be it.

Post by **LTinker68** » Thu Feb 08, 2007 3:12 pm

MadCap didn't say that it wouldn't ever be an option -- just that it's not possible now.

And to be fair, just as some programs are only available for Windows PCs because it's the larger market, likewise some bugs and enhancement requests are addressed first because they relate to WebHelp and CHMs, which are probably the most popular help formats at the moment. As more people start to use DotNet Help, then there will be more bugs and requests submitted to MadCap, which will help them decide which issues to address first.

And I haven't used RH in years, but based on what others have posted in this forum and some blogs I've read... Good luck trying to get a bug fixed or enhancement request pushed through at Adobe.

MikeKatz · Post by **MikeKatz** » Thu Feb 08, 2007 3:32 pm

LTinker68 wrote:MadCap didn't say that it wouldn't ever be an option -- just that it's not possible now.

And to be fair, just as some programs are only available for Windows PCs because it's the larger market, likewise some bugs and enhancement requests are addressed first because they relate to WebHelp and CHMs, which are probably the most popular help formats at the moment. As more people start to use DotNet Help, then there will be more bugs and requests submitted to MadCap, which will help them decide which issues to address first.

And I haven't used RH in years, but based on what others have posted in this forum and some blogs I've read... Good luck trying to get a bug fixed or enhancement request pushed through at Adobe.

You miss the point. Our company migrated NOW precisely so that we could have the Dot Net help. We're producing a software package selling to thousands of users, and the marketing department will not tolerate foreign branding - a common issue with packaged software. So, Flare has created an untenable situation as regards using it, and for very little reason. I'm not the only one complaining about this feature.

As regards getting the bugs fixed, I agree with you. However, I've been using RH for 5 years now, the last two years on this version. I don't vary how I use the package, so I'm in need of very little support.

And, since Microsoft have canned their release of the Vista help format, which would certainly not come from RH, I'm left right now with very little reason to move, and no ammunition to argue the case to my boss. Once again, you would think that MadCap would want to make all the reasons in the world for users to move. This is a trivial change, but of course, it's their prerogative - just as it's my boss's pregorative to decide not to give an unhelpful company any more money.

MadCap Software Forums

Whose help is this anyway?

Whose help is this anyway?

Richard...

Re:

Re:

Re:

Re:

Was this issue resolved?

Re:

Re: