Skip navigation
Help

Mobile browser

warning: Creating default object from empty value in /var/www/vhosts/sayforward.com/subdomains/recorder/httpdocs/modules/taxonomy/taxonomy.pages.inc on line 33.

A handful of the many canvases your site will adorn. Photo: Ariel Zambelich/Wired.com

In the bad old days of just four years ago it was pretty common for mobile users to get shunted off to some half-baked, feature-deprived “mobile” version of the website they were trying to visit. This misguided practice was common (and annoying) enough that even today Chrome for Android and other mobile web browsers ship with a feature that allows users to “request desktop site.”

To make that feature work Chrome for Android changes its user agent string. Any site that uses user agent strings to redirect mobile users will no longer because to redirect them and the desktop version is displayed.

Responsive websites don’t rely on user agent strings though. Instead they adapt to screen size based on CSS media queries so even if a user has the option for desktop sites checked in Chrome they still won’t get the “desktop” site (of course with responsive sites there really is no desktop site, just a desktop layout).

Provided your responsive designs are good, this isn’t a problem (and if they aren’t then you have bigger problems). However, Opera web standards evangelist Bruce Lawson raises an interesting edge case: what about users that have never seen the mobile layout and are disoriented when they do? If you were expecting, say, the desktop layout of the BostonGlobe.com and instead saw the mobile layout for the first time you might be understandably confused. Here’s what Lawson has to say:

My reason for wondering [about turning off responsive design] is watching my dad use his Xmas Android phone and seeing his puzzlement that some sites look completely different on that device. Non-RWD sites loaded the layout he was familiar with — the desktop layout — which meant he could verify he was on the right site, he knew where in the layout the content he wanted was, and then scroll and zoom to it. When a site looked radically different, he’d check the URL bar to ensure that he’d typed in the right address. In short, he found RWD to be confusing and it meant he didn’t trust the site – no way would he buy anything from these sites.

The first thing to note is that this isn’t a problem unique to responsive sites. The same thing would crop up with a separate mobile experience. The difference is the inability to opt out of the responsive layout. An edge case? Sure, but Lawson isn’t alone in wondering about turning off responsive designs. CSS guru Chris Coyier tackled that very question last year, writing:

Why don’t we see opt-out responsive design? My guess is two-fold:

  1. It’s a bit technically challenging to implement and there aren’t a lot of precedents.
  2. It’s admitting you didn’t do a very good job on the responsive design.

The latter likely being the bigger factor. Like: why are we creating this responsive design at all if we aren’t sure it’s a better experience?

I would agree with both points, but clearly there are at least a few edge cases where offering an option to turn off responsive design might be a good idea. Of course it may not be worth worrying about the edge case of unfamiliar visitors — that’s the sort of decision you can only really make by looking at your own visitors and doing your own testing.

If you actually want to try it, Coyier has some ideas on how to go about creating an option to opt out of a responsive design.

0
Your rating: None

Vexing Viewports

“The Web is Agreement.” Jeremy Keith’s eloquent statement neatly summarizes the balance that makes it possible for us to build amazing things. Each week, new devices appear with varying screen sizes, pixel densities, input types, and more. As developers and designers, we agree to use standards to mark up, style, and program what we create. Browser makers in turn agree to support those standards and set defaults appropriately, so we can hold up our end of the deal.

This agreement has never been more important.

That’s why it always hurts when a device or browser maker does something that goes against our agreement. Especially when they’re a very visible and trusted friend of the web—like Apple.

You see, Apple’s newest tablet, the iPad Mini, creates a vexing situation: Its device-width viewport tag defaults to the same values as Apple’s original iPad (768x1024 pixels), even though the Mini's screen is physically 40 percent smaller. That means every button, graphic, link, and line of text on a web page on the iPad Mini appears tiny—even when we try to do the right thing and build flexible, multi-device experiences.

Two iPads, one too small.

But Cupertino isn’t the only culprit out there. This is a problem that’s been brewing since we started using the viewport—and it has to do with not just pixels, but our own practices as well. Let’s take a step back and understand what’s really causing today’s woes—and what all of us need to do about it.

The trouble with pixels

Today’s viewport woes can be traced right back to pixels—yes, those tiny elements we work with every day.

The first pixel challenge is quantity. The more pixels in the display, the more information can be displayed. But as these are physical pixels whose number can’t be altered after the fact, a second factor comes into play: the screen’s physical size.

Imagine two two-inch-wide displays (about the width of the iPhone), as shown below.

Two devices, each with a two-inch-wide display. The one on the right, at 640x960, would pack four times as many pixels into the same space as the 320x480 screen on left.

The first is 320x480 pixels, the second 640x960. This gives the second display four times as many pixels as the first, but fits all of them into the same physical space. This smaller pixel size results in content that is also smaller—making it crisper, but much harder to read as well.

This is exactly what happened on the Nokia E60. In 2005, most mobile phone displays were about an inch and quarter wide, with an average of 176 pixels in that width. But the E60, which sported a “huge” 352x416-pixel display, crammed twice the number of pixels into a similar amount of space. The result: A gorgeous, crisp—but often hard-to-read—display.

The E60 also introduced a now-familiar problem: how users would manage to surf “big” sites on a tiny device. Nokia’s solution was a new browser, the Mini Map. This browser behaved similarly to today’s smartphone browsers by first rendering the full-sized page, then scaling it to fit the available screen size. Superimposed onto this rendering was a transparent red box that could be repositioned using the device’s joystick. Clicking the joystick would zoom the content indicated within the box.

Enter viewports

Mini Map was probably one of the first commercial uses of a dynamic viewport—a construct designed to dynamically change the size or scale of the visible screen area in order to improve the user experience. But it was far from the last.

In 2007, Apple released the iPhone, a much larger device than the E60, but one with a similar problem. Even on a “huge” two-inch display, surfing the “real web” on an iPhone meant loading large pages onto a small device. Apple chose to solve this problem through a series of carefully orchestrated enhancements.

The first was the creation of a virtual viewport similar to the one Nokia designed for Mini Map. When encountering desktop websites, the browser would render them at their full size (based on a default canvas width of 960 pixels). It would then scale them down to fit the two-inch display. Users could interact with the page to scroll and zoom in on areas of their choice.

Apple didn’t stop there. It also developed a new viewport meta tag. Sites not using the tag would be rendered using the default, legacy-web viewport of 980 pixels. But developers who opted to use the tag could declare the viewport for their sites, including setting the width to the all-important device-width value. This value tells the browser, “please pick a width that fits this specific device’s screen best.”

Other mobile browser vendors were quick to follow Apple’s lead. Nowadays just about every mobile browser supports the viewport meta tag, including the device-width value. This provides us with an even playing field: It respects the efforts of those who take the time to adapt sites for the multi-device web, while those who haven’t yet made this transition still receive a “good-enough” default experience.

Mini problems

The value device and browser vendors assign to device-width is directly related to that device’s physical dimensions. Physically smaller devices need a smaller device-width value (which will result in larger content). Set a value that’s too large, and most content will be too small to comfortably read.

And that’s why Apple’s iPad Mini has a vexing viewport. It uses the same 768-pixel device-width as the regular iPad, even though its physical size is much smaller. One would expect to see a device-width more in line with those of similarly sized tablets like the BlackBerry PlayBook or second-generation Samsung Galaxy 7″—around 500 to 600 pixels, as shown in this chart.

Because of this device-width, web pages appear 27 percent smaller on the iPad Mini than they do on the Google Nexus 7 (calculated based on the relative size of device pixels)—all because Apple decided to describe the device’s viewport as 768 pixels.

Solving for content size

One of the first places this causes problems is in text: More pixels in a smaller space means that fonts sized in pixels will look correspondingly dinky.

Of course, many of us aren’t sizing in pixels anymore—we’re using relative dimensional elements like ems, right? Only, that doesn’t quite solve the problem this time.

When we use ems, we imply a certain trust that the browser’s baseline font size at the default zoom level—1em or 100 percent in unit parlance—is sane and readable. But that’s not always the case. The browser’s baseline font-size value (1em) roughly equates to a 16-pixel square. This ratio serves as a ligament that binds absolute and relative units, but it can vary from browser to browser.

On the iPad Mini, font-size at baseline is precisely 16 pixels. That may have worked fine when fewer pixels were packed into our screens, but on a dense display with an improperly defined viewport, that’s going to be uncomfortably small.

Not all browsers toe the 1:16 em-to-pixel line, though. The Kindle Touch’s browser, for example, has a high-density viewport, but adapts by using a 1:20 ratio, kicking the default font size up a few pixels for readability.

This might not fix all of iPad Mini’s viewport problems, but at least the content would be legible.

Three seven-inch tablets. Note the difference in rendering.

So why did Apple do this?

To understand why Apple would release a product with such a vexing viewport, we don’t have to look further than our own habits.

In the wake of the iPad’s initial release, web folk worldwide scrambled to adapt sites to look good on the new tablets. Somewhere along the way many of us collectively settled upon pixel-based notions of tablet-ness, and those notions often resulted in fixed, 1024x768-pixel layouts precisely targeted at these devices.

Were Apple to decrease the device-width value for the iPad Mini on account of its smaller physical size, it would guarantee a second scramble as existing tablet-adapted sites assuming a 1024x768 viewport suddenly looked unexpectedly wretched on the new device.

The responsibility here goes two ways. Browser makers need to provide reliable baselines of viewport and text sizing, yes. But we as implementers also need to stop grasping for pixel-perfect control over our layouts (the “control” is an illusion, anyway).

A way forward

The only way for us to move forward is together. As developers and designers, we need to hold up our end of the bargain and be mindful of how we do our work—and that means letting go of the notion of pixel precision once and for all. We need to earn the trust of browser makers so they hear us out when things just frankly aren’t right. We hope this article illustrates we’re trying to do the right thing. We hope browser makers acknowledge that and follow suit.

Standards and consistency are more important now than ever before. Please let browser makers and device manufacturers, like Apple, know that we rely on consistent and reliable decisions about default viewports and their zooming. We’re willing to hold up our end of the agreement, and we need them with us.

Let’s move into the future—together.

RSS readers: Don't forget to join the discussion!

0
Your rating: None

Enlarge / An overview of a browser-based exploit that abuses cloud services.

Vasant Tendulkar et al.

Scientists have devised a browser-based exploit that allows them to carry out large-scale computations on cloud-based services for free, a hack they warn could be used to wage powerful online attacks cheaply and anonymously.

The method, described in a research paper scheduled to be presented at next month's Computer Security Applications Conference, uses the Puffin mobile browser to push computationally intensive jobs onto a cloud-based service that was never intended for such purposes. Normally, Puffin and other so-called cloud-based browsers are used only to accelerate the loading of Web pages on mobile devices by rendering JavaScript, images, and text from disparate sources on a server and only then delivering it to the smartphone or tablet. That's more efficient than relying on mobile devices with limited computing power to render such content themselves.

Now, computer scientists at North Carolina State University and the University of Oregon have demonstrated a way to abuse such services. By creating a customized browser that mimics Puffin, they were able to trick the cloud-based servers it relies on to count words, search for text strings, and carry out other tasks the service was never designed for—free and semi-anonymously. Out of ethical considerations, they limited both the scope and workload imposed on the cloud resources, but they warned less-scrupulous attackers could use similar techniques to perform powerful denial-of-service attacks and password cracks.

Read 5 remaining paragraphs | Comments

0
Your rating: None

I've been an eBay user since 1999, and I still frequent eBay as both buyer and seller. In that time, eBay has transformed from a place where geeks sell broken laser pointers to each other, into a global marketplace where businesses sell anything and everything to customers. If you're looking for strange or obscure items, things almost nobody sells new any more, or grey market items for cheap, eBay is still not a bad place to look.

At least for me, eBay still basically works, after all these years. But one thing hasn't changed: the eBay website has always been difficult to use and navigate. They've updated the website recently to remove some of the more egregious cruft, but it's still way too complicated. I guess I had kind of accepted old, complex websites as the status quo, because I didn't realize how bad it had gotten until I compared the experience on the eBay website with the experience of the eBay apps for mobile and tablet.

eBay Website

Ebay-web

eBay Mobile App

Ebay-iphone-app

eBay Tablet App

Ebay-ipad-app

Unless you're some kind of super advanced eBay user, you should probably avoid the website. The tablet and mobile eBay apps are just plain simpler, easier, and faster to use than the eBay website itself. I know this intuitively from using eBay on my devices and computers, but there's also usability studies with data to prove it, too. To be fair, eBay is struggling under the massive accumulated design debt of a website originally conceived in the late 90s, whereas their mobile and tablet app experiences are recent inventions. It's not so much that the eBay apps are great, but that the eBay website is so very, very bad.

The implied lesson here is to embrace constraints. Having a limited, fixed palette of UI controls and screen space is a strength. A strength we used to have in early Mac and Windows apps, but seem to have lost somewhere along the way as applications got more powerful and complicated. And it's endemic on the web as well, where the eBay website has been slowly accreting more and more functionality since 1999. The nearly unlimited freedom that you get in a modern web browser to build whatever UI you can dream up, and assume as large or as small a page as you like, often ends up being harmful to users. It certainly is in the case of eBay.

If you're starting from scratch, you should always design the UI first, but now that we have such great mobile and tablet device options, consider designing your site for the devices that have the strictest constraints first, too. This is the thinking that led to mobile first design strategy. It helps you stay focused on a simple and uncluttered UI that you can scale up to bigger and beefier devices. Maybe eBay is just going in the wrong direction here; design simple things that scale up; not complicated things you need to scale down.

Above all else, simplify! But why stop there? If building the mobile and tablet apps first for a web property produces a better user experience – why do we need the website, again? Do great tablet and phone applications make websites obsolete?

Why are apps better than websites?

  1. They can be faster.
    No browser overhead of CSS and HTML and JavaScript hacks, just pure native UI elements retrieving precisely the data they need to display what the user requests.
  2. They use simple, native UI controls.
    Rather than imagineering whatever UI designers and programmers can dream up, why not pick from a well understood palette of built-in UI controls on that tablet or phone, all built for optimal utility and affordance on that particular device?

  3. They make better use of screen space.
    Because designers have to fit just the important things on 4 inch diagonal mobile screens, or 10 inch diagonal tablet screens, they're less likely to fill the display up with a bunch of irrelevant noise or design flourishes (or, uh, advertisements). Just the important stuff, thanks!

  4. They work better on the go and even offline.
    In a mobile world, you can't assume that the user has a super fast, totally reliable Internet connection. So you learn to design apps that download just the data they need at the time they need to display it, and have sane strategies for loading partial content and images as they arrive. That's assuming they arrive at all. You probably also build in some sort of offline mode, too, when you're on the go and you don't have connectivity.

Why are websites better than apps?

  1. They work on any device with a browser.
    Websites are as close to universal as we may ever get in the world of software. Provided you have a HTML5 compliant browser, you can run an entire universe of "apps" on your device from day zero, just by visiting a link, exactly the same way everyone has on the Internet since 1995. You don't have to hope and pray a development community emerges and is willing to build whatever app your users need.

  2. They don't have to be installed.
    Applications, unlike websites, can't be visited. They aren't indexed by Google. Nor do applications magically appear on your device; they must be explicitly installed. Even if installation is a one-click affair, your users will have to discover the app before they can even begin to install it. And once installed, they'll have to manage all those applications like so many Pokemon.

  3. They don't have to be updated.
    Websites are always on the infinite version. But once you have an application installed on your device, how do you update it to add features or fix bugs? How do users even know if your app is out of date or needs updating? And why should they need to care in the first place?

  4. They offer a common experience.
    If your app and the website behave radically differently, you're forcing users to learn two different interfaces. How many different devices and apps do you plan to build, and how consistent will they be? You now have a community divided among many different experiences, fragmenting your user base. But with a website that has a decent mobile experience baked in, you can deliver a consistent, and hopefully consistently great, experience across all devices to all your users.

I don't think there's a clear winner, only pros and cons. But apps will always need websites, if for nothing else other than a source of data, as a mothership to phone home to, and a place to host the application downloads for various devices.

And if you're obliged to build a website, why not build it out so it offers a reasonable experience on a mobile or tablet web browser, too? I have nothing against a premium experience optimized to a particular device, but shouldn't all your users have a premium experience? eBay's problem here isn't mobile or tablets per se, but that they've let their core web experience atrophy so badly. I understand that there's a lot of inertia around legacy eBay tools and long time users, so it's easy for me to propose radical changes to the website here on the outside. Maybe the only way eBay can redesign at all is on new platforms.

Will mobile and tablet apps kill websites? A few, certainly. But only the websites stupid enough to let them.

[advertisement] What's your next career move? Stack Overflow Careers has the best job listings from great companies, whether you're looking for opportunities at a startup or Fortune 500. You can search our job listings or create a profile and let employers find you.

0
Your rating: None



Mozilla has teamed up with Web design studio Little Workshop to develop a Web-based multiplayer adventure game called BrowserQuest. The game is built with standards-based Web technologies and is designed to be played within a Web browser.

With the technical capabilities offered by the latest standards, Web developers no longer have to rely on plugins to create interactive multimedia experiences and application-like user interfaces. As we reported earlier this month, modern standards are making the Web an increasingly viable platform for game development.

BrowserQuest, which is built with JavaScript and HTML5, is a compelling demonstration of how existing standards can be used to create browser games. It uses the HTML5 Canvas element to render a tile-based 2D world, HTML5 audio APIs to support sound effects, WebSockets to facilitate communication with the backend server, and localStorage to save the player's progress.

The game's remote backend, which enables the real-time multiplayer gameplay, was coded in JavaScript and runs on top of Node.js. The load is balanced across multiple Node.js instances on three separate severs. At the time this story was written, the backend was successfully handling over 1,900 simultaneous players. The status of the BrowserQuest backend can be monitored through the game's real-time dashboard interface.

The developers focused on using widely-supported standards so that the game would work well across a wide range of desktop and mobile browsers. It works just as well on a tablet device, for example, as it does on a desktop computer.

The future looks even brighter, as there are a number of pending Web standards that will greatly enhance support for building games on the Web in the future. Features like 3D graphics and support for game controller peripherals, for example, could eventually take the browser beyond the realm of casual gaming. You can refer to Mozilla's wiki to see an overview of the work that the organization is doing to improve browser-based gaming. For more details about BrowserQuest, see the Mozilla Hacks blog or check out the backend server code on GitHub.

Read the comments on this post

0
Your rating: None



Fragmentation remains an issue for third-party Android application developers. The wide spread and slow rate of adoption for new versions of the operating system prevent developers from being able to use the latest APIs. But native application developers aren't the only ones who are feeling the pain. A prominent Web developer has recently drawn attention to the challenges that Android version fragmentation poses for mobile Web development.

As we explained in some of our recent Android browser coverage, the platform's default Web browser has historically not been very good at handling the most intensive application-like Web experiences. It lacks support for many modern Web standards and has difficulty handling things like animated transitions. Google is finally correcting the problem by bringing a full port of its excellent Chrome Web browser to the Android platform.

Read the rest of this article...

Read the comments on this post

0
Your rating: None

Adobe Shadow makes it easy to test your site on multiple devices at the same time. Photo: Adobe

Adobe Labs has released Adobe Shadow, a new project that offers a simple way to test your websites on multiple devices at the same time.

To try out Adobe Shadow, head on over to Adobe Labs and grab the desktop app and Chrome browser plugin, along with the Android and iOS offerings.

If you’ve never tried testing your site simultaneously on multiple devices, the fact that Shadow consist of four separate apps should give you some idea of how difficult it generally is. Thankfully, once you have all the pieces installed, Shadow makes the rest of the testing process as simple as hitting refresh. In fact, much of the time you don’t even need to do that — Shadow will automatically mirror whatever you’re doing on the desktop to the rest of your connected devices.

Though it’s still a beta release, Shadow may well be the most useful thing Adobe has ever built for web developers, particularly those that have embraced responsive design. It’s no secret that, while responsive design allows developers to easily target a wide range of screen sizes, it adds a considerable amount of work to the development process. But with Shadow mirroring your website across dozens of devices at the same time, testing becomes simple and easy. It’s a bit like synchronized swimming for web browsers. You can even debug and make changes directly in Chrome and then see the results on each device. To get an idea of how Shadow works, check out this overview video from Adobe:

There are two small problems with Shadow. The primary problem is that Shadow will only test your site in WebKit mobile browsers. We’d hate to see Shadow become yet another reason for developers to ignore non-WebKit browsers. So, while Shadow is great, it won’t give you the whole picture right now.

The good news is that Shadow is a beta release and a work in progress. I spoke with Bruce Bowman, Senior Product Manager of Shadow and, while he stopped short of committing to anything, Bowman made it clear that Adobe plans to keep expanding Shadow’s capabilities as the project progresses.

The other problem with Shadow isn’t actually a problem with Shadow directly, but its usefulness is nevertheless directly related to the number of iOS and Android devices you have on hand. Obviously those that will benefit most from Shadow are large web development shops with the budget to invest in dozens of mobile devices. Shadow is no less handy for individual developers with only one or two devices, though the results are of course limited.

Should Shadow prove popular, perhaps it will help spur the sort of device swap gatherings we’ve heard mobile expert Peter Paul Koch suggest — a group of web developers pool their resources, bring together a wide range of mobile devices and take turns testing websites. Shadow could make that process considerably easier and faster thanks to its live editing capabilities.

0
Your rating: None

  

Depending on who you follow and what you read, you may have noticed the concept of “responsive text” being discussed in design circles recently. It’s not what you might imagine — resizing and altering the typography to make it easier to read on a range of devices — but rather delivering varying amounts of content to devices based on screen size.

One example of this is an experiment by designer Frankie Roberto. Another is the navigation menu on the website for Sifter App. Roberto and Sifter are using media queries to actually hide and display text based on screen size (i.e. not rewriting or delivering different content based on context — as one would do with mobile-focused copy, for example).

Having looked at how this technique works, I wouldn’t endorse it yet, because its practical value is not clear. Also, describing this as “responsive” could legitimize what is possibly a less than optimal coding technique. Below are screenshots of how it works on the Sifter website:

Website for Sifter App
Altering the tabbed content in the navigation menu at Sifter. Large view.

How Is This Accomplished?

In this example (and in Roberto’s demo), you’ll notice a couple of things. The screenshots show two versions of the Sifter website at different screen sizes to demonstrate what is happening at two breakpoints.

When you view the website on a large device, the second-last menu tab will show the full label of “Pricing & Plans.” On smaller devices (anything up to the size of a tablet), the label changes to just “Pricing.” This particular example might not be a big deal, but my main concern is that this is being regarded as “responsive text.” It’s not. It’s simply hiding bloated content, and if the content is not important enough to show on smaller screens, then it’s probably not vital at any size.

Does the change in wording mean that information on Sifter’s plans is offered only to users on large devices, or is the “Plans” part redundant? We can assume not, because the tab at all screen sizes links to the …/plans page. This is potentially confusing for users on small devices: they clicked on “Pricing” but are sent to a page that outlines the plans first.

To show and hide the “Plans &” part of the tab, Sifter’s designer has wrapped the element in a span. For a single menu item, this isn’t the end of the world, but good luck going down the path that Frankie Roberto demonstrates with his paragraphs. I can’t imagine what a nightmare it would be to maintain multiple versions of actual page content and then tie them into breakpoints! (Not to mention our earlier question about whether text that is hidden at certain sizes is redundant in the first place.)

Hopefully, we all know to avoid hiding content with display: none !important;. Responsive design is many things; its many little tricks and techniques constitute a wonderful approach to making websites flexible. But hiding elements on a screen in this way should not be one of them.

It’s Just a Demo, Though, Right?

Frankie Roberto’s demo is just that: a demo. He’s clear about that, and he offers a suggestion for a use case. I applaud the effort — everyone should experiment with the Web. The Sifter website is a live website, though — not a demo or proof of concept — and what it has done is being described as “responsive text.”

I’m a huge fan of the concept of “one Web.” If you find you have to hide parts of your content on smaller devices, then you might need to refocus your efforts and write less bloated copy or reconsider your wording of page elements.

One of the joys of working “mobile-first” is having to maintain a sharp and critical eye in order to cut bloat (a capacity we should always exercise, of course). Responsive text seems to be the polar opposite of this approach. You are practically admitting from the outset that too much text is on the page. You are making the dangerous assumption that someone on a small device wouldn’t want to read the hidden text.

Maintenance Problems Will Come Hard And Fast

Frankie Roberto achieves a clever effect in his demo. On a large screen, you see all of the copy. And as the screen shrinks, so does the amount of content (and vice versa, of course).

Responsive text demo on a large screen
Roberto’s full content, on a desktop screen.

Responsive text demo on a small screen
On a smaller screen, the content is reduced.

Achieving this in the demo is easy. A CSS class is applied to the excess paragraphs to hide them.

Some Potential Problems to Consider

  • The copy will have to be highly structured in order for it to be readable when parts of it are hidden on small devices. For example, if a content block has 10 lines, then it should still flow when lines 2, 5, 9 and 10 are hidden on a tablet and lines 2, 4, 5, 9 and 10 are hidden on a phone.
  • The writer would need some mechanism in the CMS for flagging the breakpoints in the content. The method for updating content would end up being rather technical as a result.

If the message you are communicating on a small screen is sound, then there is nothing you could really “enhance” it with. Anything you add would simply be bloat.

Are There Any Potential Uses For Responsive Text?

I don’t think there are. But I realize this is just my opinion, and I encourage readers and the wider Web community to evaluate it for themselves and disprove me with solid examples.

When discussing this on Twitter the other day, I got interesting responses from a number of fellow designers. Many agreed that whatever you display on a small screen should be your content everywhere, because that is the distillation of your message.

Roberto (@frankieroberto) suggests a potential use case for adaptive news content; for example, showing a summary, a mid-length version or the full article depending on the device. This does sound like a useful way to digest news, but in such a fast-moving environment, I can’t imagine copyeditors would thank you for assigning them to write content that adapts so extensively and still makes sense in these different contexts. But it’s something to think about.

Stephanie Rieger points out that producing bloat-free content on a big website can be incredibly time-consuming:

@welcomebrand @froots101 Discussions with stakeholders reveal last round of copywriting took 6 mths End result, hide text on ‘lesser’ screen

No argument there. I’m working on rebuilding a large website, too, and am encountering the same issues. But I’m not sure that hiding content based purely on screen size is wise. If it’s not relevant or worth displaying, don’t simply hide it: delete or unpublish it.

In Conclusion

My interpretation of the Sifter website and what its designer is trying to achieve may be wrong (this is an opinion piece, remember!). Feel free to tell me as much in the comments below. But from my quick look at the design, code and copy, I won’t be embracing responsive text anytime soon, despite it being an interesting experiment and endorsed by some very clever folks.

I struggle to think of a use case that withstands the basic scrutiny that I apply to content for my clients, which is that if all of the content is not good enough to show on all devices, then the amount of content is not optimal. I recognize that this is a harsh stance, so do check out the code and experiments covered here so that you can make up your own mind.

Remember, just because something is “responsive,” it might not be best for your project.

(al)

© James Young for Smashing Magazine, 2012.

0
Your rating: None

With a mobile-first responsive design approach, if any part of the process breaks down, your user can still receive a representative image and avoid an unnecessarily large request on a device that may have limited bandwidth. But with several newer browsers implementing an “image prefetching” feature that allows images to be fetched before parsing the document’s body, some of the web's brightest developers are abandoning responsive images in favor of user agent detection, at least as a temporary solution. For us standardistas, UA detection leaves a bad taste in the mouth. More importantly, as the number and kinds of devices continue to grow, UA detection will quickly become untenable—just as browser detection did back in the bad old days before web standards. What's really needed, argues Mat Marquis, is a new markup element that works the way the HTML5 video element works. Sound crazy? So crazy it just might work.

0
Your rating: None