AJP — 08:19 on 10.07.2010

I loathe using wysiwyg when an entry can usually be pared down into more detailed fields. Training on wysiwyg is almost harder than training on textile/markdown, and certainly introduces more problems for non-savvy clients.

I prefer to do more detailed fields than one wysiwyg field, but sometimes the client wins out.

Alex Kendrick — 09:53 on 10.07.2010

Likewise. I also try to break down content into detailed fields, but for those times a longer “body” field needs to be there and a client needs to mix in images with the text, a wysiwyg with file upload capabilities seems the most practical solution.  While it is true that there is still a lot of room for bumbling, it seems the best alternative for non-tech users.

In attempt to reduce chances of producing goofed up html I remove as many of the unnecessary formatting buttons as possible from the wysiwyg and make a screencast for the client.  Once the client gets used to it things go pretty well.

Jason Morehead — 10:38 on 10.07.2010

My approach is very similar to Alex Kendrick’s.

Nicolas Bottari — 10:54 on 10.07.2010

Although it can get nasty, for non-tech users a wysiwyg may be more “intuitive” at first. I also feel it’s sometimes easier to skim through (usually longer) written work when code tags aren’t scattered through the text.

I often do like the above comment and try to remove as much formatting buttons as possible. If there is a source viewer option in the wysiwyg, I always add that button, just in case and for troubleshooting problem content.

Where it gets really nasty is when the client wants to paste in floating images. Having more than one image pasted this way often leads to messed up layout. To the client, the images in the wysiwyg might not seem to obstruct each other, but then they clash on the site and are pushed up/down/left/right. Not to mention that images sizes are less under the developer’s control with a wysiwyg.

Problems like the above then turn into a lesson on the principle of floating elements…

Samuel Jonasson — 18:05 on 10.07.2010

I almost always add a wysiwyg somewhere - and then I almost always regret it.

Paul Frost — 04:25 on 10.08.2010

I have never offered a wysiwyg field on any of the 12 sites I’ve built with EE.
I try and break things down to separate fields and style them in the css.
Inline images are the hardest but with a combination of String, Imagsizer and Matrix it’s achievable and simple for the user.
I have tried out the demos of wysiwyg editors and usually manage to confuse them and end up with dodgy code.

Andrew Rodgers — 12:53 on 10.08.2010

We bill and build Brandon Kelly’s (P&T) Wygwam into every project. This way we have very tight control over what can and can’t be done in each text entry field. Plus the use of the Style and Format menus (custom css/markup) is invaluable for all those “one-off” use cases which often appear all the time.

GDmac — 05:14 on 10.10.2010

Yup, many customers wanting WhoopieWyg, and like Samuel, i’m mostly regretting giving in, like with them pasting word-docs into it.

Nicolas, for floating images there are some css tricks available, like clear:left/right on every floating:left/right image.

Ryan Battles — 15:11 on 10.13.2010

As much as I’d like clients to use HTML, I for longer posts, they will inevitably want to make list items, upload images, etc.  By the time I get done explaining about li’s and ul’s they’ve already gone wonky.  WYGWAM’s paste from Word button is a lifesaver, and even if they don’t use it, it is a good segue into explaining that pasting ANYTHING into that WYSIWYG field is a sketchy idea.

Like many others above, I strip out all but the bare necessities as far as formatting the WYSIWYG field, and for the most part, it’s been a good solution.

Brian Warren — 15:23 on 10.13.2010

This is fantastic discussion. Keep it up!

Typically we at Happy Cog will use textile for all of our formatting. Back when basecamp had textile for all of their fields, it was great training for clients to use that day in and day out in the project.

We stil use it though, and it’s been a wonderful thing for us to give clients some control over formatting while keeping the markup lean and mean. For inline images, we will use something like Low Replace (we used it on Cognition) to let people place inline an image they uploaded. They will enter in something like “[image]” and Low Replace will look for that and replace it with the markup for the image and caption.

Ben — 18:52 on 10.13.2010

WYSIWYG editor is an important selling point for our clients.  Though most of them use very few of its features, any time images, lists, etc. are involved, it’s a must. We use a carefully configured version of TinyMCE along with MoxieCode FileManager (w/Leevi Graham’s extensions for both). At least, this is what we do on EE1.  Importantly, the FileManager allows multiple uploads at once.

For EE2 we’d like to do the same, but are waiting on the extensions we need.

Jonathan Schofield — 08:01 on 10.14.2010

I started out with LG TinyMCE but am moving towards Andrew Rogers’s approach with WYGWAM.

But I also agree with breaking down content into structured fields wherever possible because WYSIWYG is inevitably WYKIWYG: What You Know Is What You Get—and usually clients don’t know as much as they ideally should and are disinclined to learn it!

Brian, can you expand a bit on your Low Replace strategy some more? Can you outline a specific scenario? How does the plugin know which image [image] refers to?

Brian Warren — 08:09 on 10.14.2010

@Jonathan, sure! The way we used it in Cognition was as follows. We have an “intro” field that about halfway through it needs to have an image. So, in the intro, the writer just drops in [image] into the actual text field.

We also have a couple more fields in the form for the image, alt text, and caption.

Low Replace work by looking for a specific string and then replaces it with whatever you want. In our case, we had it look for [image] and then replace it with the image tag along with caption, if needed. I was pleased to see Low Replace was flexible enough to pull this off.

If we were going to have lots of images this might end up being cumbersome, but I could see doing it perhaps with Matrix.

Paul Frost — 09:00 on 10.14.2010

@Jonathan
Have a look at the EE forum thread “Images within entries” for a way to do it using the String plugin from eMarket South.
http://expressionengine.com/forums/viewthread/165625/

I’ve been using his sort of method for a while now, as I think placing images in the text flow is a very common requirement.

Jonathan Schofield — 09:13 on 10.14.2010

@Paul, thanks for that, very helpful.

Jonathan Schofield — 09:14 on 10.14.2010

Thanks, Brian. That’s a cool approach I may try.

And it helps with one of the (many) things I dislike about WYSIWYGs which is how they auto-insert width and height attributes for images: a pain when images need to scale to the width of their container and the height attribute needs to be empty.

Despite this I remain convinced (for now) that WYSIWYGs are a necessary evil.

Pete Karabetis — 21:13 on 10.24.2010

All our clients get WYGWAM installed with EE because, sad to say, more mistakes are made without it.

Before handing off the CMS to the client, we do a sitdown for training and provide screencasts, but the most important things are the following:

1. Set custom CSS for the “Styles” drop-down menu in the toolbar to match the site’s stylesheet.

2. Set the “remove formatting” icon to strip all html tags from data so clients can use it and feel comfortable that they can start from scratch.

3. Set the “Paste from Word” icon to remove all formatting from pasted text.

4. Make the css visible so styles are rendered in real-time to validate clients’ style choices.

After about 100 calls for questions that can easily be answered in the screencasts, clients get the hang of wygwam and are happy