Member Sign In
Not a member?

A Wired.com user account lets you create, edit and comment on Webmonkey articles. You will also be able to contribute to the Wired How-To Wiki and comment on news stories at Wired.com.


It's fast and free.

Sign in with OpenID
Sign In
Webmonkey is a property of Wired Digital.
processing...
Join Webmonkey
Please send me occasional e-mail updates about new features and special offers from Wired/Webmonkey.
Yes No
Please send occasional e-mail offers from Wired/Webmonkey affiliated web sites and publications, and carefully selected companies.
Yes No
I understand and agree that registration on or use of this site constitutes agreement to Webmonkey's User Agreement and Privacy Policy.
Webmonkey is a property of Wired Digital.
processing...

Retrieve Sign In

Please enter your e-mail address or username below. Your username and password will be sent to the e-mail address you provided us.

or
Webmonkey is a property of Wired Digital.
processing...

Welcome to Webmonkey

A private profile page has been created for you.
As a member of Webmonkey, you can now:
  • edit articles
  • add to the code library
  • design and write a tutorial
  • comment on any Webmonkey article
Close
Webmonkey is a property of Wired Digital.

Sign In Information Sent

An e-mail has been sent to the e-mail address registered in this account.
If you cannot find it in your in-box, please check your bulk or junk folders.
Sign In
Webmonkey is a property of Wired Digital.

W3C Drops Audio and Video Codec Requirements From HTML 5

By Michael Calore June 30th, 2009 Categories: Multimedia, Web Basics

The stewards of the web have removed the sections of the HTML 5 draft specification that would recommend web browsers support audio and video playback using a specific codec.

Ian Hickson, one of the primary authors of the HTML 5 draft at the Worldwide Web Consortium, made the announcement on the WHATWG mailing list Tuesday after fielding hundreds of e-mails’ worth of community comments over the past year and a half. Hickson cites the inability to reach a consensus on which codec should be implemented across all browsers as the primary reason for the decision.

The setback is sure to put a freeze on the main promise of open video and audio support in HTML 5 — the broad implementation of a single, plug-in free media playback environment in the next generation of web browsers, enabling people to watch movies and listen to songs inside the browser without having to download any additional software.

Hickson’s post, in part:

After an inordinate amount of discussions, both in public and privately, on the situation regarding codecs for <video> and <audio> in HTML 5, I have reluctantly come to the conclusion that there is no suitable codec that all vendors are willing to implement and ship.

I have therefore removed the two subsections in the HTML 5 spec in which codecs would have been required, and have instead left the matter undefined, as has in the past been done with other features like <img> and image formats, <embed> and plugin APIs, or Web fonts and font formats.

The current situation is as follows:

  • Apple refuses to implement Ogg Theora in Quicktime by default (as used by Safari), citing lack of hardware support and an uncertain patent landscape.
  • Google has implemented H.264 and Ogg Theora in Chrome, but cannot provide the H.264 codec license to third-party distributors of Chromium, and have indicated a belief that Ogg Theora’s quality-per-bit is not yet suitable for the volume handled by YouTube.
  • Opera refuses to implement H.264, citing the obscene cost of the relevant patent licenses.
  • Mozilla refuses to implement H.264, as they would not be able to obtain a license that covers their downstream distributors.
  • Microsoft has not commented on their intent to support <video> at all.

(Sorry if I’ve mischaracterised any positions above; the positions are relatively subtle and so it’s likely that I have oversimplified matters.)

I considered requiring Ogg Theora support in the spec, since we do have three implementations that are willing to implement it, but it wouldn’t help get us true interoperability, since the people who are willing to implement it are willing to do so regardless of the spec, and the people who aren’t are not going to be swayed by what the spec says.

Things are stuck in a stalemate, and, since the web’s main governing body is choosing to play it neutral and not push any vendors into support for one codec over the other, it’s unlikely there will be a quick resolution.

Others inside and outside the WHATWG have begun voicing their opinions.

Silvia Pfeiffer, an W3C invited expert and a member of Xiph.org, the non-profit group that oversees development of the Ogg media container, takes issue with Hickson’s last point, arguing that a strict requirement is a good thing:

Inclusion of a required baseline codec into a standard speaks more loudly than you may think. It provides confidence — confidence that an informed choice has been made as to the best solution in a given situation. Confidence to web developers, confidence to hosting providers, confidence also (but less so, since they are gatekeepers in this situation) to browser vendors.

In my opinion, including a baseline codec requirement into a W3C specification that is not supported by all Browser Vendors is much preferable over an unclear situation, where people are forced to gather their own information about a given situation and make a decision on what to choose based on potentially very egoistic and single-sided reasons/recommendations.

In fact, it is a tradition of HTML to have specifications that are only supported by a limited set of Browser Vendors and only over time increasingly supported by all — e.g. how long did it take for all browser vendors to accept CSS2, and many of the smaller features of HTML4 such as fixed positioning…

Sam Kuper, an open standards advocate and another W3C invited expert, backs up her argument:

Waiting for all vendors to support the specified codec would be like waiting for them all to be Acid3 compliant. Better to specify how browsers should behave (especially if it’s how most of them will behave), and let the stragglers pick up the slack in their own time under consumer pressure.

David Singer, a QuickTime engineer and Apple employee, also voiced his opinion, speaking on behalf of his team at Apple:

I just wanted to say that we’re not happy with the situation. We continue to monitor it, to take what action we can, and we continue to hope that we will, at some time, find a solution that reaches consensus.

It’s ironic that the announcement comes the same day as the release of the new version of Firefox, the second-most popular browser (behind Internet Explorer) which now ships with full native support for media playback using the Ogg Theora and Ogg Vorbis codecs.

As for the future of video codecs on the web, Hickson sees a few possible outcomes, “all of which will take several years”:

1. Ogg Theora encoders continue to improve. Off-the-shelf hardware Ogg Theora decoder chips become available. Google ships support for the codec for long enough without getting sued that Apple’s concern regarding submarine patents is reduced. => Theora becomes the de facto codec for the Web.

2. The remaining H.264 baseline patents owned by companies who are not willing to license them royalty-free expire, leading to H.264 support being available without license fees. => H.264 becomes the de facto codec for the Web.

When either of these happen, I will reconsider updating HTML5 accordingly.

Of course, the debate runs much deeper than what I’ve cited here. Follow along by reading the mailing list archives, which are available to the public.

See Also:


Post Comment | Comments | Permalink

Taking Microsoft to Task Over IE8 ‘Myths’

By Michael Calore June 19th, 2009 Categories: Software & Tools, Web Basics

Microsoft recently launched a campaign promoting its Internet Explorer 8 browser, making some bold claims about IE8’s capabilities.

The campaign, called “Windows Internet Explorer 8: Get the Facts,” trumpets IE’s speed, stability, ease of use, safety and customizability. It also provides a chart and several data points intended to show how IE8 surpasses other browsers in these areas.

While IE8, which was released earlier this year, is certainly the best version of Internet Explorer yet, several of Microsoft’s claims lead us to more questions, overlook some obviously plain facts or simply leave us scratching our heads.

On the campaign website, you’ll see Microsoft listing eight reasons to install Internet Explorer 8 — it’s “faster than ever,” it’s more customizable, it recovers from crashes — all of which point out the enhancements over previous versions of IE. No harm there.

But in the next section, titled “Browser comparison,” things gets dodgy.

Here, Microsoft claims IE8 has better protection against malware and phishing scams than Firefox and Chrome, as well as better privacy features. The privacy and security claims are dubious, especially considering Firefox 3 has some equally robust privacy features. Chrome also has almost identical features, as well as an incognito mode that mirrors IE8’s InPrivate browsing mode.

More troubling are the claims that IE8 is on par with Firefox and Chrome when it comes to support for web standards and performance.

The fact that both Firefox 3 and Google Chrome are both leaps and bounds ahead of IE8 when it comes to support for both established and emerging web standards, like HTML 5 and CSS 3, is no mystery to anyone who’s developed websites using anything beyond CSS 2.1, the latest CSS standard Microsoft IE8 supports, or to those developing user experiences with open video players or offline data storage features. Furthermore, for users of Ajax-heavy websites like Gmail and Netflix, IE8 performs just fine, but it’s not nearly as fast as Google Chrome.

And how about Safari and Opera? How do they compare? A casual reader wouldn’t know, since Microsoft didn’t include them in this chart.

On to the third section — deliciously titled “Mythbusting.” It’s here that Microsoft calls out the competitors on four common arguments against IE8.

The four “myths”:

  • 1: Internet Explorer is much slower than Firefox and Chrome.
  • 2: Internet Explorer is less secure than Firefox.
  • 3: Firefox is a richer, more adaptable browser than Internet Explorer.
  • 4: Internet Explorer doesn’t play well with Web standards.

The site goes on to attempt to de-bunk these myths one by one, with varying levels of head-spinning pretzel logic.

On the speed issue, Microsoft says its navigation features make it easier to use, therefore making it faster to find what you’re looking for. This isn’t speed, this is spin. It then dismisses page rendering and JavaScript performance data supplied by Firefox and Chrome as “micro-benchmarking page load claims” that don’t extend to real-world use cases. Again, nobody who’s serious about measuring browser speed accurately is going to buy this. And where are Safari and Opera? Not mentioned here.

On security, Microsoft says IE8 is more secure than IE6 or IE7, which is true. But to back up its claim that IE8 is the most secure browser, Microsoft cites a self-sponsored study that Opera has since called out as manipulative and incorrect. The rest of the arguments supplied here — more advanced phishing and malware protection, better defense against cross-site scripting, better security out of the box — fall flat when you look at similar features in Firefox and Chrome.

It’s the last two that are the biggest head-scratchers.

IE8 is more adaptable than Firefox and Chrome, both of which are fully open-source? More customizable than Firefox, which has the richest, most vibrant add-on community among all the browsers, including the Two Browsers Not Appearing In This Comparison?

And IE8 plays well with web standards? Again, it’s a huge improvement over older versions of IE, but IE8 surpassing all other browsers, including the Two Browsers Not Appearing In This Comparison? Au contraire.

Additonal reading: Geek Technica’s breakdown, which goes into more technical detail that I’ve provided here.

Screenshot (with commentary) by robceemoz/Flickr

See Also:


Post Comment | Comments | Permalink

Typekit Hopes to Become the YouTube of Fonts

By Scott Gilbertson May 29th, 2009 Categories: Software & Tools, Visual Design, Web Basics

A new startup is hoping to solve the web’s font problem.

Designers have been bemoaning the state of typography in the browser since the dawn of the web. The current technology for rendering type in the browser without using Flash or other non-standards-based methods essentially limits designers to only six fonts.Of course, we already have some ways around those limits, like sIFR and Cufón, two projects that use Flash and JavaScript, respectively, to embed fonts on web pages from the server side. However, there’s long been a better way to embed fonts waiting in the wings: using CSS.

The W3C @font-face declaration for CSS has been around for some time, but has languished due to two big problems. First, most browsers didn’t support it. But with the latest versions of Safari, Firefox, Opera and Google Chrome all now supporting @font-face, that problem is close to being solved.

It’s the second major problem that’s the sticking point: licensing restrictions forbid embedding fonts via CSS. Unfortunately, the font foundries which create, sell and license fonts have thus far been reluctant to embrace licensing terms that would allow designers to serve fonts legally. The foundries fear that users would be able to pirate the fonts much more easily if the files were published in the wild on the web.

It’s this problem that Typekit, an as-yet-unlaunched web service, is trying to solve. Typekit is the brainchild of Jeffrey Veen, a noted web designer (and former Wired.com engineer and contributor to Webmonkey) who is hoping that Typekit can strike a deal with the font foundries and provide licenses that will allow designers can use them on the web.

Although Typekit’s official announcement is thin on details, it looks as though the company will host the font files, which designers can then license for a fee. From there, the fonts could simply be embedded using the @font-face declaration in a site’s stylesheets.

Sounds prefect right? Well, maybe. There are some possible problems with Typekit’s scenario.

First, there’s the issue of potential downtime. If Typekit’s servers choke (and even Amazon’s S3 service goes down from time to time, so don’t expect Typekit to be any different) all your fancy fonts vanish. Depending on how complex your design is, an outage could turn your site into a garbled disaster.

The other possible problem is that Typekit will require adding “a line of JavaScript to your markup.” Hopefully what that means is that you’ll need to embed a license checking script. But the announcement isn’t clear about this, and some commenters seem to think it means Typekit is planning to use a font replacement system along the lines of Cufón.

Update: According to Typekit’s Jeffrey Veen, the commenters have it wrong.

“Typekit isn’t using any sort of image replacement for rendering fonts on web pages,” Veen tells Webmonkey. “We’re using the CSS @font-face declaration to link to TrueType and OpenType files. We’re using JavaScript to simplify that process and account for various browser versions.”

Ah, yes, various browser versions. At the back of everyone’s mind is the problem of Internet Explorer — Even the brand new IE8 still does not support the @font-face rule. However, after watching the developments come out of Google’s I/O conference it seems pretty clear that the web is moving forward with or (more likely) without IE.In the meantime, Veen says Typekit is taking special considerations to deal with Internet Explorer.

But over time, using Internet Explorer will result in a second tier web experience, since the browser remains without HTML5 and CSS 3 support. Users will start asking why, and one of two things will happen: either users switch to a different browser or Microsoft adds the missing features. Either way, the web wins.

Assuming @font-face support becomes ubiquitous across all browsers at some point, font foundries and Typekit may well find themselves in the same position that the music and film industries are today — fonts will be embedded using @font-face directly, regardless of copyright laws.

Despite the potential problems and complexities, we welcome the impending arrival of Typekit. If it can work around these outstanding issues, it has a good chance of succeeding. If you’d like to be notified when the service is available, head over to the sign up page and add the blog feed to your RSS reader.

See Also:


Post Comment | Comments | Permalink

Google’s New Design Helps Eliminate OpenID Confusion

By Scott Gilbertson May 15th, 2009 Categories: Visual Design, Web Basics

Google has announced two important changes to its OpenID API. The first is new a popup window interface with fewer redirects and a much streamlined experience for users. The second change is that sites now have access to more data like your first and last name, preferred language, country, and more (assuming you allow the site in question to access that data).

It’s no secret that OpenID is confusing for many users. Because OpenID isn’t owned by any one company, websites supporting OpenID can implement it in very different ways, and often the OpenID experience lacks the simplicity and UI polish of alternatives like Facebook Connect.

Google’s revamped interface and workflow are designed to address common problems with OpenID and make the user experience easier.

As OpenID advocate David Recordon writes on the OpenID blog, the new streamlined interface means that users signing into sites “now have a much better user experience, one on par with Facebook Connect.”

Google’s redesigned OpenID interface and workflow isn’t just something the company worked out on its own, it’s actually part of the OpenID User Interface Extension Specification, which is an attempt to standardize and refine the OpenID user experience.

The good news for users is that the recommendations in the UI Spec are catching on with OpenID providers — JanRain, another OpenID provider has also announced a similar overhaul for its OpenID interface and API.

Of course, while it may seem obvious to those who use it, the new Google OpenID interface does not replace to older method and converting a site use the new interface is left up to the site’s developers. If you’d like to see an example of the new interface, head over to UserVoice, which has already integrated the new system.

While it’s nice to see UserVoice jumping on the new interface and making the experience a little smoother, if you click through to the site you’ll see another problem with web identity — there’s seven ways to login to the site.

While we like choice when it comes to using the web, at some point choice overwhelms users — what do you do if, like us, you have a Facebook account, a Twitter account, an OpenID identity and a Yahoo identity? Which one do you choose?

Quite frankly, it’s a mess. And the problem isn’t unique to UserVoice, even logging in to leave a comment on a blog is becoming a study in the who’s who of web identity providers.

The original idea was that there would be a single identity — your OpenID. But of course that’s not how it worked out. Just about every site on the web wants to be your identity provider and figuring out which one you should choose is hard for less web-savvy users.

If the history of the web is any indicator, eventually one of these identity providers will end up the de facto choice for most users. But in the mean time, while OpenID is improving, the larger problem of where to host your identity remains.

See Also:


Post Comment | Comments | Permalink

When it Comes to Friends, Flickr’s Had it Right All Along

By Scott Gilbertson May 12th, 2009 Categories: Software & Tools, Web Basics

Relationships on the web are, to borrow a bit of Facebook parlance, “complicated.”

Some social networking sites (like Facebook) require relationships to be reciprocal — you must approve people before they can be friends with you and see what you’re up to. This model is often referred to as a symmetrical relationship.

The concept of “friends” in Facebook’s parlance seems on the surface like a reasonably accurate model of real-world human interactions — we share things with our friends, not strangers. But that model ignores the people at the fringes of conversations; friends of friends and extended networks that go beyond our close friends, but still contribute to the conversation.

Consider, for example, a dinner party at a friend’s house. You know four people there, but there are four more you’ve never met before. In the midst of conversation, you probably won’t stop one of the people you don’t know and ask them to be your friend before they continue. No, you simply follow the conversation.

Recognizing this limitation, sites like Twitter use the concept of “following” another person, which need not be reciprocal at all.

In fact, the asymmetrical relationships on Twitter are arguably a big part of its success — you can have thousands of followers, but there’s no need for you to follow them all back. That gives you the freedom to pick and choose what conversations you want to participate in, rather than being forced into conversations via the “friendship” model (This fact still stands even after Tuesday’s much-derided settings change).

Tim O’Reilly laments the disadvantages of symmetric, “friend”-based social networks, arguing that for users, the concept simply doesn’t scale. “I can’t even keep up regularly with the 500+ people I do follow on Twitter,” writes O’Reilly, “keeping up with the 400,000 who follow me would be impossible.”

O’Reilly argues that developers working on social sites ought to adopt the Twitter model rather than a Facebook model.

We agree that would move things in the right direction, but we’ve long wondered why more sites don’t copy the social network that’s always had the most nuanced way to define your relationships — Flickr.com.

All of Flickr’s available relationships — contacts (like followers on Twitter), friends and family — are asymmetrical. What’s more, they can be used to define different levels of privacy. For example, it’s easy to upload photos and set their privacy levels to “friends and family” or just “family.”

In addition, to offer a more flexible way to define your relationships on the site, Flickr uses the nature of the relationship to offer a much more flexible privacy system. You can limit content to only approved groups or you can offer it up to the world. In short, Flickr offers the best of Twitter and Facebook and does it on a per-post basis.

Facebook, which prides itself as the private social network, lacks a similar flexibility. Because it locks you into reciprocal relationships, if you try to expand beyond your circle of closest friends, the data stream eventually becomes overwhelmed by noise.

Which isn’t to say Flickr is perfect. In fact, we prefer Twitter’s model of following and followers to Flickr’s “contacts,” which, frankly is a word best left to address book applications. And Flickr’s notifications system could be better; for example, if you change a “contact” to “friend” Flickr doesn’t inform that person of the change (although some might argue that’s a feature).

However, semantic nuances aside, Flickr does offer perhaps the best model of online relationships — asymmetrical, grouped and with plenty of privacy options to control who sees what.

Facebook, Twitter, and whatever supersedes both, take note — sometimes the best solutions are are right under your nose.

See Also:


Post Comment | Comments | Permalink

Experimental Firefox Add-on Weaves OpenID Into the Browser

By Scott Gilbertson May 8th, 2009 Categories: Software & Tools, Web Basics

Mozilla wants its flagship browser to keep track of who you are.

The folks at Mozilla Labs, the browser maker’s experimental arm that builds and nurtures new features for Firefox, have revamped Firefox’s nascent Weave add-on by incorporating new functionality that could substantially smooth the process of logging into websites. In a video walk-through of a new, experimental version of the Weave extension (see our previous coverage of Weave) Labs developer Dan Mills demonstrates the add-on’s ability to store and remember any number of web identities — including OpenID. The plug-in uses the stored identities to automatically log a user into their favorite websites, in most cases requiring only a single click from the user.

There are a number of password management apps out there that can do similar things, but few of them support OpenID.  That’s what makes this new Weave component, dubbed Weave Identity, so interesting. Because every website handles OpenID logins differently, the single sign-on technology has proved baffling for many users. Mozilla’s experiment goes a long way toward quelling the confusion around OpenID by eliminating the need to deal with its complicated login procedure.

Also, unlike a traditional password manager, Weave also stores your identities outside of the browser on a remote server. You can access and use the same set of identities no matter which computer you’re sitting in front of — home, work, school or your mobile phone.

Shifting the burden of handling identity to the browser is not a new idea. The Flock browser (which is based on Firefox code) recently demonstrated an elegant and user-friendly system for sniffing OpenID support on websites and facilitating the OpenID login process. Mozilla’s new attempt is one of the slickest designs we’ve seen since. It’s proof that browser developers are making progress toward the promise of a single sign-on — or possibly even a no sign-on — web by eliminating the work involved in maintaining multiple identities for multiple websites.

The advantage of handing off your identity to the browser in this case is that Firefox literally knows who you are. When you launch Firefox with the add-on installed, you log in to Weave, which stores your various identities — including your OpenID — on a remote server of your choosing. The Weave add-on is then able to log you in wherever you go with a single click. It can even bypass the login form altogether when you visit a trusted site, handling everything in the background.While Weave’s implementation of the OpenID sign-on flow offers a much better user experience than most websites currently do, OpenID isn’t the only option in the video. Traditional username/password logins are also supported, and those are handled using a similar, everything-in-the-background approach.

Offering a single sign-in solution for the web is currently a hot topic. Google, Yahoo, Facebook, MySpace and countless other sites are all offering to host your identity for you. Many of these key players on the social web are also offering tools to allow third-party sites to let you log in using the identity you have hosted with whoever your provider is — Google through FriendConnect, Facebook through Facebook Connect and Twitter through its recently debuted OAuth-based system. But in the end, who knows how long any of those sites will last? It seems to make more sense to hand these duties off to something more permanent than the hot site of the moment.

That’s where Mozilla’s latest implementation of Weave starts to make sense. You can store your credentials anywhere, including on Mozilla’s servers or your own web server. In the particular scenario Mills illustrates, the Weave extension can sync your identities across multiple Firefox installs, multiple PCs and even mobile devices, via the mobile version of Firefox when it arrives.

So far, the tools Mills shows off in the video aren’t included in the official Weave extension. If you’re feeling brave, you can install a development snapshot of Weave and take it for a spin.

See Also:


Post Comment | Comments | Permalink

Why Facebook Shut Down the Only Useful App it Ever Had

By Scott Gilbertson May 7th, 2009 Categories: Platforms & APIs, Web Basics

FacebookIt was inevitable, but we’re still disappointed.

Facebook has shut down the single most useful application ever to grace its tightly restricted platform. The Newsfeed RSS app was built using the recently unveiled Open Stream API, a set of tools developers can use to build apps that let users read, interact with and write to their Facebook stream.

Newsfeed RSS took advantage of the newly “open” stream to deliver virtually all your Facebook activity as a stand-alone RSS feed. Instead of just status updates, Newsfeed RSS offered, well, your whole activity stream as well as anything your friends posted. In short, it made Facebook work like the rest of the web by offering a real feed.

Unfortunately, that goes against the basic closed-world mentality of Facebook. According to the restrictions in the new Open Stream API, applications can not cache or otherwise store data. What this means is, according to Facebook, the simple act of keeping track of your friends through RSS is a violation of their privacy.

As Facebook director of platform marketing Ethan Beard tells Webmonkey, “The data shared is not your data. That content is owned by your friends and not you.”

We’d argue that our friends chose to share that data with us. So, why not let us consume it the way we want — in this case, via an RSS (or Atom) feed?

Beard says Facebook “believes users should have control over their data. It shouldn’t be Facebook, it shouldn’t be developers.”

But one of the reasons we’ll miss Newsfeed RSS is it provided a tantalizing glimpse of how fun Facebook could be when we really did have control over the experience, and we used that control to read it just like we read every other site on the web.

To be fair, Newsfeed RSS did not offer a secure feed, which does lead to friend data potentially becoming public. The URLs were obscured, but that’s a long way from “secure.” Even if the app had protected the feeds, it’s hard to imagine, based on Facebook’s track record, that it would have made any difference in the company’s decision to ban it.

Perhaps the strangest part is that it’s no secret Facebook has serious case of Twitter envy. But what seems to escape the company is that the reason Twitter is currently running roughshod over it as the hot web trend — much in the same way Facebook once ran over MySpace — has very much to with the completely open approach to data sharing Twitter has taken.

It’s true that Facebook still has more users than Twitter, but Twitter clearly has something Facebook does not, something that goes well beyond just buzz, something capable of capturing the imagination of many a web user. As Daring Fireball’s John Gruber succinctly puts it: “what Twitter has over Facebook right now is the ineffable: mojo.”

To put it another way, what Twitter has is endless freedom. Rather than relying on the system to protect your data, Twitter makes you rely on yourself — that’s it’s mojo: you are in control.

Facebook talks a lot about being open, having a platform and encouraging sharing, but no matter how much lip service it gives to “openness,” it’s platform is still very tightly controlled. It feels like a site that lost it’s mojo and is left with a massive user base and a desperate need to remain relevant.

Writing about the demise of Newsfeed RSS, Marshall Kirkpatrick at Read Write Web says, “there’s something mind boggling about the fact that Facebook opened up user news feeds… allowing other applications to access and work with all that data, but explicitly prohibits the same information from being served up to users themselves as an RSS feed.”

It’s mind boggling until you come around to inescapable truth of Facebook: nothing the company does is designed to help users or spur web innovation. On the contrary, the Facebook platform and all its blustering about privacy end up looking more like a smokescreen designed to make your data available to an advertising platform that will (so the site desperately hopes) enable Facebook to one day make money. We have nothing against advertising, but if you really want to know what Facebook thinks about the privacy of your data, think back to the failure of its Beacon advertising platform.

And we can’t help thinking that everything the company has done since then is just a warm up for Beacon II. If, along the way, Facebook throws out a few bones — like say support for OpenID logins — well, that’s a fringe benefit, but not really the goal.

Perhaps Facebook will pull off something stellar that changes the open web. More likely, the rapid pace of the web will render it a has-been long before the fabled money stream arrives.

In the mean time, you can follow us on Twitter.

Note: Newsfeed RSS’s creator failed to respond to our requests for comment. All links to the Facebook application now redirect to “http://www.facebook.com/home.php”

See Also:


Post Comment | Comments | Permalink

FriendFeed Adds Simple Logins for Twitter Users

By Michael Calore May 6th, 2009 Categories: Platforms & APIs, Web Basics


If you’re a Twitter devotee who’s curious about trying FriendFeed, the service just made it easier than ever to jump in and test its waters. FriendFeed has rolled out a new OAuth-based sign-up system that lets you join almost instantly using your Twitter login.

Go to FriendFeed.com and click on the Twitter icon under the “Create your account” option. If you’re already logged in to Twitter, FriendFeed will set up an account for you, pull in your Twitter avatar and your profile info and — most importantly — automatically connect you to all of your Twitter friends who are using FriendFeed. If you’re not logged in, there’s a simple authorization form that logs you in to Twitter, then kicks you back to FriendFeed where all the aforementioned internet magic happens.

But be aware that when you’re entering your Twitter username and password, you’re not giving it to FriendFeed, you’re only giving it to Twitter. Twitter is then allowing FriendFeed to access only the personal data it needs to set up your account.

What you’re seeing in action is OAuth, the emerging standard for securely allowing third-party sites to connect to your trusted networks and access some (but not all) of your data.

Twitter recently adopted OAuth, allowing third-party applications to let users log in using their Twitter credentials. This is an especially important step for a service like FriendFeed, which is similar to but more complex than Twitter, and therefore has a steeper learning curve. Also, the value of a service like FriendFeed doesn’t become totally apparent until you have an active network of friends you can interact with.

It’s easy for FriendFeed to build that network for you instantly. Your following/followers list on Twitter is public, and Twitter uses well-formed XFN and hCard microdata within its user profiles. FriendFeed can simply match up Twitter usernames to their associated FriendFeed accounts if your Twitter friends have also hooked up their account to FriendFeed. Almost everyone who uses FriendFeed funnels their Twitter feed into the service when they first join up, so the infrastructure largely already exists.

By combining the sign-up, profile creation and friend-finding processes into one simple step, FriendFeed is opening its doors to a potential flood of new adopters. It’s also admirable that the company is using the social web’s emerging set of data portability tools to its advantage rather than try to lock users into its own network.

I’d really encourage you to test out FriendFeed now if you haven’t already, especially seeing how easy it is to sign up. It’s more than a Twitter clone — it also gives you the ability to post photos and other media, as well as leave comments which can grow into fully-threaded conversations. FriendFeed is most useful as full-on lifestreaming app. Funnel all of your posts from various places on the social web into one, aggregated river of news.

For social media junkies, it’s a godsend — I’ve been on it since it launched.

Note: Thanks to Joseph Smarr from Plaxo for his insight!


Post Comment | Comments | Permalink

Why JavaScript Will Save Offline Storage in HTML 5

By Scott Gilbertson May 1st, 2009 Categories: Software & Tools, Web Basics

We’re quickly reaching the point when many of our favorite online applications can now also be used offline.

Gmail, Google Reader, Zoho Writer and other popular apps all offer offline access thanks to the Google Gears plug-in, which is making it way into several modern browsers. But HTML 5, the next generation of the web’s lingua franca, promises to take offline access even further by standardizing the way web apps store data for offline access. The W3C has recently proposed an offline storage specification for HTML 5 which aims to define that standard.

Some people will tell you that offline web applications are pointless — after all, what you get is basically a crappy desktop application and, as the argument goes, as wi-fi, 3G and EVDO approach ubiquity, we’ll be able to stay online all the time soon enough. While those are valid arguments, for those of us who already rely on web apps for e-mail, reading news feeds, accessing Twitter and communicating with friends, being able to use those tools even when the internet isn’t available can be a godsend.

But there is another, more complex problem with the recently proposed Web Storage specification in HTML 5: it’s based on SQLite.

This means developers who want to create offline-capable apps will need to write raw SQL. While SQL isn’t all that hard to understand, it is complicated and time consuming, two things that fly in the face of what fueled the explosive growth of the web.

Worse, the HTML 5 Web Storage specification is tied to SQLite databases. While there’s nothing wrong with SQLite, it does implement a variant of SQL, with a number of departures from the standard SQL language. Also keep in mind that SQLite is totally removed from the W3C and its keepers could well decide to completly change its interface one day (unlikely, but it is a possibility). That could easily lead to situation where what works with SQLite version X does not work with SQLite version Y.

So, is there a better way? Atul Varma of Mozilla Labs recently posted an interesting alternative solution. Varma has been working with an experimental version of CouchDB in the browser to “explore the possibilities of using a simpler standard that delegates many of its semantics to the JavaScript language.”

The result is a way to run your database queries primarily through JavaScript, thus eliminating many of the potential problems with HTML 5 approach.

However, as Mark Finkle, who’s working on Mozilla’s Fennec mobile browser, points out in a comment on Varma’s post, that proposed solution dodges the larger issue of having a standard database backend. “I like localStorage/globalStorage being the standard and other wrappers being built on top of that,” writes Finkle, “I’d rather keep the standards at a lower level — more of a foundation — and allow JS libraries to blossom.”

Finkle argues in his own post on Web Storage that we need “less talk of putting features in a specification that should be in a JavaScript library.” In other words, just as there are dozens of JavaScript libraries for creating interactive page elements, so there should be dozens of libraries for accessing storage elements.

It might sound counter-intuitive, but we agree. Would it make things more complex? On the surface perhaps, but complexity breeds choice and creates flexibility for developers.

And if the web is proof of anything, it’s that having many ways to do things means there are many things to do.

See Also:


Post Comment | Comments | Permalink

Facebook Announces Support for OpenID Logins

By Michael Calore April 27th, 2009 Categories: Platforms & APIs, Web Basics

What a day for Facebook.

The company has announced it is becoming an OpenID relying party, enabling users to log in to Facebook using an OpenID from any provider like MySpace, Google, Yahoo or AOL.

Facebook engineer Luke Shepard made the announcement at a developer event held at the company’s headquarters in Palo Alto on Monday. Earlier the same day, Facebook launched its new Open Streams API, a set of standards-based tools developers can use to incorporate user’s streams into third-party applications.

Shepard says Facebook will auto-detect if a user is logged in to any OpenID account when they arrive at Facebook.com. So, for example, if you’re already logged in to Gmail when you visit Facebook, you’ll be given the option to automatically log in to Facebook with one click. New users will also be able to quickly get started on Facebook by authenticating with OpenID.

This development comes less than three months after Facebook joined the board of the OpenID Foundation.

Does this mean an end to the “cold war” between Facebook Connect and OpenID? Maybe, but more importantly, it means there are fewer hurdles to the broad adoption of single sign-on technologies across the web.

See Also:


Post Comment | Comments | Permalink
 
Subscribe now

Special Offer For Webmonkey Users

WIRED magazine:
The first word on how technology is changing our world.

Subscribe for just $10 a year