Faceted Navigation

On Sat, 2010-12-18 at 13:44 +0000, Phil Bull wrote:
> Hi Shaun,
> 
> It looks good! Comments follow.
> 
> On Thu, 2010-12-16 at 13:26 -0500, Shaun McCance wrote:
> [...]
> > * There's no way to AND on cases or matches. For example, if I were to
> > change the Message Board example to have this:
> > 
> > <facet:tag key="tech" values="gtk webkit"/>
> > 
> > It would be displayed if you have either GTK+ or WebKit checked. Is it
> > useful to be able to display links only if all their tag values match?
> 
> I see that it could be useful. A relatively simple notation would be
> something like:
> 
> <facet:match key="gtk&webkit"/>
> 
> At least it would be obvious. " " is an implicit OR, "&" is explicitly
> AND. I guess you could implement all of the boolean operators (XOR,
> anyone?), but I don't like how complicated this would start to get.

Yikes. That could get crazy. Plus, it's only giving you a way to AND
matches (and then some). We have a list of lists of tags that match
a list of tags. That's three separate places where we could say "all",
"any", or "none". To do it on cases, we could do an attribute on the
choice element, like so:

<facet:choice key="tech" match="all">

Then that choice would only be true if each of its active cases matches,
but the matching of the cases would still be any<->any. Use case: "Show
me all the demos that teach me both GTK+ and Clutter". With the current
any-any-any scheme, checking GTK+ and Clutter shows you demos that teach
you one or the other or both.

Then there's specifying you want all of the target's tags to match, but
in any value of any case in the choice. I'm not sure what the best way
of marking that up is. Use case: There could be a "prereqs" tag to list
technologies you're expected to know. You check the technologies you
know, any only see the demos you're ready for. Maybe that can be done
as an attribute on the choice tag too.

The number of permutations here is obscene. I'd rather not force people
to take a course in mathematical logic to be able to do simple things.
If we could identify a core set of really useful behaviors, we could
just provide straightforward markup for them.

>  When
> you give people tools like this, they can start writing ugly, hacky
> code. Personally, I would like to see Mallard remain a clear,
> easy-to-read markup. Can facets perhaps remain as an extension
> namespace, separate from the basic Mallard spec?

Absolutely. A case could be made for putting the tags into the core
spec, because there are other things you could build off of it. (I'll
use it for Squawk, once I unshelve it.) But then, there's no reason
extensions can't build off of extensions.

But the facets pages, along with the matches and controls, will stay
in an extension. It's the reason extensions are possible, so we don't
have to grow Mallard to 400 elements to do everything everybody wants.

> > * There's only one type of selector here: non-exclusive multiple choice.
> > I could imagine others. Exclusive multiple choice (i.e. radio buttons).
> > Numeric ranges. On/off toggles (you might think you can do that with a
> > single case in a choice, but it's different). What do we need? Probably
> > we can just start with this and grow from it as needs arise.
> 
> Exclusive multiple choice would be a very sensible addition. It would be
> nice to have a processing tool like Yelp automatically choose a sensible
> default option based on environment variables (or similar) too. e.g. for
> Ubuntu, we now have to worry about whether the user is using the Unity
> shell or the standard GNOME 2.x shell. If they're running Unity, the
> Unity option should be chosen by default.

Aaaaaand that leads us back to conditional processing, though in this
case on a per-page (rather than per-block) level. Conditionals could
be mixed with facets to selectively show pages. But that's another
feature altogether.

Thanks for the feedback.

--
Shaun