Re: [Scrollkeeper-devel] Category Trees

[Dan M. <d-...@uc...>]

On Sat, 25 Nov 2000, Ali Abdin wrote:

> * Dan Mueth (d-...@uc...) wrote at 01:48 on 25/11/00:
> > 
> > On Fri, 24 Nov 2000, Laszlo Kovacs wrote:
> > 
> > > How do we deal with category trees? I see category trees as generic
> > > empty content lists.
> > > 
> > > These are the possibilities we discussed:
> > > 
> > > 1. Enforce a category tree and ignore all docs that don't fit into it.
> > > 2. Enforce a tree and put all docs that don't fit into an Other section
> > > of the Content List.
> > > 3. Supply a tree (installed) and OMF files come with new categories,
> > > extend the Categories in the Content List with them (don't modify the
> > > category tree).
> > > 4. Recommend a set of categories on the project web site, but don't
> > > supply any tree. Build the content list(s) from whatever comes in the
> > > OMF files.
> > > 5. Don't recommend any categorization, but keep support in the OMF files
> > > to specify categories. Extend the Content List with whatever comes in
> > > the OMF files.
> > > 
> > > 1. and 5. are there for completeness only. I suppose nobody thinks they
> > > would be a way to go.
> > > 
> > > So what do people think? Which is the best way to do it? Any other
> > > ideas?
> > 
> > One more:
> > 6) Support more than one of the above and allow the user/SA to decide
> > which one method is employed in /etc/scrollkeeper.conf or
> > $HOME/.scrollkeeperrc.
> > 
> > One other issue which should be discussed for options #1-#3 - What do we
> > do with empty parts of the tree?  Do we show branches that don't have
> > documents in them?  Or are these branches only created as they get
> > populated?   I think the assumption right now is that empty branches
> > exist and are passed to the browser.  (The browser could still potentially
> > snip them out.)
> 
> I disagree. I do not think it is worth the complexity to actually let the user
> choose.
> 
> You will also confuse system administrators, and desktop users who are not
> sure of which setting to you use.
> 
> I prefer method 4. If somebody has a reason why we should NOT use number 4,
> please say why? ;)

My concerns were:

1) We want to have some configurability on the part of the SA or
user.  This basically means removing branches or adding branches.  For #4,
adding branches is trivial.  We could potentially provide another
mechanism for removing branches in place of specifying the tree, so #4
could still work here.

2) Things becoming a mess.  If we use #4, we would still need to provide a
really good tree on the web page and strongly encourage people to use it
unless their document really doesn't fit into the existing scheme.  Even
in this case, they should suggest that the tree be extended in addition to
creating their own branch in their OMF file.  If we do provide a really
good tree and most people follow it, then we should be okay.  We will need
to track down people who have blatently duplicate existing sections in
other positions than the existing sections.  It only takes a few people
doing this to produce a very confusing and inconsistant interface for the
user. I really don't want to see 9 different places for the GIMP in the
tree ;)

3) Typos and variations on translations.  Unless we do #2, we will always
get spurious duplicated branches from these.  

Given this, #4 seems like a reasonable solution. The people I've spoken
with about this so far seem pretty much split between #4 and #2.  #2
guarantees that concerns (2) and (3) above do not become real problems.  
Of course it has a couple of its own problems to contribute such as the
need to keep your contents list categories up-to-date and make the central
list well-managed and respected (we have to do that anyway though or even
with #4 we will be screwed.)

The difference between this and #3 is that #3 will have empty branches.  
I haven't decided whether I think this is a good thing or a bad thing.  
If the tree on the web page is huge and has large sections which are
frequently empty, it may be best not to have them. 

Does anybody have an opinion on this?

Dan