Oh my god. It's full of code!

Salesforce Site.com Design Principals for a Web Developer.

So Site.com has been out a while now (and it’s awesome), and while only a handful of companies are using for production websites, many more are playing with it or at least considering it. It’s a really cool product with a lot of power, and it’s kind of a bummer it wasn’t been more widely adopted yet. More adoption would likely mean more features, more developer articles and other cool stuff being built using it. However, there are probably reasons it’s been a little sluggish, and if I had to guess I’d say part of the slow uptake is due to the fact that people;

A) Don’t understand what it does
B) Don’t trust that it can do what it says it will
C) Don’t know how to approach it
D) Insane cost

I know all 4 reasons did slow up a little (even though we ended up launching a production website before site.com was even GA, so I guess we couldn’t have been that slow). However we did end up figuring it out, using it, and are really enjoying it. Though it wasn’t all smooth sailing and the hardest parts weren’t technical, they were design related. So I’d like to share with you a few of the lessons I learned and the stumbling blocks I ran into as a developer trying to write a system marketing could use.

First up, what is Site.com? Site.com is a content management system with a powerful WYSIWYG editor built in. It allows non technical people to create and manage small websites that have limited amounts of interactivity (I mean it doesn’t write javscript for you of course, the menu creator is a bit limited, though some CSS wizardry can make it pretty slick, and there is no native apex access. Maybe in the future though). It uses a template system where you can create templates with defined editable areas which pages can be cloned from. The idea being that your website has a few core layouts (maybe like a landing/splash page, a home page, and some detail pages). Those templates are probably designed by a programmer/designer type with some development background and then the pages cloned from the template should be easily modifiable by your marketing team, or any other non technical people. When changes are made they stay in your sandbox until they are published, similar to doing a commit/push in programmer terms.

This idea of templates is a big deal. For myself as a ‘old fashioned’ developer I had always used large amounts of CSS to control the look and feel of my pages. Of course the idea there being that one simple change in your CSS could easily propagate to all the linked pages. It ensured a consistent look and feel, and also reduced page weight. So this is how I first approached using site.com. I prototype’d my pages on my local machine by following the PSD given to me by our designer. I’d write up a functional example of the PSD using just pure HTML and CSS. After the prototype was as pixel perfect as I cared to get it, I’d being ‘translating’ it into Site.com. Div’s became panels, spans became content areas and basically the result would be perfect, but it sucked.

Why did it suck? Well remember, doing things the old way meant that no style information was contained in the page itself. It was all in the CSS. I usually would even setup images as CSS divs with the background-image property. Now say marketing wants to change that image (as they always do) well guess what, thanks to the way I had things build they’d have to go dig in the css, find the right ID or class and modify the hard coded image path. That’s terrible! Or what if they want to change the padding or margin of a div/panel? Back to the CSS. What was the saving grace of web developers in the past had become the bane of marketing now. Not only was it difficult for them to modify, there was also the serious risk of them breaking something else. CSS is fragile stuff and a fix one place can be an overlapping element somewhere else! So it seems we are in a catch 22 here. We can’t use much CSS, or else marketing can’t really manage the site very well. We can’t just not use it or else the site will become disjointed and have the same issues websites did before CSS. Or so it seemed.

Remember those templates I mentioned. I for a long time under estimated their usefulness. I thought they were a simple toy meant for those ‘non developer types’ so I essentially had been dismissing them. How wrong I was. If you change your thinking into looking at a template as a layout structure with embedded CSS all of a sudden it all becomes easy. Build your page as a template and go ahead and put in the images and divs. Setup as much as you like within the template and made the areas editable that you want marketing to be able to change. Use CSS sparingly to provide easily reusable styles for headers, subscripts, body text and such. Then create pages from your templates and let marketing go nuts. This way you retain some of the benefits of CSS by styling some of the really shared elements (namely text elements, and perhaps some of the container divs and very basic layout structure of your site) but still retain enough flexibility for other users to manage. Here, let’s look at an example.

Say I wanted a a background image for my banner. It’s going to have a background image and a top margin. As a developer who is trying to follow general best practice for regular websites, I might opt to something like this.

<style>
#actionBanner
{
    padding-top:20px;
    padding-left:10px;
    width:290px;
    height:281px;
    background-image:url(actionBanner.png);
    margin-bottom:19px;
    background-repeat:no-repeat;
}
</style>
<div id="actionBanner"></div>

Looks nice right? I mean the HTML has no styling attached to it, it’s only structural as it should be. The CSS is clean, easy to read. But now think of it in terms of site.com. If your users actually want to use an image that isn’t actionBanner.png for the background on only one page, they are going to have to go dig in the CSS file to either create a new class, or change the existing one. Changing the existing one would change it for any page that uses that banner, which in this case they don’t want. So now you are back to modifying CSS and have totally defeated the point of using site.com (which in my eyes is to get marketing off your back when it comes to website changes). So what can we do? Using a site.com template, we can simply insert the image in the template. Set the CSS properties on the image itself, and save the template. Now pages that are cloned from that template have the provided image by default, but the users have the ability to override them since it’s marked as editable. They can’t screw up the template so you always have that as a backup, and each page can be customized by simply modifying the properties of the image element. It’s genius!

Now you might be saying, wait this is just like going back to the old days. You have embedded styles in your pages, this is terrible! Not so fast. Remember the reason we hated embedded styles in the first place was because they were unmanageable. You’d have to modify each individual page if you wanted a change. That is not the case with templates. When you have a non editable area in a template, any change to that is immediately propagated down to any page cloned from it. Like I said, templates can be viewed as a hybrid HTML CSS definition. Modifying the inline CSS on your template is the same as modifying a CSS class.

So in short, these are basically the take aways.

1) Prototype your whole website on your local machine in regular HTML/CSS if you can. This will help you figure out what things really will be shared among all pages (like font faces, basic layout elements, paragraph spacing, etc). Also, you’ll have an easily portable copy of your website in case you decide to migrate to another hosting platform. When crating this prototype, remember it will be going into site.com though, so don’t be afraid to use IMG tags, or even a few font tags if they are one off styles.

2) Converting your HTML pages into site.com pages is pretty easy if you’ve done it the right way. Divs will become panels. Spans and P tags will generally become content areas. Try to avoid having editable content as a direct child of a panel/div as it may make styling a bit more difficult and you’ll lose some control over styling. Your marketing users would be able to adjust the panel/div if they are able to adjust it’s content so they could end moving it around or whatever. Just do a panel/div that is not editable, then inside of it create your content area that is editable.

3) Use CSS sparingly. Embed anything that isn’t totally globally shared within the templates. Otherwise you’re going to have marketing users digging around in your CSS and likely messing it up. Avoid this at all costs.

4) Come up with a reliable naming scheme for your resources, especially images. Site.com is flat, there are no folders. If you are used to using folders to organize your resources, you might be in for a bit of a rough ride, or at least a messy architecture. Before you write a single line of code, decide how everything will be named. Images, SWF files, javascript includes, custom fonts, everything exists in the same “folder” so account for that.

5) Last but not least, work with site.com not against it. I know us developer types frequently have a hard time trusting tools to work right and we often think we know better. In this case, trying to do it your way will likely cause you more work. Use the features available. Understand how site.com ‘wants’ you to work and then follow that design pattern.

I hope this helps some. I’ll probably be doing a few more articles on site.com including how to do ajax links and maybe a few other things. Till next time!

3 responses

  1. Link to the production site currently running on site.com?

    October 4, 2012 at 4:41 pm

    • Here are a few. The numbers are growing quickly, and I may have slightly dated info.

      http://www.site.com/customers

      Last I heard from my boss there was about 100 – 120 paying site.com customers.

      October 4, 2012 at 4:43 pm

  2. Attractive component to content. I just stumbled upon your website and in accession capital to
    assert that I acquire in fact loved account your weblog posts.
    Anyway I’ll be subscribing in your augment and even I fulfillment you get entry to constantly
    quickly.

    February 26, 2016 at 3:41 am

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s