Butterf.log

Comments (View)

Karma?

There’s another dimension of a person’s participation in an event - intention.

  • If I run into someone walking around the corner and someone else comes to help us and those two people get married, I am essential, but I had a neutral intent.
  • If I see someone I don’t like and I punch them and someone comes over to help and they get married, I had a selfish intent.
  • If I want two people to meet so I run into one of them as a ploy for the other person to be helpful, I have a sacrificial intent.

If we assign intent to a person’s association with an event, you can see their impact on the world as a function of altruism. Does it pay to be naughty, to be nice, or to just be?

If there’s a way to assign the positive/negative impact of an event (tough, because it’s in the eye of the beholder), you could even see how much good each of your sacrifices create, or vice versa.

Cool!

Comments (View)

Important vs. Essential

Say you’re talking to an old coworker at a party. Another person you know walks by, and you decide to introduce the two. You never see those people again, but they end up getting married and having a kid that invents the cure for AIDS.

On butterf.ly, you get just as much credit for the AIDS cure as its inventor, or the inventor’s parents. Traditionally, we give all the credit to the man or woman at the end of a chain of events, the one that triggers a milestone like curing AIDS. Butterf.ly, however, deals in one simple question: who is essential for an event to have occurred? If you hadn’t introduced those two people, they wouldn’t have had a child that cured AIDS, so you are essential.

Essential is binary. Something is, or it isn’t. Something can’t be more essential than something else. It is also transitive. If I am essential to an event, I am also essential to all the effects of that event, or what we’re calling “downstream” events.

Comments (View)
Another option for data entry is to show a Twitter-style timeline, with links to add cause/effect to each event in the timeline.  Clicking on the link will put the event’s id in the text field with an arrow pointing in the appropriate direction.

The big problem here is that it isn’t really intuitive… we’re probably going too far into geek-land.  Too bad there’s not an intuitive & short permalink for events.

Another option for data entry is to show a Twitter-style timeline, with links to add cause/effect to each event in the timeline. Clicking on the link will put the event’s id in the text field with an arrow pointing in the appropriate direction.

The big problem here is that it isn’t really intuitive… we’re probably going too far into geek-land. Too bad there’s not an intuitive & short permalink for events.

Comments (View)
Comments (View)
v1

v1

Comments (View)

Abuse & Permissions

Because everything is interconnected, content ownership would make things miserable. For example, if someone enters “Andrew Mason and John Doe hosted a poker game,” who owns it? John? Me? Both of us? What if John doesn’t know my email address (so I’m never formally linked to the event), then how do I claim ownership? It’s a mess.

Here’s a simple approach: anyone can edit anything (an aside: I suppose events act as wikis…?). We can put contribution floors on certain types of actions - for example, in order to edit someone else’s action, you must first post a certain number of events.

We can also have a “report abuse” function with a simple rule: for every abuse report, someone’s account will be terminated. If the abuse is valid, the accused loses their account. If not, you lose your account. If we can’t decide, you both lose your accounts. Such harsh rules will make people think twice about abusing the system.

Comments (View)

Don’t think we should spend too much time getting the interface right before we code a prototype. Inevitably, we’ll want to change it once we start using it… so we should design just enough to make something usable.

Comments (View)

Tree diagrams (and other visual structures) are indispensable for structuring data, but more often than not, they’re not the most useful way to display it to a human. You still have to navigate the tree and connect the dots to get your answer. They’re useful when you don’t know what you’re looking for, I guess. In the case of butterf.ly, though, for any given event, you probably want to know:

  • What other events wouldn’t have happened without this event
  • The people whose lives were effected by this event
  • The people without whom the event wouldn’t have occurred
  • etc.

I think it’s far more useful to offer lists of that information as a primary interface than a tree that leaves the hunt to the user.

Comments (View)

As I hash out the butterf.ly interface, I’m finding myself lifting a lot of stuff from Twitter. I think that’s a good thing - interface isn’t where we want to innovate. If there are good design patterns out there, it’s less work for everyone to just use them.

Although the sites are very different, they are similar in the sense that most of your time is spent reading and writing short text snippets.

Comments (View)