Flare WYSIWYG and actual output

[amberlink]

Somene mentioned in one of the answers that sometimes the XML editor doesn't show exactly what is going to be output UNTIL it's output.

Is there a list somewhere of what is shown on screen in either the WYSIWYG or the XML Editor and what is output?

Also, is there a way to show what my tags actually mean without having to choose to edit the tag?

By this I mean, when i have tags represented in the code view of:

<p+> or <td+>, I'd like to know what the styles are that in that tag by hovering over it.

Also, is there a way to stop the really annoying way the editor if you accidentally click on a tag jumps to the top of the file you're editing?

One last question, is there a way to TURN OFF collapsing my elements? I'd rather see all of my elements listed out in the XML and don't want to have to click the - or the + to expand out when I accidentally collapse my tag?

Thank you.

[RamonS]

I know that centering an image through the img style doesn't show in the WYSIWYMG editor, the output is fine. I am sure there are other things.

[NorthEast]

Is there a list somewhere of what is shown on screen in either the WYSIWYG or the XML Editor and what is output?

I don't know of a list, but you'll find that there are differences in what you'll see in the XML editor, the preview, the internal browser preview, and the final output.

The XML editor is just that - an editor - so it's never going to show you everything. For example, using things like absolute positioning or float/clear won't be represented. It also doesn't show a few things that it probably should, e.g. background images, autonumbering, forms.

The preview (and internal browser) will generally do a good job of showing you what it will look like in a browser, and elements set in your master page will be displayed. But they don't include some things which you'll only see in the final output - e.g. the miniToc.

[RamonS]

The XML editor is just that - an editor - so it's never going to show you everything. For example, using things like absolute positioning or float/clear won't be represented. It also doesn't show a few things that it probably should, e.g. background images, autonumbering, forms.

The preview (and internal browser) will generally do a good job of showing you what it will look like in a browser, and elements set in your master page will be displayed. But they don't include some things which you'll only see in the final output - e.g. the miniToc.

The editor is sold as being a WYSIWYG editor and thus should show exactly how the output will look like. Also, the internal browser/preview is Internet Explorer. It would be nice to have the ability to check against a real browser without building output. IE fudges output and it most likely depends how the preview looks like based on the IE version installed on the system. While IE7 seems to do an OK job most times IE6 is just plain horrible when it comes to rendering XHTML.

[LTinker68]

Also, is there a way to show what my tags actually mean without having to choose to edit the tag? By this I mean, when i have tags represented in the code view of: <p+> or <td+>, I'd like to know what the styles are that in that tag by hovering over it.

If you don't have a background in web design or are at least somewhat familiar with HTML, then I'd turn off the XML code view and return to normal "WYSIWYG" view (toggle the <t> icon in the toolbar). The XML code view, while it might be handy for determining if you have overlapping tags, will confuse you more than anything if you don't have a basic understanding of what the tags are, what they do, and what their limitations are. Plus you don't see your styles applied to the text, and as an author, seeing the styles applied to the text helps me better as I write and organize content.

If you want to learn more about HTML, there are plenty of books out there. Plus http://www.w3schools.com/default.asp is a good learning site. I'll often go to W3's website, too, for reference (http://www.w3.org/).

[amberlink]

I'm fine with the XML, and the tags. I just wish the XML editor was a lot more XML-spyish in it's handling of the tags and not relying on a half-hearted attempt to (me) show both the internal XML code (sort of) as well as make the XML "easy" to read. Which it really doesn't either very well.

For example, I'd like an easier way to edit my tags, clicking on the tags just either collapses or expands them, i have first put my mouse over a tag, wait for the goldish kind of box to appear, THEN choose the item I want from the context-menu.

Bit much isn't it? There is about 5-10x/hour I forget that right-clicking on a tag will let me edit it. I'd just like to turn off certain "functionality" in the editor.

As for the WYSIWYG view, I think that it's also not a completely clean implementation since WYSIWYG should be What you SEE is what you GET, not sort of what you get is what you sort of see.

I used to work in SGML so jumping to XML was not that big a deal.

[KevinDAmery]

The thing about WYSIWYG in this case is it really depends on your output format. Different browsers interpret CSS differently, so if you make WebHelp it may look one way in IE 6, a different way in IE 7, and different again in Firefox or Safari. If you're building CHMs, it will look different again. (Mike Hamilton described it as being more of a WYSIOP editor: What You See Is One Possibility.)

You CAN at least compare how things will look in print to how they'll look online using the Medium selector in the upper right of the topic window.

I'll second what Lisa says about Tag view: to me, it's worse than useless. If you want to edit the tags, you're better off either using the block selectors in WYSIWYG mode or just opening the topic in the internal text editor. (Or XML Spy, for that matter: as long as you don't add any tag types that aren't supported by Madcap's DTD you should be fine.)

[amberlink]

This leads me to another question:

Is there somewhere in the documentation where i can find out what is supported between different browsers and browser versions?

For example, someone mentioned that something in IE 6 and 7 look different as does Firefox.

Is there a listing of what is different by browser and version of browser that the output from Flare looks like? Or is there a way to make sure that what works and appears in one browser looks and works in another and the varying versions?

I realize this is a tall order but can it be done?

[RamonS]

It is a lot to ask and it is even more to ask to have that maintained as with every patch for IE of FF this may or may not change, plus it may or may not change with a Flare update. It also depends a lot on how styles are implemented and which settings one uses (such as %, pixels, ems, inches, cm....). I also do not think that this is a Flare/MadCap task. The way how stuff is supposed to look like is clearly defined in the W3C specs. Given that there are at least a dozen different browsers or better to say rendering engines that are in use by more than just a handful of people this will be quite some work.
Besides that, I think for a tw it is more important as to how to make things look and work the same in each browser. That is even one more step after finding out the differences in rendering. While ultimate perfection is an honorable goal I think a tw just has to pick the battles. And to correct the browser rendering differences is just not worth the effort in my case. Keep in mind that any style you set can be overruled by a browser style sheet reference anyway. I'd make sure that it works in those browsers that adhere closest to the W3C standards and then make sure that it doesn't totally crash and burn in IE just as a courtesy. I think IE 6/7 should be simply ignored, 6 more than 7. Microsoft promised to finally take a look at the W3C standards for IE8. Until then there is no point in breaking your neck to break your pages so that they work in IE. From what I have seen so far MadCap did a very good job to make WebHelp work in all the more popular browsers.

[KevinDAmery]

To add to what RamonS (aka David) said, this affects every html editor, not just Flare. Dreamweaver, Robohelp, Frontpage, etc. etc. all have to deal with this issue. It's just the nature of the beast when dealing with web output.

[doc_guy]

I'm going to agree with Kevin and David. It doesn't seem reasonable to me to expect MadCap to list every possible scenario for every possible Flare option in every possible browser.

My experience has been that Flare (for the most part) works with WC3 standards. Browsers that support standards should have similar output. But do you expect MadCap to re-test every element every time Firefox, IE, Opera, Safari, Netscape, etc. releases a new version? That seems totally unreasonable to me.

And I don't know of a single tool on the market that does this, and every tool suffers from the same problems. It isn't Flare's fault. It's Microsoft's fault and it's Mozilla's fault, and it's whoever's fault that doesn't follow the formal standard. (Except if it were FLARE that wasn't following the standard. Then it would be Flare's fault. )

[SteveS]

This leads me to another question:

Is there somewhere in the documentation where i can find out what is supported between different browsers and browser versions?

For example, someone mentioned that something in IE 6 and 7 look different as does Firefox.

Is there a listing of what is different by browser and version of browser that the output from Flare looks like? Or is there a way to make sure that what works and appears in one browser looks and works in another and the varying versions?

I realize this is a tall order but can it be done?

To approach this from a web developers perspective you should maintain working copies of all the browsers you think your users may use. Whenever you release a new version it should be tested in all the browsers your users use.

I currently have versions of Firefox, IE7, Opera, and a virtual machine with IE6 for testing web output. Given that our users are in a Windows world that may be overkill, but every work place has someone who installs Firefox.....

[KevinDAmery]

I currently have versions of Firefox, IE7, Opera, and a virtual machine with IE6 for testing web output. Given that our users are in a Windows world that may be overkill, but every work place has someone who installs Firefox.....

Over here, that'd be me Everyone else in the office uses IE 7 for some reason....

[RamonS]

There is also a package that makes use of DLL redirects and allows for running all IE versions in parallel from 3.01 on. I use it at work mainly for testing IE5.x, 6 and 7.

[NorthEast]

I would definitely test your help in as many browsers as you can, and ensure that it works ok.

You need to design your help so that it looks ok for everyone (or as many as possible). If it doesn't work for some people then really that's your own fault for poor design.

At the end of the day, the majority of users don't really care about W3C standards or which browsers adhere to it - and like it or not, IE is the most commonly used. If your help doesn't work in the user's browser, then they'll blame you (or more likely your tech support staff).

[RamonS]

And that is an approach that I somewhat disagree with. Sure, the help should work in any browser, but in order to make it work OK in IE one has to pull special tricks and use different coding (more in IE6 than IE7). Fact is, that this is not a deficiency of the help system, but of the browser displaying it. With your approach you need to make sure that your developers fix all the bugs in Windows, because your software runs on Windows.
The problem is that way too many web developers make their pages work perfectly with IE rather than to adhere to standards. We might as well close down the W3C and screw HTML when everybody just does what they want. This problem shows nicely why it is mandatory to unbundle IE from Windows, although it might already be too late. Microsoft did the world a horrible disservice with their arrogance and carelessness in regards to web standards. And the ones who have to pay for it is the web developers and the users. What I am not saying is to go out of your way to make the help not work in IE.

[NorthEast]

I understand what you're getting at, but I don't think you've got my point. I'm suggesting that you develop and test your help so that it works for as many of your users as possible (with the minimum of fuss).

I'm not suggesting that you should bend over backwards to suit IE, I'm suggesting that you try and produce something that works ok for all browsers.
If something works in one browser but not another, then it's probably better to find an alternative method that works or just avoid using it.

in order to make it work OK in IE one has to pull special tricks and use different coding (more in IE6 than IE7)

In my own experience, I haven't had to include any special tricks or formatting in my project to get it to work for IE or any other browser. And I don't have a simple help system either - it has quite a complex stylesheet, lots of scripting, uses forms, etc.
What I have done is to test it out, and avoid using things that I know will break one browser or another.


If you're using anything in your help (CSS, scripts, whatever) that doesn't work in a particular browser, then the surely the easiest solution is not to use it, or use an alternative method that doesn't cause any problems. If you have to resort to using special tricks or work-arounds for a particular browser, then you'll create your own maintenance problem when new versions of browsers are released.

I just don't think there's much point having a bells-and-whistles help system if it only works for half of your users. And if I conciously include something in my help that won't work for a number of the users, then that's just poor design on my part, and it'll cause complaints that I'll be asked to fix.

[RamonS]

The reason for you not needing to do anything special for IE is because MadCap's devs already did that for us. I get more and more the impression as that we both mean the same in the end, just expressed it differently.

[amberlink]

I have to support IE 5.x+
Firefox (all versions to latest)
Netscape (all versions to latest)
Linux
Unix (if I can support Linux, I should be okay with Unix)
One client even asked if I could create a text-only help system to run on AS400. Which far as I can remember, I don't remember ever doing anywhere else.

So, I have to be able to support a wide-variety of browsers and platforms. I thought maybe the WYSIWYG was doing that for me and actually showing me what I was creating IN those environments. Seems I'm going to have to create output and test in those environments individually.

[LTinker68]

Seems I'm going to have to create output and test in those environments individually.

For web designers/developers, that's a de facto step of the process. It used to be a lot easier with Netscape because you could have two versions of Netscape installed on the same computer, but Firefox doesn't allow you to do that. So if you have to support a variety of browsers and versions of those browsers, then you're probably going to need at least two computers -- one computer with one version of all those browser and another computer running another version of those browsers. Sometimes easier when you're in a work environment where not everyone is running the same browser, but definitely more difficult at home, unless you have several computers at your disposal. And it's not always easy at work, either, since you might have to track down those various computers for testing. Generally, it's a good idea to work 2 or 3 computers into the budget just for testing. In my case, I tend to remote desktop into a couple of servers that I know are running older versions of IE.

It's a bit more difficult in your situation since you're also testing across platforms. And I feel for ya. But if there was a single tool that could display web pages as they'd appear across all browsers and versions and platforms, then I know a lot of web designers would be using it. Unfortunately, the old tried-and-true method of manual testing is the only solution I know of.

[Richard Ferrell]

Flare only supports the following Browsers. From Flare's Knowledge base

• WebHelp
  
  * Required: Microsoft Internet Explorer 5.5 or later; Mozilla FireFox 1.0 or later; Safari 1.3 or Later on Mac OS X

I have seen issues with Netscape, and Opera with Flare's Webhelp.

[Ryan Cerniglia]

I have to support IE 5.x+
Firefox (all versions to latest)
Netscape (all versions to latest)
Linux
Unix (if I can support Linux, I should be okay with Unix)

A resource that might help you test out multiple browser versions on different OSes is BrowserShots. The only major drawback to this service is that you must have your website posted to the web. In addition, if you're testing the last version of IE for Mac, it is not available through this service.

[i-tietz]

If you want to learn more about HTML, there are plenty of books out there. Plus http://www.w3schools.com/default.asp is a good learning site. I'll often go to W3's website, too, for reference (http://www.w3.org/).

W3 is a nice try but
a. difficult to find your way through it (it's a GIANT website)
b. it gives you the intended standard, not reality

Is there somewhere in the documentation where i can find out what is supported between different browsers and browser versions?
I realize this is a tall order but can it be done?

How is your German or your French? I know an excellent website to visit for those purposes ... (http://www.selfhtml.org)
(I was a web developer in a "former life" )
I cannot believe there is no parallel for the english speaking web developers ... there is bound to be at least one ...

AND:
Have you got a website? Ask your web admin to look up, what browsers your customers use ... browser stats are a totally normal part of the logs ...

[RamonS]

b. it gives you the intended standard, not reality
[...]
Have you got a website? Ask your web admin to look up, what browsers your customers use ... browser stats are a totally normal part of the logs ...

Anything that is supposed to go out to the web ought to be W3C standards compliant. W3C documents describe how to code pages and one ought to adhere to that. The fact that some big company decided to roll their own and massively disrupt how the WWW works is no reason to continue this way. Enough damage is done by providing pages that work only in one particular type of browsers.

Browser stats are fine, but they are also notoriously unreliable. Depending on the web server and log configuration that information is either not captured or logged only in general means. Although less of a concern, the browser decides which browser ID to send back. So one could run Firefox and report as an Opera browser. That is a popular means to use a real web browser with IE-only sites where the pages work fine in a non-IE browser, but the web master decided to ban everyone who doesn't use IE.

Code to standard and cite the W3C documentation when complaints arise. That is the way web design has to be done. Anything else is just bringing excuses for doing a crappy job.

[i-tietz]

Code to standard and cite the W3C documentation when complaints arise. That is the way web design has to be done. Anything else is just bringing excuses for doing a crappy job.

Have you ever tried telling that to your customers or the head of your department?
Do you usually cross the street at green whatever else may happen? And if a car hits you because it drove on inspite of having the red light, you're right but dead?

Honestly: If you have a customer or a head of department and they check what you produced in whatever browser they usually use, it's simply supposed to work. It's as simple as that.
You are a good web developer, if you can make it work on as many common browsers as possible. That creates satisfied customers.

Inge

p.s.: It doesn't matter which one of the browsers you refer to - the Mozillas, Netscape, or IE - they all go astray in one way or the other ... you'd see that if you had a closer look at selfhtml.