Thread

I love EE with all of its features and flexibilit. Today I have meeting with potential customer and as usual EE is being compared with Wordpress and Blogger.

I am very confident with EE, but when It goes to the Publish form EE always being compare with those two. I explain the best I can, but the discussion became so irritating because the clients hate to see any code in the publish form. This is the point that I couldn’t give them rebuttal.

So can you help me, why there’s no WYSIWIG editor?

I know I can use any plugin there, but why there’s no built-in editor like Wordpress.

Because so far (or until very recently, at least) none have been good enough. But really, these days, get Wygwam or whatever if you need it, and you’re good.

I suspect the problem with WYSIWG editors is universal—behavior varies browser to browser. An editor is included in most CMS apps, and most have the same problem over and over again—browser compatibility issues (not to mention that some of the code generated by WYSIWYG editors is horrible).

EE’s HTML buttons can be very powerful aids for most users, though some clients will still demand a traditional WYSIWYG editor, a number of which work fine in EE (in most browsers).

I prefer Brandon Kelly’s WYGWAM.

Thanks for the replies.

The thing is Ingmar, to give an answer to the client “no good” is simply not enough. So thanks gramps for the reply.

I’m sick of always being compared with Wordpress and Blogger (in terms of Publish Form). I understand about EE point of view for generating clean XHTML code, but generally clients don’t want to know - when Wordpress (and other CMSs) steps in and have “stylish” Publish Form and can have same result of the published page.

As I said in my first post, I know that I have to install plugin for this - and WYGWAM demand 29 bucks - but here, considering the maturity of EE, I am just trying to open (reiterate) the discussion with this ongoing boring subject.

to give an answer to the client “no good” is simply not enough.

This is one of those paradoxical issues with EE. Ingmar (and EE) are correct. They have a certain standard for performance, and most WYSIWYG editors don’t measure up, and I applaud EE for providing a quality CMS product that stands well above other commercial and open source efforts in value and capability.

On the other hand, customers want what they want, and in some case keep making the same requests. Removal of index.php and a WYSIWYG editor are high on the list of customer wants, and both have been debated ad nauseam for years.

There are lots of support (money) headaches that EE would encounter with implementation of either, and third party solutions abound, so I understand EE’s obvious reluctance to fulfill the requests (and, no, I don’t believe EE should give every customer everything they want). After all, EE is a commercial entity so they have to balance costs with revenue.

I’m sick of always being compared with Wordpress and Blogger (in terms of Publish Form).

I’ve never encountered that as a problem in almost six years of using EE. WordPress, Blogger, Joomla, Drupal, et al, all have their strengths, and none compare to EE’s strengths, flexibility, capability, supportability, dependability, and security. EE is what it is. If a client cannot understand the differences between EE and others, then the developer needs a different client or different tools.

I understand about EE point of view for generating clean XHTML code, but generally clients don’t want to know - when Wordpress (and other CMSs) steps in and have “stylish” Publish Form and can have same result of the published page.

Clients usually don’t care about the technical issues behind the scenes of any lack of an apparently common features. They just want it to work. As a developer who wants to use EE, there are plenty of solutions available for virtually any similar problem. With the WYSIWYG editor problem, I start first with EE’s HTML buttons as built in to my project’s cost (and point out the benefits), and also cost out a variety of WYSIWYG editors as options (not so easily available in WP and friends). The client chooses. Everyone wins.

With the WYSIWYG editor problem, I start first with EE’s HTML buttons as built in to my project’s cost (and point out the benefits), and also cost out a variety of WYSIWYG editors as options (not so easily available in WP and friends). The client chooses. Everyone wins.

At the risk of restating something obvious from gramps, this is a basic, often ill-understood sales method that is entirely honorable.

Instead of being put on the defensive, turn it into the benefit that it is: you are able to give the client a wide range of solid, editing options that will match the ultimate project requirement and user skill levels - HTML, Textile, Markdown, and a variety of free/commercial WYSIWYG options.

Thus, you can do for your client what EllisLab wisely refrains from doing and what others only pretend to do anyway: make sure the chosen solution truly works on the selected platforms, browsers, etc.

Finally (and hopefully not in a ‘pitch’ session!), you can then cost-out the nasty headaches of each ‘solution’ so you are compensated for your time, having prepped the client ahead-of-time that THEY will be deciding on the trade-offs and, thus, owning the final decision.

Again, excuse me if this is all obvious. In earlier years, I considered our sales guys to be morons who lied all the time, while they considered my kind to be hopeless worms. Now that I play golf like them (salespeople, not worms), well, I’ve learned ....

Thus, you can do for your client what EllisLab wisely refrains from doing and what others only pretend to do anyway: make sure the chosen solution truly works on the selected platforms, browsers, etc.

Spot on.

...you can then cost-out the nasty headaches of each ‘solution’ so you are compensated for your time, having prepped the client ahead-of-time that THEY will be deciding on the trade-offs and, thus, owning the final decision.

And it works like magic. The customer ends up with what they want, what you can build in and support, and at a price that makes it all worthwhile.

In earlier years, I considered our sales guys to be morons who lied all the time, while they considered my kind to be hopeless worms. Now that I play golf like them (salespeople, not worms), well, I’ve learned…

Been there. Done that. Sales folks prefer to sell downhill wherever possible. All a good developer or marketer needs to do is follow their lead and make a nice, straightforward, downhill path toward all the prospective solutions, one after the other, that make clients happy, and developers happier.

Was it Henry Ford who said, “If I asked my customers what they wanted, they would have said, ‘a faster horse.’”?

Well, in retrospect, I just want to be good developer (as the least attempt to be “web evangelist”) - while selling my skills building clients project, also educate them the importance to have clean XHTML. My comfort remains with EE for this purpose. This is where all things that I always follow (and believe) contradict with the conundrum of Publish Form of other CMS that’s been educating a mass that push me in the quandary.

Again, I know, there IS an (obvious) solution for this. And as self assesment is always my thing - I think I am very productive and good sales person as well. What I believe as “good” sales person is not exarcebate things that will create havoc. The choice is that either I got the money or I lost my ethics. I don’t play golf, but I sleep sound every night with my conscience.

Another one to add - many “CMS’s” are no more than page publishing tools, rather than content publishing tools… you can do more with a full toolbox than a hammer 😊

I recently spent several days clearing up the mess created by a client let lose with WYSIWYG. However, we cannot ignore that fact that:

1. most clients expect and often demand WYSIWYG.
2. most other publishing platforms provide WYSIWYG as standard.

Regardless of the technical arguments, clearly the market expects and demands WYSIWYG editing.

Of course there are several good options available for EE to support this, but as much as I hate to say it: WYSIWYG should be in there, out of the box.

Of course there are several good options available for EE to support this, but as much as I hate to say it: WYSIWYG should be in there, out of the box.

There’s nothing stopping you from adding the WYSIWYG of your choice at the same time as you do a new install of EE?

Of course there are several good options available for EE to support this, but as much as I hate to say it: WYSIWYG should be in there, out of the box.

There’s nothing stopping you from adding the WYSIWYG of your choice at the same time as you do a new install of EE?

Indeed, this is what I do, for every install!

I recently spent several days clearing up the mess created by a client let lose with WYSIWYG. However, we cannot ignore that fact that:

1. most clients expect and often demand WYSIWYG.
2. most other publishing platforms provide WYSIWYG as standard.

Regardless of the technical arguments, clearly the market expects and demands WYSIWYG editing.

Of course there are several good options available for EE to support this, but as much as I hate to say it: WYSIWYG should be in there, out of the box.

Yeah, true. Nearly 90 percent of my customer demand WYSIWIG. When I explain about XHTML and the importance of clean coding - they don’t give a toss and…the following question is “why then I can have it in Blogger and Wordpress, are you saying that they break the rule of producing clean code?”...say no more.

Some clients when they see this :

<b> This is bold</b>

they really scared and hate it….

Again, I know we can install plugin for that purpose, I just wonder how possible to do publishing[editing in the preview mode