Archive for the ‘UI/UX’ Category

File Under: Mobile, UI/UX, Web Basics

‘WTF Mobile Web’ Tracks Terrible Mobile Web Design

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:

File Under: Mobile, UI/UX

Slide Show Time: Building a Future-Friendly Web

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

Take Responsive Design Beyond the (Fluid) Grid

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

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

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

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

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

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

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

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

See Also:

Tips, Tricks and Best Practices for Responsive Design

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:

Revamped Readability Rewards Writers [Updated]

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: