Requirements

Now, this is supposed to emulate the performance of Chris’ dynamic content demo, and thus it should also have to follow his three requirements. It must:

• work with JavaScript disabled (no JavaScript, so no problem),
• allow for deep linking, and
• keep the Back and Forward buttons from breaking

Okay, now let’s start coding.

Markup

Now the markup for this is pretty simple.

<header id="site-header">
  <div id="site-name">Our Awesome Site</div>
  <nav id="site-nav">
    <ul>
      <li class="page-link"><a href="#home" class="page-link">Home</a></li>
      <li class="page-link"><a href="#about" class="page-link">About Us</a></li>
      <li class="page-link"><a href="#contact" class="page-link">Contact</a></li>
    </ul>
  </nav>
</header>
<div id="site-wrapper">
  <section class="page" id="home">
    <!--"Home" Content Goes Here -->
  </section>
  <section class="page" id="about">
    <!--"About Us" Content Goes Here -->
  </section>
  <section class="page" id="contact">
   <!--"Contact" Content Goes Here -->
  </section>
</div>

And here is how it looks, with some basic styling and dummy content. The anchor links on the right will drop you down to the “page” you are after, even though this is just a one page layout right now. Let’s fix that.

CSS

At its very core, the CSS powering this ajax-looking mechanism is very simple; just set the pages to not display, and then display them when they are the target, like so.

.page { display: none; }
.page:target { display: block; }

If you take a look at it, however, you will notice a couple issues.

The first (depending on your browser; it doesn’t seem to happen in Opera), is that, if the page has enough content to require scrolling, the page will jump down a bit so the header is off screen. This isn’t a huge issue, but it can be a bit jarring, and doesn’t really give us the effect we’re looking for.

The main problem, however, is that if you just load the page, without any hash, nothing appears on the content. There is no item that is a target so nothing shows up unless you click a link. Lucky for us, both of these are fixable with a little CSS trickery.

Bug Fixing

Fixing the “jump” effect is pretty easy. When you go to an anchored item, the browser puts the top of that item at the top of the screen. We can work around this through the use of top padding and a negative top margin. To do this, we will need to know the complete height (height, plus margins) of the content that will appear above the page content. A quick check with firebug shows that the site header on this page is 92px tall, and has 10px padding on top and bottom, giving a total of 112px. Therefore, our new page target rule should be as follows:

.page:target {
  display: block;
  margin-top: -112px;
  padding-top: 112px;
}

To fix the homepage issue, however, will take a bit more work. The first thing we’ll have to do is move the “#home” page to the bottom of the “#site-wrapper” div (I’ll explain in a second), so our layout is now like this:

<section class="page" id="about">
  <!--"About Us" Content Goes Here -->
</section>
<section class="page" id="contact">
 <!--"Contact" Content Goes Here -->
</section>
<section class="page" id="home">
  <!--"Home" Content Goes Here -->
</section>

And now, we change the CSS to the following:

.page, .page:target ~ #home{
  display: none;
}
#home, .page:target {
  display: block;
  margin-top: -112px;
  padding-top: 112px;
}

What we’re doing here is leveraging CSS specificity and the sibling selector to work our magic. The first rule says to make anything with a class of “page” not display. Also, if an item has an id of “home”, and it is preceded by an item with a class of “page” and is the target of the hash, then don’t display it either. This makes the homepage vanish if any other page is being displayed, and explains why we had to move the “#home” page to the bottom, as the sibling selector can’t be used to relate an element to one that comes after it, sadly.

The second rule makes a page display if it is the target, or if it has the id “home”. The home rule is overridden by the one above, when it applies, and also makes any other page be displayed when it is the target.

Give it a look.

A Little Extra Polish

Now, we’ve got this all working nicely, but can we make it a bit more flashy? Chris Coyier’s example had a quick fade transition between pages. With a little more CSS tweaking, we can get the same for our page.

The first thing we have to do is get rid of our use of “display: none;”. It’s nice and compact, but it doesn’t really work with CSS transitions. so instead, we’ll set it up as follows:

.page, .page:target ~ #home {
  position: absolute;
  height: 0;
  left: -1000%;
  opacity: 0;
  -webkit-transition: opacity 0.5s ease-out;
  -moz-transition: opacity 0.5s ease-out;
  -o-transition: opacity 0.5s ease-out;
  -ms-transition: opacity 0.5s ease-out;
  transition: opacity 0.5s ease-out;
}

This sets the content off to the side, makes it invisible, and preps it for transitioning when we click on a link. To get that working, we change our display code to the following:

#home, .page:target {
  position: static;
  opacity: 1;
  height: auto;
  margin-top: -112px;
  padding-top: 112px;
}

And here it is in operation.

Not bad, eh?

IE Support?

Now, I’m sure that many of you are unleashing that perennial web dev query “What about IE?”. And of course, IE comes along and buggerizes everything. As you might have guessed, IE6 doesn’t support the :target pseudo-class. Nor does IE7. Or IE8.

Damn.

So, what do we do? Are we out of luck? Fortunately, it’s pretty easy to implement an IE fix with JavaScript, which we’ll be looking at in part two of this tutorial, as well as discussing whether or not this technique has any practical applications. Until then!

We are, however, no longer just making simple static pages. Even if we’re not making full-on web apps, we still probably are including much more dynamism than we might have ever thought would be even five years ago. And with this increased power comes an increased responsibility for usability. This is where the cursor icon comes in handy.

Users have for years now seen the cursor, both on the desktop and increasingly on the web, as a way to tell what something they’re hovering over is. Does it have the little pointy finger? Then it’s probably something to click. Does it have the little hourglass or the spinning circle? Then the page is probably doing something in the background.

We can leverage this familiarity in our own designs. For example, if your page is going to do something that might take a second (like an AJAX request, perhaps), it’s generally a good idea to give your user some immediate feedback, to let them know that the click was received and that you’re working on it. In that case, setting the <body> element’s cursor value to “wait” or “progress” might be a good way to let your users know that you’re on the job.

Or maybe you have images that can be clicked on to open up a lightbox. Be sure to set the <img> elements’ cursor to “pointer” to show the users that the pics accept clicks. This could be used with other effects, like lightening or darkening the image on a hover, but it could also used by itself. In fact, I’d honestly think that the simpler, cursor-only way might be more intuitive to users, as I’d imagine they wouldn’t have to think as much about what the change might mean.

These are just a couple ideas I had writing this. Another might be using the “move” value if your page/app has any drag-and-drop functionality. And of course, there’s always the “url()” value, if you want to get creative. Go give the spec on the cursor a look. See if it sparks any ideas. Oh, and if you think of something cool, be sure to share it in the comments!

Edit: I just found this article, which also talks about cursor customization, and even discusses the coming CSS3 cursor options. Give it a look.

To prepare for this, we’re going to have to start adopting responsive design. It may seem like it’s more work, but after dabbling with it a bit, I’m wishing I’d started looking into it earlier. Not only does it make it easier to tailor design for different users, but it’s also helped me break structure away from design. It forces you to start thinking of the page in terms of functional units; the things that have to stick together somehow no matter how the page might change. It’s really helped me see what exactly a page is, rather than just a flow of content. In a way, it’s doing the same thing that my adoption of semantic markup got me doing. That, however, is a discussion for another day (soon).

In the meantime, happy reading, happy coding, and a happy holiday season to you all!

Hope you all like it!

I don’t want to just rehash the content of the article, but I’ll give a quick overview. Dark patterns (which are also being gathered here) are basically using our skills to decieve our users and trick them into signing up for something, or even paying for something they didn’t intend to. These are rather extreme examples though; very clearly “bad”. But what about having users signing up for a newsletter by default when they check out, with the option to opt out? Is that wrong?

Thankfully, the article doesn’t treat this as a black-and-white issue. There are plenty of situations of lighter or darker grey, and the article does a good job of exploring them.

Personally, I hope that the article, or ones like it, might spawn a more generalized discussion of ethics in the web development community. If the field is to become a full fledged profession, we could do well to work for a generally agreed-upon set of ethical guidelines. I don’t think that we’d ever have anything like the AMA’s or the Bar’s ethical boards, and we probably don’t need it.

That being said, with every day the web becomes a bigger and bigger piece of our economy, and our lives. If we’re designing the pages and apps where people buy and sell, learn and grow, then we need to recognize that we’ve been given power of a sort. With such power comes responsibility, and we if we ignore it, we do so at our, and society’s, detriment.

Be good.

First, it’s on the bleeding edge, support-wise. Only the latest versions of Chrome, Safari 5.1+ (an earlier API can be used with 5.0), and the Firefox nightlies support it. So don’t go thinking this will be ready for prime time as a piece of core functionality for a while,  at least a year I’d wager, if not longer (especially if IE10 doesn’t support it). It will probably be a nice bit of progressive enhancement in the mean time, especially for doing things like enabling fullscreen HTML5 video.

Now, if you are going to be using this tech, I strongly suggest you have a persistent explanation of how to exit the full screen. This is something that is thankfully in the video demo given in the article, but not in the simple demo. The simple demo just has a small text box that says “Exit Full Screen (F11)” that goes away after a second, only reappearing if your mouse goes near the top of the page. This is not enough, and I spent a minute clicking “escape” and other buttons trying to get back out (I missed the instructions as I was reading the text).  It doesn’t need to be much, but a familiar “[x]” in the top right would have been most welcome. In fact simple title bar would probably be a wise thing to include. Just make sure that it’s something that the user can click, and something they can always see.

Correlated Stats

If you look at most of the stat websites I looked at, you can see things like what percentage of users still use IE6 or the latest version of Chrome. You can see what resolutions are the most popular. You can (on some sites) see what percentage of users have JavaScript enabled. But I don’t know of any site that will let you combine these statistics.

For instance, say you want to use a JavaScript polyfill to support IE 7 and below. For the sake of argument, let’s assume your stats site of choice says that IE6 & IE7 combine for 15% of all users. Then let’s assume that the same site says JavaScript isn’t supported by 3% of users. If you assume the two stats map evenly, you would get a percentage of 0.45%, or about 1 in 200, that use IE7 and below; probably won’t be worth supporting. But is that last assumption, that the two stats map evenly, valid?

I think it might not be. Think about it; who uses these older browsers? The less than very tech savvy (my parents would still be using IE6 if I hadn’t intervened), and people at companies that won’t upgrade from their current browser. They’re also the types of people I think are more likely to have disabled JavaScript, either because they read years ago that it might be dangerous to allow JavaScript, or because they have a corporate policy that disallows it. Maybe half of that 3% of users without JavaScript are also using IE7 and below.

This is probably an extreme example, but I think it would be nice if you could go to a site and ask for the percentage of users with, say, JavaScript enabled, using some version of IE, and with a resolution width greater than 1200px. I don’t think it would be that hard to implement: you could probably do it with a single (long) MySQL table of data.

Niche Stats

I actually though of this one while writing the last post, and we sort of have, to a limited extent. If you recall, I said that the W3Schools.com page might be more helpful if you’re designing something for web developers, i.e. with a similar target audience to W3Schools. That’s an example of niche site stats. It’s nice, but what if we had more than that. What if we could look at the stats of just eCommerce sites? Or of sites that target corporate clients almost exclusively? Some sites may be fairly universal – I’d imagine Google or Yahoo’s site stats are nigh indistinguishable from the Internet’s as a whole – but surely there are different genres of site that pull in users with stats that typically vary somewhat from the norm.

If you remember from last time, I said that the best stats you can have are the one’s from your site, so you can tailor your site to your actual audience. I think niche stats would provide a bit of a bridge between personalized stats and the universal stats you can get from the sites I’d reviewed.

That’s all I’ve got on my wishlist, stat-wise. What about you all? Can you think of anything else that would be a nice addition to our user stat toolbox?

Sometimes, however, this isn’t really an option. Maybe you’re just getting started with a site, and don’t have any users to analyze (yet). Or maybe you’re designing a template to sell or give away. Then, the user base might vary from installation to installation. One would hope that the people using the template would start using analytic software and tweak the site accordingly. This isn’t something you can count on, however, and in any event, if you’re putting something “out there” for the public to use, it should work right out of the box. In that case, you probably want to use some kind of statistics site.

But which one to believe? There are a number of sites out there, often with varying conclusions. Here are the top ones I’m familiar with, and what I think of them.

The Good: Global Web Stats by W3Counter.com

This site is pretty good. Their stats seem to be, by and large, accurate. They draw their info from over 50,000 websites (who have installed their plugin and have an account with them), so it has a pretty wide source base. They also cover a variety of areas, including browser (the biggie), resolution, and OS (which can impact things like fonts).

My only real gripe with the site is that their data is a bit shallow. They list browser versions for IE, but I didn’t see any for other browsers. It just feels more like a summary than a report, if that makes sense. And, of course, there’s the issue of it competing with the next site on our list.

The Great: Global Stats by StatCounter.com

This site is awesome. It’s got a lot of great info, but the best thing about it is how customizable it is. Want to know worldwide browser stats? That’s the default. What about the browser stats of just the US? Easy enough to filter. It’s good because it let’s you get a feel of where different parts of the world are at. China is still pretty big on IE6 (shudder). And where else are you going to see the dramatic fall of Safari 5 in Antarctica?

All in all, Global Stats provides a nice mix of depth and customizability, along with ease of use. It’s my first stop whenever I need to look at user info.

The Almost as Great: NetMarketShare

This site too is pretty sweet. It’s got a lot of info for your perusal, and gets into the nitty gritty of usage, even giving items with a few hundredths of a percent. If you’re looking for detailed information, it’s pretty much the best place to go. However, there are two issues I have with it, that make it slightly less great that Global Stats, to me at least.

First, there is something of an information overload. If you’re just wanting to get a general overview, all the information they have is a bit much, and if you try filtering what you look at, you can get some odd results. Second, and this is just a personal pet peeve, but I don’t like that they have information behind a subscription paywall, and they don’t tell you that it’s there until you request to see the info. That second part is the real irker. I don’t mind having things behind a paywall, but I’d like to know what I can and can’t see before I try to see it. It just leaves me with a bit of disappointment when I try to view something, and then get told I can’t. And compared with the customization of stat parameters Global Stats allows, it feels a bit of a letdown.

These complaints are pretty minor, however, and it’s still a good site to check out.

The Not-So-Great: Browser Statistics by W3Schools.com

This resource is… ok. In certain circumstances. It has a number of issues (as does W3Schools in general), the most severe of which is selection bias. Simply put, the stats they give are based on traffic to W3Schools.com. In general, you might expect that visitors to a site on web development might skew a bit to the more tech savvy. You might expect more of them to be using up to date browsers instead of older IE versions. You might expect them to be more likely to have bigger screens. And, in general, that’s what you find. When you compare the W3Schools stats with other sites, you find that the W3School user pool is much more tech friendly than the public at large.

And this isn’t just my take on them. If you look near the bottom of their stat page, they have the following disclaimer:

W3Schools is a website for people with an interest for web technologies. These people are more interested in using alternative browsers than the average user. The average user tends to the browser that comes preinstalled with their computer, and do not seek out other browser alternatives.

These facts indicate that the browser figures above are not 100% realistic. Other web sites have statistics showing that Internet Explorer is a more popular browser.

Anyway, our data, collected from W3Schools’ log-files, over many years, clearly shows the long and medium-term trends.

Now, this does not mean that their stats are necessarily wrong, or even useless. If you are designing a site that you expect to have a fairly tech competent user base (like, say, a web design/development blog), then your users will probably be closer to the type that might visit W3Schools, rather than the average user pool. In this case, it might be worth basing your decisions off of this site.