Spent the last couple of years working for the BBC, but now working for Yahoo!, but I've only been there a couple of months os if I say something controversial then that's not official policy.

Presentation will be online afterwards.

For some reason I was put down to talk about user interface, and when people think about Web 2.0 and user interface, they think about rounded corners and gradient fills.

Blogger started this entire thing. I could do a whole talk on design topes for Web 2.0, but I'm going to talk about product design at a higher level, what it means to design for the web.

I'm going to talk about what the web is changing into; what you should be building on top of it, and architectural principles.

What is the web changing into?
Web 2.0 is clearly a buzzword, and a conference, but it's also marketing to see the idea that things are changing, You could argue that it's a shift and an attempt to get money out of VCs. Buzzwords are an attempt to create order, to make sense of what's going on amongst some tremendous change.

Tim O'Reilly's article What is Web 2.0. And Marcus Angermeier's representation. But there are many difference, in design, infrastructure, server, business models, everything is changing. This idea of Web 2.0 can't support the no. of ideas going on beneath it. The church is too broad, so I'm going to concentrate on one layer, a web of connected stuff.

Think in terms of APIs and data. We are moving from a world of web pages connected by links, we are now in a world of data connected by APIs.

The web is data sources, services for manipulating, and ways of connecting them together. Conflating content and data together.

Mash-ups, terrible word but interesting idea, shows that things can be cut together

Yahoo! Astronewsology, splices news and star sign, e.g. things that happened to Capricorns, or explore a news story and compare what should have happened to someone and what actually did, which is useful when looking at obituaries.

Can use non-standard data sources and hybridise them in ways that makes each data source better, so you can navigate one in terms of another.

Two things aren't so interesting, but add a third or fourth, and it gets good, and you get a network effect of services. Every new service you create can build on top of every other service in existence, and every service which adds data to the ecosystem adds value to the other services.

This creates massive creative possibilities.
You get accelerating innovation because people don't need to invent the same thing twice
increasingly competitive services
Increasingly componentised services
Increasingly specialised services

There is money to be made. Can you se APIs to drive people to your stuff. Worked on a project at the BBC to produce info about programmes, which if the BBC opened it up, people could do interesting things with. Amazon do it well.

Make your work more interesting by providing APIs because other people go and do stuff with it. Can use syndicated content as a platform for other things. Can turn your API into a pay-for service.

If you're not part of that ecosystem, if you're not opening up, you end up in a backwater, doing all the work yourself, disconnected from the environment around you, and that's not going to work anymore.

Choosing what to build.
So if you buy this vision that if you're part of the ecosystem you'll be caught up in it and pulled forward, the question then is what kind of things do you want to build?

Ask, what can I build to make the whole web better? How can I add value with the aggregate web? Users are getting benefit from the connected web, and if you can't add value to that you are nowhere.

Can you open up a dat source? Can you help users put their own data online in reusable ways? Can you help annotate? Can you help organise? Can you get their data into the ecosystem?

Important to data that is architecturally important to people's lives that companies want to own it - location, identity, calendaring, names spaces etc.

So companies want to own that space. They want to own the data.

Also, exploring and manipulating data, improve it, navigate it, add metadata to it. Navigation is important, with increasing amounts of data being put up online, e.g. can you help people find video amongst all the TV that's going up online.

Architectural principles
Need to read Matt Biddulph's The Application of Weblike Data.

In this world, the core components are

- data sources
- std ways of representing data
- ID and URLs
- distribution
- interaction and enhancing data
- rights frameworks and financial

Believe that there is money here and this is going to happen in a solid way over the next 10 years.

1. Add value to the aggregate web.

2. Build for normal users, developers, machines (some of these may be synonymous). Normal users just want to use it, developers want to find hooks, and machines want predicability so makes sure that you're consistent.

3. Start your design with data and not with pages, data is reusable asset, it's the core part of the system so must get it right. You can do these processes together, so you need to be able to represent the data properly too. Design the data in weblike ways then manifest it as pages. Want to be comprehensible enough to be explorable and comprehensible for human beings.

4. Identify your first order objects and make them addressable, i.e. the core things that people refer to, e.g. films. Programs, not the time they are broadcast or the series, but the episode. That gives you the maximum options for aggregation and organisations. Events, which only happen once. People. Then make that addressable. Give it a unique and well structured URL so that anyone on the internet can point at it. If you do that then you're in a good situation already, you're winning because you're part of an aggregate web of data because you're comprehensible by search engine, service aggregator like Technorati, communities such as Digg or Del.icio.us can refer to it. All of these things are connected data resources connected to this data source.

5. Readable, predictable, guessable, hackable URLs. A good URL should be a permanent reference to a resource which must not change, and should represent the thing it's referring to well, solidly, reliably, for ever. If your first order object has subordinate pasts, then ok to use hierarchy in URLs, but the URL that represents the definitive object should be in one place. Should not be underlying tech, particularly if that tech might change. So get reid of .html or .aspx or whatever, because you might move away from that technology and that would make it break. Should reflect the structure of the data, e.g. events only happen at one event os their structure can have the date in, so long as it's a one-to-one correlation that's ok. And there's a temptation to make things human readable so much so that it breaks the URL, e.g. radio broadcasts shouldn't have the date in because they are rebroadcast and the date breaks the URL. Let people guess the URL. More predictable and guessable the better. Readable is good, but don't need to overdo it. Exposing identifiers is not always bad, if it's the right sort. URLs are powerful, being moved into the UI of the page. Good URLs are beautiful and a mark of design quality. Don't do bad ones because I'll cry.

6. Identifiers are not enough. Lots of things that are on the web that aren't well represented, things that maybe didn't originate on the web, e.g. people, events, films. You need a way to correlate them, so if you can correlate with other identifier schemes then do so. Films are a good example, there are lots of other urls for specific films. Need to make it easy to talk about the same thing.

7. Build list views and batch manipulation interfaces. Need to find ways for people to navigate data and manipulate it. Three types of page: destination page; lists for navigation, ways to cut through things; manipulation space, interface for batch manipulation of first-order concepts. Manipulation is a really interesting territory. Problem with changing information on the web is that the interface widgets we have aren't that powerful, so AJAX is trying to fix that problem to give more application-y style widgets to help us manipulate data. Core aspects are not to break the web, so if you're doing to use AJAX, or Flash, on the destination page is should be to only change that concept on that destination page alone.

8. Parallel data representations. All types of pages can be queried by APIs; destination and list-view pages can be represented by microformats; and then there's also parallel XML for destination pages and RSS for list-view pages. RSS in this environment is great, the ability to send data from one place to another in the easiest fashion. Delicious does that incredible ways - every page as a parallel RSS representation. So any app can go and get the RSS and use it. How you distribute the data is another matter and there aren't many ways of doing that, so look at microformats.

9 Make your data as discoverable as possible. If you do 1 - 8 you'll be doing 9 too.