Skip navigation
Help

Web Basics

warning: Creating default object from empty value in /var/www/vhosts/sayforward.com/subdomains/recorder/httpdocs/modules/taxonomy/taxonomy.pages.inc on line 33.

A handful of the many screens your responsive designs must handle. Photo: Ariel Zambelich/Wired.com

Building responsive websites can be daunting. After all, instead of just one desktop layout you’re creating at least two, probably three or even four layouts to handle different breakpoints and screen sizes. That means considerably more work, which can feel overwhelming if you don’t have a good plan of attack.

One of the better plans I’ve seen recently comes from developer David Bushell, who recently outlines 5 Tips for Responsive Builds. Among his suggestions there are two standouts, the first being “utilize breakpoint zero.” For Bushell “breakpoint zero” just means “start by writing HTML in a semantic and hierarchical order. Start simple, with no CSS at all and then “apply the basic styles but don’t go beyond the default vertical flow.”

In other words, keep your layout slate blank as long as you can so that when you do start adding layout rules you can spot problems with different breakpoints early and fix them before changing things becomes a major headache.

The other highlight of Bushell’s post is the suggestion that you maintain a CSS pattern library — reusable snippets of CSS you can drop in for quick styling. There are a ton of ways you can do this, whether it’s something formal like SMACSS (pronounced “smacks”), OOCSS, or just taking the time to write a style guide with some sample code. The point isn’t how you do it or which method you use, but that you do it.

Be sure to check out Bushell’s post for more details on these two suggestions as well as the other three ways you can help make your responsive design process a bit smoother.

0
Your rating: None

The W3C, the group that oversees the development of HTML and other web standards, is moving beyond dry, boring specifications with a new venture into developer documentation. The W3C has just launched an alpha preview of Web Platform Docs, a community-driven site the W3C is hoping will become the go-to source for learning how to build the web.

In other words the W3C is competing with Webmonkey.

We’re okay with that because there’s no such thing as too much high-quality, accurate info on the latest in HTML5, CSS 3 and other W3C standards. And quite frankly, HTML and CSS have grown considerably since the days when Webmonkey’s cheat sheets could tell you everything you needed to know.

Now there’s a plethora of resources for learning how to build the web — the Mozilla Developer Network, the Opera Developer Network and Microsoft’s developer site, to say nothing of the thousands of tutorials on developer blogs. But while there’s plenty out there to teach you what you need to know, finding exactly what you need to know can be challenging. You’re a web developer; you should spend your time building a better web, not searching Google for accurate info on web standards.

The goal of the W3C’s Web Platform Docs is twofold: get tons of great documentation all under one roof, and then — the most challenging part — make sure that it stays up to date. Solving the second problem is no small task. The web is currently littered with great tutorials on CSS Flexbox, which are, unfortunately, all wrong now that the Flexbox spec has been changed. The same is true of Web Sockets tutorials, Indexdb tutorials and any other tutorial on a spec that has changed or might change in the future.

These days keeping up with the rapidly changing world of web standards is a full-time job and who better to tell you what’s going on, how you can use new tools and when browsers will support them than the people actually writing standards and building browsers?

The W3C has managed to bring together some of the biggest names on the web to help create Web Platform Docs. Representatives from Opera, Adobe, Facebook, Google, Microsoft, Mozilla and Nokia will all be lending their expertise to the new site.

While the list of participating companies is impressive, Web Platform Docs is also a wiki that anyone, not just W3C reps, can edit. As the W3C’s Douglas Schepers tells Webmonkey, “anyone can contribute and everyone is on equal footing.”

If your head is bursting with tutorials, code snippets, examples or solutions to common development problems, head on over to the site and sign up so you can contribute. Bear in mind that this is an alpha release. While the site looks great and has the basic features of a wiki up and running, many of the features Schepers mentions in the intro blog post aren’t available just yet. “In the spirit of ‘release early, release often’, we decided to announce the site at the earliest possible point and improve it in public,” writes Schepers.

Right now the content of the site is primarily documentation, but the plan is to include tips and best practices along with up-to-date information on standardization progress and browser support for individual features. Other cool planned features include a way to share code snippets and an API for some aspects of the site.

For an overview of the site and to learn a bit more about where the W3C plans to go with Web Platform Docs, check out the video below.

0
Your rating: None

Stopwatch in CSS 3, no JavaScript necessary. Image: Screenshot/Webmonkey

Five years ago the hotness in web development was showing what you could create without resorting to Flash. Now it seems the same is true of JavaScript. While we’ve nothing against JavaScript, the increasingly powerful tools in CSS 3 mean that JavaScript is no longer a necessity for building cool stuff on the web.

The latest JavaScript-free demo we’ve run across is this very cool stopwatch demo made using only CSS 3, no images or JavaScript necessary. Now before you dive into the code and get all Karl Van Hœt on us, yes, there is a script used to handle CSS prefixing, but the actual stopwatch doesn’t require it to work.

But what caught our eye even more than the JavaScript-free stopwatch demo is the tutorial that accompanies it. The tutorial — which is one part screencast and one part code dump — is part of Code Player, which helps you learn how to do things by showing you the code as it’s written. It’s an interesting tutorial method, one we haven’t seen before.

Watching code being written isn’t for everyone, especially beginners who might not be able to easily follow what’s happening, but it’s well suited to those that already understand the basics and just want to see how some particular function was written. It also provides an interesting look at how other developers work, which in turn might teach you a new trick or two.

The Code Player offers a variety of playback speeds depending on how fast you want to run through the tutorial, and there’s a timeline scrubber for pausing and rewinding any bits you miss. Our only complaint is that Code Player forces focus in the browser; when you try to click another tab or do something in the background Code Player steals focus back immediately.

If learning something new by watching someone else type sounds intriguing, head on over to the Code Player site. And don’t worry if the stopwatch demo has no appeal for you, there are plenty of other tutorials to choose from.

0
Your rating: None

Responsive Book: Google's Chromebook site as seen by a phone (left) and a tablet.

If you’ve been waiting for responsive design to go mainstream, wait no more. While The Boston Globe‘s responsive redesign made a big splash in the developer community, The Globe has nothing on the latest web giant to throw its weight behind responsive design — Google.

That’s right, Google is now suggesting developers use responsive design tools like media queries to handle the variety of screens now accessing the web.

The Google Webmaster blog has posted a new article, Responsive Design – Harnessing the Power of Media Queries, that walks beginners through the basics of creating a responsive website.

It’s not the most thorough tutorial we’ve seen, nor is it the best — Google conflates breakpoints with device width, something we’d recommend against — but nitpicking aside, Google’s official blessing will no doubt help move responsive design to the front burner in many people’s minds.

It’s worth noting that while a tutorial is nice, Google isn’t necessarily making the leap to responsive websites for its own properties. Indeed, sites like Gmail or Reader are excellent arguments for maintaining separate mobile designs. If your “site” is actually a web app as complex as Gmail then we suggest doing what Google does — hiring a fleet of developers to build an maintain separate websites for different size screens.

Chances are, though, that your site isn’t that complex and doesn’t have the developer teams that Google can afford. Even Google uses responsive design when it makes sense. To go along with the new tutorial, Google offers up that the new Chromebook website is responsive, which shows off the company’s responsive design chops.

0
Your rating: None

Testing a responsive site across devices (using Adobe Shadow). Photo: Adobe.

We’ve covered quite a few ideas on how to build more responsive websites — that is, websites that use flexible layouts, media queries, image scaling and other tricks to make sure that the site looks great and works well on any screen.

Sometimes, though, it’s helpful to see what not to do. Responsive design guru Brad Frost recently outlined five common mistakes responsive developers make over at .Net magazine. Frost covers responsive sins like relying on specific screen sizes to trigger layout changes (it’s far better to create design breakpoints based on a site’s actual design than to just use the screen sizes du jour) and avoiding a one-size-fits all experience.

Of the latter Frost writes:

Mobile is much more than just various small screens…. We shouldn’t sell ourselves short by only creating responsive layouts. For example, we sometimes forget that mobile phones can get user location, initiate phone calls, and much more. Hopefully soon browsers on all these gadgets will have access to even more device APIs, further pushing the boundaries of what’s possible on the web.

We should do all we can to make the entire experience respond to what the device is capable of. Addressing constraints first gives us a solid foundation to stand on, then we can utilize progressive enhancement and feature detection to take the experience to the next level.

The entire post is well worth reading, but we’d like to add a sixth rule to the list: Don’t assume that what you did yesterday will be the best thing to do tomorrow.

That’s not to imply that what you do today won’t work tomorrow, just that chances are there will be an easier way to do it.

Responsive web design is a very new challenge and the best ways of meeting it are still being worked out. That can be a pain, but it also means that some very smart people are solving some very hard problems and you can benefit from their work provided you know about it.

We see new things popping up all the time, whether it’s a new way to handle responsive images or a browser update that adds widespread support for a new CSS feature. We encourage developers to spend some time reading up on the latest tips and tricks before each new project. New responsive tools are being developed and refined so rapidly that the hack you used on your last project might turn into a stable, well-maintained JavaScript library by the time you start building a new responsive site.

0
Your rating: None

A webpage doesn’t have to look the same in every browser. In fact, a webpage shouldn’t look the same in every browser, according to former Yahoo developer and JavaScript guru, Nicolas Zakas.

Zakas, who spent five years as the front-end tech lead for the Yahoo homepage, recently spoke at the March BayJax Meetup group about what he calls Progressive Enhancement 2.0 — offering users the best possible experience given the capabilities of their device.

Not the same experience, mind you, but the best possible experience. That means progressively enhancing sites according to the device’s (browser’s) capabilities.

Progressive enhancement is perhaps best summed up by the famous Mitch Hedburg quip, “an escalator can never break, it can only become stairs.” In other words, if you’re building websites well they never break, even if you look at them in Lynx. The site may not look the same in Lynx as it does in, say Chrome, it may not function as smoothly, but the core content is still there and can still serve as a stairway that gets people where they want to go even when the enhanced ease of the escalator is absent.

More practically, progressive enhancement means starting with the least capable devices — an older phone, Lynx running on Windows 95 — and then adding more sophisticated features based on screen size, bandwidth and so on.

Zakas also takes on the common assumption that a web “page” is analogous to the printed page. In fact Zakas argues the web is more like television, which has a similar separation of content and device. In that analogy old browsers are like black and white TVs. No one expects a black and white TV to play HD content, but everyone would be disappointed if you served black and white content to an HD TV. Hence the need for progressive enhancement.

If you’re well versed in the history of the web the beginning of the video may be a bit slow, but stick with it. Also be sure to watch the questions at the end where Zakas addresses how to progressively enhance more application-like web pages.

0
Your rating: None

The high-resolution retina display iPad has one downside — normal resolution images look worse than on lower resolution displays. On the web that means that text looks just fine, as does any CSS-based art, but photographs look worse, sometimes even when they’re actually high-resolution images.

Pro photographer Duncan Davidson was experimenting with serving high-resolution images to the iPad 3 when he ran up against what seemed to be a limit to the resolution of JPG images in WebKit. Serving small high-resolution images — in the sub-2000px range — works great, but replacing 1000px wide photographs with 2000px wide photos actually looks worse due to downsampling.

The solution (turns out) is to go back to something you probably haven’t used in quite a while — progressive JPGs. It’s a clever solution to a little quirk in Mobile Safari’s resource limitations. Read Davidson’s follow-up post for more details, and be sure to look at the example image if you’ve got a new iPad because more than just a clever solution, this is what the future of images on web will look like.

As Davidson says:

For the first time, I’m looking at a photograph I’ve made on a screen that has the same sort of visceral appeal as a print. Or maybe a transparency laying on a lightbox. Ok, maybe not quite that good, but it’s pretty incredible. In fact, I really shouldn’t be comparing it to a print or a transparency at all. Really, it’s its own very unique experience.

To show off the sample on his site Davidson uses a bit of JavaScript to toggle the high- and low-res images, highlighting the difference.

But how could you go about serving the higher res image to just those screens with high enough resolution and fast enough connections to warrant it?

You can’t.

So what’s a web developer with high-res images to show off supposed to do? Well, right now you’re going to have to decide between all or nothing. Or you can use a hack like one of the less-than-ideal responsive image solutions we’ve covered before.

Right now visitors with the new iPad are probably a minority for most websites, so not that many people will be affected by low-res or poorly rendered high-res images. But Microsoft is already prepping Windows 8 for high-res retina-style screens and Apple is getting ready to bring the same concept to laptops.

The high-res future is coming fast and the web needs to evolve just as fast.

In the long run that means the web is going to need a real responsive image solution; something that’s part of HTML itself. An new HTML element like the proposed <picture> tag is one possible solution. The picture element would work much like the video tag, with code that looks something like this:


 
 
 

The browser uses this code to choose which image to load based on the current screen width.

The picture element would solve one part of the larger problem, namely serving the appropriate image to the appropriate screen resolution. But screen size isn’t the only consideration; we also need a way to measure the bandwidth available.

At home on my Wi-Fi connection I’d love to get Davidson’s high-res images on my iPad. When I’m out and about using a 3G connection it would be better to skip that extra overhead in favor of faster page load times.

Ideally browsers would send more information about the user’s environment along with each HTTP request. Think screen size, pixel density and network connection speed. Developers could then use that information to make a better-informed guess about which images it to serve. Unfortunately, it seems unlikely we’ll get such tools standardized and widely supported before the high-res world overtakes the web. With any server-side solution to the bandwidth problem still far off on the horizon, navigator.connection will become even more valuable in the mean time.

Further complicating the problem are two additional factors, data caps on mobile connections and technologies like Apple’s AirPlay. The former means that even if I have a fast LTE connection and a high-resolution screen I still might not want to use my limited data allotment to download high-res images.

AirPlay means I can browse to a site with my phone — which would likely trigger smaller images and videos since it’s a smaller screen — but then project the result on a huge HD TV screen. This is not even a hypothetical problem, you can experience it today with PBS’s iPhone app and AirPlay.

Want to help figure out how the web needs to evolve and what new tools we’re going to need? Keep an eye on the W3C’s Responsive Images community group, join the mailing list and don’t be shy about contributing. Post your experiments on the web and document your findings like Davidson and countless others are already doing.

It’s not going to happen overnight, but eventually the standards bodies and the browser makers are going to start implementing solutions and the more test cases that are out there, the more experimenting web developers have done, the better those solutions will be. It’s your web after all, so make it better.

Photo: Ariel Zambelich/Wired

0
Your rating: None

The high-res future is coming

The first of the new iPads will arrive in the hands of the public this Friday, March 16. Like the iPhone before it, and no doubt many more devices to come after it, the new iPad has four times the resolution of typical screens. That means your visitors will soon be looking at your site on a high-resolution screen with a whopping 3.1 million pixels.

The sharp, crystal-clear screens are awesome news for new iPad owners, but they create some new dilemmas for web developers who’d like to offer a better experience for high-resolution screens. Sure, increased pixel density means you can serve up sharper, better looking graphics, but there is a cost as well — bigger images mean more bandwidth and longer page loads.

This isn’t a new problem by any means and Webmonkey has looked at a variety of solutions in the past, including techniques like adaptive images and responsive images.

The problem is simple: you need to send smaller images to small screens and larger images to larger screens. Sending a huge iPad-optimized image to a device with a max resolution of 320×480 just doesn’t make sense. At the same time, when bandwidth isn’t an issue, most sites will want to serve high-resolution content to displays that can handle it.

The ideal solution would be to detect both the resolution of the screen and the available bandwidth. Then, based on the combination of those two factors, the server could offer up the appropriate image. Currently that’s not possible, though there are already proposals to extend HTML to handle that scenario.

The Responsive Image Working Group is a W3C community group hoping to solve some of these problems. The group is proposing a new HTML element, <picture>, which will take into account factors like network speed, device dimensions, screen pixel density and browser cache to figure out which image to serve up. Think of it as a much smarter version of the old lowsrc property. So far though it’s all hypothetical

In the mean time if you’d like to serve up high resolution images to your third-generation iPad visitors look no further than Apple.com for one (not necessarily ideal) way to do it. An Apple Insider reader noticed that Apple is already prepping its site to deliver double-resolution images to new iPads. Cloud Four’s Jason Grigsby, whose responsive image research we’ve covered before, has a great breakdown of what Apple is doing.

Essentially Apple is serving up lower resolution images by default, then using JavaScript to send larger images on to iPads. That works, but it will definitely mean increased download times for new iPads since they have to download two files for every graphic. Apple’s approach will also up the number of HTTP requests, which will also slow down the page.

The slower page loads seem to be an acceptable trade off for Apple since the company no doubt wants to showcase the new iPad’s high resolution display with high resolution images. For other sites the bandwidth trade off may not be worth the gain in image resolution.

Still, screens are only going to continue getting better with ever-increasing pixel density. Now is the time, if you haven’t already, to start embracing CSS 3 (avoid images altogether with gradients, shadows and rounded corners in CSS 3), Scalable Vector Graphics (SVG) for resolution independent graphics and of course @media queries to serve high-res background images.

For more on detecting and developing for high resolution displays, check out these posts from around the web:

0
Your rating: None

Photo: tobias.munich/Flickr

Think your three-second page loads are “just fine”? Think again.

According to engineers at Google, even the blink of an eye — which takes around 400 milliseconds — is too long.

That’s the word from the New York Times, which makes an unusual foray into the world of web development with its article “For Impatient Web Users, an Eye Blink Is Just Too Long to Wait.”

Some web developers may remember the days of the two-second rule (and no, not the one that applies to dropping food on the floor). The established wisdom — well-tested at the time by usability experts like Jakob Nielsen and others — was that after two seconds the number of users willing to wait for your page to load dropped off significantly.

That rule still holds, it’s just the amount of time that’s changed. Nowadays, the Times claims, users drop off after a mere 400 milliseconds, and a difference in page load time of just 250 milliseconds is enough to convey a distinct advantage over your competitors.

It’s that last number that’s perhaps most interesting. Anyone who’s browsing the web via a 3G connection can tell you that if you’re only willing to wait 400 milliseconds for a page to load, you aren’t going to see much of the web. On mobile networks bandwidth constraints are even more of an issue than they were when the two-second maximum was popularized. Users seem to understand this, but they don’t see it as an excuse. Now, perhaps more than ever, slight differences in page load time can give your site a significant advantage over competitors, according to the Google and Microsoft engineers quoted in the Times piece.

In other words, users may still, in some circumstance, be willing a wait a second, but if your competitor’s page is even 250 milliseconds faster, you can kiss your users goodbye.

Don’t believe us? Head over to the Times article and see if Google’s engineers don’t convince you. When you’re done we’ve got a few tips on how to speed up your website and make sure that no one has the edge on you. Here are a few helpful articles from the Webmonkey archives:

0
Your rating: None

The Boston Globe's responsive navigation shrinks down to a selectable list

The web is moving rapidly away from its fixed-layout past into what it arguably should have been all along — a flexible medium that adapts to any screen size. While there are many aspects to the move from fixed to flexible, the overall process has been dubbed “responsive design.” That is, designing sites that respond to different screen sizes, fluidly adapting to the wide array devices available today and the myriad more coming tomorrow.

The idea of designing in a completely fluid medium is a very new notion for most developers. After all, print design was always a world of fixed layouts and thus far the web had largely followed suit. Moving to something where the size and shape is often unknown is a daunting, but exciting process that’s still very much in the early, experimental stages.

As with any experimental phase, old best practices are called into question and new ones emerge. Not all responsive design experiments are good ideas. Webmonkey has looked at some overarching best practices for responsive design in the past, but we haven’t necessarily covered the finer details of creating a responsive website.

As these things occasionally happen, several developers recently tackled one of the tougher aspects of responsive design — creating a navigation menu that works on any size screen. While key to creating a usable website, menus do not easily resize to fit smaller screens.

Maggie Costello Wachs, a developer with the Filament Group, recently posted an overview of one possible approach to creating a responsive navigation menu. Wachs’ solution is to convert the menu from a horizontal list to a drop down list as the screen gets smaller, in the end moving the drop down list underneath the site’s logo on very narrow screens (you can see a demo here).

The drop down list is not the only option for dealing with a navigation menu in your responsive designs. Developer Brad Frost recently posted a great overview of responsive navigation patterns, offering up pros and cons of each approach. Along with the drop down menu, Frost covers options like moving the navigation to the footer, hiding it behind a toggle button and of course, probably the most widespread option at the moment — doing nothing. The latter option works quite well for sites with only a few menu items, but quickly breaks down when navigation menus get more complex.

Along with Frost’s lists of pros and cons are plenty of screenshots demonstrating the trade offs inherent in each approach (bonus points to Frost for using screenshots from a wide range of mobile browsers, not just the iPhone or Android).

As with all things responsive at this point there is no one right answer to the question “how do I build a responsive navigation menu?” What works well for one site might well be disaster on your next project. Don’t be afraid to try out several approaches. And remember, these are exciting times; you’re not just building responsive websites, you’re part of a collective effort to create an entirely new visual vocabulary for flexible design.

0
Your rating: None