Brad Fitzpatrick (bradfitz) wrote in lj_biz,
Brad Fitzpatrick
bradfitz
lj_biz

The friends situation, wrapping up

There have been a ton of great comments on the friends issue, and an equal or greater number of less-than-wonderful comments. However, even the more whiny comments shed a lot of light on what the perceived problems are, even if they didn't name it directly.

So, here are my conclusions:

We have two problems:
  1. Relations: There's currently only one relation type between users, "friend", and it means a lot of different things to different people. Currently when user A befriends user B it means:
    • User A wants to read user B. (unless user A has group "Default View" and doesn't include B)
    • User A includes user B in A's "friends-only" group, which is used by many security-related things:
      • friends-only posts (without a custom security filter, which people are generally too lazy to use)
      • friends-only visibility of certain info, todo list permissions, phone transcriptions, etc...
  2. Display: The second problem is letting users decide how to represent their outgoing and incoming "friend" relationships on their profile page (userinfo.bml). Because people befriend other users for so many different reasons, there's no one good display option that suits everybody. There's also a lot of confusion about what the word "friend" means, and even more confusion about what "friend-of" means, especially to people who haven't been on LiveJournal for years. Notably, one of our newest programmers for LiveJournal was confused about "friend-of" for a while after he started working.
Now, problem #1 regarding the type of relationships we are already working on changing, but it'll take more time. Solving problem #2 (Display) before doing problem #1 kinda sucks, but there's certainly demand, so we're going to try to do it. It's not so bad as long as we keep in mind how we'll transition from the display system now to the display system in the future.

Current relationship system
There exists only one edge: "A friends B" meaning A reads B and A puts B in A's "friends-only" security group. See above for details.

The display currently is:
  • Friends (can't hide)
  • Friend-of (may hide; but only all or nothing)
Based on recommended proposals, we're all liking the idea of offering this optional display method:
  • Mutual Friends (can't hide) -- these are people you list as friends that also list you back as a friend.
  • Other Friends: (can't hide) -- these are people you list as friends that don't list you back (we might just call this "Friends" instead of "Other Friends". Or maybe "My Friends").
  • Friend-of: (may hide; but only all or nothing) -- these are people that list you as friends, but you don't add them back. Note that this only means "incoming only" when you choose to use this display method. The classic display method still shows all friend-ofs.
Please note that:
  • This is an option that users can choose, if they think the alternate view represents their use of friend relationships better.
  • It will not be the default. Nothing will change for you by default.
  • This doesn't remove anybody from anybody's friends list. We're still only offering the same option: to hide incoming friend relationship edges from the friendee.
  • We are intentionally not saying "trusted by" or "read by" or "reading list" or "watched by" or "watching". Because:
    • Watched by/watching: seems stalkerish.
    • The future relationship system will include a real "reading" edge type, so we don't want to pollute the meaning of that word yet, when we're going to be introducing it in the future with real meaning.
  • We're not hiding or otherwise polluting the raw data that's available by other means (fdata, FOAF, directory search, etc.). The friend-of hiding (like currently) only affects that one person's userinfo.bml page, and not all the outgoing links of the people who are hidden.

Future relationship system
This is problem #1 in the list at top, but the one we're solving later. We'll be adding a new relationship that's purely reading, which may optionally be private.

That is, in the future there will most likely be:

Friend: -- unchanged from now
Read (public): -- you'll read the person, and they'll know, but they won't be in your friends-only security group
Read (private): -- you'll read the person, just like using a normal RSS aggregator, but they won't know.

But that comes later. Immediately the issue is solving the display system under the existing relationship system.

Poll #258674 GoatVote: for or against?

Are you FOR or AGAINST the above proposal?

For (no argument URL necessary)
1679(86.3%)
Against (list argument URLs below)
267(13.7%)

What URL supports the AGAINST position?

What other URL supports an AGAINST position?

Subscribe
  • Post a new comment

    Error

    Anonymous comments are disabled in this journal

    default userpic

    Your reply will be screened

    Your IP address will be recorded 

  • 1014 comments
Previous
← Ctrl ← Alt
Next
Ctrl → Alt →
Previous
← Ctrl ← Alt
Next
Ctrl → Alt →