DW Filter Mgmt: The Pointers

[codeswitcher.livejournal.com]

foxfirefey posted elsewhere:

So, the main bug for improving the filter management interface is this:

* Improve UI for Filter Management

Other bugs that will influence the controls of the revamp, I think, are

* Export of access (or subscription) filter lists
* Link to per-user access/subscribe filter changing on the filter page
* Inverse reading filters on the fly
* New filters from old
* import names from access filter to subscription filter
* Add a "locked" option to subscription filters
* Add more options to ratings on subscription filters
* Subscribe to tag from /manage/circle/add or manage/circle/edit -- modularity so we could put an interface on these pages easily is a great plus

This does not have to be part of the same interface but if we are capable of doing this so much the better:

manage/subscriptions/filters should not require JavaScript

So, what we need to do overall:

* Probably make mockups, even simple ones, of what different stages/actions on the interface do, and where they are
* Backend is Perl and Template Toolkit; frontend can be HTML5 with CSS and jQuery/jQuery-UI. We're trying to kill all the BML (about 45k lines to go of mashed up Perl, JS, CSS, and HTML)

I think actually implementing all of this is pretty heavy hitting stuff and way out of the scope of one development project, but UI/UX mockups and functional specifications to start from and feedback during implementation would be great.

I looked over on DW and you had a free account, which would be very inconvenient for seeing what extra subscription filtering options there are right now, so I've gotten you a paid account for a while.

Other incidental bugs for reading filters, just so you know what's also on the table:

* Subscription Filters: create a module to display them as links -- this will let people use a list of their filters in the modules areas. Pretty easy, I think I could do this one right after my other bug goes through, I've done modules before.
* Optionally allow readers to see the other members of a custom filter
* Improve filter error message -- now that we can have public filters, an improvement to the error page is timely, since we could list public filters and provide a login.
* console command to output membership in a custom filter

DW Filter Mgmt: ? Needful to know facts

[codeswitcher.livejournal.com]

1) What are the per-user maximums for:

a) Number of grantees?
b) Number of filters?
c) Number of tags?
d) Char length of usernames?
e) Char length of tags?

2) What are the three levels of NSFWness or whatever that feature does, "anything (show all content)", "safe or non-explicit", and "safe for work only"? Wait, is this the same thing as "Age Restrictions"? (I think I may be about to get offended. Is there controversy about this?)
a) Does it map to a setting per journal or per comment?
b) "Ratings" right? Is there a ratings icon? (Otherwise I'll just use the letter "R".)
c) Is there some abbreviated version of those lengthy descriptions? I need some concision in this interface.
d) There is no "NSFW only" option? Nobody wants porn filters?

3) "AND" tag subscriptions? Really? Are there people using this? Because it adds a lot of difficulty (to say nothing of confusing the poor end users) for what I suspect is not going to be a popular feature. I'm ready to be wrong, of course. But it would be great if we didn't have to support this.

4) I'm contemplating the extant filter management tool, and a current limitation is that you cannot subscribe to different tags at different Ratings levels for the same person. So, if you want to sub to Rhonda's snarry and wincest filters, but: (1) her snarry stuff is really explicit -- NSFW -- but it's no problem for you because it's pretty 'nilla, while (2) her roy/roy alternates between really dark h/c but not always, and you don't want to read the torture but do want to tune in when it's not triggery. So you want to sub to rhonda:snarry:all but rhonda:roy/roy:safeforworkonly.

The interface approach I'm thinking of would support doing this, kinda by accident. However, will the back end? Because if the back end won't support that, then I should do something to add that constraint to the front end.

Put another way: the Rating filter seems to modify the user, not the tags.

Which is a round-about way to say, I think I'd better have some idea how subscriptions are represented in the db. I was imagining a three-column hash table, user_id/tag_id/rating_id. Except maybe I'm imaging user_id/[array of tag_ids]/rating_id to handle the "AND" case. But in any event, with all three foreign key fields being many-to-many. Which on further contemplation is not what's happening?

5) What characters are not allowed in tags and might be used as delimiters?