Archive for the ‘Mobile’ Category

File Under: CSS, Mobile
Feb
21
2012

The iPhone Monoculture Is in Your Mind

By

Photo: Ariel Zambelich/Wired.com

In the recent kerfuffle over the prevalence of the -webkit CSS prefix and the lack of corresponding prefixes for other browsers, we told you that the problem was with developers, not WebKit browsers. Instead of writing code that will work in any browser many developers are coding exclusively for WebKit and that’s a problem.

But mobile expert Peter-Paul Koch, better known in the web developer community as just PPK, argues that the real problem is not WebKit, nor is it even web developers’ fascination with WebKit. The real problem is the developer-created monoculture of the iPhone.

According to Koch, “web developers don’t care about WebKit…. They care about the iPhone.”

The interesting thing about Koch’s argument is that he doesn’t claim there is actually a monoculture of the iPhone on the web. In fact, he cites some of Mozilla’s web crawler stats which seem to say just the opposite. Instead Koch believes the problem is in our heads, so to speak.

“What we have here is an iPhone monoculture; not in the stats, but in web developers’ minds,” writes Koch. “This is the fundamental problem we must address.”

The cure, says Koch, is to diversify tutorials and examples. “Start talking about testing in mobile non-WebKit browsers (i.e., Opera),” he writes. “Start talking about other platforms besides iPhone (and Android). Start talking about mobile diversity, instead of showing the iPhone over and over and over again.” What do you do if the only phone you have to test on is the iPhone? Well, there are emulators available for most phones, including Opera’s very powerful mobile emulator which can simulate all kinds of phones and connections. And don’t forget that Opera Mini is available for the iPhone if you’d like to at least test your site in something other than Mobile Safari.

Tags: , ,
File Under: Mobile
Feb
16
2012

First Look: Mozilla’s Boot2Gecko Mobile Platform and Gaia UI

By

Mozilla launched a new project last year called Boot2Gecko (B2G) with the aim of developing a mobile operating system. The platform’s user interface and application stack will be built entirely with standards-based web technologies and will run on top of Gecko, the HTML rendering engine used in the Firefox web browser. The B2G project has advanced at a rapid pace this year and the platform is beginning to take shape.

The B2G team at Mozilla is preparing to give a demo of the platform’s user experience at the upcoming Mobile World Congress (MWC) event. Mozilla’s Brendan Eich told us via Twitter that the B2G project has already attracted partners, including one that is developing its own custom home screen. This suggests that multiple parties, possibly hardware vendors, are interested in adopting the platform.

According to a roadmap recently published by Mozilla, the B2G project could potentially reach the product stage by the second quarter of 2012. That’s a highly ambitious target, but the project’s impressive rate of development suggests that it can be done. The pervasive use of HTML and JavaScript to build the user interface and application stack is no doubt speeding the project along. Web technologies are very conducive to rapid development.

The B2G platform consists of three main layers. The bottom layer, which is called Gonk, includes the Linux kernel, the hardware abstraction layer, the telephony stack, and other low-level system components. The middle layer is the Gecko rendering engine, which has been improved with new APIs that expose device capabilities. The top layer is Gaia, the B2G user interface, which is built entirely with HTML and JavaScript.

The Linux kernel that is used in Gonk is said to be “reasonably close” to upstream Linux. According to Mozilla’s documentation, Gonk uses some of the underlying bits of the Android open source project, including some minor kernel customizations, in order to make it easier for hardware vendors to get B2G running on Android hardware. B2G is not based on Android, however, and will not run Android applications. It’s currently possible to replace the Android environment on a Samsung Galaxy S II with a B2G build.

Much of the interaction between the Gecko and Gonk layers will be mediated by a B2G process that runs with a high privilege level and acts as a sort of Gecko server. The B2G process will paint to the framebuffer and interact with hardware components like a built-in GPS antenna or camera.

The wireless modem functionality is implemented in a radio interface layer (RIL) daemon, which B2G will interact with through a simple proxy process. Actual web content and multimedia playback will be handled by separate processes that communicate with the B2G process.

Mozilla aims to build the entire B2G user interface and application stack with native HTML and JavaScript. In order to accomplish that, Mozilla launched the WebAPI project, which exposes device functionality to web content through JavaScript APIs. Mozilla has already previously introduced APIs for accessing certain device capabilities, such as the accelerometer and geolocation APIs that are supported in the mobile versions of Firefox.

The WebAPI project goes a step further and adds a great deal of additional functionality for tasks like taking pictures with the built-in camera, dialing the phone, accessing the device’s battery level and status, sending and managing SMS messages, accessing the user’s address book, and making a device vibrate. These capabilities are largely made accessible to web content through a set of JavaScript APIs. This means that the B2G dialer interface, for example, is just a web page that uses a JavaScript function to initiate a call.

Mozilla is working to standardize these APIs through the W3C Device APIs working group. In theory, the same underlying JavaScript APIs that are used to enable access to underlying platform features on B2G could eventually be supported natively in the default web browsers that ship with other platforms.

The standardization effort around device APIs is especially significant. If the APIs gain widespread adoption, it would make it possible for large portions of the B2G user experience and application stack (which are, essentially, just web content) to run in web browsers on other platforms. At that heart of Mozilla’s agenda for B2G is a vision of the future in which browser-based mobile applications, built with standards-based HTML and JavaScript, will be capable of doing everything that can be done today with the native mobile application development frameworks.

Because B2G’s Gaia user interface layer is implemented in HTML and JavaScript, it can technically run in a regular desktop web browser. Of course, the device-related capabilities will only work when the content is run in an environment that has WebAPI support.

We tested the Gaia home screen user interface and several of the platform’s applications in a Firefox nightly build. All we had to do to get it running was download the code from the relevant GitHub repository and then open the homescreen.html file in Firefox.

When the page loads, the user will see the B2G lock screen, which displays the current date and time. The home screen interface can be accessed by dragging the lock screen up. The home screen displays a grid of application launchers and has a notification bar at the top. You can drag a notification slider down from the bar, much like the equivalent user interface element in Android.

B2G lock screen

If you look at the source code of the homescreen.html page, you will see that the contents of the interface, including the lock screen, are created with HTML div tags with some JavaScript code to handle interaction and populate the values. It’s quite simple and predictable web content.

The B2G home screen

Individual applications run inside of a frame in the homescreen interface. We tested several applications, including a dialer, a web browser, and a map application. Like the home screen, these are all implemented in HTML and CSS. The web browser is basically a web page with an HTML input element for the URL bar and an embedded iframe element where the page content loads.

B2G sample map application

B2G's Web browser. It's practically begging for a Yo Dawg joke

The B2G dialer

The current implementation of the Gaia environment is still simplistic and incomplete, but it offers a compelling demonstration of how conventional web content can be used to create a smartphone user experience. It’s possible to do anything in the B2G user interface that can be done with HTML and CSS, so the possibilities for styling and theming are prodigiously extensive. Such intrinsic flexibility could help make B2G appealing to hardware vendors because it would make it easier for them to create custom user interfaces that differentiate their products.

Mozilla hasn’t created an HTML-based widget toolkit for application development. The applications currently included in Gaia are just straight markup with CSS for design. It’s theoretically possible to use existing HTML widget toolkits in B2G, however, such as jQuery Mobile and Sencha Touch.

The B2G project is off to an impressive start. The underlying concept of bringing native application capabilities to the standards-based web technology stack is also tremendously compelling. It hints at the possibility that the open web could someday provide a unified application platform for mobile devices.

It’s also worth noting that the project is entirely open. As Eich pointed out to us yesterday in response to our coverage of Open webOS, the B2G project has had open governance and public source code since its first day. B2G also benefits from Mozilla’s engineering talent and potential partners. The B2G platform has an opportunity to bring positive disruption to the mobile landscape and be a serious contender.

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

Tags: ,
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: ,
« OLDER POSTS