LJSV-1068

[kareila]

LJ just unveiled two features I've wanted here but haven't known how to implement, which are a tag list on the update page, and searching for multiple tags using AND instead of OR.

For the first, am I to assume that the new update page will support this, so we don't need to bother with trying to patch the feature into the old update page? Or perhaps rather that the new update page won't support it immediately, but it will be such a radical change that we shouldn't even bother working on it until then? (I really want this ASAP, and it has appeared on "most wanted".)

For the second, should we roll our own fix adopting LJ's URL syntax, or attempt a codemerge? Here's the syntax for those who missed the announcement:

http://username.livejournal.com/tag/tag1,tag2?mode=and
http://username.livejournal.com?tag=tag1,tag2&mode=and

The URL syntax was what bogged us down on that bug, and this seems like a reasonable solution, plus it's what users of both sites will come to expect.

Links to our Bugzilla:

http://bugs.dwscoalition.org/show_bug.cgi?id=581 (for the tag list)
http://bugs.dwscoalition.org/show_bug.cgi?id=1585 (for multiple tag search)

Comments

[cesy]

The last I heard on the tag list was that we should hold off until the new update page, though you could quite easily take part 2 out of my patch and part 1 could go straight into the site as it is, as a stop-gap solution.

[kareila]

Hmm, I looked at your patch and it looks like it only works for personal journals (it calls gettags($remote)). I know what the tags in my personal journal are; it's when I'm posting to communities that I want a list of tags in that community handy. :)

[cesy]

Ah, yes, quite possibly. I was thinking mainly of personal journals when I wrote it, and I can't remember testing it for communities.

[kareila]

If it's any consolation, it looks like LJ didn't think of that use case either. :)

http://news.livejournal.com/127833.html?thread=85464153&format=light#t85464153

[msilverstar]

argh, that gets us into teaching Boolean operators to people :-/

I much prefer the terms "ALL" and "ANY"

[cesy]

I think "AND" and "OR" are just as descriptive as "ALL" and "ANY" for a non-techie user, and considerably more useful for a techie or mathmo user.

[jazzfish]

In my depressing and frustrating experience, non-techies tend to assume "OR" means "boolean XOR" and "AND" means "boolean OR" (the logic is something like "I'm looking for X, and I'm also looking for Y"), and then get upset when there isn't any option to search for "only things that have both X and Y."

[msilverstar]

depressing and frustrating, yes

[jazzfish]

+1

I'd be happy to see "and" and "or" available as alternatives, in the same way that [lj user=] is an alternative to [user name=], but "all" and "any" are far more intuitive.

(end tech-writer / usability-guy-by-default rant)

[cesy]

I wouldn't object to them being there as alternatives, I suppose, though I'd still rather have "and" and "or" as the standard ones.

[kareila]

We could possibly codemerge LJ's support for AND, and subsequently add our own support for using ALL as an alias. (OR/ANY would remain the default behavior.)

[msilverstar]

Alternative usage is good, GUI is good, nice FAQ with examples are good.

Just, any time you use Booleans, explaining is hard

[sophie]

+1!

I prefer "all" and "any" too - it really, really is more intuitive. "and"/"or" are bad for the reasons jazzfish mentioned above. I hope that if we have this, these would be the standard.

[foxfirefey]

Looks like there are some issues that'd need to be addressed by them or us before we'd want to take them up:

http://news.livejournal.com/127833.html?thread=85543001&format=light#t85543001
http://news.livejournal.com/127833.html?thread=85464153&format=light#t85464153
http://news.livejournal.com/127833.html?thread=85473113&format=light#t85473113
http://news.livejournal.com/127833.html?thread=85486425&format=light#t85486425
http://news.livejournal.com/127833.html?thread=85488473&format=light#t85488473

[kareila]

Yes, of course we'd want to wait for any bugs to be ironed out in their implementation before pulling it in, if we decide to go that direction.

[matgb]

I hate the LJ syntax for the URL. My rule of thumb is if I can't remember it, most people won't, and I can't remember that, or indeed security filtering or date checking my friends page.

It's the ?mode=and bit that'll throw most people, if we can figure out a way of bumping the operator that isn't broken due to existing allowed characters, we're good.

I see from the bugt that no one has managed this, but, y'know.

I do think though that allowing the LJ syntax makes sense, but as a redirect to something that doesn't actually suck.

[aveleh]

me too. If we're going to lean toward keeping the commas, I want something like this:

http://username.dreamwidth.org/tag/and/tag1,tag2

(with aliases, etc.)

[afuna]

Oh, that looks fairly neat.

[pauamma]

I'd run this through suggestions first. (And personally, I'd favor a GUI generating the appropriate URL, because any/all/and/or are all English-specific. This would also sidestep the "which is clearer?" debate neatly.)

[kareila]

I didn't think the question of whether or not to do a codemerge from LJ was appropriate for suggestions. Any followup refinements, certainly.

[alierak]

GUI +1. URLs should be meaningful but not be your primary UI.

[afuna]

A GUI sounds good; that way we don't have to worry so much about the URL format, yes.

[deborah]

GUI +1

[afuna]

I prefer one of the forms in Bug 1585. Which, hm. I guess this is a good place to bring up to see what people like.

[kareila]

I didn't see any suggestions there that didn't invoke characters that we can't use, because they're allowed to exist in tags. The idea of continuing to use comma separation, but toggling the meaning of the join from OR to AND, appealed to me.

[afuna]

The characters, if meant ot be used as ilterals in the tag, will need to be escaped. (So to avoid breaking existing tag urls, we'd need to set up new urls, then have the current tag urls redirect to the new tags, with characters suitably escaped, if necessary)

[kareila]

Ah, I see. In that case, it sounds like we would want to roll our own, and continue to support LJ syntax via a redirect.

It also sounds like the kind of thing that's really hard to do correctly. :x

[afuna]

Hmm. I think it's actually easier, long-term, since it's just a couple of characters that need being redone. We'd need to make sure to reserve the characters early on, though. (Maybe have extras?)

I prefer characters (, and +, - ) to the AND/OR stuff since there's shorter and there's less confusion, but yeah *g*

(I'm kinda distracted so I hope that I'm making sense!)

[kareila]

So comma = OR, + = AND, - = AND NOT? We'd also have to reserve ? and & since that's standard GET syntax, but presumably the current code already does that.

[afuna]

Hmm, well that matches existing syntax. Not sure about ? and & -- or rather, if there is a & but no ?, then it's okay. But the & should be escaped anyway (but escaping & is pretty standard, IIRC)

[alierak]

Don't forget + is already a URI escape character for space.

[afuna]

In the arguments, so /tag/a+b isn't a space, but ?tag=a+b is a space

(Or was it the other way around?)

[mark]

I'd rather wait for the new update page than update the existing one. I should ask fu what the timeline is for that, as I'm not sure.

We could probably take the implementation for AND-tags (maybe, I haven't looked at it) but I don't like that syntax much. I definitely think the GUI suggestion is a good one, but we should also have a URL that is memorable and easy enough for people who want to do so.

[kareila]

Thanks for weighing in. For some reason this comment didn't show up in my email, though. Weird.