forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicola Ken Barozzi <nicola...@apache.org>
Subject Re: What are tabs? (Re: how to use a subdirectory)
Date Thu, 15 May 2003 12:55:58 GMT

Jeff Turner wrote, On 15/05/2003 14.18:
> On Thu, May 15, 2003 at 08:30:59AM +0200, Nicola Ken Barozzi wrote:
> 
> ...
>>>So instead of redefining tabs as "top-level menus with special 
>>>behaviour",
>>
>>Ehm, they are "top-level menus with special *appearance*"
> 
> They physically eliminate anything from the menu not in the tab's
> directory, which is what I meant by "special behaviour".

Agreed.

>>>let's fix the real problem.  That then frees us to use tabs 
>>>as they were originally intended: as bookmarks to arbitrary locations in 
>>>the site.
>>
>>Ah, so this is what you intend? No wonder we don't understand each other.
>>
>>For me tabs are not links to arbitrary locations, and IIUC this is not 
>>the intention of Stefano either.
>>
>>Look here:
>>http://www.onjava.com/
>>
>>Top-level tabs are only there to fully contain a series of links. It 
>>fully contextualizes a series of links, as the navigation has links that 
>>fully contain another series of links.
>>
>>Also there are two series of "tabs". In other parts of the site, like 
>>here http://java.oreilly.com/, you have only one.
>>
>>Given this, I still fail to see what makes tabs and links on the left 
>>different. So as the ones on the left contextualize a series of links, 
>>so shoud tabs. Hence tabs are not bookmarks to arbitrary locations.
>>
>>KISS. Why introduce a visual clue (ie "tabs") in a logical navigation 
>>space, that can be presented in any way to the user? Whycreate a 
>>different concept?
> 
> I'm not creating the concept.  It already exists, which is why we have
> tabs.xml, and why it is separate from book.xml.

Bad wording from my part. Why *keep* a different concept? We have 
tabs.xml because we do not have hierarchical book.html, and so to keep 
the base book.xml equal to the others, a new descriptor was born. 
site.xml changes all this.

> AFAIU, Forrest tabs are modelled on physical paper book tabs: some pages
> have a sticking-out labeled bit which allows fast access to that section.
 >
> I take the name "book.xml" as a broad hint that the original author was
> thinking along these lines too.
>
> Book tabs are not _containers_, they are just markers.  I can add a new
> tab with a yellow sticky paper thing, anywhere I like.  Book tabs are
> independent of the Table of Contents.  There generally isn't a tab for
> every chapter.  Most books have no tabs.
 >
> This is the model I think Forrest is currently implementing.

Nope. The fact is that a tab on a book does not contain items, while the 
current tabs do!

Current tabs include items using the concept of a directory, I just want 
them to include the items in a site.xml part, exclusively.

> Nothing
> sacred about it, but what are the alternatives?  Make every top-level
> menu entry a tab?  Fine, that can be implemented easily in tabs2menu.xsl.
> But very soon, people will complain that they don't want a tab for every
> top-level entry, and you'll have to invent a way of excluding entries.
> This will end up as an inverse of tabs.xml: a file of exclusions, instead
> of inclusions.  Have we really gained much?

Wait a sec.
What I get from your post is that people want to:

  1 - decide which entries in the same level make into tabs
  2 - decide which entries to make into tabs, regardless
      of the level

In case (2), the problem is that a top level tab would contain part of 
the same links that a lower level tab has. This is very misleading, as 
Stefano has explained on this mailing list IIUC AFAIK. Tell me, where 
would I look for a certain page, in the top level navigation or the 
lower level? It's confusing as all tabs are visually on the same level.

So we should have only tabs on the same "level", ie we cannot have tabs 
of chapters and sub-chapters, because the chapter tabs contain links 
that are also in the subchapter tab.

But in case (1), how are they going to show the links that do not have 
tabs? Have the first tab show all navigation and the next ones only 
parts of it? But this violates point 2...

For me tabs are not markers but like the tabs on phisical file folders, 
as they *contain* a series of links. If we were to accept your 
reasoning, the navigation would never be contextualized.

Question to all: should left-hand side navigation links be fully 
contextualized by tabs, or always the same, even if folding?

I'm ok with either scenario, as long as we don't mix them.

-- 
Nicola Ken Barozzi                   nicolaken@apache.org
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)
---------------------------------------------------------------------


Mime
View raw message