[LJ] friend groups

[cellio]

There are some aspects of using, and particularly editing, LJ friend groups (aka filters) that are kind of frustrating, and maybe some of you can help me refine these thoughts enough that I could post usefully to suggestions.

One problem, acknowledged by the LJ folks for years now, is that a single mechanism is used for two different purposes. A friends group might serve as access control, specifying who can read a locked post. Alternatively, a group might serve as a reading filter, specifying which journals you want to read at a given time.

If you read a lot of journals, you may find it useful to partition the list so that you can read subsets at different times. For example, I've collected syndicated feeds into their own group; there is no point in looking at most of those a second time (to pick up comments). I've collected the "news" communities (such as lj_maintenance) into a group; there are times when I want to get "the latest LJ news" by itself. I've partitioned everything I read into managable batches so that if I have limited time I can read well-defined subsets of my list. (That said, most of the time I just read my friends page, but if, say, I've been away for a week, that isn't so practical.)

That last use points to a feature I would really like to have: I want to declare a set of groups as mutually exclusive and (as a set) fully inclusive. That is, I want some automated assistance in ensuring that every journal, community, and feed that I read is in exactly one of these groups. The current interface allows you to edit the membership of a single group at a time, but gives you no information about other groups those users are in. In fact, there isn't even a way for me to ask "what groups have I put this user in?"; I have to step through the groups and look for the user's name in each of them.

Now let's talk about the other use of groups: access control. First off, if I'm defining an access list then syndicated feeds and communities are irrelevant; access groups are for people who can log in to LJ. However, since there's no way to tell LJ "hey, this is an access list", I get everything on the user list to edit. PITA. And not only that, but it's a single alphabetical list. At the very least, it would be nice if people, communities, and feeds were segregated in that list in the same way that they now are on the profile page. It used to be that your profile page just included "friends", which was a mix of these three types of content, and the "edit friend groups" interface was developed during that time. Now, however, you can tell at a glance which people, communities, and feeds a person reads, each in its own section, but the group-editing interface didn't keep up. Having those groupings available would make it easier to focus on just the people in an access list, and also make it easier to make sure that your "syndicated feeds" group contains all and only syndicated feeds, rather than just having to notice bill_walsh and geeketiquette in amidst ben_abuya and geekosaur, for example. (Note: you don't get those little icons when editing groups.)

One aspect of access control is that you might want a set of increasingly-restricted filters -- sort-of-trusted, trusted, really-trusted, and so on. In an ideal world, when you went to define "trusted" it would only show you the members of "sort-of-trusted" as a starting point. After all, you don't want to have someone on really-trusted who isn't a member of sort-of-trusted. There is no automatic support for this -- and again, because you can't inspect the group memberships of an individual user easily, checking for data-entry errors is hard. Oh, and those links should be dynamic; if I decide that someone is no longer trusted and I yank him from "trusted", if he was also on "really-trusted" he should be pulled from there too.

I'm kind of curious about whether other people share any of these desires. Or do you folks use groups in completely different ways?

Comments

[alice-curiouser.livejournal.com]

I am a Filter Whore.

I have all communities filtered by interest (ie craft groups, Jewish groups, diet groups) and out of my default veiw. This comes in handy, as my interests tend to be fairly obsessive, and they come and go. No need to scroll through all the scrapbook posts if I'm not really into it on a given day. :)

My default view is all individuals, which I have filtered by really-trust or general, as well as one for people that I know IRL, in case I want to post my addie or phone number or something. I also have Jewish and non, in case I want to post something that the Christians on my list might find offensive (not that I post that much offensive stuff, but some people are easily offended). I use the individual filters to post only, however; I read the default view friends list all together.

[alice-curiouser.livejournal.com]

There is no automatic support for this -- and again, because you can't inspect the group memberships of an individual user easily, checking for data-entry errors is hard. Oh, and those links should be dynamic; if I decide that someone is no longer trusted and I yank him from "trusted", if he was also on "really-trusted" he should be pulled from there too.

And in answer to your question, yes, I'd like to see this too.

[madfilkentist]

I haven't used anything like the full capabilities of friend groups, but I do have groups for people I want to follow regularly, people I don't want to follow quite so regularly, and people whose posts I can't stand reading but still want to give access to my own friends-locked posts. Well, something like that, anyway. :) I want everyone on exactly one of these lists, which sounds exactly like the mutually-exclusive/collectively-exhaustive partition you describe. Allowing the ability to move someone directly from one list to another would be a nice way to do this, and wouldn't enforce mutual exclusion on people who wanted friends on more than one list.

At some point I might want to set up filters for people to whom I want to admit deep dark secrets and other people on my friends list. (Not that I'd trust LJ security with really deep and dark secrets.) I haven't even studied that part of filtering yet.

[mortuus.livejournal.com]

I totally share all of those desires (except I don't use various levels of trusted, so that doesn't matter as much to me - I just have different categories). The thing that would probably be the easiest for lj to adjust, and which would make a big difference to me, would be to identify and segregate people, communities, and feeds on the filters page. It takes forever to go through the entire list, and it gets confusing very fast. But if all of your suggestions were implemented, I would love it. Their current filter interface basically works, but it is confusing, difficult, and takes forever to create the categories.

[cellio]

Allowing the ability to move someone directly from one list to another would be a nice way to do this, and wouldn't enforce mutual exclusion on people who wanted friends on more than one list.

Mutual exclusion can't be a global setting (per user) anyway. It would interact badly with access lists, for instance. So there'd need to be a way to say "this set of groups has this property", and users who don't want it just wouldn't use that feature.

(Not that I'd trust LJ security with really deep and dark secrets.)

Well, yeah. :-)

[dvarin.livejournal.com]

I do the levels of trust thing, so what I'd really like is just a way to include groups in other groups.

The other thing I'd really like it the ability to make one-off modifications of groups on the fly for individual entries. That is, if I'm making a post about a birthday party for Ulysses, I don't want to have to create a whole new group that's "all friends except Ulysses" and then delete it a week later, I want to say "This entry is visible to 'friends', with these exceptions: Ulysses [block], Ulysses's-friend-who's-not-mine [allow], Guy-who-can't-keep-secrets [block].
As an expansion on this, I'd like to be able to perform group subtractions as well as unions, like saying "This entry is visible to everyone in my list [People I've Met In Person] unless they're also in the list [Coworkers]". This is actually a group I'd use occaisionally, since it's nice to shield the identities of coworkers I complain about, but anyone else who works at Viz would have very little trouble figuring out who I'm talking about.

I don't use groups as reading filters at all, probably because I don't have enough people/communities on my friends list to make it worthwhile.

[cellio]

I'd like one-off group edits too. It would force them to store permissions differently, I suspect, so I don't know how likely it is. (I believe they currently store a group ID with a post, not a set of users. So if the membership of the group later changes, those people will see changes in what posts they can see.)

I'd also like to be able to use "and" and "not" in choosing access groups. It would be easier to define a list of coworkers and then say "not coworkers" than to maintain a list of everyone except coworkers. I assume you're currently doing the latter for when you want to vent about us. :-)

[jducoeur]

I'd like one-off group edits too. It would force them to store permissions differently, I suspect, so I don't know how likely it is.

I'd bet that you're correct here -- the particular strengths and weaknesses of the interface suggest that the data model just doesn't have that sort of richness yet. In particular, it might have a significant efficiency impact, since it requires them to do a lot more inspection on a message-by-message basis as they build friends lists.

In general, I agree with the points above, including the observation that this is really about including groups within groups. Trust per se is a special case: the general problem seems to be hierarchical groups. That's probably a significant data-model change, but one that would have a lot of beneficial effects for the power users. However, I suspect that many routine users would completely ignore it (that's my usual observation of how hierarchical groups work in most interfaces), so it's probably low priority for the LJ folks.

Actually, I wonder how they are prioritizing usability vs. functionality at this point. These fixes are pretty much entirely to make things easier to use in a powerful way, but none are really adding new functions to the system. I don't know if that's going to catch their attention right now, but it's probably worth making the suggestions...