Design issues with Sitecore sites

When building a website most companies tend to have designers, or front-end developers, that are fairly hands-on.  Not only do they do the actual site designs but they do the html\css too and sometimes the javascript if needed, or the implementation of any javascript frameworks that are used.  It's also not unusual for this to be the company's first Sitecore solution and all of these things can create their own challenges which I'm going to talk about in this blog.  It's not all technical issues though, it often comes down to politics and people management too.

Generic vs specific

The most common issue I see with designers is that they think in terms of specifics, whereas building a Sitecore website is mainly about doing things generically, maximising reuse.  Let's take a website that has a search results page and a product page.  Your search results will probably be a repetition of a div that shows the basic summary of the product such as image, title, price and it will probably link to the product details page.  What I often see from designers is a page with a class of "searchResults" on a wrapper div or maybe on the body tag, and the styles attached to each search result rely on that parent wrapper class.  So the css will have things like this to style the image

searchResults img { ... }

However you might want to use that basic product summary elsewhere, maybe as a feature spot on the home page for a product that's on sale, you might want to re-use this summary on your basket page.  However the fact that it needs that parent searchResults class means that html won't work on any other page as it won't have the searchResults parent class anywhere else so you can't make a reusable component out of it.

Even if html doesn't rely on a wrapping class, sometimes the class names are page specific, things like "searchResultTitle" or "basketImage" and so on.  It doesn't stop you re-using the markup on different pages, but it can sometimes mean the markup might not make contextual sense.

That's a typical example of designers producing html\css that is hard to re-use.  Another common example will be links or icons in the site header.  Quite often you'll get markup like;

<li id="basket"> ... </li>
<li id="help"> ... </li>

where the icons are attached via css that uses the ids.  In order to reproduce this we will need some way of storing the name of the id or class to attach to it.
There are no easy solutions to these kinds of problems, it's usually learning process for designers to stop thinking about a page being a static page, and instead think of a page as a collection of re-usable components.

The use of IDs on html elements

This is thankfully a rarer thing now than it was in the past, but designers should avoid using ids.  If your solution uses Web Forms then the need to not use IDs is especially relevant as asp.net will change your IDs so it's hard to reference them in css or javascript.  Even if you are using MVC and Razor I would still get your designers away from using IDs.  This feeds back into the generic vs specific advice, but let's say your designer places a component on a page that has a div with an id of "categoryDescription".  That's great, but what happens when you need a page that uses that component twice?  You will have an id on the page twice which breaks the rules of html and a browser might consider the duplicate element as not having an id at all, or your javascript might ignore the second element or might ignore both of them.

Background images

Ok, this is an argument I guarantee you're going to have :)  If you have an element that uses a background image you'll find the designer will create an element that has a certain class and the background image will be defined in the css using the background-image css attribute for that class.  The reason you'll get this is that it's the best way to attach background images to html elements...the problem is that the image is not content-editable.  You can't define or change the image via Sitecore's content editor.

This leaves you two options, one is to have the background-image attribute attached via an in-line "style" attribute on the element itself (as your component controls the html it can get the url of desired image from Sitecore and create the style attribute), and the other is to not use background-image but a normal img tag with an appropriate z-index to put it to the background (again as your code controls the html you can control the src of the img tag).  Your designer is going to insist you do neither of these things, however you're going to have to reach a compromise on one of them.  Good luck :)

Direct access to the project

Some designers are happy to simply give you static html and css files, and you then create layouts and renderings from that html.  They can manage the css files themselves, but any updates to the markup will need to be done by developers on the views.  This does take more development effort, especially when it comes to updates.  You need to look at the updated html and work out what exactly has changed and make the required changes to the required renderings.

Some designers are used to having direct access to the project and to do their own updates and implementations.  This might become a bone of contention and I see this being a problem more often when the designer is used to working on non-Sitecore sites where it's easier to implement and maintain the markup.  However do you want a designer creating or updating Sitecore renderings?  If you do then you probably also don't mind your gardener doing heart surgery.  There is a lot of thought regarding general project design and architecture that comes into doing a Sitecore rendering and it's not unreasonable to expect that a designer might not appreciate all of the nuances.  And no-one wants to have conversations like; "I was doing some updates and now nothing on the site works" "What did you change?" "I don't know".

I appreciate some designers are going to be competent at these things than others, these are really just observations from my own personal experience, every company and every designer is different, but these are situations you will often have to deal with.

General politics

As you can see from above it's not always technical issues, they are often political.  When a designer has been working at a company for years and is used to doing something a certain way, and you now tell them they can't do things that way anymore they often feel put out and devalued and you'll often have a tricky situation on your hands.  Developers tend to be very practical and matter-of-fact, and designers tend to be a little more artistic and sensitive; you can say to a developer "You know that javascript framework\ORM\IoC container we've been using, well let's use a different one for the next project" and they'll probably say "Yeah, good idea, let's see how they compare".  You tell a designer not to use ids anymore and World War III breaks out :)

Another common issue is that when designers start to "get" Sitecore and what it is all about they can again feel marginalised and devalued.  They're used to making all the updates and handling the creating of pages etc, and when they see you're moving away from that model and toward one where you are supplying re-usable components that the marketing team, or the content editing team can use to create their own pages designers can feel that they're effectively programming themselves out of a job.

What designers really want is just a Rich Text field that they can stick anywhere they want on the site, where they maintain the markup in that field.  That's not what Sitecore is all about, though.  It's a different way of thinking, it's a CMS, so yes the idea is to possibly move the responsibility of building pages away from the design team.  However in reality that often rarely happens.  Normally the design team do end up with the responsibility of creating the pages, but rather than creating them with basic html markup, they're reduced to sticking something together like a Lego kit, and sometimes they're not going to like that.

Conclusion

I know I've been long on problems here and short on answers, but this is largely an exercise in dealing with people, in explaining things, in bringing people around to the benefits of change and so on...just managing people in general so how you resolve these situations will depend on the people involved and on your own style in resolving conflict.  Sometimes it can come down compromise as well, I've often implemented things in Sitecore I've not been mad keen on doing, but I've done them to reach a compromise to match how a designer wants to work (such as storing your css in Sitecore which will be the subject of my next blog), and hopefully you can get designers to meet you half way sometimes too.

I'd love to give you more concrete solutions to these problems, but I'm a developer, not a motivational speaker :)