> [email protected] writes:
> >Me, three. Which brings up a feature request which I submitted to
> >Support, so presumably the people combing Support for good ideas will
> >find it, but I figure I'd plug it here.
>
> >It would be really cool if sets of filters could be user-defined such
> >that membership of a trusted/watched user was required of
> >one-and-only-one filter. This could be done entirely at the interface
> >layer for managing groups and adding/modifying friends
> >(watchees/trustees), and be implemented by a convention that uses a
> >prefix and a dot to group filters.
>
> I don't like it, but I think you're trying to solve the same problem I
> want to solve with a different, never quite articulated feature req:
I want to solve a simpler problem than yours. Yours is more flexible,
but as with so many technologies it gets that flexibility at the
expense of simplicity. Myself, I don't particularly want to
mix-and-match filters on the fly, I want pre-sets like on a radio
dial. "All people not in these other filters" is useful to me only to
manually check to make sure I haven't orphaned someone, and I'd rather
the system take the initiative for validating my input instead of
making me check.
Do you realize in your example, you have an implicit additional
Root-level Watchlist, which turns it almost (but not quite) into my
example? Factoring this in an exclusive system like I proposed:
> Root-level Watchlists:
> Close Friends
> Loud Friends
> Comics
>
> Actual desired readlists:
> 1 Comics # this I'll always read
> 2 CLose Friends # catchup list
> 3 Loud Friends # timekiller
> 4 all-(Loud Friends+Comics) # normal non-comics read-list
> 5 all-(Loud Friends+Comics+Close Friends)
> # for when I've caught up, and want to skim the non-loud, non-close
> # friend posts I missed.
We get:
Root-level Exclusive Watchlists:
Close Friends
Loud Friends
Comics
Everybody else
Actual desired readlists:
1 Comics
2 Close Friends
3 Loud Frinds
4 Close Friends + Everybody Else
5 Everybody Else
Which is computationally much easier to achieve, and because it's
managed at the group-management interface it doesn't further thrash
the server on page render. Excepting 4, everything you want you can
get under what I've described, and 4 only requires viewing two
watchlists at once, which I expect would be simpler to implement than
exclusion at the page render.
> As it is, to get #4, which is my -normal- readlist, I need to maintain
> a separate "non-comics" filter that has all my close friends -plus-
> anyone I want to normally read. And sometimes I make mistakes and
> someone isn't on that filter and I don't read them and wonder why.
Right, which is why I propose multiple exclusive categories, instead
of all these tedious binary choices.
> Moreover, to get #5, I'd have to do even more work, and maintain a
> "non-comics - close friends" filter. I don't, making fill-in reading
> after a catchup far more of a chore.
Oh, right. Add to previous: User can specify group default for friend
add. So when you add a new watchee, you *have* to assign them to one
of Close Friends, Loud Friends, Comic, or Everybody Else -- and if you
don't specify, it defaults to adding them to, say, Everybody Else (or
whichever one you picked as the default for the group).
-- Siderea
_______________________________________________
dw-discuss mailing list
[email protected]
http://lists.dwscoalition.org/cgi-bin/mailman/listinfo/dw-discuss
