Archive for the ‘Visual Design’ Category

Responsive Design Tricks: Fluid Typography With CSS 3

Photo: Ariel Zambelich/Wired.com

Building responsive websites means that your design has to adapt to different screen sizes. That there is no such thing as “pixel perfect” has long been a maxim of good web design, but nowhere is this more true than when you start working with percentage widths, em-based type and other flexible techniques of responsive design. While fluid grids, adaptive images and other tools help, sometimes even basic things like the flow of type can look wrong without a little extra help.

One common problem when designing for multiple devices is handling the changes that happen when the user rotates the screen. It’s frustrating to see your elegant portrait-oriented designs fall apart as the device moves to landscape mode (or vice versa). Frequently the problem is that images, videos and other embedded content in your page is sized in relation to the pixel width of the viewport, but the type is not. That means that the type fails to adapt to layout changes, leaving ugly gaps, whitespace or hard-to-read, overly long lines.

There are a number of ways to solve this problem, but one of the simplest and easiest is to use fluid typography in addition to your fluid grid. BBC developer Mark Hurrell wrote up an excellent tutorial some time ago that shows how, by specifying font sizes in rems, you can “adjust every font-size on the page by using media-queries to change the font-size set on the BODY or HTML element according to viewport width.”

To find the right size type for various screen widths, Hurrell calculates a resolution-independent font scale based on target widths. That is then applied using a series of media queries and the new CSS 3 unit rem. The rem unit means ems relative to the root (the HTML) element. That means your type gets proportionally larger overall, rather than in relation to its parent element as would happen with a simple em. As Hurrell notes, support is pretty much universal on tablets and phones (browsers that don’t support it will fall back to px sizing, so all is not lost).

In the end what you get using rems and media queries is fluid typography that scales just like a fluid grid. That means that when the device rotates the type resizes to fit the new screen dimensions. For more details on how to make it work on your site be sure to check out the Responsive News blog post, which also has a few links to websites already using this trick.

Twitter Adds Responsive Design Tools to Bootstrap 2.0

Twitter is gearing up for the release of Bootstrap 2.0, the second major version of its popular open source front-end toolkit for web developers.

Bootstrap 2.0 will arrive Jan. 31, but if you’d like to take it for a spin today you can help test the pre-release build. Just head on over to GitHub and checkout the branch, 2.0-wip.

Bootstrap is designed to help you get your website up and running as fast as possible. Somewhere between a CSS framework and a “theme,” Bootstrap offers an HTML, CSS and JavaScript base for your designs, including built-in forms, buttons, tables, grids and navigation elements. Among Bootstrap’s more impressive tricks is the grid layout tool, which is based on the 960 grid system, with support for advanced features like nested and offset columns.

Bootstrap 2.0 will solve one of the bigger complaints about Bootstrap 1.0 — it was not responsive. To embrace a more responsive approach for mobile devices, Bootstrap is moving to a flexible 12-column grid system. The 2.0 release also includes some updated progress bars and customizable gallery thumbnails, but perhaps the best news is that, at just 10kb (gzipped), Bootstrap 2.0 remains an impressively lightweight framework.

While Bootstrap offers good browser support, with all the modern options covered you should be aware that it won’t work with Internet Explorer 6. To see some real world examples of what you can do with Bootstrap, head on over to the unofficial showcase, Built with Bootstrap on Tumblr.

Photo by Mike Love/flickr/CC.

Building a Responsive, Future-Friendly Web for Everyone

A handful of the many screens your site needs to handle. Photo: Ariel Zambelich/Wired.com

This week’s Consumer Electronics Show in Las Vegas has seen the arrival of dozens of new devices from tablets to televisions. Some of these newfangled gadgets will soon be in the hands of consumers who will use them to access your website. Will your site work? Or will it end up mangled by a subpar web browser, odd screen size or slow network connection?

No one wants to rewrite their website every time a new device or browser hits the web. That’s why approaches like responsive design, and the even broader efforts of the future-friendly group, are trying to develop tools and techniques for building adaptable websites. That way, when a dozen new tablets suddenly appear on the scene, you can relax knowing your site will look and perform as intended, no matter which devices your audience is using.

Even if you aren’t a gadget lover, CES should help drive home the fundamental truth of today’s web — devices, they are a comin’. Webmonkey has compiled helpful resources for creating responsive design in the past, but the field is new and evolving rapidly so here’s an updated list of links to help you get started responsive, future-friendly sites that serve your audience’s needs whether they’re browsing with a tiny phone, a huge television or the web-enabled toaster of tomorrow.

Basics:

  • 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 4-inch screens, one for 7-inch, one for 10-inch and one for desktop. Keep it liquid, otherwise what happens when the 11.4-inch screen 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. 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 screens. Similar techniques can be used to scale video.
  • Forget about perfect. If you haven’t already, abandon the notion of pixel perfect designs across devices. An iPad isn’t a laptop isn’t a television. Build the perfect site for each.

Further Reading:

  • Future Friendly — An overview of how some of the smartest people in web design are thinking about the ever-broadening reach of the web: “We can’t be all things on all devices. To manage in a world of ever-increasing device complexity, we need to focus on what matters most to our customers and businesses. Not by building lowest common-denominator solutions but by creating meaningful content and services. People are also increasingly tired of excessive noise and finding ways to simplify things for themselves. Focus your service before your customers and increasing diversity do it for you.”
  • Building a Future-Friendly Web — Brad Frost’s excellent advice: “Think of your core content as a fluid thing that gets poured into a huge number of containers.”
  • There is no mobile web — “There is no mobile web, nor desktop web. It is just the web. Start with the content and meet people halfway.”
  • Responsive by default — Andy Hume on why the web has always been responsive, but was temporarily sidetracked by the fad of fixed-width sites.
  • COPE: Create Once, Publish Everywhere — NPR’s Director of Application Development, Daniel Jacobson, walks through how NPR separates content from display and uses a single data source for all its apps, sites, APIs and feeds. A great example of what Frost talks about regarding content as a fluid thing.
  • Support Versus Optimization — It can seem daunting to support dozens of mobile browsers, but if you aren’t up to the challenge of a few mobile browsers now what are you going to do when you need to support car dashboards, refrigerators, televisions and toasters, all with dozens of varying browsers?
  • The Coming Zombie Apocalypse — Not satisfied thinking a few years ahead? Scott Jenson explores further into the future and tries to imagine what the web might look like when devices all but invisible.

Techniques:

File Under: Humor, Visual Design

Forget New Twitter. Check Out Old Facebook

1997 called. Your CRT is ready.

The tech press is abuzz, debating the merits and failures of the new (new new?) Twitter web and mobile designs.

If you’re like most, you aren’t even seeing Twitter’s new website just yet, so if you’d like to contemplate something a bit more fun on a Friday morning, consider what Twitter might have looked like had it been around in 1997.

You might remember 1997, the heady early days of web design — 1-pixel spacer images, animated gifs, tables with gray borders and a magical new idea called “cascading stylesheets.”

How would Twitter have looked in that world? We’ll never know, but thanks to a new art project dubbed “Once Upon” you can see what Facebook, YouTube and Google+ might have looked like had they been around in 1997. Once Upon was created by artists Olia Lialina and Dragan Espenschied, who describe the project as “three important contemporary web sites recreated with the technology and spirit of late 1997, according to our memories.”

That’s right, Facebook, YouTube and Google+ redesigned in the spirit and look of 1997. As an added bonus the demo site has been set up to limit bandwidth at a 1997-esque 8 kB/s so it loads just as painfully slow as it would have on dialup.

Naturally all three sites are “best viewed with Netscape Navigator 4.03 and a screen resolution of 1024×768 pixels, running under Windows 95″ (that resolution actually seems a bit large for 1997, but that’s okay). If you can’t find a Windows 95 machine in the closet fear not, the demo site will work in any web browser that supports frames.

[via Today and Tomorrow]

File Under: Mobile, Visual Design

How to Scale Embedded Media in Responsive Designs

A responsive movie embed working on a Sony Ericsson (photo by Anders Andersen)

In order to make responsive designs successfully adapt to any screen size, you need to properly scale not just headlines and text elements, but images and other media. We’ve already covered a number of solutions for images, but what about other elements like video?

Scaling video when you can control the embed code is pretty easy, the same max-width tricks that work on images will work on video. The tricky problems with scaling video come when you start trying to embed movies from other websites.

YouTube and most other video hosting sites typically include a fixed width and height in pixels as part of the embed code. That’s fine for older designs, but it doesn’t scale in a responsive layout.

Swedish web developer Anders Andersen recently tackled the problem of responsive embeds and came up with a solution that works with both YouTube and Vimeo movies. Andersen’s solution is to wrap any embed code, whether it’s an actual embed tag or an iframe, with an extra div and then scale that div. Naturally you’ll need to strip any fixed dimensions out of the YouTube or other embed code for this to work.

For the full details and the CSS that makes it work, be sure to read Andersen’s whole post.

The core of Andersen’s method lies in the CSS, which uses this handy trick to preserve the intrinsic ratio of the video even as its container element scales down.

Andersen has tested this technique with YouTube, Vimeo and SlideShare embeds, though it may work with others as well.

Between stripping out any video dimensions and adding a wrapper div, Andersen’s responsive embed trick is a little bit of work. It’s probably not practical for a site with a lot of video, or a site where non-technical users will be posting video. However, if you’ve got a simple site that’s 99 percent responsive, but you’ve been looking for a way to handle video, this fits the bill.

Be sure to check out Andersen’s follow-up post where he does some device testing. The results are generally encouraging, with most modern phones handling the code just fine. The only real problem device seems to be the new Nokia Lumia 800 (running Windows Phone 7) which fails to play the YouTube embeds.

File Under: CSS, Visual Design

Using Sass to Help Internet Explorer Handle ‘Mobile-First’ Designs

If you’ve embraced a mobile-first approach to responsive design, you’re probably building your CSS in layers. One common method is to start with a base layer of CSS that applies to all screen sizes — like font definitions, colors, etc — and then using CSS 3 @media queries to add in floats and the like for larger screens.

This approach works well with most browsers, except of course our old friend Internet Explorer, which, prior to IE 9, doesn’t know what to make of @media. Naturally there are solutions to the IE 6/7/8 problem. You could use a polyfill like Respond.js or css3-mediaqueries.js, both of which use JavaScript to make media queries work in older web browsers.

Sometimes though you don’t want the JavaScript dependency. What’s more, most of the time you don’t really even care if IE actually understands @media, you just want it to apply the CSS inside the @media block.

Developer Nicolas Gallagher recently outlined a different, JavaScript-free approach to making older versions of IE apply your @media rules. Gallagher’s technique builds on an idea developer Jeremy Keith uses to work around a bug in Windows mobile. If you’re looking for a simple, JavaScript-free means of serving up a mobile-first design without abandoning older versions of Internet Explorer, this is one of the best solutions I’ve seen (provided you’re already using Sass).

Here’s Gallagher’s description:

The basic idea is to produce two versions of your compiled CSS from the same core code. One version of your CSS includes CSS 3 @media queries and is downloaded by modern browsers. The other version is only downloaded by IE 6/7/8 in a desktop environment and contains no CSS 3 @media queries.

Be sure to read through Gallagher’s post for the full details on how and why it works. Obviously if you’re not a fan of Sass, then this approach isn’t for you (Less fans should check the comments on Gallagher’s post as developer Peter Wilson has a link to a Less version of the same idea).

New Google Bar Hides Navigation, Showcases Google+

The new Google bar: minus the links, plus the +

Google is rolling out an updated look for the “Google bar” that runs along the top of your screen on all of the company’s various web services.

As with most Google interface changes, this one seems to be rolling out incrementally. If you’d like to see it for yourself right now, the Google Operating System blog has instructions on how you can edit your browser’s Google cookie and trigger the revamped design.

The new Google bar dispenses with the black bar that currently runs along the top of most Google pages and provides links to Google’s frequently used services like Web Search, Maps, News and Gmail. If you’re logged into Google the old bar also lists your user info on the right and offers links to various account settings.

The links to Gmail and the rest of Google’s services have been stripped out of the new Google bar. Instead of a list at the top of the page they’re now buried under a drop-down menu attached to Google’s logo, though Google’s help page notes that on the main Google homepage “the Google bar’s product menu may be expanded.” In other words, Google’s not entirely confident that the new drop-down menu is a good idea. Given that the only clue there’s a drop-down menu in the logo is a tiny arrow to the right of the “e”, the auto-expanded menu for the homepage is probably a good idea.

As part of the company’s effort to inject its nascent Google+ social network into the rest of its services, Google+ gets top billing in the new Google bar. Your general Google account info is still located on the right, but now links up with your Google+ account and adds a Google+ share button. If you haven’t yet set up a Google+ account you’ll see the old account info along with a new link suggesting you join Google+.

Along with the Google+ share button there’s also a new notifications icon that lets you know whenever there’s some activity on your Google+ account. When someone adds you to a circle, posts a comment in your stream, or shares something directly with you, the new notifications badge will let you know.

The new Google bar looks a bit cleaner, but the drop-down menu is definitely a step backward for anyone frequently switching between services. It’s also curious to hear Google talking about the old Google bar taking up “precious space” when the company just recently added an incredible amount of whitespace and padding to nearly all of its pages.

If you’re not seeing the new interface just yet, here’s Google’s promo video showcasing the new Google bar:

File Under: CSS, Mobile, Visual Design

Make Your Most Important Images Stay that Way With Responsive Images

Developer Dave Rupert helps you keep your cats properly scaled

If you’ve spent any time at all playing with responsive images (or adaptive images) you’ve probably noticed something about small screens — portrait-oriented images take on a much greater importance. The simple fact is that on the vertically-oriented small screen, taller images are larger and, thus, assume a greater importance.

As developer Dave Rupert puts it: Image Height == Image Importance.

The problem with that equation is that it often means that on mobile screens less important images suddenly steal the spotlight. Take an image with thumbnails below it for example. As Rupert recently found, when scaling down your designs, sometimes the image importance equation means the emphasis is wrong on small screens:

Our design employed a ~3:1 hero image with three ~4:3 thumbs below it. At full width it possessed the proper hierarchy: Biggest == Most Important. However, when resized and folded into a single column, the 3:1 image appears to be about half the height of the 4:3 images below it.

The solution for Rupert is what he calls, “Uncle Dave’s Squeeze n’ Crop Method,” which consists of a wrapper div and some very clever CSS combined with @media rules. Head on over to Rupert’s blog for the full solution and a little explanation of why it works. It’s not exactly cut-and-paste code you can just drop in your own projects since image dimensions and ratios will vary, but it’s definitely worth bookmarking should the problem arise in your own work.

File Under: Visual Design

Thinking with Type: Brush Up Your Typography Skills

The power and potential impact of typography on the web has grown by leaps and bounds with the advent of widespread browser support for @font-face and font hosting services like Adobe’s Typekit.

Of course with new tools come new problems. Many web developers don’t know much about fonts and typography. After all it used to be there were only six reliable font choices on the web — why bother learning about something you couldn’t use? But that, like so many other things in web development, is no longer true.

If the web’s newfound typography options leave you feeling a bit behind, head over to Ellen Lupton’s Thinking With Type website. The site is a goldmine of information on typography dos and don’ts both on the web and off. The site is not, however, so much about fonts, but rather about type as a visual element and what it can do (both good and bad) within a design.

If you’ve ever wondered why your small caps don’t look right, how to properly kern text or how you can use contrasting font weights to create more visually engaging banners, Thinking With Type has the answers for you.

There’s even a section on working with multi-column grids, something that will hopefully be possible in the near future as more browsers begin to support the various CSS grid layout systems.

The Thinking With Type website is a companion to Lupton’s book of the same name, which is well worth picking up if you have any interest in learning more about typography.

See Also:

Adobe Acquires Typekit Web-Font Service

Adobe has acquired web-font service Typekit. Typekit helped pioneer the use of fancy fonts on the web thanks to its easy-to-use service which takes care of licensing, font loading and cross-browser support. Today all a designer needs to do to add typefaces in their page is drop in a couple lines of Typekit code.

Typekit currently serves over 250,000 sites, including The New York Times and WordPress.com, as well as Webmonkey and Wired.

Writing on the Typekit blog, CEO Jeffrey Veen assured Typekit users that little will change, at least for now. “Typekit will remain a standalone product,” writes Veen, “our team will stay together, and we’re excited to start working on even easier ways to integrate web fonts into your workflow.”

Typekit and Adobe are hardly strangers. The companies previously partnered to bring many of Adobe’s more popular fonts to the web — Adobe Garamond, News Gothic, Myriad, Minion and others are all available through Typekit. It seems likely, now that Typekit is part of Adobe, that the service will add more of the Adobe fontface library in the future.

Potential new fonts won’t, however, do much to assuage the fears of those worried about the future of Typekit under the Adobe umbrella. If the comments on the Typekit blog are any indicator, Typekit users are evenly split — about half of Typekit’s audience seems optimistic about the change and half, well, less so. A common sentiment for the latter group comes from a commenter named Jason who writes, “I am happy to see the Typekit team get a reward for an amazing service, but terrified to see Adobe ruin what they created so lovingly.”

Indeed Adobe has a mixed track record with companies it has acquired, as anyone who relied on Macromedia FreeHand or Director can tell you. Hopefully Typekit will fare better, especially since, small though the company may be, it’s a big part of the reason web fonts have become so popular.

When Typekit first launched in 2009 hardly anyone was using web fonts. Browser support was spotty at best and very few type foundries offered web licenses. Fast forward to today and the landscape has changed remarkably. Now every recent browser release supports CSS 3′s @font-face and Typekit has hundreds of fonts from most of the major type foundries.

Obviously much of that change is due to a combination of effort from browser makers, standards bodies and type foundries, but Typekit played no small part as well, helping to create a demand for high-quality fonts on the web, and then delivering those fonts in a way anyone can use.

See Also: