Testing IE Versions via IE Compatibility Modes

This past week I have encountered people asking about testing for Internet Explorer browser versions in real life, on Twitter, via email, and spray-painted under a bridge (along with the phrase I don't want the world, I just want your half). I have seen response after response directing web developers to simply use the different browser modes in Internet Explorer 9 for browser testing, in particular addressing those who are using Macs and do not want to install multiple versions of Windows for each browser instance.

I whipped up some HTML and CSS of the most basic (and invalid) sort to run my installations of Internet Explorer through the paces. Historically I have found subtle differences between the emulation modes and how the original version of a browser (specifically IE) might render a page. This time out I simply found the emulation mode testing process so confusing that I suspect many developers who rely on this method are doing it incorrectly.

Four Versions of Internet Explorer

These images represent screen shots from Internet Explorer versions 6, 7, 8 and 9 — the full install version of each, using default settings, no emulators. For the most part we can see differences between IE6, IE7 and IE8, while the differences between IE8 and IE9 are negligible.

Internet Explorer 6

Internet Explorer 7

Internet Explorer 8

Internet Explorer 9

You can see that IE6 has trouble with the 24-bit transparent PNG files, and both IE6 and IE7 apply the padding to the wrapper element differently than IE8 and IE9 do. IE6 is also not setting the height of the element that is the green box, but from IE7 onward the height declaration is honored.

Internet Explorer 9 as an Emulator

The problem is that once you install IE9 you are kind of stuck. Unless you are willing to spin up a virtual machine for the last few versions of IE you want to test (and I still recommend you at least see how IE6 will munge your pages), you have to rely on emulators. Many developers think that IE9 will allow them to see how older versions of the browser saw pages, and to some extent it will. The confusing part is that not only is there a Browser Mode setting, there is also a Document Mode setting. Using combinations of those two settings, I generated the following screen shots:

Internet Explorer 9. Browser Mode: IE7. Document Mode: IE7.

Internet Explorer 9. Browser Mode: IE8. Document Mode: IE7.

Internet Explorer 9. Browser Mode: IE8. Document Mode: IE8.

But those aren't all the modes. You can also run the browser in the following slightly confusing modes. You might notice that "Quirks Mode" most closely resembles the rendering in IE6 above, without the issues displaying PNG files. This is as close as you can get to testing IE6, and even that doesn't do justice to some of the rendering issues of that rather old browser.

Internet Explorer 9: Quirks Mode.

Internet Explorer 9: IE9 Standards Document Mode

Assuming you simply toggle the "Compatibility Mode" in IE9, which of all the above combinations do you think you'll get? Or better yet, how do you think your page will render? This experiment shows that it most closely resembles the rendering used for its IE7 browser and document modes. I would have expected it to use IE8, or at least some clear indication of which browser version it is trying to emulate. This example alone shows that even a quick cross-browser test in IE9 to test older versions of IE may provide unexpected results.

Internet Explorer 9: Compatibility Mode.

Even if you understand all the document and browser modes available in the IE developer tools, that doesn't mean your web staff, client, or random web savvy user will. The best way to truly test how a site renders in older versions of a browser is not by running emulators, but by running the versions of those browsers themselves.

If you still insist on going down the path of testing using emulators, you should take a few minutes to read the Microsoft article, Testing sites with Browser Mode vs. Doc Mode. The article outlines what each of those settings means and how it adjusts the rendering of the page.

The article makes an assumption, however, that as a developer you will want to serve up different doctypes and meta tags based on how the browser reports itself in the user agent string as defined by the Browser Mode. This image illustrates that:

If you do have a site that adjusts itself based on the browser, given the extra steps to configure the browser, test and compare differences, it's still probably easier and definitely fool-proof to use the specific version of IE that you want to test. This way you don't have to worry about incorrectly read UA strings or mis-selected settings in your browser emulator.

Conclusion

Suck it up and install some virtual machines to get each version of Internet Explorer for testing.

Update: February 4, 2013

Microsoft has made virtual machines with old IE versions available to developers at its Modern.IE site. There really is no excuse now to claim you can't test in older versions of Internet Explorer.

Update: March 14, 2013

Typekit points out the dangers of cross-browser testing with IE9′s Browser Modes when it comes to font rendering. Typekit comes to the same conclusion as I do: Instead, you should test with real installed copies of IE7 and IE8[.]

Update: March 15, 2013

Found this post on Stack Overflow, dated just a couple months before I wrote this post: How well does IE7/8 mode in IE9 compare to actually running IE7/8? Many specific issues there.

Is RSS at Risk?

I spent about a thousand words explaining RSS before I realized that, for the most part, if you are reading this blog I have to guess you have some familiarity with it (at least by just having heard of it). If you need some background, Wikipedia has a pretty good overview on RSS.

If you are a web site developer or author, there are three methods to get your Twitter feed or your Facebook business page information integrated into your site: via some sort of JavaScript-driven widget, via an API that is unique to each, or via RSS. This isn't limited to just Twitter and Facebook. PicPlz, Foursquare, and others provide these methods as well.

A JavaScript widget (whether via an embedded iframe or not) typically does not integrate well with a site, forcing the branding of the service, its color scheme, and its styles. For many sites, a Facebook widget or Twitter widget can look very out of place, almost like an afterthought. On top of this, because these widgets rely on JavaScript so heavily there is no alternative for those without JavaScript support (whether by choice, by restrictions, or by errors elsewhere on the page — see my post Beyond Hash-Bangs: Reliance on JavaScript Is a Bad Idea)

The API approach gets around styling issues, but often each API has its own proprietary offerings and syntax, requiring you as the developer to learn it, integrate it with your own platform, and spend time maintaining it as the API changes (possibly on a whim). While using this method you have control over how the data is styled on your site, relying on a free service means that you will have less input and recourse should a feature suddenly change (as I say, free doesn't mean good: You Get What You Pay For). Many APIs are reliant on JSON solutions as well, requiring JavaScript to perform the calls, and therefore the rendering, unless you are processing all of the features server-side.

The third method I mention, and the point of this post, is RSS. Because RSS has a standardized XML structure behind it (spread across parallel but unique versions, not counting variants like ATOM), as a developer you always know what to expect from an RSS feed. A JavaScript developer can just as easily parse the XML structure as a server-side coder. Once you have built a function to parse and display an RSS feed from one source, you can re-use it for any other RSS feed, forking it if you want to present the data in a different way on your site. This means you have complete control over the presentation (HTML, CSS and code structure).

In addition, most blog platforms (I'd say all, but someone might surprise me with one I don't know) not only provide RSS feeds of their data (and can even rely on a service like FeedBurner to provide additional RSS versions), they also support RSS import. This little feature means that if you provide content from your site as an RSS feed, any blogger can integrate it into his or her blog with only a few clicks.

An example of just how robust RSS can be is demonstrated with podcasts (and even vodcasts). The structure of a podcast file is really just an RSS feed with attachments, much like you might attach a file to an email. A regular RSS reader should be able to process the file, even if it cannot play the music. A podcast reader should, conversely, be able to read a standard RSS feed, even if there is no music to play.

Another powerful adaption is GeoRSS, which allows geographic data to be embedded in a feed. Syndicated content can be associated with locations on a map, something which has proven to be useful to the rise of location-based social media. For example, you can get your Foursquare history as an RSS feed, with each location tagged with geolocation data. In fact, a precursor to Foursquare, Brightkite, allowed users to generate custom RSS feeds to track specific spans of time, locations, groups of users, and even control how many items to display. When it came time for Brightkite to shutter its location-based services, it made all user data available to its users via RSS feeds.

Because of these reasons I have typically ignored hype expressing that RSS is on its way out. And then I stumbled across the post Twitter and Facebook Both Quietly Kill RSS, Completely, which was followed up a couple weeks later with Facebook Listens. RSS Added Back to Pages. Will Twitter be next?

This reminded me of an exchange I had on the Picplz API mailing list, where I asked if they would update the RSS they provided with geolocation data (since most photos are associated with a venue pulled from Foursquare). I was told that the RSS pre-dates the API and essentially that there aren't any changes in the pipe.

In just the last few days I have been struggling with the new MapQuest, trying to figure out how to embed GeoRSS in the new platform. In addition, I noticed that my "classic" MapQuest maps were no longer showing the embedded GeoRSS. After going through the support forum I found that GeoRSS is not (yet) supported in the new MapQuest, and nobody had noticed that it appears to be broken on the classic MapQuest (the solution they told me I should use for now).

So now I find myself wondering about the future of RSS. When Google Chrome doesn't even show an RSS icon or format it for display, when a new location-based service isn't adding the GeoRSS features, when a major mapping service doesn't support GeoRSS in its latest release, when Twitter buries the link for RSS, and when Facebook toys with its removal, I am concerned that they are contributing to the eventual demise of RSS.

I understand that content drivers (Twitter and Facebook) who survive on advertising revenues want to drive their brand and, ideally, their advertising to end users. Widgets that include a brand and drive people back to the advertising on the parent site make sense. For services and platforms (Picplz and MapQuest), pushing developers to a proprietary API increases the developers' investment in your platform, making it less likely for them to peel off when they can't simply apply their code to the next shiny new thing.

Unfortunately, these all combine to make the barrier to content syndication higher for everyone. While we can still wield an RSS parser to syndicate much of this content (often the one built into a blog, but typically a module within a CMS or other platform), it may be a matter of time before we lose the freedom to rapidly and repeatedly re-use a tool already in our belt. It may also be a matter of time before we as developers forget we should always build an RSS feed when we are instead enamored with the ability to claim our product or service has an API — even if it's not offering any more than an RSS feed can offer.

As developers we need to make sure we are helping our users, future developers, and ultimately our clients, by leveraging standardized tools. When it comes to content syndication and generally sharing data, RSS is the common denominator and typically worthy of implementation as the first step in a solution. If we aren't continuing to use it and expect it, the walled gardens and self-congratulatory APIs will catch up to us.

Related

• Rest in Peace, RSS, May 5, 2009.
• No, RSS Is Not Dead, and Neither Are RSS Readers, September 13, 2010.
• How to reboot RSS, September 13, 2010
• XML vs the Web, November 24, 2010.
• RSS Is Dying, and You Should Be Very Worried, January 3, 2011.
• Sure, RSS Is Dead — Just Like the Web Is Dead, January 4, 2011.
• What I mean by "the open web", January 04, 2011
• Why Big Media Wants to Kill RSS, and Why We Shouldn’t Let It, January 4, 2011.
• Blogging Forefather Seeks to Re-Invent Blogging, Again, January 5, 2011
• RSS: A Reply, January 14, 2011.
• Twitter and Facebook Both Quietly Kill RSS, Completely, May 8, 2011.
• Facebook Listens. RSS Added Back to Pages. Will Twitter be next? May 21, 2011.

HTML5 Goes to Last Call (of First Step)

If you follow the ongoing developments of HTML5, by which I mean the W3C specification and not the regular JavaScript and CSS sites-of-cool-gee-whiz bandied about across the web (Apple.com (Not Really) Updated to HTML5, Google Doodle: Bouncy Balls Aren't HTML5, Google, Arcade Fire Confused on HTML5), then you probably know that it has gone to Last Call as of two days ago. I think, however, that we all need a little context for what this means.

The version of HTML5 I am referencing here is the W3C version, not the WHATWG version. WHATWG has already stated that it will not be releasing discrete versions of HTML, owing partly to the modular nature of the specification. The W3C, however, is still keeping versions and sending the core HTML5 specification and related specifications to last call. Both organizations have been providing updates as they have them (W3C and WHATWG Provide HTML5 Updates), not counting the public mailing lists.

To clarify further, there are six specifications heading into last call, one of them is HTML5. The specifications are:

• HTML5
• HTML+RDFa 1.1
• HTML Microdata
• HTML Canvas 2D Context
• Polyglot Markup: HTML-Compatible XHTML Documents
• HTML5: Techniques for providing useful text alternatives

And just to keep things interesting, the W3C published three other documents at the same time, which are related to the six specifications mentioned above:

• HTML: The Markup Language Reference
• HTML5 diffs from HTML4
• HTML to Platform Accessibility APIs Implementation Guide

What's important to note here is that last call in this context does not mean that the HTML5 specification will be ready at 4:15am (in Buffalo, bars are open to about 4am, so last call is at about 4am). This is simply the last part of the first step of a four step process. The four steps:

1. Working Draft (WD): This is the first time a proposed specification is shown to the public and open for comment.
2. Candidate Recommendation (CR): Significant features are mostly locked and feedback is requested in how to implement the standard.
3. Proposed Recommendation (PR): The specification has been submitted to the W3C Advisory Council for approval. Changes at this point are rare.
4. W3C Recommendation (REC): The specification is final and endorsed by the W3C. This is what the general public considers a final standard.

To recap, we are approaching the end of the Working Draft step. This meets the timeline that the W3C laid out in the HTML Working Group Charter and a press release from mid-February (ok, Valentine's Day) of this year. The schedule that working group has been pushing all along puts the final release of HTML5 in the second quarter of 2014. The dates as laid out in the charter, as they correspond to each step in the process

1. Working Draft (WD): Last call: 2^nd Quarter 2011
2. Candidate Recommendation (CR): 2^nd Quarter 2012
3. Proposed Recommendation (PR): 1^st Quarter 2014
4. W3C Recommendation (REC): 2^nd Quarter 2014

If the HTML working group keeps making its deadlines, we are still three years out from a final standard (or set of standards, really). Given how complex these all are and how much debate is happening among them, it shouldn't be a surprise that it can take this long. For example, these two posts helped re-open the issue of alt attributes in HTML5: Image alt Attributes Not Always Required in HTML5, More on Image alt Requirement in HTML5.

If we're practical about all this, and I'd like to think we are, we are in the midst of a new set of browser skirmishes that have resulted in greater and greater support for many of the features to be included in HTML5 and its related specifications. Even if the semantic meaning of all the new elements can't be harnessed in CSS or even in search engine parsing, some of the more advanced features can be used in some of the more advanced browsers. These are all contributing to testing the specifications, something necessary for a specification to keep moving forward (indeed, test suites are a necessary part of the natural flow).

If you are interested in contributing to the specification, you have until August 3, 2011 to get your feedback to the working group. If you want more detail on what you can do or what is expected, go read the FAQ for HTML5 Last Call.

Now I'd like to put a little context in place here. Nearly a year ago I wrote about how CSS 2.1 was not yet a final specification (CSS 2.1 Still Not Final). CSS 2.1 was in the second step as a Candidate Recommendation. the CSS 2.0 specification was finalized in May 1998, but it's taken over 12 years to move the 2.1 revision along. That has not, however, stopped its real-world implementation by developers. It also helps that CSS 2.1 is just building on CSS 2, so it's not quite a fair analogue.

Related

• Last Call: W3C Invites Broad Review of HTML5 and Five Related Specifications
• HTML5 Spec Hits Last Call Status
• HTML5: Are We There Yet?

More on Image alt Requirement in HTML5

Nearly two weeks ago I wrote up a post outlining the W3C decision to no longer require the alt attribute on images in HTML5: Image alt Attributes Not Always Required in HTML5. I was genuinely surprised to see that was the most popular post on this blog and garnered the most re-tweets on Twitter I've ever had.

I pulled the alt decision off the W3C mailing list, before it was officially announced in any forum, so I suspected it might languish in obscurity for a while. I wasn't quite right. First, to recap the decision:

• The presence of aria-labelledby does not make missing alt conforming.
• The presence of role=presentation does not make missing alt conforming.
• The presence of <meta name=generator> makes missing alt conforming.
• Use of private communications does not, in itself, make missing alt conforming.
• The presence of title makes missing alt conforming.
• The presence of figcaption makes missing alt conforming.

Just over a week later, Steve Faulkner, member of W3C HTML Working Group along with other W3C working groups, provided a more in-depth and detailed overview, including a re-hash of the full decision in his post HTML5 Accessibility Chops: the alt decision.

On Friday, the HTML Accessibility Task Force mailing list took up the discussion of the alt attribute, starting in the email with the subject "[text] updated draft of clarification on alt validation." This message outlines the response to the alt decision, specifically targeting those issues with which the Accessibility Task Force has taken issue.

To distill the response on why the exception for the presence of <meta name=generator> should be re-examined (these are just the key points, descriptions of each are in the email):

• Evidence: deliberately omitting alt due to generator exception.
• Evidence: list of authoring tools (mis)using the meta generator.
• Evidence: lack of alt checking is harming:
  • A reintroduction of versioning.
  • Two tier document quality.
  • Generator is already in use for other purposes.
  • Drops all requirements on the floor.
  • Alternatives to the generator exception.

A distilled high-level list of why the presence of a title attribute obviates the need for an alt:

• Title has taken on the role of a visual element in the form of a tooltip and invisible when images are turned off, but alt is visible when images are turned off.
• Where images are disabled or inaccessible in current browsers such as smartphones saving bandwidth, title will be useless to users.
• Title text will now be generated on even decorative images, negatively impacting the user experience.
• A link to screenshots (IE8, Firefox, Chrome, Opera, Safari) is provided as an example of how a title and alt display when images are disabled.

Finally, on the decision that <figure> with an associated <figcaption> allows the exclusion of alt (also distilled):

• Given that <figcaption> lends itself to verbose text, this may be far more than is necessary for an end user, and removes the ability for the user to choose.
• Current use of <figcaption> tends to be for images users can see, whereas alt is for images users cannot see.
• Screen readers do not currently support <figcaption>, meaning it cannot effectively replace alt today.

Further discussion on this draft is scheduled for a meeting among the W3C HTML Accessibility Task Force today (May 2). In the meantime, feedback has been rolling in from other members on the list, some of them challenging the assertions made in the draft response. You can continue to follow the discussion by reading the thread in the April 2011 mail archive. Since May has just started and this thread crosses into May, you can catch up on the most recent discussion in the May 2011 mail archives.

Sadly, as evidenced by my posting silence for most of April, I won't be able to follow the results of a meeting today and will probably have to wait for the news like everyone else. If this topic interests you , then you may want to follow along on the W3C mailing list archives.

Image alt Attributes Not Always Required in HTML5

It has long been accepted that the alt attribute of the <img> element, while not a perfect method to provide a text alternative to an image, is still a necessary attribute to provide at least some level of access to the image content for users who cannot see the image (whether by disability or otherwise).

The alt attribute is required on images in HTML 4.01. The notion that the alt is a de facto required attribute in future versions of HTML is echoed in the WCAG version 1.0 and 2.0 (7.1 of WCAG 1.0, H67 and F38 of WCAG 2.0). It is even stated as much in the latest W3C HTML5 working draft document, HTML5: Techniques for providing useful text alternatives, as you can see in this sample conformance item:

When an image is decorative and it is the authors intent that it not convey any information, an empty alt attribute SHOULD be considered as an indication that the image can be safely ignored.

The W3C uses the strongest language in its arsenal when it says an alt should be used, even in this example of an empty attribute.

Yesterday the W3C mailing list rendered a decision on Issue-31 and Issue-80 (a combined issue). This issue was last reported by Ian Hickson of WHATWG on the W3C mailing list. Confusing though that may be, it's still a decision on the W3C list. The issue summary (not the decision):

Require that authors include alternative text for images. Provide detailed instructions and examples for doing so to all readers of the HTML specification.

The decision as outlined on the mailing list:

• The presence of aria-labelledby does not make missing alt conforming.
• The presence of role=presentation does not make missing alt conforming.
• The presence of <meta name=generator> makes missing alt conforming.
• Use of private communications does not, in itself, make missing alt conforming.
• The presence of title makes missing alt conforming.
• The presence of figcaption makes missing alt conforming.

Essentially, if you use a title attribute on your image, or wrap it in a <figure> with an associated <figcaption>, then you may exclude the alt attribute. In addition, the presence of a <meta name=generator> element, which implies the HTML was generated by some sort of WYSIWYG editor or automated tool, also makes the absence of an alt attribute valid.

There are arguments on both side of the issue, and the decision handed down on the mailing list does a good job of collecting them, even if the qualification of each may be cause for dissent. Given that the W3C is pushing HTML5 to Last Call status next month, it's unlikely this will change.

Warning: Opinion

An alt attribute is intended to describe the image to which it is affixed, but the (redundant) title attribute has been implemented by authors to provide more value to users owing to browsers typically rendering it as a tool-tip. While this doesn't preclude an author from inserting an alt as well, it also may result in use of solely the title when it may not offer a sufficient description of the image.

The argument for excluding alt in the presence of a <figure> and associated <figcaption> element applies best when the browser supports those elements. In time they will, but given the collection of users still on IE6, older assistive technologies, and the lack of understanding of these new elements, this leaves a gap for some users. This isn't a clean transition with a guarantee of the same level of accessibility as outlined in the current HTML 4.01 specification and accompanying WCAG versions.

I do not agree with letting an HTML page off the hook simply because it has been generated by an automatic tool of some sort (relying on the <meta name=generator> block of code). This is really included to allow generated HTML5 to validate, not because the tools are incapable of inserting a blank attribute value (though they may not have been coded to do so). The argument against this references the current lack of support for ATAG guidelines within HTML editors and generators. I think this caters to ego by allowing authors to claim validation that would otherwise fail.

In the end, I think the best approach (at least for web developers and authors) is to still require it in all cases, reducing the need for seasoned web developers to retrain themselves. Ideally, these web developers would still continue to include alt attributes in all cases. Developers of HTML editors/generators (who care about the output) will hopefully follow suit instead of inserting additional complexity at the risk of misunderstanding (and mis-coding) these new rules. Makers of HTML editors/generators that cannot implement the spec should not be given a free pass.

If you're really interested in <img> attributes on the chopping block, read up on the fun regarding longdesc at longdesc in HTML5.

Update: April 27, 2011

Steve Faulkner, member of W3C HTML Working Group along with other W3C working groups, provides a more in-depth and detailed overview, including a re-hash of the full decision in his post HTML5 Accessibility Chops: the alt decision.

Making and Using QR Codes (at evolt.org)

Having spent a good deal of time answering questions about QR codes lately, I figured the easiest thing to do for everyone was just write an article. And so I did. It went live very early this morning at evolt.org. Go check it out: Making and Using QR Codes.

If you aren't familiar with QR codes, they are those pixelated-looking collections of black and white squares that have been popping up more and more in recent weeks and months, even though they have existed for years. The QR (Quick Response) code was first developed in 1994 in Japan to track vehicle parts but has since grown to become a handy way to encode all sorts of data, most notably web site addresses for use in traditional media campaigns.

In the article I outline the general process of using QR codes in your own projects by providing suggestions on encoding web page addresses, how to build the QR code itself, and basic pre-press tips. I also push some other ideas, such as embedding on your printed web pages or embroidering into your headgear.

So again, go read Making and Using QR Codes at evolt.org and consider my year-old QR code primer, Real World Hyperlinks.

Color Has a Gray Pallor

Color is the newest social media application on the block, launched just after SxSW and relying on proximity-based media sharing instead of a friend model. Founded by names from other successful ventures along with $41 million in funding, Color seemed poised to storm the social media market.

One day after its launch, Color Labs, Inc. released an update to the Color app. Originally launched to support a 100 foot radius to find people for sharing, its new update was released to adjust that radius on the fly based on nearby activity. Considering the app is essentially useless without others who participate, this update is necessary to gain users (and necessary given it missed a great geek-dense SxSW event). When you read the opening statement in the product description in the Apple App Store and Android Marketplace, you can see that this need for others using the app nearby isn't exactly a surprise for Color:

WARNING: DON'T USE COLOR ALONE.

With so little activity visible to a user, users might look to the interface to provide some clues to using the app. After all, knowing if you are even using it correctly can manage your expectations one way or the other. Once installed, the app immediately asks for your first name, then prompts you for a photo of yourself, and then drops you right into its interface with some inexplicable icons (notwithstanding the tiny "Next" text-link-like buttons that move you along in the process). With no activity, it's hard to know what those icons do. This company-provided screen shot shows the app with its confounding icons in an ideally-active stream of content:

You might be motivated to look for a help screen in the application, but you'll have no luck. You might even be motivated to go to the Color web site to look for a tutorial or some form of documentation, but no luck. It turns out that there is a demo video available on Vimeo, but Color doesn't even link it from the site — you have to find it somewhere in the copious industry press coverage, which is something the typical user won't be doing.

When the Color Labs CEO says that the company is much more of a research company and a data mining company than a photo sharing site, it seems fair to question if the technology led the product rather than a tangible business model taking the lead. Given Color's reception so far, that seems like it may very well be the case.

In the Apple App Store product page for Color, the highest rated review of the product is really a parody, comparing it to a puzzle game (images of the full description):

You conquered Myst. You understood the end of Lost. You can do this! You're not going to let this new adventure game genre get the best of you! You will master this if it takes all weekend. You discover a button to create a group! You wonder what a group is. Progress, of sorts.

Given how easy it is to spoof GPS locations on a phone, even though the Color Labs CEO says that Color doesn't rely on GPS, it's a matter of time before a method to spoof locations is widespread. Let's not forget that Color is essentially anonymous, too, requiring no validation beyond location. It won't be long before you can expect to see Color turn into nothing more than a spam outlet or Chatroulette variant. I can assure you, I would not be letting my children (non-existent though they may be) install this app on their phones.

Related

• Color's Ambitious Photo App Seeks to Reinvent Mobile Social Networking
• Color CEO: The Tech Justifies the $41 Million
• Color to Get Major Update, Fix 'Loneliness' Problem
• PR Case Study: Where Color Went Wrong
• Color: Is it just the latest useless social media app?
• GPS check-ins taking off