Kyle Schaeffer - Web Design and SharePoint Branding » Best Practices

10 Things a Website Should Never, Ever Do

Kyle — Thu, 22 Sep 2011 21:19:15 +0000

As a designer of the world wide web, you are armed with the power to amaze, enlighten, entice, and captivate. The web is an easel for your creative aspirations, and the content you design for is the foundation of your creativity. With so much power at the tips of your fingers, you also possess the ability to deter, annoy, anger, and infuriate. Your users are yours to command, their emotions yours to pluck like the strings of a harp.

It’s the latter of these powers that we discuss today: your ability to destroy the desire for users to stay on your site. We’ll examine the causes of user strife on the web, and see clear examples of common mistakes that designers and developers all-too-often seem to make.

1. Never interfere with the ability to scroll

The browser window is a fairly simple application: an address/search bar, a few buttons, and a big window where users read, scroll, and click. Sure, most browsers have other bells and whistles, but it really boils down to these essential elements of the browsing experience. Rule number one: never, ever (ever, ever) interfere with these most basic features of the browser window.

Example: Microsoft SharePoint 2010

One of the most preposterous features of an interface that I’ve seen is SharePoint 2010′s new ribbon interface. The default SharePoint 2010 interface includes a simple CSS style that disables the scrollbar on the element. Microsoft chooses to remedy this by adding a scrollbar to other division elements in the interface instead. This results in a fairly impressive “fixed” ribbon, but it has some infuriating side-effects.

When a SharePoint 2010 page loads, users will not be able to scroll until all JavaScript has loaded. On slow servers or on large pages, this can take up to 2-3 seconds, which can be quite infuriating.
Some devices don’t execute the JavaScript in the expected fashion, resulting in the complete inability to scroll on mobile devices and tablets.

An easy solution

The truth is, creating a “fixed” element is a fairly simple CSS technique that has become extremely popular in the last few months. The complexity of Microsoft’s interface is it’s downfall. Always practice in simplicity, because fewer things can go wrong in the end. Build simple interfaces, and never disable the scroll bar. Do this, and you’ll know at least one person who doesn’t hate your guts.

2. Never allow form resubmissions

Forms are a fairly standard feature of the web. Users see them and use them all the time: to sign up, sign in, order, update, and the like. With so much familiarity, it’s a wonder that forms are one of the largest sources of frustration to users. Between data, validation, formatting, handling errors, and all the auxiliary things that seem to surround web forms, things can get pretty complex for designers and developers. All the while, you try to keep it simple for your users. It’s a tall order, to be sure, but there is at least one thing that you can do to help users stay calm.

Example: The Form Resubmission Prompt

This is Google Chrome’s form resubmission prompt. Most browsers have something very similar. This appears when users click on the “Back” and “Forward” buttons in the browser, or when they “Refresh” a page on which they have submitted a form. As web junkies, we might know what this means, but it has a more elusive meaning to your every-day internet users. Most of the time, you’ll find that users simply click the default option (in this case, “Continue”), which can lead to duplication of orders, data, requests, and all sorts of things that would be better off if avoided. Also, it’s just another annoying prompt that users encounter while they’re using your site.

A Simple Solution

The solution to form resubmissions really depends on the platform your website runs on. In most cases, a simple fix is to separate the script that submits the form data, and the script that receives and processes that data. For example, if you’re using a PHP-based platform, you might have a form that looks like this:

To avoid the resubmission prompt, your submit.php script would forward to another page, rather than displaying a page in the browser.

if(isset($_POST['user']) && isset($_POST['pass'])){
  // do something with the form data
  header('Location:/login/form.php?success=true');
}

This receiving script never actually displays anything in the browser window. Instead, it receives the form data, does something with it, and then forwards the user somewhere else. Using this technique, when users click on the “Back” or “Forward” button, the browser will skip the submit.php page completely, and never see the annoying form resubmission prompt.

3. Never disable keyboard support

While we’re on the topic of forms, let’s look at another deviation from web standards you’ll want to avoid. To the right, you’ll see a screenshot of the login form at mysprint.sprint.com. I have a Sprint mobile phone, and I occasionally use this login form to sign in and review my account, see my bill, or (more commonly) daydream about all the fancy new mobile phones that I don’t have.

What went wrong

The font sizes are a little small for my taste, but the appearance of this form is not the worst I’ve seen (yes, that was a compliment). Design and aesthetics aside, there’s one feature of this form that drives me absolutely crazy. It’s an extremely simple form, one that I’ve encountered on countless other websites before. As usual, I would expect to enter my username and password to sign in without a fuss.

Unfortunately, this is not the case. While focusing in either the username or password textbox, pressing the ENTER key does absolutely nothing. I’m not the type of user that wastes time after filling out a form by lifting my hand from the keyboard and finding the submit button with my mouse cursor. I’m all about speed: on most websites, it’s type, type, ENTER, and the form has been submitted. On Sprint’s website, however, they’ve removed this behavior, and thus they’ve earned a place on my list of don’t-do’s.

4. Never fail to give feedback

Feedback is important, especially if you’re working with the awesomeness of AJAX. Traditionally, you knew what was going on in a web page, because any time you clicked on something, you had to wait while the next page loaded. There was a very apparent interaction period, and very obvious feedback from that interaction. With the introduction of new technology like AJAX, however, that feedback is not always so obvious. Today’s websites are much more interactive, and the result of those interactions (whether successful or not) needs to be communicated to the user.

Example: Facebook

There’s an easy way to test this: visit a web page, turn off your wireless adapter, and then click on things and see what happens. Obviously, because you’re not online, anything you do should be very obviously followed by a “no connection” message or some sort of indication that you’ve failed to do something. Facebook, a website that makes gratuitous use of AJAX for interaction, is not so good about warning users when things have failed.

Editor’s note: yes, I am using pirate Facebook.

One particular example is the new “lists” feature that allows you to mark a list as “favorite.” Even when you’re offline, Facebook gives you no indication that the action has failed. Never assume that users will have a fast connection, or that AJAX requests will complete. You should always provide feedback if something fails, especially when no page loads are involved.

5. Never disable keyboard navigation

Different strokes for different folks. That’s a saying that I like to spew off at random times, usually in a failed attempt at humor, but the lesson of this silly quip is tried and true: everyone has their own way of doing things. This can also be applied to navigation on the internet. Some people prefer to use their cursor for absolutely everything, and only resort to keyboard use when absolutely necessary. Others use the keyboard almost entirely, tabbing, backspacing, and scrolling their way through the world of the world wide web. Others, still, use gestures and touch screens to flick and fly their way through the internet. As a crafter of the interactive, you must adhere to all of these people. Never detract from your users’ ability to navigate in whatever way they damn well please.

Example: No, I don’t want to search

I’m going to use eBay as an example, just because they’re so big, but many websites out there are guilty of this annoyance. Upon arriving at eBay’s website, they use JavaScript to auto-focus on the search bar. I guess they’ve already decided, before you even visit, that you want to search their website. For some users, however, this can be incredibly annoying. A common and simple way to scroll down the page, in all browsers, is to press the space key. Pressing this key will advance the screen about one page, so you can continue reading without having to worry about scroll bars and the like. If you’re auto-focused on a search box, however, it disables your ability to do this. Even if it’s only a minor annoyance, it can be incredibly frustrating to users who like to navigate in this fashion. Likewise, I often use the backspace key instead of the back button to go back when I didn’t find what I was looking for. With the focus on a search field, backspace navigation simply doesn’t work.

The fix for this one is easy: don’t do it. It’s annoying.

6. Never move content without user interaction

Websites can be so damn sneaky. I guess they need to make a buck, but who doesn’t? One thing that will drive your users bonkers is anything that moves without a prompt from the user. Yes, I’m talking about you, “auto-expanding-advertisement-that-plays-a-stupid-video-of-a-guy-who-walks-across-my-screen-when-I-just-want-to-read-the-damn-article” guy. I also dislike anything that happens on hover (including drop-down menus). Hover is so 2000′s, get with the times, people. The only time your website should “move” or “do something” is when users tell it to. Most simply, any time they click, drag, or scroll. That sounds simple and obvious, but not everyone adheres to this most basic of principles.

Example: Digg.com

While the quality of Digg’s content is another concern, one thing that does drive me crazy is the sponsored links that appear in the rollup. Notice the promotion from NewEgg.com. This link does not actually appear on page load, but rather when users hover their mouse cursor into the rollup of popular stories. This means that if you’re a fast clicker (aren’t we all?), you will often accidentally click on the advertisement instead of the story you’re interested in. Good for Digg, bad for users. Stop being so shifty, internet.

7. Never use fixed position without a fallback

A “fixed” element in the browser window is one that stays on the screen, even as you scroll down the page. It’s a simple CSS technique, but it’s been amazingly popular in recent months. One thing I’ve noticed in all these fixed designs is the failure to provide a fallback for users who are on smaller screens. The truth of the matter is that the web isn’t just for desktops any more. Internet connectivity is coming in all sorts of shapes and sizes: desktops, laptops, mobiles, tablets, e-readers, gaming consoles, and even refrigerators (yes, even refrigerators). The future promises only more diversity in internet-connected devices, and that means you can’t assume users will have a large viewing area on which to see your website.

Example: Pandora.com

This is a screenshot of Pandora’s fancy new HTML5/CSS3 design. First of all, I’ll say that I love Pandora. Maybe too much. It’s pretty awesome, and it even lets me give all of my radio stations quirky little names like “Harmonizatorasaurous” (eat that, spell-check).

Pandora’s new design includes a fixed header, like many new designs, but it seems the header does not provide a fallback for users on a smaller screen. When reducing the window width, it clips the player controls off the edge of the screen. If a fixed element is clipped, users can’t see it, even if they try to scroll to see more, which can be a huge problem.

A simple solution

An easy solution to this problem is to make the default behavior of your site’s header to maintain a static position, but when users have a large enough screen, you can make things fixed for a more impressive presentation. The following jQuery snippet does the trick quite nicely:

$(window).resize(function(){
  resizeUI();
}); 
$(document).ready(function(){
  resizeUI();
});

// resize on page load AND window resize
function resizeUI(){
 if($(window).width() > 500){
 $('#header').css('position', 'fixed');
 }
 else{
 $('#header').css('position', 'static');
 }
}

This script runs both on page load AND as users resize the window, so no matter what happens, you can decide whether or not to use fixed elements. You’ll have to mess with the values that the script looks at (width and height) to determine what works best for your site’s design, but it’s a useful technique to use.

8. Never use pop-up windows

Do I really even have to mention this one? I thought that pop-ups were notorious for the infuriating behavior that have on users, but I still see them “pop up” from time to time (pun intended).

Example: TinyMCE

I never use pop-ups. I always recommend against them. A common excuse is that your site should stay open, in it’s own tab, even if users click a link that takes them away from your site. I’ve got a simple response to that: wrong! Don’t let your head grow so big that you think your website is god’s gift to the internet. Users have gotten pretty comfortable with the idea of tabbed browsing, and they know how to manage their windows. Unless you’re Google, you’re not allowed to use pop-ups. It’s that simple.

Imagine my surprise when I attempted to implement the TinyMCE JavaScript editor into a web application I was building, and realized it still used pop-up windows for things like links and images. I am building a PHP application, and I have had stars in my eyes for WordPress the entire time, so TinyMCE was the obvious choice. I was so taken aback by this behavior that I ended up switching to CKEditor, another popular editor that has recognized the need to rid the world of these annoying little boxes, and I’m all the happier for it.

9. Never get quirky (well, not too quirky)

I love websites that are different, but not too different. There’s a fine balance to be made between adhering to expectations, and getting so weird that users have no idea what’s going on. As with most users, if I visit a website and am prompted to “explore this insanely huge image of nonsense to learn how to navigate our site,” I’m going to leave and never return. I’ve never been a proponent of Flash, for this very reason, but I also recognize that it has it’s place. Flash can enhance a website’s content with some awesome features, but it should never be used to present content in its entirety.

Example: Sony.com

Check out Sony.com, and you’ll realize that a full 5-8 seconds will go by before you actually see anything on the screen that you can click on. Almost the entire site is in Flash, and it breaks about five of the ten “don’t do’s” that I’ve described in this article. All that aside, Sony has provided a non-Flash version of their site, which also subsequently presents a loading spinner for about 2-3 seconds that covers all of the content on the page. I’m not entirely sure why the designer who created the Sony website was so fond of things that come between users and consuming the content they came to read, but I do know this: it’s annoying. Don’t do it.

10. Never do THIS…

Okay, this last one is really just for fun, but never do THIS…

body * {
  -webkit-transition: all 0.5s ease;
  -moz-transition: all 0.5s ease;
  -o-transition: all 0.5s ease;
  transition: all 0.5s ease;
}
body *:hover {
  -webkit-transform: rotate(180deg);
  -moz-transform: rotate(180deg);
  -o-transform: rotate(180deg);
  transform: rotate(180deg);
}

Try it out by clicking on this button (you’ve been warned):

From “Developer” to “Designer”

Kyle — Thu, 25 Aug 2011 16:34:16 +0000

It’s easy to forget how a website really works. I mean really works. I’ve had the pleasure of working with many brilliant and talented developers (programmers) who could bend the functionality of any application or server-side platform at the drop of a hat. They are problem-solvers, as is everyone in this industry of the online.

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:

200 OK - The most common response; the resource you requested was found
301 Moved Permanently - The resources has moved, and the browser will redirect the request to the new location
304 Not Modified - The resource was found, and your browser already has the most recent version in the browser cache (yay!)
401 Unauthorized - You need to sign in to see this resource
403 Forbidden - You’re not allowed to see this
404 Not Found - The resource you requested does not exist
408 Request Time-Out - That took too long, sorry
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.

Responsive Layouts Using CSS Media Queries

Kyle — Tue, 03 May 2011 02:23:03 +0000

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 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 element in your design’s header.

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.

Constraint Aids in Design

Kyle — Fri, 17 Dec 2010 03:57:04 +0000

I am starting to see a pattern. It is approaching the end of the year, and as with many, hindsight is on the mind. Over the course of my blog, I think I’ve set a course and direction for what I write. The web has definitely changed since my first post in September of 2008; so too have we, as designers, developers, and avid fans of the internet. We have altered our methods, our tools, and our expectations for what a website should be. In all of this change, I have clung to one idea that holds me steady on this shaky ground: constraint.

Constraint is not a buzz word. You don’t sell design with promises of constraint. No, constraint is a discipline in design; it is an essential tool for success in the creative process. All designers begin the creative process in roughly the same fashion: you start with a blank area of two-dimensional space, and you apply your creative ideas in whatever way that suits the medium in which you work. Many designers begin with paper, drawing and sketching their ideas as they emerge. Others may choose to begin in an electronic format, using wireframes, graphic design applications, and the like. No matter the medium in which you choose to work, the process is essentially the same. The problem with this very early stage of creative development is that it lacks constraints of any kind. You can draw anything you can possibly imagine on a piece of paper. It can be a concise and well-planned idea, or it can be complete nonsense. Although the space in which you are now working lacks constraint, the medium in which you eventually implement your idea (the browser window) does not.

As many designers are, I am a detail-oriented person. Every errant pixel or unpolished element in a design can drive me mad. When I begin the creative process, it’s entirely too tempting to explore my ideas completely and thoroughly at the very inception of the thought. My mind wanders astray as I work out the details of color, functionality, even the HTML, CSS, or the JavaScript that will be needed to implement the idea. The problem is, these details don’t matter, at least not yet. My failure to focus on the Big Picture, the vision of what this should really be inside my head, can lead to the failure of the design on the whole. When you first begin the design process, you must remove the details from your mind.

Tools of Constraint

There are some fantastically simple ways to fight your urge to delve into the details of design at such an early stage of your idea. Use any or all of these methods to improve the quality of your design process.

Constraints of Space
Although it seems amazingly elementary to consider, constraining the space in which you work can greatly hinder your ability to focus on the needless details in such an early stage of idea development. On paper, try dividing your space into smaller sections, forcing you to focus on the most important elements of design. If you are working in an electronic medium, try to avoid using the zoom tool for the same effect. Develop your ideas in a constrained space, and you’ll find that you spend less time thinking about the endless details of everything that you create.
Constraints of Medium
Design your idea to the lowest possible standards for the medium(s) in which it will be implemented. For instance, if you are creating a website design, consider designing for mobile devices first. This forces a sense of simplicity in all that you create, which is something that cluttered and disorganized websites often lack. Ensure that your design will function on every possible platform in which it will live, and enhance the experience of your idea for users who can support it.
Constraints of Expectation
Understand the expectations of your users, and recognize the established design patterns of the platform in which you work. Don’t try to reinvent the wheel unless it makes sense in the bigger context of your project. Don’t be afraid to use shared resources to accomplish a common goal, but know when to deviate from the rules in order to avoid a sense of mediocrity.

Gradation of Constraint

Brandon Schauer has created a fantastic multi-page sketchboard template, which can be used to begin the creative process. These templates are fantastic to work with, as they essentially divide a letter-sized area of paper into six divisions, forcing you to work within the spacial constraints of each individual division. Furthermore, Brandon has wisely chosen to include a very subtle suggestion of a browser window in the background of each division of the paper. This is a constant reminder of the constraints of the medium or platform in which you are designing. Brandon also includes a larger, single-sized sketchboard template that can be used to go into greater detail once the big ideas of your design have been explored and polished.

The wisdom of this larger template cannot be overlooked. There is a time in every design process where you must move beyond the constraints of the drawing board. Many designers may move from sketching directly into graphic design, or perhaps into wireframes and prototyping. It can be difficult to suddenly jump from such a well-defined, constrained medium of design into an area that lacks similar constraint. You’ll find that by creating a gradation of constraint, where you constantly “zoom in” to focus on an idea a little at a time, you can aid your mind in avoiding the needless details of implementation until they are necessarily significant.

Use the tools of constraint to explore your ideas a little at a time. Focus on the vision of the design that you have in your head, and elegantly correct your design’s course over the span of its development to ensure that the idea of the design, and the reality of the design are one and the same. Avoid detail-diving, however tempting it may be. Do these things, and you’ll find, as I have found, that the vision of clarity in your mind can gradually and surely become clarity within the browser window.

Taking it Down a Notch

Kyle — Sun, 12 Sep 2010 22:50:12 +0000

Bigger, better, and bolder. That’s the direction of things. The art of the interface is a little more complex than it was yesterday. We have new techniques, new technology (languages and libraries and acronyms, oh my), and even more bandwidth to back it all up. What to do with all this power? The possibilities are nearly limitless. I say, take it down a notch.

Let me explain…

Now, don’t get me wrong. I’m not suggesting that we participate in an exercise of mediocrity; quite the opposite, in fact. I merely suggest that we take a step back and look at interface design on the web as a whole. There’s something so beautiful about it, isn’t there? Perhaps the beauty lies in the very nature of the web; a rare medium in which art and logic can collide. As you well know, the fusion of these two seemingly opposing forces can sometimes end in a gruesome battle between form and function. That simply shouldn’t be the case.

The form of an interface should support the application’s underlying function, and vice versa. The battle that undoubtedly ensues between these two elements is ultimately what damages the design, and any compromise by either party can result only in mediocrity. As the interface designer, it’s your job to cool the tempers on both sides of the development fence, and to facilitate a relationship that fosters that holy center ground, which at times can seem quite elusive and difficult to attain.

A practice of simplicity

The battle is set. The warriors are ready to fight. In the blue corner, Logic eyes its formless opponent with a cold-hearted certainty. You are the mediator, and the time has come for you to tame your design into something everyone can be happy about. Logic is your first adversary. This is the underlying technology and function of your design. It is simple and unforgiving. Treat it as such.

In terms of design, this is the underlying HTML and server-side functionality behind the pages. It needs to be simple, semantic, accessible, and structured in a way that makes sense to the logic of your application. Ask yourself with each snippet of markup that you type in, “What does this ultimately do?” Think about the data of what you’re marking up, and not the appearance of it. We’ll worry about the form of your design later.

A simple example

How would you implement your site’s logo? Before you drop in an or a

, think about what the logo really is. What does it (logically) do? In fact, it’s a header – it is used to describe or encapsulate the content below it. Use the

tag – that’s what it’s for. I don’t care about your silly logo or designer font. My name is Logic, and I demand simplicity. Give me what I want:

Medazio: a completely made up word.

The visual appearance of our site header is not entirely simplistic, but the HTML markup for it certainly is.

A little complexity, please

How would you implement a design for this comment? As soon as you look at this image, it’s easy to see the layout, the colors, or even the position of the data. Now, take a step back and remove the appearance of the image from your mind. We’re working with the logic of the data, remember? The position and orientation of the data simply doesn’t matter right now. Don’t create classes like commentBottom – you’ll probably kick yourself later when you decide to switch things around a bit. Use something more descriptive of the actual data contained in your markup, like comment-description or comment-meta. In our case, we’ll do something very similar:


  
    Lorem ipsum dolor...
    
      photo" src="/path/to/kyle.png" alt="Kyle" />
      Kyle @
      
        Feb 18, 2010 9:49 pm

Notice that we’ve used self-describing class names for most of the data within the comment. The class names in bold are not required, but we’ve added them in order to adhere to the very useful hreview microformat. This helps define your data beyond what can be done with HTML tags and attributes. Additionally, we can append classes together to reduce the need to create extraneous style selectors later on. Logic is now appeased.

And in the red corner…

Meet Art, an element of design not so easily defined as Logic. Logic suffers without Art, its disobedient and relentlessly unpredictable counterpart. It’s not “art” by any traditional sense of the word, no, but it is art nonetheless. It’s bold and daring and difficult. Art is what makes an interface attractive. I dare not attempt to encapsulate the process by which one creates attractive design (it’s a creative process, after all), but I will dabble in the application of it.

Our tool for artistic application is the style sheet. We will use CSS to infuse our structured HTML with our creative ideas. Using the aforementioned examples, let’s see how we can bring our flat and unforgiving concept images into interactive life.

Making the header happen

Remember the logo? Let’s take our cold-hearted HTML and add some “fresh,” CSS-style.

.medazio-logo {
   width: 223px;
   height: 31px;
   background: url(medazio-logo.png);
   text-indent: -9999px;
}

We’re using image replacement to bump that pesky header text out of the way (make way, fabulous logo coming through). The human eye is appeased by the appearance of our logo, and likewise the eye of the machine (search crawlers, screen readers, etc.) is equally appeased by the semantic structure of our HTML document. Even more exciting is the fact that our style sheet actually supports the logic of our design. We’re achieving the appearance that our design demands without compromising the integrity of its structure or function. Much rejoicing is in order.

Adding style to our comments

Similarly, let’s take the same approach with our comment HTML:

ol.comments {
   margin: 0;
   padding: 0;
}
li.comment {
   list-style: none;
   margin: 0 0 20px 0;
}
li.comment p.description {
   background: #f8f8f8;
   border-bottom: 4px solid #eee;
   margin: 0;
   padding: 20px;
}
li.comment p.comment-meta {
   background: url(chat-arrow.png) no-repeat 37px 0;
   padding: 5px 0 0 0;
}

With a few simple lines of CSS, our sensationally semantic HTML comment becomes exactly what we always dreamed it would be. The best part? Both the technology and the design of our application are meeting in the middle. Better that than we, the designers, having to force the union in a rather rude and unsightly manner.

You, the negotiator

The cruel truth of the matter is that not every design element will be so simple or quite as easy to negotiate as this. These are simple examples of a much bigger concept that takes time and practice to master. You, as a designer, are the negotiator of both logic and art. You are forced into a difficult role in which you must understand both the creative aspirations and the technical limitations of your project. Most design professionals fall on either one side or the other of the art vs. technology skill-set. Forcing yourself into an impartial role between the two is a difficult, yet imperative step in your journey to design bliss.

Designing Body Type

Kyle — Thu, 15 Jul 2010 21:26:55 +0000

Header text gets all the love, doesn’t it? From Photoshop to the browser window, the focus seems to be on design elements like logos, navigation, and of course, header type. It’s great fun to use tools like Typekit to make your header text something a little less than ordinary. It defines your site, gives you a unique look and feel, and gives readers that oh-so-scannable sensation they know and love. When you really think about it, however, readers aren’t there for the header text. The headers serve as an essential tool to quickly find what you’re looking for, but the real prize here is the body text, isn’t it? This is where your information is, this is where you write and communicate to readers, and this is an area of design that cannot be neglected. Sadly, it often is.

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 text or lighter
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 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 (
or
), the horizontal rule (), 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.

Input Prompt Text: A Better Way

Kyle — Fri, 04 Jun 2010 02:43:37 +0000

It’s a very cool feature to have a form field that has prompt text such as Enter search keywords… right inside the input box, itself. It looks good, it makes sense to users, and it can save a lot of real estate in your design by negating the need for field labels. The problem, however, is that there are about one hundred ways to implement prompt text, and ninety-nine of them are wrong. Let’s look at this thing from all angles and come up with a fantastically simple and reliable way to make this work.

What is input prompt text?

You’re probably familiar with the concept, even if you don’t know what I’m talking about. Here’s an example:

The prompt text appears inside the form field as soon as the page loads, so users immediately know what it’s for. Simple, right?

Why it Doesn’t Work

There are a number of problems you’ll encounter while implementing prompt text into your forms. Watch out for these caveats when you’re developing your own solution.

Input validation — if someone submits the form without first removing the prompt text, your prompt text is submitted in lieu of real data. Fixing this is a pain. Avoiding this entirely is recommended.

Prompt style — it’s best to style the prompt text so that it doesn’t look like real form data. Creativity is a virtue, but generally web users will expect light (gray) text and italics. This can be problematic because you’ll have to swap the input style back and forth using JavaScript.

Losing focus — when users focus on a form field, don’t type anything, and then click somewhere else, you should always add the prompt text back into the input box. Otherwise, users could miss the intent of the form field entirely. Again, you’ll have to do this with JavaScript, which can be a little tricky.

Progressive enhancement — always make sure that users without JavaScript can still understand and interact with your form fields. This is progressive enhancement at its finest.

The Solution

Almost everything related to the problems listed above originates from one basic fact: you’re trying to create both a field and a label using a single HTML element. When you take a step back and think about that, it really doesn’t make much sense, does it? The solution lies in separating the form field from the label entirely. We’ll use a little bit of jQuery to create an elegant solution that dynamically creates these labels and places them over our form fields. Because we’re creating two separate elements, we can use CSS to style them independently. Perfect!

The jQuery:

$(document).ready(function(){ $('input[type=text][title],input[type=password][title],textarea[title]').each(function(i){ $(this).addClass('input-prompt-' + i); var promptSpan = $(''); $(promptSpan).attr('id', 'input-prompt-' + i); $(promptSpan).append($(this).attr('title')); $(promptSpan).click(function(){ $(this).hide(); $('.' + $(this).attr('id')).focus(); }); if($(this).val() != ''){ $(promptSpan).hide(); } $(this).before(promptSpan); $(this).focus(function(){ $('#input-prompt-' + i).hide(); }); $(this).blur(function(){ if($(this).val() == ''){ $('#input-prompt-' + i).show(); } }); }); });

The CSS:

.input-prompt { position: absolute; font-style: italic; color: #aaa; margin: 0.2em 0 0 0.5em; }

The HTML:

title="Enter search keywords..." />

Basically, this script finds any tags that have a title attribute (i.e. ). For each of these form fields, it takes the title and creates a little tag next to it. The CSS positions the tag so that it appears on top of the form field. The rest is just a little bit of scripting that makes sure to hide and show the labels based on what the user is doing with the input box.

The Result

Here is a demo of the code shown above:

Users without JavaScript enabled will see the normal title tool tips when they hover their mouse cursor over the form field. Please note that you’ll probably have to adjust the margin a bit in the CSS to make sure the labels fit the size of your input boxes. For more information on jQuery and all the great things it can do, visit jQuery.com.

The Perfect jQuery AJAX Request

Kyle — Wed, 14 Apr 2010 14:10:41 +0000

If you’re into client-scripting, then jQuery AJAX is probably your thing (if it’s not, perhaps it should be!). jQuery has some fantastic support for AJAX, and implementing it into your web application is so easy it’s stupid. The AJAX functionality in the AJAX library is so flexible, sometimes it’s easy to get lost when you’re trying to do something very simple. I’ve come up with a very basic jQuery AJAX template that I use for just about everything I do, and I thought it might be useful to share.

The Old Way

Did you work with AJAX way back when, when it first came out? You might remember that an AJAX request looked a little like this.

var xmlhttp;
xmlhttp = GetXmlHttpObject();
if(xmlhttp == null){
  alert("Boo! Your browser doesn't support AJAX!");
  return;
}
xmlhttp.onreadystatechange = stateChanged;
xmlhttp.open("GET", "http://www.google.com", true);
xmlhttp.send(null);

function stateChanged(){
  if(xmlhttp.readyState == 4){
    // do something with the response text
    alert(xmlhttp.responseText);
  }
}
function GetXmlHttpObject(){
  // IE7+, Firefox, Chrome, Opera, Safari
  if(window.XMLHttpRequest){
    return new XMLHttpRequest();
  }

  //IE5, IE6
  if(window.ActiveXObject){
    return new ActiveXObject("Microsoft.XMLHTTP");
  }
  return null;
}

In a nutshell, that sucks! All of that code to simply request the contents of Google’s home page, and then alert in the window. That’s not very helpful at all. Alternatively, here is the exact same function written in jQuery:

$.ajax({
  url: 'http://www.google.com',
  success:function(data){
    alert(data);
  }
});

As you can plainly see, the jQuery AJAX method is much easier to wrap your mind around. You give it a URL to request, and then you give it a set of instructions if a successful request is made. Easy!

I understand that it’s not very useful to request the contents of a web page and alert it to your users (in fact, that’s probably pretty annoying), so let’s take it up a notch. jQuery AJAX features a ridiculous amount of customization options, events, and the like to give you a huge amount of flexibility, and it can be hard to find a good place to start. I’ll help you find the starting line, and you can take it from there.

The Perfect AJAX Request

I’m fairly positive that by using the term perfect, I’m going to get a good amount of nay-sayers telling me why jQuery AJAX sucks, but that’s not what I’m getting at. This jQuery function is perfect in the sense that it handles 99% of all the AJAX requests you’ll ever need to make, it includes a success and failure function to ensure that users get the proper feedback they need, and you’ll get a spinning loading image while the request is being processed to boot. Throw on top of that the fact that it’s extremely easy to use, and I’d say you have something that’s pretty damned close to perfect, at least in my book. Here is the template:

$.ajax({
  type: 'POST',
  url: 'http://kyleschaeffer.com/feed/',
  data: { postVar1: 'theValue1', postVar2: 'theValue2' },
  beforeSend:function(){
    // this is where we append a loading image
    $('#ajax-panel').html('/images/loading.gif" alt="Loading..." />');
  },
  success:function(data){
    // successful request; do something with the data
    $('#ajax-panel').empty();
    $(data).find('item').each(function(i){
      $('#ajax-panel').append('' + $(this).find('title').text() + '
' + $(this).find('link').text() + '');
    });
  },
  error:function(){
    // failed request; give feedback to user
    $('#ajax-panel').html('Oops! Try that again in a few moments.');
  }
});

In this case, I’m loading my site’s RSS feed into a

with an ID of ajax-panel. What does it look like exactly, you ask? Let’s try it out.

Data Types

We’re loading an RSS feed in this example, so the AJAX function is designed to interpret XML data. jQuery AJAX also understands a number of other data formats, such as HTML, plain text, and even JSON. Find out more about data types at the jQuery AJAX documentation page.

Loading Image

Did you notice the spinning loading image? In the beforeSend function, we’re appending a loading image to our AJAX panel, and we’re then taking it out when a request has completed. If you’re not already aware, be sure to check out the very handy website, Ajaxload. This site allows you to quickly create spinner images of any size and color. They have an impressive array of bars, circles, flowers, and the like, so all your design needs should be satiated by the array of options they provide. It’s always a good idea to include a loading image when working with AJAX requests — depending on the client’s connection speed and a number of other variables, the time it takes to complete a request can vary. Don’t assume it will be lickity-split and lightning fast every time. Give your users some feedback to let them know that you’re working on it.

POST Data

You may have noticed that we’re using POST as the request type. POST requests works just like GET requests, except you get the added flexibility to also send data and other variables along with your request. We sent some dummy data that isn’t used by the RSS feed (data: { postVar1: 'theValue1', postVar2: 'theValue2' }), so feel free to change or omit this line of code in order to customize your AJAX request function. As an example, you could send a variable like userId: '45' to a custom PHP script that in return sends you information about a particular user. The possibilities are endless!

Remember the Search

Take what you’ve learned and venture into the wide world of web development armed with the knowledge you now possess. Destroy post-backs wherever they may live, and always remember that Google hates AJAX and won’t interpret anything on your page that’s loaded via script! Good luck, and happy styling.

9 Amazing Things You Can Do in Firefox 3.6

Kyle — Fri, 12 Mar 2010 16:43:32 +0000

The latest update to Mozilla’s wonderful web browser, Firefox 3.6, includes support for some fantastic CSS version 3 recommendations that you may or may not be aware of. Obviously, these tricks won’t work in Internet Explorer just yet, but look for widespread support coming in the (hopefully) very near future.

Most of the new features revolve around background image and color management. This has been a definite pain point for designers in the past, as we’ve had to create extraneous

tags and other silly markup hacks to implement our favorite visual elements. Fear not, for all browsers will soon support these great features! If you’ve already installed Firefox 3.6, you should plainly see all the great features in my examples below. If you haven’t installed the latest update, head on over to Mozilla’s website now to download the latest version.

The Linear Gradient

You can now add linear gradients to your HTML elements with a handy CSS attribute called -moz-linear-gradient. Here are a few examples to get you started.

A simple example:

Are you using Firefox 3.6? Check out my linear gradient background. Lorem ipsum dolor sit amet, consectetur adipiscing elit. Proin tempor odio ac elit faucibus vel rhoncus purus hendrerit. Pellentesque imperdiet fermentum lacinia.

The CSS:

.shiny-box {
	background: -moz-linear-gradient(top, #fff, #e9e9e9);
}

Drawing gradients at an angle:

Gradient backgrounds can be drawn at an angle. Quisque mollis, dui quis hendrerit accumsan, dui lorem congue nibh, et scelerisque neque tortor ac magna. Quisque faucibus lectus tellus. Cras sodales, nulla in suscipit ultricies, mi neque pulvinar augue, a congue lacus tellus eu lorem. Donec varius posuere ligula, adipiscing adipiscing nibh eleifend eu. Nulla sagittis porttitor placerat. Praesent non pretium nisl. Curabitur tempor ante sed orci commodo placerat. Curabitur faucibus ornare augue. Duis adipiscing libero sed ante venenatis posuere. Etiam sodales felis ac est ultricies volutpat. Pellentesque varius iaculis dui, in interdum turpis porta ac. Ut rutrum consequat lectus sit amet euismod. Proin suscipit metus vitae magna condimentum eget blandit ante blandit. Duis lorem magna, luctus sed rutrum non, dictum a erat. In egestas libero a nisl faucibus lobortis. Duis aliquam erat vitae ipsum placerat quis dignissim elit pretium. Sed dictum interdum feugiat. Praesent feugiat libero a enim vulputate ut viverra tortor ornare. Donec vel diam mi. Morbi porttitor porttitor mattis.

The CSS:

.slide {
	background: -moz-linear-gradient(top -45deg, violet, blue);
	color: #fff;
}

Stringing colors together:

Specify multiple colors in your gradients. In fermentum ipsum eget quam pharetra sagittis. Phasellus mollis, nulla nec sagittis pharetra, magna tortor commodo felis, eget dictum sem ipsum gravida ligula. Aliquam pharetra libero quis ligula sollicitudin condimentum. Sed sed diam nulla. Fusce malesuada gravida felis, id porttitor lacus porttitor sed. Maecenas mollis feugiat ultrices. In ac viverra ligula. Maecenas suscipit tempor nibh ac mattis. Morbi ac metus velit. Morbi enim purus, adipiscing at consectetur eget, blandit id nibh.

The CSS:

.rainbow {
	background: -moz-linear-gradient(left 20deg, violet, red, orange, yellow, green, teal, blue, purple);
	color: white;
}

Alpha Gradients

Alpha gradients allow you to specify an RGBA transparency for background images and colors. This allows you to “fade” your background on a gradient, so it gets slightly more opaque as you near the edge of your element. It works a lot like the linear gradients shown above.

Let’s try it out:

Apply alpha gradients to background colors and images. Mauris id mauris diam, vel hendrerit tortor. Pellentesque leo erat, ullamcorper et consectetur eget, elementum id ipsum. Vestibulum et diam mi, quis commodo velit. Maecenas bibendum purus id sapien sodales ut dapibus est consectetur. Donec vel elementum quam. Suspendisse quis risus nulla. Cras imperdiet, est sit amet rhoncus tincidunt, elit turpis consectetur enim, sit amet gravida erat magna id urna. Cras feugiat, orci nec hendrerit pulvinar, tortor mi dapibus neque, in varius massa velit vitae mi. Fusce dignissim malesuada felis in tincidunt. Donec lacus magna, blandit quis ullamcorper consectetur, interdum in nisl. Curabitur luctus lorem in leo aliquam vestibulum. Ut tempus ornare augue non aliquet. Sed id elit eget sem condimentum tempus et non libero. Proin at nisi quis dolor dignissim varius. Nam fermentum mauris eget justo laoreet vitae tristique quam varius. Praesent sodales sem sed dolor aliquet sagittis. Vestibulum fringilla ultricies nunc. In lacus nisl, mollis blandit aliquam ut, tristique in libero. Suspendisse lacinia aliquet aliquet.

.alpha {
	background: -moz-linear-gradient(left, rgba(255,255,255,1),
	rgba(255,255,255,0)),
	#4aceff url(http://thepeev.com/wp-content/themes/thepeev/images/plant.png) bottom no-repeat;
}

Radial Gradients

Radial gradients allow for some really cool effects like gradient “shine” and other neat things you’d otherwise have to create in Photoshop.

The example:

You can even draw radial gradients. See how I shine! Donec malesuada, augue in pulvinar tincidunt, tellus lectus iaculis mi, vel facilisis ante mauris et sem. Nunc pretium orci in lacus sollicitudin rhoncus. Lorem ipsum dolor sit amet, consectetur adipiscing elit. Cras sollicitudin risus eu libero vestibulum vel mattis diam sagittis. Duis vel dui non erat eleifend dignissim vitae vitae dui. Curabitur dictum imperdiet diam euismod viverra.

The CSS:

.radial {
	background: -moz-radial-gradient(top left, white 20%, orange);
}

Repeating Gradients

As if this wasn’t enough, you’ll also have support for repeating gradients, which allows you to do some really cool stuff.

Check it out:

Repeating gradients make it easy to add slash-boxes. Vestibulum at fringilla dolor. Pellentesque id consectetur enim. Suspendisse vel nibh magna, et imperdiet mi. Aliquam erat volutpat. Maecenas dui quam, volutpat vitae cursus et, suscipit sit amet lorem. Duis congue, nisi eu aliquet ultricies, ipsum ligula rutrum libero, quis rhoncus nisi mauris lacinia nunc. Nam iaculis, nibh et faucibus tempor, massa magna eleifend urna, sit amet pulvinar arcu velit et lacus.

The CSS:

.slasher {
	background: -moz-repeating-linear-gradient(left -45deg, #fff, #f5f5f5 1px, #fff 5px, #fff 1px);
}

Use it with radial gradients:

Repeating radial gradients make it easy to add special effects to your design. Aliquam tempor tempor nunc, ut dapibus nisl vehicula et. Nullam felis metus, consectetur eu pretium eu, iaculis eu tortor. Pellentesque habitant morbi tristique senectus et netus et malesuada fames ac turpis egestas. Ut quis ligula orci, id molestie orci.

The CSS:

.burst {
	background: -moz-repeating-radial-gradient(-5px -5px, circle, #bfeeff, #bfeeff 15px, #fff 15px, #fff 30px, #bfeeff 30px, #bfeeff 40px);
	border: 5px #bfeeff solid;
}

Background Images

This is one that I’m really excited about. You can apply multiple background images to a single layer. Here’s how it works:

Multiple background layers:

You can layer multiple background images on a single element. This example was taken direclty from Mozilla’s demonstration page. Class aptent taciti sociosqu ad litora torquent per conubia nostra, per inceptos himenaeos. Quisque imperdiet elit dignissim libero sollicitudin tempus. Pellentesque habitant morbi tristique senectus et netus et malesuada fames ac turpis egestas. Duis mattis, leo at rhoncus varius, leo eros tempus ligula, eget blandit mi tortor vitae ante. Nulla varius aliquet massa ac varius. Vestibulum a ipsum vitae ante lobortis facilisis vitae eu risus.

The CSS:

.layers {
	background: url(http://demos.hacks.mozilla.org/openweb/resources/images/logos/firefox-48.png),
	-moz-linear-gradient(left, rgba(255, 255, 255, 0),  rgba(255, 255, 255, 0.8)),
	url(http://demos.hacks.mozilla.org/openweb/resources/images/patterns/flowers-pattern.jpg);
	background-repeat: no-repeat, no-repeat, repeat;
	background-position: bottom right, left, right;
	color: #fff;
}

You can also resize background images!

You can scale a background image to any size. It’s so ugly! Morbi sapien urna, convallis quis accumsan mattis, congue non ante. Phasellus bibendum nibh id orci consequat hendrerit rhoncus in leo. Ut a mauris eu nisl accumsan pulvinar sit amet at leo. Aenean sit amet enim sit amet tellus pellentesque tempus. Vivamus lobortis dui sed arcu venenatis vel vehicula felis vestibulum. Fusce vel ipsum eu nulla fermentum gravida. Suspendisse tincidunt euismod consectetur.

The CSS:

.sizer {
	background: #f5f5f5 url(http://demos.hacks.mozilla.org/openweb/resources/images/logos/firefox-48.png) bottom right no-repeat;
	-moz-background-size: 120px;
	-webkit-background-size: 120px;
	-o-background-size: 120px;
}

Other Additions

Mozilla has included some other great new features, such as the highly anticipated CSS attribute @font-face, which allows you to embed WOFF downloadable fonts into your web design. Type is finally coming to the web! For details on this and the many other great new features in Firefox 3.6, visit Mozilla’s update details for developers page.

Image Buttons and Accessibility

Kyle — Thu, 19 Nov 2009 21:29:32 +0000

Image buttons are a fairly common occurrence in web media. As with everything else in web design, you have a dizzying arsenal of methods from which you can choose to create this type of design element, and choosing the right method can greatly aid in your design’s accessibility, performance, and SEO-friendliness.

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 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.

Learn Guitar

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!