Design for a Generic Wishlist Service

first published:
Nov 13, 2008
tags:

Wishlists: Useful but Limiting

Many online shopping services — Dabs and Amazon.co.uk, to name but two — provide a wishlist facility, where you can store lists of things that you wouldn’t mind being bought for you. (See, for example, my Amazon wishlist)

These lists can be enormously useful for the people who use them, because they can make gift giving for events like birthdays, weddings, or Christmas much more efficient — it makes gift selection much more straightforward, and it stops two or more people from inadvertently giving the recipient two of the same item. (Plus, online retailers can take care of the packing and delivery of gifts, which in many cases can be most useful.)

However wishlist services as they are currently realised are limiting: you can only purchase items on a list from the provider offering them for sale. (Well, that’s not strictly true — you can always talk to the individual concerned and ask them to remove the item from their wishlist, and purchase the item somewhere else. This ruins the possibility of surprising the recipient, however, and is enough work that most people don’t bother.)

Naturally, shopping services consider the lack of competition with other like online retailers an asset; less competition means that they don’t have to be as competitive on price. From a user’s perspective, however, it would be better if they weren’t tied to any one retailer, not just in the hopes of getting a better deal, but also because there is no one retailer which offers everything of interest for sale. Even Amazon, with its enormous range of wares, have routinely discontinued items that I’d like to own — typically books which are no-longer widely available.

Stand-alone Wishlist Services

A naive solution to this problem would be to provide a stand-alone wishlist as a separate service, publishing links to sought-after items along with a “claim” button. A visitor can then look down the list, claim an item or items of interest, and then go to a retailer of their choice to order the item.

This solution works in the sense of providing mutual-exclusion — it prevents two people from accidentally procuring the same item — but there’s nothing to stop an evil-doer (or simply a web crawler gone rogue) from clicking on all of the claim buttons without then going on to purchase the items they’ve claimed responsibility for.

One approach to dealing with this problem would be to require end-user authentication, either using simple one-shot passwords or something more reusable like OpenID — and then manually adding and removing users as required or using some kind of reputation system. But this is clunky: anyone who you want to buy you something nice now has to go through yet another online sign-up process, and the web has far too many of those already.

Dropping the authentication requirement

However, we can provide an open service which doesn’t require any kind of wishlist-specific authentication. If we’re clever and require clients to pay the cost of the goods as part of the claiming process, probably using an online payment service like Google Checkout or PayPal, then it’s no-longer possible for an evil-doer to remove all of the items on our wishlist without paying for them first. (Anyone found doing this should probably be referred to by a name nicer than “evil-doer”!)

Such a system has many other desirable properties:

Because purchases aren’t atomic, however, there are a few corner cases to be careful of, but engineering graceful solutions for these should be reasonably straightforward. For example, if an item goes up in price between the gift being paid for and the purchase order being made, some mechanism to either reallocate the funds to some other item or to return them to gift-purchases should exist. (Similarly, if the cost of the goods goes down, it’d be nice to be able to return the difference!)