Archive for the ‘UI/UX’ Category

File Under: CSS, HTML5, JavaScript, Mobile, UI/UX, Visual Design, Web Basics
Jan
12
2012

Building a Responsive, Future-Friendly Web for Everyone

By

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:

Tags: , ,
File Under: Mobile, UI/UX, Web Basics
Nov
18
2011

‘WTF Mobile Web’ Tracks Terrible Mobile Web Design

By

Sometimes the best way to figure out what works is to see what doesn’t. That’s the thinking behind WTF Mobile Web, a new site that tracks examples of terrible mobile web design and user experience. Whether it’s a “native look” that inevitably looks wrong on all but one platform or simply treating the iPad as a mobile browser, WTF Mobile has plenty of examples of what not to do when developing a mobile site.

WTF Mobile Web is the brainchild of developers Jen Simmons and Brad Frost who are careful to note that the point isn’t to be mean or pick on specific sites. In fact, perhaps the best part about the site is that, as people were quick to point out, it’s guilty of some of the very same things it’s calling out in other sites. Hypocrisy? Sure, but it also illustrates just how hard it is to get mobile right.

As Simmons and Frost write:

The problem is that we’ve all been doing this thing called Making a Website for a long time in a particular way. And now everything is changing. Sure some developers are resistant to learning new things, but most developers are interested, excited and willing. But this isn’t a problem that you can fix by just switching out which bit of code to use. It’s bigger than that. Content strategy, design, business all have to change. The fundamental way in which people work together to plan and coordinate the creation of a website has to change.

Perhaps the most important thing to keep in mind is that, to paraphrase developer Steven Hay, there is no mobile web, no desktop web, no tablet web. There is just The Web, which we view in different ways. Design for The Web, avoid assumptions about devices (like assuming the iPad is a mobile device) and please, stop with the “native” designs.

If you run across an example of bad mobile design you can submit it to WTF Mobile Web.

So how do you build better mobile sites? Well, WTF Mobile Web has a few links to get you started, including one to Frost’s Building a Future Friendly Web slideshow, which we’ve covered before. Webmonkey has also been covering mobile and responsive design for some time so be sure to read through our archives.

WTF? photo by Daniel Lobo/Flickr/CC

See Also:

Tags: ,
File Under: Mobile, UI/UX
Oct
4
2011

Slide Show Time: Building a Future-Friendly Web

By

Embedded above is an excellent presentation by Brad Frost. Below you can find a video that goes along with the slides.

Frost’s slides and talk revolve around the idea that the web is changing too rapidly to claim we can create future-proof websites or webapps. Instead we need to think in terms of future-friendly sites. In other words, forget perfection and start embracing what elements you can today. For Frost that means tools like responsive design, but also creating content that is “like water.”

“Think of your core content as a fluid thing that gets poured into a huge number of containers,” writes Frost. “Get your content ready to go anywhere because it’s going to go everywhere.”

Of particular note in the slides is Frost’s breakdown of Forbes.com into content and, ahem, not content. As Frost says, “people’s capacity for bullshit is rapidly diminishing… we need to respect people’s time and give them relevant, purposeful content without the extra cruft.” In other words, don’t be Forbes.

Be sure to check out the various helpful websites and books Frost lists toward the end for more on how to make your own sites future-friendly. [Update: Here's a link to Frost's collection of helpful links and resources for future-friendly sites.]

For a Future Friendly Web from Brad Frost on Vimeo.

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: 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: Blog Publishing, UI/UX, Visual Design
Feb
1
2011

Revamped Readability Rewards Writers [Updated]

By

The new Readability pays the sites you read

Readability, a browser tool which isolates the text on a webpage making it easier to read, has announced it’s moving beyond its humble beginnings to become a “full-fledged reading platform.” Readability will now offer iOS apps and, more importantly, it’s no longer a free tool.

The new Readability will cost you a minimum of $5 a month, with 70 percent of that fee going directly to the writers and publishers whose sites you visit.

Readability and similar tools, like Apple’s Safari 5 web browser have been criticized for cutting into publishers’ bottom line by eliminating online advertisements. The new non-free Readability is at least in part a way to address this concern. As readers, most people want a clean, distraction-free reading experience. At the same time no one wants to deprive their favorite websites of the income necessary to keep the site going. Readability’s new pricing plan is an attempt to find some common ground and keep everyone happy.

Not only does the new Readability give readers an option to hide ads and view a more readable page (which they may well be doing anyway), it provides a new source of income for the site. Even better, that additional revenue comes from the actual content, rather than simply the ads surrounding the content.

Ironically, in testing the new Readability, I realized that most sites I read regularly already have clean designs, nice typography and uncluttered layouts — sites that don’t really need Readability. But the new payment system can help those sites too. Readability’s payment system turns the service into something more than just a reformatting tool — it’s a bit like a roving micropayments system, handing out money to sites you enjoy.

Here’s how it works: The minimum fee is $5 a month, though Readability encourages you to spend more if you can afford it. The money is then split up between articles where you use Readability. Visit only one site and it will get all of your money; visit several dozen and each will see only a few pennies unless you up your monthly payment. You can use the Readability web interface to see where your money is going. It’s like micropayments, but all the transaction details are handled behind the scenes by Readability.

Of course you aren’t just paying the writers and publishers. Thirty percent of your monthly fee money goes to Readability, which has some new browser extensions, web badges, an API and some nice looking (though as-yet-unapproved) iOS apps built around the popular Instapaper.

The Instapaper contribution means that in addition to the “Read Now” button, which gives you a more readable version of the current article, there’s also a new “Read Later” button. Read Later works just like it does in Instapaper, saving the article to your account for when you have more time to read. Unfortunately, right now there’s no way to actually integrate your Instapaper account with Readability.

The “Read Now” and “Read Later” buttons can come from either the Readability browser extension, bookmarklet or from the site itself using a new embedded button (there’s also an API for more sophisticated integration).

Despite the integration tools and new payment system, it’s unlikely most sites will ever get rich from Readability. Of course it’s unlikely most sites are making much from Google Ads either, and it certainly never hurts to have another form of income, even if it is measured in pennies.

[Update: For those worried that Readability is no longer free at all, we should note that you can keep using the bookmarklets and browser extensions without paying for the service.]

See Also:

Tags: ,
File Under: Browsers, UI/UX
Jan
3
2011

Try Firefox 4 with Tabs in the Title Bar

By

Top: Maximized window with tabs in the titlebar. Bottom: Normal tab bar

Firefox 4 has entered the home stretch. The recent release of beta 8 added the last of the major new features for Firefox 4, including a new add-ons interface, better syncing and more hardware accelerated WebGL support. From now until the final release later this year, Firefox development will primarily focus on squashing bugs and refining the user interface.

The Firefox 4 UX roadmap outlines the user interface changes that Mozilla is hoping to complete before Firefox 4 is released. Most of the changes are very small — improving the contrast of the type in the URL bar or tweaking the session restore dialog — but there’s one welcome change in the list that many Firefox fans have been clamoring for — tabs in the titlebar.

The idea of saving screen real estate by smashing tabs up into the title bar of the browser windows started with Google Chrome and has since been copied by other browsers and applications.

It’s a tiny tweak, probably not more than a few dozen pixels are saved, but it can make all the difference when you’re using a netbook or other small screen device. Putting tabs at the top of the browser window also adheres to Fitts’ law, which says that the closer things are to the edge of the screen, the easier they are to click.

In Firefox’s case Fitts’ law seems to be the main reason for the new look — tabs are only pushed into the title bar when the window is maximized, making it easier to flick the cursor to the top of the screen and click a tab.

The new tabs-in-the-title-bar look is expected to arrive in Firefox 4 beta 9 (which will be the next release in Firefox’s beta cycle), but you can preview it today by grabbing a special build of Firefox for Windows and Linux. The builds are the work of Firefox developer Bill Gianopoulos, and as such are not official releases nor are they supported by Mozilla.

Also bear in mind that the code used to create these experimental versions of Firefox comes from Firefox’s nightly builds, which means there may be more bugs than you’ll find in the latest Firefox beta. That said, these builds worked just fine for us on Windows 7 and XP.

If you’ve got a small screen or have been looking for a way to make Firefox’s tabs a bit more like Google Chrome’s, grab the experimental builds. If you prefer to wait for something official, Firefox 4 beta 9 should be released in the relatively near future.

See Also:

Tags:
File Under: Programming, UI/UX
Oct
28
2010

Unleash an Army of Bees With Machine Guns on Your Website

By

Want to know if your website can stand up to a sudden, massive deluge of traffic? Sure, you could use some of the available tools like Flood, JMeter or The Ginder. But none of those options have bees with machine guns.

The news applications team at the Chicago Tribune, has released a new tool it calls Bees with Machine Guns that uses Amazon EC2 servers to launch what amounts to a distributed DoS attack against your site.

Now only is it an incredibly handy way to load test a website under arguably more realistic conditions than you’d get with other load testing tools, Bees with Machine Guns has awesome print statements that will turn your terminal session into a war zone.

For example:

$ fab -f bees.py attack:http://YOUR-DOMAIN.com/,1000,100
Read 2 bees from the roster.
Connecting to the hive.
Assembling bees.
Each of 2 bees will fire 500 rounds, 50 at a time.
Stinging URL so it will be cached for the attack.
[localhost] run: curl http://YOUR-DOMAIN.com/ >> /dev/null
Organizing the swarm.
Bee 0 is joining the swarm.
Bee 1 is joining the swarm.
Bee 0 is firing his machine gun. Bang bang!
Bee 1 is firing his machine gun. Bang bang!
Bee 0 is out of ammo.
Bee 1 lost sight of the target (connection timed out).
Offensive complete.
     Target failed to fully respond to 1 bees.
     Complete requests:     500
     Requests per second:   81.670000 [#/sec] (mean)
     Time per request:      612.188000 [ms] (mean)
     50% response time:     358.000000 [ms] (mean)
     90% response time:     1541.000000 [ms] (mean)
Mission Assessment: Target successfully fended off the swarm.
The swarm is awaiting new orders.
Done.

Keep in mind that this is essentially a DoS attack. Launch it against a site that isn’t yours and very bad things will happen to you. But for testing your own site’s performance, Bees with Machine Guns is awesome — all you need is an EC2 account and the script.

Major bonus points if your site can fend off the bees with miniature pies:

See Also:

Tags: ,
File Under: UI/UX
Oct
27
2010

Design for Serendipity (And Drinking Monkeys)

By

Part of the beauty of the internet and HTML is its inherent serendipity — links lead you somewhere, and other links lead you somewhere else, beyond, anywhere. Yet, serendipitous as the web may be, few sites encourage this sort of haphazard exploration.

As developer Derek Powazek writes, “Serendipity powers the social web. It’s why every website has a “share this” link. Serendipity is at the core of why Twitter is fun, YouTube is valuable, and everyone you know has a Facebook account.”

In fact, argues Powazek, “we should be designing for serendipity.”

Unfortunately, things like the bottom line, advertising dollars and other external forces mean web designers are tasked with keeping you on a page, not sending you off to discover something else. Even Powazek’s examples, like YouTube’s “related videos” section is inherently designed to keep you on YouTube’s page. But the way it keeps you on YouTube is by creating a potentially serendipitous experience.

Nothing is going to change the need or desire to keep visitors on your page, particularly if eyeballs on those pages are your source of income, but adding the element of the accidental discovery to your site can make it even more valuable for your visitors.

Here’s more advice from Powazak (who is a former Webmonkey, by the way):

If you make a website, take a look at it and ask yourself, “when someone comes here looking for one thing, where do I have the opportunity to tell them about something else?” It could be in a footer, for example. This can be tricky, because you don’t want to interrupt a self-directed experience. Just look for the cracks where you can leave hints about what else is available. Hint: Newspapers have been designed this way for years. Crib, crib heartily.

There are many serendipitous routes that lead people to your stuff. Understand what they are and nurture them. But don’t become over-reliant on them. Design your stuff to create serendipitous connections between things. Look for every opportunity to hint that there’s much more to be discovered. Take the time to design the serendipity in to the experience.

Or, you could watch this video about drinking monkeys and see where that leads you:

Bookshelf photo by Juhan Sonin/Flickr/CC

See Also:

Tags: , , ,
File Under: Browsers, UI/UX
Jul
22
2010

An Alternate Version of Firefox’s Home Button

By

Back at the beginning of July, we saw the release of Firefox 4 beta 1. The first beta version of Mozilla’s next browser shipped with some important user interface changes — most notably, Windows users got tabs-on-top and the new Firefox Button. It’s a button that sits at the top of the browser window and contains all of the most-used menu options, neatly nested in hierarchical menus and accessible via one click.

The final browser isn’t expected until October, but the team is still experimenting. The picture above is one such experiment, a rough first draft at “flattening” the new Firefox Button, which turns it into something less of a “Greatest Hits” menu and more of a browser dashboard.

Firefox creative lead Aza Raskin, who really did this to satisfy his own curiosity, writes:

Hierarchical menus are almost always slower to use than flattened menus. This is a first-draft pass at flattening the Firefox Button’s menu. For things like accessing bookmarks, I’ve left the menu as a secondary action. In truth, I ran out of time while doing the bottom left hand corner of the mockup and so it is still very raw and not right. I’ve also moved more rich interactions to the right side pane. Letting us bubble up interesting add-ons and extension points inside the Firefox menu, as well as give real indication and controls to Sync.

Keep in mind that this design is just an idea and most likely will not be part of the next Firefox. But Raskin’s design could push the button in interesting directions.

See Also:

Tags: , ,
« OLDER POSTS