How to build a web application in four days

There’s been a bit of buzz around ‘How To Build A Web App in Four Days For $10,000‘. Not everything is applicable to the kinds of projects I’d be involved in, but I really liked these points:
  • The best boost you can give you or your team is to provide the time to be creative.
  • You’ll come back to your current projects with a new perspective and renewed energy.
  • It will push your team to learn new skills.
  • Simplify the site and app as much as possible. Try launching with just ‘Home’, ‘Help’ and ‘About’.
  • Make sure to build on a great framework
  • Be technologically agnostic. If your developers are saying it should be built in a certain language and framework and they have solid reasons, trust them and move on.
  • Coordinate how your designers and developers are going to work together.
  • Get your ‘Creation Environment’ setup correctly. [See the original post for details]

“The coolest thing to be done with your data will be thought of by someone else”

I discovered this ace quote, “the coolest thing to be done with your data will be thought of by someone else”, on JISC’s Common Repository Interfaces Group (CRIG) site, via the The Repository Challenge. The CRIG was created to “help identify problem spaces in the repository landscape and suggest innovative solutions. The CRIG consists of a core group of technical, policy and development staff with repository interface expertise. It encourages anyone to join who is dedicated and passionate about surfacing scholarly content on the web.”

Read ‘repository or federated search’ for ‘repository’ (or think of a federated search as a pseudo-repository) and ‘scholarly’ for ‘cultural heritage’ content, and it sounds like an awful lot of fun.

It’s also the sentiment behind the UK Government’s Show Us a Better Way, the Mashed Museum days and a whole bunch of similar projects.

Lonely Planet launch API

Lonely Planet launched their ‘Explore API’ and developer network at the BBC Mashed 2008 day. Available content includes ‘destination content, including geocoded points of interest reviews, destination profiles, traveller-created “best of” lists and travel photographs’ from their image library so as a travel junkie I’m already itching to have a play.

There’s more background in this interview with Chris Heilmann and Chris Boden on the Yahoo! Developer blog, ‘Lonely Planet starts developer program at mashed08 in London‘, but I thought it was worth pulling out this quote about the benefit of APIs, particularly as they’re an organisation whose business model relies on its reputation and content:

Where do you see the benefit in releasing an API? How do you plan to monetize it or is it a loss-leader for you?

We don’t have a funky web app like Twitter or Dopplr at this stage but we do have content – in a sense, that content is our platform. We want to take the Lonely Planet content and community experience onto relevant new platforms and make it accessible to travellers in new ways. We’re not going to be able to do all of that on our own so we’re looking to tap into external sources of innovation and creativity through open collaboration to help us imagine and execute the next generation of services that might enrich the lives of our community.

In terms of monetization, we’ll look to work commercially with those developers who come up with innovations that we believe have the potential to create commercial value.

Interesting BBC article on the philosophy behind Craig’s List:

Initially it was mostly coming in via email which we would reply to, but we’ve grown so much that now the more common thing is you set up a series of discussion forums in which users bring up various things that they think are important to change or modify in some way.

Users talk amongst themselves about things we’re doing poorly or could be doing better, and then we’re able to observe that interaction. It proves to be a very kind of efficient and interesting and useful way, nowadays, of digesting that feedback.

The other important aspect that you might not imagine initially is that all of the feedback is coming in as ‘voting with their feet’. We just watch how people are using particular categories.

If we see that, ‘oh users want to do this and we’re not currently enabling this’, then we try to code up some changes to better enable them to do whatever that is.