Quick Update
Things have been quiet on the blog as we have been heads down on some major new functionality. We continue to make small bug fixes and talk with all of you via email, Twitter and FriendFeed.
I can tell you that the new functionality has been our most requested feature and in testing it is pretty darn cool.
More details next week!
|
Bookmark:
|
Follow:
Big in Japan is REBORN!
I am pleased and proud to announce that Big in Japan Inc. is one of 50 finalists Google’s Android Developers Challenge with it’s GoCart™ application. Of course, the credit really should go to Rylan Barnes, GoCart’s developer. GoCart was built specifically for Google’s Android mobile phone platform. GoCart users can easily scan the barcode of any product using their phone’s built-in camera. Once scanned, GoCart will search the inventories of nearby, local stores using data from the phone’s built-in GPS. Soon we will port GoCart to the iPhone and enable mobile payments.
Over the past year the Big in Japan team has become more and more involved with mobile applications. Our initial focus was the iPhone (applications like iPhoneVote), but quickly we began working on Google’s Android mobile phone building a fun application called SocialTones. Recently we decided to reinvent Big in Japan to focus exclusively on the development of mobile applications. GoCart is our first serious mobile application with a real business model behind it. The newly incorporated company has three co-founders (including me):
Rylan Barnes co-founded Big in Japan and is the developer of GoCart™, one of 50 winners of Google’s Android challenge. Rylan started his career at HP where his work on XML-based frameworks was widely acclaimed. Since then he has worked as a software developer for Vertical Alliance and Software Architects working with AJAX, C# and .NET.
Jason Hudgins co-founded Big in Japan and was on the team that developed Tunewiki, one of the 50 winners of Google’s Android Challenge. Jason has spent the last eight years developing software for companies including Idearc Media, DeviantART and Ariesnet.
Alexander Muse co-founded Big in Japan. Alexander is a serial entrepreneur with more than a decade of startup experience. He served as CEO of Architel, a provider of outsourced information technology services. Previously, he was founder and CEO of LayerOne, a ventured backed telecommunications infrastructure company he started in the late 1990’s.
|
Bookmark:
|
Follow:
Media Migration Marches On
I’ve been doing some research regarding “media migration,” that is, the general movement from certain media channels (e.g., print) to others (e.g., mobile).
Of course, none of this is new. However, it’s striking when you dive into some of the data. A few data points of note:
- Network television viewership has declined 40% since the early 80s
- Daily newspaper circulation is down 20% since 1990
- Consumer magazine circulation is down 11% since 2000
It’s an oversimplification to claim that this is all about those pesky Internets. Cable has come on strong with higher quality, niche programming - although cable itself is now maturing.
Where the audiences are moving (again, nothing shocking):
- Social networks. Social networks are winning over destination websites in terms of time spent. For example, users on MySpace spend an average of 17 minutes per visit. Compare that to four mintutes per session at FUEL.tv - a very engaging action sports focused destination site.
- Smartphones. Smartphones are coming on strong. Worldwide smartphone sales grew 29% in Q1 2008. With the iPhone, and other new platforms, this medium is now a reality.
- Games. Here is a scary statistic: the average 17 year old plays 10 hours per week.
- Desktop. New development tools are making it possible to create some very interesting, Internet aware, socially enabled applications.
Of course, media migration happens over decades, not months. The following video tells that story well. Some folks still love to kick back and watch the tube (the kind without the “You” in front of it). Internet vs. TV
|
Bookmark:
|
Follow:
Android Design Image
Wired Magazine has a picture of the first Google Android phone on their website. Known as the HTC Dream the device has a Google tag line on it and will be released by T-Mobile.
|
Bookmark:
|
Follow:
HTC Android Handset Launch - October 13th
Huliq News is reporting that the ‘HTC Dream, aka G1′ is going to be launched on October 13th and available on T-Mobiles network. According to the site you won’t be able to pre-order the ‘HTC Dream G1′ until October 17th (it confused me too). Huli explains that the phone is,
…a slider, which slides to the side to reveal its QWERTY. The keys on the QWERTY are neatly spaced, which lets your fingers easily type along. At the back of this phone, you can see the words “With Google”. Apparently, the handset is to make use of the big name of Google to get itself more popular.
T-mobile will offer this handset with pre-order price $199 after the instant rebate, and you’ll be bound with a 2-year contract. You’ll also need a GMail account to setup the HTC G1 handset. Since it runs on Android, do expect that it comes bundled with tons of Google services. What are known now are those common ones such as maps with Street View, You Tube, IM and text, Gmail.
Other goodies you can find on HTC Dream G1 handset are a 3 megapixel camera, video playback, music player, memory card slot and an application store. And it’s equipped with a huge touchscreen that is likely to rival the iPhone’s.
|
Bookmark:
|
Follow:
Get your Blogger following fix (in Reader)
Our friends on the Blogger team just lauched Following. Blogger users can now "follow" blogs they like, given them an easy way keep up with their favorite blogs, and allowing authors to see who their readership is.
Better yet, followed blogs also show up in your Reader account, in their own folder. That way you can get the full power of Reader's tagging, sharing and starring without having to maintain two separate reading lists. Of course, if you'd rather not see followed blogs in Reader, there's a setting to hide them.
We hope you'll have fun playing with Blogger's new social feature. And if following brings you to Reader for the first time, welcome!
|
Bookmark:
|
Follow:
Authenticated Commenting Needs Help
The new service backtype which aggregates comments and allows you to follow them a bit like friendfeed or twitter is further proof for me that authenticated commenting needs to be pushed further up everyones priority list.
backtype are currently scraping the posts for comments (bit like CoComment does via their plugin) so that they can pickup the URL of the user who posted it, they have to do this because RSS / ATOM feeds do not contain the URL. The problem with this is three fold,
- The commentator must be consistent about the URL they leave.
- Because the URL is not authenticated it means people can imposonate others very easily (which happens a lot more than people think!)
- If the blog does not require you to enter a URL it wont work at all, we removed the requirement in fav.or.it to enter a URL when we realised that this was a major barrier to our mass market audience (we have 80% Internet Explorer users now) This is because outside our world of blogs most people do not have a URL to pin their names too.
Authenticated
Because of the above concerns we chose to work with the RSS/ATOM feeds + API’s available from each service, this means for sites that do support authentication we then get the data that allows us to confirm real ownership of the comments. For instance Louis Gray has DISQUS installed on his blog (along with 30,000+ other blogs) so via the DISQUS API we get back the comments in a format that allows us to identify each user (as seen here)
Blogger also supplies the same information - so again if you look here you will see those who left comments via their blogger accounts show up as authenticated users. Our users can claim each of those individual identities (Disqus, blogger, etc) and join them together, this includes the ability to claim your OpenID which although useful for login purposes does not help with commenting.
The reason for this is that although I can use my OpenID via Blogger (and other commenting services) to leave a comment, once left the comment data is not then exposed back out via the comment feed.
Working Together
The work we have started is still just a partial solution to the problem and I am sure that others like backtype would welcome any moves to improve the identity aspects of commenting. Given the number of companies getting involved I do believe we will start to see change over the next 6-12 months and given the right push from the right people/companies the formats for storing identity information within RSS / ATOM could be standardized.
OpenID is certainly not the only solution and we need a strong workgroup with representatives not just from the commenting companies but also from all the major blogging platforms because we need their support to then expose this information via the feeds they supply.
As usual if you want quicker updates on what we are doing at fav.or.it follow me on twitter.
|
Bookmark:
|
Follow:
Five Insane Upgrades That You Should Never Do
|
Bookmark:
|
Follow:
30 Skills Every IT Person Needs
|
Bookmark:
|
Follow:
Simple Update Protocol: Fetch updates from feeds faster
When you add a web site like Flickr or Google Reader to FriendFeed, FriendFeed's servers constantly download your feed from the service to get your updates as quickly as possible. FriendFeed's user base has grown quite a bit since launch, and our servers now download millions of feeds from over 43 services every hour.
One of the limitations of this approach is that it is difficult to get updates from services quickly without FriendFeed's crawler overloading other sites' servers with update checks. Gary Burd and I have thought quite a bit about ways we could augment existing feed formats like Atom and RSS to make fetching updates faster and more efficient. Our proposal, which we have named Simple Update Protocol, or SUP, is below. You can read more details and check out sample code on Google Code. Discuss the proposal in the SUP FriendFeed room.
SUP is just a proposal at this stage. We are eager to get feedback and ideas, and we expect to update the protocol based on feedback over the next few months.
Simple Update Protocol
SUP (Simple Update Protocol) is a simple and compact "ping feed" that web services can produce in order to alert the consumers of their feeds when a feed has been updated. This reduces update latency and improves efficiency by eliminating the need for frequent polling.
Benefits include:
- Simple to implement. Most sites can add support with only few lines of code if their database already stores timestamps.
- Works over HTTP, so it's very easy to publish and consume.
- Cacheable. A SUP feed can be generated by a cron job and served from a static text file or from memcached.
- Compact. Updates can be about 21 bytes each. (8 bytes with gzip encoding)
- Does not expose usernames or secret feed urls (such as Google Reader Shared Items feeds)
SUP is designed to be especially easy for feed publishers to create. It's not ideal for small feed consumers because they will only be interested in a tiny fraction of the updates. However, intermediate services such as Gnip or others could easily consume a SUP feed and convert it into a subscribe/push model using XMPP or HTTP callbacks.
Sites wishing to produce a SUP feed must do two things:
- Add a special
<link>tag to their SUP enabled Atom or RSS feeds. This<link>tag includes the feed's SUP-ID and the URL of the appropriate SUP feed. - Generate a SUP feed which lists the SUP-IDs of all recently updated feeds.
Feed consumers can add SUP support by:
- Storing the SUP-IDs of the Atom/RSS feeds they consume.
- Watching for those SUP-IDs in their associated SUP feeds.
By using SUP-IDs instead of feed urls, we avoid having to expose the feed url, avoid URL canonicalization issues, and produce a more compact update feed (because SUP-IDs can be a database id or some other short token assigned by the service).
Because it is still possible to miss updates due to server errors or other malfunctions, SUP does not completely eliminate the need for polling. However, when using SUP, feed consumers can reduce polling frequency while simultaneously reducing update latency. For example, if a site such as FriendFeed switched from polling feeds every 30 minutes to polling every 300 minutes (5 hours), and also monitored the appropriate SUP feed every 3 minutes, the total amount of feed polling would be reduced by about 90%, and new updates would typically appear 10 times as fast.
You can see SUP <link> elements in FriendFeed's Atom feeds (e.g., http://friendfeed.com/paul?format=atom), and you can see FriendFeed's SUP feed at http://friendfeed.com/api/sup.json.
|
Bookmark:
|
Follow:
