shift+control

76design's blog

Archive for the 'CSS/XHTML' Category

Design-feed

Posted by Brett Tackaberry on February 9th, 2007 Comments 2 Comments

http://design-feed.net

“Design-Feed is a design feed aggregator. [Design-feed] hand-pick the most interesting design related RSS feeds and present them in an easy-to-browse format. This means you can get all the latest design news in one place, rather than trawling through hundreds of sites a day. Every post aggregated is also searchable by keyword.”

Where’s my target=”_tab”?

Posted by 76design on December 21st, 2006 Comments 4 Comments

I’ve been using the target=”_blank” attribute in my «a» tags since before my first Tea Party fansite ever graced the hallowed pages of Geocities. Fast forward to what will soon be 2007 and we now have the ability to have multiple tabs instead of a bunch of floating windows all over your desktop. So when will we be able to tell HTML links to open in a new tab as opposed to a new window?

This “innovation” (the kind of innovation where you wonder why it wasn’t that way the whole time) has finally been adopted by the big M (only four years later, I might add), so we can officially call it a “standard”. Now it’s time to ask ourselves: When will HTML catch up to current browser technology?

There are still uses for the “new window” link, so I wouldn’t want to eliminate it entirely. I think it should be up to the designer/programmer to decide which link is appropriate; either link in the current window, open a new tab or open a new window. It would be one more level of functionality that could be used to better serve the website’s needs.

There are a TON of uses for this “tab link” idea. For on-line orders, you could have your regular shopping tunnel in the current window, but Terms and Conditions could be viewed in a separate tab, as opposed to having a whole new window pop up, possibly confusing the user.

Someone needs to give our old pal Tim a call and ask him when we can have a link with target=”_tab” in it!

4 Seconds… Your Website Has to Respond Quickly

Posted by Brett Tackaberry on November 9th, 2006 Comments 3 Comments

Akamai and JupiterResearch have released a report announcing that 4 seconds is the “maximum length of time an average online shopper will wait for a web page to load”. The report focuses on retail sites (no surprise with the holiday season only weeks away) but the message rings true for just about any site and extends well beyond online shopping. As with any site that seeks to engage customers or clients – be it a specialty record store, a nationwide clothing chain or a professional services firm – the customer experience is paramount and that experience starts with the moment a visitor types your web address into their browser. A site that takes 10 seconds just to load is going to irritate any user that cares to wait that long.

The report notes that most shoppers who have had experience purchasing online cite page load time as a “top priority”, adding that a site’s navigation during key moments of the transaction – registration, log-in and check out – as another important factor.

So what can you do to put a little spring in your site’s step? A page that isn’t top-heavy (and by that I mean: relies on graphics, scripts and multimedia elements) generally loads pretty quickly. That doesn’t mean that you can’t include any of that stuff – just do it in a smart way that ensures the important parts of the page like the navigation load first and are available to the user before the eye candy fills in. How do you do that? Well, text should be used wherever possible for page headings and menus (this is obviously beneficial for SEO as well), graphics should be included in style sheets to keep your HTML markup lean and elements like Flash should be included using something like SWFobject.

Obviously a lot of other variables come into play like the user’s connection speed and proximity to the server but making a few small changes to how a page is built behind-the-scenes can go a long way to ensuring your site responds quickly without sacrificing any of its design integrity.

Something fresh… but fresh for how long?

Posted by Brett Tackaberry on October 18th, 2006 Comments Comments Off

Shaun Inman, web development guru and exceedingly smart guy, has launched the 9th version of his personal site this week. What makes this particular redesign noteworthy is the new dimension he’s added to an otherwise no-frills blog: each post and comment is associated with the moment in time that it was created and, as in the natural world, it “decays” (i.e. fades in colour) as time passes. Posts a year old are noticeably lighter than posts written last week. I think it’s a real innovative twist on the typical notion of a blog and something that is perfectly suited to what Shaun writes about – technology and the web. It’s pretty much a given that something written two years ago is probably out of date and becoming irrelevant, so why not make that immediately apparent in the design when a visitor stumbles onto an old post on your site via a direct link on Google?

Shaun’s always been on the cutting edge and I think he’s clearly demonstrated he’s a step ahead once again. I’m certain that this low-level, almost subconscious approach to navigation – something that Boxes and Arrows’ Ross Howard recently dubbed ambient signifiers – will become more and more prevalent on the web. Especially in the social media landscape. However the key to its success, I believe, is the adherence to a universal standard or set of best practices when it comes to how we as designers communicate to users on this level. For example, if one site darkens its colour palette slightly when you’re logged in and another lightens theirs slightly, the inconsistency will muddle the message and users will be forced to fall back on design cues that force them to think – icons and text – rather than feel their way along.

To Print or Not To Print

Posted by Brett Tackaberry on May 16th, 2006 Comments Comments Off

Just about everybody knows that you can specify what media a CSS style sheet applies to – whether it’s for print, screen or both. When users want to print pages on your site, this allows you to deliver up a specially constructed style sheet that hides things that you’d rather not have print (ads, navigation, etc.) and adds things that you’d rather not have on screen (maybe some kind of letterhead or a page footer) so that it’s print-friendly. In this respect, CSS has done wonders for making content on the web that much more ubiquitous and practically sounded the death knoll for the old fashioned technique of having a “Printer Friendly” button that links to a pop-up or new window containing an unformatted version of the original page.

I’d like to share a technique that I’ve found useful when setting up sites to be print-friendly. First off, declare your respective stylesheets in the document head:

<link media="screen" href="default.css" type="text/css" rel="stylesheet" />
<link media="print" href="print.css" type="text/css" rel="stylesheet" />

As you can see, default.css is for the screen and print.css is for printing. Now, in the actual markup what I’ll do is add classes called “print” and “noprint” to various elements:

<h1 class="print">This is a Printed Headline</h1><p>This will show up on screen and when printed.</p>

<img src="photo.jpg"Â class="noprint" alt="This photo will be shown on screen only" />

In case it’s not evident at this point, what I’m doing here is indicating which elements will be for print only and which are for screen only. Everything else will be displayed on both.

Now in my screen stylesheet, default.css, I’ll add the following styles:

.print { display: none; }
.noprint { display: block; }

And in the print stylesheet, print.css, I’ll reverse it:

.print { display: block; }
.noprint { display: none; }

Now it’s easy for me to globally show (or hide) elements depending on the medium we’re in – screen or print. Nothing groundbreaking here, but this a lot cleaner than addressing each element one by one in your stylesheet.

Cutting Corners

Posted by 76design on March 29th, 2006 Comments Comments Off

Oh, the wonderful rounded-corner box. It’s very popular online these days. As developers and designers we’re always trying to do it leaner and meaner. On the weekend I caught a great link on Del.icio.us that led me to Spiffy Corners, one of the best rounded-corner techniques I’ve seen yet.

No JavaScript, no images. Just CSS… and it’s anti-aliased. Steve mentioned to me that Spiffy Corners creator Greg Johnson plans to add variable corner radius support soon. Sounds great to me!