Thread

I suppose the difference may be that they would be able to have the advantage of having a stylized list - if the css was set for unordered lists.

Ya, then a <ul> would have an advantage. Most of my clients just have bulleted lists within the body so I havn’t had that need yet.

Using EE for Clients with No HTML Experience

I’d say that for anyone without any HTML experience whatsoever, any set-up that came without WYSIWYG would be quite daunting.

And it renders how? Same as if they just typed Opt-8? If so, what’s the advantage? Does it really have to be a <ul>? Just curious. Does the fact that it’s a <ul> buy the client anything semantically?

@Pxlated:

Your Opt-8 suggestion is a new one on me.  How does it render in the markup?  Yeah, I typically style the UL’s differently than the default styling. Sometimes, I use images for the bullets using CSS and the client just has to type * list and the CSS handles the rest.  But using textile has other advantages beyond unordered list - as you probably already know.

Your Opt-8 suggestion is a new one on me.  How does it render in the markup?

Opt-8 is just the standard Mac keyboard combo for a bullet and it’s been used in standard apps (wordprocessing, page makeup, etc) for almost ever. There’s an equivalent for Window (Word) can’t recall what it is though. It renders in the post as &# 8226; (added a space to render here). So, it’s something that most clients are familiar with and takes no effort.

Yeah, clever.  I was aware of it, but never thought to use it with HTML.

My experience has been that these things make it too easy for the client to make a mess.  Nested tags, tons of nbsp; etc…

You can just not supply them the WYSIWYG buttons that would really make a mess, right? And a little EE find/replace tag can take care of some nbsp and such. Obviously that is not ideal, but still. The other options aren’t perfect either. I have found that auto br can confuse people as well. (Although that may say more about my design skills, dunno). There’s almost always a way that a blockheaded user can mess up our perfect, perfect designs.

So, the cliche applies, it really depends on the client and the job.

A good practice for me has been: after making it as simple as I can, explain it to them patiently, and leave them with a onesheet instruction guide with pictures and arrows and such. Everyone loves that kind of thing.

Also, a) having the EE buttons right beside the field they are to be used with b) replacing the buttons like < i > with a word-like image of an italicized letters everyone’s familiar with. Both I think would go a long way for helping the tech averse users (ie: people over the age of 40) “get it.” However I have not had the time or patience to figure out how to do that. Oh well. Live Look can help too.

The best idea: make a site that never needs bolds, bulleted lists, etc. Banish all that. They can use caps lock and dashes if they want to be obnoxious.
😝

The trouble with the formatting buttons is different browsers insert differently (haven’t checked this recently with the absolute latest)..at insertion point or at end of post. I always found it easier to just teach them what <i></i> and <b></b> mean (in a little guide) than trying to figure out what’s happening when they call. 😊

Yeah, I agree. This is why I’ve only bothered to think about it, never actually got around to doing it. It’s just a small thing, usually not that hard for people to get the tags. Just one of those litter user experience things that I think makes people (I’m speaking of the impatient, technically averse) feel more comfortable quicker. Though I have no scientific measurement on that.

So, yes, a small thing, but I am obsessed with the small things. 😊

And I’d forgotten about the insertion point. But yeah, if it does it at the end of the post, kind of defeats the purpose of the buttons.

Both WYSIWYG and not-WYSIWYG have their advantages and disadvantages. In my (very limited) experience, non-WYSIWYG is more often better, but that doesn’t mean it always is.

I am wondering how important everyone thinks it is for a client to need a WYSIWYG in order to update content on their site. 

I have done two sites in EE and love it!  I would not want to have to go back to Wordpress only for that one feature.  Is having the auto
feature along with the bold and italics features enough for a client to get by with?

Thanks!

You can, but so far in my experience not only are they extremely buggy to implement, slow, and cause lots of formatting problems.

I got so fed up with them, I turned them off.  Although I don’t know how I would have a client edit their own articles if formatting was required.

No WYSIWYG is pretty much an electric fense issue for me. Don’t have it, won’t purchase. Forcing users, or customers to have to worry about 3rd party addons, or getting users to learn HTML, or a variation of the two. Unacceptable, and it’s a barrior to entry IMO.

No WYSIWYG is pretty much an electric fense issue for me. Don’t have it, won’t purchase. Forcing users, or customers to have to worry about 3rd party addons, or getting users to learn HTML, or a variation of the two. Unacceptable, and it’s a barrior to entry IMO.

Once you install (easy as pie) the textile plugin, it’s easier and more reliable than a WYSIWYG editor could ever be.  If you have your CSS setup to style the output, you could not ask for more finite control.  If a WYSIWYG is your barrier for entry, I’d caution you on the loss of control you’ll have over the appearance of your page.

No WYSIWYG is pretty much an electric fense issue for me. Don’t have it, won’t purchase. Forcing users, or customers to have to worry about 3rd party addons, or getting users to learn HTML, or a variation of the two. Unacceptable, and it’s a barrior to entry IMO.

By not having one by default its our intent to let users decide what is best on a per-project basis. Though you make a good point the counter point is that by including one by default you’ll face customers with browsers freezing, bad HTML code, or endlessly configuring tools they don’t need.

The truth is that WYSIWYG is not a mature web-technology yet. Its absolutely fantastic in some situations and terrible in others. There also isn’t reliable cross-browser compatibility in the popular open source tools.

The good news is that they are getting better every day. At some point one will be good enough to include but that day hasn’t arrived yet.

Though you make a good point the counter point is that by including one by default you’ll face customers with browsers freezing, bad HTML code, or endlessly configuring tools they don’t need. The truth is that WYSIWYG is not a mature web-technology yet.

Again, just my own personal experiance here. I’ve been using the default WYSIWYG editors in popular software products such as Vbulletin, IPB, PhpBB and Community Server for more than a decade without a freezing browser, bad HTML code, or configuring of any tools whatsoever.

I’d say the number of issues caused by any of the aforementioned products in combination with their WYSIWYG editors, is an exception to the norm. Again, just my personal experianes, obviously you’ve had different experiances and that’s okay.

I’ve got to jump in with my endorsement of Markdown. I’ve had 5 people without HTML knowledge pick it up in just a few seconds using only John Gruber’s guide. I expected a little push-back and received none.

I’ve had a question about nested lists, and I’ve seen some “creative” formatting, but those are minor quibbles considering what I’ve seen from WYSIWYG editors in the past.