What might *MOTW* be? I don't use IE myself for anything BUT testing (GRIN). I'm a proud Firefox guy.
IE is, however, our corporate standard. Should I be enabling MOTW for those who use IE, as in everyone here but me?
MOTW and IE users
-
- Propellus Maximus
- Posts: 1571
- Joined: Fri Jan 11, 2008 1:30 pm
- Location: Horsham, Pennsylvania
MOTW and IE users
Craig
Lost in Disturbia
Lost in Disturbia
Re: MOTW and IE users
MOTW stands for "mark of the web". When that's enabled, Flare inserts a line of code in each topic at compile time that tricks Internet Explorer into thinking that it's viewing the help from a public website and not from your local computer. If you're viewing the help locally and you have MOTW disabled, then you'd see the yellow warning bar at the top of the IE window and your content wouldn't appear until you clicked on that bar and told it that it was ok to show the content. And you'd have to do that every time you went to the help.
So if your users will be viewing the help on their local computers, then enable MOTW in Flare.
If your users will be viewing the help from your web servers (i.e., a public website), then disable MOTW in Flare. Haven't it enabled in this situation can cause other problems.
If your users will be viewing the help from your web servers but during testing you'll be viewing it from your local computer and don't want to have to click that bar every time, then you might want to create two targets, one labeled "WebHelp Local" and the other "WebHelp Remote". Enable MOTW on the local target and disable it on the remote target. During testing, build with the local target. When ready to release to your customers, build with the remote target. You can also set up the publishing feature on the remote target to upload the files to the web server when you're ready.
So if your users will be viewing the help on their local computers, then enable MOTW in Flare.
If your users will be viewing the help from your web servers (i.e., a public website), then disable MOTW in Flare. Haven't it enabled in this situation can cause other problems.
If your users will be viewing the help from your web servers but during testing you'll be viewing it from your local computer and don't want to have to click that bar every time, then you might want to create two targets, one labeled "WebHelp Local" and the other "WebHelp Remote". Enable MOTW on the local target and disable it on the remote target. During testing, build with the local target. When ready to release to your customers, build with the remote target. You can also set up the publishing feature on the remote target to upload the files to the web server when you're ready.
Lisa
Eagles may soar, but weasels aren't sucked into jet engines.
Warning! Loose nut behind the keyboard.
Re: MOTW and IE users
One thing to keep in mind that bit me in the butt is that if you enable MOTW, users can't open PDF files you've linked into your TOC or made a link to from a topic.
There is a workaround for this that Tinker gave me, which if you search this forum you'll find, but you should be aware of that limitation. Until I had Tinker's hack, I had to choose either to leave out PDF files or make my users see that security message every time they opened the help. Both options were annoying.
Cheers
There is a workaround for this that Tinker gave me, which if you search this forum you'll find, but you should be aware of that limitation. Until I had Tinker's hack, I had to choose either to leave out PDF files or make my users see that security message every time they opened the help. Both options were annoying.
Cheers
Victoria Clarke
Re: MOTW and IE users
Here are details on the hack --> http://forums.madcapsoftware.com/viewto ... 327#p31324
Lisa
Eagles may soar, but weasels aren't sucked into jet engines.
Warning! Loose nut behind the keyboard.