Archive for the ‘Mobile’ Category

File Under: CSS, Frameworks, Mobile, Visual Design
Jan
26
2012

Twitter Adds Responsive Design Tools to Bootstrap 2.0

By

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.

Tags: ,
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: Browsers, Mobile, Web Basics
Dec
22
2011

Support Versus Optimization: Dealing With Mobile Web Browsers

By

Just a few of the many screens on the web

Last time we sent you over to Brad Frost’s blog it was for a slideshow about building a future-friendly web. Now Frost is back with some more tips for web developers in a post entitled Support vs Optimization, which tackles the thorny subject of what to do about the wide range of mobile browsers on the web.

As Frost points out the mobile world is more than just the WebKit-based iOS and Android browsers that often grab all the headlines. In fact the most widely used mobile browser is not even a WebKit browser (it’s Opera) and there are dozens of other mobile browsers out there as well. And, as the tablet market begins to expand beyond the iPad, there will likely be dozens more coming in the near future.

Faced with the diversity of the mobile browser market developers can either stick their heads in the sand and develop exclusively for WebKit browsers, or, as Frost suggests, we can be more considerate to other browsers. 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? (For a more far-future look, check out Scott Jenson’s The Coming Zombie Apocalypse).

The solution, according to Frost, is to recognize the difference between supporting a browser and optimizing specifically for it.

The typical argument against supporting older BlackBerry browsers or Nokia’s WebKit fork, for example, is that these browsers don’t support nearly the number of features that iOS and Android browser’s offer. While that’s true, as with most things on the web, it doesn’t have to be an either/or choice. It can actually be both. That’s what Frost means be the difference between support and optimization:

You don’t have to treat these browsers as equals to iOS and Android and no one is recommending that we have to serve up a crappy WAP site to the best smartphones on the market. It’s just about being more considerate and giving these people who want to interact with your site a functional experience. That requires removing comfortable assumptions about support and accounting for different use cases. There are ways to support lesser platforms while still optimizing for the best of the best.

For some practical advice on how you can take a more supportive approach to the wide range of mobile browsers on the market, head over to Frost’s site and read through the post. Be sure to check out the links to the various mobile emulators and brush up on the ideas behind progressive enhancement.

It’s a big web out there, with dozens of browsers and an ever-increasing number of devices connecting to it. If you want your site to be part of the future it’s going to have to work everywhere — perhaps not perfectly optimized, but at least working.

[Photo by Jeremy Keith/Flickr/CC]

Tags: ,
File Under: Mobile, Visual Design
Dec
6
2011

How to Scale Embedded Media in Responsive Designs

By

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.

Tags:
File Under: Mobile
Dec
2
2011

Microsoft Uses the Web to Showcase New Windows ‘Metro’

By

Windows Phone on an iPhone

As part of its effort to win over iOS and Android fans, Microsoft has created a very slick web-based demo of its new Windows Phone operating system.

Designed to run in your iPhone or Android web browser, the site effectively replicates the company’s new “Metro” user interface in HTML. The demo is a clever effort to show people what the Metro UI looks like without the need to set foot in a store.

If you’re curious, head over to the demo site. (Note that the site primarily works with mobile devices, though it will load in the desktop version of Chrome as well.)

A number of news outlets have called the site an “HTML5 demo,” which is technically true, though aside from the doctype the site doesn’t use many of the new features found in HTML5. Mainly what you’ll find under the hood is some JavaScript hooking into various WebKit CSS animation features (since the target audience is iOS and Android browsers, limiting the demo to WebKit browsers seems like a fair decision).

HTML5 hype aside, the site makes a nice demo Windows Phone and an impressive use of web tools to recreate a native OS interface.

Tags:
File Under: Mobile, Web Services
Nov
29
2011

Latest Stats Say We’re Building a Fatter, Slower Web

By

Been feeding your site too many JavaScript donuts?

The web is getting fatter, as much as 25 percent fatter in the last year alone.

That’s right, based on the top 1,000 most visited sites on the web, the average page download size has jumped 25 percent since this time last year — 626 kB per page to 784 kB. That’s a hefty weight gain in just a year and of course usually the larger the page, the slower the page.

The latest page size data comes from the HTTP Archive, which keeps monthly tabs on the size of web pages.

As you might expect, the largest single type of content on the average page is still images, which account for 451kB of the total 784kB. Images alone do not, however, account for the rapid increase in page size.

Our friends over at Pingdom sliced and diced the HTTP Archive data and found that much of the remainder of the bloat can be blamed on JavaScript. CSS files are also getting bigger, but since they’re generally smaller to begin with, the increase doesn’t add nearly as much to the bottom line.

Here’s Pingdom’s take on the matter:

In terms of sheer size, images are still the biggest factor, but the fastest-growing content type by far is JavaScript. It is also the second-largest content type in terms of size.

CSS content has increased 25 percent in size, which may seem like a lot, but we are still talking about relatively small files. That increase doesn’t matter as much. It does matter, though, that every single content type is growing. Size optimization seems to have gone out the window pretty much across the board.

Pingdom goes on to note that if you expand the data sample beyond the top 1,000 most visited sites the trend is even more dramatic, with the average page size at nearly 1MB.

So the web is getting fatter on a diet of ever-richer JavaScript files and more sophisticated CSS, it’s worth asking — does it matter? After all, broadband is getting faster, 3G and even 4G are spreading in the mobile space and web browsers are speeding up their JavaScript engines with every release. Do we really need to worry about larger download sizes?

Bigger pages aren’t necessarily a problem until they outstrip the corresponding increases in bandwidth and performance gains in web browsers. Bigger pages are, after all, a natural outcome of more complex, more powerful sites and web applications. But assuming all of your users have fast connections can be a mistake, particularly with a global audience. Sure, users in South Korea might be able to download a 1MB page in the blink of an eye, but the same page is going to crawl over dialup in the rural United States.

What’s perhaps most alarming about the HTTP Archive data is the rate at which pages are growing. If the 25 percent jump were to continue, it would mean that in just five years the average size of a webpage would be nearly 2.5MB. And remember, that’s the average; many pages will be much, much larger. Relying on broadband speeds to keep pace with page size growth is risky at best.

At the same time throwing out modern app building tools like JavaScript is also a mistake. What’s disheartening about Pingdom’s analysis is that sites seem to be ignoring the middle ground and, according to Pingdom, “size optimization seems to have gone out the window.” The mystery is why very large, very popular websites would risk creating larger, potentially slower pages. That’s clearly a recipe for disgruntled users. New features are great, but if they slow down your site, no one is happy. It’s a well established fact that speed is the most important element of your website. Study after study show that users turn their backs on websites that take more than mere seconds to load.

There’s nothing you can do to help slim the top 1,000 sites (unless you happen to be in charge of one of them), but if you’d like to put your own website on a diet there are number of tools that can help you compress and compact your site. We suggest starting with Web Page Test to get a basic look at how your site loads and where you might be able to compress files. Another handy tool is Google’s Page Speed service, which can help speed up your site. Yahoo’s YSlow is another invaluable tool for diagnosing page load problems.

Other things worth experimenting with include using CSS 3 to replace background images (where possible), making sure that your scripts load through a CDN and optimizing your site for mobile networks.

[Donut image by D Sharon Pruitt/Flickr/CC]

File Under: CSS, Mobile, Visual Design
Nov
29
2011

Make Your Most Important Images Stay that Way With Responsive Images

By

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.

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, Multimedia
Nov
17
2011

Damn the Torpedos: Mozilla Adds Flash to Firefox for Android

By

Flash Player running in Firefox for Mobile. Photo: Scott Gilbertson/Wired.com

Adobe may be abandoning Mobile Flash, but Mozilla is pushing forward with Flash in Firefox for Mobile. In addition to the new native Android UI we recently showcased, the latest nightly builds of Firefox for Android now offer experimental support for the Flash plugin.

If you’d like to give it a try, head over to the Mozilla nightly builds page and download a copy of Firefox for Android (note that if you have the beta release installed you’ll need to remove that first). Once the download is finished just open the file to complete the installation and setup.

The nightly builds are, obviously, not stable releases, but I took the latest version for a spin on a Dell Venue and had no problems watching Flash movies. Or I should say no technical problems with Firefox for Android. The browser didn’t crash and Flash worked as advertised in that it loaded and attempted to play movies. Sadly playback was jittery at best, often fell out of sync with the audio and more or less made a good argument for why Flash doesn’t work well on under-powered mobile devices (all testing was done over wifi).

Flash’s lackluster performance isn’t Firefox’s fault, but that probably won’t stop users from blaming the browser. In truth how well Flash performs in Firefox for Android will vary considerably based on your phone’s hardware.

While Flash on mobile is imperfect enough that even Adobe is done with it, Mozilla reports that 21 percent of Firefox for Android’s 1 and 2 star reviews come from users requesting support for Flash. For those that have been waiting for Flash, rest assured, Firefox for Mobile is indeed getting Flash support, though the final version won’t arrive until Firefox 10 ships early in 2012.

See Also:

Tags:
File Under: Browsers, Mobile
Nov
10
2011

Hands on: Firefox’s Experimental New Native Android Interface

By

Mozilla is working on a major overhaul of the Firefox mobile user interface for Android. The developers are transitioning away from XUL — the cross-platform user interface toolkit used by Firefox on the desktop — in favor of native widgets. This major design change will offer smoother performance, better platform integration, and a look and feel that is a bit more consistent with the rest of the Android environment.

We looked at the new native Firefox mobile tablet interface when it surfaced in September for Honeycomb devices. Mozilla’s mobile team is currently preparing to deliver a similar native interface for the smartphone flavor of the browser. It shares visual style of the tablet implementation, but is designed to fit well on a phone-sized screen.

The new interface was developed in an experimental Firefox mobile branch called Birch. The changes aren’t just skin deep — the transition to native widgets involved some significant architectural changes in addition to bringing a new look and feel. Mozilla is seeking volunteers to help test the overhauled version of the browser before the changes are rolled out in a stable release.

I conducted some hands-on tests with the latest Birch nightly build, which is available from Mozilla’s FTP server. I downloaded the APK and side-loaded the application on my Nexus One smartphone. It installs as “Nightly” and can be used alongside the stable Android Market version of Firefox mobile. It needs more work before it will be ready for day-to-day use, but it seems like a compelling step forward for Firefox on Android.

The user interface has been dramatically simplified and streamlined. The distinctive sidebars that slide out from the left and right in the current stable version are gone. In the new native user interface, tab management is done with a simple menu that is accessed from an arrow on the left-hand side of the navigation bar.

Although I’m a bit sad to see Mozilla abandon the nifty thumbnail-based tab switcher, there are arguably some usability advantages to the new approach. In particular, the spacing makes it easier to hit the close button for a tab and reduces the risk of hitting the close button by accident. I think the placement of the tab menu button also helps make tab management more discoverable.

When you tap the page title at the top of the screen, the browser will give you a URL box. It displays a list of bookmark and history items that will be filtered as you type, with AwesomeBar-style completion. This interface also shows tabs for quickly navigating through your bookmarks and recent history.

Most of the peripheral functionality has been relocated to the native Android menu, which is accessible by tapping the standard hardware button. The reload and forward functions are are located in the menu. There is no back function exposed through the user interface — the user can simply hit the phone’s physical back button.

The menu also has buttons for bookmarking and sharing a page. Bookmarks are completely flat now — you can boomark and unbookmark a page, but there doesn’t appear to be any way to manually organize bookmarks or even choose custom names. It’s not clear if the new limitations in the bookmark system are intentional or if the feature simply hasn’t been fully implemented yet.

The old tabbed sheet with preferences, add-ons, and downloads that used to be accessible from the gear button is gone. The add-on manager is accessible from the overflow section of the menu and opens as a separate tab. The actual add-ons interface hasn’t been fully implemented yet. The preferences have been moved to their own native native Android sheet which is also accessible from the menu overflow.

The Gecko-based embedded HTML renderer still has some minor issues. For example, any physical contact with the rendering area is interpreted as text selection, which made the browser awkward to use. Scrolling through a page was fairly smooth, but pinch-zooming was sluggish and unpredictable. The browser also doesn’t appear to have support yet for reflowing text after zooming.

Despite the glitches, the general direction of the new browser is promising. The extensibility of a XUL-based user interface makes great sense on desktop computers, but it’s arguably just wasted overhead in an Android version of the browser. Moving to native widgets on Android will make mobile Firefox more competitive — it greatly reduces the startup time and also reportedly decreases the memory footprint. The difference in startup performance was really noticeable during my tests.

It’s important to remember that my test was conducted with a nightly build, so it’s not intended to be fully functional yet. The problems I encountered all appear to be things that are fixable, so we can expect to see a lot of improvements before this new interface lands in a stable release.

Mozilla’s quality assurance team is planning a special test day tomorrow (Nov. 11) for the new native mobile interface to help identify technical issues. As we have said on several previous occasions, participating in the Firefox QA process is a great way for non-developers to contribute to the project. You can find more information about how to obtain and test the nightly from the Mozilla wiki.

This article originally appeared on Ars Technica, Wired’s sister site for in-depth technology news.

Tags:
« OLDER POSTS