You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@forrest.apache.org by Jeff Turner <je...@apache.org> on 2003/05/15 14:18:02 UTC
What are tabs? (Re: how to use a subdirectory)
On Thu, May 15, 2003 at 08:30:59AM +0200, Nicola Ken Barozzi wrote:
>
...
> >I assume we want to implement this click-menu-to-expand behaviour in
> >Forrest.
>
> Yes, but what's the point with tabs?
>
> >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".
> >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.
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. 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?
--Jeff
> --
> Nicola Ken Barozzi nicolaken@apache.org
> - verba volant, scripta manent -
> (discussions get forgotten, just code remains)
> ---------------------------------------------------------------------
>
Re: [USER POLL/VOTE] Defining tabs?
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Jeff Turner wrote, On 28/05/2003 11.20:
> On Tue, May 27, 2003 at 03:10:42PM +0200, Nicola Ken Barozzi wrote:
>
>>Jeff Turner wrote, On 27/05/2003 12.29:
>>
>>>On Mon, May 26, 2003 at 04:49:33PM +0200, Nicola Ken Barozzi wrote:
> ...
>
>>>Now we've got this node. We need to discover the associated tab.
>>
>>Wait a sec... eh? I mean, that node *is* the associated tab, no?
>>
>> <tab sitepath="about/download"/>
>>
>>means we find in site.xml the node
>>
>> //site/about/download
>>
>>and render from there all the below elements.
>
> Yes, but that's not the problem. The problem is, how do we know we're in
> the about/download tab? We have to infer the current tab from the
> current path.
>
> Say our current path is "about/download/binaries/index.html". This path
> belongs to the "about/download" tab. How can we know that? What's the
> algorithm in tab2menu.xsl?
Ahh, ok, *that's* what I was missing! 8-)
Theorically, the two solutions are roughly equipollent, as we can make
that the xpath to the site.xml node is equivalent to pointing via an id.
So the info is there.
Hmmm, but this is really tricky. The fact is that we have to make a page
that may not be in site.xml fit there nevertheless, so to be able to
resolve the tab it applies to.
The algorithm to look for a node with which to resolve the tab would
look something like this:
1 - search if the page has a tag in site.xml -> got it
2 - else search if there is a node that has a dir that is in
the path of the file
3 - else simply do not highlight any tab
Or something between these lines. Still not useful for an impl? I know,
but I haden't thought of this issue yet, that is that pages are not all
listed in site.xml.
In any case, I'm confused why your approach would solve the issue, as we
still can have pages that are not in tabs.xml or in site.xml...
> Anyway, just to clarify: technical details aside, I agree with what
> you're suggesting for tabs; it's just that the only implementation I can
> see is an under-the-covers emulation of the @tab-in-site.xml solution.
Yup, I've understood that, but thanks anyway for clarifying :-)
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: [USER POLL/VOTE] Defining tabs?
Posted by Jeff Turner <je...@apache.org>.
On Tue, May 27, 2003 at 03:10:42PM +0200, Nicola Ken Barozzi wrote:
>
> Jeff Turner wrote, On 27/05/2003 12.29:
> >On Mon, May 26, 2003 at 04:49:33PM +0200, Nicola Ken Barozzi wrote:
...
> >Now we've got this node. We need to discover the associated tab.
>
> Wait a sec... eh? I mean, that node *is* the associated tab, no?
>
> <tab sitepath="about/download"/>
>
> means we find in site.xml the node
>
> //site/about/download
>
> and render from there all the below elements.
Yes, but that's not the problem. The problem is, how do we know we're in
the about/download tab? We have to infer the current tab from the
current path.
Say our current path is "about/download/binaries/index.html". This path
belongs to the "about/download" tab. How can we know that? What's the
algorithm in tab2menu.xsl?
Anyway, just to clarify: technical details aside, I agree with what
you're suggesting for tabs; it's just that the only implementation I can
see is an under-the-covers emulation of the @tab-in-site.xml solution.
--Jeff
> --
> Nicola Ken Barozzi nicolaken@apache.org
> - verba volant, scripta manent -
> (discussions get forgotten, just code remains)
> ---------------------------------------------------------------------
>
Re: [USER POLL/VOTE] Defining tabs?
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Jeff Turner wrote, On 27/05/2003 12.29:
> On Mon, May 26, 2003 at 04:49:33PM +0200, Nicola Ken Barozzi wrote:
...
>>in tab.xml
>> <tab sitepath="about"/>
>> <tab sitepath="about/download"/>
>> <tab sitepath="getting-involved"/>
>> <tab sitepath="documentation"/>
>>
>>Basically, what I mean is that it's not necessary to use ids, we can use
>>an xpath to site.xml instead.
>
> It sounds nice. Keeps everything to do with tabs in the tabs file.
>
> I can't see how to implement this though.
Let's see...
> Thinking it through..
>
> Step 1) We get given a path (say 'foo/faq.html')
>
> What can we do with this, other than use it to look up a node in
> site.xml? So..
Nonono, I don't want to give it a path, but a site.xml link!
It's
<tab sitepath="about/download"/>
==
<tab url="site:about/download"/>
> Step 2) We find the node //*[@href='foo/faq.html']
>
> Now we've got this node. We need to discover the associated tab.
Wait a sec... eh? I mean, that node *is* the associated tab, no?
<tab sitepath="about/download"/>
means we find in site.xml the node
//site/about/download
and render from there all the below elements.
Am I still missing something?
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: [USER POLL/VOTE] Defining tabs?
Posted by Jeff Turner <je...@apache.org>.
On Mon, May 26, 2003 at 04:49:33PM +0200, Nicola Ken Barozzi wrote:
>
>
> Jeff Turner wrote, On 26/05/2003 14.30:
>
> >On Mon, May 26, 2003 at 01:54:49PM +0200, Nicola Ken Barozzi wrote:
> ...
> >>Wouldn't it work equally well if we simply show the children of a
> >>site:xxx link in tabs.xml instead of the dir ones? It would even be less
> >>changes for the users, but maybe I'm missing something.
> >
> >Sorry I'm not following. "children of a site:xxx link in tabs.xml"?
>
> Sorry, I mean that if tabs.xml has a site:x/y/z link, then all the
> children of the //x/y/z element are the ones shown.
>
> Example from ours
>
> site.xml:
> <site ...>
> <about label="About">
> ...
> </about>
> <getting-involved label="Getting Involved">
> ...
> </getting-involved>
> <documentation label="Documentation">
> ...etc
>
>
> in tab.xml
> <tab sitepath="about"/>
> <tab sitepath="about/download"/>
> <tab sitepath="getting-involved"/>
> <tab sitepath="documentation"/>
>
> Basically, what I mean is that it's not necessary to use ids, we can use
> an xpath to site.xml instead.
It sounds nice. Keeps everything to do with tabs in the tabs file.
I can't see how to implement this though. Thinking it through..
Step 1) We get given a path (say 'foo/faq.html')
What can we do with this, other than use it to look up a node in
site.xml? So..
Step 2) We find the node //*[@href='foo/faq.html']
Now we've got this node. We need to discover the associated tab.
And here's the problem: the implementation demands that the site.xml node
reference the tab, not the other way round. <tab sitepath="..."> can
only ever be a fiction for the benefit of users. Underneath, there will
have to be something like the @tab system I've hacked up.
Or so it seems..
--Jeff
> --
> Nicola Ken Barozzi nicolaken@apache.org
> - verba volant, scripta manent -
> (discussions get forgotten, just code remains)
> ---------------------------------------------------------------------
>
Re: [USER POLL/VOTE] Defining tabs?
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Jeff Turner wrote, On 26/05/2003 14.30:
> On Mon, May 26, 2003 at 01:54:49PM +0200, Nicola Ken Barozzi wrote:
...
>>Wouldn't it work equally well if we simply show the children of a
>>site:xxx link in tabs.xml instead of the dir ones? It would even be less
>> changes for the users, but maybe I'm missing something.
>
> Sorry I'm not following. "children of a site:xxx link in tabs.xml"?
Sorry, I mean that if tabs.xml has a site:x/y/z link, then all the
children of the //x/y/z element are the ones shown.
Example from ours
site.xml:
<site ...>
<about label="About">
...
</about>
<getting-involved label="Getting Involved">
...
</getting-involved>
<documentation label="Documentation">
...etc
in tab.xml
<tab sitepath="about"/>
<tab sitepath="about/download"/>
<tab sitepath="getting-involved"/>
<tab sitepath="documentation"/>
Basically, what I mean is that it's not necessary to use ids, we can use
an xpath to site.xml instead.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: [USER POLL/VOTE] Defining tabs?
Posted by Jeff Turner <je...@apache.org>.
On Mon, May 26, 2003 at 01:54:49PM +0200, Nicola Ken Barozzi wrote:
>
> Jeff Turner wrote, On 26/05/2003 12.44:
>
> >On Mon, May 26, 2003 at 09:04:05AM +0200, Nicola Ken Barozzi wrote:
> >...
> >
> >>What Jeff has proposed is the best IMHO. It can accomodate a skin that
> >>allows tabs to show things at the skin's wish. We'll see if the impl
> >>will be nice enough for users.
> >
> >
> >I have something implemented locally:
> >
> > - Any site.xml node can have a @tab attribute.
> > - @tab attributes are like namespaces: they are inherited by child
> > site.xml nodes unless overridden by a child's @tab.
> > - tabs.xml <tab> elements can now have a @id identifier.
> > - When rendering tabs, book2menu.xsl will render as "selected" the <tab>
> > whose @id is equal to the site.xml @tab.
>
> It basically makes tabs work as now, but using the site.xml structure
> instead of the directory structure.
Yes, it's just a different tab selection mechanism.
> Wouldn't it work equally well if we simply show the children of a
> site:xxx link in tabs.xml instead of the dir ones? It would even be less
> changes for the users, but maybe I'm missing something.
Sorry I'm not following. "children of a site:xxx link in tabs.xml"?
> >So, pretty simple and generic.
> >
> >As for the
> >are-tabs-bookmarks-or-containers debate, it becomes a one-line change in
> >tabutils.xsl, which I'll parametrize and set to 'containers' by default.
>
> Excellent.
>
> >Will commit tomorrow'ish..
>
> TIA
>
> What about the tabs.xml-site.xml dichotomy? Could we just make it so
> that if tabs.xml is not defined, we can instead use a <tabs/> section in
> site.xml?
Sounds good. It follows the general pattern established by site.xml
overriding book.xml.
--Jeff
Re: [USER POLL/VOTE] Defining tabs?
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Jeff Turner wrote, On 26/05/2003 12.44:
> On Mon, May 26, 2003 at 09:04:05AM +0200, Nicola Ken Barozzi wrote:
> ...
>
>>What Jeff has proposed is the best IMHO. It can accomodate a skin that
>>allows tabs to show things at the skin's wish. We'll see if the impl
>>will be nice enough for users.
>
>
> I have something implemented locally:
>
> - Any site.xml node can have a @tab attribute.
> - @tab attributes are like namespaces: they are inherited by child
> site.xml nodes unless overridden by a child's @tab.
> - tabs.xml <tab> elements can now have a @id identifier.
> - When rendering tabs, book2menu.xsl will render as "selected" the <tab>
> whose @id is equal to the site.xml @tab.
It basically makes tabs work as now, but using the site.xml structure
instead of the directory structure.
Wouldn't it work equally well if we simply show the children of a
site:xxx link in tabs.xml instead of the dir ones? It would even be less
changes for the users, but maybe I'm missing something.
> So, pretty simple and generic.
>
> As for the
> are-tabs-bookmarks-or-containers debate, it becomes a one-line change in
> tabutils.xsl, which I'll parametrize and set to 'containers' by default.
Excellent.
> Will commit tomorrow'ish..
TIA
What about the tabs.xml-site.xml dichotomy? Could we just make it so
that if tabs.xml is not defined, we can instead use a <tabs/> section in
site.xml?
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: [USER POLL/VOTE] Defining tabs?
Posted by Jeff Turner <je...@apache.org>.
On Mon, May 26, 2003 at 09:04:05AM +0200, Nicola Ken Barozzi wrote:
...
> What Jeff has proposed is the best IMHO. It can accomodate a skin that
> allows tabs to show things at the skin's wish. We'll see if the impl
> will be nice enough for users.
I have something implemented locally:
- Any site.xml node can have a @tab attribute.
- @tab attributes are like namespaces: they are inherited by child
site.xml nodes unless overridden by a child's @tab.
- tabs.xml <tab> elements can now have a @id identifier.
- When rendering tabs, book2menu.xsl will render as "selected" the <tab>
whose @id is equal to the site.xml @tab.
So, pretty simple and generic. As for the
are-tabs-bookmarks-or-containers debate, it becomes a one-line change in
tabutils.xsl, which I'll parametrize and set to 'containers' by default.
Will commit tomorrow'ish..
--Jeff
> >PS. The fact that red and green does not mix together well does not mean
> >that we should removed both colors. :-)
>
> ;-)
>
> --
> Nicola Ken Barozzi nicolaken@apache.org
> - verba volant, scripta manent -
> (discussions get forgotten, just code remains)
> ---------------------------------------------------------------------
>
Re: What are tabs? (Re: how to use a subdirectory)
Posted by Juan Jose Pablos <ch...@che-che.com>.
Jeff,
web site so users will use tabs for Jeff Turner wrote:
>>Is there anywhere where there is a definition of tabs?
>
>
> tabs2menu.xsl :) But exactly what tabs2menu.xsl is trying to achieve is
> not defined anywhere.
I think that a definition (After Nicola's Poll) should be added to the
web site on http://xml.apache.org/forrest/linking.html so users knows
what tabs are for.
>>I agree with this,tabs are tabs and should not be used instead of a
>>horizontal menu.Tabs needs to be defined, so would be useful to add this
>>to site.xml?
>>
>><tabs>
>><tab href="site:comunity:howto"/>
>></tabs>
>
>
> Or the attribute equivalent:
>
> <site>
> <community ...>
> <howto label="How-To" tab="true"/>
> ...
But then, if you want to add a another feature to a tab, how would you
do it?
Re: What are tabs? (Re: how to use a subdirectory)
Posted by Jeff Turner <je...@apache.org>.
On Fri, May 16, 2003 at 03:18:20PM +0200, Juan Jose Pablos wrote:
> Jeff,
>
> >I'm not creating the concept. It already exists, which is why we have
> >tabs.xml, and why it is separate from book.xml.
>
> Is there anywhere where there is a definition of tabs?
tabs2menu.xsl :) But exactly what tabs2menu.xsl is trying to achieve is
not defined anywhere.
> >This is the model I think Forrest is currently implementing. 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?
>
> I agree with this,tabs are tabs and should not be used instead of a
> horizontal menu.Tabs needs to be defined, so would be useful to add this
> to site.xml?
>
> <tabs>
> <tab href="site:comunity:howto"/>
> </tabs>
Or the attribute equivalent:
<site>
<community ...>
<howto label="How-To" tab="true"/>
...
--Jeff
Re: What are tabs? (Re: how to use a subdirectory)
Posted by Nicola Ken Barozzi <ni...@apache.org>.
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)
---------------------------------------------------------------------
Re: [RT] Generalizing tabs (Re: [USER POLL/VOTE] Defining tabs?)
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Jeff Turner wrote, On 16/05/2003 17.13:
...
> In RT mode for a second, how about adding another option:
Aaarggg ;-PPPP
> 3 - A tab is a visual flag indicating some property of the current page
>
> Typically, we think of menus containing pages. How about if, instead, we
> consider the page's top-level menu as a _property_ of that page? So all
> manual/*.xml files have a 'classification' property with value "User Manual".
>
> Why bother with this weird inverted thinking? Because we can represent
> _other_ properties as tabs too:
<snip>awesome ascii art</snip>
> Visually, most of these tabs would be tiny things off to the right of the
> tab bar. We would want to fit more than one 'tabset' in the tab bar.
> We'd want the category and format tabsets on by default.
>
> Implementation
> --------------
>
> Currently, tabs2menu.xsl takes the current page path, and uses this as a
> 'key' to lookup the current tab in tabs.xml.
>
> We can generalize this quite simply: instead of doing the lookup in
> tabs.xml (containing just 'classification' metadata), do the lookup on a
> dynamically generated site.xml, which contains metadata for every file:
>
> <site>
> <index label="Index" href="index.html"
> format="html">
> xml:lang="en"
> applies-to="C2.1"
> review-status="draft"
> classification="home"/>
> ....
>
> Much of those site.xml attribute can be generated on the fly from page
> <meta> tags. The real thing would probably be RDF.
>
> We would need a schema (RDFS? RNG?) declaring the possible attribute
> values for our page metadata. We'd need that to know, for example, that
> 'draft' is part of the set {draft, published, obsolete}.
Since we do have meta tags in xhtml2, it's very easy to think that we
can add these items to the page.
The question is: why show them as tabs? More below.
> So we've got an XML source of page metadata. tabs2menu.xsl opens this,
> looks up the current page's node, and displays some aspect of this
> metadata as a set of tabs.
No flaws here. You are right, the presentation can decide to do as you
say, it's correct.
> Implications
> ------------
>
> Instead of having to POLL/VOTE for the One True Meaning of Tabs, we
> define a mechanism by which tabs can represent a variety of things,
> including a variety of classification models. To treat tabs as
> bookmarks, just write a tabs-as-bookmarks.xsl. For tabs that correspond
> to top-level menus, write a tabs-as-toplevelmenus.xsl. We can do both
> and see which works best.
Ok, put it this way, we are on the same page, with additional features I
really like, in your RT.
You see, I think tabs are top-level menus, you have another idea. Well,
if we can implement both and have users be able to decide is ok with me,
if done like you say, and also getting metadata stuff too.
I also can use both, as I can include "my" tabs as normal tabs and other
meta info as a combobox, or back and forward buttons for navigation
(they are standard xhtml2 meta tags).
You are basically proposing to switch the burden -fully- to the
rendering engine, which is exactly what I want :-)
But the discussion of the poll is still somewhat relevant, as Forrest
will come with a default "skin" behaviour, so we have to decide what
that is. From this quick poll it seems that the tabs-as-containers is to
be tried as the default for now, but I'd also like other flavors to be
available and switchable easily by the user with a property somewhere.
So, trying to recap:
+1 to making site.xml be transformed to include page-level metadata
+1 to making site.xml be transformed to include dir-level metadata
+1 to making site.xml be transformed to include site-level metadata
+1 to making tabs-as-containers the default behaviour of Forrest for
now
+1 to making it easily switchable by the users
+1 to making a poll/vote on this before the next release
Good idea Jeff, I like it :-D
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
[RT] Generalizing tabs (Re: [USER POLL/VOTE] Defining tabs?)
Posted by Jeff Turner <je...@apache.org>.
On Fri, May 16, 2003 at 03:28:36PM +0200, Nicola Ken Barozzi wrote:
>
> We have seen that there are different interpretations about what tabs
> are, so we need to just decide what forrest thinks they are.
>
> Tabs can be seen as:
>
> 1 - shortcuts to certain parts of the site, as tabs in a book
> 2 - containers of separate parts of a site, as tabs on file folders.
In RT mode for a second, how about adding another option:
3 - A tab is a visual flag indicating some property of the current page
Typically, we think of menus containing pages. How about if, instead, we
consider the page's top-level menu as a _property_ of that page? So all
manual/*.xml files have a 'classification' property with value "User Manual".
Why bother with this weird inverted thinking? Because we can represent
_other_ properties as tabs too:
- Page Format:
,-----._____._____
__________________/ HTML | PDF | XML \___
|
| Some Documentation
| ------------------
|
- Page language:
,---.____.____
__________________/ en | de | fr \_________
|
| Some English Documentation
| --------------------------
|
- Applicable Software version:
,______,------.__________
________________/ C2.0 | C2.1 | C2.2-dev \____
|
| Doing XYZ in Cocoon 2.1
| -----------------------
|
- Page status:
,------.___________.__________
________________/ draft | published | obsolete \____
|
| Some Draft Documentation
| ------------------------
|
- Page Review status:
,-----------._______________.____________________
______/ Unreviewed | Peer reviewed | Committer reviewed \____
|
| Some Wiki Documentation
| ------------------------
|
And our primary use-case:
- Page classification (menu):
,-----._________._________
__/ Home | Manual | Samples \____
|
| Some Draft Documentation
| ------------------------
|
Visually, most of these tabs would be tiny things off to the right of the
tab bar. We would want to fit more than one 'tabset' in the tab bar.
We'd want the category and format tabsets on by default.
Implementation
--------------
Currently, tabs2menu.xsl takes the current page path, and uses this as a
'key' to lookup the current tab in tabs.xml.
We can generalize this quite simply: instead of doing the lookup in
tabs.xml (containing just 'classification' metadata), do the lookup on a
dynamically generated site.xml, which contains metadata for every file:
<site>
<index label="Index" href="index.html"
format="html">
xml:lang="en"
applies-to="C2.1"
review-status="draft"
classification="home"/>
....
Much of those site.xml attribute can be generated on the fly from page
<meta> tags. The real thing would probably be RDF.
We would need a schema (RDFS? RNG?) declaring the possible attribute
values for our page metadata. We'd need that to know, for example, that
'draft' is part of the set {draft, published, obsolete}.
So we've got an XML source of page metadata. tabs2menu.xsl opens this,
looks up the current page's node, and displays some aspect of this
metadata as a set of tabs.
Implications
------------
Instead of having to POLL/VOTE for the One True Meaning of Tabs, we
define a mechanism by which tabs can represent a variety of things,
including a variety of classification models. To treat tabs as
bookmarks, just write a tabs-as-bookmarks.xsl. For tabs that correspond
to top-level menus, write a tabs-as-toplevelmenus.xsl. We can do both
and see which works best.
Thoughts?
--Jeff
Re: [USER POLL/VOTE] Defining tabs?
Posted by "Nathaniel G. Auvil" <na...@yahoo.com>.
something like this:
...
<tabs>
<tab label="Home" dir="">
<menu>
<about label="About">
<index label="Index" href="index.html"/>
</about>
<community label="Community" href="community/">
<index label="About" href="index.html"/>
</community>
</menu>
</tab>
<tab label="Sample" dir="samples/">
<menu>
<about label="About">
<index label="Index" href="index.html"/>
</about>
</menu>
<tabs>
<tab label="All" dir="all/">
<allCharts label="All Charts" href="allCharts/">
</tab>
...
</tabs>
</tab>
where the tab selection determines what menu shows up. Although, this example takes it to another
level and lets you embed tabs inside of tabs.
--- Nicola Ken Barozzi <ni...@apache.org> wrote:
>
> Juan Jose Pablos wrote, On 16/05/2003 17.20:
> > Nicola,
> >
> > 2
> > but the tab itself does not contain the links, the links are define in
> > site.xml. The tab just selects.
>
> Do the navigation iems on the left contain other navigation items, or
> just select?
>
> A tab can be a shortcut or a container of links, but now it's a mix of
> the two.
>
> --
> Nicola Ken Barozzi nicolaken@apache.org
> - verba volant, scripta manent -
> (discussions get forgotten, just code remains)
> ---------------------------------------------------------------------
>
=====
http://nathaniel-auvil.blog-city.com/
__________________________________
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo.
http://search.yahoo.com
Re: [USER POLL/VOTE] Defining tabs? [OT]
Posted by Clay Leeds <cl...@medata.com>.
Sorry to dirty your inboxes with a bit of humor, but I just thought the
freudian dyslexia (?) was a bit apropropos... check out the sub-node of
<site> below... hehehe...
On 5/17/2003 2:34 AM, Nicola Ken Barozzi wrote:
> Juan Jose Pablos wrote, On 16/05/2003 19.04:
>> Nicola,
>> The Navigation items on the left contain other items that belong to
>> that selection:
>>
>> <tab href="site:community"/>
>>
>> <site>
>> <commutiny>
>> <foo1/>
>> <foo2>
>> <foo2.1/>
>> </foo2>
>> <foo3/>
>> </commutiny>
>> </site>
...
> I hope I was clear now.
--
Clay Leeds - cleeds@medata.com
Web Developer - Medata, Inc. - http://www.medata.com
PGP Public Key: https://mail.medata.com/pgp/cleeds.asc
Re: [USER POLL/VOTE] Defining tabs?
Posted by Juan Jose Pablos <ch...@che-che.com>.
Nicola,
>>> <tab href="site:community"/>
>>> <tab href="site:foo2"/>
>> what I like from the tabs was that you were allow to select only the
>> navigation links relative to that directory.
>
> Which is conceptually wrong, as the navigation is not necessarily
> dependant on the dir layout, but on the link layout in site.xml.
Sorry, I did not mean directory, I wanted to say site element that is
why I used site:whatever on the description on the top
>> but do you have to write down again all the links you want for the
>> navigation links on the left? if you do it like that, what is tab
>> diferent from menu?
>
>
> IMV it's not different. Each tab in this view should have its own set of
> menus.
Even if you have you own set, they should be a reference, I would not
like to write down the same information again.
> What Jeff has proposed is the best IMHO. It can accomodate a skin that
> allows tabs to show things at the skin's wish. We'll see if the impl
> will be nice enough for users.
we will see that tomorrow. but I think that it is closer to what I am
saying..
Re: [USER POLL/VOTE] Defining tabs?
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Juan Jose Pablos wrote, On 20/05/2003 3.21:
> Nicola,
>
> I fell so bad, I got the feeling that I did not get your proposal right.
mp.
>> Of course. But look at this:
>>
>> <tab href="site:community"/>
>> <tab href="site:foo2"/>
..
>>
>> What I like to see is either that both tabs contain the full menu on
>> the left, or that each has it's own separate share of links.
>
>
> what I like from the tabs was that you were allow to select only the
> navigation links relative to that directory.
Which is conceptually wrong, as the navigation is not necessarily
dependant on the dir layout, but on the link layout in site.xml.
> but do you have to write down again all the links you want for the
> navigation links on the left? if you do it like that, what is tab
> diferent from menu?
IMV it's not different. Each tab in this view should have its own set of
menus.
What Jeff has proposed is the best IMHO. It can accomodate a skin that
allows tabs to show things at the skin's wish. We'll see if the impl
will be nice enough for users.
> PS. The fact that red and green does not mix together well does not mean
> that we should removed both colors. :-)
;-)
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: [USER POLL/VOTE] Defining tabs?
Posted by Juan Jose Pablos <ch...@che-che.com>.
Nicola,
I fell so bad, I got the feeling that I did not get your proposal right.
> Of course. But look at this:
>
> <tab href="site:community"/>
> <tab href="site:foo2"/>
..
..
> You will get two tabs, one of which is a superset of the other. So tabs
> do *not* contain items *exclusively*.
I understood that,but I thought that you wanted to create another level
of tabs to avoid this type of situation so foo2 should go under a
community tab, something like a sub-tab or whatever.
>
> What I like to see is either that both tabs contain the full menu on the
> left, or that each has it's own separate share of links.
what I like from the tabs was that you were allow to select only the
navigation links relative to that directory.
but do you have to write down again all the links you want for the
navigation links on the left? if you do it like that, what is tab
diferent from menu?
PS. The fact that red and green does not mix together well does not mean
that we should removed both colors. :-)
Re: [USER POLL/VOTE] Defining tabs?
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Juan Jose Pablos wrote, On 16/05/2003 19.04:
> Nicola,
> The Navigation items on the left contain other items that belong to that
> selection:
>
> <tab href="site:community"/>
>
> <site>
> <commutiny>
> <foo1/>
> <foo2>
> <foo2.1/>
> </foo2>
> <foo3/>
> </commutiny>
> </site>
>
> The tab exclude anything on the menu that does not belong to that.
Of course. But look at this:
<tab href="site:community"/>
<tab href="site:foo2"/>
<site>
<commutiny>
<foo1/>
<foo2>
<foo2.1/>
</foo2>
<foo3/>
</commutiny>
</site>
You will get two tabs, one of which is a superset of the other. So tabs
do *not* contain items *exclusively*.
What I like to see is either that both tabs contain the full menu on the
left, or that each has it's own separate share of links.
I hope I was clear now.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: [USER POLL/VOTE] Defining tabs?
Posted by Juan Jose Pablos <ch...@che-che.com>.
Nicola,
The Navigation items on the left contain other items that belong to that
selection:
<tab href="site:community"/>
<site>
<commutiny>
<foo1/>
<foo2>
<foo2.1/>
</foo2>
<foo3/>
</commutiny>
</site>
The tab exclude anything on the menu that does not belong to that.
Nicola Ken Barozzi wrote:
>
> Juan Jose Pablos wrote, On 16/05/2003 17.20:
>
>> Nicola,
>>
>> 2
>> but the tab itself does not contain the links, the links are define in
>> site.xml. The tab just selects.
>
>
> Do the navigation iems on the left contain other navigation items, or
> just select?
>
> A tab can be a shortcut or a container of links, but now it's a mix of
> the two.
>
Re: [USER POLL/VOTE] Defining tabs?
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Juan Jose Pablos wrote, On 16/05/2003 17.20:
> Nicola,
>
> 2
> but the tab itself does not contain the links, the links are define in
> site.xml. The tab just selects.
Do the navigation iems on the left contain other navigation items, or
just select?
A tab can be a shortcut or a container of links, but now it's a mix of
the two.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: [USER POLL/VOTE] Defining tabs?
Posted by Juan Jose Pablos <ch...@che-che.com>.
Nicola,
2
but the tab itself does not contain the links, the links are define in
site.xml. The tab just selects.
Nicola Ken Barozzi wrote:
>
> We have seen that there are different interpretations about what tabs
> are, so we need to just decide what forrest thinks they are.
>
> Tabs can be seen as:
>
> 1 - shortcuts to certain parts of the site, as tabs in a book
> 2 - containers of separate parts of a site, as tabs on file folders.
>
> In case 1 the links on the navigation are not contextualized, and the
> tab is just a link, not a container. In case 2, each tab contains its
> own set of navigation links.
>
> Current implementation is a mixture of the two, where the tabs are just
> links but nevertheless contextualized.
>
> So, users and devs, what do you prefer tabs to be?
>
> [] 1 - shortcuts to certain parts of the site
> [] 2 - containers of separate parts of a site
> [] 3 - exactly as now
>
> I just vote -1 for option 3, and any in 1 or 2 are fine for me.
>
[USER POLL/VOTE] Defining tabs?
Posted by Nicola Ken Barozzi <ni...@apache.org>.
We have seen that there are different interpretations about what tabs
are, so we need to just decide what forrest thinks they are.
Tabs can be seen as:
1 - shortcuts to certain parts of the site, as tabs in a book
2 - containers of separate parts of a site, as tabs on file folders.
In case 1 the links on the navigation are not contextualized, and the
tab is just a link, not a container. In case 2, each tab contains its
own set of navigation links.
Current implementation is a mixture of the two, where the tabs are just
links but nevertheless contextualized.
So, users and devs, what do you prefer tabs to be?
[] 1 - shortcuts to certain parts of the site
[] 2 - containers of separate parts of a site
[] 3 - exactly as now
I just vote -1 for option 3, and any in 1 or 2 are fine for me.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: What are tabs? (Re: how to use a subdirectory)
Posted by Juan Jose Pablos <ch...@che-che.com>.
Jeff,
> I'm not creating the concept. It already exists, which is why we have
> tabs.xml, and why it is separate from book.xml.
Is there anywhere where there is a definition of tabs?
> This is the model I think Forrest is currently implementing. 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?
I agree with this,tabs are tabs and should not be used instead of a
horizontal menu.Tabs needs to be defined, so would be useful to add this
to site.xml?
<tabs>
<tab href="site:comunity:howto"/>
</tabs>