Re: [platform-help-dev] identifying views

[robertsj@xxxxxxxxxx]

The mappings for primary TOC and subsequent sections seems OK to me. From
an IBM perspective, though, we still have the visual / help UI need to
separate different solution sets into primary TOCs, then only show / search
partial TOCs from there.

Think of this another way: we need a "TOC collection" level
view--regardless of what it's called. Call it a "bookshelf", if that makes
it clearer. In Eclipse 1.0, that's the pull-down menu for infosets.

Putting all of this into one primary TOC will simply get too complex, as
one solution after another offers different ways to chop up their
information.

So we simply need an affordance in the DHTML (or as an XSL style, as Dorian
mentions) that will let users select / browse the bookshelf / collection of
primary TOCs. The visual problem with the 1.0 drop-down is that it
effectively hides all the the other primary TOCs / infosets--and it doesn't
need to be modelled in the XML as it was.

I agree with Jeanette about users providing their own views / topic
arrangements--at some point we should probably give them

1. a way to annotate topics
2. a way to easily add their own topics and TOCs (this is probably a help
tools thought)

One of the issues with customers' control over information is an update
issue--what happens to their changes if a plugin changes?


- Jamie




Dorian Birsan/Toronto/IBM@IBMCA@xxxxxxxxxxx on 20/11/2001 06:48:29 PM

Please respond to platform-help-dev@xxxxxxxxxxx

Sent by:  platform-help-dev-admin@xxxxxxxxxxx


To:   platform-help-dev@xxxxxxxxxxx
cc:
Subject:  Re: [platform-help-dev] identifying views


Yes, we've been pretty vague about some of the infoset/infoview migration
issues, especially as people give those terms different meanings.
There are things that can be done now, and there are things that are not
there and we don't have all the input to make a decision on what to
provide.
What works now, is selecting one of the two types of mappings:
1. Treat infosets as the main containers, i.e. primary tables of contents,
and views as main topics in those tables. If an infoset is viewed as a
tree, then the first level nodes are the infoviews.
2. Ignore the infosets, and make the infoviews your primary tables of
contents. This will likely mean changing the infoview labels to something a
bit more descriptives, perhaps taking into consideration the infoset label
as well.

What we may want to do in the future, if not too complex, is understand the
need to have different views and what they are for, and perhaps add a
presentation layer (i.e. the necessary XML markup) on top of the existing
table of contents specification.
As Greg pointed out, tagging some TOC's or topics as "view" is one
solution. Another solution could involve a separate presentation files that
would define the "views" and associate the appropriate TOC's with them.
Both of these alternatives really involve a predefined structure that help
would understand. A different approach, given the current move towards a
browser based rendering of navigation, would be to allow for complete
customization of a TOC by providing some XSL styles, etc.

Related to the notion of views, we were also thing about providing some
built in mechanisms, that could provide a feature based view, i.e.
providing a filtering button on the help view to re-arrange topics based on
the plugins they were contributed from. There could be some other ways to
have built-in views, but I guess this is a bit different than allowing for
user defined views.

This is a great topic for discussion and we are only begining to think
about some of the issues.


-Dorian





                    "Greg Adams/OTT/OTI"

                    <Greg_Adams@xxxxxxx>            To:
platform-help-dev@xxxxxxxxxxx
                    Sent by:                        cc:

                    platform-help-dev-admin@e       Subject:
[platform-help-dev] identifying views
                    clipse.org



                    11/19/2001 12:51 PM

                    Please respond to

                    platform-help-dev









<Dorian>
I think the use of infoviews wasn't quite thought out well, and we need to
re-evaluate those decisions.
The current 2.0 navigation really deals with the data part, i.e. how to
build tables of contents, without much concern of how to render it. Next,
we will certainly need to consider how to render that information, and it
will help to gather as requirements and suggestions to find the right
balance between complexity and usefulness. For now, you may need to map the
views as first level entries (topics) in a table of contents. This leads
into the next question:
</Dorian>

JD> And if infosets are gone, will there be any way of titling a doc web?

<Dorian>
You can think of a primary table of contents as your infoset and I think
that's a fairly reasonable mapping between 1.0 and 2.0 navigation concepts.
</Dorian>


<Greg>

Jeanette, there are probably several options to "map views as first level
entries.". These include
a direct mapping, or a more explicit tagging (i.e. tag something as a
view). Dorian would it be worthwhile enumerating some of
the options so that someone like Jeanette who has an extensive doc web can
comment on
implications/applicability to her case? Perhaps example snipets would be
useful of each approach.

</Greg>


_______________________________________________
platform-help-dev mailing list
platform-help-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/platform-help-dev