Category Software

URLs aren’t just for web pages

We’re all use to using URLs to point at web pages but we too often forget that they can be use for other things too. They can address any resource and that includes: people, documents, images, services (e.g., “today’s weather report for London”), TV or Radio Programmes in fact any abstract concept or entity that can be identified, named and addressed.

Also, because these resources can have representations which can be processed by machines (through the use of RDF, Microformats, RDFa, etc.), you can do interesting things with that information. Some of the most interesting things you can do happen when URLs identify people.

Currently people are normally identified within web apps by their email address. I guess this sort of makes sense because email addresses are unique, just about everyone has one and it means the website can contact you. But URLs are better. URLs are better because they offer the right affordance.

If you have someone’s URL then you can go to that URL and find out stuff about that person – you can assess their provenience (by reading what they’ve said about themselves, by seeing who’s in their social network via tools such as XFN, FOAF and Google’s Social Graph API), you can also discover how to contact them (or ask permission to do so).

With e-mails the affordance is all the wrong way round – if I have your email address I can send you stuff, but I can’t check to see who you are, or even if it is really you. Email addresses are for contacting people they aren’t identifiers; by conflating the two we’ve gots ourselves into trouble because email addresses aren’t very good at identifying people nor can they be shared publicly without exposing folk to spam and the like.

This is in essence the key advantage offered by OpenID which uses URLs to provide digital identifiers for people. If we then add OAuth into the mix we can do all sorts of clear things.

The OAuth protocol can be used to authenticate any request for information (for example sending the person a message), the owner of the URL/OpenID decides whether or not to grant you that privilege. This means that it doesn’t matter if someone gets hold of an URL identifier – unless the owner grants permission (on a per instance basis) they are useless – this is in contrast to what happens with Email identifiers – once I have it I can use it to contact you whether you like it or not.

Also because I can give any service a list of my friend’s URLs without worrying that their contact details will get stolen I can tip up at any web service and find which of my friends are using it without having to share their contact details. In other words by using URLs to identify people I can share my online relationships without sharing or porting my or my friend’s contact data.

You retain control over your data, but we share the relationships (the edges) within our social graph. And that’s the way it should be, after all that all it needs to be. If I have your URL I can find whatever information (email, home phone number, current location, bank details) you decide you want to make public and I can ask you nicely for more if I need it – using OAuth you can give me permission and revoke it if you want.

Photo: Point!, by a2gemma. Used under licence.

Phun the fun science simulator

Phun was developed by Emil Ernerfeldt, Umeå University, Sweden.

It is:

  1. a 2D physics sandbox;
  2. brilliant.

You can download it for Windows or Linux  here and see what others have done with it here.

links for 2008-02-19

Managing the code-garden

Kevin Barnes suggests that software engineering is a bit like gardening – software is never finished – you need to spend some time planning, some time adding new features and some time tending to what you have. Otherwise your code will become steadily more and more unmanageable.

Artfully planned decay

Basically, code is like a garden. We lay it out, plant it and then tend and maintain it for as long as it continues to warrant the attention.”

The trouble is how do you make sure that you allocate enough time to maintenance while continuing to add new features or enhancements? How do you make sure you don’t allocate all your time to adding the next new thing, nor spend weeks on end tidying your code because all you’ve done recently is add new features?

Likewise how do you give the team the time and space to innovate – to try out their ideas? One solution is to let anyone add a new item to the product backlog or requirements catalogue and then prioritise it alongside everything else. Well this is OK if it’s a big idea, but not great for smaller items nor for more geeky ideas if the Product Owner or the business at large doesn’t understand the value of such things. It also feels wrong – if someone has a good idea that can be implemented quickly then they should be able to so, after all going via the Product Baacklog route may take more time than simply implementing the feature. And that is as good a way to kill off innovation as anything else.

But likewise you need to provide appropriate project governance – if everyone did whatever they wanted then the business is unlikely to get what it needs from the software.

One solution is the idea of Gold Cards [pdf] as suggested by Tim MacKinnon. Gold cards are designed to address:

A lack of innovation because the customer does not necessarily explore options that are technically possible but not currently required. Consequently, cutting-edge knowledge may be slowly lost from the team.

Gold Cards allow developers time to explore technical possibilities in a controlled and focused way.

In Scrum the current sprint’s work items are written on cards and pinned to the wall – so everyone knows what’s being worked on and everyone knows what’s completed. Gold Cards are special cards that let you work on your own idea – it can be anything you want so long as it’s on the current project.

Each developer is allocated two Gold Cards at the beginning of each calendar month… Gold Cards can be used at any time during a month, but cannot be carried over into the next month. [...]

Each card grants the developer who has it, one day of work on a topic of their choice.

In a similar fashion ‘Gardening Cards’ let you work on whatever is bugging you – not bugs which should be prioritised elsewhere – but those things that just annoy you about the way something is implemented, that missing feature that would make life much easier if it were there. It’s your chance to spend time tending to your garden, not planting new features.

So the idea is that you place one Gold Card and one Gardening Card on the wall. Each sprint everyone can spend one day on a gold card item and one on a bit of gardening. But because the project only has one gold card and one gardening card only one person can be doing each activity at a time – everyone else is working on the backlog as normal. It’s the Scrum Master’s responsibility to encourage everyone to take the time to work on these items.

Now clearly how many days you allocate to gardening and gold card items will depend on a number of different factors: team size, sprint length, age of the project and the state of the code (you wouldn’t allocate gardening time at the start of a project for instance). But generally when a project matures you should be allocating some time every sprint to this. The Scrum Master can plan around this because although they don’t know exactly what everyone will work on she does know how much time will be allocated.

The other advantage of this approach is that they also help fill the gaps – if your planning is a bit off, you encounter some unforeseen problems and some member of the team are being held up then they can remain productive by working on their gold card idea or fixing that pesky item that’s being bugging them for while rather than waiting for someone else.

The mobile web – will Android make it interesting?

Nic Newman is predicting that this year will be the year of the mobile web. He cites the focus of handset manufacturers on improved user experience – spearheaded by Apple and the iPhone, ‘all you can eat’ tariffs from networks and the delivery of content in formats that are more easily consumed by mobile devices. All of this is true and 2008 may well transpire to be the year of the mobile web. But my fear is that we are going to be building the wrong thing.

Mobile web

If the mobile web is only about delivering content to work on small screens then we’re all missing the point. And I have to say from a personal point of view it won”t be particularly interesting to build. That’s because not only are current phones devices with small screens, they are also crippled – third party developers can’t access the phone’s features. As Joel points out:

You can follow the p-code/Java model and build a little sandbox on top of the underlying system. But sandboxes are penalty boxes; they’re slow and they suck, which is why Java Applets are dead, dead, dead. To build a sandbox you pretty much doom yourself to running at 1/10th the speed of the underlying platform, and you doom yourself to never supporting any of the cool features that show up on one of the platforms but not the others. (I’m still waiting for someone to show me a Java applet for phones that can access any of the phone’s features, like the camera, the contacts list, the SMS messages, or the GPS receiver.) Sandboxes didn’t work then and they’re not working now.

In otherwords we have a major problem with our current mobile space: the lack of access to the device. Currently we are just delivering content – with low bandwidth and poor interfaces; developers have no meaningful access to the phone’s API. And this is a shame because what makes mobile devices interesting is only available via the API. Mobile devices are interesting because they are with you most of the time, they can know their location and store information about your friends, family and colleagues.

As Peterme at Adaptive Path puts it design for mobility not for mobiles:

What I’ve seen in our work is that form factor, though important, is not crucial. In fact, it might be a misleading concern. The thing that’s interesting about designing for mobile isn’t the form of the device. It’s that the device comes with you.

What we’re realizing is that the key item of concern when designing for mobile is the context in which the device is used. What this means is that discussions of “PC” versus “mobile” are misguided, because we shouldn’t be focusing on the device. We are not designing for mobile — we’re designing for mobility.

Android might be different. Android does give you access to its API and this means that as a developer you can combine information from the web with data from the mobile phone such as the user’s contact data, their calendar, or geographic location. Or as Andreas Constantinou puts it:

The Android SDK is an environment for building connected applications. Every application (including dialler, idle screen, SMS, contacts, etc) can consume and produce content. Every application on Android is a Web 2.0 citizen.

Android not only makes the mobile web interesting it also means that developers need to build something quite different. Rather than worrying about whether we should be delivering different content to mobile devices we should be worrying about building a web of data and mobile applications that can combine that data in interesting ways with data on the phone. Of course this will depend on how successful Android turns out to be and whether or not other manufacturers follow suit and give third party developers access to the phone’s API.

Photo: 1000 mobiles, by Gaetan Lee. Used under licence.
Follow

Get every new post delivered to your Inbox.

Join 819 other followers