[gnome-devel-docs/hig-devel] Mention in that in-place progress indicators are preferred to modal progress dialogs windows.

[Calum Benson <calum src gnome org>]

commit ac57f37a308015735c4c92dd6d8a5dd0ab210e01
Author: Matthew Paul Thomas <mpt postinbox com>
Date:   Tue Mar 2 15:41:50 2010 +0000

    Mention in that in-place progress indicators are preferred to
    modal progress dialogs windows.
    
    Replace guidance about progress windows having same title as
    their primary text, which lead to unnecessary redundancy. Advice is
    now that progress window title should summarize the overall operation.

 ChangeLog           |   15 +++++++++++++++
 hig-book.xml        |    8 ++++----
 hig-ch-whatsnew.xml |   11 +++++++----
 hig-ch-windows.xml  |   18 ++++++++----------
 4 files changed, 34 insertions(+), 18 deletions(-)
---
diff --git a/ChangeLog b/ChangeLog
index f481c71..83f6287 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,18 @@
+2009-03-02  Calum Benson <calum benson sun com>
+
+	* hig-book.xml
+	* hig-ch-whatsnew.xml
+	* hig-ch-windows.xml
+
+	Mention in <xref linkend="windows-progress"/> that in-place progress 
+	indicators are preferred to modal progress dialogs windows.
+
+	Replace guidance about progress windows having same title as 
+	their primary text, which lead to unnecessary redundancy. Advice is 
+	now that progress window title should summarize the overall operation.
+
+	Based on patch by Matthew Paul Thomas <mpt postinbox com>
+
 2009-03-03  Calum Benson <calum benson sun com>
 	
 	Fix image to match text, as pointed out by 
diff --git a/hig-book.xml b/hig-book.xml
index c0cf4ed..3f463bd 100644
--- a/hig-book.xml
+++ b/hig-book.xml
@@ -23,11 +23,11 @@
 <bookinfo>
     <author><firstname>The GNOME Usability Project</firstname></author>
 <copyright>
-<year>2002-2008</year>
+<year>2002-2010</year>
 <holder>Calum Benson, Bryan Clark, Adam Elman, Seth Nickell, colin z robertson</holder>
 </copyright>
-<pubdate>2008-09-25</pubdate>
-<edition>2.3</edition>
+<pubdate>2010-03-02</pubdate>
+<edition>2.3.1</edition>
 
 <legalnotice>
   <para>
@@ -51,7 +51,7 @@
   </para>
 </legalnotice>
 
-<title>GNOME Human Interface Guidelines 2.3</title>
+<title>GNOME Human Interface Guidelines 2.3.1</title>
 
 </bookinfo>
 
diff --git a/hig-ch-whatsnew.xml b/hig-ch-whatsnew.xml
index 612bc79..466d689 100644
--- a/hig-ch-whatsnew.xml
+++ b/hig-ch-whatsnew.xml
@@ -4,12 +4,15 @@
   <preface id="whatsnew">
     <title>What's new?</title>
     <para>This section highlights recent changes to the HIG that may affect your application.</para>
-     <para>The following changes were made in HIG v2.2:</para>
+     <para>The following changes were made in HIG v2.3.1:</para>
     <itemizedlist>
-	<listitem><para>Mention deprecation of low contrast icons in <xref linkend="icons-design-accessible"/>
+	<listitem><para>Mention in <xref linkend="windows-progress"/> that in-place progress 
+	indicators are preferred to modal progress dialogs windows.
 		</para></listitem>
     	<listitem><para>
-	    	Updated illustrations throughout.
+	    	Replace guidance in <xref linkend="windows-progress"/> about progress windows having 
+		same title as their primary text, which lead to unnecessary redundancy. Advice is now 
+		that progress window title should summarize the overall operation.
 		</para></listitem>	
     </itemizedlist>
 
@@ -68,7 +71,7 @@
 	    <listitem><para>
 		<xref linkend="windows-primary"/>
 		</para></listitem>
-
+	    
 	    <listitem><para>
 		<xref linkend="windows-utility"/>
 		</para></listitem>
diff --git a/hig-ch-windows.xml b/hig-ch-windows.xml
index 8771601..60da42d 100644
--- a/hig-ch-windows.xml
+++ b/hig-ch-windows.xml
@@ -1730,13 +1730,11 @@ saved, in case an error occurs.  Then hide the document window immediately after
     during an operation that takes more than a few seconds. See <xref
     linkend="controls-progress-bars" /> for more details about proper use of
     progress bars.</para>
-	<para>A progress window may appear in the panel window list if it
-	is, or may be, the only window shown by an application. For example,
-	the file download progress window of a web browser may remain after
-	all the browser windows have been closed.</para>
-	<para>Otherwise, a progress window should be raised above the
-	application when the application window itself is selected from the
-	window list.</para>
+		
+    <para>A progress window should always appear as an independent window in a window list.
+	If progress of a task makes a window temporarily unusable, do not present a modal dialog-like progress window in front of it.
+	Instead, present progress somewhere in the original window, making all its other elements temporarily insensitive.
+	This helps reduce visual clutter.</para>
 
     <figure id="example-progress-figure">
       <title>An example of a progress window</title>
@@ -1764,9 +1762,9 @@ saved, in case an error occurs.  Then hide the document window immediately after
     <formalpara>
       <title>Title Format</title>
 
-      <para>Progress windows should have the same title as their primary text.
-      Unlike alerts, it is expected that progress windows will be present in
-      the window list and may be active for extended periods.</para>
+      <para>Progress windows should have a title representing the overall
+      operation: for example <guilabel>Copying Files</guilabel>, <guilabel>Installing</guilabel>, or <guilabel>Calling</guilabel>.
+      As with other window titles, do not end progress window titles with an ellipsis.</para>
     </formalpara>
 
     <formalpara>