Building a Website From Scratch | Part 4 – Bring It Home to ASP.NET

In Part 1 of the Building a Website Series, we talked about taking a graphic design and prepping it for the web by slicing it up.  In Part 2, we dove into a crash course on CSS to prep you for actually coding the website.  In Part 3, we put it all together in a static HTML page.  Now, let take a little dip into .NET land and convert our work so far into a ASP.NET web app.  This will be the first time where we start focusing on a specific server-side technology.  Up to this point, you could go with whatever server-side technology your heart desires.  But, since I am a .NET guy, it’s time to bring it home.

I am working with Visual Studio 2008, so that is the IDE I will be basing this talk around.  The plan is to take the static HTML page that we created in Part 3 and create a Master Page out of it.  Then, we will create a ASP.NET Server Control out of the container we created, so we can just drop the container control on the page wherever we want to use it.

Create the Project

For starters, you’ll want to create a new ASP.NET Web Application, giving it whatever name you want (I used MySweetWebApp).  You’ll want it as part of a solution, to enable clean separation when you actually start building out the functionality and guts of your web app.  Once you have the app created in Visual Studio, you will see a single file, Default.aspx.  That file will be of use to us later, so just leave it alone for now.  The first thing that we need to do is bring over the image files and css files that we used for the static page.  So, just copy those from their original location and drop them into the root folder of the web app.  Note that the root folder of the web app is likely a sub-folder of the solution itself, if you just went with the defaults that Visual Studio offers when you created your project.

Before you are able to see the files you just copied over in the Solution Explorer, you have to add them to the project.  To do this, right click on your web app project and choose Add > Existing Item…  This will open a file dialog to select the css files and the images folder.  Select them and click Add.

Now that the files are there, we will start adding our pieces, beginning with the Master Page.  Go ahead and find your web app project in the Solution Explorer (mine is called MySweetWebApp.csproj), right click on it and go to Add > New Item…  Once the Add New Item dialog is showing, click on the Web Category, to filter out the stuff we don’t need.  On the right, you should see an option for Master Page.  Click on the Master Page option and give it a name of your choosing (I will be using SweetMaster.Master).  Once you have added your Master Page, you will see that it looks something like this:

For the most part, it looks like a standard HTML page.  A few notable exceptions are the <%@ Master Language=”C#” … %> definition at the top and the tags in the and .  The first one is the server-side code that defines the page as a Master Page, this is required for it to function as a Master Page.  The second are ASP.NET server controls, specifically ContentPlaceHolder controls.  Those define where you can place variable stuff, the stuff that each page will define for itself.  Essentially, everything else defined in the Master Page will be exactly the same for every page that uses that Master.  It’s the ContentPlaceHolder controls that will give each page the capability of defining new elements.  With that in mind, it’s time to start modifying the Master Page to make it ours.

Flesh out the Master Page

Let’s start in the header.  Our original static page has the style sheets included in the header, so let’s bring those in.  There will be a slight modification, though, to make sure that the correct path is always used:

There are two differences to take note of here.  The first is the href attribute has ~/ added to the beginning.  The second is the addition of the runat=”server” attribute.  Those two attributes work together with ASP.NET to ensure that the file paths are injected on the server side and they are always relative to the root of the web app file structure.  Adding those two lines makes your Master Page header look like this:

Visual Studio added id attributes to both of my CSS links, but that doesn’t really affect us.  Note that by having the ContentPlaceHolder server control in the header, it gives pages that use this Master Page a chance to include other links into the header on an individual basis.

Now, for the body.  We’ll want to keep the ContentPlaceHolder control in the body as well, but we’ll want to move it into the middle of our markup.  So, you can do the fudging if you like, but I’ll just give you the code to make it happen:

Note that the only real difference between the static HTML body code and the code we are using for the Master Page is the addition of a <form> element and the ContentPlaceHolder control.  The <form> element allows ASP.NET to do postbacks, which some ASP.NET controls require.  The ContentPlaceHolder control is added to our content div, which his where the main content of the page is intended to go.

Another quick note…  The menu portion will be static in our case, so you will need to add links that you want to show up here by hand, as you add more pages to your website.  You will most likely want to convert to using the ASP.NET Menu control to make things easier going forward, but that control requires some background that I will not be going into with this post.

One more quick addition we will be adding is another ContentPlaceHolder control as the last element in the to give us a place to put any javascript includes that individual pages may require:

With that, our complete Master Page looks like this:

Now that we have our Master Page set up, let’s go back to our Default.aspx page and put it to use.  At the top of Default.aspx, add the attribute MasterPageFile="~/SweetMaster.Master" to the Page definition.  Then, you can delete the rest of the contents of the page and put in your Content controls (which match up to the ContentPlaceHolder controls we added to the Master Page):

If you run the web app now, you should see our page come to life with no content.  Play around with that page a little by added something to the ContentPlaceHolder1 control.  You should see the page change as you do that.  Next we will create a control for our container to give our content a place to hang out.

Our first Server Control: The Container

In the Solution Explorer, right click on the web app and choose Add > New Item…  Select the Web category and choose ASP.NET Server Control, giving it a name of your choosing (I’m using SweetContainer.cs).  You will see that it defines a class for you that derives from WebControl.  Visual Studio automagically adds a property called Text to show you how it is done.  That property is useful to us, but needs to be renamed to Title.  That gives us the following code:

There are three methods that you can override, which are of importance to us here: RenderContents (as shown above), RenderBeginTag, and RenderEndTagRenderContents will allow you to define what will be rendered for the guts of the control.  In our case, we want to be able to drop the control on a page (or even another control) and add content to it using markup.  So, the RenderContents function isn’t of much use to us here and can be removed.  RenderBeginTag and RenderEndTag do what their name suggests, render the beginning and ending of the control.  Those are the functions that matter the most for us.

RenderBeginTag will be where we put the code for rendering out the title and tags before the content and RenderEndTag will be where we put the code for rendering the tags after the content.  Also, to enable us to add markup to the content of the container, we need to set some class attributes: ParseChildren and PersistChildren.  So, here is the code for the container control:

You’ll notice that ParseChildren and PersistChildren are both added as class attributes.  You’ll also notice that RenderBeginTag and RenderEndTag are both fleshed out by outputting the tags required before the content and after the content as well as adding the title of the container.  Now we have a control that can just be dropped in wherever we want a container, without having to copy all the junk that comes along with it every time.  To use it, the page (or control) needs to register the control:

The control needs to be added with the prefix defined by that registration (in this case the prefix is cc1):

You’ll note that I added a paragraph for the content of the container.  If you want to use the Visual Studio designer, you can see that your control is added to the top of the tool box, when in design view.  Just drag it onto the page where you want it, setting the title if you want.  Sweet huh?


This time around we talked about taking your static HTML page Part 3 and bringing it into ASP.NET.  We created a web application for it and the Master Page to define it.  Then we created a custom server control to use for the container, saving time and effort for the future.

Now we are sitting comfortably in .NET land again (or uncomfortably, depending on your perspective, I guess).  You can use this web app foundation to go forth and multiply!  Or something like that…  Happy coding!


Building a Website From Scratch | Part 3 – Stand It Up

In Part 1 of the Building a Website Series, we talked about taking a graphic design and prepping it for the web by slicing it up.  In Part 2, we dove into a crash course on CSS to prep you for actually coding the website.  In this part, it’s time to take what we’ve done/learned so far and make something useful out of it.  Are you ready for this action?  Hope so…


For starters, we need just some simple markup:

That is the foundation of a web page.  You’ve got your DOCTYPE definition (we’ll go with XHTML 1.0 Transitional), you’ve got your (the root of all the content), you’ve got your (where we will put our CSS includes) and (which defines what the browsers will display as the page’s title), and you’ve got your <body> (where all the visible elements go).

Go ahead and save that markup with a filename of your choosing, ending with .htm or .html.  I’ll be using SweetDesign.html.  Next, we need to get our external css file created.  For that you can just create an empty file with a name of your choosing that ends in .css.  I’ll be using SweetStyle.css.  These can be in the same directory, if you like.  On bigger projects, you’ll probably want to put the css in it’s own sub-folder, but that isn’t a big deal here.

Now that you have the css file created, you’ll need to link it into the html file.  You do that by modifying the <head> as follows:

What we have done here is tell the browser to load the file SweetStyle.css and use it as the stylesheet definition.  Before we go any further, we also want to include a reset stylesheet.  Why?  Because every browser adds default styling to elements and that styling may differ across browsers.  If we include a reset stylesheet, that eliminates all the default styles and puts us on the right track for cross-browser compatibility.  We’ll use the one defined on Eric Meyer’s Blog:

Go ahead and copy that into a file called reset.css, right next to your other css file.  With that we will need to further tweak our <head> as follows:

Notice that I have added the include for reset.css *BEFORE* the original css file include.  That is very important because we want the reset file to be applied first, clearing the default styles for all browsers.  Then our styles can be applied, trumping the reset styles that we want to change.

Now that we have the style sheet and html foundation in place, make sure to copy your sliced images from Part 1 into a subdirectory of your choosing.  Then we can start using the images on the page.

Time to Rock

Before we go any further, a quick disclaimer…  My goal here is to help you get your feet wet by creating your first table-free (or maybe just first) web page.  I don’t want to overwhelm you with complex details, so don’t assume that this approach is the only way to mark up a page.  I will try to keep the markup as clean and simple as possible, but there will definitely be room for improvement once you start to understand the concepts.  I will leave it as an exercise for you to make those improvements.

Now that we have the foundation in place, it’s time to do this thing.  Take a look at the graphic design from Part 1.  You will notice that there distinct vertical sections (rows, if you will).  One is the blue bar at the top, including the logo.  The next is the menu bar.  Finally, there is the gray body section.  Those sections are there for a reason, and I will now show you that reason.  To get the markup of our design started, we will modify the <body> tag as follows:

Notice that I have added one div tag, with the id layout, containing three <div> tags to the, each with an id (header, body, footer).  These tags will make up the logical sections of the page.  From this foundation, we will further elaborate to make the page begin to take shape.  layout will define the styles for sizing for the whole design and the other tags will define elements for their own individual sections.

We’ll throw down some foundation styles to get the ball rolling:

This sets up the background color and gradient as well as the width and positioning of the actual layout.  Now, it’s time to drill down a bit.


Let’s start with the top and work our way down, shall we?  The header is pretty straight-forward in this case.  Still, we will need to elaborate on our foundation a bit to make it happen.  Modify your header tag as follows:

Note that I am using compass directions, W for west (left) and E for east (right), to signify the elements location.  Now, let’s add some style to those tags and see if we can pull this thing together.  Go back into your style sheet (mine is SweetStyle.css) and add the following:

Now, if you view the page in a browser, you should see just the blue header and the gradient background.  If so, you are in good shape.  If not, check your image reference.  Recall that the path defined in the url(…) is relative to the location of the css file that it is defined.

Now lets add a little polish to the left side of the header:

That defines a width and a height, so the image fits perfectly in where it is supposed to go, then it floats it to the left side of the header.  Viewing the page now, you should see a nice rounding out of the bottom left of the header.  Let’s do the same thing for the right side:

This is basically doing the same thing as the left side, but for the right.  Right?  Viewing your page again should show a nice rounding out of both bottom corners of the header.

Let’s round out the header by adding the style for the logo:

This positions the logo absolutely within the header, so that it goes exactly where we want it.  There we have it: header == done.


The next stop in our tour is the body of the layout.  Go ahead and modify the body div as follows:

And add this to your style sheet:

A little explanation here, the body div will be the container for the menu and the actual content.  This is because these are the two things that can actually vary once the design is in place.  So, we have a parent <div> for both of them and add a new <div> for both the menu and the the content.  The menu is where we will put the navigational menu, so let’s start there.  Elaborate on that tag as follows:

That sets up the left and right finishing to the menu, just like in the header, as well as starts an unordered list with links for the actual menu items.  Now apply the following style to your style sheet:

That sets up the background for the menu and both of it’s sides.  It also sets up the styling for the unordered list items by floating them to the left so they play well with our horizontal menu.

For the actual hyperlinks (anchor tags) in the menu, add the following:

That gets us set up with some initial state for the menu links as well a state for when the mouse is hovering over a link.  Notice that there is a margin of 1px on the initial state and the margin is removed on the hover state, BUT a 1px border is added to the hover state.  That is because borders are added to the *outside* of the element.  Since there is no border on the initial state, we need to add a margin (padding would work in this case also) so that we don’t have any bizarre jumping things happening from borders being added and making the link elements bigger when the mouse is over it.  To see what we are trying to avoid, comment out the margin in the initial state, reload the page, then mouse over a link.  You should notice that it the text jumps a pixel.

That wraps up our menu.  Now, any content we add to the page will go inside the content div.  We’ll gloss over that for the moment and come back to is shortly.  Let’s finish up the layout with some quick additions to the footer.  Add this to your html:

And add this to your stylesheet:

We just added a simple footer that has some text (or links) of your choosing at the bottom of the page.  The footer will get pushed down to make room for whatever content you add to the page.


Now, lets get back to the content of the page.  In our awesome design, there is a container for each section of content to reside in.  It gives the content definite separation.  So, let’s get that bad boy standing up as well!

This is going to look like a lot, but go ahead and add this markup to your content div:

Let’s start from the outside and work our way in…  The class box is the outermost element for the whole container.  From there, we have three logical rows: the header, the content, and the footer.  The header has the classes boxN* (Note that the use of the compass notation again), the footer has the classes boxS* and the content has the remaining ones.  If you look at each logical row, you will see the usual definitions for left, right, and center.  Note that there is a div at the bottom with the class clearboth.  That is a simple way to make sure that the content element contains all the containers the page may have by clearing all floats.  That should stay at the bottom and any additional containers will be added above it.  Now add the following to your stylesheet:

That’s a lot of css, but each definition is pretty simple if you look at them closely.  The key point to take note of here is that the elements on the left and right have their background images starting in various locations and repeating in various ways.  That is what makes this container look correct.

Now that you’ve got your container set up, copy that markup and drop a few of them in the content element.  You’ll notice a three column layout, which is a pretty good place to start.


This post was a doozy!  There was a lot of info to cover here, but none of it is too complex.  If you take each part as a section, you’ll see that things break down into manageable parts.

We covered the initial markup required for a html page and how to include your external stylesheets.  Then we covered how to break the layout down into logical parts to tackle individually, starting from the top and working your way down the page.  Then we covered how to create your containers to give your content a way to have separation.

I hope that this has proven useful for you get get your graphic design translated into a real web page.  You can use this spankin’ new web page as your template (or master page) for all the pages in your website.  Other things that you can do from there include using Javascript and Ajax to make the navigation animated, smooth and flicker-free.  But, that is a topic for another conversation!

Get the code for my design here


Building a Website From Scratch | Part 2 – Get Some Style

This is the second of a series of posts I will be doing on building a website from scratch.  In the first post we covered how to slice a graphic design to prep it for conversion to a web layout.  This installment will be more of a preparation for the work to come, rather than an example of what to do.  I will be giving a crash course on a little something I like to call Cascading Style Sheets (CSS for short).  Like most aspects of web development, CSS is a large topic in and of itself.  So, I will be just giving enough of a taste of it to learn what we will need to build our website.  So let’s get to it!

What is CSS?

That is a great question, thanks for asking…  Cascading style sheets (CSS) is a way of defining positioning, look and feel of HTML elements.  Using CSS, you, the developer, can make a broad definition that says, "Gee, I really want all the <h1> elements on the page to be extra big and bold."  Of course, CSS is much more succinct than that, saying the same thing with this:

If you’ve ever looked at a website before, and I’m going to take a completely random guess that you have, you’ve seen CSS in action.  CSS, when done right, defines how everything on a page will look.

What’s with the ‘Cascading’?

With a name like ‘Cascading Style Sheets’, there must be some significance to the word ‘Cascading’, right?  Well, of course there is.  Man, you have some great questions today.  When a CSS style is defined, it can apply to more than just the specific element you are targeting.  In essence, the style ‘cascades’ down to anything that is contained within the element you are targeting.  At first glance, that may seem lame.  I assure you that it is not.  How about an example.  Let’s say that we want to make all paragraph text 12 pixels tall.  We do that by saying this:

Now, within our paragraphs, we have hyperlinks that we also want to have 12 pixels tall.  That’s where the cascading part comes in.  Let’s say our HTML markup looks like this:

This structure has a <p> tag as the outer element, with an tag within it.  With our style applied to the <p> tag, that means anything within the <p> tag will also have a font-size of 12px.  (Well, that is not totally true, but we will get to that shortly.  For now, assume that it is true.)  So, by applying a style to the <p> tag, everything within it gets the same style applied, ensuring uniformity.  Are you starting to see the power?  We can quickly apply styles and shape the look of a site with broad strokes.

Where do I put these ‘style’ things?

CSS can be defined in several ways: inline on an element, in an internal style sheet, or in an external style sheet.  Each of these definitions look pretty much the same at the style level.  What really separates them is their scope.

An inline definition on an element is only good for that particular element.  It looks like this:

This is usually something you’ll want to try to avoid using, for a few reasons.  The most obvious being that it would be way too much work to style a website one piece at a time.  The lesser obvious reason is that at some point down the road you may want to change the way your site looks.  Ouch.  Every element now needs to be changed.  Finally, and possibly most importantly (depending on your point of view), using the inline element style marries your markup with your presentation.  Not a good thing.  Any good developer understands the need for ‘separation of concerns’.  When you use an inline element style, you take your clean markup, which contains your content, and make a sloppy mess out of it.  It makes the code more difficult to read because there is all this extra stuff added to every tag.  Of course, inline style elements don’t have to be used on every element, but I think you get the point.  I have, however, found a good use for inline element styles: quick and dirty layout tweaks.  Sometimes you find yourself needing to make temporary changes or changes that you aren’t sure if you will use long-term.  Bam!  Inline element styles to the rescue.  Put your change to the test and see if it is worthy of living on.  Then, remove the inline style and place the style definition into one of the other options.

The internal style sheet has a slightly more broad scope: a single page.  One of those bad boys looks like this:

Notice that it is placed within the <head> of the page.  I have only shown one element defined in the example, but you can have as many as your heart desires.  The difference between the internal style sheet and the inline element style is that the internal style sheet applies to all elements on the page.  With the example above, we have defined all contents of <p> tags to have a font-size of 12px and a normal font-weight.  Since we are defining things a whole page at a time, this is a little more useful than the inline element style, but is still limited as a whole.  We can still have the clean separation of markup and presentation using internal style sheets, but they are still hard-coded into the page.  Thus, putting a new face on your site is still a fairly tedious task.  These guys still have their place, however.  I have found that they are most useful for browser-specific hacks (which is outside the scope of this discussion).

The external style sheet is where you’ll probably want to play the most.  An external style sheet is an external file with the extension .css, containing all the style definitions for the entire site.  Here’s an example of a style definition in an external style sheet:

Notice how the style definition itself looks exactly like the internal style sheet, but there are no other tags involved.  That’s due to the fact that the external style sheet is an entirely separate file.  To get it into your site, you have to include it at the top of every page that it applies to like so:

Notice how the include is located within the head of the document.  Inside that , you can also define an attribute for ‘media’, which is really cool.  What that does is give you the ability to have completely different style sheets for different media types, like screen or print.  You can also include more than one style sheet, if you like, giving you the ability to separate your style definitions into logical groups.

The external style sheet is really where you should put your style definitions.  Using the external style sheet gives you the power to define, in one single location, the look and feel for an entire website.  It also gives you the power to completely change the look and feel of a website by simply including a different style sheet.  A great example of that is CSS Zen Garden, where you can see the same exact markup completely transformed by simple swapping out style sheets.

Cascading – Revisited

Now that you have learned about the three different ways to define style, you might suddenly have images of multiple style definitions for a single element type.  Not to worry, that’s where the cascading comes back into the picture.  Let’s say we have an external style sheet that defines the style for <p> like so:

And, let’s also say that there is an internal style sheet that defines the style for <p> like so:

What happens now?  There you go with the great questions again!  The answer is that the internal style sheet definition is used.  Here’s why: proximity rules the day.  Here, proximity is more of a conceptual thing, rather than a physical thing.  Basically, whatever is closer to the element wins.  The external style sheet is the ‘furthest’ away because it is potentially site wide.  The internal style sheet is the ‘middle man’ because it is at the page level, ‘closer’ than the external style sheet, but ‘farther’ than the inline element style.  And, in case you didn’t guess it, the inline element style is the ‘closest’.

You see, with the cascading part of cascading style sheets, a definition cascades down to all affected elements until it is overridden by another closer or more specific definition.  The cool part about that is that you can make some broad definitions such as:

This style will apply to everything within the <body> tag (basically everything visible on the page).  The you can add a more specific definition such as:

Now, anything inside a <p> tag will have a font-size of 14 px and a normal font-weight.  At least, it will unless it is further overridden.


We’ve already dabbled in the topic of selectors, with our examples of ‘p’ and ‘body’.  As the name implies, this is what you use to select things to style.  There are three basic ways to select an element: by element type, by class, and by element id.

Selecting by element type is what we have already seen.  Basically, you just start the line with the type of element you want to select:

You can further elaborate on this by getting attributes involved as well:

The previous example selects all elements that are <input type="button">.  Consider the element selector to be the broad stroke to start painting on the canvas.  You lay the foundation and then move on to some detail.

The class selector is where you can start getting a little more detailed.  Actually, you can be as detailed as you want with it.  It requires involvement on the markup side as well.  First, the markup:

Next, the style:

Notice how the selector begins with a dot.  That is how classes are selected.  In the previous example, we selected a class of "container".  It doesn’t matter what element type has that class, it could be a <div>, a <span> or a <p>, they all would get selected.  Unless we do a combination:

What that is selecting is all <div>s that have the class "container".  In fact, say we have both of those styles together in our sheet like so:

What this is saying is all elements with the class "container" will have the given background, height, and width.  But, only <div> tags that have the class "container" will also have the given color.

We can also apply multiple classes to the same element:

This would apply the styles defined in both the "container" class and the "bold" class.  If there is any overlap, the last class wins ("bold" in this case).

The last basic selector is the id selector:

With the selector:

Notice the difference between the class selector (.container) and the id selector (#key). Where the class starts with a dot, the id starts with a pound sign (#).  Since an id can only be used once per page, the id selector is good for using in laying out the site’s design framework.  Elements that serve a single purpose can be given an id and styled accordingly.  Elements that can show up repeatedly can be given a class.  Plus, we can use them in combination like we did with the element and class selectors.

With the selector:

This works great when you start dynamically messing with classes using javascript because you can define the basic styles on the id and have some styles change based on the class it has:

Notice how the width and height never changes, but the color changes depending on whether the class "bold" or the class "mellow" is applied.

The last thing I want to talk about before letting you take a rest is child selectors.  Child selectors are when you use combinations of the basic three selectors in a particular order.  Say we have the following markup:

You may find yourself wanting to give special styles to only those elements inside the "container" class.  Well, never fear, child selectors are here!  Here’s how you accomplish it:

You first start with the outer element, class or id, then add a space and put the inner element, class or id.  That basically says, all <h1> elements inside an element with the class "container" act a special way and all <p> elements inside an element with the class "container" act an equally special (but different) way.  You don’t have to stop there, you can go as deep as you like:

With the style:

Are you starting to see the power?  I hope so, because I’m about out of breath here.


I’ve barely scratched the surface here with cascading style sheets.  Hopefully I’ve given you enough of an understanding to be able to begin applying it to our website as we move forward to the next steps.  I told you how CSS is defined, what it does and how to control what it does.  To learn more you can start with W3 Schools.  For some more advanced topics, A List Apart is a fantastic blog.  As we move through this blog series, you will be exposed to more and more CSS.  You’ll see plenty of examples of selecting elements as well as properties that can be used.  See you next time!


Building a Website From Scratch | Part 1 – Slice and Dice

Building a website is a complex endeaver.  It requires a pretty broad skillset that doesn’t come without practice.  To really do it right, you need to have a good eye for graphic design, have a firm understanding of how to structure the files into a coherent sitemap, and have the ability to read and write code in several different flavors.  And that’s just for starters.  Websites can be as simple as a single, static page or as complex as a full-blown, data driven, ajaxified web application.  It’s really up to you and the needs of whoever the site is for, if it’s not for you.

My goal here is to give you the tools you need start with a twinkle in your eye and finish with a solid, interactive website.  Since I’m not a graphic artist, I’m going to leave the graphic design work up to you.  We will start by assuming that you have already created the sweetest design the world has ever known…  From that point, we can start getting into developer land by taking that graphic design and translating it into a web page.  From there we will further elaborate on it until we arrive at a respectable finished product.

To illustrate what we will be doing, I’ve designed what could possibly be one of the worst looking website designs I’ve ever encountered.  Well, I’ve actually seen worse, but this one is pretty bad.  Don’t believe me?

I did this so I wouldn’t have to worry that anyone steals my design and make millions with it.  What this design does have is all the pieces we will need to help you learn how to do the make a website out of your design.

Let’s do this!

The first step is to take your spankin’ new graphic design and cut it all to pieces.  You see, when someone visits your website, they have to wait for every single byte of data that your site has to download before they can see it in it’s entirety.  Since the goal is to minimize download time, we need to minimize the amount of data that they will have to download.  A good website design keeps things stream-lined.  What I mean by that, is it is designed in such a way that the design can be cut into much smaller pieces and assembled to give the illusion of one whole piece.

To help make this a little more clear, let’s look at my graphic design:

If you look at the top of the design, you can see the light blue title bar that spans across the top with a logo on it’s left side.  Below that, there is the menu bar with the main content area taking up the rest of the space.  Each of these three important parts is designed with a specific goal in mind: to be repeatable.  Look again and you will see what I mean.  Ignore the logo for a moment.  The light blue title bar has the bottom two corners rounded and the rest of the space is taken up by a repeating design.  What we can do to make that more efficient to download, is to slice it into three parts: the left side, the right side, and a one-pixel wide sliver that we will repeat across the remaining width of the header.  When I say slice, I mean to take the original design and pull out the three parts that I mentioned into individual images, leaving three separate images (slices) created from the one big one.

The details of how you actually slice up your design are up to you, probably dictated by what application you are working with.  I use Photoshop, but that’s me.  However you do it, I’ve found the easiest whay to slice properly is to zoom way in and make sure that you are grabbing the right size slice.  Too small of a slice and you will be able to notice a definite separation between your side graphics and the repeatable zones.  Too big of a slice is just a waste of data to have to download.  If you don’t get it right the first time, don’t worry too much about it.  You’ll notice soon enough whether your slices blend well together or not.  If they don’t, just make the necessary adjustments to the sliced images and adjust the code accordingly.

There are some things that you should keep in mind when slicing up your design.  You’ll need to decide how the pieces will fit back together again.  With my design, I plan on making four conceptual blocks that will stack on top of each other: the header on the top, the menu bar in the middle,  the body underneath the menu bar and a footer on the bottom.  Knowing this will help me decide how to slice the pieces up.  For the header and the menu bar, the combined slices will each make up a uniform row.  So, I want each slice in a row to be the same height, allowing the whole row will be the same height.   When I get the bare header in place, I plan on positioning the logo in front of it.  So, the logo will have to be sliced on it’s own.

Since the goal is to minimize the amount of image data to download, you’ll want to remove as much text from the graphic design as you are reasonably able to before slicing it up.  With the design we are working with, the only text that will be incorporated into the images is the text that is on the logo.  That is because that text has special effects applied to it that are not possible to display without keeping it in the image.  The rest of the text that you see on the design will be incorporated as part of the html markup that each page will serve.

When all things are said and done, you might be surprised at how little of the overall design you actually need to use to make the web layout complete.  Here’s a representation of the slices I will be using for this series:

Before we go any further, a quick note about transparent .png files.  As you may know, .png files support transparency.  That’s really cool and all, but here’s something you maybe didn’t know: Internet Explorer 6 doesn’t support transparency.  You may be asking: so what?  Well, I guess it is up to you whether you worry about IE6 users or not.  There are still a lot of them out there, even with IE7 pushed down with automatic Windows updates.  My opinion is that it’s about time for them to upgrade to the latest version of IE or, better yet, Firefox.  They are both free and are helping move the future of web development in the right direction.  That being said, I still usually avoid transparent images as much as I am able to, without compromising the design.  In places where the background is unchanging, just leave the background in there rather than having a transparent background and avoid the possiblity of a poorly rendered view provided by IE6.

Well, I think that’s about all I need to say about the slicing phase.  I talked about how the original design will need to be broken up, or sliced, into several smaller pieces to minimized the amout of image data that will need to be downloaded to view your site.  I talked about looking for repeatable zones as a way of streamlining the download process.  I also mentioned that text should be removed from the images whenever possible and added to the html markup.  I even made you aware of the pitfalls of working with .png images with transparency.  It is your homework to take your killer design and slice it up to prepare it for it’s web debut.  In the next part of this series, we will talk about some of the principles that you will need to take those sliced images and run with them.

Here’s the sliced images from my design if you want to play along without creating your own: