Substitue to VisualFormat?

Hello Developers,

I work for Interwoven, and I have a question for you all -

(i) Do you currently use VisualFormat?
(ii) If not, what is the #1 reason?
(iii) if you had an applet-based tool, would you use it?
(iv) do you have a recommendation on what would be a good and complete replacement to VisualFormat?

- anilp

Find more posts tagged with

Comments

pawlr

I'm really suspicious of applet-based tools because they tend to **** out alot. redraw errors, memory leaks all that stuff

I don't know much about VisualFormat specifically though.. I would try it if I knew where I could find it.. is it a templating GUI?

Migrateduser

Those are some of my main concerns regarding VFE, but they would probably apply to any product.

One of the primary purposes of templating should be to separate content from presentation. Adding visual format editor makes this impossible. It also reduces the structured nature of the content.

The "tags" that visual format editor inserts are HTML (maybe even deprecated?), which would seem to make the content less usable for non-HTML applications.

VFE is marketed as giving users all the control they need, so when it's time to implement users and management may expect those features. But to follow style guidelines I think restrictions have to be in place.

I think VFE supports custom stylesheets, but I'm not sure how easy it is to configure and if that makes it harder for users. This seems to be a critical issue but I don't have enough information to judge.

Interwoven is sold as a browser-based application, but VFE requires installation. It apparently even overwrites certain VB libraries and whatnot. There is also performance overhead with every VFE textarea on a page. I think a DHTML control might work better, but I'm not sure.

Migrateduser

Oh yeah, and the whole paste from word issue, but I'm sure you know about that one. I think this is also a critical issue.

anilp

From KB article 2274 :
Change the style sheet in the configuration file visualformatconfig.xml.
<style publishstyles="false" href="mypath/mycss.css"/>

most javascript based lightweight WYSIWYG editors don't have good support for enforcing style, nor copy-and-paste from Word. (many customers do ask specifically for this feature, regarless of the whole notion of separating content from presenation)

so, what are the merits and demerits of an applet based tool (i hear one - stability), and do any of you have any recommendation?

Migrateduser

Right, but is there a way to associate the bold button with a stylesheet for instance? Otherwise you lose a lot of value. I hope that there is but I haven't done the research. Actually, soon the UI people on this project should be doing an extensive analysis regarding what this tool can give us and what we can't live with about it.

If you are talking about building an aplet, I would expect that a company that focuses exclusively on this kind of functionality should be able to do the best job, and Interwoven should focus on it's core competencies.

Migrateduser

There is at least one more issue. Some companies must have put some time into developing configuration files for the Ektron tool, even writing custom replacements to iw_value and Perl subroutines to wrap XML parses of the DCRs to clean up the content VFE creates, and training users. So if another tool is available, the Ektron tool should probably continue to be freely available and supported in the base product.

Also, why would an applet be preferable to a DHTML tool?

mick

We are currently using VF to allow our content contributors, who are business users and have no knowledge of HTML or XML, to enter content.

Our main concern with VF is the inability to clean up all the word garbage that is valid XHTML (e.g. class attributes) but that we don't want in our pages. It would be good to be able to do this at data-capture stage rather than presentation stage.

A java applet would have to work *properly* across Windows, Macintosh (OS 9 and OS X) and Unix for us to consider using it as an alternative to VF.

A good replacement would be something that allowed us to specify our own DTD or XML schema and would allow non-technical users to enter content which followed that schema. This would be a good step towards real separation of content from presentation. I know we can do something like that now by having a separate DCT field for each element on the page - but it would be good to have something like a VF field where users can enter headings, paragraphs etc and tag them according to a given doc-type rather than being confined to html or xhtml.

MattP

I agree! This is the biggest issue with VFE. It is a challenge to get authors to understand they are not "designing" a page. The design is taken care of for them. VFE is a slippery slope.

When it does get used, I agree with all of the post here. It is a large install, it is buggy, and not very elegant.

Matt

Matthew Petitjean
BOC Group
Murray Hill, NJ 07974 USA

Migrateduser

That's a good one.

Good thread and excellent replies!

Applets??? It's dangerous. It needs to be VERY WELL TESTED on all the different platform/OS/browser combinations. Then, tomorrow MS release I.E. 7 and the applet would have to be re-installed. We would have the same problem we face today with eWebEditPro.
If, and only IF, you can accomplish the same thing with DHTML, that would be the way to go.

Also, agree to the fact that Interwoven should focus on its core products, and not try to re-invent the wheel. For sure, there is a product/company our there with a good webeditor type of thing.

Last, but not least, eWebEditPro is not all that bad. I guess, IW paid for it. Make ektrom fix/upgrade/change/revamp their product.

Paulo Gouveia
Royal Caribbean and Celebrity Cruises
Information Tecnology

anilp

if an applet is used, it most definitely would be a third party product, and interwoven wuldn't build one. currently available DHTML editor tools don't support complicated features such as custom-style support & copy-and-paste from word - even if they did, it would be very slow.

The approach is to provide an alternative to VFE, but still keep shipping and supporting VFE as the official solution. The applet alternative would be recommended for those that don't want to use VFE, but not shipped out-of-the-box.

mick, the kind of functionality you are referring to is definitely stretching the use of VFE. stay tuned for more, you will be pleasantly surprised. i can't discuss more than that in this public forum.

Thanks all for your comments. if/when we come across a good applet-basesd solution, we will make ensure stability and cross platform/os/browser support before we recommend it.

- anilp

Edited by anilp on 02/03/03 09:55 AM (server time).

mogoo

I agree with mick's suggestion.

We've had all sorts of problems with VF, as most people have. Is there any way you guys can link a VF-type box with Dreamweaver or Homesite editors? Those are 2 types of editors that are far cleaner when it comes to handling Word code, stylesheets, and overall html code. That would be my suggestion. VF is a good and needed concept; just work with Macromedia instead to develop a better, less buggy version.

maureen

gzevin

Hi Anil,

Department of Education and Nraining of NSW, which is one of the largest installations in Australia, is using my Rich Text Callout that works for 99% of their requirements. This callout does not use any ActiveX and could be used in a strict environment, where no software could be installed.

Greg Zevin
Independent Interwoven Consultant/Architect
Sydney, AU

Migrateduser

We use VisualFormat with TST 5.5.2. Clients are Win98 through WinXP.

The major pain points are:
Stability - Win98 clients in particular. We had to use the VF "button" in all of our templates because we have replicants with text fields which would cause browser crashes if more than 5 text areas were open with VF in-line.
Documentation - complex and often incorrect
Configuration - complex and often requires much trial and error
Client itself - heavy installation and execution requirements, problems when our corporate install of IE has settings changes that cause the Applet to stop working, inconsistent browser support, no cross-platform support.
Support - turn around time on basic problems has been very long, due to Ektron having to make code fixes. I understand this is getting better, but I'm sure it will always be a challenge.

Our users like VF, and we've turned off enough of the 'dangerous' stuff like Tables so that they can't mess up our corporate look-and-feel too badly.

Alternatives? I don't know what else is out there. I can imagine a DHTML solution might be almost as hard to support as VF, due to the vagaries of DHTML support in various browsers.

anilp

Supporting tools like Dreamweaver and Homesite is definitely beyond the scope and intent of VisualFormat. VF is intended for business users to markup textual content and for businesses to enforce style of the content. if we keep nudging the scope of functionality, the technology might gradually become totally unsuitable for it's original intent.

the stability and installation problem you've mentioned with inherent with ActiveX technology. unfortunately for the advanced functionality like cut-and-paste from Word and such, you'd need these AciveX controls - DHTML is simply not capable and definitely not realiable for enterprise rollout of such critical business-user features. this is where applets *could* be a better alternative.

as far as support is concerned, i think the open cases have dwindled down to a trickle. Ektron has fixed quite a few problematic areas with their patches and is quite responsive to us in fixing critical bugs.

gzevin

Anil,

IMHO, VF is much more what the users would need as you give them an ability to change the presentation in a way that goes beyond the principle of separating content and presentation. What is needed - RTF area plus a limited table building facility. This is what I have also done in many implementations - restricted VF to these features only.

Greg Zevin
Independent Interwoven Consultant/Architect
Sydney, AU

Renata

Just a point on usability of VF, we had a large implementation where VF was more or less successfully accepted by the user community. We did however have to invest a lot of time and testing into VF configuration which control what buttons are available to users and how the individual boxes behave including encodings for special characters.

I definitely agree with all weaknesses listed here, but some of them can be resolved via training - not the nicest solution but works.

also, if your users are really set on using MS Word or other such tools, FrontOffice may be the preferred solution. Its drawback, another piece of s/w you need to buy ... then again, it may be worth it Smiley Happy

-- R