click to enlarge

I wrote a quick post to Google Buzz recently that dealt with a concept and issue that’s been rattling in the back of my mind lately. We consume so much information from so many sources that we’re bound to run into the same stories. The news that becomes popular does so because of it being shared, telling friends, sending it to others, and spreading the word.

Virality is the term that’s been associated with this for some time. Getting things to “go viral” is a key to success, but the value of any story is its exclusivity, or who publishes it first. The above concept image is a visualization of my thoughts on how this issue might be dealt with.

I call it – Flume.

1. flume – noun. - A narrow gorge, usually with a stream flowing through it.

The goal is to group all similar information from throughout the web, from social networks and from all of your friends, and distill it to just the original sources.

You’d have a list of news stories that are by default presented by popularity. Each story would get a score that represents how often it’s cited across the web – based on tweets and retweets from Twitter, inbound links from reactionary blog posts, and personal status update reactions from friends and colleagues on social networks like Facebook and Google Buzz. The presentation would be consistent regardless of the source, with simple links to click and visit any story in detail. You’d have at-a-glance, with no interaction needed from the user, an importance-ranked delivery of information stemming from the people and content sources they value most.

Behind the scenes, the application would detect when a story all points to the same common news event, and instead of you having to look elsewhere through your various feeds, walls, streams, etc., the story would show up only as a single source origin story – all within the confines of one application.

For example, if CNN gets the story first, that’s the one that would show up in Flume. All other stories that were posted anywhere on the web afterwards would be consolidated underneath it. Anyone posting about it on Twitter – hidden. Anything on Facebook about it – not seen. All of the reactions would fall in a toggleable area below each story, where if you desired to drill down into to see what people are saying, you’d know from where it came from and where it was being talked about. But only if you want to.

So how would it work?

You’d use a combination of keyword density, trackback links, un-shortened URL detection, and possibly the Salmon protocol to algorithmically distinguish the content streaming in as either original or reactionary. As more content arrives, whichever source has the content origin first gets the credit. So if your friend on Twitter was the first to post about a story before it arrived to you via someone else on Facebook, you’d only see the tweet. If the blog post came before the Buzz, you’d get the blog post alone.

The mockup design is obviously heavily influenced by TweetDeck. Where the multicolumn view works in TweetDeck’s favor, I’d like to take all the separated information and throw out anything other than the first place something appeared. Rather than having separate columns for each service, I’d want a single column for all news, regardless of source. If you wanted to of course, you could always re-sort it by source if you desired.

It’s a bit like Google Buzz or FriendFeed, where you have a single aggregated stream of information, but instead of being source-centric, the default is popularity centric. It’s throwing TweetDeck, Google Buzz, FriendFeed, Facebook, Brizzly, Redux, Amplify, Google Reader, and countless other web tools into a blender to create an ultimate single point-of-entry news reading mechanism.

HTML5 and web application standards would be ideal for the client to allow for both desktop and cross-platform mobile usage, while a robust database application layer in the cloud would be constantly evaluating and delivering the ranked information requested by the client.

What do you think? Would a single view of content without the same stories popping up over and over interest you? What other features would you expect to see in this application? What are some of the limitations that would prevent an application like this from existing, and how might they be overcome?

Since FriendFeed’s launch of a new still-in-beta redesign, there’s been much debate over some of the features and style changes – both on blogs, and within the service itself. While any change is sometimes met with reluctance and skepticism, as Facebook has realized with their latest changes, there’s a number of reasons why the aesthetic and functional revamps of FriendFeed are helpful for both its users, and for the proliferation of real-time data on the web. Here’s a breakdown of why I believe FriendFeed has made a lot of correct choices in their transition from data aggregation, to a broad conversational hub for the web.

1. Perceptual Familiarity

Since FriendFeed has a complex amount of data to display, attraction of users unfamiliar to the service proves to be difficult for many casual web users. One of the primary reasons other social networks such as Twitter or Facebook have garnered buzz and widespread adoption are because of their ease of entry, and narrower focus.

What makes Twitter and Facebook‘s interfaces work – showcasing the people that we connect with through the use of avatars – are how we’re used to seeing content displayed. The new inline visual cue from the content’s creator, via an avatar image, goes a long way to breed familiarity and a sense of “I understand this already” for new users. Along with simpler things – rounded edges to the interface, even column distribution between navigation and content – all create a sense of uniformity with services elsewhere – which allows users to spend more time communicating and sharing and less time trying to understand the mechanics to do it.

2. Real-Time

The ability to have instant discussion about topics across the web is becoming increasingly important to stay relevant in the ever-increasing pace of the flow of news. FriendFeed’s decision to make real-time the standard has propelled the discussion of stories to be faster than even Twitter can react. With a broader userbase, story reaction through immediate discussion on FriendFeed could allow them to become the main source of the absolute earliest debate and dissection of content funneling from the web.

3. Simplification

The removal of service icons (the graphical representations of the content’s source) in the new FriendFeed helps to eliminate distraction from viewing the content itself. Ultimately, if you see a picture from your friend, does it matter whether it came from Flickr, Smugmug, or Picasa? Why should it?

Eliminating the distinction between Groups & Feeds also aids the initial comprehension of content management that sometimes confuses users at first. While I do think there’s still considerable room for further term elimination (groups, feeds, filters, friends, subscriptions – there’s just too many), the infrastructure is arriving at a simpler solution to visualize a myriad collection of content.

4. Advanced Search

The new “Filters” of FriendFeed offer a way to save complex searches, which allows for a level of data mining never before available. The following of trends, brands, story topics, and people has never been simpler – or with as much variable control. The simple, but powerful, form-based searches in the new FriendFeed often make for an even more accurate result than even Google or Yahoo can deliver.

5. Communication

While direct messaging has been a staple of other services, FriendFeed’s new implementation takes the concept even farther by allowing for simultaneous broadcast and private messaging. Being able to send content to individuals, or groups of friends on the new FriendFeed, now effectively creates an instant, private, and real-time discussion thread. This is an unprecedented level of immediate discussion. Within seconds, users can be debating the river of information as it flows from the many sources worldwide – in a centralized location. Where reading RSS feeds, or content on blogs or other websites fail to offer the ability to announce a timely, reactive viewpoint, FriendFeed delivers the most spirited, instant reaction on the web – without reloads, comment verifications, captchas, and all of the other barriers that other sites present.

Among all of the advancements, there are still more elements of FriendFeed that require sharpening and refinement, such as:

• better user management that allows for sorting your friends by level of engagement
• clearer and immediate notification of direct replies within comment threads
• and naming systems that are intuitive, and accurate for the various views that FriendFeed offers (“My discussions” for example should not include posts that I’ve never commented on)

Since the site is still being actively refined during the beta process, now is the time to make your voice known of the things you want that aren’t yet present, and the things that are being done right. With an increase in user participation, the developers of FriendFeed have an opportunity to create the largest vehicle of content discussion and dissemination in the world.

I recently started a Twitter discussion with Chris Coyier of CSS-Tricks on the relevance and usefulness of the <small> tag. I’ve had this same debate with co-workers on why one would still use <small> over just using a <p> or <span> with an appropriate <class> or <id> to define the “smallness” of the tag. The one thing we both noticed is that no one uses the <big> tag anymore, so why should anyone use the <small> tag? This seems to be only the tip of the iceberg when it comes to determining which element to use for an intended result. Let’s look at a few more instances of controversy in the realm of standards and semantics on the web.

Strong or Bold? How Do You Like Your Emphasis?

Another debate is why we now use <strong> and <em> for bold and italics over just using <b> and <i>. Is there a true reason for why we as web designers have made this transition? None of these tags are deprecated (according to the W3C), so why have these presentational tags gone by the wayside?

I suppose it becomes a matter of semantics, which leads to the current buzz term in web design – the semantic web. The W3C does state that even though these tags are not deprecated, their use is discouraged in favor of style sheets. My good friend, Eric Filson, takes this approach and never uses any presentational markup for text (no <strong>, <em>, <b>, or <i> ) but rather wraps the element in a <span> and applies the appropriate CSS (such as font-weight: bold or font-style: italic) instead.

An old forum thread on Webmaster World dives into this struggle with some helpful clarification:

When setting a bold or italic font for purposes of typography only, use <b> and <i>. If there’s a word or phrase that you want to emphasize as you would while speaking, then – and only then – use <strong> or <em>.

I’m fairly certain however that many designers don’t take this approach. When you look at industry standard editors like Dreamweaver or Expression Web, there are exclusive selectable options defaulted to “use <strong> and <em> instead of <b> and <i>” – so there’s an obvious push from the top down as well to essentially deprecate those tags for designers to begin with.

When an <address> Isn’t an Address

Microformats adopters have given some focused attention to the rarely used <address> tag lately since the markup of adr relies heavily on adding address information to a page. One would assume that using the one tag in the HTML spec that seems perfect, <address>, seems obvious. In fact, <address> is almost never the right choice. The adr-examples wiki sets the story straight:

The <address> element is typically very confusing for web authors and is best avoided.

The <address> element does NOT mean what you might think it means (unless you are one of the few folks who has thoroughly read the HTML 4.01 recommendation.

The <address> element does NOT mean “address”.

The hcard-faq also goes into further explanation to say:

The poorly named <address> element really means <contact-info-for-this-web-page>. The HTML4 definition of the ADDRESS element says it is used “to supply contact information for a document or a major part of a document such as a form.” Therefore, <address> should be used ONLY IF it represents the contact information for the page or major part thereof. In short, DO NOT use <address> to markup physical/street/mailing addresses. Only use it to markup the contact information for the page.

So the moral of the story here is apparently we shouldn’t be using <address> anymore because it’s just too confusing. But if you’re going to use it, it’s basically achieving the same thing <meta name="author"> is for, but in a block of text somewhere within the body of your page. What a piece of junk <address> turned out to be!

The Future Of The Web

So with all of that said – what do your markups look like? Will you roll along with whatever works for you, or will you jump through hoops to markup your code semantically and get on the “Web 3.0” bandwagon? Are your sites going to be ready for the bleeding edge of microformats, RDF, OWL, SWRL, SPARQL, GRDDL and WPT? Will any of this matter to paying clients? (strong emphasis!)

Come to think of it – maybe I should have used <acronym> on all of those…

Ever wished you had one place to test your web designs in all browsers easily? Well thanks to IETester, it’s now possible to check your work in IE 6, IE 7, IE 8 Beta (and even IE 5.5 for anyone still living in the year 2000). It’s still in alpha, so it has occasional crashes, hiccups, and limited browsing functions. In spite of this, the app in its current release is already incredibly useful. The developer has a forum set up for feedback and bug reporting as well which should hopefully keep the project moving forward.

With IETester combined with VMWare Fusion, I can now test my work on my Intel Mac in Internet Explorer, Safari, and Firefox without having to resort to remoting to other machines, using slower web-based visual checks, or using Virtual PC to test multiple IE versions anymore. It’s a fantastic setup.

Now if only there were conditional comments, and a version of Firebug for IE and Safari… Hey, a web designer can dream, right?

UPDATE: Apparently since I have an old Blogger template I am unable to add the labels list to my sidebar. Rats!

My solution is this:

What about putting a sequence of UP, LEFT, RIGHT, and DOWN arrows over a grid pattern. Then the user would just push the arrow keys in the sequence shown. All of the angles would be impossible for a computer to decipher what combination would work – but a human could distinguish the arrows and press accordingly.

It would be like entering the Contra code as a captcha.

This would also work on keyboards worldwide, as non-western keyboards might have characters outside of the English alphabet – but all keyboards have arrow keys (as far as I’m aware).

This doesn’t solve the issue of accessibility for the blind however that all captcha’s suffer from. The best solution I’ve found is an audio file that reads off what’s visually shown. This presents another issue – what language would it be read in? What if you are blind and deaf? What if you have no keyboard? At what point do you stop?

A truly worldwide, accessible captcha – Is it possible?

Poetic Rage Clothing, Co.

Alternately, you would have to point those users (XP, Mac, Linux) to a special download of an altered or limited version of Avalon made for those platforms. It seems that downloading something with that large of a graphic framework would not be as simple as a Flash Player download.

You would download probably a 60MB+ file (just a guess) and then after install have to reboot before you can view the content. That’s a journey that nearly any non-computer savvy customer will not be willing to take. And most companies, large or small, would be hesitant to help them through.

Right now we can do a LOT with the Flash Player using the tools Macromedia provides, and a new install takes seconds, and without a reboot if users don’t happen to have it. In my mind, Sparkle’s features will be the best thing ever to hit application development for Windows Vista and future platforms. But for the web, Sparkle has a lot of limitations compared to Flash’s cross-platform ubiquity.

What it’s doing is it’s taking my last played song’s Album Title and Artist Name (thanks to Audioscrobbler/last.fm) and sending it along to Amazon as a keyword search. Amazon then gives back an XML file with the results, and then my Flash app parses the XML and finds the node with the CD cover that matches the keyword’s search results. So if you look over there in the sidebar, you’ll see that the cover appears as it would show on Amazon. Pretty neat huh?

And here’s the code, if any Flash junkies want to see what I was working on. If you have any questions about it, email me or hit me up on IM. I still have to add something if there is no image available, and maybe try another service (Google, AllMusic) if Amazon comes up short.

// Allow this Flash app to show the loaded images consistently from the remote server, images.amazon.comSystem.security.allowDomain("http://images.amazon.com");////var audioscrobblerURL = "http://ws.audioscrobbler.com/rdf/history/[YOURPROFILENAMEHERE]";var audioscrobblerReply_xml:XML = new XML();audioscrobblerReply_xml.ignoreWhite = true;audioscrobblerReply_xml.onLoad = function(success) { if (success) {  //  trace(audioscrobblerReply_xml);  processAudioScrobblerXML(audioscrobblerReply_xml); } else {  trace("error loading"); }};audioscrobblerReply_xml.load(audioscrobblerURL);function processAudioScrobblerXML(audioscrobbler_xml) { audioscrobblerArtistTitle = audioscrobbler_xml.firstChild.firstChild.nextSibling.firstChild.nextSibling.nextSibling.nextSibling.nextSibling.nextSibling.firstChild.firstChild.firstChild; trace(audioscrobblerArtistTitle); audioscrobblerAlbumTitle = audioscrobbler_xml.firstChild.firstChild.nextSibling.firstChild.nextSibling.nextSibling.nextSibling.nextSibling.nextSibling.nextSibling.firstChild.firstChild.firstChild; trace(audioscrobblerAlbumTitle); // set the standard Amazon URL var amazonURL = "http://webservices.amazon.com/onca/xml?Service=AWSECommerceService&SubscriptionId=[YOURDEVIDHERE]&Operation=ItemSearch&Keywords="; var urlEnd = "&SearchIndex=Music&ResponseGroup=Images"; var keyword = audioscrobblerAlbumTitle+" "+audioscrobblerArtistTitle; // create new XML var amazonReply_xml:XML = new XML(); // ignore the whitespace amazonReply_xml.ignoreWhite = true; // trace the returned XML and process it amazonReply_xml.onLoad = function(success) {  // trace(amazonReply_xml);  if (success) {   processXML(amazonReply_xml);  }  error = "error loading"; }; // send off the URL to pull back the new XML data from Amazon (note variable "keyword" comes from textfield on stage) amazonReply_xml.load(amazonURL+keyword+urlEnd); // create the function of processing the returned XML function processXML(amazon_xml) {  // amazon_xml is now a reference to the XML  // object where information is stored  // trace(amazon_xml.firstChild.firstChild.nextSibling.firstChild.nextSibling.nextSibling.nextSibling.firstChild.nextSibling.nextSibling.nextSibling.firstChild.firstChild);  albumCoverURL = amazon_xml.firstChild.firstChild.nextSibling.firstChild.nextSibling.nextSibling.nextSibling.firstChild.nextSibling.nextSibling.firstChild.firstChild;  //load CD Cover image into movieclip on stage  imageHolder.loadMovie(albumCoverURL); }}