Entries for label: content

Found 2 entries.

Client Editing of HTML should be Banned

It is well known that the large majority of HTML pages out there are invalid HTML, use custom tags and have layout information mixed in with semantic information.

The real surprise though is that a lot of these pages have been crafted by professional designers and developers over the years. People who are actually being paid to create these things. Properly you might think. But no, not even close.

So if the people who are being paid to create the HTML can't create it correctly, what hope does that leave someone who isn't trained in it at all?

The answer is (of course) none. No hope whatsoever. Even assuming they have had minimal training in HTML, it just isn't enough.

But why is that whenever we have a new client and they say "And we want a WYSIWYG to be able to edit everything" we say without hesitation "Of course". In my view, the customer is not always right and it is wrong to give them that option.

I'm of the opinion that WYSIWYG editors are bad for clients to use especially because most editors generate HTML. The client moves on from wanting some minor formatting buttons and quickly on to "we want to edit all the HTML in the world directly".

This just causes problems. Not just immediate ones but long term ones too.

Firstly the client starts creating weird and wonderful effects (as shown today on Contented). Soon enough they start creating invalid, inconsistent and badly formatted HTML. It gets even worse when <font>, color="#bbb" and unclosed tags start appearing. Don't even get me started about embedding JavaScript in tags to popup a video window - it's not nice and it ain't pretty.

(Aside: I tried to explain unobtrusive JavaScript to a client once but I'm not sure I was explaining it on the right level even if there is such a level as a correct one.)

Even ignoring the actual edited HTML it also leaves the rest of the nicely groomed and well maintained site at the whim of someone who knows nothing about the web let alone the subtleties of HTML.

This practice is incorrect and this function should never be given to the client. It's in their best interests not to be able edit HTML and this practice should be changed.

Instead, clients should be given one of two options:

1) a a semantic markup language they can use which is relevant to their site. Anything to do with styles, layout and formatting is no concern of theirs. Instead they should know what a heading is, a paragraph, some emphasised text and what a link looks like. If you want to give them higher abstractions, how about an external link or a popup one. What about an embedded picture from a local store or from Flickr, or even a YouTube video. This is easy from your point of view and simpler from theirs (no more HTML cheat sheets for the editors).

2) or give them proper editing screens in the CMS which lets them edit only the content of the site. Whenever something should look different it should be because it is different not because someone says it should look different. The Content Management System should be for editing content and content only. It is not a Content, layout, formatting and stylesheet Management System. (And no, I don't believe they should be able to move blocks around in the CMS either but that's a different story.)

Let me give you an example of what happens now and what really should be happening. Let's say you have blog entries on the site each of which has a headline but depending on what type of blog entry it is (technical, opinion, guest), the sub-heading should look slightly different.

What happens now is the following. The editor says to himself:

"Hmm, this blog entry is an opinion piece so the subheading should be blue and bold, but this one is a newsflash, so the subheading should be red and flashing!"

This is bad. Bad, bad, bad.

To fix this you need to do some research on how many different types of blog entry there are. It's not so hard really.

You just quiz the client on how many blog entry types there are and arrange for the appropriate tickboxes, drop-downs or select boxes to appear in the CMS. This way the styles for every blog entry type are correct, consistent and don't look terrible. Furthermore, they are semantically defined rather than syntactically defined. (You have heard of the semantic web, haven't you?)

And finally, if those advantages weren't enough this last one really drums it home. When the site's design is changed in 2 or 3 years time and the blog entries have to look consistent with the new design, showing the sub-headings with the new correct styling is trivial.

Try doing that when your subheading has invalid, unknown and inconsistent HTML in it. Furthermore, if you think sub-headings are a problem, just wait until you get onto the blog entry itself, spotted and pitmarked with nasty HTML all over the place.

All I can say is, good luck to you or the poor person who has taken over on the project. That's going to one beast to untangle.

Labels: web, html, cms, planet-geek, planet-catalyst, content

Inserted: 2008-04-15 22:08 (2 years, 4 months ago)

Zaapt CMS Working under Preassure

There are two types of pressure: technical and environmental. Let's talk about technical pressure to start off with.

On the technical side, I had a bit of a personal challenge last night, but I managed to fix it up in what I thought was a nice way.

As a bit of background information. Each content type contained in Zaapt comes with a Perl Module for (database) abstraction and a load of Mason pages to render that content to the web page. So far, I have been dealing with the administration side of things (the edit pages) and the public side of things (the view pages). Most of the content types fall into this category: the news, blogs, content pages, FAQs, etc

Last night I realised there was a third category. For the Forums, I had written the view and the edit pages. So far this has worked since the view pages were only seen by people once they had logged in, but we (KiwiWriters) also wanted the forums to be publically viewable too.

Therefore, I had to think about what I could name the type of pages which can be read but not changed. This kinda threw me for a while but then realised that it was simply these pages which should be called the view pages.

I set about renaming the current forum view pages to the new category I have called user pages. After a fair bit of renaming I then added the proper view pages. And guess what, it worked a treat :-)

The best thing about it is that there is now a more formal idea about what types of pages there are. This will also come in handy in the future for things like Wikis and being able to post comments or trackbacks on blogs. It is these pages which blur the line between site content and user generated content as demonstrated yesterday with forums.

Labels: zaapt, content

Inserted: 2007-02-03 12:12 (3 years, 7 months ago)