Why jealousy?  I have not had the opportunity to work on a responsive redesign yet; REALLY jealous of all parties involved!

A short while ago, the Boston Globe rolled out a redesigned website. To say that it was just redesigned is an understatement, though – the new entity is the result of Responsive Web Design.

This very buzzwordy descriptor is a new philosophy in web design where content is delivered in principally the same manner to all devices but its presentation is adjusted to accommodate the browser’s screen size and orientation. There is a single site that works for both desktop and mobile displays in both portrait and landscape. In the past, this has been accomplished by developing a site per visitor type – one site for the iPhone visitors, one for Blackberry visitors, a ‘main’/'regular’/'desktop’ site, etc. Sure, designers and developers could combine some of the views and use a generic ‘mobile’ site, but the idea was the same.

The Boston Globe site is one of the first big names to implement a full redesign using this responsive philosophy, which is why the new site has garnered so much attention. Take a look for yourself – open the site, then resize your browser and watch the content shift. Image sizes adjust; column widths shrink; eventually columns start to drop down to be pillars, instead of side-by-side; the navigation shrinks and eventually starts to drop items. The whole thing is just a marvel of web design.

The point of responsive web design is not to accommodate this type of resizing – a lot of sites now use fluid layouts, so as you expand your browser the line lengths increase – rather the point is that the site naturally respects your browser size and remains device agnostic. You’ll get a slightly different experience if you move from the Droid to your desktop, or rotate your iPad from portrait to landscape, but you’ll never get a different site. You still have access to all the same content without having to click the “full site” link from your mobile browser.

Upstatement, the Filament Group and a few contractors (notably, Ethan Marcotte, write-up) worked together to create this masterpiece. Upstatement’s write-up is pretty thorough. If you’re into it, give it a read. Jeremy Keith has another great journal article about the Boston Globe’s new site, and the response he’s witnessed.

http://www.bostonglobe.com

Before we begin, let me say that the delivered stylesheet should be minified and free of excess spaces, tabs, semicolons and lengths of 0px instead of “0″, using tools like the YUI compressor or the CSS Drive Online CSS Compression Utility.

I have read and been part of many discussions about the format of a CSS document.  I happen to prefer to keep my declarations on one line, alphabetized.  I also like to keep the entire ruleset on one line, unless the ruleset is too long (I know, that’s subjective, but it is my blog).

Recently, though, I’ve had to work on some interesting and complex designs.  As the DOM depth grew, I found myself getting lost in my own HTML.  The solution, for me, was a simple one, both easy to implement and easy to back out of (especially when using the tools listed above).

My CSS formatting rules were category based:

1. Reset CSS, if necessary/desired (note, I don’t always use a full reset library)
2. HTML declarations
3. ID rules
4. class rules

Beyond that, I found my formatting rules lacking.  Last-in mental flow within category left me lost and confused.  To buttress my existing formatting rules, I adopted a visual outline in my stylesheet that matched the indent rules of my HTML.  For example, the following HTML:

<div id="nav">
   <ul>
      <li><a href="http://www.google.com" title="some local navigation link">Navigation Item 1</a></li>
      <li><a href="http://www.google.com" title="some local navigation link">Navigation Item 2</a></li>
      <li><a href="http://www.google.com" title="some local navigation link">Navigation Item 3</a>
         <ul>
            <li><a href="http://www.google.com" title="some local navigation link">Sub-Navigation Item 1</a></li>
            <li><a href="http://www.google.com" title="some local navigation link">Sub-Navigation Item 2</a></li>
            <li><a href="http://www.google.com" title="some local navigation link">Sub-Navigation Item 3</a>
         </ul>
      </li>
      <li><a href="http://www.google.com" title="some local navigation link">Navigation Item 4</a></li>
      <li><a href="http://www.google.com" title="some local navigation link">Navigation Item 5</a></li>
      <li><a href="http://www.google.com" title="some local navigation link">Navigation Item 6</a></li>
   </ul>
</div>

Would be supported by this CSS:

	#nav {border:1px solid #ccc;}
		#nav ul {list-style-type:none;margin:0;padding:0;}
			#nav ul li {display:inline;list-style-type:none;margin:0;padding:0;}
			#nav ul li:hover {position:relative;}
				#nav ul li a {display:inline-block;color:#000;padding:4px 12px;text-decoration:none;}
				#nav ul li a:hover {text-decoration:underline;}
				#nav ul li ul {background-color:#666666;border:1px solid #333333;display:none;position:absolute;left:5px;top:100%;width:200px;}
				#nav ul li ul li {display:block;width:200px;}
				#nav ul li:hover ul {display:block;}
				#nav ul li ul li a {color:#fff;}

There’s nothing new or magical here. In fact, this isn’t even a very pretty implementation of a flyout menu. The point here, though, is that my CSS has been formatted to mimic the indentation and format of the HTML.  Clearly, “li” is a child of “ul” is a child of “#nav” and so on.  As your style sheet grows, you’ll be glad you took the extra steps to maintain a mock of your HTML formatting.

Don’t forget – the final step before publishing to production should, at the very least, be minification!

Bonus content: this concept can be rewritten to use Object Oriented CSS (stubbornella@github, #jqconn #oocss, object-oriented CSS).  Check back later for that post!

In another post, Jason vs. Page Weight – Accessibility Series, pt. 2, I talked about a page weight problem I had with a client.  In the end, the client decided to put a lot of data on a single page.  In my opinion, this would have been a great time to use AJAX to pull in the data rather than just pushing it all to the page at load.  The problem with AJAX is that it relies on JavaScript (reliance may, in fact, be too weak a term, honestly) and so would not have been ideal for search engines and would not have provided accessible page content.  We could fix that by linking to pages with additional content, but we really want to use AJAX to show the data on a single page for all visitors with JavaScript enabled.  So, we just do both.

By leveraging the preventDefault method available in the jQuery library (this is actually a JavaScript call, and exists outside of jQuery.  See the W3C write up.) we can provide a page that is static, accessible HTML content by default, but picks up some dynamic interest at page load.  Note: some of the following examples presuppose a single domain; using AJAX to load content from other pages can easily get into cross-site scripting issues.  This can be overcome with some sparse use of iframes.

Take the following HTML code for example:

<div class="targetLinks">
	<ul>
		<li><a href="somepage.html">Some Page</a></li>
		<li><a href="anotherpage.html">Another Page</a></li>
	</ul>
</div>

No magic here.  Two links to two different pages (for simplicity, these are two pages within the same domain).

The Task

Our task is to display content from a different page in a modal dialog.  Just to make it more fun, we’ll pull a specific part of the target page in our modal (denoted in each page by a div with ID of “target”).  To add that last little bit of shine to the action, we’ll prevent the URL from changing (more appropriately, we’ll stop any calls to window.location.href).

We’ll need three things for this tutorial:

• jQuery v 1.3.2 (preferably minified)
• jQuery UI Core v 1.7.3
• jQuery Modal code base v 1.7.3

Let’s take a look at the code required to attain our goal, then we’ll break it down piece by piece.

$(document).ready(function() {
	$('.targetLinks ul li a').click(function(eventMarker) {
		var $dialog = $('<div></div>')
			.load($(this).attr('href') + " #target")
			.dialog({
				autoOpen: false,
				modal:true,
				title: $(this).attr('title'),
				width: 500,
				height: 300
			});
		$dialog.dialog('open');
		eventMarker.preventDefault();
	});
});

If you’ve seen jQuery snippets before, you should be familiar with the $(document.ready), which executes the wrapped code only after the document has finished loading.

$('.targetLinks ul li a').click(function(eventMarker) {

This line of code does two things:

1. Traverses the DOM to find the elements with class “targetLinks” that also contain the UL LI A descendant path and establishes a jQuery array of elements representing the matched <a> tags.
2. Assigns a click event to each <a> in the returned array of elements.  The click event is an anonymous function that takes the DOM Event and assigns it to an argument called “eventMarker”.

var $dialog = $('<div></div>')

Next, we establish a variable, $dialog, as a pointer to a newly created DIV element. Why a new div? The jQuery UI dialog, like many other jQuery plugins, destroy the element used as the selector when the dialog closes.  We could target an existing DIV as the dialog, but when the modal closes, the existing DIV will be destroyed (lost for all script).

.load($(this).attr('href') + " #target")

We continue the method chain, established on our newly created div, by calling the jQuery .load() method.  Load expects a URL (same site URI, of course), which we have passed by calling $(this) (the clicked anchor) and calling the .attr() method asking for the href.

.dialog({
	autoOpen: false,
	modal:true,
	title: $(this).attr('title'),
	width: 500,
	height: 300
});

Still continuing the method chain, we call the .dialog() method on the $dialog variable (div that was created).  This established the UI Framework necessary to make the dialog work.  We set a few options to the dialog (see the UI documentation for the dialog for more options), again referencing $(this) (the clicked anchor) and calling the .attr() method asking for the title of the anchor to set to the dialog title.

$dialog.dialog('open');

Here, we have separated the open command from the dialog instantiation.  This doesn’t need to be the case, here, but may prove to be a useful practice later.  If you were waiting to see your dialog, you should see it now.

eventMarker.preventDefault()

This is the moment we’ve been waiting for.  We have been following happily along wherever the DOM actions will take us but now, we are going to take control of the clicked anchor tag, and force it to do what we want.  Remember, eventMarker is the event argument passed in initially.  Here, we are calling the JavaScript preventDefault method on the event.  Since our event is the result of the click of an anchor, the default action should be to alter the window.location.href.  Instead, we have truncated the event prior to changing the address bar.  As you might imagine, this same method can be used for bookmark links as well – in the end, the preventDefault() method will prevent the hash from being appended to the URL.

Why preventDefault() instead of return false;?

Whenever  you run a return from a JavaScript function, you exit the function – completely preempting any further actions.  With preventDefault(), further processing can be accomplished after the method call, within the same function.  Note that eventMarker.stopPropogation() or eventMarker.cancelBubble=true should be used to completely cancel event bubbling.

So what?

Why would the methods in this post be useful?  With this code,  we are unobtrusively adding click event handlers to targeted links, but we are doing so without actually coding “onclick=’…’” or setting href=”javascript:function()”.  If your visitors have JavaScript disabled, then they will get the benefit of linked content.  If JavaScript is enabled, they will get the benefit of dynamic content display, without leaving the page.  Win-win.

Download the code used in this post.

When the topic of Web Accessibility arises, I immediately think of a standard set of keywords: ADA/508 compliance, information architecture, JavaScript, well-formed HTML, ALT text, etc.  This list represents the things that, as I have been taught over the past few years, have significant impact on the accessibility of a page and a site.

Recently, during an accessibility assessment, I discovered a new factor to consider: page weight.  Page Weight should not be a new concept to any web designer.  Ever since the days of dial-up dominance, we have been scrutinizing every paragraph, abusing calculators to determine the most appropriate image collection, mapping the dimension and location of every new icon and rollover in our sprite, clocking speed tests and ripping out every non-essential bit of white-space we could find.  I admit that I have become a little lax, allowing more and larger images on my page for the sake of design, all the while whispering silent apologies to the dial-up community.

During the aforementioned assessment, we paid special attention to one set of pages in particular.  Our project, the public-facing site of a university, has a section outlining each of the degree programs.  The challenge the client faced is one that many education websites face: how to appropriately define a program and all its structural elements, without destroying the visitor’s sense of connection to the program itself.  The client’s decision was to provide all the program details on one page, rather than just linking from the program page to course description pages.  Program details include the course subject, required course list, course descriptions and, in some cases, subject description.  For a full program page, we discovered the amount of information could be….daunting.  With nine or ten requirement categories and as many as fourteen course requirements per category, we were looking at a number of pages with an HTML weight of 130 kb.  Once the images were added in, we were well above 200 kb in page weight which could take up to 30 seconds to load on a 56 Kbps modem.

As it turns out, the page weight is a necessary evil for this particular page.  We had two options, in order to maintain an accessible data set: put all the information on one page or link to it all from one page.  All the data on one page makes the navigation of the program easier for the site visitor, but overloads the ideal weight.  Linking from the program page to each course would have delivered a light page but would have forced a lot of usage of the back button.

So what is the ideal solution?  For this client, the massive page was the preferred solution.

Alternatively, we could have used a bit of JQuery magic to deliver a lightweight page, with links to additional content, that was also slick and usable. I cover the details of this option in an upcoming post (Jason vs. Anchor Tags – Getting Results with the PreventDefault method) but the idea is this:

Provide the user with an appropriate amount of content – an amount that would adequately describe the program- and supply links to the detail pages of each course.  When a visiting user has JavaScript disabled, the content would behave as you might expect: the visitor reads the program description, clicks a link and navigates to a course description page.

When JavaScript is available, however, we capture the click event of the anchor and, since we’re in the same domain as the source content, pull the source content into a modal dialog (like ColorBox, if you’re in the market for a good one) via AJAX request and prevent the default action of the link from firing.  We’ll use the HREF property of the anchor as the URI to the source.  Further, we’ll use the anchor’s class as the selector target (See jQuery’s class selector for more details).

A few things to note -

1. We did not have to include any onclick property to return false at the click, which helps us maintain our unobtrusive JavaScript.
2. Since we would be relying on the anchor’s class when attaching click events, we can flag any anchor to be skipped just by adding another name to a compound class of the anchor OR omitting a target class name.
3. Degradation is smooth and predictable, since we’re just talking about anchors with standard href properties.  Without the JavaScript to cause the Modal onclick, the link will fire and redirect the visitor to the uri referenced in the href.

With the JavaScript in place, we will have taken a very large page and trimmed it down to a manageable size, and successfully merged accessibility with usability.

Usability is finally starting to bubble to the top for Web Designers and Information Architects.  We are, as an industry, starting to realize that our audience exists outside of Photoshop canvas and beyond the code.  In fact, I have witnessed an increased focus on JavaScript degradation over the past few months – an unspoken admission that we, as web design professionals, should and shall provide web content to users of all browsing backgrounds and capabilities.  We have started providing, in earnest, content for the connoisseurs, the design savvy, the critics and the forward thinkers all in tandem with the conservative visitors, the visually impaired, our friends on mobile devices and those that, for whatever reason, just have JavaScript disabled.

Personally, I like movement on a web page.  I like my flyout navigation to have some animation, and my repetitive content divs to mimic an accordion as I expand and collapse each panel; the action is interesting  and it adds to my experience.  In fact, I am disappointed, in most cases, when I find no animation where I expect to find it.  Like many of my contemporaries I am quickly discovering that all those things I enjoy about modern web design are also the things that make a webpage into an accessibility nightmare.  What do I, as a conscientious Web Architect, do?  What do I suggest to my clients?  Do I keep my designs and techniques moving forward or do I abandon all the movement and interaction so that the minority of users can browse the web to their own enjoyment?

My answer, flying in the face of the quintessential proclamation about having and eating cake, is simply “do both”.  The analysis phase of every project I accept has increased to allow for accessibility planning.  With so many well-defined best practices for Web Accessibility to be found, the platform for an enjoyable, accessible site is out there; we just have to plan for it.

Throughout this series, I will focus on modern web design trends and how to reconcile these trends with the movement toward, and significant need for, designing websites that are accessible to all audiences.  We may all be surprised as we find a best-of-both-worlds scenario for most design techniques.

I also suggest reading W3C’s Web Accessibility Initiative’s article about making websites accessible for users with disabilities and for mobile devices.