[LJ] friend groups
May. 27th, 2005 10:08 amOne 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?
(no subject)
Date: 2005-05-27 04:06 pm (UTC)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. :-)
(no subject)
Date: 2005-05-30 04:50 pm (UTC)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...