close
The Wayback Machine - https://web.archive.org/web/20110622070739/http://www.webmonkey.com:80/
Jun162011
File Under: CSS, UI/UX, Visual Design, Web Basics

Take Responsive Design Beyond the (Fluid) Grid

We’ve given you a look at some best practices for responsive design, but beyond the nuts and bolts of @media queries and flexible grids, there is something more subtle, and more important, at work behind the moniker responsive design.

Good design has always been about not just putting content first, but making it easy to read that content — give people what they’re looking for or they will go elsewhere.

It sounds rather basic, but if good, content-driven design were actually common on the web, then we wouldn’t need tools like Readability, Safari’s Reader or Instapaper, which are all services that strip out superflous distractions and give people what they want — content. If you’ve read through our guide to designing for readability first, hopefully you’re already streamlining your website and focusing on the content rather than sidebar, ads and other distractions. Responsive design picks up where that idea leaves off.

The cornerstone of any responsive design is a flexible grid system that adapts to different screen sizes, but that’s really the least interesting aspect once you master it. In the larger sense, responsive design is not about fluid grids, it’s about determining the constraints of the reader’s screen and how those constraints change the way your site needs to display. It’s about shifting your content based on the screen size of your reader and ensuring that your visitors have the best experience regardless of what device they might use.

In other words, responsive design is about making sure that the reading device being used doesn’t matter. Screen size is the obvious place to start. The constraints of small screens dictate some design choices, for example a single column of content, and means putting the primary content at the top of the page. It also mean ensuring your typography looks good. For example, the typical desktop browser font sizes of 14-16px often feel too small on an iPad.

But screen size isn’t the only thing to bear in mind when you’re building your site. Don’t ignore other aspects of today’s myriad mobile devices, like touch-based interfaces, access to GPS data or screen resolution. For example, your site might have a nice flexible grid, but if half your links require a hover state to be noticed, your site is no more “responsive” for a touch screen user than the average archived Geocities page. Also consider the impact of transitions and animations which can help guide users and create a greater feeling of responsiveness.

Different devices also have different built-in tools. Test for things like geolocation support using Modernizer and if the device supports it, use it. For example, a location-based form that works well on your desktop site might be better served by using the location data automatically on a mobile site.

In the end responsive design is not just about the size of the screen, it’s about how your arrange you information to give people what they want. Every site is different and you if simply jump on the flexible grid bandwagon without giving proper thought to your unique content, you’re not going to have an effective website.

See Also:

Jun142011
File Under: Uncategorized

CSS 3 Box Shadow Showcases Browser Differences

BERJAYAThe CSS 3 box-shadow property allows for drop shadows and other gradient-based effects without the need for images or other hacks. Box shadow works in Firefox 3+, Chrome, Safari, Opera and Internet Explorer 9. Older versions of IE will ignore the rule, but in most cases losing the shadows won’t be catastrophic for your design.

Box Shadows are handy and can do a lot more than just create a shadow effect. Check out this experiment for some examples of the myriad effects you can achieve with just a few box shadow rules (note that some only work in WebKit browsers). However, the box-shadow rule also showcases the ever-present differences between web browsers — even when the browsers all handle the CSS just fine.

While box-shadow works in all the browsers listed above, that doesn’t mean that it looks the same in every browser. For an interesting look at the variety of ways web browsers display box-shadow, head over to this handy guide to box shadow.

As you can see from the screenshot above, there’s considerable variation between the four browsers — everything from the almost non-existant shadow in some IE 9 examples, to the much heavier shadows in Firefox 4. That’s not to say that any one of them is right and the others wrong, just that there are differences. You’ll also find quite a bit of variation in font display and CSS gradients.

The point is, no matter how hard you try, you’re never going to to have pixel perfect rendering across web browsers. Nor do you need pixel perfect rendering across browsers. The real lesson of box shadows is that there will be variety, so stop worrying and get on with creating.

See Also:

Jun92011
File Under: CSS, JavaScript, Mobile, UI/UX, Visual Design, Web Basics, Web Standards

Tips, Tricks and Best Practices for Responsive Design

BERJAYAUnless you’ve been too busy wake boarding the Alps to notice, there’s a movement afoot amongst web designers — Responsive Design. Ethan Marcotte coined the term responsive design to describe the process of using liquid layouts and media queries to scale websites so that they fit any screen size. If you’ve never heard of responsive design before, Marcotte’s introduction is well worth a read.

In a nutshell, responsive design means using fluid grids, fluid layouts and @media queries to adapt your website to the plethora of different screen sizes on today’s (and tomorrow’s) web. Whether your visitor is on a phone, an iPad or a gargantuan desktop monitor, your website adapts.

Responsive design becomes an even more appealing tool when you start, as Luke Wroblewski says, designing for mobile first. That is, start with the small screen. Strip your site down to its essence and then build from there. Starting from the bare bones ensures a great mobile site, and it forces you to really focus on what matters to your visitors.

So how do you go about building a good responsive site? Well, that depends on the individual website, but there are some common patterns that are starting to emerge. To help you get started with responsive design, here are a few nascent best practices we’ve gleaned from a variety of sources around the web:

  • Use @media to scale your layout for any screen, but remember that this alone isn’t really responsive design.
  • Use liquid layouts that can accommodate any screen size. Don’t simply design one look for the iPhone/Android, one for tablets and one for the desktop. Keep it liquid, otherwise what happens when some new, intermediate screen size suddenly becomes popular?
  • Roll your own grids based on the specifics of your site’s content. Canned grid systems will rarely fit the bill. The problem with canned grids is that they don’t fit your unique content. Create layouts from the content out, rather than the canvas (or grid) in.
  • Start small. Start with the smallest size screen and work your way up, adding @media rules to float elements into the larger windows of tablet and desktop browsers. Start with a narrow, single-column layout to handle mobile browsers and then scale up from there rather than the other way around.
  • Use the Respond or CSS3 Media Queries JavaScript libraries to bootstrap @media query support into older browsers that won’t otherwise know what to do with it. Starting with the smallest screen and working your way up means it’s the desktop browsers that need to handle @media, make sure older browsers work by using polyfills like Respond.
  • Forget Photoshop, build your comps in the browser. It’s virtually impossible to mock up liquid layouts in Photoshop, start in the browser instead.
  • Scale images using img { max-width: 100%; }. For very large images, consider using something like Responsive Images to offer the very smallest screens smaller image downloads and then use JavaScript to swap in larger images for larger screen.
  • Embrace lazy loading. There may be items on your site, auxiliary content that’s nice to have, but not essential. Load that content using JavaScript after the primary content is done loading.
  • Forget about perfect. Even with these suggestions you’re still leaving out users who have old browsers with JavaScript disabled. Such users are increasingly rare and if they see the mobile layout on their desktop, guess what, it’s not the end of the world. Your site is still perfectly usable.

Keep in mind of course that responsive design is a young idea and new ideas — and new tools — pop up everyday. Think of these not as hard and fast rules, but guidelines to build on.

See Also:

Jun72011
File Under: CSS, Web Basics

Create Image Sprites the Easy Way

BERJAYAIf you’ve ever used Google’s Page Speed or Yahoo’s YSlow to optimize your website chances are you’ve seen a suggestion to “use CSS sprites.” CSS sprites reduce HTTP requests by combining multiple images into a single file which you can then display throughout your page, positioning it as need with the CSS background-position property.

Typically sprites are used for small images — like icon sets or small logo images — though you can use them for larger images as well.

The only problem with sprites is that creating them can be a hassle, particularly if you need a rather large sprite, say all the icons in an online game. Opening dozens of tiny icon images and pasting them into a single document is time-consuming. Fortunately there’s the CSS Sprite Generator, which takes a zipped file of all your images and gives you a single image sprite.

The CSS Sprite Generator even has options to fix a bug in older version of Opera, resize the width and height of the input images and generate CSS classes to apply your sprites to the right elements.

See Also:

Jun22011
File Under: HTML5, JavaScript

Load Only What You Need With Yepnope.js

BERJAYAIf you’ve started using HTML5 and CSS 3 in your projects, chances are you’re using Modernizr to detect for features and gracefully degrade for those browsers that don’t support the latest and greatest on the web.

Modernizr adds classnames to your page which you can then use for browsers that support the HTML5 features you’re using. It’s a great tool, but it does have some overhead; wouldn’t it be cooler if you could just test for features and load polyfills all in one step?

That’s the thinking behind the powerful (and cleverly named) Yepnope.js. Yepnope is an asynchronous conditional resource loader which loads only the scripts that your users need. And at 1.6kb it won’t add much overhead to your page.

In fact, Yepnope.js is so handy it will be integrated into Modernizr 2, which is currently a beta release.

That said, Yepnope.js isn’t right for every situation and the project freely admits that some other conditional loaders are a bit faster. One gotcha to be aware of is that Yepnope.js requires that your server sends proper cache headers. Hopefully your sever does, but with some shared hosting setups that just isn’t possible.

If Yepnope.js doesn’t do quite what you want there are other options like the larger, but more feature-rich RequireJS.

See Also:

May302011
File Under: Uncategorized

Stop Typekit Fonts From Slowing Down Your Site

That's a fancy-lookin' T you got there.

That’s a fancy-lookin’ T you got there.

Typekit is one of the easiest ways to get fancy fonts working on your website. Just sign up for an account, pick a font and paste a few lines of code into your pages. TypeKit takes care of the rest, ensuring that your fonts load and there’s no unsightly flash of unstyled content (FOUT) or other problems.

There is, however, one possible problem with the default way of embedding Typekit fonts. If the TypeKit code fails to load, it can slow down the rest of your site. Typekit avoids FOUT by pausing your page load for a fraction of a second, but if the Typekit script never finishes loading, that fraction of a second can turn into many seconds. While Typekit has excellent uptime, let’s face it, outages happen, and we understand if you don’t want to hang your own site’s fate on another.

For those worried about depending on Typekit there is a workaround — load Typekit scripts asynchronously. The Typekit blog recently put posted an in-depth look at various way to embed Typekit fonts in your pages, including an asynchronous method which won’t slow down your page should Typekit become temporarily unavailable.

The disadvantage of the asynchronous design pattern that Typekit outlines is that it means a bit of extra code in your pages. Most likely a few more bytes in your HTML isn’t going to cause a significant speed hit, but it is something to keep in mind.

See Also:

May252011
File Under: CSS, JavaScript, Software & Tools, Web Standards

Review: Hype Animates the Web, No Flash Necessary

BERJAYATo create animations using web standards like HTML5, CSS 3 and JavaScript requires writing code. That’s fine for programmers who love nothing more than the blank space of a new document in their favorite text editor, but it’s a problem for designers accustomed to the visual, drag-and-drop workflow of animation apps like Flash. There’s nothing quite like Adobe’s Flash application for designers who want to stick with web standards.

Hype is hoping to change that. The new Mac OS X application uses many of the familiar interface elements that Adobe Flash offers — timelines, keyframes and drag-and-drop editing — but generates web standards output consisting of HTML, CSS and JavaScript. In short, Hype hopes to be to standards-based animation what the Flash app is to creating Flash movies.

While the initial release of Hype is impressive, it’s far from a Flash replacement. Perhaps more disappointing is that animations created with Hype suffer some of the same drawbacks you’ll encounter when using Flash.

The Good

For those with a background in Flash, the Hype learning curve is very short. Hype’s menu layout and palette structures are different, but the basic elements are essentially the same. To use Hype you drag objects — images, videos, vector art, etc — onto the stage and then you animate them by creating keyframes. One thing that’s different from Flash is Hype’s very handy “record” feature. To animate an element, just get everything where you want it for the first frame, add a new keyframe and then click record. Everything you do after that is recorded and translated into CSS and JavaScript-based animation.

To create a more complete movie-like animation Hype uses scenes, which break up your content and allow you to create transitions. For example, to create a slideshow, just drag your images into Hype and then create a new scene for each image. Add some transitions and you’re on your way. (That’s not the only way to create a slideshow, but it’s one of the simplest.)

Hype doesn’t offer everything you’ll find in Flash. Most notably there is no concept of MovieClips — self-contained movies within movies. There’s also no equivalent to Flash’s customizable tweens and advanced filters for blending objects.

Hype does offers plenty of canned elements, like buttons, boxes, and text boxes, to speed up simple tasks like adding text and other elements to your animations. To add elements to your page you just head to the Insert menu, select what you want and then you can style it with the properties palette just like you would any other element in Hype.

BERJAYA

Hype's Flash-like IDE makes animating easy

Hype is simple enough to use that I was able to download a copy, watch the intro movie and five minutes later I generated the simple animation at the bottom of this post. Naturally to create something more interesting and useful will take you a bit longer, but it’s nothing compared to writing out the CSS and scripts by hand.

While Hype is primarily a visual editor, there are options to access properties like an element’s innerHTML and the Identity palette allows you to customize element IDs so you can target that element from other scripts. This is particularly handy if you want to create some custom CSS on top of what Hype generates.

The Bad

Hype, despite what its marketing materials claim, does not generate HTML5. It generates good old (standards compliant) HTML 4, CSS and JavaScript. That shouldn’t detract from from what Hype is capable of, but it’s disappointing to see the amount of HTML5, ahem, hype, surrounding Hype. Hype doesn’t even use canvas elements (animations are wrapped in div tags), nor does it use any of the new APIs (like say History or Web Workers).

Perhaps most disappointingly Hype doesn’t use the HTML5 History API. Because of the way Hype documents are embedded in a page, like Flash animations, Hype breaks the browser’s back button. What’s even more disappointing about Hype breaking the back button is that it’s not necessary. If Hype supported the History API, Hype documents could easily update the URL and not break one of the most fundamental elements of the web (see Mark Pilgrim’s excellent write up in the History API for more details on how to use it).

In some use cases that won’t matter, but if you’re thinking Hype would make a great slideshow creator, well, keep in mind that no one will ever be able to link to your individual photos without some extra effort on your part. Similarly, any transitions that happen in any Hype animation won’t be accessible via the back button.

Hype does offer an embedded editor so you can hook up the JavaScript yourself and take advantage of the History API, but then you’re back to writing code yourself.

Hype also makes some assumptions about your site structure when it generates HTML and JS. If you’ve got FTP access to your server then there’s nothing to worry about. But to embed my simple Hype animation in this post I had to change quite a few file references in the code. Hype assumes that all the resources it needs are in the resources folder it creates. Since I don’t have FTP access to this domain there is no way to get that folder on the server. Instead I uploaded the three required files through WordPress and then had to edit the generated Hype code to add the correct file paths. It wasn’t all that hard, but it did mean digging into the code, which at least partially defeats the purpose of Hype.

Another things to keep in mind is that Hype is heavily geared toward the WebKit rendering engine. While most of the effects work just fine in other standards compliant browsers, there are a few things that only work in WebKit. Where possible Hype falls back to pure JavaScript (for example in browsers that don’t understand CSS 3). Fortunately the Hype export function will warn you about any browser incompatibilities when you publish.

Conclusion

Despite some publishing hiccups and a few missing features, Hype is still one of the easiest ways I’ve seen to create Flash-free web animations. It’s like having most of what’s good about Adobe’s Flash app, without the downside of publishing to the Flash file format. Sadly Hype still falls prey to some of Flash’s weaknesses, but this is a 1.0 release and no doubt Hype will improve as time goes on.

Hype is currently available for $30 in the Mac app store. If you’ve been wanting to transition from Flash-based animations to web standards, but haven’t wanted to wade through the complexities of JavaScript and CSS 3, Hype is the droids you’ve been looking for. Just bear in mind that it has a few shortcomings of its own.

Hype Example

Here’s a very simple example of an animation created with Hype. Use the WebKit Inspector or Firebug to see how it works.

May242011
File Under: Browsers

Mozilla Rejects WebP Image Format, Google Adds it to Picasa

BERJAYAGoogle built the royalty-free WebM video format with the sophisticated VP8 compression technology that it obtained in its 2009 acquisition of On2. In addition to advancing the goal of open video for the Web, the search giant also used On2 technology to build a new image format called WebP with the aim of reducing page load time by increasing the efficiency of image compression.

WebP uses some of the still-image compression techniques that VP8 relies on to compress individual video frames. The format is intended for use with lossy images as an alternative to the venerable JPEG. Google conducted a large-scale study demonstrating that WebP offers an average file size savings of 39 percent. Despite the seemingly impressive results, not everybody is convinced by Google’s findings. Mozilla, which has officially refused to support the format in Firefox, has emerged as one of WebP’s most prominent opponents.

BERJAYA

Building mainstream support for a new media format is challenging, especially when the advantages are ambiguous. WebM was attractive to some browser vendors because its royalty-free license arguably solved a real-world problem. According to critics, the advantages of WebP are illusory and don’t offer sufficient advantages over JPEG to justify adoption of the new format.

Aside from Google—which introduced official support for WebP in Chrome 12—Opera is the only other browser that natively supports the format. Despite the ease with which it can be supported, other browser vendors are reluctant to endorse the format and make it a permanent part of the Web landscape.

After studying quality and performance characteristics of WebP, Mozilla decided last month not to support the format. The WebP feature request in Mozilla’s bug tracker was resolved with the “WONFTIX” label and a number of community-supplied patches to enable the feature in Firefox were politely rejected.

“As the WebP image format exists currently, I won’t accept a patch for it. If and when that changes, I’ll happily re-evaluate my decision!” wrote Mozilla developer Joe Drew in a Bugzilla comment.

Mozilla’s Jeff Muizelaar offered a more detailed technical explanation about the problems with WebP in a blog post. His well-articulated critique sheds light on the problems with Google’s testing methodology, lays out the weaknesses in the WebP feature set, and explains Mozilla’s broader philosophical objections against indiscriminately adding new image formats to Firefox.

Muizelaar’s complaints about Google’s WebP testing methodology are familiar because they echo some of the concerns that were raised early on by other WebP critics like x264 developer Jason Garret-Glaser. The gist of it is that Google is using peak signal-to-noise ratio (PSNR) as its basis for quality comparisons—a technical benchmark that experts say fails to account for how images are actually perceived. Another problem is that Google recompressed existing JPEG images rather than starting with uncompressed source files. Both of these factors raise doubts about the validity of Google’s testing.

WebP’s lack of basic feature parity with JPEG in areas like metadata handling and ICC color profiles is identified by Muizelaar as another major problem with Google’s format. It also doesn’t add any important features that JPEG lacks, such as support for an alpha channel. He goes as far as using the phrase “half-baked” to describe the deficient WebP feature set.

Adopting a new image format in Web browsers is a big decision. Once a format becomes a part of the Web, it will have to be supported in perpetuity—adding overhead to the browser—even if it largely fizzles and only gains a small niche following. The chances of WebP attracting widespread use at this stage are very limited, so it seems prudent to avoid shoveling it into the browser.

Muizelaar argues that there is still room for further optimization by improving JPEG compression. The time that Google is putting into WebP, he says, would be better spent by improving JPEG encoders or contributing to existing next-generation image format efforts. One in particular that he cites as more promising than WebP is Microsoft’s JPEG XR, which has a better feature set than WebP, but also suffers from a lack of obvious quality advantages.

Google’s enthusiasm for WebP hasn’t been dampened by Mozilla’s criticism. A post published on Google’s official Chromium blog last week highlights a number of quality improvements in the implementation and discusses the growing number of third-party adopters. Most significantly, Google is adding WebP support to its own Web applications—including Picasa and GMail.

A new “fancy” upsampler that Google has integrated into the decoder implementation will reduce the pixelation of edges between colors in compressed images. The encoder has been improved with an experimental feature that it can selectively apply different compression and filtering behavior to various sections of the image in ways that will reduce the kind of “ringing” artifacts that are commonly seen in lossy images. The search giant also touts improved progressive loading support for WebP, which shipped in Chrome 12.

Despite WebP’s present limitations and lack of clear competitive advantages, it seems like Google is still making meaningful progress. The WebP format isn’t ready for widespread adoption today, but further optimization and perhaps a rethinking of the container format could someday make it successful.

This article originally appeared on Ars Technica, Wired’s sister site for in-depth technology news.

See Also:

May242011
File Under: Blog Publishing, Browsers

WordPress Drops Support for IE 6

BERJAYAThe popular blog publishing tool WordPress has joined the growing cadre of sites dropping support for Microsoft’s Internet Explorer 6 web browser. The recently upgraded WordPress.com brings a handful of new features and a revamped, cleaner design in the admin pages, but perhaps the biggest news in the release is that the admin pages no longer support IE 6.

Users visiting the admin section of WordPress.com with IE 6 will now see a message to upgrade their browser (the same message will appear in the self-hosted WordPress 3.2 when it is released in June). The WordPress blog says it’s dropping IE 6 because, “it has required increasingly complex code trickery to make the WordPress dashboard work in the IE 6 browser, which was introduced 10 years ago and does not support current web standards.”

WordPress is just the latest in a long list of sites that have abandoned IE 6, including Gmail, YouTube, Basecamp and hundreds of others.

Indeed you’d be hard pressed to find a web developer who wants to keep supporting IE 6. Even Microsoft has set up a website that essentially dances on the grave of IE 6 (after WordPress announced it would drop IE 6, Microsoft actually said “thank you WordPress“).

However, according to Net Applications, IE 6 still has almost 12 percent user share worldwide. In the U.S. the number is just under 3 percent, but in China it’s still nearly 35 percent.

Compounding the problem are the number of corporate intranets that require IE 6. Microsoft is hard at work trying to convince large corporations to upgrade — if you’re still using IE 6, that means you haven’t upgraded to Windows 7, which is Microsoft’s real goal with the kill IE 6 campaign — but for Microsoft’s biggest customers, upgrading means investing millions of dollars in new infrastructure.

While developers may enjoy dropping IE 6 because of its subpar support for web standards, for end users that’s generally not a concern. What is, or at least should be, the bigger concern for users is that IE 6 is less secure.

If you’re part of the tiny segment of users that can — but haven’t — upgraded from IE 6, we suggest doing so. Grab a copy of Firefox or Chrome and join the modern web.

See Also:

May232011
File Under: Uncategorized

Simplify Firefox: Experimental Add-on Hides the URL Bar

BERJAYA

LessChrome HD Offers a minimalist take on browser chrome

Mozilla Labs has released a new experimental Firefox add-on, dubbed LessChrome HD, which hides the URL bar to give webpages a bit more room. The idea is to only show the Firefox user interface when needed, the rest of the time the screen real estate is given over to the actual webpage.

The LessChrome HD experiment is available through the Mozilla Add-ons site and you can even try it out without restarting Firefox. LessChrome HD works in Firefox 4 and above.

LessChrome HD doesn’t dispense with the URL bar, it’s just hidden. Moving your mouse anywhere into the window chrome will reveal it, as will the old cmd-L keyboard shortcut or cmd-T to create a new tab. Mozilla refers to this as an “on-demand interface.” In other words, it’s there when you need to navigate and disappears when you’re just reading something on the page.

LessChrome HD is somewhat similar to the new hidden nav bar option in Chrome 13 and seems to hint at a new UI design direction for browsers: hiding the URL bar. The extra screen real estate is useful if you’re using a small screen laptop, but even if you’ve got a massive monitor the minimalist user interface helps focus your attention on the web page, rather than the web browser.

Not everyone likes this trend. Software developer Dave Winer likens the missing URL bar trend to building a house without a backdoor, writing that the URL bar is “the way you can be sure you can get somewhere even if all the powers-that-be don’t want you to go there.” I’d argue that LessChrome HD and Chrome 13’s URL bar experiments are more like hiding the backdoor than eliminating it. That said, I’d hate to see this become a default in any web browser. It seems to work well as it is — an add-on for those that want it, while those that don’t can safely ignore it.

See Also:

« OLDER POSTS