[daisy] Navigation tree improvements ideas

[Marc Portier]

Bruno Dumon wrote:
> On Fri, 2006-09-01 at 14:23 +0200, Marc Portier wrote:
>> some random ideas on this:
>>
>> Bruno Dumon wrote:
>>> Hi,
>>>
>>> I'm trying to consolidate the ideas for things we would wish to do with
>>> navigation trees but are currently not possible. The result is below.
>>> We'll likely only implement a few of these things in the short term, but
>>> it's good to have a view on future requirements so that these can be
>>> considered in the current design decissions.
>>>
>>> * a new node type: 'separator': a non-clickable node, simply rendered as
>>> a separator line between two other nodes.
>>>
>>> * a new node type: 'title': similar to a group node, but doesn't have an
>>> ID of its own, hence it doesn't become part of the navigation hierarchy
>>> path and the URL in the browser. Since this node has no ID, it is not
>>> addressable and so even in contextualized mode it will include its
>>> children, though collapse/expand can still work client side.
>>>
>> what is the advantage over allowing that group at id is not filled, and
>> then handle the node as described?
> 
> It's really a completely different thing with a quite different
> behaviour, so I think a different tag would be more appropriate.
> 

yep, I started realizing that:

>> on the other hand, both 'separator' and 'title' seem to be not related
>> to anything the navigation component should actually know about?
>>
>> IIUC then these are more concerned with introducing placeholders for
>> styling to react upon? As such, introducing them inside the
>> node-language seems like opening the door to an endless list of requests
>> for possible new-node-types?
>>
>> >From this assumption I'd prefer an approach that keeps the navigation
>> more opaque to these kind of things:
>>
>> IDEA: introduce *one* extra unspecified 'node' that just gets
>> transferred over in an opaque way to allow any weird thing people might
>> be dreaming about,
>>
>> - we could of course sample it's use through providing the basic styling
>> effects in our default skin for the ones you mentioned above that get
>> introduced as
>>
>> <node type="separator" />>
>> <node type="title" title="i18n:my-title.label" />
>>
>> and would immediately allow the weirdest stuff that our navigation
>> component should never worry about
>>
>> <node type="my-hardcoded-type">
>>   <my-link href="...">whatever</my-link>
>>   <my-link href="...">whatever</my-link>
>>   <my-link href="...">whatever</my-link>
>>   <my-link href="...">whatever</my-link>
>> </node>
>>
>> <node type="google-search-box" />
>>
>> <node type="advertisements-from-server-xyz" />
>>
>> <node type="pictures-from-flickr" owner="flickraccount-name" />
>>
>> <node type="headlines-from-blog" feed-url="..."/>
>>
>> Hm, I think I can anticipate a response on these last referring me to
>> publisher-requests that should be pulling out different navtrees in
>> stead, while I think this is about allowing the nav-tree-editor to be
>> arbitrarily positioning these in his overall nav-tree, rather then him
>> needing to ask a more programming-type of guy to be changing
>> pubrequests, styling and whatnot ?
>>
>>
>> I might even get adventurous and place daisy-system links at arbitrary
>> positions in the nav-tree:
>>
>> <node type="daisy-search-box"/>
>> <node type="daisy-recent-changes"/>
>>
>> wdyt?
>> Just tell me if I'm overlooking some obvious mistakes in my reasoning...
> 
> If you follow this reasoning, you could start to consider the navigation
> tree as an arbitrary XML document with some tags in it that have a
> special meaning. Maybe I'm stretching it a bit, though first you talk
> about one generic 'node' tag and then you give an example with a
> 'my-link' tag nested in the generic node tag.
> 

yep,
I don't think you're stretching it further then I was :-)

> Still, it's an interesting idea that would offer a lot of flexibility.
> Just to play the role of the conservative side, I see some issues
> though:
> 
> - the navigation tree editor would not know about these new node types,
> it would need to become customizable through a schema to support the
> custom node types.
> 

yeah. making the editor assist in those in an extensible manner is a
challenge, for starters it would be quite ok for me if the editor could
just accept any attributes and content on this node (even require to
hand-type it in 'raw' mode)

> - possibly the navigation tree manager would need to know about the new
> node types too, if the implementation of the new nodes is more
> appropriate to be done over there (e.g. because they need contextualized
> behaviour)
> 

well, I think that was the distinction I was trying to make: nodes that
need to trigger something in the navigation manager should be specific,
all the others (passing through until they get styled) should be handled
with one catch all node

> - the navigation tree becomes less standard. If something like 'title'
> or 'separator' nodes are things that are useful to everyone, why not
> introduce them in the navigation tree language, with their clearly
> attached semantics?
> 
> - the navigation tree is an end-user tool, not a programmer's tool, so
> it should stay simple.
> 

well, this is the strongest argument for sure.
I agree.

> - none of your examples are really convincing ;-) (a search box in the
> middle of a navigation tree? flickr photos in the middle of a navigation
> tree? The feed include is a nice idea though)
> 

well yeah, you can blame me for having little imagination on a
Friday-afternoon, but I was thinking more about these kind of occurrences:

- "search this site" as on my blog: http://blogs.cocoondev.org/mpo/
- "small flickr image previews" as on Rik's : http://bruggen.com/
- "advertisements" as on Ugo's: http://agylen.com/

I know this kind of stuff is handled in styling and such, I was just
starting to dream that their relative position could be edited in the
navigation doc, rather then through reshaping your styling...

I agree these samples are not convincing material: it was rather the
other way around: if we had a node-hammer, the above questions could be
seen as node-nails :-)

anyways: I don't have specific needs (in the foreseeable future) for any
of the mentioned cases. It was more a food for thought kinda post (I
happen to know from close by how hungry your thoughts can become :-))


nevertheless, (and a bit off-topic):
Trying to be even more imaginative about these navigation-cases:

I am hoping somebody would eventually make something like a sitemap-like
(ajax enabled?) styling for a navtree-documents that could replace or
current non-styling as seen here: http://cocoondev.org/daisy/1

Still in hopeful mode I would expect that to look like different columns
in which you drill down towards leaf nodes, much like the the "java
browsing perspective" in eclipse [1] or even better fitting: the Apple
file browsing experience: [2]

[1] http://www.eclipse.org/screenshots/fullscreenGTK/JavaBrowsing-GTK.png
[2]
http://www.biostat.wisc.edu/bcg/categories/applications/macintosh_osx/screenshots/safari_plist.png

So in any case I'd like us to see navigation-tree documents become
materialized not only in the left-hand side of the screen :-) and I
assume such will automatically lead to even more requests for new
node-types?


> <snipped the drooling stuff/>
>>> * Make it possible to use a "mount point" or "base path" variable in
>>> link nodes. Currently to create link nodes to e.g. extensions URLs one
>>> needs to use absolute paths like "/daisy/...". The mount point variable
>>> would remove this hardcoded path.
>>>
>>> Actually we need two mount point variables:
>>>  - one for the global mount point
>>>  - one for the site
>>>
>>> I'd like to keep the navigation manager free from Daisy Wiki concepts
>>> like sites, so the second one could be name e.g. "contextPath".
>>>
>> dunno what this is about, example?
>> (isn't this also a complete styling/wiki-related issue?)
> 
> e.g. now to link to an extension you have to do
> 
> <link url="/daisy/mysite/ext/myextension"/>
> 
> and this could become
> 
> <link url="${mountPoint}/${contextPath}/ext/myextension"/>
> 
> How would you make this a styling issue? The link needs some way to
> indicate something needs to be put in front of the URL, and it seems
> like a good thing to introduce a standarised syntax for this.
> 

yep, thx for explaining, just didn't get it before

>>> * New attributes for link nodes:
>>>     - target: to open the link in a new window/frame/...
>>>     - method: get or post
>>>
>> giving that 'link' nodes don't really relate to daisy (or do they?),
> 
> They do relate to navigation trees, they are a common enough requirement
> to have them directly inside the navigation tree language. A bit like
> HTML versus XML I think?
> 

not sure, the chosen word 'relate' was probably giving the wrong message

as mentioned above the distinction I tried to make was between elements
in the navtree that are just copied over verbatim to the client to be
styled, and the ones that actually trigger some real navtree-magic
(mapping ids-to-url-paths, executing query-nodes...)

so I agree, they 'relate' to the nav-tree (to the extend that typically
people want them as leaf nodes in there) but to my knowledge they're not
actually and actively inducing any effect in the daisy machinery, are they?
(not more then the pass-through separator and title would be doing)

>>  why
>> not move this under my previous catch-all 'node' idea as <node
>> type="link"> as well?
>>
>>> That's it. Comments on the above are welcome, as well as other
>>> navigation feature wishes in order to complete the picture.
>>>
>> as hinted in my <node> samples, I think it would be nice if people could
>> have typical daisy-system-links referenced from arbitrary positions in
>> the navigation
>>
>> HTH,
>> -marc=

regards,
-marc=
-- 
Marc Portier                            http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at                http://blogs.cocoondev.org/mpo/
mpo at outerthought.org                              mpo at apache.org