Use case wish list

Use Case: Wish List

This is a simple little app -- a list of things I would like to receive as presents. The primary Model is Present, which contains, eg:

• Name of the item
• Category/tags of the item
• Price
• Description/notes about the item
• URL where it can be found online
• Number desired (usually 1, but could be more)

I (the owner of the Space) add items to the list; friends and family (as I allow it) can search the list and indicate that they are claiming this particular gift.

Analysis

This one is close to trivial, easy enough that I could implement it early. And it sounds duplicative at first glance -- after all, most big online stores already have wish-list capability. But that's the key: this is primarily aimed at small stores.

And things get really interesting if we can provide serious integration with those stores. Say that we build a "Wishlist button": sort of like the Share buttons that so many places have to spread the word about news articles, but this time to record things I'd like to buy or have bought for me. The button would be a one-line drop-in script that we would make available to merchants. When you click the Wishlist button on a page that is showing something for sale, it slides in the Querki Panel, with the fields pre-populated for this item. (Assuming the user is logged into Querki; otherwise, we need a login handshake.) All the user has to do is press an OK button to accept this item onto their Wish list -- trivially quick and easy, and any online store can use the feature easily.

This one's a fairly serious killer app. It would take a while for the network effects to kick in, but it can start with simply users filling in the information by hand. And once there is critical mass, it starts to become really useful for stores to integrate with it.

Another idea is Dependencies. Kate suggests that, say, if she puts a cross-stitch pattern onto her Wish List, she really wants the cloth and the stitches for that pattern to also go onto the Wish List, more or less automatically. But she should be able to easily remove any of those dependent items that she doesn't want or need, simply by unchecking them. And those dependent items should only show up in the context of the main purchase -- they shouldn't be shown separately until and unless the pattern itself gets purchased.

Another idea: cross-population. For example, the Craft Gallery App should have an easy Wish List button on each pattern. If you press that button, and you have Wish List set up, it auto-populates that pattern into your Wish List. Doing this in a general way is not easy, but it's potentially very powerful, especially because it leads into the notion of Apps as Services, which other Apps can talk to.

Features

• Querki Panel -- the one bit of new technology that this would need to really sing: a panel that can slide in over a cooperating web page, showing a specific Querki page or form, to make it easy for users to add new stuff.