Archive for February, 2009

Early Web 2.0 Startups - Where are they now?

Posted by Jeremy on February 21st, 2009

In Feb 2006, a thoughtful Flickr contributor named Ludwig Gatzke, uploaded a graphic. It was basically a big collection of logos of Web 2.0 companies. I thought it would be interesting to see what happened to all these various start-ups in the last few years.

So I’ve edited the graphic by fading out those start-ups that are no longer with us.

Graphic of Web 2.0 Start Ups

The methodology for this was simple, I typed in the URL for the company, failing that I Googled the company. If I didn’t find anything relevant on Page 1 of the Google results I marked it as dead. I also marked as dead sites that are “under improvement”, still in closed beta-signup or otherwise not immediately usable. Further, any company that redirected to another domain I marked as dead - so buy-outs/ups are faded as well (eg. Writely became Google Docs so it no longer exists as such).

There’s lots to think about in terms of what led to these companies disappearing - especially those that simply shut-down.

If any of these are alive and kicking, I’ll be happy to amend the photo, so let me know.

Usability Spot-Fix #324094 - Bookmarks and Draggy Interfaces

Posted by Jeremy on February 19th, 2009

An increasingly common technique, I think appropriated from PDF and other document viewers (Google Maps?), is the draggable interface. http://www.fichey.com/ is a site that implements this navigation method.

This kind of thing allows for innovative two dimensional navigation, especially if you use Flash to make the movement fluid. Fichey and others that use a Flash solution miss a critical element, especially give the rather massive size of their grids - and that is bookmarking.

A simple solution would be to have Flash parse the GET request to look for a “coord” value. If your site implements so-called clean URLs, make the x and y coordinates the last sections in the URI.

That way a user can link their friends directly to the area in question and bookmark it to return to later - both a critically important to usability.

Why we need a code.gc.ca

Posted by Jeremy on February 8th, 2009

My good friend David Eaves wrote an exciting post wherein he talked about his vision for StatsCan and how it should act like Google.

I think that StatsCan, on its own, could provide some compelling and valuable data for citizens of all stripes by implementing simple, cheap and scalable web services via conventional APIs. However I think StatsCan alone fails to capture the potential in technology.

Taking the Google analogy further and perhaps more literally - I think the Government of Canada needs a centralized managed repository for all its open initiatives. From APIs to software projects and packages to documentation.

Models abound for this kind of service - code.google.com being the most salient and directly applicable.

By providing robust (bilingual) documentation of the APIs proffered by Statistics Canada (and other ministries) Ottawa could spur innovation nationwide. Value-added services, mashups, statistical models and the like would all be available to anyone with the determination and the skills required to make use of the data provided.

Taking it a step further, the Government could provide an eco-system for these projects. A greenhouse for projects that make use of government data or contribute or expand government services.

The savings this could bring to the government’s TCO for software would be tremendous. The cost of staffing an open source community management bureau would be a fraction of the expense paid out to extortionist software vendors. Even if the government outsourced the maintenance of this project to a company, the cost savings would still be significant.

If the government developed robust and transparent standards for security, provided code and tools to develop applications - the issues of security and usability would be minimized.

By providing incentives for development of specific projects and fostering a community of recognition and respect the government can use its most valuable assets, trust, knowledge and influence to drive innovation.

The infrastructure required to build this is peanuts by governmental standards - a rack of servers, a high bandwidth internet connection and a horde of politically minded software nerds (some of whom speak and read French).

To start out, the working group should look like this:

6 developers with experience in open source. Two should know .NET, two should know Java EE and two should be web app experts - PHP, RoR, Python etc. They write foundational code, submit updates to the code bases and handle bug fix delegation etc.

1 project manager - this is our big-picture thinker, tie breaker and bean-counter. The Boss-Person.

4 community managers to wrangle the community projects and facilitate community leaders.

2 government liasons. One should be techie and the other political but both should be competent in the other discipline.

2 UX people, these people ensure applications comply with usability and accessibility guidelines and give guidance to the designers in the community.

3 Tech writers. These people document code and APIs, write tutorials and construct videos and other media.

So that’s 18 full-time, high-quality tech people - that’s probably about a million dollars per annum in costs all told,  the value generated by the team would be tremendously greater than that.