My topic was Design Patterns in SharePoint, which is an introduction to the concept of design patterns, and how to apply them to your SharePoint environment.  Luck you, we have been recording these webinars, and they’re freely available on our website. Feel free to view the webinar video below, and check out the webinar archive for any and all webinars that we’ve recorded in the past.

As mentioned in the video, I will be teaching a SharePoint design class in the Netherlands starting on March 22.  If you are looking for design training and can make it to the class, please feel free to sign up.

Watch this video on YouTube.

With most developers, I’ve found that there can be a disconnect between how I understand websites, and how they’ve come to understand them. Not just a disconnect: The Disconnect. If you work in a team environment, you know the feeling. I say “element,” and you say “control.” I say “script,” and you say “method.” Most developers are ultimately, completely, and entirely focused on the server-side application.

That’s okay. I need my developers, and they need me. It’s a good relationship for all of us, with our complimentary skills, tools, and techniques. They make it work, and I make it look good.

How to Connect

Overcoming the Disconnect is all about education, on both sides of the fence. Developers and designers alike would benefit from understanding how the technology that they use comes together. The grand finale of everything that we do online ends up in a single place, where it can be seen, read, clicked, and tested: the browser window.

As a designer, that’s where my beautiful designs will end up, and they somehow need to be translated from Photoshop into HTML and CSS that works well with the server-side application. Good designers understand the technology before they create the designs. Likewise, as developers, the controls and methods that you create are all somehow translated into HTML, whether you’ve recognized that or not. Understanding the output of what you do in the application is just as important as making the application work.

Don’t Forget the Browser

This is where it all ends up. Everything that we do as designers, developers, project managers, or architects: it all comes together in the browser window. The browser is the tool that is used to present all of your hard work, everything that you’ve done throughout an entire project. With so much responsibility resting upon the shoulders of the browser, why is it that so many people ignore it completely?

Back in The Day, the browser is all there was. In 1989, Tim Berners-Lee created the world’s first web server. When requested, it served up documents to be viewed inside the very first web browser. These documents were pure HTML, and the browser interpreted that language in order to create Hyper-Text documents that could be linked together. As you probably know, this simple concept caught on, and by the mid 1990′s, the Internet had become arguably the most influential product of Man in the 20th century.

Everyone that works in the industry of the world wide web should pay their respects to the oft-neglected browser. It has so much power, and it is the tool that allows us to do what we do. The browser is everything. The W3C and WHATWG can make all the recommendations they want: nothing really happens until browsers support it. In the mid 2000′s, the W3C started working on a recommendation called XHTML 2.0. It failed. The browser manufacturers didn’t like it, and that’s why we’re now working with HTML5 instead of XHTML2. Similarly, Microsoft created something called the XMLHTTPRequest in the early- to mid-2000′s, and everyone loved it. The major browsers quickly adopted this technology, and AJAX was born.

The point is, the browser truly has the power in web application development. It doesn’t matter if you’re a programmer or a designer: you need to understand how technology works inside the confines of this little window. In all the amazing technology that surrounds the Internet, it’s really based on a few simple languages: HTML, CSS, and JavaScript.

Making Requests

Web browsers are fairly simple applications. In essence, they do two things: make requests, and handle responses. A request might be something like “show me the document at KyleSchaeffer.com,” or “give me the image at /images/kittens.jpg.” The server that you’re requesting from then responds and the browser does something with the response. It all sounds very simple, but it’s so easy to forget this fundamental layer of web technology. I’ve helped troubleshoot dozens of web applications, and my first question is always “What request is the browser making?”

This entire process is called an HTTP request. HTTP requests are sent by your browser every time you type something into the address bar. The first requests is almost always an HTML document, and then the browser subsequently makes additional requests for things like CSS files, JavaScript, and images. Even if your web application is running on PHP or ASP.NET or SharePoint, the server is returning an HTML document, which subsequently loads additional resources. Simple, right?

1. The Request

Every HTTP request has a URI, or Uniform Resource Identifier. That’s a fancy way of saying the address of the resource you’re requesting. The address can be both absolute (http://kyleschaeffer.com/images/kittens.jpg) or relative (/images/kittens.jpg). The browser sends this request to the “Internet,” which routes the request to the appropriate server, somewhere out there. The browser then waits for a response.

2. The Response

After sending a request, the server that you requested the document from will send back a response. Again, the browser handles the responses, and each resource that is requested is handled differently. First of all, the browser reads the HTTP response code, which is an indication of the status of your request. The most common HTTP response codes are:

1. 200 OK - The most common response; the resource you requested was found
2. 301 Moved Permanently - The resources has moved, and the browser will redirect the request to the new location
3. 304 Not Modified - The resource was found, and your browser already has the most recent version in the browser cache (yay!)
4. 401 Unauthorized - You need to sign in to see this resource
5. 403 Forbidden - You’re not allowed to see this
6. 404 Not Found - The resource you requested does not exist
7. 408 Request Time-Out - That took too long, sorry
8. 500 Internal Server Error - Something went wrong!

My descriptions of each response are less than technical, but you get the idea. If you’ve ever wondered what the “404″ in “404 Not Found” meant, it’s the HTTP response code for “not found.” For a more comprehensive list of HTTP response codes, visit the W3C’s documentation.

Another important element of the HTTP response is the Content Type. This tells your browser how to handle the requested resource when it’s downloaded. Unlike on your computer, your browser does not decide how to use a resource based on it’s file extension! It’s all about the content type. Some of the more clever server-side programmers can actually utilize this element of the HTTP response to create server-side scripts that actually disguise themselves as other types of content (like a PHP script pretending to be JSON or XML).

3. Execution

At this point, the browser now knows the HTTP response code, and the resource content type. Using this information, it’s time to make something happen. The browser downloads the resource, and presents it inside the browser window. Browsers can sometimes handle resource requests differently, so this is where you get into the nuances of browser testing. One browser might handle HTML and CSS requests slightly different from another, so testing your applications is merely a practice of testing how these HTTP responses are handled.

From “Developer” to “Designer”

Bridging the divide between developers and designers is all about understanding how the different technologies of the web come together. The browser window is the one place where the user experience, the architecture, the design, the program, the database, and everything else that goes on behind the scenes comes to fruition and is finally presented. Clients pay for you to meet needs and requirements, but what they ultimately expect is something that appears inside the little box that they call the Internet. Embrace it, learn it, love it, know it inside and out, and you’ll find that disconnecting from The Disconnect is not so difficult after all.

Update 8/17/2011: The “Medazio” theme can now be downloaded directly from SusQtech.com/medazio.

The Video

While building the Medazio theme, I recorded over 11 hours of video in order to document the entire SharePoint design and customization process. From creative sketching to design in Photoshop to actual coding of CSS and HTML in SharePoint Designer 2010, you can see the entire project from start to finish, compressed into about five minutes of rapid SharePoint Design fury. Check out the video, download the theme, and see first-hand how SharePoint is truly a viable and impressive publishing platform for your design-savvy projects.

Watch SharePoint Design in Five Minutes on Vimeo.

The days of the desktop are numbered. In the past, designing a web interface involved targeting a screen resolution in the vicinity of 960 pixels wide. For many years, this worked, and it worked well, because 99% of online users could easily read and scroll at that resolution, regardless of the browser, operating system, or machine they were using. Times have changed.

The supreme rule of desktop design began to wane in the past couple of years. With the explosion of the mobile browser phenomenon (largely due to devices like the iPhone, Blackberry, and the Android operating system), online traffic began to show the first signs of diversification. With increasing numbers of users on these mobile devices, the distinction between mobile and desktop content was born. As you most likely have noticed, many online publishers have chosen to neatly dissect their content into two distinct applications that serve two distinct types of devices. You have “mobile” versions of many websites available today, which often offer similar or identical content to what can be found on the desktop version of that same website. Very simply, the web server detects the device that’s requesting the content, and serves up a different document (or redirects to a different location) depending on the device being used.

Today, this dichotomy between mobile and desktop content persists as the most popular strategy for serving up web content to a multitude of devices. The technical implementation of this strategy differs from site to site, but the end result is the same: a design and layout that targets a single device or resolution. This has been a great approach for many online publishers because it offers so much flexibility in the appearance of mobile content. By segregating a design into two entirely different implementations, the limits to what can be done on a mobile site are nearly limitless. As with every design, however, there are disadvantages to this approach that cannot be overlooked:

• Increased effort – it is more difficult to create and maintain two separate design layouts simultaneously.
• Publishing concerns – creating a division between mobile and desktop content begs the question: where does the content come from? Should all desktop content be available on the mobile site? Do you publish everything twice (once for desktop, once for mobile users), or do you dual-publish to both mediums simultaneously?
• Planning for diversification – is “mobile vs. desktop” really good enough?

The last disadvantage listed here is perhaps the most important point to consider. Recent history has shown that targeting a single device (i.e. the desktop) did not withstand the test of time. Is the simple distinction between “mobile” and “desktop” content really good enough?

Mobile is important, but not end-all.

The truth of the matter is that mobile devices are taking off. According to Mary Meeker of Morgan Stanley, the sale of “smartphones” is expected to overtake PC sales (both desktops and notebooks) by next year. Browsing statistics are showing this trend as well. StatCounter shows that about 6.5% of all users in North America are browsing on mobile devices. You can count on about one in twenty users experiencing your online content on a three inch screen – how does your content stack up in this scenario? If you haven’t thought about it yet, it’s time to start.

The growth of the smartphone landscape and the diversification of browsing statistics are the driving factor behind the explosion of mobile-friendly site design. Today, this practice is entirely acceptable, but don’t count on anything in this industry to stick for more than a few years. Mobile devices aren’t the only new kids on the block.

Enter the tablet.

Tablet devices like the iPad and similar devices that utilize the Android operating system have been somewhat of a curveball in the industry of web design. They’re not quite mobile devices, and they’re not quite desktops, but rather somewhere in between. In the current design landscape, where everything has been neatly divided between mobile and desktop content, many designers are choosing to place tablets into the “mobile” category, serving up tablet content in like kind. This does not always go over well with tablet users, who justifiably feel that the tablet offers unique advantages of a desktop computer, namely a better browsing experience than what can be had on a smaller mobile device.

What, then, do we do with these users?

Responsive Web Design

The ongoing problem is that as designers, we’ve set our minds on this idea that a web interface is going to be displayed on a screen that is 1024 pixels wide (or larger). It’s a desktop mindset; anything smaller than 1024 is a “mobile” device and generally gets a pixel value of about 320 pixels. All devices that access our online content must adhere to one of these two layouts – there are two numbers, and nothing in between.

The trouble for web designers is that internet connectivity is rapidly spreading to a vast array of devices and products that people use every day. Someone might access your online portal from a desktop, phone, notebook, netbook, tablet, or even some consumer appliances. The Nintendo Wii, for instance, comes loaded with an Opera browser that’s quite good, and is hindered only by the fact that many televisions only have a resolution that is 480 to 720 pixels wide. At this resolution, many website layouts simply don’t provide an enjoyable user experience due to poor formatting and display on smaller screens. Furthermore, there is no end in sight. Expect this diversification of internet-ready devices to increase in the coming years, and plan to change the way you design and create layouts for the web.

The great thing is, whether you recognize it or not, this is actually a very good thing. Web layouts have been too rigid and design-centric for a long time now, and forcing designers to apply layouts to a multitude of devices will encourage them to create content that can be consumed in a variety of mediums. In the end, this translates into a better experience for the user, who doesn’t have to worry about what device they are on, what resolution they’ve chosen, or what issues they may encounter. Ethan Marcotte sums it up best in his article, “Responsive Web Design” from A List Apart:

Rather than tailoring disconnected designs to each of an ever-increasing number of web devices, we can treat them as facets of the same experience. We can design for an optimal viewing experience, but embed standards-based technologies into our designs to make them not only more flexible, but more adaptive to the media that renders them. In short, we need to practice responsive web design.

Responsive web design is creating web layouts that can adapt to a multitude of displays and devices. Using this technique, you can eliminate the need to create device-centric designs (like a “mobile” site), and allow your content to be displayed from a single source, on an unlimited number of mediums.

Techniques for Responsive Web Design

Responsive web design is not “one big thing.” It’s a collection of disciplines and techniques that you employ to ensure that your designs can appear fluidly on a multitude of display sizes. The fundamental change that you have to make to start creating responsive designs is to ask yourself with everything that you do: what happens with this content when the display shrinks? Plan for a multitude of resolutions from the very beginning. By mere acknowledgement and foresight, you’ll find that the challenge of creating a responsive layout is not so difficult to overcome.

1. Layout Width

The most important element of flexibility that must be employed in your responsive design is a fluid layout width. This is the condemning factor that breaks many designs when they are viewed on smaller display screens. Create wrapper, content, and column widths that can stretch display ideally in different resolutions. There is no “trick” to this technique, it’s merely a change in the way you create columns in your style sheets. Here’s an example:

#wrapper {
  width: 80%;
  margin: auto;
  max-width: 1200px;
}

This is a simple example of a fluid design width. Setting a max-width on your design is a good idea to salvage any formatting issues for users on very large resolution monitors.

2. Responsive Design and Column Widths

In most designs, you might be working with multiple column widths to display content in a number of different ways. In your style sheet, you could simply apply a percentage width to each column, but this technique is generally not ideal. In many cases, a sidebar column may include fixed-width elements like advertisements, menus, or text that does not necessarily adapt in any beneficial way as the width of your layout grows. Instead, you may choose to adapt only a single column as the layout width changes. This is a common layout structure that can easily be created within your existing style sheet. Consider the following example:

#wrapper {
  width: 80%;
  margin: auto;
  max-width: 1200px;
}
#column-main {
  margin-left: 200px;
}
#column-sidebar {
  width: 200px;
  float: left;
}

In this example, the “main” column will always fill the width of the layout area, and the sidebar column (in this example, on the left) will always remain exactly 200 pixels wide.

3. What about images?

A common concern when moving from a fixed-width to a fluid layout is HTML images (the <img> element). An image file, for the most part, is a fixed-size file that does not scale as your design width decreases. This results in some rather unsavory presentation bugs, like large images being drawn beyond the edge of the browser window. The solution is a simple addition to your design’s style sheet:

img {
  max-width: 100%;
} 

This simple addition causes any images in your design to display at full size by default. As the width of the design layout shrinks so that the image is too wide to display in the confines of it’s parent element, the image too, begins to shrink.

It’s worth noting that the image scaling ability of Internet Explorer is admittedly poor at best. Ethan Marcotte shares his very handy Fluid Images script to help alleviate your scalable image woes.

4. No More Zoom

Many mobile devices and tablets utilize a “zoom” feature to display content that is too large to fit on smaller display screens. This is an important utility for mobile and tablet users, but it creates a detrimental experience for users, as they have to constantly zoom in, pan, and zoom out in order to browse your web document’s content. You can disable this zooming behavior by way of a simple <meta> element in your design’s header.

<meta name="viewport" content="width=device-width, minimum-scale=1.0, maximum-scale=1.0" />

This meta element is only interpreted by a number of browsing devices (namely smartphones and tablets). You should only disable the zoom feature if it enhances users’ ability to consume content on your site. If you’ve formatted your design layout so that users don’t need to pan or zoom, the zoom feature actually impairs the user from navigating your content (which only needs to scroll vertically). If you’ve incorrectly formatted your layout, however, disabling the zoom feature will only further infuriate your users, as you are removing a very important navigation capability of the browser.

5. CSS Media Queries

The final and most powerful technique that you can employ for responsive web design is a fairly new feature of CSS technology called the media query. Very simply, CSS media queries allow you to apply changes to your site’s design based on the viewing size and capability of the device on which your content is displayed. This is an extremely powerful tool for creating responsive designs, and it has garnered support across all major mobile browsers (including Safari, Chromium, Opera, and even the forthcoming Internet Explorer Mobile [Windows Phone 7]). Here’s a simple example of using a media query in your design’s style sheet:

#wrapper {
  width: 80%;
  margin: auto;
  max-width: 1200px;
  min-width: 800px;
}
@media screen and (max-width: 800px) {
  #wrapper {
    width: 90%;
    min-width: 0;
  }
}

In this example, we use the same fluid layout as before, but we’ve added a new minimum width (800 pixels) to the style sheet. If the width of the screen drops below 800 pixels, all of the styles defined in our media query will take effect, and the wrapper will be resized to 90% of the design width (with no minimum width).

The power of media queries becomes more apparent in a layout with columns. Consider the following example:

#wrapper {
  width: 80%;
  margin: auto;
  max-width: 1200px;
  min-width: 800px;
}
#column-main {
  margin-left: 200px;
}
#column-sidebar {
  width: 200px;
  float: left;
}
@media screen and (max-width: 800px) {
  #wrapper {
    width: 90%;
    min-width: 0;
  }
  #column-main {
    margin-left: 0;
  }
  #column-sidebar {
    width: auto;
    float: none;
  }
}

In this example, when the width of the device screen drops below 800 pixels, we completely reformat the appearance of the columns in our design. Rather than displaying a fixed-width sidebar column, at 800 pixels or less, this design switches to a stacked column layout (with the sidebar displaying on top or below the main column). This preserves space on smaller screens, and provides an easy way to display multiple columns on devices that aren’t suited for column-based layouts.

The great part about media queries is that you can define multiple queries in your style sheet. You can have a design layout for desktop machines, a new layout for tablets, and yet another new layout for smaller devices like mobile phones. The number of variations is limited only by what you can do within your style sheet. Furthermore, the latest versions of desktop browsers like Firefox, Safari, Chromium, and even Internet Explorer will recognize media queries as you resize the browser window, allowing you to test your variations on the fly. If you’re using said modern browser, simply resize this window to see how my design responds to new device sizes.

Looking Forward

Responsive web design is an important next step in presentation on the web. Expect the device landscape to broaden and diversify, and expect your job as a designer to increasingly become the curator of a flexible and fluid online experience that is more focused on content and less on pixels or devices. The idea of “mobile vs. desktop” is fairly new and very strong, but the mobile distinction will likely become an element of features and convenience, rather than an element of presentation, as it is so largely viewed today.

Body text is often an after-thought in design. We have all been guilty of this at some point in our careers. When you implement your CSS, you might simply throw a body { font-family: blah, blah blah; } into the CSS, and after that you move on. You’ve probably figured out the whole base font size thing too, which can help, but there’s so much more you can do. Let’s look at a number of things to help your body type become something a bit more visually appealing and readable.

Text Color

Hopefully you’ve already figured this one out, but I dare not exclude it for the sake of accuracy. Probably the single most important thing you can do to your body text is change both the color of the text as well as the background color of the area shown behind the text. Here’s a few pointers:

• Readers generally prefer dark text on a light background. There are a few impressive exceptions to this rule, but for the most part, it’s best to stick with the old “dark on light” tried-and-true formula.
• While contrast is important, don’t take it too far. Black text (#000000) on a white background (#ffffff) is perhaps a bit too much contrast. Opting for a slightly lighter shade of text can make it easier on your readers’ eyes. If I’m working on a white background, I generally choose a font color that is at or in the general vicinity of #666666 (don’t be afraid to add a subtle hue of color too, but keep it dark).
• Add some variety by slightly changing the color of elements in your body text like darker <strong> text or lighter <li> items. You don’t have to stick with a single color for all text in the entire design.
• Keep the focus on your article or body text. If you have a sidebar or widgets that appear to the side of your actual body text, try lightening their text color (or reducing contrast with a different background color) to make sure that users focus on the real content of the page.

Font Size

Another obvious and quite important element of your body text style is the font size. There are a number of different ways to establish a default font size for your text. While the method of setting your font sizes is a matter of debate, there are a few best practices you should be aware of.

• It’s easiest on your users to set the body font size at 62.5%, and use ems to size your fonts from there (.wrapper { font-size: 1.3em; } would set the font size to 13 pixels in height).
• Choose a base font size of at least 12 pixels in height. There are exceptions to every rule, but you’ll find that users are frustrated by tiny font sizes, and are apt to leave a site even before using the handy browser zoom feature.
• Deviate from the base font size only where it makes sense in the overall theme of the design. Consistency is key. Set default CSS styles for things like the <small> tag and headers.

Font Family

Fonts are a bit tricky in web design, basically because you’re forced to choose one of about ten fonts that are used on every other website in the world. Typekit is great for header text, but you’re better off using regular web-friendly fonts for your body text. Here’s a few pointers:

• Serif vs. Sans-Serif: First choose the font style you’ll be working with. Choose something that fits with your design’s overall theme or concept. Serif fonts like Times and Georgia give your site a vintage and book-like feel. They are flowing, artistic, and regal in theme. Sans-serif fonts like Arial or Helvetica can be used to portray a clean, professional, and strong atmosphere in your design.
• Choose a common font for your body text that is available on both Mac and PC platforms. There are some great fonts on the Mac, but you’ll want to design your site so that it looks good no matter what device is accessing it.
• It’s completely acceptable to add a “nice to have” font into your design, such as Helvetica or Myriad Pro. These fonts can gracefully degrade to Arial without jarring the layout of your page too much.
• Georgia and Times are not the only serif fonts available! Try experimenting with fonts like Book Antiqua or Platino Linotype, which have a more book-like and artistic feel.
• Courier New is a great fixed-width font best used for displaying CSS, HTML, or some kind of code to your readers.
• Don’t forget other elements in your design! By default, text boxes, buttons, and select menus will not use the body font family and/or size, so make sure to set a consistent font on all elements in your design.
• Don’t use Comic Sans.

Margin, Spacing, and Line Height

This is probably the most overlooked element of body type design. After you’ve developed the character design of your body type, take a step back and examine the paragraph style.

• Unless you specify otherwise, the lines of text in your design are drawn very close together, and it can be difficult for readers to follow as they read down the page. Add a bit of CSS such as p { line-height: 1.5em; } to make this text easier on the eyes.
• Likewise, paragraphs of text have default margins applied to them that may make them appear too close together or too far away from the headers that appear above them. Try adding some CSS such as p { margin: 0 0 1.5em 0; } to standardize the spacing around paragraphs.
• Paragraph text is not the only thing you’ll see in a page. Don’t forget to style other HTML elements like lists (<ul> or <ol>), the horizontal rule (<hr />), and block quotes or call-out boxes.

Be Creative

Following these rules isn’t a guaranteed way to make your body type look amazing, and breaking any or all of these rules certainly doesn’t guarantee that your design will be ugly and fail. In the end, it’s all about being creative and paying attention to all the tiny details that go into making a website look amazing. The difference between a good design and a bad one can be very subtle. Create something fun, stick to a theme, and take note of every visual detail that appears on the page, body type included.

Concerning Accessibility

Accessibility is chiefly important for a web designer (or at least, it should be). When you create your HTML, keep things as simple as possible. Assume that every single user who visits your site will (1) not have CSS support, (2) will disable all images on your page, and (3) will not have JavaScript enabled. If you design your HTML in this fashion, you’ll find that creating accessible content is much easier to do. Once you have an accessible document that works on all systems, you can use the fantastic features of CSS and client-side scripting to really bring your site to life. These “nice to have” features (style, scripting, etc.) are not essential to the structure of your document or the content that’s contained within. When it comes down to it, users are after your content, so that’s priority number one.

A Simple Example

With that in mind, let’s say we wanted to create an image that links to another page (this is so very simple, but it serves as a great example of this technique). Because we’re assuming that users have disabled all images, we certainly don’t want to use the <img/> tag for our link, because those users without image support simply won’t see it. For that reason, our link will look like any other link on the site.

<a class="learnGuitar" href="http://www.mahalo.com/how-to-play-guitar-for-newbies">Learn Guitar</a>

I know…this is really simple, but stay with me; I promise we’re going somewhere with this. Our very simple HTML has passed our criteria: users with CSS disabled will see the link, as will users without images or script. It’s very simply an accessible link on our page, read as easily by normal users as it is by search engines or even people using screen readers. Next, for users who can utilize our “nice to have” features, we’ll add a bit of CSS to make our image appear.

.learnGuitar {
	display: block;
	width: 200px;
	height: 50px;
	background: url('/path/to/learn-guitar.png');
	text-indent: -9999em;
}

As you can see, we’re using the text-indent CSS property to bump our text out of the way, and in it’s place, we’re using background to set an image for our link. All you have to do for your own image is adjust the width, height, and background URL to match. What you get when you’re all done is this:

Learn Guitar

Adding a Hover Image

Easy and accessible CSS image replacement! It looks great, but let’s take it one more level to really make sure users know that our button DESERVES to be clicked. Let’s add a hover style. I’m going to use an image “sprite” for the hover image, which means that both our static and hover states are contained within the same image. Here’s my *single* image that’s used for this type of style:

We’ll adjust our CSS to account for our new hover image. Note that the height and width attributes will not change! The hover-state image will be “clipped,” so that it’s only visible when users move their mouse cursor over our image button.

.learnGuitar {
	display: block;
	width: 200px;
	height: 50px;
	background: url('/path/to/learn-guitar.png') top;
	text-indent: -9999em;
}
.learnGuitar:hover {
	background-position: 0 -50px;
}

Now, when users move their mouse cursor over our image button, the CSS will “slide” the background image so that the hover state is displayed instead of the static state.

Learn Guitar

Crafting your image buttons in this fashion can really save on performance and download times. Perhaps more importantly, your site will be much more “friendly” to visually impaired users using screen readers, and you’ll find that search engines will have an easier time understanding what your links and other content are all about.

Let me know if you have any questions or comments!

Rounded corners are all the rage; they have been for some time now. There are pure CSS approaches to implementing this type of design, but occasionally your clients demand that your user experience be consistent across all browsers. Whether it’s time to stop using HTML and images for rounded corners is still a matter of debate. Nonetheless, I think every designer finds themselves doing this from time to time.

Say No to Images

I’ve found that many designs contain various types of rounded box styles on the same page. In my previous tutorial, this would demand that you create a separate corner image for each style of box. If you have a box with a red background, you’ll need to create a corner image with red corners. That makes sense from a visual perspective. From a data perspective, however, it’s not the best approach. If you think about it, the only thing you’re really “downloading” when you download a corner image is the curvature of your box’s edge. Wouldn’t it be better if we could somehow reuse that data on every box style everywhere else in your design?

Well, you can! How gloriously fantastic! Well…don’t get all excited just yet. There are a few limitations to this. This will only work when your rounded box appears on a solid color. For instance, the text you’re reading right now is on a solid white background. We can easily add rounded boxes to this page because of the solid color. This doesn’t really work if your background is an image or a gradient color.

Meet the Sprite

So, you have a solid background color, and you’re ready to add some rounded corner boxes to your page. The only really important thing here is your corners image. In Photoshop or an image editing software of your choice, create a square image. Basically, your image is all four box corners stuck together, so make it symmetrical. Fill your image with the background color of your page, and then delete a circle out of the middle of the square. It’s that easy! Here’s what it should look like when you’re done:

In case you’re not Photoshop-savvy, I have created a few templates that you can download and use.

• TransparentCorners-10.psd – 10×10 pixel corner image template
• TransparentCorners-15.psd – 15×15 pixel corner image template
• TransparentCorners-20.psd – 20×20 pixel corner image template

The Markup

Now that we have this nice fancy reusable transparent corner image, it’s time to create the HTML that will be used to house our beautiful box and its contents. Here’s the basic setup:

<div class="box red">
	<div class="corner TL"></div>
	<div class="corner TR"></div>
	<div class="corner BL"></div>
	<div class="corner BR"></div>
	<p>This is your box content. Lorem ipsum dolor sit amet.</p>
</div>

Pretty simple, right? We have an outer “box” <div/>, a <div/> for each corner, and then our content that will appear inside the box.

The Style

Our HTML doesn’t do much by itself. Most of the work to be done is going to be done in our CSS style sheet. In an attached style sheet, add the following CSS:

.box {
	position: relative;
	padding: 1em;
}
.red {
	background: #cc0000;
	color: #fff;
}
.corner {
	position: absolute;
	width: 10px;
	height: 10px;
	background: url(/path/to/cornerImage.png) no-repeat;
}
.TL {
	top: 0;
	left: 0;
	background-position: 0 0;
}
.TR {
	top: 0;
	right: 0;
	background-position: 100% 0;
}
.BL {
	bottom: 0;
	left: 0;
	background-position: 0 100%;
}
.BR {
	bottom: 0;
	right: 0;
	background-position: 100% 100%;
}

As you can see, we’re really trying to keep this simple. Basically, we have an outer “box” style, a “red” style that sets the box’s background color to red, and finally individual “corner” styles that will automatically position themselves at the edges of our content, regardless of the height/width of that content. Groovy.

The Result

I’ve created a simple “white” background corner image for use on this page. What you get when you put all of this together is a very flexible corner system that requires very little HTML and CSS to implement:

And the coolest part…

It’s Reusable!

The coolest part about using transparent images for our corners is that we can apply these corners to just about anything on our page that we want to. For instance, I could create some additional box styles (other than “red”) by adding a bit of CSS.

.red {
	background: #cc0000;
	color: #fff;
}
.blue {
	background: #00cc00;
	color: #fff;
}
.green {
	background: #0000cc;
	color: #fff;
}
.gray {
	background: #dedede;
	color: #666;
}

After changing our box’s class (class="box blue", class="box green", etc.), we would get:

That’s really cool, but this doesn’t even touch the limits of how you can apply this. In addition to solid color boxes, we could also apply this to photos and gradients (which would be much harder in a more traditional corner system). Our corners really don’t care what type of content they’re applied on, they only really care about the background color. Let’s try it out on some different page elements (accompanying HTML and CSS are included for each style):

The Mini Profile

HTML:

<div class="box photo">
	<div class="corner TL"></div>
	<div class="corner TR"></div>
	<div class="corner BL"></div>
	<div class="corner BR"></div>
	<h3>My Profile</h3>
	<img src="kyle.jpg" alt="Me" />
</div>

CSS:

.photo {
	width: 200px;
	padding: 0;
}
.photo h3 {
	background: #000;
	color: #fff;
	padding: 10px 20px;
	margin: 0;
	font-size: 1em;
}

The Gradient

HTML:

<div class="box blueGradient">
	<div class="corner TL"></div>
	<div class="corner TR"></div>
	<div class="corner BL"></div>
	<div class="corner BR"></div>
	<p>Notice the gradient background image!</p>
</div>

CSS:

.blueGradient {
	background: url(gradient-image.png) repeat-x;
	color: #fff;
}

We’ve accomplished all of the styles you see above using a single image and some fancy CSS footwork. This really minimizes the impact of your corners on page download times, especially if you’re using a number of different styles on a single background color. No scripts, no confusing HTML, simple markup, and a single image. Happy styling.

The Idea

First of all, I will say that this approach only really works if you know the maximum size of your comment data. On ThumbSticks.com, for instance, users can’t enter comments that are over 300 characters in length, so I have a good idea of how large each comment box could possibly get. Rather than splicing my comment box into multiple images (which is more flexible, but decreases page performance and increases download times), I decided to create a single image that is used to wrap each comment chat bubble:

The Image

Basically, my chat bubble boxes can shrink to any size, but they can’t grow beyond the height of this image. If you know exactly how large your data can get, this is a really simple solution to implement. All that I need to show my chat bubbles is a bit of HTML and CSS.

The Nitty-Gritty

HTML:

<div class="bubble">
	<div class="bubbleHeader"></div>
	<div class="bubbleInner">
		<p>Lorem ipsum dolor sit amet.</p>
	</div>
</div>

CSS:

.bubble {
	width: 477px;
	background: url('/path/to/commentBg.png') no-repeat;
	background-position: 100% 100%;
}
.bubbleHeader {
	height: 20px;
	background: url('/path/to/commentBg.png') no-repeat;
	background-position: 100% 0;
}
.bubbleInner {
	padding: 0 20px 10px 37px;
}

Make sure you change “/path/to/comment.Bg.png” to reflect the actual path to the background image you’re using. Once you’ve dropped this into your design, you should see something that looks a little like this.

Good luck, and happy styling!

The truth of the matter is that a web document is a compilation of various highly organized computer languages (XML, HTML, CSS, JavaScript, etc.). The web designer has the difficult task of considering the “art” of the design as well as the technical architecture of it. A truly skilled web designer has the ability to think both creatively and logically. A designer bridges the gap between design and development, which is sometimes a very difficult task; a task made far more feasible by the utilization of simplicity.

A Simple Example

I use the word “simplicity” in a very generic sense; it’s a very broad term, so I’d like to use a few examples to show how simplicity can be a great aid in web design. Take, for instance, the anchor tag (<a/>). The anchor tag is at the very foundation of HTML; it is the most basic implementation of the concept of the internet: the hyperlink. It’s so simple in and of itself, how could designers possibly do anything at all to mar it’s glorious simplicity?

Here are two anchor tags. They appear quite identical, but the behavior of each is remarkably different. Which one is better?

A Simple Link A Simple Link

Did you notice a difference? At first glance, they are identical, but the interactive behavior of each link is quite different. Move your mouse cursor over each link, and notice the difference in clickable area on each link. On the first anchor tag, only the text “A Simple Link” is hyperlinked. The padded area around the link is not. The second link, however, is fully hyperlinked (the entire padded area is clickable).

Visual Interactivity

This is a demonstration of the fundamental elements of simplicity in design. A user who visits your site doesn’t care how you’ve formatted your CSS and HTML, or how you’ve scripted page behavior to allow for access to your data. The user only cares about navigating to the content they’re interested in. When a user sees a visual element on the page (such as the links above), they want to move their mouse pointer to that element and click. If a particular page element has some level of interactive behavior associated with it, the entire element should react to that behavior.

Logical Simplicity

Treating page elements in this fashion can also help eliminate extraneous HTML and CSS. Again, using the example above, let’s look at the source code of these two different links and examine their differences.

<style type="text/css">
.complexLink {
	display: block;
	width: 15em;
	padding: 1em 0;
	margin: 0 2em 2em 0;
	float: left;
	background: #f0f0f0;
	border: 1px #e0e0e0 solid;
	-moz-border-radius: 1em;
	-webkit-border-radius: 1em;
	text-align: center;
}
.complexLink:hover {
	border-color: #c0c0c0;
}
.complexLink a {
	color: #555;
}
.complexLink a:hover {
	color: #d56e1c;
	text-decoration: none;
}
</style>
<span class="complexLink"><a href="...">A Simple Link</a></span>

<style type="text/css">
.simpleLink {
	display: block;
	width: 15em;
	padding: 1em 0;
	margin: 0 2em 2em 0;
	float: left;
	background: #f0f0f0;
	color: #555;
	border: 1px #e0e0e0 solid;
	-moz-border-radius: 1em;
	-webkit-border-radius: 1em;
	text-align: center;
}
.simpleLink:hover {
	color: #d56e1c;
	border-color: #c0c0c0;
	text-decoration: none;
}
</style>
<a class="simpleLink" href="...">A Simple Link</a>

The code above relates to the first and second links, respectively. At first, the two links seemed almost identical, but now the differences are really starting to show. Not only is our more complex example (the first link) more difficult for the user to interpret, but it’s also more work for you as the designer because you have more elements, layers, and styles to deal with.

Now Repeat

It might be somewhat trivial to look at an anchor tag in such depth, but this type of design methodology extends into every aspect of web development. From HTML to CSS, from JavaScript to server-side programming, simplicity is an essential element of a good design. You’ll find that adopting this mentality can increase your productivity, lower the costs of site re-design, and expedite efforts to troubleshoot and resolve rendering problems in your web application. Less really is more.

Take a moment, take your time, and think about each and every element that you design as an independent function of logic and art. Think about the best way to approach every control, and apply uncompromising simplicity wherever possible.