October 2007
Mon Tue Wed Thu Fri Sat Sun
« Sep   Nov »
1234567
891011121314
15161718192021
22232425262728
293031  

Month October 2007

Entries 3 Total

OpenSocial Google’s answer to Facebook’s walled garden

Oct 31, 07 11:20 PM

Tech Crunch have a couple of reports on Google’s assault on the social networking market – OpenSocial – but rather than building a walled garden like Facebook, Google are trying to make it easy for developers to create a single application that can work on all social networks. And in turn deliver a social layer across all of its applications.

OpenSocial

OpenSocial will provide a set of common APIs to allow developers to access core functions and information on social networks. Specifically the APIs will give access to:

  • Profile Information (user data)
  • Friends Information (social graph)
  • Activities (things that happen, News Feed type stuff)

In turn the social network, or ‘Host’, agrees to accept the API calls and return appropriate data. And unlike Facebook which relies on a proprietary mark-up language Google’s API will use JavaScript and HTML. This open or inside out Facebook, leverages the ‘web as a platform’ rather than trying to tie users and developers in and is exactly what I was wittering on about previously. This is also bad news for Facebook.

There is a theory that as a technology matures it moves from closed proprietary systems where competition is based on functionality (e.g. mini computers); through improved reliability, convenience and finally commoditization with the resultant fall in cost (e.g. PCs).

Fans of Clayton Christiansen’s The Innovator’s Dilemma will recognize this transition. For those that aren’t, Christiansen argues that initially a new technology is forced to compete on functionality because, bluntly, they tend to be a bit rubbish – failing to meet users needs. Because the technology falls short of its user’s expectations the company is forced to design right up to the cutting edge where standards have yet to be agreed. So while the system will rely on standard components and technologies the architecture of the system is proprietary.

However, overtime the architecture becomes standard because people want reliability and reduced cost. This is possible because the technology improves at a faster rate than the users expectations. This in turn means that the company can step back from the edge to create more reliable, stable products. And because the design of the architecture doesn’t need to be innovative the company standardizes it and its value drops.

But standardizing the architecture allows new proprietary technologies to be designed and built on or with those, now open, systems. Or put another way value switches from the architecture to the component of a system. Facebook is a proprietary systems built using open, standardized technologies. Google with OpenSocial appear to be on the brink of launching an open, standard architecture, and open, standard architectures will switch the value from the architecture (Facebook) to the component because that is what is now distinctive.

So why would Google build something that has little value? Because Google are in the business of owning the glue.

Leave a Comment

Making Agile User Centered

Oct 30, 07 1:16 AM

To integrate UX activities into an agile software development process can be tough. Just consider this discussion between Kent Beck the creator of Extreme Programming and Alan Cooper a leading proponent of Interaction Design.

I’ll divide what Alan is talking about into two things: a set of techniques, and the larger process into which they fit. While I’m 100 percent with the techniques themselves, I’m 100 percent against the process that he described for using them. The techniques are optimized for being thoughtful in a cognitively difficult, complicated area where you’re breaking new ground, and the thinking that’s embedded in the practices is absolutely essential to doing effective software development.

The process, however, seems to be avoiding a problem that we’ve worked very hard to eliminate. The engineering practices of extreme programming are precisely there to eliminate that imbalance, to create an engineering team that can spin as fast as the interaction team. Cooperesque interaction design, I think, would be an outstanding tool to use inside the loop of development where the engineering was done according to the extreme programming practices. I can imagine the result of that would be far more powerful than setting up phases and hierarchy.

To me, the shining city on the hill is to create a process that uses XP engineering and the story writing out of interaction design. This could create something that’s really far more effective than either of those two things in isolation. (Kent Beck)

The techniques that Cooper proposes seek to define the behavior of software products “from the point of view of understanding and visualizing the behavior of complex systems, not the construction of complex systems.” He views “interaction design as part of the requirements-planning or product-planning process rather than as something that comes after the product planning is done.”

The User

Despite the fact that its tough to integrate agile and user centered design approaches it is possible because there are similarities – most notably the desire to create useful software. Take, for example, Alistair Cockburn’s comparison of agile development to a cooperative game:

Software development is a (resource-limited) cooperative game of invention and communication. The primary goal of the game is to deliver useful, working software. The secondary goal, the residue of the game, is to set up for the next game.

And as the name suggests, user centered design is about placing people, users of a piece of software, at the centre of the design process – making software that is useful to them – to do this effectively UX professionals seek to understand user goals and motivation through user research.

Or put another way user centered design helps us understand how people use our products, while agile development let us build and deliver software that is more relevant to its users. Both approaches are trying to deliver meaningful software products to people.

The problem then is not because the two approaches are trying to achieve something different but rather the way of achieving it is different; and specifically the sequencing of events and the time given to different aspect of the product development life cycle. Agile’s iterative development cycle is its key strength, but it also makes for some tight deadlines and people often question whether there is sufficient time to fully consider the users’ needs? However, as Alan Cooper suggests, the time to define the user’s needs is not during the development but before the development starts.

I’ve written previously about using an envisaging team to scout out ahead. Not to design the solution but to understand the problem space – understand what the business needs, what users need, who the users are and what the technology ecosystem looks like – and report this back in a coherent fashion to the rest of the team. This isn’t Big Design Up Front by another name. The envisaging team’s work should be limited to discovery work only. This combined with regular rounds of user testing between each iteration – the results of which are fed into the next round of development – can mean that agile software development can be highly user focused.

Photo: The User, by Pete Ashton. Used under licence.
Comments (2)

Ladies and gentlemen I give you BBC Programmes

Oct 18, 07 1:56 PM

Somewhat strangely, you might think, the BBC doesn’t publish persistent webpages for most its programmes. Or rather it didn’t, because today we’ve launched comprehensive programme support (in beta). So now if you go to bbc.co.uk/programmes you will now find an episode page for all our programmes – whether on radio or TV.

Book at Bedtime

Unlike the existing What’s On service, which publishes a page for every broadcast, with bbc.co.uk/programmes, we are publishing a page for every episode (with broadcast information), programme or series. In other words, rather than a the specific broadcast instance we are publishing a page for the cultural entity. A page for every episode rather than every individual broadcast is cool. Its cool because no matter how many times the programme is broadcast there remains just one page to represent that programme. This helps people find the programme because it helps maximize Google Juice – because all references link to the same URL. It also means that we can add more information to the same page over time and create context around that episode.

If instead of creating a page for each episode we created a page for every broadcast not only would we dilute the Google Juice we would also dilute the information about that programme. Users would be swamped with dozens of versions of broadly the same page, each with slightly different bits of information or different links. This makes it harder to find what you want and when you do find it the page is less valuable because it contains less information.

Publishing a page for every episode is all well and good, but its not the whole story, its also important to be able to create context around programme pages. What does this mean? Well, for starters we are categorizing programmes by genre and format and letting users browse by these categories, we are also grouping episodes into series, and programme. And over time we will add more information and additional links to supporting webpages.

We also want to help other people create context around our programmes so we have implemented a few features to support this too (although we aren’t including all these in this initial release). First up relevant pages are microformatted with hCalendar which makes it easier for the data on the webpages to be processed with software. And in the near future we’ll be publishing the data in different formats – RSS, Atom and HTML for starters, and iCal and JSON after that. And finally the URLs for all this will also be persistent – the resource will always be available and the URL to that resource will remain the same.

Providing persistent URLs is clearly a good thing – it means people can link to a page and know it will remain available and search engines work better – but building a system to deliver persistent URLs has some important implications. What have we chosen to do? Well here are some URLs:

And some future URLs:

  • bbc.co.uk/radio4/programmes/
  • bbc.co.uk/radio4/programmes/genres/news
  • bbc.co.uk/programmes/tags
  • bbc.co.uk/radio4/programmes/tags
  • bbc.co.uk/programmes/tags/japan
  • bbc.co.uk/radio4/programmes/schedule/fm
  • bbc.co.uk/radio4/programmes/schedule/fm/2007
  • bbc.co.uk/radio4/programmes/schedule/fm/2007/10
  • bbc.co.uk/radio4/programmes/schedule/fm/2007/10/12
  • bbc.co.uk/radio4/programmes/schedule/fm/2007/week40
  • bbc.co.uk/programmes/b006qtlx.rss
  • bbc.co.uk/programmes/b006qtlx.atom

The most obvious thing to note is that we haven’t included the programme title, broadcast date, Programme Brand (e.g. Heroes) nor channel (e.g. Radio 1 or BBC2) in the URL for our primary objects because all these things can change and its never a good idea to reflect your organisational structure in your URLs. For example, programmes are repeated on different channels – especially in the era of multi channel TV and P2PTV and programmes can start off on one channel before being ‘promoted’ to another (e.g. Little Britain).

So instead the individual objects (episodes, programmes and series) are identified using an eight digit, alpha numeric key. And this doesn’t ever need to change – not when we change the underlying technology, nor when we add more information, rebroadcast the programme, or decide to reorganise. However, the URLs for the aggregation pages (e.g. …/programmes/genre/music) are human readable and hackable, they support wombling.

UPDATE (2007.12.17)

Some more information on new features: tags and radio player, and iPlayer embedded video.

Comments (17)
Follow

Get every new post delivered to your Inbox.

Join 1,236 other followers

%d bloggers like this: