incubator-ooo-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject svn commit: r1206297 [3/19] - in /incubator/ooo/ooo-site/trunk/content/framework: documentation/ documentation/devmanual/ documentation/filters/ documentation/filterui/ documentation/mimetypes/ documentation/others/ drafts/ proposals/ proposals/apply/ ...
Date Fri, 25 Nov 2011 20:02:33 GMT
Added: incubator/ooo/ooo-site/trunk/content/framework/proposals/apply/apply_button_spec.htm
--- incubator/ooo/ooo-site/trunk/content/framework/proposals/apply/apply_button_spec.htm (added)
+++ incubator/ooo/ooo-site/trunk/content/framework/proposals/apply/apply_button_spec.htm Fri Nov 25 20:00:55 2011
@@ -0,0 +1,266 @@
+	<META HTTP-EQUIV="CONTENT-TYPE" CONTENT="text/html; charset=iso-8859-1">
+	<META NAME="GENERATOR" CONTENT="StarOffice/5.2 (Win32)">
+	<META NAME="CREATED" CONTENT="20010105;8322800">
+	<META NAME="CHANGED" CONTENT="20010216;14322466">
+<P ALIGN=CENTER STYLE="margin-top: 0.42cm; page-break-after: avoid"><FONT FACE="SunSans-Heavy"><FONT SIZE=4 STYLE="font-size: 16pt">Proposal
+for the Use of an Apply Button in Dialogs</FONT></FONT></P>
+<P ALIGN=CENTER><FONT FACE="SunSans-Heavy"><FONT SIZE=4>Version 1</FONT></FONT></P>
+<P ALIGN=CENTER><FONT FACE="Times New Roman, serif">Date: February
+14<SUP>th</SUP>, 2001</FONT></P>
+<P ALIGN=CENTER>David Engen, Andrea Mankoski, Leyla Schroeder</P>
+<H2><B>User Problem Being Addressed</B></H2>
+<P STYLE="font-style: normal; text-decoration: none">These guidelines
+for the placement and functionality of a standard &quot;apply button
+set&quot; in dialog boxes have been developed to facilitate the
+process of finely adjusting objects within StarOffice / documents. The benefit is that users will be able to
+see their changes immediately reflected in the context of the
+document while the dialog box is still open. Users frequently want to
+make iterative changes to the selection, and if the dialog closes as
+each change is made, it is inefficient to re-open the dialog multiple
+<P STYLE="font-style: normal; text-decoration: none">The &quot;Apply
+button&quot; functionality was deemed as a necessary tool for the
+medium-skill to advanced-skill user to avoid tedious command
+repetitions and for efficiency. Because this functionality will
+replace several other button sets, it is important that while it
+helps with efficiency to the advanced user, it does not hinder novice
+or cross-over users.</P>
+<H2><B>Project Definition</B></H2>
+<P>The proposed guidelines set standards for the placement of a
+&quot;standard set of Apply buttons&quot; as well as the behavior of
+each of the buttons in the set. Inclusion and exclusion principles
+have been established to more clearly state when and when not to use
+this functionality. It clearly states what buttons should be included
+in the &quot;standard set of Apply buttons&quot;, what types of
+dialog boxes they should be used with, and their location and
+arrangement in those appropriate dialog boxes.</P>
+<P>In addition to guidelines for the use of the standard set of apply
+buttons, a non-exhaustive list of dialog boxes to which it might be
+useful to add the standard set of apply buttons has been included -
+these can be found in the Appendix. Dialog boxes in four modules of
+StarOffice / (Writer, Calc, Impress, Draw) were
+examined to see whether they warranted the Apply functionality.
+Because of the variation in conditions under which these buttons can
+be used, some dialog boxes were verified individually. All of those
+mentioned in this specification were found under the Format menus on
+the main menu bar of StarOffice v5.2. There is some overlap from
+module to module, but there are also dialog boxes that are
+<P>In summary, this report provides inclusion and exclusion
+guidelines, button configuration and behavior guidelines, scenario
+descriptions, and screen-shots of some of the dialog boxes that may
+be affected by the implementation of this functionality.</P>
+<H2><B>Related and Competitive Products</B></H2>
+<P>StarOffice v5.2 used several variations of an Apply button without
+any apparent standardization measures, and this functionality is not
+new. Some examples of programs that have already implemented similar
+functionality are: for Windows Display and Desktop Themes (Start -
+Settings - Control Panel - Display/Desktop Themes); and for GNOME the
+Panel Properties dialog. This dialog shows a button set with <SPAN STYLE="background: transparent">&quot;OK&quot;,
+&quot;Apply&quot;, &quot;Close&quot;, &quot;Help&quot;, t</SPAN>hough
+in the desktop's Control Center <SPAN STYLE="background: transparent">(Main
+Menu Button - Programs - Settings - Desktop - Panel) </SPAN>you can
+find a set with <SPAN STYLE="background: transparent">&quot;Try&quot;,
+&quot;Revert&quot;, &quot;OK&quot;, and &quot;Cancel&quot;.</SPAN></P>
+<P STYLE="margin-bottom: 0cm"><B>Note:</B></P>
+<P STYLE="margin-bottom: 0cm">The Assign button that can be found in
+several dialog boxes in StarOffice / Draw (i.e. Format
+- 3D Graphics) is not dealt with in this HCI Specification. It is
+suggested that when the behavior of those Assign buttons is identical
+to that of the Apply button, the mouse-over tip for the assign button
+be changed from &quot;Assign&quot; to &quot;Apply&quot; to avoid
+confusion. Otherwise, the name of this command should be changed to
+something less ambiguous.</P>
+<H1><A NAME="Main"></A>Basic Functionality</H1>
+<P>It is recommended that dialog boxes employ the standard set of
+apply buttons: &quot;OK&quot;, &quot;Apply&quot;, &quot;Reset&quot;,
+and &quot;Close&quot;. Because it is also useful to be able to find
+contextual help from each of those dialog boxes, the standard button
+set will also include a &quot;Help&quot; button. The buttons order
+and layout can be seen in Figure 1.</P>
+<BR><B>Figure 1:</B> This is what the button layout and order should
+be for dialog boxes that require the standard set of apply buttons. 
+<P>The buttons should be aligned along the bottom of the dialog boxes
+in question and should be referred to as &quot;the standard set of
+apply buttons&quot;. Their behavior is as follows:</P>
+	<LI><P STYLE="margin-bottom: 0cm">When a user clicks the OK button,
+	the settings should be saved and the commands specified in the
+	dialog box should be carried out. The dialog box should then be
+	closed.</P>
+	<LI><P STYLE="margin-bottom: 0cm">When a user clicks the Apply
+	button from the main dialog box, changes are applied to the selected
+	object within the document, but the dialog box is not closed.</P>
+	<LI><P STYLE="margin-bottom: 0cm">When a user clicks the Reset
+	button from the main dialog box, the settings in the dialog box are
+	returned to their values as per the last Apply command. If the user
+	has opened the dialog and has made changes but has not yet clicked
+	the Apply button, the settings are returned to the values
+	corresponding to when they first opened the dialog box. The Reset
+	button does not close the dialog box. 
+	</P>
+	<LI><P STYLE="margin-bottom: 0cm">When a user makes changes to the
+	values in the dialog box and clicks the Close button from the main
+	dialog box without first clicking Apply, an alertbox like the one
+	shown below should be displayed to allow them to continue without
+	losing any information.</P>
+	<LI><P>The Help button invokes the standard Help Tool window
+	contextualized to the dialog box in question.</P>
+<P ALIGN=CENTER><IMG SRC="apply_alert.gif" NAME="Graphic2" ALIGN=BOTTOM WIDTH=280 HEIGHT=105 BORDER=0></P>
+<P ALIGN=CENTER><FONT SIZE=2 STYLE="font-size: 9pt"><B>Figure 2:</B>
+This is the alert-box that is displayed if a user clicks the Close
+button and there are changed settings that have not yet been applied
+to the document. </FONT>
+<P>The wording of the text within the alert-box is modeled after
+phrasing that is already used throughout StarOffice 5.2. It should
+read: &quot;Settings have been modified. Do you want to apply your
+changes?&quot; The alert-box is similar to that which appears when a
+user attempts to close a document without saving its contents first.
+The behavior of each button in this alert-box is as follows:</P>
+	<LI><P STYLE="margin-bottom: 0cm">When a user clicks the Apply
+	button in the alert-box, the changes they made to the values within
+	the main dialog box will be applied to the selection in the
+	document, and the dialog box is closed.</P>
+	<LI><P STYLE="margin-bottom: 0cm">When a user clicks the Discard
+	button in the alert-box, the changes they made to the values within
+	the main dialog box should <I>not</I><SPAN STYLE="font-style: normal">
+	be applied, and the dialog box should be closed.</SPAN></P>
+	<LI><P>When a user clicks the Cancel button in the alert-box, the
+	alert-box should be closed but the changes should <I>not</I> be
+	applied and the user should be returned to the main dialog box. 
+	</P>
+<H2><B>Mouseless navigation</B></H2>
+<P STYLE="margin-bottom: 0cm">Mouseless navigation and keyboard
+traversal should work as in other StarOffice / dialog
+boxes employing default buttons, mnemonics, and full keyboard access.</P>
+<P STYLE="margin-bottom: 0cm">For accessibility reasons, mnemonics
+have been added to the Apply and Reset buttons. The Close button does
+not require one because the Escape key defaults to Close in a dialog
+box. The letters &quot;a&quot; and &quot;r&quot; have been chosen as
+the mnemonics for Apply and Reset respectively. The letter &quot;h&quot;
+will remain as the default for Help as is standard.</P>
+<H2>&quot;Undo&quot; Command Protection</H2>
+<P STYLE="margin-bottom: 0cm">To ensure that users have a safety net,
+they should always be allowed to undo commands that were invoked
+through an Apply button in a dialog box. The current behavior in one
+of the few modeless dialog box that currently (v5.2) contains an
+Apply button (Insert - Hyperlink) is to undo each of the apply
+commands individually, even if the selection has been changed. It is
+suggested that modal dialog boxes follow this behavior as closely as
+possible for the sake of consistency. This means that for both modal
+and modeless dialog boxes the Undo command should only go as far back
+as one Apply command, and not as far as all the Apply commands
+invoked in the last instance of the dialog box.</P>
+<H2>Inclusion Guidelines</H2>
+<P>The &quot;standard set of apply buttons&quot; should be used ... :
+	<LI><P STYLE="margin-bottom: 0cm">When it might be helpful to users
+	to make iterative changes to a selection within a document without
+	closing and re-opening the dialog box.</P>
+	<LI><P STYLE="margin-bottom: 0cm">Even in instances where the dialog
+	box presents the user with a preview of the changes in question.
+	This allows the user to view the object's properties in the context
+	of the document.</P>
+<H2>Exclusion Guidelines</H2>
+<P>The &quot;standard set of apply buttons&quot; should <I>not</I><SPAN STYLE="font-style: normal">
+be used ... :</SPAN></P>
+	<LI><P STYLE="margin-bottom: 0cm">If the changes applied to the
+	user's selection are not visibly noticeable. Dialog boxes that
+	contain visibly confirmable changes <I>and</I> non-visibly
+	confirmable changes may still use the apply button set, and should
+	apply both sets of changes.</P>
+	<LI><P STYLE="margin-bottom: 0cm"><SPAN STYLE="background: transparent">If
+	the changed settings will not immediately be reflected in the user's
+	document.</SPAN></P>
+	<LI><P STYLE="margin-bottom: 0cm"><SPAN STYLE="background: transparent">If
+	the Apply command is in reference to an action that will occur
+	within that specific dialog box. It should only be used when setting
+	are transferred from a dialog box directly to a document.</SPAN></P>
+	<LI><P STYLE="margin-bottom: 0cm">In any dialog box that is accessed
+	from within another dialog box (i.e. secondary, terciary, ... ).</P>
+	<LI><P STYLE="margin-bottom: 0cm">When the changes made in the
+	dialog box are immediately reflected in the document, as in an
+	inspector window.</P>
+<H2>Behavior Guidelines</H2>
+	<LI><P STYLE="margin-bottom: 0cm">The Apply and Reset buttons should
+	be inactive(graye<SPAN STYLE="background: transparent">d out) when
+	the user first opens a dialog box that contains the standard set of
+	apply buttons. They should become active as soon as any of the
+	values are changed in that dialog box. As soon as the Apply or Reset
+	buttons are clicked, they should again revert to their greyed out
+	condition.</SPAN></P>
+	<LI><P STYLE="margin-bottom: 0cm"><SPAN STYLE="background: transparent">When
+	a user clicks the Apply button in a dialog box containing multiple
+	tabs, the settings in all tabs within that dialog box should be
+	applied, not only those in the active window. To be consistent, when
+	the Reset command is clicked, the settings in all tabs within that
+	dialog box should be reset.</SPAN></P>
+	<LI><P STYLE="margin-bottom: 0cm">The Reset button (that returns
+	settings to previously applied values) should not be confused for a
+	defaults button (that returns settings to program defaults). Dialog
+	boxes that need a Defaults button should present it separately from
+	the standard set of apply buttons.</P>
+<H1>Open Issues</H1>
+<H2>Button set</H2>
+<P>The account of buttons should be reduced to a minimum as too much
+buttons could be confusing for a user. Because of this two questions
+came up:</P>
+	<LI><P>It is not clear if the Reset button should be an optional
+	part of the button set. As there might be situations where an Apply
+	button would be useful, but a Reset button would not make so much
+	sense. An example are dialogs, where just some simple values are
+	entered, e.g. for adjusting the row height of a table (see Format &#150;
+	Row &#150; Height). The more complex the possible dialog settings
+	are, the more useful a Reset button would be. Should the Apply
+	button set always contain a Reset button?</P>
+	<LI><P>Can we find another solution for the Help button, for example
+	by replacing it with an icon? (As this also affects other dialogs,
+	that won't have an Apply button, this will probably be an open issue
+	for the future.)</P>
+<H2>Reset Button Behavior</H2>
+<P>The Reset button's current behavior allows users to revert the
+settings in the dialog box to their values as of the last Apply
+command. As we see it, there are several options here:</P>
+	<LI><P>Change the behavior of the Reset button to more of an Undo so
+	that it reverts the settings back to the values at the invocation of
+	the dialog box</P>
+	<LI><P>Eliminate the Reset button altogether to eliminate clutter,
+	still allowing the user to &quot;cancel&quot; their Apply commands
+	using the Undo function</P>
+	<LI><P>Leave the Reset button like it is.</P>
+<P>Again, there are other options that are listed here, but what is
+the best solution?</P>
+<P STYLE="margin-top: 0.42cm; page-break-after: avoid"><A HREF="apply_button_spec_appendix.html"><FONT SIZE=4><FONT FACE="Times New Roman, serif">Appendix 
+  1: Proposed Additions</FONT></FONT></A></P>
\ No newline at end of file

Added: incubator/ooo/ooo-site/trunk/content/framework/proposals/apply/apply_button_spec_appendix.html
--- incubator/ooo/ooo-site/trunk/content/framework/proposals/apply/apply_button_spec_appendix.html (added)
+++ incubator/ooo/ooo-site/trunk/content/framework/proposals/apply/apply_button_spec_appendix.html Fri Nov 25 20:00:55 2011
@@ -0,0 +1,105 @@
+	<META HTTP-EQUIV="CONTENT-TYPE" CONTENT="text/html; charset=iso-8859-1">
+	<META NAME="GENERATOR" CONTENT="StarOffice/5.2 (Win32)">
+	<META NAME="CREATED" CONTENT="20010124;11183400">
+	<META NAME="CHANGED" CONTENT="20010216;14401605">
+<H3>Apply Button Specification: Appendix #1 - Proposed Additions</H3>
+<P STYLE="margin-bottom: 0cm">When a module (e.g., StarOffice / Writer) is not specified, it is because the function
+appears in more than one, or perhaps in all four (Writer, Calc, Draw,
+Impress). This list of proposed additions is not exhaustive. A
+proposal that contains a list of dialogs is currently in work. The
+following are screen-shots of the revised dialog boxes.</P>
+<P STYLE="margin-bottom: 0cm"><BR>
+<P STYLE="margin-bottom: 0cm"><B>Format - Numbering / Bullets: </B>The
+&quot;Remove&quot; button should be exchanged for a &quot;No Bullets&quot;
+option. Change the &quot;OK&quot; button to &quot;Apply&quot;, and
+the &quot;Cancel&quot; button to &quot;Close&quot;. The buttons take
+on the configuration below. <BR>&nbsp; 
+<P ALIGN=CENTER STYLE="margin-bottom: 0cm"><IMG SRC="format_bullets.gif" NAME="Graphic15" ALIGN=BOTTOM  BORDER=0></P>
+<P STYLE="margin-bottom: 0cm"><B>Format - Page:&nbsp;</B><SPAN STYLE="font-weight: medium">Change
+the &quot;OK&quot; button to &quot;Apply&quot;, and the &quot;Cancel&quot;
+button to&nbsp;</SPAN>&quot;Close&quot;. The buttons take on the
+configuration below.</P>
+<P STYLE="margin-bottom: 0cm"><B>Problem: </B>Under Page layout you
+can select for which layout the settings should be valid. Thus it can
+happen, that the settings made are not immediately visible in the
+<P ALIGN=CENTER><IMG SRC="format_page.gif" NAME="Graphic16" ALIGN=BOTTOM 9 BORDER=0></P>
+<P STYLE="margin-bottom: 0cm"><B>Format - Paragraph:&nbsp;</B><SPAN STYLE="font-weight: medium">Change
+the &quot;OK&quot; button to &quot;Apply&quot;, and the &quot;Cancel&quot;
+button to&nbsp;</SPAN>&quot;Close&quot;. The buttons take on the
+configuration below. 
+<P STYLE="margin-bottom: 0cm"><BR>&nbsp; 
+<P ALIGN=CENTER><IMG SRC="format_paragraph.gif" NAME="Graphic17" ALIGN=BOTTOM  BORDER=0></P>
+<P STYLE="margin-bottom: 0cm"><B>Format - Styles - Catalog:</B>
+Change the &quot;OK&quot; button to &quot;Apply&quot;, the &quot;Cancel&quot;
+button to &quot;Close&quot; and add a &quot;Reset&quot; button. These
+buttons, along with the &quot;Help&quot; button, should appear at the
+bottom of the dialog box to distinguish them from contextual buttons
+such as &quot;New&quot;, &quot;Modify&quot;, &quot;Delete&quot;, and
+&quot;Organizer&quot;. The buttons take on the configuration below.
+<P ALIGN=CENTER STYLE="margin-bottom: 0cm"><IMG SRC="format_styles.gif" NAME="Graphic18" ALIGN=BOTTOM  BORDER=0></P>
+<P STYLE="margin-bottom: 0cm"><BR>
+<P STYLE="margin-bottom: 0cm"><B>Draw - Format - Area:&nbsp;</B><SPAN STYLE="font-weight: medium">Change
+the &quot;OK&quot; button to &quot;Apply&quot;, and the
+&quot;Cancel&quot;</SPAN>button to &quot;Close&quot;. The buttons
+take on the configuration below. <BR>&nbsp; 
+<P ALIGN=CENTER STYLE="margin-bottom: 0cm"><IMG SRC="format_area.gif" NAME="Graphic21" ALIGN=BOTTOM  BORDER=0></P>
+<P STYLE="margin-bottom: 0cm"><B>Draw - Format - Dimensions:</B>
+Change the &quot;OK&quot; button to &quot;Apply&quot;, the &quot;Cancel&quot;
+button to &quot;Close&quot;, and add a &quot;Reset&quot; button.
+Align these buttons in the standard order at the bottom of the dialog
+box. The buttons take on the configuration below. <BR>&nbsp; 
+<P ALIGN=CENTER STYLE="margin-bottom: 0cm"><IMG SRC="format_dimensions.gif" NAME="Graphic3" ALIGN=BOTTOM  BORDER=0></P>
+<P STYLE="margin-bottom: 0cm"><B>Draw - Format - Text:&nbsp;</B><SPAN STYLE="font-weight: medium">Change
+the &quot;OK&quot; button to &quot;Apply&quot;, and the
+&quot;Cancel&quot;</SPAN>button to &quot;Close&quot;. The buttons
+take on the configuration below. <BR>&nbsp; 
+<P ALIGN=CENTER><IMG SRC="format_text.gif" NAME="Graphic24" ALIGN=BOTTOM WIDTH=529 HEIGHT=308 BORDER=0></P>
+<P STYLE="margin-bottom: 0cm"><B>Calc - Format - Cell: </B>Change the
+&quot;OK&quot; button to &quot;Apply&quot;, and the &quot;Cancel&quot;
+button to &quot;Close&quot;. The buttons take on the configuration
+below. <BR>&nbsp; 
+<P ALIGN=CENTER STYLE="margin-bottom: 0cm"><IMG SRC="format_cell.gif" NAME="Graphic25" ALIGN=BOTTOM  BORDER=0></P>
+<P><B>Calc - Format - Conditions:</B> Change the &quot;OK&quot;
+button to &quot;Apply&quot;, and the &quot;Cancel&quot; button to
+&quot;Close&quot;. Align these buttons in the standard order, and add
+a &quot;Reset&quot; button to the right of those three buttons. The
+buttons take on the configuration below. 
+<P ALIGN=CENTER STYLE="margin-bottom: 0cm"><IMG SRC="format_conditions.gif" NAME="Graphic4" ALIGN=BOTTOM  BORDER=0></P>
+<P STYLE="margin-bottom: 0cm"><BR>&nbsp; <BR>&nbsp; 
+<P STYLE="margin-bottom: 0cm"><BR>
\ No newline at end of file

Propchange: incubator/ooo/ooo-site/trunk/content/framework/proposals/apply/apply_button_spec_appendix.html
    svn:eol-style = native

Added: incubator/ooo/ooo-site/trunk/content/framework/proposals/apply/format_area.gif
Binary file - no diff available.

Propchange: incubator/ooo/ooo-site/trunk/content/framework/proposals/apply/format_area.gif
    svn:mime-type = image/gif

Added: incubator/ooo/ooo-site/trunk/content/framework/proposals/apply/format_bullets.gif
Binary file - no diff available.

Propchange: incubator/ooo/ooo-site/trunk/content/framework/proposals/apply/format_bullets.gif
    svn:mime-type = image/gif

Added: incubator/ooo/ooo-site/trunk/content/framework/proposals/apply/format_cell.gif
Binary file - no diff available.

Propchange: incubator/ooo/ooo-site/trunk/content/framework/proposals/apply/format_cell.gif
    svn:mime-type = image/gif

Added: incubator/ooo/ooo-site/trunk/content/framework/proposals/apply/format_conditions.gif
Binary file - no diff available.

Propchange: incubator/ooo/ooo-site/trunk/content/framework/proposals/apply/format_conditions.gif
    svn:mime-type = image/gif

Added: incubator/ooo/ooo-site/trunk/content/framework/proposals/apply/format_dimensions.gif
Binary file - no diff available.

Propchange: incubator/ooo/ooo-site/trunk/content/framework/proposals/apply/format_dimensions.gif
    svn:mime-type = image/gif

Added: incubator/ooo/ooo-site/trunk/content/framework/proposals/apply/format_page.gif
Binary file - no diff available.

Propchange: incubator/ooo/ooo-site/trunk/content/framework/proposals/apply/format_page.gif
    svn:mime-type = image/gif

Added: incubator/ooo/ooo-site/trunk/content/framework/proposals/apply/format_paragraph.gif
Binary file - no diff available.

Propchange: incubator/ooo/ooo-site/trunk/content/framework/proposals/apply/format_paragraph.gif
    svn:mime-type = image/gif

Added: incubator/ooo/ooo-site/trunk/content/framework/proposals/apply/format_styles.gif
Binary file - no diff available.

Propchange: incubator/ooo/ooo-site/trunk/content/framework/proposals/apply/format_styles.gif
    svn:mime-type = image/gif

Added: incubator/ooo/ooo-site/trunk/content/framework/proposals/apply/format_text.gif
Binary file - no diff available.

Propchange: incubator/ooo/ooo-site/trunk/content/framework/proposals/apply/format_text.gif
    svn:mime-type = image/gif

Added: incubator/ooo/ooo-site/trunk/content/framework/proposals/apply/new_preview_concept.html
--- incubator/ooo/ooo-site/trunk/content/framework/proposals/apply/new_preview_concept.html (added)
+++ incubator/ooo/ooo-site/trunk/content/framework/proposals/apply/new_preview_concept.html Fri Nov 25 20:00:55 2011
@@ -0,0 +1,223 @@
+	<META HTTP-EQUIV="CONTENT-TYPE" CONTENT="text/html; charset=iso-8859-1">
+	<META NAME="GENERATOR" CONTENT="StarOffice/5.2 (Win32)">
+	<META NAME="CREATED" CONTENT="20010228;15350717">
+	<META NAME="CHANGED" CONTENT="20010309;11552907">
+	<!--
+		@page { size: 21cm 29.7cm; margin: 2cm }
+		H1 { margin-bottom: 0.21cm; font-size: 16pt }
+		TD P { margin-bottom: 0.21cm }
+		H2 { margin-bottom: 0.21cm; font-size: 14pt; font-style: italic }
+		P { margin-bottom: 0.21cm }
+	-->
+	</STYLE>
+<P ALIGN=CENTER STYLE="margin-top: 0.42cm; margin-bottom: 0.5cm; page-break-after: avoid">
+<FONT FACE="SunSans-Demi, sans-serif"><FONT SIZE=4 STYLE="font-size: 16pt">Proposal
+for a Preview Feature in Dialogs</FONT></FONT></P>
+<P ALIGN=CENTER STYLE="margin-top: 0.42cm; margin-bottom: 0.5cm; page-break-after: avoid">
+<FONT FACE="Times New Roman, serif"><FONT SIZE=3>Version 1</FONT></FONT></P>
+<P ALIGN=CENTER>Date: March 8, 2001</P>
+<H1>Table of Contents</H1>
+<P><A HREF="#2.Introduction|outline">Introduction</A></P>
+<P STYLE="margin-left: 2cm"><A HREF="#2.1.Modeless and Modal Dialogs|outline">Modeless
+and Modal Dialogs</A></P>
+<P><A HREF="#3.Live Mode Concept|outline">Live Mode Concept</A></P>
+<P STYLE="margin-left: 2cm"><A HREF="#3.1.Basic Functionality|outline">Basic
+<P STYLE="margin-left: 2cm"><A HREF="#3.2.Buttons|outline">Buttons</A></P>
+<P STYLE="margin-left: 2cm"><A HREF="#3.3.Undo|outline">Undo</A></P>
+<P STYLE="margin-left: 2cm"><A HREF="#3.4.Live Mode Behavior|outline">Live
+Mode Behavior</A></P>
+<P><A HREF="#4.Alternative: Preview Icon|outline">Alternative:
+Preview Icon</A></P>
+<P><A HREF="#5.Benefits to former Apply Proposal|outline">Benefits to
+former Apply Proposal</A></P>
+<P><A HREF="#6.Open Issues|outline">Open Issues</A></P>
+<H1><A NAME="2.Introduction|outline"></A>Introduction</H1>
+<P><FONT FACE="Times New Roman, serif">This document is based on the
+</FONT><A HREF="apply_button_spec.htm"><FONT FACE="Times New Roman, serif">first
+proposal</FONT></A><FONT FACE="Times New Roman, serif"> for a new
+Apply button concept in StarOffice / Based on the
+feedback of the community, we decided to think this concept over. As
+a result a new idea came up, which is described in this document.</FONT></P>
+<P>The initial idea of having an Apply button in dialogs was to
+improve the usability of the program, namely the dialog handling,
+with the goal to reduce the number of steps a user would have to
+complete a task. Therefore an Apply button seemed to be a good
+solution as it allows applying and changing settings without having
+to re-open a dialog several times.</P>
+<P>The community's feedback to the proposal for the use of an Apply
+button in dialogs has shown some problems that would occur when
+introducing it in the application as suggested. 
+<P>The disadvantage of the proposed button set was that</P>
+	<LI><P>it contained too much buttons what could be dazzling for a
+	user</P>
+	<LI><P>the combination of OK, Cancel/Close, Apply could be confusing
+	for a user</P>
+	<LI><P>the meaning of an Apply button might not be intuitively
+	understandable</P>
+	<LI><P>it might not be understood easily which data will be effected
+	by the Reset button: single tab, whole dialog or applied data.</P>
+<P>The community's feedback also made clear, that not an Apply
+(=Assign) button is desired but a Preview (=Try) feature. Whereas an
+Apply always assigns settings made in a dialog, a Preview is only for
+testing the settings without applying them ultimately.</P>
+<H2><A NAME="2.1.Modeless and Modal Dialogs|outline"></A>Modeless and
+Modal Dialogs</H2>
+<P>The proposed Apply concept did not distinguish between modal and
+modeless dialog boxes, as the possibility of &quot;testing&quot; some
+settings with having the dialog opened should not depend on the
+dialog type. Therefore the Apply button - that is usually used in
+modeless dialog boxes - seemed to be a good solution for modal
+dialogs, too. But this does not correspond to the desired Preview
+<P>In <B>modeless</B> dialog boxes an Apply button is necessary, that
+assigns settings to the actual selection. Changing the selection is
+possible here. Thus it must be possible to assign settings ultimately
+before changing the selection. Here Apply has the same functionality
+as an OK button, the only difference is, that the dialog box is not
+closed when pressing Apply. The sense of an Apply button is not for
+testing but for a better and faster workflow as the dialog remains
+open when switching the selection.</P>
+<P>When introducing this Apply button to <B>modal</B> dialog boxes,
+the behavior of the Apply button must, of course, be the same. Thus
+the settings made in a dialog must be assigned to the document/object
+selection ultimately. But this is something, the user might not
+expect or what he does not want. Instead something like a Preview or
+Try button, that is only for testing the settings without applying
+them ultimately, should be offered. The final assignment should be
+done by clicking on an OK button. (Otherwise, if the settings are
+assigned ultimately via Apply, an Undo of the settings made could be
+too complicated for the user.)</P>
+<H1><A NAME="3.Live Mode Concept|outline"></A>Live Mode Concept</H1>
+<P>Trying to find a solution for all those issues that came up in the
+community's discussion, a new idea came up, which is described in the
+<H2><A NAME="3.1.Basic Functionality|outline"></A>Basic Functionality</H2>
+<P>Two different button sets should be used for modal/modeless
+dialogs, that only offer the basic functionality that is necessary</P>
+	<LI><P>modal: OK, Cancel, Help</P>
+	<LI><P>modeless: Apply, Close, Help</P>
+<P>Beneath these buttons a Live mode icon is offered for both dialog
+types. If Live mode is active, all settings made in the dialog get
+directly visible in the document. But they are not applied ultimately
+unless the user clicks on OK (for modal) or Apply (for modeless
+dialogs). Switching back to Normal mode is possible by clicking on
+the Live mode icon again (=deactivation).</P>
+<P>If the user changes something in the Normal/Live mode and then
+switches to Live/Normal mode, the information within the dialog
+should not be lost:</P>
+<P>When switching from Normal mode to Live mode, the changes made
+before get directly visible in the document.</P>
+<P>When switching from Live mode to Normal mode, the screen display
+of the document switches back to its former state, with those
+settings that were valid, before the dialog was opened. (But the
+settings made in the Live mode are not re-set in the dialog.)</P>
+<H2><A NAME="3.2.Buttons|outline"></A>Buttons</H2>
+<P>The button set is reduced to a minimum, whereby modal and modeless
+dialogs must have different sets due to their nature.</P>
+<P>The buttons behave as follows:</P>
+	<LI><P>OK: Finally applies the settings made. The dialog is closed.</P>
+	<LI><P>Cancel: Cancels the settings made to return to the original
+	state before the dialog was opened (=undo for all steps). The dialog
+	is closed.</P>
+	<LI><P><SPAN STYLE="background: transparent">Apply: Changes are
+	applied to the selected object within the document but the dialog
+	box is not closed.</SPAN></P>
+	<LI><P><SPAN STYLE="background: transparent">Close: Closes the
+	dialog. (Settings are not applied to the document, unless the user
+	has used the Apply button before.)</SPAN></P>
+	<LI><P>Help: Opens context sensitive help for the dialog.</P>
+<H2><A NAME="3.3.Undo|outline"></A>Undo</H2>
+<P><SPAN STYLE="background: transparent">Undo is possible via menu
+(Edit &#150; Undo). Thus for modal dialogs the user can use this
+command after the dialog has been closed via OK. Here Undo would
+return to the original state before the dialog was opened. For
+modeless dialogs he can even use Undo while the dialog is still open.
+Here an Undo step is valid for the settings applied via Apply button.</SPAN></P>
+<H2><A NAME="3.4.Live Mode Behavior|outline"></A>Live Mode Behavior</H2>
+<P>In the Live mode the user can change the settings of the dialog as
+usual. The only difference to the Normal mode is, that the changes
+get directly visible in the document.</P>
+<P>Whenever the focus is removed from a control, the settings should
+get visible in the document as soon as possible. If the focus is not
+changed from one control to another and the user changes something
+within that single control, then the changes should get visible after
+a defined time. This delay time is necessary to avoid fast screen
+display changes due to hectic user actions. Whenever a change has
+been made and no user's action takes place in this time, then the
+settings get automatically visible in the document.</P>
+<P>The delay time has to be verified, perhaps it should be about 2-3
+seconds. The time might also be adjustable in a Tools/Options dialog.</P>
+<H1><A NAME="4.Alternative: Preview Icon|outline"></A><SPAN STYLE="background: transparent">Alternative:
+Preview Icon</SPAN></H1>
+<P>Instead of a Live mode that shows dialog changes automatically, it
+is also possible to offer a Preview icon: When pressing it, all the
+changes made in the dialog get directly visible in the document (but
+they are not applied ultimately). The difference to the Live mode is,
+that the user must be active to see the changes. 
+<P>With this alternative technical problems that might occur with the
+Live mode, such as time consuming data processing, are avoided.</P>
+<H1><A NAME="5.Benefits to former Apply Proposal|outline"></A><FONT FACE="Times New Roman, serif">Benefits
+to former Apply Proposal</FONT></H1>
+	<LI><P>The button set has been reduced to a minimum to offer only
+	the basic features that are necessary. Thus the problem of having
+	too much buttons in a dialog, that might not be understandable,
+	should not appear.</P>
+	<LI><P>A Live or a Preview mode does not apply any settings to the
+	object selection in the document. Therefore a user must not worry
+	about how to undo changes. He just has to decide, if he wants to
+	apply the current settings and then click on Apply (modeless) or OK
+	(modal).</P>
+<H1><A NAME="6.Open Issues|outline"></A><FONT FACE="Times New Roman, serif"><B>Open
+	<LI><P>Should a modal dialog contain an Apply button? This only
+	makes sense to apply settings of an intermediary state, while
+	&quot;playing&quot; with the dialog and trying out some settings. If
+	yes, it should be tested, if the combination of OK/Apply is
+	understood by a user.</P>
+	<LI><P>Should a modeless dialog contain an OK button? This could
+	make sense for offering the possibility to apply settings and close
+	the dialog with just one mouse-click instead of two (=Apply +
+	Close). If yes, it should be tested, if the combination of OK/Apply
+	is easily understood by a user.</P>
+	<LI><P>Is a Live mode, that shows changes automatically, better than
+	a Preview button, that just displays the changes on the screen, when
+	it is pressed by the user? (Technical problems that might appear
+	with a Live mode must be cleared.)</P>
+	<LI><P>Live mode: The names Live mode and Normal mode have to be
+	verified (=&gt; Preview mode active/not active?)</P>
+<P><FONT SIZE=4 STYLE="font-size: 16pt"><B>Further Issues</B></FONT></P>
+<P STYLE="font-weight: medium">Independent of this proposal of a Live
+mode or a Preview button, some issues are still open and are
+summarized for the future:</P>
+	<LI><P>We need to establish functional button sets for use
+	throughout our dialogs to avoid that users might be confused as to
+	the behavior of the buttons (e.g. Reset, Back, Standard).</P>
+	<LI><P>We need to establish window behavior, such as making sure all
+	dialogs that can AND should be modeless, are modeless. This is to
+	guarantee a faster workflow.</P>
\ No newline at end of file

Propchange: incubator/ooo/ooo-site/trunk/content/framework/proposals/apply/new_preview_concept.html
    svn:eol-style = native

Added: incubator/ooo/ooo-site/trunk/content/framework/proposals/apply/oarch.gif
Binary file - no diff available.

Propchange: incubator/ooo/ooo-site/trunk/content/framework/proposals/apply/oarch.gif
    svn:mime-type = image/gif

Added: incubator/ooo/ooo-site/trunk/content/framework/proposals/dialogs/b1.gif
Binary file - no diff available.

Propchange: incubator/ooo/ooo-site/trunk/content/framework/proposals/dialogs/b1.gif
    svn:mime-type = image/gif

Added: incubator/ooo/ooo-site/trunk/content/framework/proposals/dialogs/b2.gif
Binary file - no diff available.

Propchange: incubator/ooo/ooo-site/trunk/content/framework/proposals/dialogs/b2.gif
    svn:mime-type = image/gif

Added: incubator/ooo/ooo-site/trunk/content/framework/proposals/dialogs/b3.gif
Binary file - no diff available.

Propchange: incubator/ooo/ooo-site/trunk/content/framework/proposals/dialogs/b3.gif
    svn:mime-type = image/gif

Added: incubator/ooo/ooo-site/trunk/content/framework/proposals/dialogs/b4.gif
Binary file - no diff available.

Propchange: incubator/ooo/ooo-site/trunk/content/framework/proposals/dialogs/b4.gif
    svn:mime-type = image/gif

Added: incubator/ooo/ooo-site/trunk/content/framework/proposals/dialogs/index.html
--- incubator/ooo/ooo-site/trunk/content/framework/proposals/dialogs/index.html (added)
+++ incubator/ooo/ooo-site/trunk/content/framework/proposals/dialogs/index.html Fri Nov 25 20:00:55 2011
@@ -0,0 +1,63 @@
+	<META HTTP-EQUIV="CONTENT-TYPE" CONTENT="text/html; charset=iso-8859-1">
+	<META NAME="GENERATOR" CONTENT="StarOffice/5.2 (Win32)">
+	<META NAME="AUTHOR" CONTENT="Christian Jansen">
+	<META NAME="CREATED" CONTENT="20010124;9262370">
+	<META NAME="CHANGEDBY" CONTENT="Christian Jansen">
+	<META NAME="CHANGED" CONTENT="20010124;14113550">
+<A HREF="../../index.html#Proposals">back</A>
+<P ALIGN=RIGHT><FONT FACE="Arial, sans-serif"><FONT SIZE=2><B>Christian
+<P><FONT FACE="Arial, sans-serif"><FONT SIZE=4><B>Proposal of a new
+dialogue size and a modified tab page handling.</B></FONT></FONT></P>
+<P><FONT FACE="Arial, sans-serif"><B>Problem 1:</B></FONT></P>
+<P><FONT FACE="Arial, sans-serif">The current standard size of the
+tabbed dialogues is not large enough. Due to this fact we are running
+into trouble especially for the CJK &#150; version of OpenOffice /
+<P><FONT FACE="Arial, sans-serif"><B>Solution:</B></FONT></P>
+<P><FONT FACE="Arial, sans-serif">The solution could be to provide
+the user a new dialogue which is nearly double in height than the old
+one. </FONT><A HREF="#Rahmen1|frame"><FONT FACE="Arial, sans-serif">Figure
+1</FONT></A><FONT FACE="Arial, sans-serif"> shows the proposed
+dialogue in a rough sketch. The dotted line visualizes the change in
+the total height, if more then one tab row is needed. In my opinion
+it is not recommended to extend the dialogue in width too, because
+most of the space is <FONT FACE="Arial, sans-serif">needed </FONT>in
+the vertical. And it give the whole look and feel a nicer touch,
+because of the format which adopts the 4:3 ratio of the monitor. If
+the dialogue is extended with a tree view for example it will have a
+size of about 620 pixel in width (on a Windows system with a Tahoma
+UI-Font 8pt, at a resolution 1280x1024 with 96 dpi).</FONT></P>
+<P><IMG SRC="./b1.gif" NAME="Rahmen5" ALT="Rahmen5" ALIGN=BOTTOM></P>
+<P><FONT FACE="Arial, sans-serif">In a real world the dialogue could
+look like the scribble in <A HREF="#Rahmen2|frame">figure 2</A>. </FONT>
+<P><IMG SRC="./b2.gif" NAME="Rahmen6" ALT="Rahmen6" ALIGN=BOTTOM></P>
+<P><FONT FACE="Arial, sans-serif"><B>Problem 2:</B></FONT></P>
+<P><FONT FACE="Arial, sans-serif">Another problem that should be
+solved is the circumstance, that to many tabs are confusing and hard
+to handle for the user. Especially if more than two rows are used in
+the design. </FONT>
+<P><FONT FACE="Arial, sans-serif"><B>Solution:</B></FONT></P>
+<P><FONT FACE="Arial, sans-serif"><A HREF="#Rahmen4|frame">Figure 3</A>
+shows the original design of <FONT FACE="Arial, sans-serif">the
+property dialogue of the CJK version</FONT>. (Also this is still the
+old tab page size)</FONT></P>
+<P><FONT FACE="Arial, sans-serif"><IMG SRC="./b3.gif" NAME="Rahmen7" ALT="Rahmen7" ALIGN=BOTTOM></FONT></P>
+<P><FONT FACE="Arial, sans-serif"><A HREF="#Rahmen3|frame">Figure 4</A>
+shows how it could look with the new design. It provides a lot of
+more clarity, than a dialogue with 14 tabs.</FONT></P>
+<P><IMG SRC="./b4.gif" NAME="Rahmen8" ALT="Rahmen8" ALIGN=BOTTOM></P>

Propchange: incubator/ooo/ooo-site/trunk/content/framework/proposals/dialogs/index.html
    svn:eol-style = native

Added: incubator/ooo/ooo-site/trunk/content/framework/proposals/dialogs/staroffice_60_desk_env_int.sdc
Binary file - no diff available.

Propchange: incubator/ooo/ooo-site/trunk/content/framework/proposals/dialogs/staroffice_60_desk_env_int.sdc
    svn:mime-type = application/octet-stream

Added: incubator/ooo/ooo-site/trunk/content/framework/proposals/filterfactory/filterfactory.gif
Binary file - no diff available.

Propchange: incubator/ooo/ooo-site/trunk/content/framework/proposals/filterfactory/filterfactory.gif
    svn:mime-type = image/gif

Added: incubator/ooo/ooo-site/trunk/content/framework/proposals/filterfactory/proposal_filterfactory.html
--- incubator/ooo/ooo-site/trunk/content/framework/proposals/filterfactory/proposal_filterfactory.html (added)
+++ incubator/ooo/ooo-site/trunk/content/framework/proposals/filterfactory/proposal_filterfactory.html Fri Nov 25 20:00:55 2011
@@ -0,0 +1,119 @@
+	<META HTTP-EQUIV="CONTENT-TYPE" CONTENT="text/html; charset=windows-1252">
+	<META NAME="GENERATOR" CONTENT="StarOffice 6.0  (Win32)">
+	<META NAME="CREATED" CONTENT="20020116;12484000">
+	<META NAME="CHANGED" CONTENT="20020215;8401975">
+	<!--
+		@page { margin: 2cm }
+		P { margin-bottom: 0.21cm }
+		H1 { margin-bottom: 0.21cm }
+		H1.western { font-family: "Albany", sans-serif; font-size: 16pt }
+		H1.cjk { font-size: 16pt }
+		H1.ctl { font-size: 16pt }
+		H2 { margin-bottom: 0.21cm }
+		H2.western { font-family: "Albany", sans-serif; font-size: 14pt; font-style: italic }
+		H2.cjk { font-size: 14pt; font-style: italic }
+		H2.ctl { font-size: 14pt; font-style: italic }
+	-->
+	</STYLE>
+<BODY LANG="de-DE">
+<H1 CLASS="western">Proposal: Searching and creating filters (3)</H1>
+<H2 CLASS="western" ALIGN=JUSTIFY>Problem</H2>
+<P ALIGN=JUSTIFY STYLE="margin-bottom: 0cm"><FONT COLOR="#000000"><SPAN STYLE="background: transparent">Our
+current mechanism to <SPAN STYLE="font-weight: medium">search</SPAN>
+and create filters which are registered for types is not really
+understandable for api user. This proposal describes a better (but
+incompatible) way to make it easier.</SPAN></FONT></P>
+<H2 CLASS="western">Changes</H2>
+<P ALIGN=JUSTIFY STYLE="margin-bottom: 0cm"><FONT COLOR="#000000"><SPAN STYLE="background: transparent">Please
+see the follow list corresponding with the graphic below to get all
+<P ALIGN=JUSTIFY STYLE="margin-bottom: 0cm"><BR>
+	<LI><P ALIGN=JUSTIFY STYLE="margin-bottom: 0cm"><B></B><A HREF=""><SPAN STYLE="background: transparent"><U><FONT COLOR="#000000"><BR></FONT></U></SPAN></A><B><FONT COLOR="#008000">(unchanged)</FONT></B><A HREF="file:///X:/as/proposal/"><SPAN STYLE="background: transparent"><U><FONT COLOR="#000000"><BR></FONT></U></SPAN></A><SPAN STYLE="background: transparent"><FONT COLOR="#000000">Use
+	it for a low level read/write access to pure filter configuration in
+	the same manner as now. The interface works with internal filter
+	names only and supports set/get filter properties.</FONT></SPAN></P>
+	<LI><P ALIGN=JUSTIFY STYLE="margin-bottom: 0cm"><B></B><A HREF=""><SPAN STYLE="background: transparent"><FONT COLOR="#000000"><BR></FONT></SPAN></A><B><FONT COLOR="#b3b300">(draft)</FONT></B><A HREF=""><SPAN STYLE="background: transparent"><BR></SPAN></A>Use
+	it to search/group filters by special parameters. Returned
+	enumeration contains filters wich match your search parameters. They
+	are represented by flat data structures as Sequence&lt;PropertyValue&gt;
+	including all properties of them. So it's not neccessary to use
+	XNameAccess again to get the properties. Internal name of filters
+	will be a part of returned data structures too and can be used on
+	interface XMultiServiceFactory to create the filter objects.</P>
+	<LI><P ALIGN=JUSTIFY STYLE="margin-bottom: 0cm"><B></B><A HREF=""><SPAN STYLE="background: transparent"><FONT COLOR="#000000"><BR></FONT></SPAN></A><B><FONT COLOR="#800000">(changed)</FONT></B></P>
+	<LI><P ALIGN=JUSTIFY STYLE="margin-bottom: 0cm"><FONT COLOR="#000000"><SPAN STYLE="background: transparent"><I>old</I><BR>The
+	method &bdquo;createInstance()&ldquo; called with an internal filter
+	name wasn't supported. Same method called with an internal type name
+	searched for any suitable (registered default) filter in the
+	configuration and returned a created filter object.<BR>The method
+	&bdquo;createInstanceWithArguments()&ldquo; does the same as
+	&bdquo;createInstance()&ldquo;. The optional argument &bdquo;FilterName&ldquo;
+	suppresses the search and create the specified filter object by name
+	directly.</SPAN></FONT></P>
+	<LI><P ALIGN=JUSTIFY STYLE="margin-bottom: 0cm"><SPAN STYLE="background: transparent"><FONT COLOR="#000000"><I>new</I><BR>Both
+	methods of this interface create filter objects by internal name
+	only. There exist no optional search mechanism any longer. The
+	return value is the created filter object, initialized with his own
+	configuration data by calling
+	&bdquo;XInitialization::initialize()&ldquo;.<BR>Format of
+	initialization data:<BR>Sequence&lt;Any&gt;[0]     = filter config
+	data as Sequence&lt;PropertyValue&gt;<BR>Sequence&lt;Any&gt;[1..n] =
+	optional arguments of &bdquo;createInstanceWithArguments()&ldquo;<BR>
+	directly</FONT></SPAN></P>
+<P ALIGN=JUSTIFY STYLE="margin-bottom: 0cm"><BR>
+<P ALIGN=JUSTIFY><IMG SRC="filterfactory.gif" NAME="Objekt1" ALIGN=LEFT><BR CLEAR=LEFT><BR><BR>
+<H2 CLASS="western" ALIGN=JUSTIFY>Consequences</H2>
+	<LI><P ALIGN=JUSTIFY STYLE="margin-bottom: 0cm"><FONT COLOR="#000000"><SPAN STYLE="background: transparent"><I>XMultiServiceFactory</I>
+	methods doesn't support the creation of filters using internal type
+	names any longer.</SPAN></FONT></P>
+	<LI><P ALIGN=JUSTIFY STYLE="margin-bottom: 0cm"><FONT COLOR="#000000"><SPAN STYLE="background: transparent">This
+	should be a part of new interface <I>XContainerQuery</I>. Please
+	have a look on
+	<A HREF=""></A>
+	too, to get more information about the generic functionality of this
+	interface.</SPAN></FONT></P>
+	<LI><P ALIGN=JUSTIFY STYLE="margin-bottom: 0cm"><FONT COLOR="#000000"><SPAN STYLE="background: transparent">Filter
+	implementations must support <I>XInitialization</I> to get her own
+	configuration data and optional arguments of
+	<I>XMultiServiceFactory::createInstanceWithArguments()</I>.</SPAN></FONT></P>
+	<LI><P ALIGN=JUSTIFY STYLE="margin-bottom: 0cm"><FONT COLOR="#000000"><SPAN STYLE="background: transparent">They
+	can implement <I>XNamed()</I> to identify herself. User of a filter
+	object can use returned internal name on service FilterFactory to
+	get more information about it.<BR>&bdquo;getName()&ldquo; must
+	return the internal name of the filter<BR>&bdquo;setName()&ldquo;
+	can be ignored or should be used to rename the filter inside the
+	configuration by using mechanism of service FilterFactory.<BR>=&gt;
+	Discussion: Should it be allowed to rename a filter during
+	runtime?<BR>=&gt; I would say: &bdquo;NO&ldquo;! Nobody can support
+	a right error handling for name clashes if a filter with same name
+	already exist. This functionality should be a part of the setup or
+	an administration process.</SPAN></FONT></P>
+<H2 CLASS="western" ALIGN=JUSTIFY>Example</H2>
+<P ALIGN=JUSTIFY>Follow sequence diagram should show creation of a
+suitable (default) filter for a detected type. First the user try to
+get the internal filter name by using <I>XContainerQuery</I>
+interface with the internal type name and some optional search
+parameters. The returned filter name can be used on another interface
+<I>XMultiServiceFactory</I> to create the filter object directly.
+Filter will be created and initialized (by calling
+<I>XInitialization::initialize())</I> with his own configuration data
+by used FilterFactory.</P>
+<P ALIGN=JUSTIFY><IMG SRC="seq_create_filter.gif" NAME="Objekt2" ALIGN=LEFT><BR CLEAR=LEFT><BR><BR>

Propchange: incubator/ooo/ooo-site/trunk/content/framework/proposals/filterfactory/proposal_filterfactory.html
    svn:eol-style = native

Added: incubator/ooo/ooo-site/trunk/content/framework/proposals/filterfactory/seq_create_filter.gif
Binary file - no diff available.

Propchange: incubator/ooo/ooo-site/trunk/content/framework/proposals/filterfactory/seq_create_filter.gif
    svn:mime-type = image/gif

Added: incubator/ooo/ooo-site/trunk/content/framework/proposals/filters/exportfilters.html
--- incubator/ooo/ooo-site/trunk/content/framework/proposals/filters/exportfilters.html (added)
+++ incubator/ooo/ooo-site/trunk/content/framework/proposals/filters/exportfilters.html Fri Nov 25 20:00:55 2011
@@ -0,0 +1,115 @@
+	<META HTTP-EQUIV="CONTENT-TYPE" CONTENT="text/html; charset=windows-1252">
+	<META NAME="GENERATOR" CONTENT="StarOffice 6.0  (Win32)">
+	<META NAME="AUTHOR" CONTENT="Mathias Bauer">
+	<META NAME="CREATED" CONTENT="20020320;11105752">
+	<META NAME="CHANGED" CONTENT="20020320;17323202">
+<BODY LANG="de-DE">
+<H2>Proposal for a unified API for exporting and saving documents</H2>
+<P>Impress has two different kinds of export filters. Some of them
+can be used for &bdquo;SaveAs&ldquo; (like PowerPoint and StarOffice
+binary filters), some of them are only accessible throuh the &bdquo;Export&ldquo;
+function. While the first kind of filters can be used via API (
+com::sun::star::XStorable::store(To/AsURL) ), the second kind of
+filters can't. We want to change this, and the most natural way is to
+use the same API for both. The &bdquo;Export&ldquo; functionality in
+the user interface will use this API in the same way the &bdquo;SaveAs&ldquo;
+functionality does it, with some slight differences:</P>
+	<LI><P>&bdquo;Export&ldquo; uses storeToURL, SaveAs uses storeAsURL.
+	The difference is, that the latter method also changes the URL of
+	the document in memory.</P>
+	<LI><P>This implies that it's not possible to use a pure export
+	filter in the storeAsURL method, because the generated file would
+	not be importable. Pure export filters can only be used in the
+	storeToURL method. Using a wrong filter will cause throwing of an
+	exception.</P>
+	<LI><P>To ease the implementation to find out which filters shall be
+	used in which funtion, &bdquo;Export&ldquo; uses only pure export
+	filters, while &bdquo;SaveAs&ldquo; only uses filters that can both
+	import and export. If an Import/Export filter should also be used
+	for &bdquo;Exporting&ldquo;, another filter must be created in the
+	filter configuration for the same file type, but without the
+	&bdquo;Import&ldquo; flag set. If new filters are created in the
+	configuration, they can get the same UI names as the old
+	import/export filter (because they won't be seen in the same file
+	dialog), but must get a new internal filter name. Filter names of
+	import filters must not be changed, because they may have been used
+	before. If an import filter shall not be used in the &bdquo;SaveAs&ldquo;
+	dialog, they must not have the &bdquo;Export&ldquo; flag set, use a
+	different filter ony for export.<BR>We will have three kind of
+	filters then: pure import filter (document can't be stored over the
+	old file after loading), pure export filters (saved document is not
+	loadable again, so this filter will be used only in the &bdquo;Export&ldquo;
+	function) and combined import/export filters.</P>
+	<LI><P>Export filters support an additional property
+	&bdquo;ExportSelection&ldquo; in the media descriptor, that tells
+	the filter to export only the current selection and not the whole
+	document. This will be reflected by a checkbox in the file dialog.</P>
+<P>All parameters to configure the export operation will be passed in
+the &bdquo;FilterData&ldquo; property of the media descriptor that is
+passed to the filter (implemented as sequence&lt;PropertyValue&gt;).
+If there is no configuration data given, the filter must use some
+suitable defaults. 
+<P>In the user interface it's also possible to provide a UI component
+that retrieves the needed information and adds it to the media
+descriptor. If the filter wants, it can also store the input in a
+configuration file and use it as default in the next operation
+without given parameters. Here also the &bdquo;UserData&ldquo;
+parameter of the Typedetection.xml can be used for storing the
+configuration. This is only possible for data representable as a
+string, but the advantage is that the default for the filter can be
+specified in the Typedetection.xml, not in the source code. In this
+case the filter implementation first must look for &bdquo;FilterData&ldquo;,
+then for &bdquo;UserData&ldquo;.</P>
+<P>The UI component is identified by an implementation name in the
+filter configuration (Typedetection.xml). The UI code for the
+&bdquo;Export&ldquo; function will look into the configuration and
+instantiate the UI component. The exact interface for this component
+will be specified in a different proposal, it should use a media
+descriptor as input/output paremeter and return a boolean value, that
+will be set to &bdquo;false&ldquo; if the user cancels the operation.</P>
+<P>The UI component is not restricted for usage inside the &bdquo;Export&ldquo;
+functionality. We will also have this new feature for the filters
+used for loading and storing documents.</P>
+<P>At the end we will have one single API for storing or exporting
+documents, one single set of filters with a common API, only the two
+UI functions will use it in two different ways. This API also enables
+other developers to provide export filters for OO.o documents using
+our filter API, with the additional capabilities of exporting only
+parts of the document.</P>
+<P>Of course this mechanism can be used in other office components
+	<LI><P>Extend Typedetection.xml for new implementation name for UI
+	component and change filtercache implementation. Make sure that the
+	compatibilty to 6.0 is preserved.</P>
+	<LI><P>Provide properties &bdquo;ExportSelection&ldquo; and
+	&bdquo;FilterData&ldquo; in media descriptor and SfxItemSet at
+	SfxMedium.</P>
+	<LI><P>Divide filters into import, export and import/export filters.</P>
+	<LI><P>Create interface for the UI component.</P>
+	<LI><P>Implement a UI component for all current export filters and
+	register it for all of them in the configuration.</P>
+	<LI><P>Move the old &bdquo;core&ldquo; code from the FuExport to the
+	ConvertTo method in Impress.</P>
+	<LI><P>Offer SID_EXPORT in SFX that will look for the UI component
+	and feed the API call.</P>
+	<LI><P>Check for pure export filters in storeToURL and for pure
+	import filters in store calls.</P>
+	<LI><P>Enable the current code for loading and storing documents to
+	use the filters UI components.</P>
+	<LI><P>Document all parameters of our current export filters.</P>
\ No newline at end of file

Propchange: incubator/ooo/ooo-site/trunk/content/framework/proposals/filters/exportfilters.html
    svn:eol-style = native

Added: incubator/ooo/ooo-site/trunk/content/framework/proposals/helpagent/HelpAgentProposal_01.htm
--- incubator/ooo/ooo-site/trunk/content/framework/proposals/helpagent/HelpAgentProposal_01.htm (added)
+++ incubator/ooo/ooo-site/trunk/content/framework/proposals/helpagent/HelpAgentProposal_01.htm Fri Nov 25 20:00:55 2011
@@ -0,0 +1,272 @@
+	<META HTTP-EQUIV="CONTENT-TYPE" CONTENT="text/html; charset=iso-8859-1">
+	<TITLE>Proposal for a new Help Agent</TITLE>
+	<META NAME="GENERATOR" CONTENT="StarOffice/5.2 (Solaris Sparc)">
+	<META NAME="CREATED" CONTENT="20010209;15581100">
+	<META NAME="CHANGED" CONTENT="20010209;15581700">
+	<META NAME="CLASSIFICATION" CONTENT="Help Agent in StarOffice /">
+	<META NAME="KEYWORDS" CONTENT="User assistance, documentation, help system, Help Agent">
+	<!--
+		@page { size: 21cm 29.7cm; margin: 2cm }
+		P { margin-bottom: 0.21cm; font-family: "sunserif regular", "SunSerif-Regular", "Geneva", "Arial", "Helvetica", "Lucida Sans", Sans-Serif; font-size: 10pt; page-break-before: auto }
+		H1 { margin-top: 0.63cm; margin-bottom: 0.21cm; font-family: "sunsans demi", "SunSans-Demi", "Geneva", "Arial", "Helvetica", "Lucida Sans", Sans-Serif; font-size: 14pt; font-weight: demi-bold; page-break-before: auto }
+		H2 { margin-bottom: 0.21cm; font-family: "sunsans demi", "SunSans-Demi", "Geneva", "Arial", "Helvetica", "Lucida Sans", Sans-Serif; font-size: 12pt; font-weight: demi-bold; page-break-before: auto }
+	-->
+	</STYLE>
+<P ALIGN=CENTER STYLE="margin-top: 0.42cm; page-break-after: avoid"><FONT FACE="Sunsans Heavy"><FONT SIZE=4 STYLE="font-size: 16pt">Proposal
+for a new Help Agent</FONT></FONT></P>
+<P ALIGN=CENTER STYLE="margin-top: 0.42cm; font-style: normal; font-weight: demi-bold; page-break-after: avoid">
+<FONT FACE="sunsans heavy, SunSans-Heavy, Geneva, Arial, Helvetica, Lucida Sans, Sans-Serif"><FONT SIZE=4>Version
+1, Lutz H&ouml;ger, 02/09/2001</FONT></FONT></P>
+<DIV ID="Table of Contents1">
+	<DIV ID="Table of Contents1_Head">
+		<P STYLE="margin-top: 0.42cm; font-weight: medium; page-break-after: avoid">
+		<FONT FACE="Sunsans Demi"><FONT SIZE=4>Table of Contents</FONT></FONT></P>
+	</DIV>
+	<P STYLE="margin-bottom: 0.2cm"><FONT FACE="SunSans-Demi"><A HREF="#1.Preface|outline">Preface</A></FONT></P>
+	<P STYLE="margin-bottom: 0.2cm"><FONT FACE="SunSans-Demi"><A HREF="#2.Problem|outline">Problem</A></FONT></P>
+	<P STYLE="margin-bottom: 0.2cm"><FONT FACE="SunSans-Demi"><A HREF="#3.Solution|outline">Solution</A></FONT></P>
+	<P STYLE="margin-bottom: 0.2cm"><FONT FACE="SunSans-Demi"><A HREF="#4.Details|outline">Details</A></FONT></P>
+	<P STYLE="margin-left: 0.5cm; margin-bottom: 0.2cm"><FONT FACE="SunSans-Demi"><A HREF="#4.1.WhenshouldtheHelpAgentbetriggered?|outline">When
+	should the Help Agent be triggered?</A></FONT></P>
+	<P STYLE="margin-left: 0.5cm; margin-bottom: 0.2cm"><FONT FACE="SunSans-Demi"><A HREF="#4.2.Let'sgetvisual|outline">Let's
+	get visual</A></FONT></P>
+	<P STYLE="margin-left: 0.5cm; margin-bottom: 0.2cm"><FONT FACE="SunSans-Demi"><A HREF="#4.3.UsingtheHelpAgent|outline">Using
+	the Help Agent</A></FONT></P>
+	<P STYLE="margin-left: 0.5cm; margin-bottom: 0.2cm"><FONT FACE="SunSans-Demi"><A HREF="#4.4.Advancedfeatures|outline">Advanced
+	features</A></FONT></P>
+	<P STYLE="margin-left: 0.5cm; margin-bottom: 0.2cm"><FONT FACE="SunSans-Demi"><A HREF="#4.5.ConfiguringtheHelpAgent|outline">Configuring
+	the Help Agent</A></FONT></P>
+	<P STYLE="margin-bottom: 0.2cm"><FONT FACE="SunSans-Demi"><A HREF="#5.ImplementationSteps|outline">Implementation
+	Steps</A></FONT></P>
+	<P STYLE="margin-bottom: 0.2cm"><FONT FACE="SunSans-Demi"><A HREF="#6.OpenIssues|outline">Open
+	Issues</A></FONT></P>
+<H1><A NAME="1.Preface|outline"></A>Preface</H1>
+<P>This short proposal doesn't claim to completely cover all aspects
+of the subject, even though I'm trying to propose the feature as
+complete as possible.</P>
+<H1><A NAME="2.Problem|outline"></A>Problem</H1>
+<P STYLE="margin-bottom: 0.2cm"><FONT FACE="Sunserif Regular">When
+working with StarOffice / (SO / OO.o) there are
+various situations where the program 'decides' to act in a certain
+way that might not have been expected by the user. Some examples for
+this are: </FONT>
+<UL STYLE="margin-left: 0.5cm">
+	<LI><P STYLE="margin-bottom: 0.2cm"><FONT FACE="Sunserif Regular">the
+	'AutoCorrect' feature automatically completes a word the user has
+	just started to type</FONT></P>
+	<LI><P STYLE="margin-bottom: 0.2cm"><FONT FACE="Sunserif Regular">the
+	same feature automatically creates a bullet list from plain text
+	while typing (type '- test', press Enter)</FONT></P>
+	<LI><P STYLE="margin-bottom: 0.2cm"><FONT FACE="Sunserif Regular">the
+	'Print' dialog box is shown even though the user has clicked on the
+	'Print File Directly' symbol in the 'Function Bar' (because there
+	was a mismatch between the default system printer and the printer
+	stored in the document)</FONT></P>
+<P STYLE="margin-bottom: 0.2cm"><FONT FACE="Sunserif Regular">To
+simplify it: from a user's point of view in some situations a program
+behaves unpredictably. No matter how hard we try to avoid these
+cases, in certain situation the expectations of users simply are too
+<H1><A NAME="3.Solution|outline"></A>Solution</H1>
+<P STYLE="margin-bottom: 0.2cm"><FONT FACE="Sunserif Regular">The
+first and very simple idea is to tell users what's happening, e.g.
+use some plain text explaining the current behavior. We tried that in
+SO 5.x, using the so called Help Agent. In the current SO / OO.o
+release (614) there is no such information any more. </FONT>
+<P STYLE="margin-bottom: 0.2cm"><FONT FACE="Sunserif Regular">Due to
+the lack of this feature, we can now see the real benefit of this
+mechanism. It helps users in getting out of 'screen mysteries', it
+offers support when users actually need it. So this proposal is about
+the re-implementation of the Help Agent feature to be more elegant,
+more intelligent but also less annoying than formerly.</FONT></P>
+<H1><A NAME="4.Details|outline"></A>Details</H1>
+<H2><A NAME="4.1.WhenshouldtheHelpAgentbetriggered?|outline"></A>When
+should the Help Agent be triggered?</H2>
+<P>The most important feature of the Help Agent is to 'proactively'
+(I don't know any better word) offer support in certain situations.
+This distinguishes it from common help systems which offer help only
+if a user asks for it, e.g. by hitting the 'help' button. The Help
+Agent needs to detect if the user performs an action that may lead to
+confusion or that's generally difficult to understand in order to
+present helpful information to the user.</P>
+<P>The detection of these situations is a quite critical part of the
+Help Agent. The range of implementations for this goes from a static,
+pre-defined list (like in SO 5.x) to some artificial intelligence
+driven agent analyzing the user's behavior and thus detecting usage
+problems. The compromise between release driven reality and feature
+theory lies somewhere in-between. 
+<P>I think it's best to start with the simple list implementation and
+advance to something more sophisticated later. A list of situations
+that require user assistance already exists in SO 5.x and can be
+maintained based upon the feedback from our users, e.g. by evaluating
+the FAQ lists that are regularly generated by Sun's Support. 
+<H2><A NAME="4.2.Let'sgetvisual|outline"></A>Let's get visual</H2>
+<P>When designing the UI of the new Help Agent, we tried to follow
+the paradigm 'K.I.S.S.' (keep it short &amp; simple). SO 5.x users
+sometimes did complain about the old Help Agent. Very often the first
+thing that was done with it was to disable this feature completely,
+because it was rather irritating than helpful. That was caused by two
+aspects: The window showed up automatically but had to be closed
+again manually, and the content wasn't appropriate for the majority
+of our users - beginners.</P>
+<P>To change the content of the help system is one thing. It's safe
+to say that it will take some time to be accomplished and the whole
+process will probably span a couple of SO / OO.o releases. Fixing the
+usability issue should be possible soon, so let's have a look at a
+first UI design idea. 
+<P>Here's a mock-up screen shot of a typical Help Agent situation:
+The user adjusts some settings that have 'invisible side effects' -
+in this case the spell check for the selected languages only
+functions if the appropriate language has been installed, something
+users very often aren't aware of, if they are just 'playing around'
+with some character formatting settings.</P>
+<P ALIGN=CENTER><IMG SRC="offering.gif" NAME="Graphic1" ALIGN=BOTTOM WIDTH=384 HEIGHT=303 BORDER=0></P>
+<P>Due to the 'SO 5.x help content issue', we decided to initially
+display as few text as possible. This leads to the idea of just
+showing up an image button indicating that help is available.  The
+Help Agent gets triggered and shows up in the lower right corner of
+the current document window. The design of the image above is just a
+placeholder for some artwork that would still have to be created.</P>
+<P>The Help Agent window or indicator should appear on top of the
+current document window but underneath a potentially open dialog box
+that has got the focus. It shouldn't be possible to raise the
+document window's z-order above the Help Agent's one. The current
+focus should remain unchanged so that the user can continue his work
+without being interrupted. (This is exactly the behavior of the Help
+Agent window in SO 5.x.)</P>
+<P>Behind the scenes, the help ID of the control that triggered the
+Help Agent gets forwarded to the Help Agent in order to be available
+for later processing.</P>
+<H2><A NAME="4.3.UsingtheHelpAgent|outline"></A>Using the Help Agent</H2>
+<P>To address the complains about the old Help Agent's stickiness,
+the new Help Agent should disappear after a time-out of 30 seconds.
+If the user doesn't do anything but continue his normal work and
+ignores the Help Agent, the pop-up window simply disappears after
+this time-out. If another item triggers the Help Agent within this
+time-out, the countdown timer should be reset and the new help ID
+should be stored instead of the old one.</P>
+<P>If the user clicks on the Help Agent indicator within the time-out
+timeframe, the help system will be opened and the help related to the
+temporarily stored help ID will be displayed. Starting with SO 6.0 /
+OO.0, the help system is an own operating system task. In case this
+task is already running at the time the Help Agent is used (clicked),
+it simply gets the focus and displays the respective help topic. That
+way, only one help task can be open at the same time.</P>
+<H2><A NAME="4.4.Advancedfeatures|outline"></A>Advanced features</H2>
+<P>Turning the static list of Help Agent relevant help IDs into a
+'semi-static' list could be achieved by dropping items dynamically.
+Whenever the Help Agent detects that his help offer didn't succeed,
+i.e. the user didn't make use of it a couple of times (3? 5? 10?)
+within a certain time (e.g. 90 days), an item can be dropped from the
+list. That way the occurrences of the Help Agent can be minimized
+down to what an individual user actually needs. 
+<P>I'm not sure whether or not it is necessary to manually reset a
+list that has been modified this way to the factory default. But my
+guts tell me that there might be a number of people who want to have
+this feature. 
+<P>So far this is not 'rocket science'. A far more advanced feature
+would be to add new items to the list based on an analysis of the
+program's usage. This could come pretty close to an interactive
+tutor, detecting certain 'inefficiencies' in usage patterns and
+offering the respective shortcuts to the user. This feature itself
+would need a much more extensive description than this proposal is
+supposed to deliver. Maybe someone else wants to pick this up and
+follow upon it?</P>
+<P>Regardless whether or not the typical geek likes it: animations
+are one of those neat features that particularly beginners do like.
+As there is a quite contradictory discussion about this detail, I'll
+leave it open and name it just for the purpose of completeness.</P>
+<P>Something maybe more important to think about is the position of
+the Help Agent indicator. On one hand it brings a certain calmness to
+the user interface, if this window always shows up at the same
+position, on the other hand if this position should ever be occupied
+by something else (like a toolbar or a docked float), it could be
+desirable to open the window somewhere else. SO 5.x had a mechanism
+that tried to position the Help Agent's floating window intelligently
+so that it doesn't cover the currently used dialog box. Of course
+such a feature would be helpful for the new Help Agent's window, too.
+But as the new window should be much smaller than the old one, it
+might be something that can be done later.</P>
+<H2><A NAME="4.5.ConfiguringtheHelpAgent|outline"></A>Configuring the
+Help Agent</H2>
+<P>Even though the new Help Agent tries to be both - as visible as
+necessary and as invisible as possible - there's probably the
+requirement to configure at least some basic settings. 
+<UL STYLE="margin-left: 0.5cm">
+	<LI><P>Advanced users might want to switch the feature completely
+	off; so this option should be offered. This implies that the default
+	should be 'on' ;-)</P>
+	<LI><P>The suggested default time-out of 30 seconds might be
+	something that users want to adjust, too. We should offer a scale
+	from 0 to 60 seconds in 5 second steps, so this can be combined with
+	the above configuration setting ('0 seconds' means 'feature is
+	deactivated'). Or should the two settings be independent from each
+	other?</P>
+	<LI><P>As soon as the Help Agent is able to 'forget' or 'learn'
+	about situations it should show up, there's probably some
+	requirement to reset a modified list to the factory default. 
+	</P>
+	<LI><P>As mentioned above, the position of the Help Agent window
+	should later be configurable if it's not possible to make it evade
+	intelligently .</P>
+<H1><A NAME="5.ImplementationSteps|outline"></A>Implementation Steps</H1>
+<P>Driven by product release reality, I suggest the following three
+steps of implementation. However, if someone thinks this isn't
+appropriate, I would be happy to see an alternative.</P>
+<OL STYLE="margin-left: 0.5cm">
+	<LI><P>The first implementation basically should include anything
+	described in the chapters &quot;When should...&quot;, &quot;Let's
+	get...&quot; and &quot;Using&quot;, plus the basic configuration
+	option of enabling/disabling the feature and justifying the
+	time-out.</P>
+	<LI><P>The addition of the feature &quot;dropping items from the
+	list&quot; and the possibility to reset the list should be the main
+	parts of step 2. In addition to this, the window positioning issue
+	(if at all there is such an issue) should be finalized.</P>
+	<LI><P>The third step could be a mid-term to long-term project,
+	defining and implementing the feature &quot;add new items to the
+	list&quot;, as this would probably affect other projects as well.</P>
+<H1><A NAME="6.OpenIssues|outline"></A>Open Issues</H1>
+<P>These are just a few open issues that would need to be resolved in
+order to achieve step 1 and step 2 of the implementation. Probably
+there are many more if one starts digging into the details, but I
+think these are the most obvious ones.</P>
+<UL STYLE="margin-left: 0.5cm">
+	<LI><P>Artwork for the Help Agent indicator<BR>This should clearly
+	indicate 'click me' and 'there's something you might want to know'</P>
+	<LI><P>Further configuration details<BR>Are the configurable
+	settings sufficient or already too detailed? What are reasonable
+	default values to minimize the necessity of configuring this
+	feature?</P>
+	<LI><P>Window behavior<BR>What about stickiness, movability, focus
+	behavior? 
+	</P>
+	<P STYLE="margin-top: 0.1cm; margin-bottom: 0.2cm"><FONT SIZE=1 STYLE="font-size: 8pt"><SDFIELD TYPE=DOCINFO SUBTYPE=CHANGE FORMAT=DATE SDNUM="1033;1033;MM/DD/YYYY">02/09/2001</SDFIELD>	<SDFIELD TYPE=DOCINFO SUBTYPE=TITLE>Proposal for a new Help Agent</SDFIELD>	Page

View raw message