Kiko was seed-funded by Paul Graham’s YCombinator, for the price of one programmer’s 6 month salary. Paul sums up Kiko’s failure in two words: Google Calendar. Supposedly it was the integration with Gmail that made Google Calendar more useful. This is the same office-effect Microsoft has used in the past to combat rival office products: integrating products together.

Whilst Paul was blaming competitors for failure, the founders blogged their own thoughts on why they failed. In summary:

- Stay focused

“Most entrepreneurs have lots of ideas. Often times, many of them may be really good. I don’t know about you, but my favorite part about startups is talking about new products and new business ideas. If you’re a creative person, it’s very easy to get side-tracked on side ideas when you really should be working on your main one. This is bad. Bad, bad, bad. We did this a lot with Kiko, and it caused many delays in getting the product out the door.”

- Don’t release too early

“You always hear “Release early, release often”, especially if you hang around Paul Graham crowd, but the footnote that doesn’t get enough airplay is that you shouldn’t release too early … You only get one shot to impress people; don’t blow it because they won’t coming back next week to see if you’ve improved.”

- Build incrementally

“We tried to build the ultimate AJAX calendar all at once. It took a long time. We could have done it piece by piece. Nuff said.”

- Do it right from the beginning

“Cute hacks can cost you time. Take the time to do things right from the beginning. Seriously.”

- Hire Slow, Fire Fast.

- Define your target market, don’t just target the early adopters

“… If you ever want to gain any real traction as an online calendar service you have to target the cubicle dwellers and their Outlook calendars that only exist outside the (Techno)sphere. Techie users are fickle, transient and demanding. You can spend all of your time implementing ATOM feeds and hCalendar export and never be the better for it.”

“Our contact management and calendar sharing implementation did not meet our users’ needs because we never defined our target market. In addition, our designs for how these features should behave were negatively affected by our marriage to the existing, and broken, workflow in Kiko 1.0. Techies, families, social groups, and businesses all have different needs for sharing their calendar data with others and, by ignoring that fact, we created a solution that met no one’s needs.”

It seems that all of these points come down to one thing - focus. If you focus your ideas and your business you will have less features to maintain, the ability to build incrementally, be careful about who you hire, and target the right market. Its better to be the leader of a niche market, then a nobody in a large one. Less is more.

The classical reason for failure - hubris - still applies. I think the web 2.0 hype has given the founders unrealistic ideas about their market, product, and value. Whilst the geeky early adopters are willing to try anything, it is not an indication of quality. Imagine what the techcrunch crowd would actually think of MySpace if it just came out. Realistically, Kiko’s user interface was far from perfect for anyone who doesn’t know the term AJAX. Google does lots of things at a time, and yet their calendar looks neater. If calendaring is all you do, you better make sure yours is not just better, its amazing. That takes some real calendar passion, far beyond making a web version of outlook.

I wish the founders all the best, and hope they find that failures are just as valuable as hits.

The primary purpose of a search engine is to direct users to data relevant to their query. This is done by returning a set of pointers to data - “links” along with a preview (small subset) of the data. A search engine can obtain such links in any way, including:

- crawling the web autonomously
- structured XML feeds (eg sitemaps)
- manual user submission

The distributed and hyperlinked nature of the web allows users to publish data at a single location, allowing it to be discovered by other users and search engines. In contrast to pushing data to users by publishing it in various locations, this approach eliminates management and versioning problems if data needs to be updated. In other words, allowing search engines to discover your data is better than publishing it in various centralized databases (web applications such as classified listings sites, Google Base, etc).

Vertical Search

A vertical search engine only contains pointers to data of certain type / class. Reducing the search space to data of a certain class greatly improves the relevancy of search results, as is evident by recent popularity of vertical search engines like indeed (jobs), edgeio (classifieds), sidestep (travel), kelkoo (shopping) and extate (property).

Generic search engines like google consider all data to be of the same class - text. The only attributes used for searching and refinement are keywords. This may have been appropriate at a time when most of the information on the web was static text - articles, reviews, stories, etc. Now, however, much information comes from databases. Therefore, different classes of data have different attributes, just as in the object-oriented programming world: a book for sale has a price, a property has N bedrooms, a business has an address. A vertical search engine allows searching and filtering data by these attributes, which is crucial.

Horizontal Search

Some may say that a vertical search engine is not generic enough - its a function that works only on certain inputs. Horizontal search on the other hand is not limited to data type - its limited to a set of attributes. In essence, it allows searching over a pre-defined set of attributes across different information types. Google is an example of horizontal search where allowed attributes are keywords. Possible other horizontal search engines may be:

- Local Search: find everything in a given location
- Price Search: find everything in given price range

although these are currently limited to certain classes of data as well to improve search results.

Search Matrix

We can combine both vertical and horizontal search scenarios in a matrix, where the verticals represent different classes of data and horizontals - different attributes that apply. Some of these attributes may be boolean - such as keywords, or quantitative - such as price.

Both vertical and horizontal search engines currently only support searching by a constant set of attributes. The primary reason is ease of implementation: a constant set of attributes allows data to be stored in a single table with the applicable schema. It also allows the user interface to map directly to SQL statements, and keeps the interface (such as filtering of results) more or less constant.

The ultimate goal however is obvious - a search engine that uses all possible attributes to search over all possible classes. The aim is thus to cover as much of the matrix as possible. In light of this, a query can be represented as a set of attributes:

Q = { m1a1, m2a2, m3a3 … }

where mN is a quantifier (the amount of attribute a), and aN is the attribute. For example, a query for a flight may be:

Q = { ‘london to new york’:keywords, 0-9:hours, 0-300:dollars }

Even if this can be achieved, the user may often want to limit results to a certain class. Yet the query does not always provide enough information to determine a unique class to return. For example, a query for:

Q = { 0-300:dollars }

will return everything from flights to books. Whilst allowing a user to filter results is possible, this is highly inefficient. Alternatively, the user may specify the class of data to return:

Q = { ‘books’, 0-300:dollars }

In essence, we encode the class as an attribute, thus turning our search matrix into a more regular representation: document - attribute matrix, where attributes are not limited to boolean values (absence or presence of a keyword). Given the above representation of the query, it may be possible to deduce a variation of the classic boolean model: a quantitative boolean model.

Data Class Hierarchy

Classes themselves form a hierarchy - books and gadgets is a subclass of items for sale, for example. As in OOP, attributes are inherited from parent classes: all items for sale have a price, yet books also have an author. Can such a directory of all things be constructed manually? Tedious, yet possible.

An important question remains: how to determine the type of data. Perhaps the set of extracted attributes will provide significant insight, or machine learning and classification techniques will do the trick. Current vertical search engines solve it by manually specifying the data sources, however this is very inefficient. Additionally, being able to identify the permanent URL of a single data object (not some list thereof) is another problem altogether. Perhaps structured initiatives, such as providing RSS feeds of data objects, will prove to be effective solutions.

Indeed natural language processing techniques may allow us to determine nearly all quantitative attributes, and perhaps even classify data accurately. However, will a single company be able to achieve this? The distributed nature of the web is more likely to produce vertical search engines that focus on parts of the search matrix, solving a single problem really well, rather than a difficult problem poorly.

The concept of an operating system, stolen from the desktop world, does not belong on the Internet. The major advantage of the WWW is that it’s a distributed platform - each application chooses its own implementation, the libraries and web services it uses in the backend. The Wikipedia definition of a Web OS is ridiculous – a set of abstractions, such as a file-system, for networked applications. Except the only abstraction in a distributed system is the protocol. Web services like Amazon’s S3 file-system already provide such functionality. Why would we make web applications dependant on a standard set of libraries and APIs of a Web OS when the Internet provides us with the freedom of choice? In fact, specifications like BPEL already allow us to define business processes that dynamically determine which web services to use during execution.

So if web applications don’t need the services provided by a Web OS, what does a Web OS actually do? Perhaps it’s a convenient container that allows us to run multiple web applications side by side? Indeed so, however isn’t that the purpose of the browser? Why have another container, another layer of abstraction? How efficient would such a container be? Assuming its written in Javascript and HTML, not very. Why not simply improve the browser – after all it already is the default runtime platform for any web application.

Of course a standard set of libraries, like GUI libraries, are great. They standardize the user experience across applications. And we already have them. However the trick is, as in the real world, in mass adoption, not constraints of an OS.

We already have the basic components of a Web OS: the distributed web applications functioning like services and their runtime environment – the browser. What may be lacking is a central view of our data across all these distributed applications. I believe that this is what will come to be known as ‘the homepage’. And it’s not far fetched: RSS can already make much of that happen. What’s needed is browser support for such features and a few basic specs.

To conclude, browsers are the operating systems of the Web. They should provide sophisticated client-side APIs for ajax web applications to make use of: desktop notifications, desktop integration through drag-and-drop, client-side data cache, secure access to the file-system, and so on. Why browsers remain dinosaurs is beyond me.

- Facebook turns dows $750M offer, hoping to fetch $2 billion [1]
- Zopa - a person-to-person lending company based in London raises $15M [1]
- Jobby Launches - job hunting web 2.0 style
- Riya Launches - photo search with facial recognition, long rumored to be acquired by Google
- PayPal Mobile Launches - not too late to beat TextPayMe [1]
- Beyond AJAX: HTTP Streaming [1]

After TCP/IP has been standardized as the protocol of the Internet, Tim Berners-Lee invented its first great application - the World Wide Web: a simple collection of hyperlinked documents. Each document is identified by a fixed URL address, and written in a mark-up language called HTML. The documents are meant to be viewed in a web browser, which in turn uses a protocol for publishing and receiving HTML documents known as HTTP which works over TCP/IP.

This web of information proved extremely popular for large text collections, such as newspapers, encyclopaedias, blogs, etc. Similar to Adobe Reader and the PDF format, the web browser - a simple tool for reading and navigating HTML documents, proved extremely easy and safe to use for a long time. Web directories such as Yahoo! were created in an attempt to classify all of these documents, and make them easy to find.

Everything was simple until developers figured out a way to generate HTML documents dynamically, for each client request. Instead of static documents that are published by users and read by users, these documents are generated using an application and can thus be different for every user. A way to pass parameters along with such requests in URLs also became popular, allowing HTML pages to act as functions, rather than documents. Such functions quickly became building blocks of complete applications that visualized their results using the popular HTML format so that they could also be accessed through the browser. This highly inefficient approach has many flaws, most notably:

- Whole document has to be generated and transferred to the client even if a small part of it changes with each request.
- Applications typically have internal state that browsers don’t know anything about. This state may be lost if the user navigates back or to a random document altogether.

More concrete approaches to delivering applications inside the browser, such as Sun Microsystems’ Java Applets and Web-Start have failed miserably. Downloading and running code on-demand inside the browser almost seemed a failed cause. That is, until JavaScript proved that HTML documents can be made more interactive and animated without giving up on security. As browsers evolved, so did their support for JavaScript – a hack used to embed code within an HTML document. Most importantly, recent support for the XmlHTTPRequest object allows JavaScript to request new documents in the background, and update parts of the current document without user’s intervention – a technique commonly knows as AJAX.

It is amazing how far we have stretched the WWW and humble HTML, without ever considering its intentions. AJAX now allows us to interact with an application as if it’s a single HTML document. We have successfully hacked existing technologies into a way to deliver something it wasn’t meant to, moving ourselves away from the hyperlinked web of information published by people.

Google would me ultimately perfect without such hacks, and information on the web would be much more readily accessible, not hidden behind applications and databases.

Content on the web should be static, with a unique address – URI to identify it and share it with others. The purpose of applications is to create that content and publish it on the web, rendering it as HTML document, be it a database, a blog, a word document, etc. But why should these applications be HTML documents themselves, when HTML is extremely poor in rendering common software components, and was never designed to do so? Why can’t we stick to interactive desktop applications, like iPhoto, iWeb, and allow them to publish our content to the web?

Is it because web applications are easier to write? I don’t think so. The main reason is *accessibility*. We want users to access our applications without having to download, install, and configure them. We also want our data to reside on servers where we can access it from anywhere, but that’s not really an issue – desktop applications can easily save our data remotely, to iDisk, WebDAV, or an FTP drive.

What we want is for the application code to run on the server, yet have it draw the user interface as a typical desktop application on our screen. Sounds impossible? Not at all, such technology has existed on Linux for years: simply launch a remote application and tell it to draw on client’s X server. However, this has never really taken off primarily because of speed issues. The problem is that the application draws primitives – lines and shapes, instead of pre-defined components (as with HTML), requiring large network throughput.

An alternative approach, somewhat similar to HTML, would be to define a standard mark-up that can be used to render the UI of a desktop application. Such mark-up would define common UI components (textbox, toolbar, menu, window, button, etc) as XML elements. Similar idea will be used in Vista, knows as XAML. UI events will cause new requests to be sent to the server, and only the required changes in the UI will be sent to the client. Thus, an application can be launched by providing the ‘application browser’ with the URL of the document containing UI mark-up. The browser can then render the mark-up using operating system’s native GUI library.

Such an approach would mean total security too – no custom code is ever run by the client. Alternatively, support for JavaScript will make such applications more ‘offline’, and will require connectivity with the server only for data access – as with AJAX. In either case, it will bring the same UI standard experience to Internet applications.

I plan to begin working on this in the near future. One question still bugs me though: what if users actually prefer the look and feel of HTML-based applications? Would you want Flickr to look like a desktop application?

Menus Hide Functionality: Placing functions within menus makes them extremely difficult for users to find. Don’t do it. Don’t mimic desktop applications that have all of their functions always available to you from a single giant menu or toolbar, simply disabling menu items when they are not applicable. Operations should always be visible next to the object they apply to. A typical example is photo manipulation. You can allow the user to manipulate thumbnails directly using some menu. A better solution is to have the thumbnail link to a separate page that allows manipulations on that object.

One View at a Time: Whilst ajax allows us to have sophisticated desktop style interaction, showing and updating multiple views, this is generally not recommended. The reason the web became so popular is due to simple story-board pages that reduce decision making to a minimum. Avoid using DHTML for pop-outs and having multiple windows - they don’t give the user a clear choice since the main UI is still operational. Instead, cover the current UI completely, like lightbox.

One Object at a Time: Each page should contain at most one object, and may have a side-pane on the right listing possible operations (functions) on that object. For example, a list of photos as thumbnails is an object, with a side-pane allowing us to to refine that list. However, the sidepane should not allow operations on individual photos - these should be moved to a seperate page.

Operations are Vertical: Toolbars are horizontal because they are static. Lists of operations are context sensitive. Always list operations applicable to the current viewed object vertically on the right side of the page. This differentiates operations from navigation, and allows any number of operations to be accessable by scrolling. Toolbars have limited space.

Navigation is Horizontal: Since operations are vertical, this is a natural choice. This is obviously where the logo belongs too.

The implementation is highly focused on tags. Locations are tags, so search is keyword driven, not map-driven. This should be more user-friendly, minimalistic, Google-like. I didn’t integrate it with google maps because that would require geocoding all addresses, and that costs $$$. The only other site that does something similar is ononemap which is completely map driven. I hope my approach will appeal to some, especially those not familiar with maps.

Some interesting features are:

• Autocompletion of locations (a-la Google Suggest)
• Related locations are shown to expand the search
• Multiple tags can be selected (eg. waterside, lift, porter) and de-selected
• Selecting tags and changing price filters updates properties in the background (ajax)

Many more things are to come, including RSS feeds for results, email alerts, and a REST API to allow mashups with the service. I’d love to start making this international, although trulia already has something similar for US.

Yes, I know, you want access to the full content in your RSS reader, not just the summary. But that isn’t the purpose of RSS. As a listing, it simply points to objects. If you want your RSS reader to show you these objects directly (instead of viewing them in your browser) they have to be written that way: the content must provide an alternative rendering of itself (HTML, XML, plain text, video, etc) that your RSS reader would understand (note: your RSS reader may understand HTML already, so what you really want is to display only the text, removing any ads that the content provider may need to generate revenue and publish that content in the first place). But of course, content rendering is in the hands of the publisher.

Yet don’t underestimate the power of a universal format for a directory listing. What I find surprising is the fact that the web never had one from the very beginning, because after all its a distributed file system. Directory listings serve the purpose of a sitemap, allowing search engines and RSS readers to syndicate content (Google’s sitemaps can be in RSS) and easily determine what has been added/updated/modified. It is then somewhat surprising that RSS came from the blogosphere, as it is a general method of formating a directory listing that may soon become a building block of the WWW.

Isn’t this a centralized, google-owned, semantic web anyone? Something that the RDF guys, including Tim Berners-Lee would sweat over and throw shit at. If anybody, Google may have the potential to pull it off, although I’d hate to see that happen. The monopoly would be far beyond Microsoft, it would wipe out Craigslist, eBay, Amazon, everything.

However, that’s not Google’s kinda marketing. They would claim that you own the content, and they are just a bookstore. So just as you can sell something on eBay, you should be able to sell it on Google. Fair enough. But then everything would end up on Google, and that’s scary. Why have multiple bookstores when you can have one with everything in it, and its next door to everyone?

How is a distributed semantic web different? RDF standards describe the data structure in a common fashion, enabling search engines to aggregate this data. Anybody can publish something somewhere, and hope for it being found (or submit URL to google?).

In either case, service and application-centric web is being replaced by a data-centric one, where user’s own the data, so no application boundaries exist. The only functions needed are publish and search. What’s left for businesses to do apart from hosting? Show me the $$$.

The next step? Fine grained permissions for web resources.