[ZDP] Keywords and Categories: Discussion based on Use Cases

[Rik Hoekstra]

Perhaps this is just a bit off-topic, but

Sometimes the answer you are looking for is not in any topic you might
think of when you have the question.

As an example, I see often that people want to know if a thing is of a
particular type:

Q.  How do I know if a thing is a list so I can work around the "Strings
are not allowed as input to the in tag" error?

Ordinarily, if one has not read the list archives, the answer is a bit
of an epiphany:

A.  You don't.  Make sure it is a list by using <select multiple
name="myselect:list">.

One would not ordinarily look in "Zope HTML extensions" to find this bit
of wisdom, because the context is "handling variables returned from a
form".

Two things:

1.  Assure that sibling ideas like the above are accessible one from the
other; use hypertext for what is is really good for.  (And let the book
publisher figure out how to put it in print)


[RH]Of course

2.  I prefer Tables of Contents that relate to what I am trying to do.
I would like to see: "Using select lists", which would walk me through
creating the list to displaying it to doing something with its output,
showing the special pitfalls of multiple selects.  I would not like to
see a TOC with "Zope in HTML Forms" and "<dtml-in>" and "Python lists",
because I would have to somehow zen that these are all related to my
usage of a multiple select.


[RH] Now, that is going to be difficult. Unless, perhaps (I hope) you mean a
table of contents should show the more specific content (read: the title) of
the items instead of just the category/keyword table of contenst, which is
obvious (to me ;-)). And of course there should be a full-text searching,
also per category (or is this asking too much)

So, summarizing, that leaves us with 4 levels of access (in a presenter case
as opposed to use case ;-) order):

1. Per category - what do we as ZDP think the information belongs to
2. Per title - what does the author (editor) think the item is about
3. Per keyword - what does the author/editor think the item also belongs to
4. Per full text search - boiling down to: what does the user want from the
information
    This could be refined to full text search per category (or whatever):
what does the user
    think/hope is in the information.

This last item (4) is also a case for logging full-text searches: they give
a clue what people want to know, and where and how they think they can find
it.

Rik