Archive for June, 2011

File Under: Blog Publishing
Jun
30
2011

WordPress 3.2: Write More, IE Less

By

WordPress has released an upgrade for the popular, self-hosted blogging platform. Unlike the last few WordPress upgrades, which focused on improving developer tools, WordPress 3.2 is primarily about changes ordinary users will appreciate. The revamped admin section, for instance, offers a new “distraction-free,” full screen editor, and, as we noted earlier, this version finally drops support for Internet Explorer 6.

If you’d like to upgrade, head over to the WordPress site and download a copy of WordPress 3.2.

The theme for WordPress’ latest incarnation is “faster and lighter.” That’s reflected in new tools like the simplified admin interface, which offers a fullscreen editor mode. The fullscreen mode is modeled on the interface found in writing apps like WriteRoom or OmmWriter, where the focus is primarily the text, and not the bells and whistles on the main new post page.

Another aspect of the faster and lighter motto for WordPress 3.2 means eliminating the cruft, also known as dropping support for IE 6. That won’t of course affect your site’s visitors (unless your theme has dropped IE 6), but it does mean that the WordPress 3.2 admin won’t work in IE 6, something to keep in mind if you’re upgrading a site that has numerous admin users.

For now WordPress hasn’t dropped support for IE 7, though an early outline of what to expect in WordPress 3.2 did say that this release will also start the end-of-life cycle for Internet Explorer 7.

For a full list of the new features found in WordPress 3.2, head over to the release notes page.

See Also:

Tags:
File Under: CSS, UI/UX, Visual Design, Web Basics
Jun
16
2011

Take Responsive Design Beyond the (Fluid) Grid

By

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:

Tags:
File Under: Uncategorized
Jun
14
2011

CSS 3 Box Shadow Showcases Browser Differences

By

The 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:

File Under: CSS, JavaScript, Mobile, UI/UX, Visual Design, Web Basics, Web Standards
Jun
9
2011

Tips, Tricks and Best Practices for Responsive Design

By

Unless 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:

Tags: , ,
File Under: CSS, Web Basics
Jun
7
2011

Create Image Sprites the Easy Way

By

If 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:

Tags:
File Under: HTML5, JavaScript
Jun
2
2011

Load Only What You Need With Yepnope.js

By

If 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: