Matthew Paul Thomas wrote on 22/02/10 17:13:
This patch makes small changes to the HIG's "Progress windows" section.
* New: "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."
* Removed: "Progress windows should have the same title as their
primary text." (This guideline has often caused redundancy in
progress windows, e.g.
<http://www.dedoimedo.com/images/computers/pendrivelinux_ubuntu_installing.jpg>.
It also usually causes the window
title to inappropriately use header capitalization.)
* Added: "Progress windows should have a title representing the
overall operation: for example “Copying Files”, “Installing”, or
“Calling”. (As with other window titles, do not end progress window
titles with an ellipsis.)"
Attached.
--
Matthew Paul Thomas
http://mpt.net.nz/
diff --git a/hig/C/hig-ch-windows.xml b/hig/C/hig-ch-windows.xml
index 078b70e..f7075be 100644
--- a/hig/C/hig-ch-windows.xml
+++ b/hig/C/hig-ch-windows.xml
@@ -1720,13 +1720,10 @@ 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>
@@ -1749,9 +1746,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 “Copying Files”,
“Installing”, or “Calling”.
+ (As with other window titles, do not end progress window titles with an
ellipsis.)</para>
</formalpara>
<formalpara>
_______________________________________________
Usability mailing list
Usability@gnome.org
http://mail.gnome.org/mailman/listinfo/usability
