LiveJournal Business Discussion

We've just changed the term "Friend of" on user information pages to a more appropriate label "Read / Trusted by". This change is temporary, and will only last until we've completed work on splitting up the current friends idea into more of a read/trust system.

This is related to the GoatVote poll posted yesterday, but it isn't our final decision on the matter. We're still reading each position and discussing our policy with each other.

Revionist History: We changed it back in light of a new discussion in lj_biz

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?
Open to: All, detailed results viewable to: All, participants: 1947

Are you FOR or AGAINST the above proposal?

What URL supports the AGAINST position?

What other URL supports an AGAINST position?

Just to clear things up, the options first voted on aren't being discared in light of the new lj_biz post.

The new post was just meant to summarize the problem statement, and propose a variation of an elegant solution people were advocating.

The use of the optional "Show mutual friends and my friends only, not friend-ofs" display mode does not mean we can't also do individual friend-of hiding via banning or otherwise. The point of the new post was just to explain that there were really two issues: the relationship confusion vs. the display confusion.

We're also thinking this option would be nice:

[ ] Hide inactive friend-ofs

So then people who list you as a friend and haven't used their account in any way for 6 months don't show up.

So the best solution is probably all three:

1) optional alternate display mode
2) optional hide inactive friend-ofs
3) banning users removes them (but if you have to do this often enough, option 1 might be best for you, with hiding friend-ofs)

So please relax... we're not imbeciles over here, and we don't actively ignore user comments for fun. There's a lot to read, and knee-jerk fixes won't fix anything... we want to understand the real problems and implement solutions that will actually work.

I'm going to go enjoy the weekend, but we'll all get on this all next week. None of the code to implement these are hard at all. (Corollary: offering code won't motivate us to bypass the design phase) It's design/policy that's hard, and all this lj_biz discussion has helped with that a ton. Thanks for all the constructive comments!