cms/stands for "complicating my shit"
It's sad but true. The gap between back-end developers and front-end developers remains. In my plea to trust your htmler I focused on the importance of the work we do, I'll take this opportunity to get a little closer to one of the core issues tearing our priorities apart. Rather than target actual developers here (this article is meant to build bridges, not destroy them), let's see what drives them to discard our sweat and tears in favor of html poo.
Initiatives like Fronteers surely help our cause but to make this marriage work there has to be effort on both sides of the fence. Awareness of our job alone won't fix this somewhat awkward situation, it demands a more structural change in how web projects are developed. Our tools prove crucial in this process and that's exactly where things go wrong.
content management system
Most sites these days are built using external CMS systems. From small-scale projects using WordPress, middle-sized sites using Drupal to corporate monsters using Tridion. Static sites or sites using custom-made CMS systems are rare these days which is not that surprising considering the complexity of building a quality site. Most CMSes offer lots and lots of out-of-the-box functionalities that make the life of a developer a lot easier.
Content Management Systems these days do way more than simply managing content. The WMS-hype has long since gone, but in fact Web Management System is a much better description for the functions of a modern-day CMSes. These CMS systems are life savers, at the same time they are most often the biggest limiting factor within a project. While coping with all the complexities of setting up a site most CMSes lock themselves down, limiting flexibility in order to assure a working-out-of-the box experience for the layman.
And while I do understand the need for these simplistic solutions, locking out the pros to do a good job is definitely not the way to go. You won't hear me say this is an easy task to accomplish, front-end development doesn't know too many best practices and even those are often contested by different groups of people. The fact remains that if I deliver a set of static templates, your system needs to be able to implement these templates flawlessly. No questions asked.
cannot modify stuff
The truth is that most default implementations of a CMS fall short when it comes to front-end development. There's html-code vomited from the core of the system, css handling is handled in the least efficient (even faulty) manner possible and coding structures dictate how html pages are structured. If you want to know what kind of CMS people are using, it often suffices to look at the html source code. This is of course plain madness.
If you press hard enough you'll learn that most CMSes do offer the option to override html and you can often tweak the html code to perfection. Either the knowledge to do this is too limited or the CMS itself makes it too difficult to accomplish this within the confines of a project, but the result is always the same. Your meticulously developed templates are thrown overboard or they're used as a general guideline rather than a blueprint. Previous css work becomes obsolete and you'll need every trick in the book to cook up something that somewhat mimics the original design.
consumers must suffer
A website should be user-centered. And by user, I mean the people visiting your site, not the ones entering content. Your visitors interface with the front-end, meaning html, css and javascript. Messing this up is simply not an option anymore as it will visibly decrease the quality of your site. If a CMS is poor at html output you need to grow experts to bypass these problems and/or you need to budget this from the very start. Out-of-the-box solutions are good if you want to set up a quick, private initiative, but they simply won't do for corporate sites and professional projects.
Some people seem to believe front-end developers spend their days happily tweaking html and css, only to go back to Fairyland every evening to play with the magical animals and sing jolly songs while dancing in the middle of flower fields. I can assure you this is a far sniff away from reality. The fact that our work is often discarded because it's too difficult to implement into some or other automated system definitely doesn't help. I don't believe it's wise to start pointing fingers, but I hope it's clear by now that this is counter-productive and doesn't help the quality of the final product.
slowly but surely
Truth be told, CMSes are slowly changing to accommodate to the needs of the front-end developer. Drupal 7 should make a serious leap forward (when it's out of beta), SharePoint 2010 has dropped most of its tables (hell yeah!). Still, the need for skilled html skinners remains, no matter how hard it is to accomplish in the system of choice. If CMSes want to becomes WMSes they should remember that outputting html is a key feature and flexibility to change and adapt code is a priority.
If outputting custom html becomes easier developers should have little trouble implementing our work into their CMS of choice. Whether this is a definite promise remains to be seen.
Comments
Dan Hensby
Damn, you must have used some terrible CMSs. Take a look at SilverStripe (www.silverstripe.org) for one that has practically no restrictions on HTML structure.
Maik Jablonski
Have a look at Jease (http://www.jease.org). Jease is built from ground up on the idea to separate the CMS from the public site properly. So you're absolutely free to use any existing (Java based) template technology to create the HTML exactly as you like it.
Matt
Strange, I haven't come across a single CMS which does not give me the flexibility to freely apply my own HTML/CSS to content. What kind of CMS and what kind of restrictions are you talking about?
Niels Matthijs
From what I learned about SharePoint2010 the webparts (flexible html parts) are still rendered using tables. Another popular example is the Drupal breadcrumb which doesn't pass through a template but is rendered from the core code.
Mind that our company specializes in front-end only. For back-end implementations we depend on parters, so if they tell us something is impossible (or too much work considering the budget) there is not much we can do.
The proposed CMSes look interesting but sadly the choice of technology usually lies beyond our reach.
Jeremy Wilken
I specialize in CMS development (of the php flavor), and while I can understand some frustration I obviously don't agree that it makes things worse.
Any reasonable CMS (or WMS if you want to call them so) can do what you are fighting against. Drupal can do it, but its not the best platform for front-end developer friendliness in my opinion. Much of the time you need php incantations to 'hook' into various aspects, making it part voodoo. For example, Joomla allows you to override any part of the output (which is written so that display files are separate from logic files due to MVC architecture), simply by including a modified copy in your template.
Point being, that out of the hundreds of CMS platforms out there today, many of them do a pretty good job of letting a front-end developer customize the output. How they do it varies, and some are easier, but any one worth using can do it.
What I'd be more interested in is what more you want, or how you plan on getting it? It takes the input of front-end developers like you to give direction on how to make tools better.
Mihael Konjević
We are working on hosted CMS solution that tries to fix these things. You can read my blog post about view layer in CMS's here http://www.retroaktive.hibreedcms.com/blog/view-layer-in-cmss-part-1
I think the biggest problem is that things that are really easy for developers can be really hard for people that implement CMS. Also it is hard to create flexible system for which you don't need some programming knowledge.
Niels Matthijs
I think that's where the biggest problem lies. As a front-end developer I don't work with any kind of CMS. I make static templates, keeping my focus entirely on writing html, css and sometimes a little javascript.
Those templates are sent to our implementation partners who in their turn use them to set up the CMS. My need is very simple, all I want is to see my static templates translated to the CMS output in the same way a designer wants to see his design translated to the browser. How this is done and where to improve a CMS to make this process easier I really don't know. What I do know is that this task is slowly turning into a job for specialized people.
I do recognize the Joomla way of working you're talking about by the way, if I'm correct Drupal 7 is doing something similar at the moment. This sounds like a move in the good direction for sure.
As for using less popular CMSes, that's always a bit risky as most clients love to hear recognize a familiar name. And as a company who doesn't have the inhouse knowledge to set up these CMSes, we can't really vouch for them unless we find a specialized partner who can do the implementation.
Marcus Kielly
The two biggest problems when using CMS are dealing with markup generated by plugins, and giving the user a rich text editor. You can get round the former (to a degree) if you have any server skills, but the latter causes far more of a problem IME At the same time - I personally feel part of the problem is the demand for "pixel perfection" in layouts - no matter how much we'd like it to be, the web isn't print. (JFTR - I was an artist for over 10 years, I switched camps, now I'm a dev)
cmsguy
check out typo3-cms
typo3.org
you can easily use static html files as templates:
http://typo3.org/documentation/document-library/tutorials/doctuttemplselect/0.1.0/view/1/3/ (google for "typo3 modern template building",underscores seems to cause problems here)
with tempavoila extension its just a matter of a few mouseclicks to map your cms-contents to divs for example.
a very powerful opensource enterprise cms.
look what others are doing with this cms:
http://www.aoemedia.com/en/references.html
IMHO one of the most flexible cms around, once you get used to typoscript.. here in germany i think most of business-sites are using typo3
cancel bubble
I think this is an awesome article that really highlights HUGE issues I've experienced and continue to experience.
"SharePoint 2010 has dropped most of its tables (hell yeah!)."
I'm currently in SP 2010-land and it's still tables tables tables. Do you have any more info on how to coax 2010 to not use 3 nested tables to hold what is really needed? Inspecting the outputted SP DOM makes me want to cry...
Vingborg
Technically speaking, you are right, but I think you gloss over the central issue: Why do we choose a CMS in the first place? As opposed to writing one bottom-up and tailormade for each and every project? I can assure you that many back-end developers would love to give it a go!
The answer, of course, is budgets, deadlines and a host of other restrictions, none of which is necessarily determined by neither front- nor back-end developers.
Contrary to popular belief, most back-end developers (CMS tailors) actually like bringing those "fairyland" html/css/javascript concoctions to life. That's what we do. That's how we make people happy.
The problem is not so much the markup (and css and javascript) itself, but all the myriad assumptions a front-end developer is making about how easy it is to implement in realword, tightbudget, deadline-is-looming scenarios ... within the given boundaries, on the platform of choice.
I have been in the business too many years not to recognize a good front-end developer when I see one, and I really, truly appreciate the art and craft of the trade. But the ones I like to work with are definitely the ones that appreciate the restrictions that ultimately applies to us all. And one such restriction is the CMS at hand. You may have done a terrific piece of work in and of itself, but if it means that I have to work extra, unbudgetted hours to meet the deadline, I cannot help becoming a wee bit grumpy.
Your call for action (such as it is) is perfectly valid. On its own terms, I couldn't agree more. But in the real world, it's not a matter of raping your html into submission with regards to a specific CMS (or vice versa) . It's a matter of recognizing the restrictions of the project at hand.
cancel bubble
@Vingborg I totally hear what you're saying and agree. The problem I see is front-end (from product management/marketing/ideation to wireframes to design to interaction to front-end code/working protoypes) may not know the restrictions of the project at hand. This is because what I'm lumping all as "front-end" doesn't know the back-end especially when it's brand new technology (this is my first foray into SharePoint from the front-end and our internal back-end doesn't really have SP expertise). The eventual back-end folks may not, either, especially if it's outsourced to ESL folks, communication is more difficult and this might be their first "real" SP project of this size, or even the same version (2010).
We tried our SP project internally - taught us we can't do SP development internally. We ended up outsourcing and while we're working with the vendor, we're not really working with the vendor if you know what I mean. For example, I have no idea how they're going about coding all the components - they're just doing what they're doing trying to meet the deadline because I'm sure there are financial incentives. And I doubt they care about front-end concerns the same as I do because they're not front-enders.
And we're having to make concessions in our design because they can't replicate it.
We hand off front-end working prototypes and don't know what we're going to get until down the road when we finally see it for the first time. It's pretty much a reactionary relationship.
IMO, you really need tight collaboration between front-end and back-end as early as possible:
Get back-end involved with wireframe review to at least flag "interesting" items.
Get back-end involved with high fidelity design. Take a close look at those interesting front-end/UX/interactive modules and workflows. Are we still on the same page? Any big flags running up their flag pole?
Get back-end involved with front-end production:
Front-end: "This is how I'm going to build the data table with sortable columns, our thead is the hook for the javascript, standard fare...Here's a working demo, let's check out the source....What do you think?" Back-end: "Hmmm, we can't render the table with a thead, the out-of-the-box data grid just doesn't support it." Front-end: "OK, can you not use the out-of-the-box data grid and write a custom one that does render a thead? We're using these sortable data tables in many places, this isn't just a one-off module." Back-end: "Well, we could but it'll take time which I don't think we really have for this project." Front-end: "OK, can you render out a sample table with the out-of-the-box data grid so I can see what markup I have to work with? That way I can provide code which should be the same structure you'll be outputting." Back-end: "Sure, no problem." ... Front-end: "OK, here's the re-worked demo, do you think this will fly on your end?" Back-end: "It looks like it should."
Vingborg
@cancel bubble, yup. That conversation pretty much sums it up. Or, rather, that's how it ought to be.
In my experience, the very best projects are almost always delivered by tightly knit teams, in which the distinction between designers, architects, front- and back-end developers etc is blurred by an unstinting commitment to the overall result. Where professional compromise is the modus operandi, not a cause for strife and blame games.
Still, Mr. Matthijs does have a point. And a very good one. It's just not very helpful in my dayjob.
Chris Graham
Since version 2 of ocPortal (http://ocportal.com/, we're now on v5) we've made it so there's complete flexibility in HTML/CSS layouts. All markup comes out of modifiable templates.
Where it becomes difficult for any system is when frontend designs imply functionality that the CMS might not deliver, or how the system is organised. A few examples:
If a gallery screen includes multi-resolution download links, and the CMS does not have that feature
If the member profile screen includes a Facebook-like wall and the CMS does not have that feature
If gallery images have various thumbnails around the system, all different sizes, and cropped in different ways
If the login box includes a Facebook Connect option, and the CMS's internal system for keeping track of users (e.g. for private messaging, permissions, whatever) doesn't support that feature
If the gallery navigation exists as a box embedded on the right of all screens and is browsed by AJAX, and the CMS is implemented structurally to serve galleries via gallery-view screens linked to image-view screens.
Ultimately this gets solved by a strong communication process, good planning, and appropriate budgetting. The CMS can be changed as needed, or the design can be made to match what the CMS can do, or usually it's a bit of both. There's really no way that can ever be solved, so a mature process and relationship is needed to make things work smoothly.
It's very similar to the problem frontend developers have when graphic designers design things that CSS layout cannot do (e.g. assumptions about text size in tight layouts), or cannot perform well enough (e.g. it' all images), or can't be spidered, or have usability issues when built (e.g. links not styled right).
Also there is learning to be done if one is implementing for a CMS oneself. Again, it's analogous to the frustration a graphic designer would have learning CSS to implement what they put together quite easily in photoshop. The designer thinks their design is intrinsically ready for publishing, the frontend designer knows it needs a lot of work to implement for the web, and the CMS implementor knows that to make designed features work and to allow content management it needs a lot of further work.
All the potential difficulties I've stated here have very little to do with HTML implementation itself. It's more a design issue.
Niels, please drop me an email (chris@ocproducts.com) if my company can help you. We have very successfully partnered with design companies on complex site implementations in the past, without having to ever throw away frontend HTML.
Niels Matthijs
Let me make it clear that I do appreciate the difficulties of translating static html input to CMS output. I've had many talks with CMS developers before so I do know about some of the problems you guys are facing. Maybe I didn't put it strongly enough in my article but I do put most of the blame on the CMSes, not on the developers.
On the other hand, every single person in a project is facing these deadlines and extra hours. I don't think anybody is expecting a 100% match from the next in line on the work he has done (our designers know that I won't be able to match their designs in all browsers, even a single one is often impossible - much like Chris explains in the post above). That said, one advantage back-end developers have is that their job comes at the end of the whole development process. What he makes (almost always) reaches the final delivery, so even if there are extra hours involved, they are usually well spent.
When I spend extra hours and stress over tight deadlines I'm not even sure I'll see 50% of my work back into the live implementation. And whatever piece of html that doesn't make it only means more hours of rewriting css and additional browser debugging. I can assure you most standard CMS code isn't the best to work it, especially when dealing with IE6.
That's actually a very good point. While it makes sense from a business/contract point of view, there's not too much logic behind the fact that the choice of CMS is usually made at the beginning of a project. It would make more sense to wait until the wireframes and designs are finished before making a well-considered decision. Most companies only specialize in single-software implementations though, so that makes it a little harder.
Going back to the core of the argument, I still believe a site should be made for the needs of the users. The technology should follow those needs, not the other way around. That's probably a little idealistic in a world dominated by profits, but one can only aim for the best.
Also, I've been very happy with all the reactions so far. Thanks to all for the meaningful input!
Nathalie P
There are some great points-and being on the frontend myself I agree that there is a huge gap that needs to be bridged.
I have often asked backend to discuss with me implementation and CMS constraints. But there is often a lack of communication to explain what is and what is not possible on a platform.
What goes hand in hand with your point Niels where you mention that maybe the CMS should be picked after the wireframes are finished. I whole heartily agree but it is rarely possible. The other issue I have encountered is that shops have CMS preferences. Ultimately, a projects is pushed on one platform (not because it is the best platform for a project), but because is is development preference. We work now with different developers to have them give us detailed CMS recommendation for various platforms which is hopefully in the best interest of the project and not because of their preference.