Re: [Scrollkeeper-devel] Category Trees

[Ali A. <ali...@au...>]

* Dan Mueth (d-...@uc...) wrote at 03:43 on 27/11/00:
> 
> 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.

You don't need to "remove" or "add" branches within scrollkeeper. It will all
be queried at runtime.
 
> 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 ;)

I think that if people "do their own thing" that proves that the Category tree
provided is somehow ineffective (confusing? too many duplicates? etc.) 

I seriously doubt people will just "do their own thing" because they just feel
like it...Actually, on second thoughts, I recommend we DO distribute a
Category list and scrollkeeper-install should provide a "warning" if it is not
ine one of the "suggested" list of categories! (otherwise people will be too
lazy to go to the website to look it up!)

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

This is interesting (translations of categories). My vote: don't translate the
category. (this is the same as saying don't translate the XML tags)
 
> 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?

Empty branches suck. They are wasteful.