RE: .net and Help

["Zigo, Joy" <Joy -dot- Zigo -at- HARPERCOLLINS -dot- com>]

I agree with John. 
Many thanks, Michael! Your second email shines even brighter light on
what used to be murky mysteries.

p.s. I'll bet there are yet other help authors out there who would
appreciate being able to read something along these lines right on the
Macromedia/Robohelp site where the versions of Robohelp are described. 


-----Original Message-----
From: John Posada [mailto:JPosada -at- isogon -dot- com] 
Sent: Friday, March 05, 2004 5:33 PM
To: Michael Hamilton; Zigo, Joy
Subject: RE: .net and Help


Michael...this is very good. Thanks

John Posada
Senior Technical Writer
Isogon Corporation
http://www.isogon.com

-----Original Message-----
From: Michael Hamilton [mailto:MHamilton -at- macromedia -dot- com] 
Sent: Friday, March 05, 2004 5:25 PM
To: 'Zigo, Joy'; TECHWR-L; John Posada
Subject: RE: .net and Help

Hi Joy,

Answers in line below... 

-----Original Message-----
From: bounce-techwr-l-79152 -at- lists -dot- raycomm -dot- com
[mailto:bounce-techwr-l-79152 -at- lists -dot- raycomm -dot- com] On Behalf Of Zigo, Joy
Sent: Friday, March 05, 2004 1:48 PM
To: TECHWR-L
Subject: re: .net and Help


John and Mike, thank you both. 
This information shines some light on the dark mysteries of help for
.net!

I do still have some questions about how this web forms and web services
map onto the latest versions of Robohelp.

Specifically: 
A) If our developers are using .net to develop an application of the Web
Forms variety, it seems to me you are saying that we can use plain 5x
(or continue using DreamWeaver) to make the Help. 

[Mike] Yes, this works.


B) If developers are embedding web services, such as reports using SQL
Server Reporting Services, into a Web Forms type application, then what?


[Mike] Then you have choices :0). Actually, in this case, where the app
is "consuming" a service, but not really running as a service itself,
then I would probably stick to the traditional browser-based help.


B.1) Mike, what do you mean by "traditional Web technologies sort of
hung on the side of your Web Service"? What would this look like in real
life? What does "hung on" mean in simpler language? Could there simply
be Help in a small window of its own, which is opened when user clicks a
Help link on the same screen where the reports are displayed? Or would
it be something else? If so, what? (If you "code your own" help for use
with .NET, presumably it also hangs on the side, whatever that means.)

[Mike] By "Hung on the side" I am referring to the fact that you will be
using traditional HTML technologies and not .NET technologies. From a
customer perspective it makes absolutely no difference. The customer
experience should be exactly the same. The difference is on the dev
side. I have run into shops where they are demanding that everything be
.NET from end to end, now that they have made the switch. For this type
of situation we developed our RoboHelp Office Pro for .NET. With this
tool the help system runs natively in the .NET framework as a service
and the .NET app can communicate with the help server via the .NET
framework. For example: The developers could embed a search box directly
in the .NET application. When the customer does a search the app
collects the search string and sends it to the help server as an XML
data string through the .NET Framework. The help server can digest this
search string, generate the search results (a list of appropriate
topics), and send this back to the application as another XML string.
Neither the customer nor the application ever actually opened the help
system, but were able to interact with it programmatically. (did that
make any sense?). This would not be possible (or at least not
easy) with the traditional browser-based (non .NET) formats. If you
don't need this kind of application/help interactivity and your
developers aren't purists and don't mind mixing technologies, the
formats like WebHelp, FlashHelp, (YourVendorsBrowserHelp), can still be
used. 


B.2) If Help does "run as a .NET service" -- what does that help look
like in use? Is the process of developing the help any different in this
case than if the help were being developed for a cold fusion app?

[Mike] I can only speak to RoboHelp here, but for the customer it looks
identical, and for the Help Author the process is close to identical.
The main difference is on the developers end. With things like
WebHelp/FlashHelp they will be making standard http URL calls to launch
the help system. With the .NET version of RoboHelp they will be able to
use the .NET context sensitive APIs to link the app to the help and they
get the additional programmatic control that I described above. The
major difference for the Help Author is that if they are doing the http
URL calls, then the developers will have control over the browser
windows which open and host your help system. When the APIs are used,
they the Help Author maintains control over the browser window
attributes which are used.


Also, what are the advantages and disadvantages of B.1 vs B.2 from a
help developer's point of view? What about usability differences from
the end user's point of view?

Thanks again--
Joy
.....................
Joy Zigo
Interface Architect
HarperCollins Publishers
New York
212-207-7645






**********************************************************************
This message is intended only for the use of the individuals to which it is addressed and may contain information that is privileged and confidential. If you are not the intended recipient, you are hereby notified that you have received this transmission in error; any review, dissemination, distribution or copying of this transmission is prohibited. If you have received this communication in error, please notify us immediately by reply e-mail and delete this message and all of its attachments.



^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

ROBOHELP IS THE INDUSTRY STANDARD IN HELP AUTHORING
New RoboHelp X5 includes all new features such as,
content management, multi-author support, distributed
workforce support, XML and PDF support, and much more!

Purchase new Macromedia RoboHelp X5 by March 31st and receive a
$100 mail-in rebate. http://www.ehelp.com/techwr-l

---
You are currently subscribed to techwr-l as:
archiver -at- techwr-l -dot- com
To unsubscribe send a blank email to leave-techwr-l-obscured -at- lists -dot- raycomm -dot- com
Send administrative questions to ejray -at- raycomm -dot- com -dot-  Visit
http://www.raycomm.com/techwhirl/ for more resources and info.