Lots of high profile Web Industry Pro's describe Front End Design/Development (what ever else you want to call it) as 'Responsible for View Source' and I tend to agree. 'View source' covers everything except things that happen on the server and occasionally, some of that as well. Most Web sites can actually be built and run with purely Front End functionality only calling on in-depth server side technology if clients specifically want to use a CMS rather than allow their Web designer to update the Web site as part of a maintenance agreement.
We often have exposure to things outside the HTML arena though. Some situations dictate that we even have to go against what we feel to be the best practice because of restrictions beyond our control.
These restrictions can range enormously. Some of them are understandable and are dependant on the wishes of clients and the budget they have to play with. Others in my view are more avoidable and if not dealt with can undermine the way a site functions or is received by third parties.
All projects have them and there is no point trying to shoehorn a large amount of work into a small budget as this will always lead to disappointment for the client. The process of building a Web site can be tailored to the budget if being looked at by someone who knows what they are doing. There is a certain amount of guess work involved in providing a timing estimate. I always over estimate. The difficulty here is that each discipline overlaps.
Firstly let me explain the terms BED and FED. BED stands for 'Back End Development' and FED 'Front End Development'. In large companies, the two areas are usually dealt with by two seperate specialist departments. Back End Developers deal with the functionality of the site and the interaction between the server and the Web site. This usually means when users interact with forms, register on a site, post a request or product etc, a BED will be the one making the database that will hold all this information, talk to the site. Front End Designers, as hinted above, are usually called upon for everything else. The main issue here is that modern sites have many dynamic areas (which use data directly from a database) which constantly overlap both specialities. A popular way of dealing with this are systems called Frameworks (MVC), which aim to separate Front End and Back End code so they can be worked on separately. Without getting too technical, this is not fool proof because you have to get server data to and fro somehow.
There has been many a time where I have been happy to update a site myself for a client who doesn't update regularly or isn't particularly enthusiastic about the technical aspects of many CMS's. I can't say I blame them most of the time, many CMS's aren't particularly user friendly and sometimes I even comment my HTML and provide an instructional guide so they can update the HTML directly.
The future of CMS - HTML?
This is something every Front End Designer hears regularly. It is easy to get frustrated with clients who break the layout but it isn't their fault. The system they use should not allow them to break a layout. No CMS that I have used is immune to this problem. The inherent flexibility of HTML is difficult to control. There are so many combinations of HTML that are possible on a site that it is quite easy to update the site with content that 'looks wrong' or input a HTML tag that breaks the flow (and layout) of a page.
The other unfortunate part of this situation is that content added by a user is processed and inserted into a database, which means that it falls into the realms of Back End Development. Personally, in my full time job, I have found this situation to be one, if not the main topic that causes the most friction when building or maintaining a CMS driven Web site as part of a team. With the in depth knowledge of how the HTML should behave, a Front End Designer seems to be best placed to fix the problem, which they can if they can access the HTML and edit it without the CMS changing things. This is usually the reason why the original issue arises. As I said before, the Back end programming language is responsible for these kinds of issues and can only be resolved by knowledge from both BEDs and FEDs.
Usually a BED will provide finer control over single field inputs via the back end. There are only so many things a user can enter through using a single text input, a drop-down, check-box etc. The problem usually comes when putting large amounts of content directly into an editor field. WordPress has the best editor I have used but isn't immune to its little quirks. Due to the fact I know HTML very well, I am able to work in the 'HTML' tab on the interface, which gives me much more control over the layout and design of my posts.
Many CMS's, even under this setting, can add their own HTML, or strip things out without warning because it thinks it knows better than the user. I'd take great pleasure in providing a one stop answer to this predicament, however, the inherent flexibility of HTML means that there are simply too many combinations of HTML elements possible to control anything that is entered into a CMS. Saying that, there are projects run by people who care about this kind of thing.
There is a solution which would seem to make sense if agreements can be achieved between FED/client and BED, which would be to lock down the amount of control a client has over the things they can enter through the editor. I've read many articles about the use of style guides. The University of Pennsylvania has an excellent and very clear style guide which anyone can view online. It is in the form of a mini site off of the main one and makes the style of headings, content and any other elements clear to anyone who might be using or updating the site. These seem to be the most sensible way of controlling the look and feel of a site throughout its life. They do not work however, if the site is not locked into them. By this I mean that everything surrounding the editing of the content is geared towards outputting what a style guide is advising, not what the CMS is dictating. Many editors are vastly out of date with Web standards and I realise what a mammoth task this is. I obviously don't know if the styles of the Pennsylvania University site are 'Locked down' in the functionality of their CMS but it certainly makes things completely transparent with no grey areas over the agreed design of their Web site.
Other professionals who recognise the need for Web Style guides include the BBC, the University of Kent and of course Apple. Other organisations, largely due to the nature of their organisation, provide suggestions for styling, such as Yahoo and A List Apart. These are all great examples of how we should be planning out Web design, rather than having a 'build to forget' attitude. Personally, I don't like seeing one of my designs broken and feel like I have failed if I cannot keep my own design under control.
A tool I found recently after a frantic session on google was http://htmlpurifier.org/. This php project aims to take any content and make it standards complaint, no matter what it contains.
If there are mismatched html tags it will remove those that it sees fit, based on best practice. You can also stipulate allowed tags (something I strongly advise for any CMS). Its a shame there is nothing using asp that does something similar. One of the many reasons I never use the stuff.
This article is in the Web Industry category. Here are some other related articles also in this category.