CSS Media Queries are a Useful Tool for Mobile

One of the unfortunate side effects of the strident title I chose was that it gave many people the impression that I didn’t think CSS Media Queries were useful at all for mobile.

That’s not the case. We’re using them in two mobile projects right now and contemplating using them for a third.

I wrote in the post that “CSS media queries are a tool, but they are not a silver bullet.” But that point was overshadowed by the post title and the rest of the article talking about the problems that you need to be aware of when using them.

I got a chance to chat with Ethan Marcotte via Twitter. He wrote:

I think we agree on the fundamental points, honestly—the implementation should always be tailored to the site/audience.

I wholeheartedly agree. In fact, Ethan wrote in his article about Responsive Web Design:

That’s not to say there isn’t a business case for separate sites geared toward specific devices; for example, if the user goals for your mobile site are more limited in scope than its desktop equivalent, then serving different content to each might be the best approach.

In the same way in which my more nuanced opinion about media queries was skewed by my poor choice of title, I think Ethan’s nuanced opinion about when and how media queries can be used for mobile has been skewed by the enthusiasm that people had in response to his A List Apart article and how they might use the technique for mobile.

As I said in my post and reaffirmed to Ethan over Twitter, I’m actually quite excited about Responsive Web Design. I’m going to write more about that separately.

What I really meant to say was…

Even though Ethan never intended media queries to be seen as a total solution for mobile, that view has been enthusiastically adopted by others. I’ve read many blog posts and tweets on the topic. There was a session at Web Visions called Mobile Web Dev without Developing a Mobile Site based on building sites using media queries.

PPK got is right when he said that I “challenged the conventional view that media queries are all we need to make a website mobile-friendly.” There was a growing consensus that media queries were all that was needed and that consensus needed to be challenged.

In rereading my post, there is one sentence that I think best summarizes my view:

The way in which CSS media query has been promoted for mobile hides tough problems and gives developers a false promise of a simple solution for designing for multiple screens.

I’ve modified the sentence slightly to make it clearer that it was the way media queries were being promoted as a solution for mobile that was the real problem.

It is also clear that fool’s gold is not the right phrase. Fool’s gold is something that looks like something of worth, but in reality has no intrinsic value. Media queries do have value and are useful tools.

I’m sorry for poor title choice.

Great Ways to Use CSS Media Queries

There are a few great use cases for media queries for mobile. I highlighted selected web apps and html emails in my previous email. A few others are:

• As PPK suggests, pairing media queries with javascript could be the core of a mobile web solution. The javascript can be used to swap the correct images in for each context. This is most effective if you start from a mobile design and use media queries and javascript to add functionality for desktop users. You also need to understand which devices your customers are using to make sure this technique works for those browsers.
• As Pim Derks commented on my post, in situations where “a client has a limited budget, but wants his site to look good on iPhone.” Given the alternative of no mobile web site, it makes sense. I’d suggest looking to see what you can do to stop unnecessary downloads where possible.
• And the most likely use of media queries, as a small part of a larger mobile optimization effort or a discrete tool being used in one off situations like web apps or html emails.

You’ll notice that the solution that PPK suggests is quite a bit different than starting from the desktop web and simply adding media queries.

It requires images to be uploaded in multiple sizes. For optimal use, it requires html to be retooled to start with mobile web appropriate html only and then javascript to enhance it.

It is entirely possible that a great mobile solution could be built that way. I question the likelihood that web sites are going to be retooled to deliver mobile html first and then progressively enhanced with javascript and css. But I’d be happy to be wrong about that.

What are the Tough Problems that Discussion of Media Queries Obscures?

I’ve enumerated many of the technical challenges with media queries, but when I talk about media queries hiding tough problems, I’m not talking about any of the issues I raised in my previous post.

What I was referring to was the idea that there was a simple solution to creating a mobile web site obscures a series of infrastructure issues that I believe web developers are going to be confronting over the next few years.

Let’s assume for a moment that there are situations in which you need to deliver different html and associated assets to different mobile devices. To do so requires that your content management or ecommerce system is equipped to do the following:

• Detect different devices and the capabilities of those devices.
• Select the correct template based on the device. This implies that your system gracefully handles multiple templates.
• Separate assets added by authors from the words that they write so that those photos, video, etc. can be resized and reformatted appropriately for the device.
• Provide tools or establish processes for resizing images and videos. Either manually, or better yet automatically, encode video in multiple formats based on the device.
• Support non-web consumption of content (e.g., native applications). This will likely require further consideration of how to remove markup and presentation from content.

And many more obstacles created by legacy web publishing tools designed long before we started thinking seriously about mobile.

The big challenges our clients face are rethinking and retooling their infrastructure for mobile. It’s going to be a massive undertaking for a lot of businesses.

The sooner we realize this fact, the sooner we can get to work figuring out the best ways to build that infrastructure.

Even I’m guilty of contributing to this meme with my article on CSS orientation.

Unfortunately, CSS media query is fool’s gold for mobile devices. It hides tough problems and gives developers a false promise of a simple solution for designing to multiple screens.

The Short Version

Ferreting out the problems with CSS media queries for mobile devices is easy if you look at what media queries purportedly promise:

All you need to do to transform your desktop web design into something optimized for devices with smaller screens, less powerful CPUs, and slower network connections is to add more code.

The idea of adding more code—adding more to download—in order to optimize for mobile should be the first clue that this isn’t a good solution.

Core Assumption: Speed Matters More on Mobile

I’m going to point out several technical flaws with media queries. Nearly all of them rely on my belief that speed matters more on mobile devices.

That isn’t to say that we’re more tolerant of slow desktop web pages. Instead, that mobile is more likely to be used in situations were the speed of access matters more (urgently looking for a business) and under conditions (network speed, device processing power) that are less optimal for speed.

When designing for mobile, performance is a key consideration.

Letting the Browser Scale Images is a Bad Idea

Ethan’s article on Responsive Web Design relies on a technique he calls Fluid Images.

The idea behind fluid images is that you deliver images at the maximum size they will be used at. You don’t declare the height and width in your html, but instead let the browser resize the images as needed while using CSS to guide their relative size.

This technique is a bad idea for mobile for a couple reasons.

Full Images = Unnecessarily Large Files to Download

The full image is downloaded despite the fact that it will only be seen at a fraction of the size on a mobile device. In the Responsive Web Design example page, the images are 330 x 345 pixels in true size, but when viewed on an iPhone, they are only ever seen at approximately 150 x 157 pixels.

The six images of characters from Sherlock Holmes that are included in the example page total 208K. Resizing those images and optimizing them reduces the total file size for all six images to 45K. That’s an 78% reduction in file size and download time.

Downloading 162K unnecessarily on a mobile device is nothing to sneeze at no matter how good the mobile phone is.

Browser Resizing Can Be CPU and Memory Intensive

Yes, desktop browsers and iPhones have no trouble resizing images, but what about older or cheaper phones with less formidable CPUs? With this technique, we’re asking them to download larger images, uncompress them to their full size in memory, and then resize them to fit the screen.

Even Apple’s Mobile Safari documentation says “You need to size images appropriately. Don’t rely on browser scaling.”

Using Media Queries to Deliver Different Images Doesn’t Work

I know what many of you are probably thinking. So the fluid images technique doesn’t work. Let’s just use media queries to deliver different images depending on screen size.

There are two ways this can be accomplished. The first is to have image tags that are hidden by CSS. The second is to use CSS background images and switch the background image. Let’s look at both techniques.

Hiding Image Tags Using CSS Media Queries

Rachel Andrew’s article about CSS media queries showcased dConstruct’s web site as an example.

The dConstruct site is beautiful. The site grows bigger as your browser gets bigger. The photographs come to life when you hover over them. It’s truly worth a look.

The large photographs of the speakers are placed on the page using image tags. The black and white images are a single sprite that is layered over the color photographs using CSS.

And if you view the site on a mobile device, the large photographs of the speakers are hidden from view. You get a simple list that fits well on the screen.

A CSS media query instruction is used to set display:none on the div containing the speaker images.

However, the iPhone still downloads the images even though they are not displayed.

There was a some speculation during the Big Web Show interview with Ethan Marcotte that perhaps the tools that were reporting what the browser was downloading were erroneously inflating the number of files that were truly download.

To verify that images are downloaded despite CSS media queries, I tested two different ways. First, I made a copy of a page using the responsive design onto a local server, loaded it on an iPhone, and then watched the web server logs to observe what was downloaded. Second, I set my iPhone to use my Mac as a proxy server so every request to dConstruct’s site was logged.

In both cases, it showed the image files are downloaded despite the fact that the media query has set them to display:none. This means that the iPhone downloads an extra 172K for photos that the user will never see.

Hiding CSS Background Images

Surely CSS background images will work better than image tags, right? Wrong.

I tested a few different combinations of CSS background images and media queries. What I found was:

• Using CSS media query to set display:none on an element containing a background image does not prevent Mobile Safari from downloading it.²
• Using CSS media query to override a background image with one created specifically for mobile results in both the desktop and the mobile image getting downloaded.⁴

Two methods that appear to work are:

• Setting the parent of an element with a background image to display:none.³
• Using media query min-width declaration to only specify a minimum browser width for the desktop image and a max-width for the mobile image does result in only the mobile image being downloaded in Mobile Safari.⁵

These two options mean that using CSS media queries isn’t completely impossible, but using the parent element to hide images and changing existing desktop CSS to add min-width declarations are significant changes to existing CSS. It isn’t going to be as simple as adding a CSS media query for mobile and calling your job done.

FWIW, it is this behavior of downloading images even if they are currently not displayed that allows us to have images show up in pull down menus and on other hover events without a delay while the image is downloaded. This is generally a good thing.

CSS Media Queries Do Not Optimize HTML or Javascript

My first introduction to media queries was when we were asked to assist another web developer who had built a page that contained a Google Map on the desktop version, but the div containing the map was hidden on the mobile web version using a media query.

Unfortunately, even though the map no longer showed up, the 180K javascript library was still downloaded by the browser.

CSS media queries will not remove unnecessary html nor remove javascript that will slow down mobile browsers.

CSS Media Queries aren’t Supported Well

If you can overcome all of the challenges I’ve outlined above, you’ll find that CSS media queries are not supported by many mobile browsers. PPK’s compatibility table shows that even amongst modern smartphones, the support is spotty and inconsistent.

The picture is much worse when you decide to support older browsers.

If you choose to use media queries to provide a mobile version of your web site, you’re not only picking a poor solution, but you’re excluding a large number of mobile users.

People with modern smartphones may be the demographic you care about, but you should be make a conscious decision about what device classes you support.

Ignoring the Mobile Context

The promise of CSS media queries is that you can take your existing desktop web site html and add this additional presentation layer for mobile. Doing so ignores the fact that a mobile user may have very different needs than a desktop user.

There is a great quote from Brian Fling in his book on mobile design:

Create a product, don’t re-imagine one for small screens. Great mobile products are created, never ported.

Does your desktop web home page use geolocation lookups? Probably not. Should your mobile site home page? Quite possibly.

If you send the same HTML and Javascript to the mobile user that you do for the desktop user, even if you format it to fit their screen, you’re likely missing opportunities to provide a great mobile experience based on the capabilities of the device and the context of the mobile user.

Separate Mobile Web Sites are a Good Thing

I know separate mobile web sites are a pain to develop. We have a lot of infrastructure to build to make the mobile web go, and I’m going to be writing more about that soon. But there are good reasons why we need separate mobile web sites.

During Ethan’s interview on the Big Web Show, some time was spent discussing how sharing links from the New York Times doesn’t work the way you would hope. If you send a link from the mobile site and someone opens it on their desktop browser, it is still formatted for mobile.

The conclusion drawn from this during the podcast is that CSS media queries might be a better solution because there would only be one URL, and it would work for both desktop and mobile.

Here’s some hard numbers to consider from a YSlow examination of the New York Times desktop and mobile home pages:

As you can see, the mobile web site has a fifth of the HTTP requests of the desktop version and is 583K smaller. That’s over 90% smaller and significantly faster on a mobile device.

(As an aside, HTTP requests are much more expensive on mobile devices than on desktop due to the latency of wireless network connections.)

I agree that the NY Times links should work, but the solution isn’t to take the bloated desktop home page and add more CSS code to make it mobile (un)friendly.

Some Good Uses of CSS Media Queries

There are some good uses of CSS media queries. If you’re building a discrete web application where you have more control and can make sure that the desktop web isn’t bloated, it can make sense.

Also, Ros Hodgekiss from Campaign Monitor wrote an exceptional article on how you can use media queries in html email to provide a mobile optimized layout. This is perhaps the ideal use case because when you send html email, you have no choice but to send a single html document regardless of what device the recipient will be using.

Responsive Web Design Still Rocks

Wait? Responsive web design still rocks? Hard to believe after everything I’ve written, eh?

I’m not talking about CSS media queries, but instead of the idea of building around a grid, planning your design for different screen sizes, and thinking about the modular building blocks and how they can be moved based on screen size.

That is the real gem in Ethan’s article. I hope we see two things come from his responsive web design piece:

• More desktop web sites that take advantage of fluid grids and CSS media queries to optimize for the multiple sizes of desktop screens. Media queries still make sense for desktop designs.
• More designers and developers thinking about design as modular even if it isn’t implemented with media queries.

I find his comparisons to responsive architecture to be fascinating and the designs we’ve seen using these techniques to be compelling. But the core mechanism used to accomplish them, CSS media queries, isn’t up to the task when it comes to mobile development.

No Silver Bullets

Developing for the mobile web is difficult. There are no simple solutions that make it easy to provide a great mobile-optimized experience. CSS media queries are a tool, but they are not a silver bullet.

This shouldn’t be a surprise to us. We now take our content management systems for granted, but it wasn’t always this easy for the desktop web. We forget how difficult it was to simply get Apache running properly.

During the last big wave of technology, we had a lot of infrastructure to build before we could reliably deliver quality experiences for desktop browsers. We’ve got a similar road ahead when it comes to mobile.

But no matter how difficult, mobile is worth it. The power of having information in people’s hands—no matter where they are in the world—makes mobile worth the extra time and effort.

I’m not sure I’ll attend SXSW again.

Don’t get me wrong. I enjoyed the conference in many ways. I got to see friends that I haven’t seen in months. I met people that I’ve always wanted to meet. I had fun speaking with people about the iPad, and it was great to experience Mobile Monday in another city.

Austin is an amazing city. I had a blast in the city, and I feel like I saw and experienced more of the city than I typically do at conferences.

Unfortunately with a few notable exceptions, the conference itself was not terribly good.

I’m not sure why this is. I have read others talking about how this conference was worse than previous ones. It saddens me to think that when I finally manage to attend the reknowned SXSW, that it has jumped the shark. But it appears that may be case.

One of the main problems in my opinion is the dominance of panels at the conference. I find panels to be of lower quality overall than presentations by a solo presenter.

I’m not sure why SXSW has so many panels, but I have a few generous and not so generous theories.

The generous theory is that SXSW values the input of the community. It starts with allowing anyone to vote for session, continues with selection of panels, and is demonstrated by their core conversation sessions designed to foster discussion instead of presentations.

The less generous theory is that people propose panels solely to get free passes for themselves and their friends.

I was told essentially that on my return trip to the airport. I took a shuttle and bumped into a friend. He asked what I thought of the conference, and I lamented the fact that the sessions had been so poor.

Two of the other passengers in the shuttle told me that my mistake was that I didn’t get a pass for the conference. They didn’t know that I was a speaker at the conference so they proceeded to tell me how I needed to get on a panel so that I could get a free pass.

Then they laughed about how once you have a pass and are on a panel, you don’t have to prepare anything. You just roll into your panel, answer questions, and then use your pass to network and party.

I was extremely offended. I couldn’t believe that they could have such disrespect for people’s time and money.

Even though I only had four minutes to present during my panel, I started researching as soon as I knew I was going to be on the panel.

I had several pages of notes in addition to my slides. I decided to hack the format to make the panel more interesting by treating my presentation like an Ignite talk which meant I had to practice extensively to get the timing right. I also set up a script to tweet background information during my presentation.

And I wasn’t the only one. Everyone on our panel took it seriously. We prepared ahead of time. The audience response to our session was great.

I know a lot of people don’t attend conferences for the sessions. My friend Aaron Hockley’s recap of SXSW is talks about how the value of conferences is not the sessions, but in the connections that are made.

I agree with Aaron that tremendous value comes from the connections, but that’s no excuse for treating the people who attend your session poorly and wasting their time.

The contrast between the attitude of the fellow passengers on my shuttle and the work that Jay Rosen and his fellow panelists put into their SXSW session couldn’t be starker. In fact, it seems completely inappropriate that those who treat SXSW panels so disrespectfully should be able to share the metaphorical stage with Rosen and others who take the conference seriously.

The attitude that some have towards SXSW reflects poorly on those of us who take our roles as speakers and educators in the technology community seriously.

I don’t know if this is a pervasive attitude of speakers at SXSW, but I can say that the quality of content way not what I expected. I expected to be inspired as Jeremy Keith was. That’s what I want from any conference.

Perhaps I just picked sessions poorly, but instead of being inspired, my final and lasting impression was of a conference that didn’t deliver.

I decided to give them a try during the conference. That is until Foursquare decided to give me a “Hookup Badge.”

Apparently, the Hookup Badge is given to someone who checks in at two different hotels.

For anyone visiting Austin who doesn’t stay at the historic Driskill Hotel, there is a good chance you’re going to check in at two hotels during your trip. The Driskill is a must see and you will likely check in at the hotel you’re staying at.

That is what happened to me.

I checked in at the Driscoll Hotel when I met friends there. I purposely asked Foursquare not to tweet the check in because I feel like it is spam in my Twitter stream.

However, I didn’t remember that I had allowed Foursquare to post updates about badges that I won. Foursquare didn’t tweet the check in, but it did tweet about my “Hookup Badge.”

So part of the blame is mine. I shouldn’t have let Foursquare post to Twitter at all.

At the same time, I had no expectations that Foursquare would be posting inappropriate tweets. I’m a happily married man. Joking about hooking up while I’m on business travel is not funny.

Thankfully the damage was limited. A few months ago I disconnected Twitter from Facebook. Otherwise, my new “Hookup Badge” would have been shared with family members who would have no idea what Foursquare is nor understand Foursquare’s idea of a “funny” badge.

When I relayed this story with Péter Green of Finnish Mobile Association, he told me how he had received the “Hangover Badge,” and received many comments from his friends back home.

Those comments were funny, but imagine how quickly they would have turned into concerned or panic if the Hangover Badge was handed out to a recovering alcoholic who was half a world away.

I like the idea of gaming mechanics to get people to participate in a location-based service, but Foursquare seems to be making some big mistakes here:

• The incentive structure in the game should be known instead of a surprise. For example, if you check-in more times than another person, you become mayor. That’s well known and easy to understand. The Hookup and Hangover badges use rule combinations that you don’t known until you unwittingly unlock a badge.
• The badges indicate a lack of perspective on what issues they may cause for the people who receive them.
• The overall impression of the service based on these badges is one that is designed for party-going twenty-somethings. It’s hard to take such a service seriously.

We’ve heard a lot about location-based services and cell phone logs getting people in trouble for their infidelity. There’s no need for services like Foursquare to create problems where none exist.

As far as I’m concerned, this was inexcusable breach of trust. I deleted my Foursquare account and will not use their service again.

More often than not, we’re building that site using Drupal. We believe Drupal is a perfect fit for organizations and associations.

Before we started started Cloud Four, Aileen, Lyza, John and I had all worked for several years at Kavi which is focused on providing software for organizations.

John was one of the co-founders of Kavi. Lyza was one of the first employees. And Aileen and I had been at Kavi for over seven years.

Needless to say, we have a lot of experience working with these organizations.

After we left Kavi, we searched for a new web platform that would fit the needs of these organizations. Our experience had taught us that while there are some common characteristics of organization web sites, that each organization has unique goals and functionality that they need implemented on their site.

With that experience in mind, we tried many different solutions before settling on Drupal. Drupal provides:

• Top-notch content management features
• Support for simple or complex user management
• Foundation that provides for future expansion
• An active development community
• Ability to build custom solutions on top of Drupal if needed
• Integration ease including the NTEN favorite membership management suite, CiviCRM¹

In addition to these core features, we found that Drupal supports other things that organizations often talk about such as:

• Revisioning
• Authoring Roles
• Content Syndication
• News Aggregator
• Tagging
• Localization
• Blogging
• Forums

All of this goodness wrapped in an open source platform that is widely used by both companies and non-profits.

We’ve been talking to our customers and partners for quite some time about why Drupal makes sense for organizations, but have been waiting for the perfect showcase site to make the point to a larger audience.

As you can see from the recently launched JEDEC.org site, Drupal makes it possible to build beautiful and powerful web sites that accomplish the objectives of standards-setting organizations and associations.

If you’d like to learn more about how Drupal can help your organization, association or your company (Yes, it works well for corporate sites as well!), please contact us.

We’d be happy to talk to you more about how Drupal can help your organization.

1. As an aside, if you run an organization and haven’t looked into CiviCRM, we highly recommend that you do. It is a full-featured, open source membership tool that integrates fully with Drupal. Not only that, but our friends at raSANTIAGO + Associates provide a great service called CiviServer and are experts in helping organizations utilize CiviCRM effectively.

The name comes from the fact that you can only have 20 applications on the iPhone’s Home (or first) screen.

To date, the site showcases 35 home screens from various luminaries. The site also lists the most popular applications as:

• Tweetie – 21 home screens
• Things – 11 home screens
• Facebook – 10 home screens
• Birdfeed – 9 home screens
• Instapaper – 8 home screens

Unfortunately, First and 20 was wrong. These are not the most common applications on these 35 home screens.

Here is my count based on reviewing the 35 home screens. I gave extra credit for applications that were listed in the dock because they remain visible on every screen—not just the home screen.

The most popular applications are Phone, Mail and Safari. These are the only three applications that are on all 35 home screens.

Looking at the table now, it seems obvious that these applications would be the most popular applications. Of course people want to make phone calls, send email, and browse the web.

But as I mentioned in a previous post, because of the focus on the the iPhone and the iPhone App Store, massive changes are happening right in front of everyone’s noses and most people are missing them.

The number of articles talking about App Stores and strike-it-rich application stories vastly outnumber those talking about the explosive growth of the mobile web.

Consequently, many businesses are focused on how their going to build an iPhone application and missing the fact that those same iPhone owners are already probably trying to access their web site on their mobile phone and failing.

Should it be surprising that the most popular applications on the iPhone are Phone, Mail and Safari? No, but if you believe what you read in the media these days, these applications are underdogs when competing against the explosion of apps.

Making calls. Sending email. Browsing the web. There are apps for that too.

On slide 29, Meeker starts her argument that “The Mobile Internet Is and Will Be Bigger Than Most Think.” I encourage you to read her slides and watch the video of her talk. Both are embedded below.

I’ve been thinking a lot about how her title speaks to what is going on right now in most people’s minds when it comes to mobile.

There is so much focus on iPhone applications and the iPhone generally, that massive changes are happening right in front of everyone’s noses that aren’t being noticed or are being taken for granted.

Perhaps the simplest example of this is the explosive growth of the mobile web. We have analysts predicting that 1 billion mobile web users in 2010—more than the number of PC users accessing the web.

Opera continues to report exponential growth in usage of its Opera Mini browser—a browser designed for low end feature phones instead of smart phones like the iPhone. The biggest growth is happening in developing countries.

And despite all of this mobile web growth, most businesses aren’t taking the steps necessary to optimize their web sites for mobile devices. Some have iPhone blinders to such a degree that they undermine their own iPhone applications.

And its not just the mobile web. The same could be said for SMS, MMS, GPS, or cameras.

In her presentation, Meeker stated talked about this as a trend for 2009, but I don’t see this disconnect between the size of the mobile Internet and most people’s perception of it going away any time soon.

In fact, Meeker summarized succinctly what I’ve been writing and about presenting about for the last couple of years.

Therefore, I’m adopting her trend title as my theme for next year.

• 2010: The Mobile Internet is Bigger than You Think

That’s right. The mobile internet is already here and it’s bigger than you think. Are you ready? If not, what are you waiting for?

Previously, if you retweeted something, your retweet was your own. Only you had the ability to delete it.

But with Twitter’s new retweet feature, your retweet is tied to the original author’s tweet. And if the original author deletes the tweet, your retweet is deleted from your timeline.

I’m not sure what the proper way to handle this is.

On the one hand, if the original author shared something they wished to retract, it would be nice to honor that.

On the other hand, the tweet didn’t happen in a vacuum. More importantly, the act of retweeting should be tied to the timeline of the person who retweeted it. Someone else shouldn’t be able to scrub that history.

What do you think?

My plan was simply to ignore the new retweet feature until they fixed its shortcomings. However, Loren Brichter released a new version of my favorite Twitter client for the iPhone, Tweetie, that incorporates the new retweet feature and “deprecates” the old way of retweeting.

After spending some time with the new version of Tweetie, it became clear that the new retweet feature and all of its warts are here to stay. Instead of ignoring it, it was more important to document the ways it is broken and try to get Twitter and the developers of Twitter clients to fix it.

What Ev Got Wrong

Ev’s post does an excellent job of outlining the perceived shortcomings of the old way of retweeting. I’m grateful for his explanation. Not only is it helpful to understand the design decisions they made, but it also helps me understand where Ev missed important uses of retweets.

Attribution Confusion vs. Credibility and Reputation

One of the main things that Twitter was trying to solve with the new retweet feature is attribution confusion. “Most notably, the text of the tweet is not written by the person whose picture you’re seeing, nor the username that’s at the beginning.”

The solution to this in the new retweet feature is to show the name and picture of the original person who wrote the tweet and annotate below the tweet the name of the person you are following who retweeted the post.

The problem with this solution to attribution confusion is that it eliminates one of the main values of retweets: the credibility and reputation of the person who is retweeting.

By removing the picture of the person who retweeted and making the name much smaller, it becomes much harder to tell quickly which of the people you are following retweeted the post.

The person who retweeted a link to an article matters a lot. We place different value on the people we follow and the information they share.

In the example above, it is more important to me to know that Dave Winer was the source of the retweet than it is to know that jenny8lee—someone I don’t know—wrote the original tweet.

Tim O’Reilly is someone who I find to have very intelligent takes on technology. When I see his picture in my twitter stream, I stop scanning and pay closer attention. His credibility and reputation is what makes me pay attention to what he tweets or retweets.

This is something that the independent Twitter clients have done a better job of addressing than Twitter itself. Both Tweetie and Tweetdeck have included both the picture of the person who originated the tweet as well as the person who retweeted.

I much prefer the way Tweetie handles the retweet in the screenshot above to the way Twitter handles it. I see both Dave Winer’s name and picture. My only complaint is that the picture of the person retweeting is often too small to recognize quickly.

Redundancy vs. Dipping in the Stream

Another point that Ev makes is that “if five people you follow retweet the same thing, you get five copies, which can be useful but is a lot of noise.”

Ev is right that if you are reading every single tweet having redundant retweets can be a bit of noise. That said, it isn’t something that has ever bothered me.

The multiple retweets has however been something that has alerted me to important information. When you think of Twitter as a stream that you dip your toes into when you have time, important information can be missed if it only shows up in your stream one time. However, the more people retweet it, the more likely you are to encounter it whenever you decide to dip your toes in your Twitter stream.

I have to look no further than this past weekend to see the importance of this. On Saturday, the City of Portland announced that e-coli had been found in some of its water supply.

I happened to be out with the family in one of the affected areas. While waiting in line, I checked Twitter. By the time I checked, it had been several hours since the announcement. Yet, I saw one of the many retweets about the outbreak and was able to advise the people around me what water to avoid.

Let me repeat, the only reason I learned about the e-coli outbreak was because I received multiple retweets.

Another reason multiple retweets are valuable is because of reputation and credibility. A retweet from someone I follow whose opinion I value more highly than others is more likely to catch my eye.

There is value in multiple retweets. I’d love to have this be an option to see all retweets or only the first one.

Problems with the Current Implementations

Aside from the two viewpoints about credibility and the value of multiple retweets, there are things lacking in the current retweet implementations. As my friend Peter Whooly pointed out, it’s hard to tell if these are problems with the Twitter clients or Twitter’s API.

No Way to See Who Has Retweeted Your Tweets

In Tweetie, when you go under your profile and look at the retweets, there is no way to tell who retweeted your tweet. This is possible on Twitter’s web interface.

No Notification of Retweets

One of the nice aspects of the old style of retweeting was that retweets also contained the @reply syntax. This meant that you could not only could see the retweets easily, but if your Twitter client offered notifications for replies, you would be prompted when someone retweeted you.

Knowing when someone retweets you is important so that you can participate in the conversation.

Retweets Don’t Show Up in Lists

This again is an issue of credibility and reputation. Say you create a list of people whose opinions and thoughts you highly value. It is a very select list and you read every tweet these people write. When you look at that list, you will miss any retweets using the new feature.

Being able to see retweets in Twitter lists is a big deal.

Ability to Annotate Retweets

This is already on the Twitter team’s radar. Ev says they have some ideas on how they might implement it. This isn’t a show stopper for me, but it is for a lot of other people.

Vocal Minority or Silent Majority?

One of the things that got me worked up about this was seeing Loren Brichter’s take on the new retweet feature. He said, “vocal minority have problem with change – no doubt once they try it they’ll realize how awesome it is.”

Because Loren is the developer of Tweetie, the iPhone client I prefer to use, his opinion about the retweet feature matters. The fact that he thinks that:

1. it is only a vocal minority that has problems with it and
2. that we simply have a problem with change

frustrated me. From the conversations I’ve had with other users, that isn’t an accurate description.

Many of the same people who have problems with the new retweet feature embraced the new lists feature. Discounting opinions by saying people simply have a problem with change is a way of marginalizing contrary opinions without having to address them. There are legitimate issues with the retweet feature as I’ve outlined above.

And I’m not convinced that it is a minority of people who have problems with the new retweet feature. So far, I haven’t seen a single person who thinks the new retweet feature is complete.

Unlike lists which a majority of people raved about and immediately started using, the new retweet feature is something that most people seem to be at best accepting with hopes that Twitter will address its issues and at worst, so strongly opposed to the new feature that they are taking actions like refusing to upgrade Tweetie to avoid it.

How to Fix Retweets

I don’t disagree with most of what Ev said were the reasons for the new retweet feature. I also think formalizing retweets can lead to some really interesting information and features.

That said, the new feature has significant shortcomings that need to be addressed before we should consider the old way of retweeting deprecated.

I’m thankful that Loren implemented the new feature in Tweetie. It made me recognize that the feature wasn’t going away and was already impacting me even if I choose to use the old style retweet because others may use the new feature and I won’t see their retweets.

Therefore, the most important thing we can do to fix the situation is provide feedback to Twitter and Twitter client developers.

My hope is that if enough people provide feedback to Twitter (they are asking for feedback on the feature) that we can have a new retweet feature that we embrace as enthusiastically as we did Twitter lists.

In case you missed it, the FCC sent letters to Apple, Google, and AT&T asking them about Apple’s rejection of the Google Voice for iPhone application and what role each company played.

Apple and AT&T released the full content of their responses to the FCC. Google asked for portions of its response to be redacted. However, a Freedom of Information Act request prompted Google to divulge the full content of their response.

And yet despite this latest revelation, the he said, she said nature of the follow ups, and word that Google may even have a screenshot proving that Apple is lying, Google Voice is nowhere near the most important App Store rejection.

That distinction belongs to Freedom Time.

Why Freedom Time Matters More than Google Voice

Like many iPhone applications, Freedom Time was a frivolous application. The application displayed a cartoon character of George Bush with arms like a Mickey Mouse watch. But instead of telling time, the application counted down the days until Inauguration Day.

Freedom Time wasn’t one of the more high-profile iPhone App Store rejections. Unlike Google Voice, people barely noticed when the application was rejected.

What is important is the reason why Freedom Time was rejected. Apple’s response to the developer was:

Upon review of your application, Freedom Time cannot be posted to the App Store because it contains content that does not comply with Community Standards. Usage of such materials, as outlined in the iPhone SDK Agreement section 3.3.12, is prohibited:

“Applications must not contain any obscene, pornographic, offensive or defamatory content or materials of any kind (text, graphics, images, photographs, etc.), or other content or materials that in Apple’s reasonable judgement may be found objectionable by iPhone or iPod touch users.”

Defaming, demeaning, or attacking political figures is not considered appropriate content for the App Store.

Can you imagine political discourse of any significance that doesn’t include demeaning or attacking political figures? Like it or not, that’s part of the exchange of ideas that form a democracy.

This policy essentially bans any editorial cartoons—cartoons that have been part of America’s history since its inception.

The idea that political discourse might be rejected from the App Store as a matter of policy surely must be a mistake, right?

Think Different? What’s the Point?

Unfortunately, it isn’t a mistake. The developer of Freedom Time emailed Steve Jobs, and he actually got a reply. Steve wrote:

Even though my personal political leanings are democratic, I think this app will be offensive to roughly half our customers. What’s the point?

Steve

I’ve often wondered what the Steve Jobs who attended Reed College during the early days of the Watergate scandal would think of that quote.

Steve Jobs, George Bush, Richard Nixon, and Scott Ritter

These four people—two that I admire and two that broke our trust—have become linked in my mind because of the Freedom Time rejection.

Freedom of speech is easy to defend when the speech is popular, but the real test comes when you have to defend unpopular speech or things that you don’t agree with.

In Fall 2008, George Bush had the worst approval ratings since Nixon. At a time in which we had one of the most unpopular Presidents in American history, Apple didn’t have the courage to approve a simple, stupid application like Freedom Time.

What is the likelihood that Apple would approve a truly controversial and unpopular application during a time when popular opinion makes it difficult to stand up for what’s right?

I find myself wondering what would have happened if former marine and U.N. Weapons Inspector Scott Ritter had tried to release an application in 2002 talking about how there were no weapons of mass destruction in Iraq.

When Ritter did speak up in 2002 and told the world that he had been in Iraq and that there were no weapons of mass destruction, popular opinion was so high in favor of Bush policies that despite being known as a patriot, conservative, and a hawk, Ritter was called a traitor by some.

What if the only means Scott Ritter had to share what he knew with the rest of the world had been through an App Store?

Flickr Censorship Pales in Comparison

Recently Flickr received a lot of scrutiny and pressure because of perceived censorship of a political image. The image showed a modified version of Obama on the cover of Time Magazine where Obama was made to look like the Joker from the most recent Batman movie.

Yahoo, the parent company for Flickr, later explained that they removed the image from Flickr because they had received a copyright infringement claim.

I don’t care to debate the Flickr censorship case. Instead, I want to ask simply why Flickr got a lot of grief for censoring a single image that they say they removed because of a copyright claim, but Apple has thus far escaped scrutiny for a standing policy that rejects any applications that attack political figures.

The image that Flickr removed would have never made it through the iPhone app review process in the first place.

The Mobile Proposition: Trade Liberty for Security

Apple has good reasons for why it has an App Store review process. It told the FCC that:

We created an approval process that reviews every application submitted to Apple for the App Store in order to protect consumer privacy, safeguard children from inappropriate content, and avoid applications that degrade the core experience of the iPhone.

This is a very similar argument that carriers and handset manufacturers have been making for years now. The argument is that mobile phones contain so much personal, sensitive information that applications need to be vetted to ensure that consumers are protected.

This is the same argument that Ben Franklin famously warned us about when he said:

Those who would give up Essential Liberty to purchase a little Temporary Safety, deserve neither Liberty nor Safety.

And despite the fact that we would not accept similar arguments from our government, we seem willing to give up our freedoms to mobile companies for the sake of our own security.

It’s Not About Apple. It’s About Gatekeepers

While I’ve spent most of my time focusing on Apple, please don’t mistake this as a tirade against Apple. Apple just happens to be leading the way in this area of mobile as well.

The reality is that if mobile is going to live up to its promise, we need a future without gatekeepers.

It isn’t hard to conceive of a future where more people have smartphones than have PCs. In some countries, people get more news from their mobile phones than they do from their desktop computers.

Before we get to the point where mobile phones have become the primary way that people get their news and information, we need to ensure that we have the freedom to publish what we want without restrictions.

For these reasons, I’m encouraged by the work of organizations like the Open Mobile Consortium. They are tackling the difficult work of providing truly open mobile solutions that allow people in repressive regimes to communicate freely.

The Moral Imperative of the Mobile Web

In addition to the Open Mobile Consortium, we need to make sure that there are alternatives to app stores and their gatekeepers. The best alternative is web technology.

This is why I’ve gone from thinking about mobile web technology as a smart business decision for some applications to thinking of it as a moral imperative.

Even if you are an Objective-C programmer who has had a lot of success on the iPhone App Store, it is in your best interest that the mobile web develop into a viable alternative to app stores. It is in society’s best interest.

To get to that point, we need to solve the short-coming of the mobile web. We need the technology to stabilize. We need real browsers on all phones. And we need a reliable and easy way to accept payment for our mobile web applications and services.

I cannot state this strongly enough: we need an open and free mobile web to be a viable alternative to the mobile gatekeepers to ensure that we have the freedom to say what must be said and the ability to have our voices heard by others.