Maybe this kind of info could be provided on a website. eg. Electricity companies compared, the best water tanks, qualified installers, etc. You can still get the kickbacks but it is free for users.

Idea

A small internet connected computer with wifi is used to serve images to a screen, ideally a plasma screen hanging on a wall. In reality it will probably just be the home TV. The network can be used as a source of data to display images which may reflect the season, the weather, one’s personal photographic collection or one’s mood. Maybe it even synchs in with imagery associated with sounds that might be playing.

Detail

The user would need to be able to configure the device so that they can specify what images are to be displayed: local folder, URL, list of URLs, season/weather/mood server. Also timing, transition effects.

Implementation

A cheap small linux computer which can connect to the internet. It might have a hard disk and a webserver so that images can be ftped to it so that it can also act as a source of images.

Problems

Maybe this can be done already with consumer hardware that is out there. Games consoles can connect to the web. MP3 and phones can store images. They just need a little bit of software and the right hardware connection. This idea is different in that it can connect to a remote server and serve files that the user has never seen before. It can certainly be done with an ordinary computer and as media centers become more popular they will win out. Maybe a simple client (web browser) and some server software is what is required.

Refinement

So what we have left is just a website capabale of serving images from various sources.

Problem

People are concerned about public liability and want to protect themselves contracturally. More generally, people have the need to enter into agreements which can be recorded and referred to.

Solution

A website could be set up where a user could create a contract and then send it to subsequent parties to sign. The acceptance could then be recorded and further info made available.

Inspiration

North Shore parents being the leaders in paranoia.

Implementation

A website as per usual. Should be pretty quick to put together.

Strengths and Weaknesses

The biggest weakness would relate to the legality of the agreements entered into. Obviously the strength of the agreement depends on the wording and its status as a contract. These could be difficult to overcome. If so – I believe that the system would still work to a certain degree.
So far I haven’t heard of any “contracts for the masses” on the web so may be worth looking into further.

Business Model

I believe that people would pay $10-$20 for one off events. It could be marketed to schools and excursions, events organisers etc.

Problem

The problem is that there are few entry-level metadata consumers that can take metadata feeds, aggregate and (re) publish them. There are a lot of channels talking but not that many listening. The human agent is still doing the filtering. TBL vision of the semantic web is still a long way off. We need some smarter agents doing the work for us.

Solution

The solution is to do something practical about it and to do it in a way that will spread around the web. The solution is one cross platform metadata consumer and several platform specific metadata producers. The consumer can take registered feeds and publish aggregated and filtered channels. The producers are modules that sit on top of established CMS systems.

The use of public subjects (PSIs) such as those found in DMOZ can be used to merge channels from different sources. This is the different proposition with this system – sources can be merged. This relies on content producers marking up their content correctly.

Inspiration

I have been interested in CMS systems for quite a while. I was thinking rolling a generic version of my own from code cobbled together from various projects. The main feature of my CSS would be that it supported standard Dublin Core (DC) metadata attributes and that it could output RSS and Topic Maps. I quickly realised that this would be wasted effort because there were so many CMSs out there and that it would be better to concentrate on the interoperability aspects (metadata exchange). This lead to the realisation that a number of Metadata Producers could be written on top of existing CMS packages. The corollary was that the core of the system needed to be a cross platform metadata consumer.

Implementation

Most of the hard work has been done by the open source movement. There is an open source topic map engine, TM4J, which could be used to drive the topic map aspects of the application. The most difficult aspect is merging and an engine such as this one would save a lot of work.

The basic application would allow users to log on and customise their channels and how they would want them served. For example, UserX wants channel x,y,z and wants it delivered to their inbox every morning. Admins would also be able to go on and register new metadata sources and define merging rules. This is the real value add of the system.

The system could support a very basic metadata management system that allowed users to blog and to maintain CMS. Users could define their own subject areas and blog till their heart is content. They could then share their ideas. Users could be encouraged to reuse DMOZ PSIs.

Strengths and Weaknesses

There are a lot of nerds out there working hard on content. They belong to big companies with a lot of programming resources. However, we must remember that it is often the simple things that work on the web, e.g. HTML, RSS. Simple concepts tend to take off as well, e.g. Blogging. The right balance needs to be struck.

Business Model

The metadata consumer is the smart end of the system and we need to be able to get people to pay for the use of it. The users, those using the channels, will not pay. They can just use Google or some other source. However, content providers wanting to integrate their content might pay. E.g. those with a “topic brain” (associated subjects) publishing time sensitive resources. Content providers just get screwed from every angle, don’t they?

It might also be possible to do consulting work for the CMS providers to write the modules to output the metadata. Ie. Topic Map output routines which could dump XTM at a file location.

Outcome

I am yet to do any work on this project. Topic Map engine vendors have been stretched to come up with their basic engines. It is up to the next generation of developers to start building applications with these engines.

Problem

A purchaser of an engagement ring needs to be reassured of a number of things. In descending order they are as follows:

• The vendor is reputable
• The diamond is of suitable quality and price
• The ring is of a suitable design
• The service is good.

Generally high street jewellers may satisfy the first requirement, although this may not always be the case, however they fail in the other three categories. My small experience suggests that the diamonds on sale in traditional establishments are overpriced, the range poor and the service haughty.

One possibility is that purchasers go online to buy the ring. I would guess that online vendors would score well over all categories however, there is always a concern over reputation for such a high ticket item. Most purchasers would baulk at buying something worth $10000 online.

Solution

A physical and virtual store where purchasers can get a good price on the diamond and have a choice of several standard, “classic” designs for engagement rings.

Inspiration

Buying an engagement ringwas a difficult process. Luckily we had a very good experience from Marcus Creations, an importer of diamonds. The business was good enough to get me excited about the possibility.

Implementation

Establishment would consist or real and virtual shop. Most sales through virtual but purchasers could come in to try on if required.

Strengths and Weaknesse

Need expertise in diamond important and jewellery manufacture. Not easy skills to get or to find./pp

Business Model

Good prices on the diamonds means that you need to make a bit extra on the ring. You don’t want to get into a cost cutting exercise in this market but there is room to be cheaper than the high street. Would need to rely on word of mouth in this business.

Outcome

A possibility but unlikely due to the expertise required.

Problem

There was no problem. It was a perceived opportunity. People were not crying out for massage services.

Solution

An online massage booking service for those in the London area. Masseurs could come to your office. You could buy gifts, etc, etc. Backed up with a contractual agreement with a variety of masseurs.

Inspiration

This was the result of throwing around a few ideas with my wife Sam. I think we were sitting in a little beer garden in Amsterdam when the ideas began to come together for this one.

Implementation

A database. Online booking. Lots of legwork to sign up the masseurs.

Strengths and Weaknesses

This idea wasn’t that great. In fact it was pretty lousy. Firstly, masseurs are geographically dispersed, hard to locate and organise. They are not very good candidates for a system such as this. Secondly, you needed a pretty good business plan to survive the Dot Com fallout. I don’t think that the up front costs would have been recouped.

Business Model

Cost born by the consumer. Masseurs paid less than their usual rate because we could ensure continuous supply of clients.

Outcome

Not pursued at all. Not aware of any other successful massage sites.