Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [platform-help-dev] identifying views

Dorian, you touched on something that is very intriguing...user defined
views. It would be pretty powerful to give users the ability to
build/customize their own TOC, picking either individual topics or groups.
It would need to be simple to update, like adding a bookmark in your
browser, and then editing and moving them around. Not all users would take
advantage of it, so help providers would still need to provide a logical
TOC.This would just put a bit more power into the user's hands.

Thanks, Jeanette

--------------------------------------------------------------------------------

Jeanette Deupree
ID Manager & Lead, WebSphere Studio Application Developer
 RTP NC
919-254-1149 (tieline 444-1149)
deupree@xxxxxxxxxx



                                                                                                                      
                    Dorian                                                                                            
                    Birsan/Toronto/IBM@IBMCA        To:     platform-help-dev@xxxxxxxxxxx                             
                    Sent by:                        cc:                                                               
                    platform-help-dev-admin@e       Subject:     Re: [platform-help-dev] identifying views            
                    clipse.org                                                                                        
                                                                                                                      
                                                                                                                      
                    11/20/2001 06:48 PM                                                                               
                    Please respond to                                                                                 
                    platform-help-dev                                                                                 
                                                                                                                      
                                                                                                                      



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





Back to the top