Tue, May 10, 2005
Piles versus tags
Card sorts are genius because they ask people to do what people have been doing for eons: place things in piles.
Card sorts are genius because they ask people to do what people have been doing for eons: place things in piles. We?��Ǩ�Ѣre surrounded by piles. Kitchens are piles of stuff we use to cook with. A bed is a pile of things we sleep with. Bookcases are piles of things we like to read.
Tags, likewise, work because they also let us put objects in piles. But the experience isn?��Ǩ�Ѣt the same. Instead of placing an item in a pile, we place the pile on the item. We?��Ǩ�Ѣre moving the mountain to Mohamed when the prevalent model says we should move Mohamed to the mountain.
This is an interface problem, compounded by the way virtual environments conflate space and time and allow us to place singular objects in an infinite number of separate, totally unrelated piles. It?��Ǩ�Ѣs much simpler to list piles by name than it is to show all of the separate piles laying about.
Also, tagging, by its nature, requires a tag, a concrete word, a label, when in many cases we may not have a specific language that describes the concept around which the pile begins to coalesce.
Tags face the same problem we face with search. With search, the user translates a search query from its original inception as an abstract concept in their mind; into a conscious thought that?��Ǩ�Ѣs translated into verbalized speech; and further truncated into the actual query they tap into the search box.
Tags require the search query before we know what we?��Ǩ�Ѣll be searching for. Tags require people to create the map before they?��Ǩ�Ѣve traversed the territory; they suggest the map is the territory, a veritable impossibility considering the territory constantly changes.
In cases where we?��Ǩ�Ѣre not sure where we?��Ǩ�Ѣre going, we develop default categories, nebulous ?��Ǩ��other?��Ǩ�Ѣ realms, gigantic formless piles with little use beyond remembering that we wanted to pile something somewhere. Tufte points to ancient mapmakers and their habit of proclaiming ?��Ǩ?�here there be monsters?��Ǩ��, and for librarians, certainly, these piles house the uncategorizable bugbears that refuse to acknowledge existing taxonomies.
It?��Ǩ�Ѣs a much more natural human instinct to create a pile and name it later once we have a better idea about the pile?��Ǩ�Ѣs boundaries. People prefer traversing the territory before drawing the map. If the map really came first, Lewis and Clarke would never have found the Northwest passage because Columbus would never have found America.
Drag and drop interfaces allow people to pile things about, but mostly, you still need some kind of title, some kind of tag, a country on the map: file folders have names.
Interfaces that encourage piling make handling large amounts of data very easy. In applications like iTunes, you can drag songs from your library (your big pile) into playlists, smaller piles. Likewise, in several IM clients, you can drag contacts to different piles like friends or family. With Trillian, conversations occur in piles by default, and you can move a conversation from one pile to another, or into an entirely new pile with a simple click and drag of the mouse.
The limitation in iTunes and in IM contact lists is that your piles must be named first. Trillian?��Ǩ�Ѣs ability to let you pile conversations without labels is the only application beyond the desktop (I know of) that allows you to freely organize objects.
The interface conundrum, then, isn?��Ǩ�Ѣt how to allow piling, but how to allow the navigation of piles; how to recognize what a pile will contain when it doesn?��Ǩ�Ѣt have a name. In real space, piles have numerous physical affordances that help us navigate to find objects in a pile, and to differentiate piles from one another, even if we can?��Ǩ�Ѣt enunciate a clear tag that defines the pile. Piles almost immediately communicate the types of objects we can find there and how many of those objects there may be.
Online, with low-dpi monitors and two-dimensions, we lose sight of the granularity that makes piles such a powerful interface. Navigating large virtual spaces of visual objects, like photos, could conceivably be accomplished using thumbnails and easy zoom features, but how do you thumbnail a pile of words (documents) or sounds (mp3s)?
I don?��Ǩ�Ѣt think, we have any easy answers.
For documents, it?��Ǩ�Ѣs possible to use the documents title, or the first few lines, to provide users with enough of a visual hint to suggest the nature of the object. And it?��Ǩ�Ѣd be easy enough to display more of a hint if a user were to hover or focus on the object.
Similarly, mp3s could be thumbnailed using the artist or composer?��Ǩ�Ѣs name and the song?��Ǩ�Ѣs title. Windows and OSX already attempt this, but nothing of this sort happens online in shared spaces, and the implementation relies inevitably on someone other than the user properly providing the necessary meta data.
There?��Ǩ�Ѣs a sweet spot halfway between the current desktop OS implementation for piles and the solution suggested by Dan Saffer and his Pile Cabinets. It?��Ǩ�Ѣs certainly where we should be headed. How much easier would del.icio.us be if we could simply drag links to piles and sift through other people?��Ǩ�Ѣs piles without ever having to think about tags?
That sweet spot can only be fully realized in online, collaborative spaces where we can encourage other people to come sift through our piles. One of the most important attributes of a pile is that any other person on the planet can walk up and sift through. Piles, after letting the individual give some order to the world, are predicated on their ability to be navigated by someone, anyone, other than us who will take our pile into consideration as they reorganize it into their own piles.
Piles are conversations, not only with ourselves about the here, now, the past, and the future, but also with others. And we must always design to further the conversation.
Talk About "Piles versus tags"