Tying Down Feature Ecology
Posted by Jeremy Voorhis Thu, 21 Sep 2006 23:33:00 GMT
Feature ecology is a collection of concepts I am developing in an attempt to frame my work as a technology producer. The term feature ecology pays homage to media ecology from which I draw some inspiration. While feature ecology intersects with media ecology, it focuses on product utility and aesthetics.
In my last post, I introduced the term feature ecology. The discussion that took place in the comments, however, digressed from the meaning I intended to share. In an effort to clarify the already-overloaded terms I have chosen, here are some operating definitions.
- Feature
- A unit of behavior and perceptual attributes. For practical reasons, a feature may be defined recursively, as a set of other features1.
- Product
- An environment consisting of features which a user may interact with.
Features provide an arena for human behavior. Features also have an agenda – their capabilities inform the user of what is important, and through ommision, what is not important2. A product will contain features that reflect the values of its producers, and – hopefully – the values of its users as well. Interactions also take place between features, as I have mentioned in my last post. Depending on the product, the addition of a feature may change the way users interact with features. A new feature may also make prior features more or less valuable to their users.
In response to the original post, Brian Ford wrote,
I’m cool with the zen-ish “products are features” but “features collected are not products” if I’m just being contemplative. But I’m wondering how does this help me think about software?
How can feature ecology assist us in creating better products? It reminds us to be aware of the behaviors we wish to evoke in our users. It also requires an awareness of the interactions between features within a given context; when adding a feature, we must consider to what extent we are redefining the product, and how consistent its messages are with neighboring features.
1 This definition is purposely vague on some levels. I work in the domain of web applications, but I think similarly about desktop software, my iPod, the newspaper, and anything else I call “technology”.
2 Marshall McLuhan stated this more succinctly when he said, “The medium is the message”.
You start with a problem that needs to be solved, then define a solution to the problem. The product is a concrete implementation of a that solution. Features should always be viewed within the context of the problem(s) that needs to be solved.
I like where you are going with this feature ecology approach, very interesting.
As producers, we are always motivated by some problem or interest. I’m taking that as a given, but focusing on some ideas that can help us better understand what we produce.
I’ve long been fascinated by media studies and also surprised by software practitioners’ lack of interest in it, since we are rapidly producing new forms media. This is my attempt at fostering some interest within our community and synthesizing lessons from both fields.
“It reminds us to be aware of the behaviors we wish to evoke in our users.”
This is the most interesting part.
I’ve often thought that the real goal behind any app isn’t to make the computer do something, but to make the people using the computer do something.
We have all of these metaphors – files, tabs, etc – that engineers have used to frame technology in terms of daily life.
But look at most really successful technologies, and you’ll find that people have adapted to its unique logic.