An Application Design Guide 
for Microsoft Windows (Chicago)


Table of Contents


NOTE:  This document should be considered a preliminary
release, intended for review.  As a result it is still
subject to change and information included does not
necessary imply a commitment by Microsoft to support
all the conventions suggested in the final product.

Introduction
This design guide provides guidelines for developing
user interfaces for applications that run in the Microsoft
Windows graphical environment.  Its purpose is to promote
visual and functional consistency within and across
Windows-based applications.  
Overview
Windows (Chicago) is the advent of the evolution of
GUI to OOUI; that is, a more data-centric/object-centric,
rather than application-centric, interface; a continuation
of the design direction portended by OLE.  As a result,
application developers/designers may need to rethink
their applications in terms of what are their basic
components and the respective operations and properties
that apply to those objects.  This is particularly important
since long term, from the user's perspective, the application
is destined to become as transparent to the user as
the code which manages menus.  The user's data/information
(and tasks associated with that data) will become the
major focus on the user interface. 

The UI design aspects that an application developer/designer
needs to consider in terms of evolving their software
to fit in the Windows interface include:
  Title bar icons
  Property sheets
  Transfer model (including drag and drop)
  Pop-up menus
  New controls (e.g., sizable scroll boxes, new common
dialogs)
  Interfacing with the shell (explorer views, scraps,
system menu)
  Help interface
  Object linking and embedding
  Visual design of windows, controls and icons
  Window management (MDI/SDI, workspaces, workbooks)
  Use of minimized windows

These are covered more in depth throughout this document.

Purpose
These guidelines are intended for developing for Windows.
They supercede those issued for Windows version 3.1.

How to Use This Book
Why this book was written, what it contains, and what
it doesn't contain.
How to Apply the Guidelines
A discussion about the recommended guidelines, describing
how to apply them and reiterating taht they are simply
guidelines--not requirements
Conventions
How the formats used in the document should be interpreted.


Principles of Good UI Design
It is impossible for a UI design guide to capture every
situation that a software designer/developer may need
to apply.  This section summarizes some of the basic
principles that have been used in the development of
Windows so that a designer can extend the intent of
the overall design.
User Interface Principles 
A brief overview of the basic principles such as user
control, consistency, feedback, etc.  
Bibliography
Basic Concepts
Data/Document Centricity
The Windows 4.0 user interface is based on a data/document
centric design.  Specifically this means that user interface
design revolves around data and tasks that involve manipulation
of data rather than applications.  A document is composition
of data of level of granularity that is often used in
a task and exchanged between users.  The design of the
environment is intended to allow users to browse for
data/documents and edit them directly without necessarily
having to first locate an appropriate editor or application.
Such an environment allows users to focus on their information
and tasks rather than applications and how applications
interact.  
Objects
The Windows design model is based on the metaphor of
objects.  Object is a very natural metaphor since it
is the way we percieve the world around us.  Objects
are used to describe not just files or icons, but elements
of the entire environment including cells, paragraphs,
characters, circles as well as the documents that exist
in.

Like their real-world counterparts, objects can be described
through the following basic concepts.  While any one
of these facets can be used to described the others,
these terms have been defined to facilitate discussion
and description of particular aspects of objects as
they are expressed in the user interface.  These elements
contribute to an object's type, a descriptive way of
distinguishing or classifying objects.  Objects of a
common type are expected to have similar traits and
behaviors.  

Components  The nature of the design of objects in the
interface as in the real world is one of construction;
that is, most objects are a composition of other, smaller
objects.  The goal of the user interface is to try to
make the user interaction at any level of granularity
consistent, using a small basic framework which can
be built up to produce very complex constructions. 
For example, a document is an object that can be decomposed
into paragraphs which in turn can be decomposed into
characters.

Operations  Things that can be done with or to an object
are considered its operations.  Examples of operations
are moving or copying an object.  Operations may be
exposed in the interface through a variety of mechanisms.


Properties  Certain characteristics or attributes that
define the appearance or state of an object; for example,
its color, size, modification date are referred to as
an object's properties.

Relationships  Objects always exist within a context
of other objects.  The context or relationships that
an object has may effect the way an object appears or
behaves.  An object may have multiple relationships
with different objects.  Membership, constraints and
containment are all examples of relationships.  

The impact of these concepts will be detailed in later
sections of this document.

The Windows Environment
The Desktop
The Desktop is the fundamental work area, filling the
screen and form the visual backdrop for all operations.
However, the Desktop is more than just a background.
It can actually be used as a convenient place to store
objects that are stored in the file system.  In addition,
for computer connected to a network, the Desktop also
serves as a private work area from which a user can
explore and access objects located in the public world
of the network.  
The System Toolbar
The System Toolbar is a special component of the Desktop
that can be used to access global commands and other
frequently used objects.  As a result, it provides a
home base, an operational anchor for the interface.
Like most application toolbars, the System Toolbar is
configurable.  It can be undocked from its default location
and windowed or re-docked along another edge of the
screen.

Icons
Icons appear on the Desktop and in windows.  These icons
represent objects stored in the file system (are distinguished
from the minimized form of a window).  

Applications should provide icons for the application
and any of its associated data/document files in two
sizes, 16 x 16 and 32 x 32.   If these are not supplied,
the system will automatically generate an icon for the
object.  (More details on the design of icons can be
found in a following section on Visual Design.)

The Windows environment includes a number of basic objects
that are represented as icons including the following:

The File Cabinet, an object that provides access to
objects stored on the user's local computer.


The World, an object that provides access to the network.


The Wastebasket, an object that acts as a temporary
repository for objects that are deleted from the file
system.  


Folders, objects that provide for organizing objects
that are stored in the file system.  


Links, special objects that provide access to other
objects.  Typically, they are used for providing convenient
access to objects that may be stored elsewhere.  

Windows
Windows provide a means of viewing and often editing
objects.  Windows are used to view the contents and
properties of objects, but they may also be used to
display parameters to complete commands, palettes of
controls, or messages informing a user of a particular
situation.

Interaction Basics
Operations or commands should be designed to be contextual
to the selected object they apply to.  That is, the
presentation of commands or properties (or other aspects
of an object) are determined (made visible, accessible)
based on the characteristics of the object itself and
the context (i.e., relationship) it exists in.  

Often the context of an object may add to or remove
the traits of an object. 
Most objects should support the following basic operations:
  Selection
  Transfer
  Viewing
  Transactions 
User Input
Mouse Input 
The mouse is a primary input device for interacting
with objects in the interface.  All basic mouse actions
in the interface use either mouse Button 1 or Button
2.  Button 1 is the leftmost mouse button and Button
2 is the rightmost button.The following are the common
behaviors performed with the mouse:

Pointing, or positioning the pointer so that it "points
to" a particular object on the screen (no mouse button
is used).

Clicking, or positioning the pointer over an object
and then pressing and releasing the mouse button.  The
mouse is usually not moved during the click, and it
is quickly released after it is pressed.  Clicking is
often used for identifying objects so that actions can
be performed on them.

Double-clicking, or positioning the pointer over an
object and pressing and releasing the mouse button twice
in rapid succession.  Double-clicking an object typically
invokes its default behavior/operation.  

Pressing , or positioning the pointer over an object
and then holding down the mouse button.  Pressing is
done as a way to initial a click or drag operation.


Dragging, or positioning the pointer over an object,
then pressing down the mouse button and while holding
the mouse button down, moving the mouse.  Dragging an
object is often used in selection and direct manipulation
of an object.  

Keyboard Input
The keyboard is a primary means of entering or editing
textual information.  However, the Windows interface
also uses keyboard input for facilitating navigation,
to toggle modes, to modify input and as a shortcut means
of invoking certain operations.  
Noun-Verb (Object-Action) Paradigm
The Windows UI model continues to be based on a fundamental
noun-verb paradigm where the object is identified and
then the action is identified.  Most objects require
explicit user selection to identify the object and its
associated action.  However, in some aspects of the
interface the object or action may be implicit.  For
example, dragging a window or scroll bar implies the
operation to be "move".  
Selection
Selection is the means by which a user identifies objects,
actions and properties.  As a result, the basic model
for selection is one of the most important aspects of
the interface.  Selection is typically an overt action
on the part of the user to identify the object.  This
is known as explicit selection.  Once an object has
been selected, then an action can be specified for the
object.  

There are also situations where the identification of
an object can be derived by inference or context.  This
is known as implicit selection.  This method works most
effectively where the object-action intent is simple
and visible, and where the identification of the object
and action are closely joined.  For example, when a
user drags a scroll box, selection and direct manipulation
are established at the same time.  Implicit selection
may also occur based on the relationships of a particular
object.  For example, selecting a character in a text
field may implicitly select the paragraph that the character
is a part of.  

Because many objects can be manipulated as a set, the
interaction model must support the selection of multiple
items as well as individual items.  It also needs to
provide a convenient way for adding or deleting elements
from the set, including objects elements that are logically
contiguous and those that are not (disjoint).

Mouse Selection
Selection using a mouse can be performed with either
button 1 or button 2.  Shift and Ctrl key modifiers
provide support for modifying a selection set.  On the
down transition of the mouse button the starting point
the starting point or anchor point of a proposed selection
is established.  While the button is down the selection
extends to the object logically nearest to the hotspot
of the mouse allowing the range to be dynamically adjusted.
The objects within that range that are included identify
themselves as being selected via feedback (typically,
highlighting or some other change in the state of the
visual state of the object).  The up transition of the
mouse ends the selection operation (though the established
selection set can be adjusted with subsequent selection
operations).  

In most cases, selection is optimized so that creating
a new explicit selection within the same domain of the
existing selection (e.g., view) resets the selection
set to be the new selection.  This allows simple selections
to be done quickly and easily (based on the assumption
that the user typically makes single object or single
range selections most frequently).  An existing selection
set is reset on button down if the pointer hotspot is
outside (not in or on) the selection.  If the pointer
is over a selected item, the button down transition
does not reset the selection.  For example, if the pointer
is moved it is typically interpreted as a transfer operation
(see following section on the transfer model for more
details).  However, the interpretation of the up transition
of the mouse when the pointer is within an existing
selection is dependent of the mouse button.  The up
transition of button 2 displays the contextual pop-up
menu for the object.  The button transition of button
1 is contextual to the object.  In some cases, it may
also reset the selection; in others it may simply designate
a distinguished member of the selection set.

While selection is typically done by positioning the
pointer over an object, it may be inferred based on
how close (logically) to the pointer.  For example,
when selecting text, the pointer may be placed on the
blank area beyond the end of the line and the resulting
selection may be inferred as being the end of the line.

Selection Adjustment
A selection set can be adjusted (elements added to or
removed from the set) using keyboard modifiers.  The
Ctrl key is the disjoint or toggle modifier.  Pressing
the Ctrl key resets the anchor point at the new mouse
down location while the existing selection set is preserved.
The selection state of the object under the pointer
is toggled (if not selected, becomes selected; if already
selected, becomes deselected).  This state is perpetuated
across the range of objects included while the button
is down.  This means if the first item included during
a drag is not selected, it becomes selected as do all
the objects included by the range.  If the first item
included had been selected previously, it becomes deselected
as are all the objects included in the range regardless
of the current selection state.  The Ctrl key must be
depressed before the mouse button to be used for disjoint/toggle
selection.  Otherwise, the operation may be interpreted
as a drag-Copy operation.  However, once a disjoint/toggle
selection is initiated it continues until the mouse
button is released (even if the Ctrl modifier is released
before the mouse button).  

Shift is the adjust/extend range key.  It is used to
adjust (actually resets) the selection set from the
most recent anchor point.  It continues that selection
state to the button down point and tracks with the pointer
to the object nearest to the button up point.  The anchor
point is not changed and existing selections not established
from the current anchor point are preserved.  The effect
on the selection state is based on the first item included
by the selection.  If the first becomes selected, then
all objects included in the range become selected. 
If the first item becomes deselected, then the objects
included all become deselected.  

The Shift must be pressed before the mouse button is
pressed to initiate the adjust/extend range mode and
it continues (even if the modifier is release) until
the button is released. 

The Shift adjust/extend selection modifier can be considered
as a continuation of a drag or Ctrl+Drag selection.
For example:  

Drag


This same result can be accomplished with--

Drag,


then Shift+Drag (from anchor point first to the button
down and track to button up).



The next example illustrates how Ctrl+Drag may be used
for disjoint selection.

Drag,


then Ctrl+Drag (to do the disjoint selection--anchor
point is reset at the button down point).



Shift+Drag allows the last (disjoint) selection to be
adjusted.

Drag,


then Ctrl+Drag, 


then Shift+Drag (which adjusts the selection from the
anchor point first to the button down point and tracks
to the button up).


The following table summarizes the mouse/keyboard selection
operations:

Operation Mouse (and keyboard combination)   Select
item/range Click/Drag  Disjoint/toggle selection
state of  non-contiguous item/range Ctrl+Click/Drag  Adjust
(extend) current selection Shift+Click/Drag  
The tables in the appendix of this document summarizes
the mouse interface including selection behavior.

All drag selections are dynamic in that the selection
state changes as the pointer is moved during the drag
not only in terms of selecting the object included,
but also deselecting it when the pointer retreats or
otherwise is moved such that the object is no longer
included.  

Hierarchical Selection
Range selections are typically made of objects at the
same (hierarchical) level.  However, a range selection
may elevate to the next level if it extends beyond the
frame of the object (but within the same window).  It
will return to the original level if the range is adjusted
back within the frame of the start of the range.  For
example, dragging from within a cell in a table to the
next cell should elevate the selection from the character
to the cell, but retreat back to the individual characters
if the pointer moves back into the cell.  

Region Selection
In z-ordered contexts, a selection may begin (button
down point) not on an object.  In this case, to determine
the range of the selection, a bounding region is drawn
(typically a rectangle, but other shapes may be possible)
while the button is held down and the pointer is moved
(a form of drag selection).  All objects that are intersected
or contained within the bounding region are considered
to be affected by the selection rules already described.
If the Shift or Ctrl modifier is used the selection
set is appropriately changed.  The decision whether
to include an object based on whether it is totally
enclosed within or simply intersected by the bounding
region  is based on the context of the application.
Selection visualization should be provided so that the
user can determine this while doing the selection operation.


Scope of Selection 
The scope of a selection of objects that properties
may be requested together is dependent to visual peers.
If the objects are considered to be in the same visual
plane, then they may be considered the same selection
set.  For example, a folder icon and a document icon
appearing in the same view of a window may be selected
as a set.  Yet their selection is independent of the
selection of the scroll bar, a menu or even the window
itself.  So the scope of selection is also the scope
of what properties may be displayed.  

Selection visualization
All drag (unmodified or modified) selections should
provide feedback dynamically such that as the drag is
done, each object included is displayed with selection
visualization.  Each object is responsible for providing
its own selection appearance (to distinguish it from
normal appearance).  
Interface Mechanisms for Displaying Operations
The operations of objects can be invoked by several
mechanisms in the UI, including direct manipulation
of the object itself, direct manipulation of an object's
control point (i.e., handle), menu commands, buttons,
dialog boxes, tools or programming.  Support for a particular
mechanism is not exclusive to other mechanisms.  For
example, an object may have a "Size" command on its
menu as well as a sizing handle.  Applications designed
for the Chicago environment should make frequent use
of pop-up menus to present the operations of an object.
(See later section on Pop-up Menus.)  
Operations on a Multiple Selection
The operations available for a selection of objects
should be the result of an intersection of the operations
of the members of the set.  In addition, an object's
container may add to or filter out what commands are
displayed to the user.  Likewise, the scope of what
operations are displayed in the interface are limited
to the scope of the selected objects.  Selecting a word
in a document being viewed in a window provides access
to the operations of the word, but not necessarily to
the operations of the view or the window or a selection
in another window. 

It is possible for a particular member(s) of a selection
to determine the effect of a command for a multiple
selection.  For example, when selecting a set of graphic
objects, selecting an alignment command could be based
on a particular item identified in the selection set.

View Operations
The following basic operations associated with viewing
an object.  Viewing often affords editing as well. 


Open  Opens a window, typically the primary view of an
object(s).  For container objects like folders and documents,
this means display the contents of the object.  If the
object being viewed is editable, it usally also means
to permit editing of the object through the window.


Close  Closes a window.  Closing a window does not necessarily
mean closing the process associated with the object
being viewed.  

Properties  Displays the properties of an object(s),
typically in a property sheet window.  

Help  Displays a window with the contextual help view/information

of an object(s).

Opening a new window should always display it at the
top of its z-order (of its peer windows) and make it
active.  This means that a supplemental window of a
particular application is displayed at the top of its
local z-order, not of all windows being displayed. 


Repeated View Operations
If the window or view of an object is already open,
invoking its view command a second time generally restores
the window.  However there are exceptions.  For example,
for the Open command, the following are the recommended
conventions:

For a document/data file Restores the window/view of
the object.  Its window is displayed at the top of the
z-order.  For an application file Presents a list
of the open instances and offers the user the option
to switch to a particular instance or create a new instance.  For

an MDI document file already open Restores the window/view
of the object; i.e., the MDI parent window comes to
the top of the z-order and the document appears at the
top of its z-order within the MDI frame.  For an MDI
document file not already open, but its associated MDI
application is already running.   Opens a new instance
of the MDI application (at the top of the z-order) loaded
with the document window.    
View Shortcuts
Double-click   (Button one)  Opens the object.  However,
note that double-click does not always mean to open
a view of an object.  Double-click means to execute
the default command of the object.  If the default operation
is Open, a window with the main/primary view of the
object is displayed.  Some objects may not have a "content"
view and may display a properties view of the object
instead.  Others may prefer to execute another command.
For example, a macro or sound object might have "Run"
or "Play" as their default command.

  (Button two)  This is the recommended shortcut for
accessing the properties view of an object.

Enter  Like button 1 double-click, this shortcut is contextual
in terms of its use as a shortcut, but it may be used
to open the default view of an object.

Ctrl+O  This is the recommended shortcut for the "Open"
command.

F1  This is the recommended shortcut for the "Help" command.
Transfer Operations
The Chicago transfer model is an interface designed
to provide a consistent and unified interface for transferring
and repositioning objects as well as creating new objects.
The transfer paradigm is made of the selection of an
object, the selection of a transfer operation and then
the selection of the destination object.  The destination
must be supplied before a transfer operation is complete.
Either the source object or its potential destination
may determine whether a copy operation is available
or successful.  

The basic transfer model is composed of the following
three fundamental operations:

Move  "Move" means to relocate or reposition the selected
object.  "Move" should not change the basic identity
of an object, therefore, a "Move" operation is not the
same as a copy with delete of the original.   

Copy  "Copy" means to make a duplicate of an object.
The resulting object is independent of its original.
A copy operation is usually deep with respect to those
aspects that may be duplicated.  For example, some of
an object's properties may be different.  For example,
copying an object may require a difference in its name
or creation date.   Likewise, if some component at a
lower level restricts copying (e.g., a document in a
folder), then the unrestricted elements are copied.


  Copy provides a creation paradigm in the interface.
Creating a new object is conceptually accomplished by
copying some existing object.  

Link  Link creates a connection between two objects.
The result is usually an object in the destination that
provides access to the original.  

Transfer Command Model
The basic transfer model includes both a command based
model where the user explicitly selects the operation
to be performed, as well as a direct (drag) manipulation
method model where the resulting operation may be explicit
or implicit.  Both techniques are important since each
has its advantages depending on the context and the
experience of the user.  

The command model is a two part process.  This allows
a transfer operation to be as modeless as possible since
the user may need to perform intermediate operations
before the transfer can be completed.  The user initiates
a transfer operation by identifying the source via selection
and invoking its menu (pop-up and/or dropdown) and selecting
the preferred operation.  The command names for the
basic operations are the same as the operations themselves;
"Move", "Copy", and "Link". The object's container may
determine which operations may be supported. 



To complete the operation the user moves to the destination
object, invokes its menu and selects its transfer completion
command.  Typically, this will be a menu entry that
includes the word "Put", a description of the object
(the object's name or type) and the word "Here".  



"Put Here" also appears on the initial menu of the object
being transferred even if there is no object pending
transfer (though in this case it would be disabled)
to provide symmetry of menu structure.

It is recommended that "Put object description Here"
format be used for most common transfers to provide
for consistency in the interface.  However, the destination
may modify the completion verb to provide more information
about the resulting operation.  For example, a destination
uses the words "Copy of" or "Link to" as part of the
destination command to indicate the result of the transfer.
"Put Copy of Cell B1 Here" is an example of a "Copy"
completion command.  

A destination may also reinterpret (or potentially even
disallow) the original operation.  Using a printer object
as the sample destination and the original transfer
command selected was "Move", the completion command
could be "Put Copy of object Here" or even "Print object
Here".  

Partial transfers (where a subset of an object,e.g.,
properties) or transforms (where an operation is applied
along with the transfer, e.g., transpose) are handled
similarly.  The destination may offer an additional
command to handle this using the same semantic format
and postpending the word "As"; for example,  Put-Object/Type
Here As.  The choices can either be provided in a dialog
or as a submenu.  




After an object transfer operation has been completed
and before another is initiated, a destination may continue
to provide a completion command using the original source
as an argument without having to reinitiate the operation.
For example, if you select some text in a document,
then select "Move" as the operation, and then complete
the transfer by selecting "Put Text Here" in the destination
to complete the operation, reselecting another location
may provide "Put Text Here" enabled on the menu.  This
allows users to repeat commands efficiently.  

The new transfer model continues to the Clipboard as
the way to retain the description of the object between
when a transfer operation is initated and when it is
completed.  Like Clipboard transfers, if a new command
based transfer operation is initiated before a pending
one is completed, the new operation/object replaces
the existing one.

If a transfer initiation command is invoked and then
that object is destroyed before the transfer is completed
(i.e., a transfer completion command is invoked), then
the transfer operation is aborted.  The container that
placed the description of the object to be transferred
on the Clipboard should remove its notation if possible.

If a transfer operation is initiated on an object and
the window with the view of the object is closed, its
description should be preserved so that the operation
can be still be completed.  If it cannot do this, it
may instead transfer the object to the Clipboard prior
to closing.  If the Clipboard cannot maintain the object
in its original form, then a message dialog should be
displayed with the notification that this is the case
and offering a choice as to whether to proceed with
retaining the degenerate form.  


Transfer Direct Manipulation Model
The conceptual model for direct manipulation transfer,
or drag and drop, is essentially the same as the command
model in that the source, transfer verb and destination
are all a part of completing the operation.  The drag
model can be considered a shortcut method of applying
the command model.  

While the two models are similar, they are functionally
independent.  Specifically this means that a transfer
operation initiated with the command method is unaffected
by a drag transfer.  So you may invoke "Move" on an
object, drag another object right next to it, and still
be able to complete the transfer of the original identified
object.  This also means that a drag transfer operation
is completed at the end of the drag operation.  It is
not a candidate for a repeated transfer completion command.
In other words, if you "Drag-Copy" an object you cannot
go to another destination and expect to use "Put Copy
of object/type Here".  

Objects can be  transferred by dragging the object with
either Button 1 or 2.  The button used determines which
of the two methods is used.  

Default (Button 1) Drag and Drop
Dragging an object with Button 1 is referred to as "default
drag and drop" because the interpretation of the operation
is determined by what the destination considers to be
the default interpretation of the transfer operation.
Most commonly, the default transfer operation is "Move",
but the context of the operation (e.g., type of object,
type of destination) may reinterpret the operation to
be whatever is most important.  Therefore, a default
drag and drop operation could be reinterpreted as "Copy"
or "Link".  The transfer operation is completed when
the mouse is released at the destination.  

Non-default (Button 2) Drag and Drop
Dragging an object with Button 2 is referred to as "non
default drag and drop".  In this case, rather than completing
the transfer, a pop-up menu is presented when the mouse
button is released at the destination.  The menu contains
the appropriate transfer completion commands; typically
"Move Here", "Copy Here", and "Link Here".  



The destination still can filter and display only the
appropriate commands, including offering an alternate
completion command(s).  

Drag Transfers and Drag Selection
Drag selection must be differentiated from drag transfers.
This is determined based on where the pointer is located
at the beginning of the drag.  If the pointer is within
an existing selection, then the drag is interpreted
to be a drag transfer operation.  If the drag begins
outside of an existing selection, then the drag is interpreted
as a selection operation.  

Drag Transfer and Scrolling
When the user drags an object within a scrollable region
and reaches the edge of that region, an interpretation
must be made as to whether to scroll the region or to
assume that the intent is to transfer the object outside
the region.  This is accomplished by the use of timing
and proximity.  During a transfer operation, if the
pointer remains within a fixed distance from the edge
of the region for a short delay (50 milliseconds), then
the region is scrolled.  If the user does not pause
within this distance for at least the timeout period
or at any time (even if scrolling has been initiated)
moves the pointer outside this scroll detection area,
scrolling ceases and the drag is reinterpreted as a
drag transfer operation (which also resets the scroll
detection timeout).

Transfer Feedback
During a drag operation, visual feedback is provided
on the source object, on the pointer and at the destination.
Specifically, 

  The source remains highlighted (selection visualization)
while its view has the focus.  It may also display some
additional visualization to indicate that it is in a
transfer state.  (This state may change based on the
default completion operation supported by the destination
the pointer is currently over.)

  An outline or translucent (so as not to obscure potential
destination targets) representation of the object moves
with the pointer.  The source is responsible for providing
the initial visualization, which may be changed by any
destination.


  The interpretation of the transfer operation is displayed
to the right of the stem of the pointer.  No additional
glyph means the operation is interpreted as "Move".
A "plus" character (+) means the interpretation is "Copy".
An "equal sign" character (=) is used for "Link".

*Note that currently the OLE specification uses the
"equal sign" character.  However,  a pair of "greater
than" symbols (>>) are used to indicate a file link.
We are considering changing the OLE usage to be the
same.  

  Potential destinations indicate their receptivity
as targets.  Objects may simply highlight and additionally,
animate or display a representation of the transfer
object in the destination.  

When the transfer is completed, the object transferred
appears selected in the destination's view (if the view's
window is opened).  

While the transfer operation is in progress, a representation
of the source object remains at the original location
since, in most cases, the interpretation of the operation
cannot be determined until the operation is complete.
In addition, it provides a convenient visual reference
point.  

Shortcut Keys
In addition to the menu and drag based methods of transfer,
there are some suggested shortcut methods for supporting
the transfer operations.

Ctrl key  The Ctrl (Control) key may be used when dragging
as a shortcut for toggling the meaning of the default
operation.  The key always toggles the meaning of the
default drag operation to "Copy" (provided the destination
supports "Copy").   The modifier may be used with either
mouse button.  When it is used with button 2 drag, the
operation is still interpreted as "Copy" and the pop
up does not appear unless the destination does not support
a "Copy" operation.  

Esc  The Esc (Escape) key may be used at any time for
cancelling a drag and drop transfer operation.  (It
has no effect on command initiated transfers.)

Ctrl+M  Ctrl+M is now reserved for the "Move" operation.

Clipboard keys  The existing Clipboard shortcut keys
for "Copy" (Ctrl+C) and "Paste" (Ctrl+V) are supported
for the new transfer model.  The shortcut for Ctrl+X
remains reserved for "Cut"; however, an object/application
that does not support a "Cut" operation may optionally
map this shortcut to "Move" (more detail on the relationship
of the Clipboard with the new transfer model in the
next section).

Compatibility and Extensibility
Conceptually, the new transfer model is different than
the existing Clipboard model in that the objects never
change their existing containment relationship until
the operation is completed by executing a verb at the
destination.  However, this model provides easy migration
from the existing Clipboard model.  It is similar in
its relatively modeless, dyadic (two-part) semantics.
However, the new transfer model verbs are easily applied
across the entire interface.  ("Cut" and "Paste" are
inappropriate when applied to objects like windows and
files.)  

In addition, the new model will provide for easy operational
compatibility. 

  For transfers between applications that still use
the existing Clipboard model, there is no operational
difference.  

  Since the new transfer command model uses the same
technical mechanism for maintaining its identification
of the object(s) to be transferred (when a transfer
initiation command is invoked), objects can easily be
transferred between applications using the Clipboard
model and those that use the new transfer model.  For
example, if you "Cut" a selection of text in a Clipboard
based application, a destination supporting the new
transfer model can supply "Put Copy of Text Here" or
even "Paste".  Likewise, you could invoke "Move" on
an object (supplying the new model) and find that the
"Paste" command in a Clipboard based destination provides
the right results.  

  While "Cut" is no longer considered to be part of
the basic transfer model, it is an acceptable addition
if the context is considered to be appropriate. 

  While the new transfer model outlines the basic transfer
interface with the intent of providing a consistent,
unified user interface for objects, it is not an exclusionary
design.  Situations that require more specific commands
like "Delete", "Duplicate", or "Swap" are allowable
provided they are included as additional commands and
not a replacement for the basic model.  
Default Operation
An object can also have a default operation.  This is
an operation that is assumed when shortcut mechanisms
are used.  For example, double-clicking a folder will
display a window with the contents of the folder.  However,
double-clicking a sound object might play the sound
rather than open a window for editing.  

The context of an object may affect which operations
is its default.  For exampe, dragging a document within
the same folder is considered a Move operation.  However,
dragging it to an printer would imply copy.      
Transactions
A transaction is a unit of change to an object.  The
granularity of a transaction may span from a single
operation to a set of multiple operations.  In an ideal
model transactions are applied immediately and provisions
are supported for rolling back transactions.  However,
this is often not practical, so specific interface conventions
have been established for committing transactions (e.g.,
Save, Apply, etc.).  If there are pending transactions
when a user attempts to close an object, he/she should
be prompted for applying them.  In addition, mechanisms
should be supported for rolling back transactions (e.g.,
Undo).  

The following are the recommended commands for committing
transactions:

Save  Save "checkpoints" (writes to disk) all interim
edits and begins a new editing session.

Close  If there are any unsaved/uncommitted edits, the
user is prompted for confirmation.  If confirmed, the
interim edits are saved and the window is removed.

On a finer granularity, objects may support the following
commands:

Repeat    Duplicates the last/latest user transaction.

Undo    Reverses the last (or specified) transaction.

Redo    Restores the most recent (or specified) "undone"
transaction.

There are also transaction commands recommended for
use in property sheets.  A following section on properties
covers this in more detail.  

The recommended commands for handling process transactions
are as follows.

Pause  Suspends a process.

Resume  Resumes a suspended process.

Stop  Halts a process.  Cancel may also be used to halt
a process, but it usually infers that the previous state
will be restored.  
Persistence 
The nature model for objects is for them to persist
unless explicitly destroyed.  The long term direction
is for objects to automatically persist without the
requirement for user commitment.  However, in the interim
applications should take steps by saving not only the
state of content changes, but also view state information
such as cursor position, scroll position, window size,
window location so that these can be restored when an
object's view is reopened. 
Properties
Defining and mapping the properties of an application's
components are a key part of the design evolution. 
Commands like "Options", "Info", "Summary Info", "Format"
should be redescribed as properties of a particular
object.  The command used for directly accessing the
properties of an object is "Properties".  Button 2
double-click is a shortcut for accessing the Properties
command of an object.

It is usually straightforward to define how to provide
access to properties of a visible object, such as a
selection of text, cells or drawing objects.  It may
be more difficult to define where to place properties
of more less tangible objects such as paragraphs.  In
some cases, it may be necessary to include these properties
by implication.  For example, requesting the properties
of a text selection may also display the properties
of the paragraph it is included in.  Another way to
do this may be by creating a representation of the object
as a handle to its properties.  For example, the properties
of a "page" might be accessed through a graphic or other
representation of the page in a special area (e.g.,
status bar) of the window.  A final way to handle this
may be to include specific properties entries on the
pop-up menu of a related object.  For example, the pop
up menu of a text selection could include individual
menu entries or a hierarchical menu off of the Properties
command.  


Relationships
The following are descriptive terms that can be used
to define some basic types of relationships used in
the interface.  

Collection
A collection is a set of objects that share some aspect
in common with each other.  A collection itself is not
an object, but a descriptive way of referring to a simple
relationship.  The only qualification for an object
to be part of a collection is that it is a member of
a set.  Examples of collections is a multiple selection
or the results of a query.

Constraint
A constraint is a stronger relationship between a set
of objects, such that making a change to an object affects
some other object in the set in some way.  The way a
text box streams text, the way a drawing application
layers its objects in a z-order or even the way a word
processing application may organize its content into
pages are all examples of a constraint relationship.

Composite
Sometimes a collection of objects not only affect one
another, the set itself becomes an object with its own
operations and properties.  Such a relationship is referred
to as a composite.  In this sense, the whole is greater
than the sum of the parts.  However, like a collection,
removing all the elements from the set and the composite
ceases to exist.  Examples of composites include words,
paragraphs, a range of cells in a spreadsheet or a set
of drawing objects that have been grouped.  

Containment
Containment is the concept that objects exist in a place,
i.e., another object that is called a container.  Containment
differs from the other relationships in that the container
object can exist independent of what it contains.  However,
a container can have a significant influence on what
it contains.  Moving or destroying the container usually
results in the same action on its contents.  However,
containers may also affect objects that they do not
contain, specifically restricting what may or may not
be contained by them.  Just as a bottle's neck may restrict
the size of what may be dropped in the bottle, so too,
containers may refuse or force an object to conform
to certain pre-requisites to be contained.  More specifically,
attempting to transfer an object to a container may
result in one of the following alternatives:

  Reject the object;
  Accept the object;
  Automatically encapsulate the object with an object
it can accept;
  Accept a subset or transformed form of the object
(e.g., extract its content or properties, but discard
its present containment, or transform the object into
a new type).
Windows
Common Uses (Types) of Windows
Window Components
The primary window of an object (typically used to provide
a view of its contents)  includes the following elements:

The Window Frame
Every window has a boundary that defines its shape.
If the window is sizable, the border area is wider to
provide a handle for sizing the window.  If the window
is not sizable, the border is coincident with the edge
of the window.  

The Title Bar
At the top edge of the window, inside of its frame is
a bar which extends across the width of the window.
This serves as a handle for dragging the window as well
as access to commands that apply to the windows and
its associated view.  Clicking on the title bar with
mouse button 2 displays the pop-up menu for the window.
(More detail on the "window" menu is covered in a following
section.)

The Title Bar Icon
The small version of the object's icon (16 x 16) appears
in the upper left corner of the title.  This icon represents
the object being viewed in the window.  It also provides
access (via pop-up menu) to the operations of that object.
Double-clicking on the title bar icon is a shortcut
for closing the window (and exiting the application).


If the object in the window represents a "tool", i.e.,
does not provide for loading and saving separate data
files, then it should place the small format of the
application's mini-icon in its title bar.  



If the application does provide for loading and saving
documents or data files, then the application should
provide the icon that represents its document/data type
in the title bar.  



If the application uses the Multiple Document Interface
(MDI), then the application should use the application's
icon in the parent window's title bar and use an icon
in the document windows that reflect's the application
data file type.  



However, if the user maximizes the child/document window
such that its title bar is hidden and its title information
merges with the parent, as may occur when the child
window is maximized, then that child/document's icon
is displayed in the title bar, even if there are multiple
documents open.  If multiple child/documents are open
within the MDI parent window, then the current active
(topmost) document window's icon is displayed.  







Title Text
The design convention for the ordering of the title
text in the title bar has changed in Windows (Chicago).
It is now recommended that applications place the name
of the document/data file first, then the application.
If the application is a tool that has no associated
data files, then only the application's name is used.
Applications may also optionally omit the name of the
application (since the title bar icon helps to identify
the type of object).  



Window Buttons
Push buttons that appear on the right size of the title
bar are associated with the commands of the window and
act as shortcuts to specific commands.  Clicking a 
push button with mouse Button 1 invokes the command
associated with the button.  Clicking the push button
with Button 2, displays the pop-up menu for the window.

Minimized Windows
Windows (Chicago) provides a new visual for displaying
minimized windows to help communicate that it is a minimized
window and to distinguish it from objects represented
as icons.  

 


Applications should avoid animating their minimized
representation and use the mini-icon instead.  
Splitting Views/Windows
info to come on split boxes and split commands and their
location
Property Sheets and Inspectors
The properties of an object may be displayed in a number
of ways in the interface.  For example, some folder
views will display some of the "file" properties of
an object.  The icon image and appearance of an icon
and name appearing on the desktop are also an expression
of certain properties of an object.  Other interface
conventions like toolbars, status lines, or even scroll
bars may reflect certain properties.  However, the more
common presentation of an object's properties will be
through a property sheet.  A property sheet is simply
a modeless window which displays a form of user accessible
(viewable, and often editable) properties of an object.


A property sheet is differentiated from a property inspector
in that a property sheet is considered to be a view
of an object's properties that remains fixed on the
object it was invoked on.  A property inspector is a
dynamic viewer/browser that reflects the properties
of whatever the current selection is.  

Ideally, the values for properties found in property
sheets should be transferable, at least for text-based
values.  In addition, applications may provide special
transfer completion commands so that an object's properties
can be copied to another object.  (See later section
on Transfer Model.)

Property Sheet Interface
Since the properties of an objects (and its implied
context) may be numerous, it may be appropriate to categorize
and group properties within the property window.  There
are two mechanisms for doing this.  The first is a "tabbed"
page.  Each set of properties of the object is presented
within the window as a page with a tab labeled with
the name of the set.  
  



Tabbed property pages are best suited for a small set
of related property sets or large groups of peer level
properties.  Applications may also wish to provide access
to the hierarchically related objects.  For example,
when selecting a cell in a spreadsheet, an application
may wish to provide access to its related row and column
properties.  It may choose to do this with additional
tabs, but it may instead provide access to these properties
through another switching mechanism (such as a dropdown
list or menu).  



Property Sheet Transaction Commands
Property sheets usually allow properties to be changed
and subsequently committed as a set.  Property sheets
include the following commands (typically implemented
at push buttons) to facilitate application of property
changes.  

OK  The OK command applies all pending changes and closes
the property sheet window.

Apply  The Apply command applies all pending changes,
but leaves the property sheet window open.

Cancel  Aborts any pending changes (does not Undo changes
that have already been applied) and closes the property
sheet window.  

Applicatons can also optionally include a "Reset" command
that aborts pending changes, but does not close the
property sheet window.  (In this way, it is the same
as Cancel without closing the window.  

Placement of the transaction push buttons can be very
important.  If the buttons are placed outside of the
property "page", then it is to be interpreted that the
property transactions are applied as a set, that is
all changes on all pages are applied (or canceled) at
once.  However, if the buttons are placed within the
page, then transactions are considered to be local to
that page.  In addition, if the user changes the current
pages, any transaction are automatically applied.  



Closing a Property Sheet Window
If the user closes a property sheet window, it is similar
to the model for closing an open view of an object;
that is, if there are pending changes which have not
been committed, the user is prompted to confirm the
changes via a message dialog.  

If the user confirms that the properties may be applied
then the message dialog and the property sheet windows
are removed.  The user may also continue without applying
the changes or abort the closing of the property sheet
window.  

Properties on a Multiple Selection
When the user selects multiple items and requests the
properties of these items, generally the properties
of all the items are reflected in a single property
sheet.  Where the property values differ, the field
reflecting the values are rendered with an indeterminate
state.  

If access to individual items is important, applications
may include a mechanism (e.g., list box, dropdown list)
in the property sheet for switching/viewing the individual
properties of a particular item.  

Properties on a Heterogeneous Selection
When the selection set includes heterogeneous types
of objects, the resulting property sheet should include
the intersection of properties between the objects.
However, there may be exceptions when the object(s)
of a different type may be treated as if it were of
the same type.  For example, if a selection is made
in a text stream which includes an embedded graphic
(e.g., ellipse), font properties may be available if
in that context the graphic is treated as a character.

Properties on Grouped Items
A multiple selection should not be equated with a grouped
set of objects.  A group is a stronger relationship
than a simple selection whereby the composition resulting
from the grouping can be considered an object itself,
potentially with its own properties and operations.
Therefore requesting the properties of a grouped set
of items may not result in a collection of the properties
of its individual members.  

Menus, Controls, and Toolbars
Menus
The Window Menu (formerly the System/Control Menu)
The "window" menu (not to be confused with the menu
title found in MDI applications) is the menu associated
with the window.  It replaces the former System or Control
menu.  The standard commands on this menu are Close,
Move, Size, Minimize, and Maximize.  The "window" menu
may be accessible via button 2 from any area of the
window that is not part of the data being viewed in
the window.  Specifically, this means the window menu
is accessible from anywhere in the title bar area, including
the Window button (but excluding the title bar icon)
and any sizing handle.  

Applications may append commands to the "window" menu
that apply to the window or view within the window.
For example, an application could append a "Split" command
to the menu to facilitate splitting the view into panes.
Likewise, commands that affect the view could be shown
there (e.g., Outline), commands that add, remove or
filter elements from the view (e.g., Show/Hide Toolbar),
or commands may open certain subordinate or special
views (e.g., Show Color Palette).  

The Menu Bar
Windows continues to support application use of a menu
bar.  However, it should be understood that the long
term evolution of the menu bar is toward tool bars;
that is, that the menu bar evolves into a tool bar configured
with "menu" controls.  Like tool bars, the menu bar
should be optionally displayable.  This means that applications
should not be dependent upon the display of a menu bar
to be operational.  Pop-up menus, toolbars and other
interfaces should be sufficient.   

The following menu bar entries are recommended where
they are appropriate.  

The File menu  The File menu is used to provide an interface
for file operations on an object.  The commands found
on the file menu usually correspond to those found on
the object's title bar icon menu.  

The Edit menu  The Edit menu includes commands used for
editing the internal components of an object.  These
include the standard transfer commands and also include
the following commands if they are supported:

Undo Reverses last action  Repeat Repeats last action  Find
and Replace Used for text search and substitution  Delete Removes

the current selection  Duplicate  Creates a copy
of the currrent selection  Cut Removes the current
selection and moves it to the Clipboard.  (For more
details on Cut see the section on Compatibility in the
Transfer Model description.)   
The View menu  The View menu includes commands for changing
the user's view of data in the window.  Commands on
this menu should affect on the view and not the data
itself (e.g., magnification commands like Zoom).  The
menu may also contain commands for controlling the display
of particular interface elements in the view.  View
menu entries can typically also be included on the pop
up menu of the object's window.  

The Window menu  The Window menu is typically only used
in MDI applications and includes commands for managing
the windows within an MDI workspace.  These commands
are more generally found on the pop-up menu of the parent
MDI window.  

The Help menu  The Help menu contains commands that provide
access to Help information.  Generally, this menu includes
a Contents command that provides access to the main
topics of included in the application's Help file, a
Search for Help On... command that opens the Help file
and displays a dialog that allows the user to search
for Help topics that contain specific keywords, and
an About <Application Name> that displays a dialog box
containing the application's name, version number, copyright
information and any other informational properties of
the object.  This information may also be included as
a page in the property sheet of the object.  

Pop-up Menus
Applications are encouraged to make use of pop-up menus
to provide a contextual interface to the operations
of objects.  Pop-up menus are invoked using Button 2.
On the down transition of the button, the object(s)
is identified.  On the up transition the menu is displayed,
typically to the right and below the hotspot of the
pointer (though this is adjusted if the menu would be
clipped by the edge of the screen).  

If the pointer is over an existing selection when the
menu is invoked, then the menu displayed should apply
to that selection (see previous section on Displaying
Operations on Multiple Selection).  If the menu is outside
a selection, but within the same selection scope, then
the button down point establishes a new selection (usually
resetting the current selection in that scope) and displays
the menu for the new selection.  However, if the button
is clicked a second time within the same selection,
the menu is simply removed.  Pressing the Esc key also
dismisses the menu.  (Clicking with Button 1 will also
dismiss the menu.)

Pop-up menus can also be supported for objects that
are typically implicitly selected or not directly selectable.
For example, applications can provide pop-up menus for
controls like scroll bars via Button 2 click or for
static items in a status area.  However, in general,
when providing pop-up menus on objects like controls,
the menu items included in the menu should be the commands
relating to object the control represents.  For example,
a scroll bar represents a navigation view of a document,
so commands might include "Beginning of Document", "End
of Document", "Next Page", "Previous Page", etc.  The
exception is if the control is being treated as an object
itself in a window/form layout context.

Icon Menus
Pop-up menus displayed for icons should represent the
operations of the respective  objects.  For a data/document
editing based application the following are the suggested
items that should be included in the various iconic
presentations.

Application .EXE 
file icon
(e.g., seen in a folder) Document file icon
(e.g., seen in a folder) Document title bar icon
(e.g., seen in an open window)  New  Save  Open Open Close  Move
Move Move  Copy Copy Copy  Link Link Link  Put
Here Put Here Put Here  Delete Delete Delete  Help Help Help  Pro
perties Properties Properties  
If an application does not edit data files, then its
title bar icon is the same as the document with the
exception that Save is not included.  

In the case of MDI applications, the application's icon
in the parent MDI window may include the following commands:

New  Save All  Find...  Close/Exit  Help  Properties  Controls
Controls are interactive forms of representing commands
or objects.  The fundamental commands found in Windows
are the same as those found in Windows 3.1.  

Like most elements of the interface controls provide
feedback indicating their selection on the down transition
of the mouse button, but do not activate until button
up.  

Buttons
Command (push) button  Initiates an action.

Option button  Allows the setting of an option from a
set of mutually exclusive set.  

Check box  Allows the setting of an option, independent
of other options.  This is not to imply that check boxes
may not be used to affect other controls or that the
state of other controls may not affect the state of
a check box.   

Lists
Single selection list box  Presents a list of items from
which a single item can be selected.  

Extended selection list box  Presents a list of items
which is optimized for single item selection (or single
range selection), but also supports disjoint selection.


Multiple selection list box  Presents a list of check
box items; any one of which can be set.  

Dropdown list box  A single selection list box that where
is optionally displayed.

Text Fields
Text box  Presents a field in which text can be typed
and edited.  

Combo box  Combines a text box with a single selection
list box.  The scroll position of the list tracks based
on characters entered in the text box portion.  

Dropdown combo box  Combines a text box with a single
selection dropdown list box.  The scroll position of
the list tracks based on matching characters entered
into the text box portion.


Static text field      Displays read-only text.  

Pop-up text field  A text field that displays itself
in a title-less window.

Group Box
A frame used to visually group related controls.  
New Controls
Windows now provides access to the following controls:

Spin Boxes
The Chicago interface also now include spin boxes. 
These are specialized instances of text boxes that accept
a limited set of discrete ordered input values.  The
arrows on the control allow the user to increment or
decrement the values (see current style guide for more
details).  




Toolbar
A toolbar is a special frame control that supports toolbar
functionality.  (See following section for details on
toolbars.)  



Status bar
A status bar control supports the functionality of a
status bar.   (See the following section for more details
on Status Bars.)









Column header
A column header is a control used to display properties
of a selected object in a multi-column list.  The control
defines which property is displayed and the sort order
based on the property for items in the list.  



Slider
The Chicago interface now includes a standard slider
control  (formerly described in the previous version
of the style guide).  This control is preferable to
the use of a scroll bar for setting or adjusting values
on continuous dimensions.  Scroll bars are more appropriately
applied to scrolling information.



Progress Indicator
A progress indicator is a control that can be used to
show the percentage of completion of a particular process.
The bar "fills" from left to right.  



Tabs
A notebook-like tab control is now included.  This control
is intended for simple navigation between logical "pages"
or sections of information.  




List view
A list view is a control that allows the display of
a list of a set of objects.  It supports viewing objects
by their large icon, small icon, as a list, as a table,
as a chart, or as a "preview".  It is often used in
conjunction with the Tree control (see following description).


Property page
A property page control displays the properties of a
selected object as a set of tabbed property pages. 
It can be used to construct property sheets for objects.




Tree control
A tree control displays a list of logically hierarchical
containers as an expandable/collapsable outline.


Rich-text box
A text box that supports formatting of individual characters
and paragraphs.
ToolBars
A toolbar is a frame containing a set of controls. 
Generally, they are used to provide quick access to
specific commands or options (e.g., ribbons, toolboxes,
palettes).  

A toolbar can be fixed or movable.  If it is movable,
it appears inside it own window.  It is recommended
that movable tool bars be designed such that they can
be windowed or docked at the discretion of the user.
(The default state is up to the application.)  In a
windowed state, the controls appear in a sizable window
which includes a title area so that the user can move
the control bar around.  The position of control bar
windows should be retained so that they can be restored
to their former position.  To dock a control bar the
user moves the window until it comes in contact with
the edge of its parent frame (i.e., window) at which
point it "snaps" to align to that edge and its title
bar is no longer displayed.  To change a docked control
bar to its windowed state the user drags anywhere in
the "blank" area of the control bar.  After moving and
releasing the mouse button in the new location, the
control bar returns to its windowed (and sizable state).
Optionally, applications can support double-click in
the blank area of a control bar to restore a control
bar to its windowed state.   

Applications may allow multiple control bars to be docked
side by side, reconfiguring their arrangement and size
as necessary.  
Status Bars
A status bar is a special area within a window that
displays information about the current state of object
being viewed in the window or its components or any
contextual information that relates to operation to
that object (e.g., keyboard state, time, etc.).  It
is  and is typically configured as a part of a window.


Scrolling (Proportional Scroll Box)
The standard scroll bar control now features a proportional
scroll box (slider).  It is recommended that applications
incorporate this except where the proportional feature
has no logical meaning.  The scroll box size is intended
to provide visual feedback as to the relationship of
what is being viewed in the window to the entire viewable
area.  For example, for a word processing document,
the size of the scroll box represents the portion of
the document appearing in the window with respect to
the entire document.  If the entire viewable area is
contained in the window, then the scroll bar would fill
the scroll bar channel. 
Dialog Boxes 
Dialog Boxes
Types
Messages
Message Types

Common Dialog Boxes
The design of the dialogs for common functions like
File Open, File Save, Find, etc. have been revised.
Application developers are encouraged to use these where
they are apppropriate.  They provide a high degree of
consistency as well as support some of the new file
naming conventions of Windows.

File Open
The File Open dialog allows the user to browse the file
system and includes controls to open a selected/specified
file.

File Save (As)
The File Save (As) dialog that allows the user to browse
the file system and provides controls for saving a specified
file in a particular location with a new or specified
name and/or format.

Find File
Find File  includes controls for searching for files,
displaying the list of files that match the specific
search criteria and can optionally display a content
preview of a file selected in the list.  

Search
Search displays a list of previous and default searches
tha can be modified or deleted and includes controls
for performing searches based on the specified criteria.


Find and Replace
The Find and Replace dialog provides controls that search
for a text string or format specified by the user and
optionally replaces it with a second text string or
format specified by the user.  

Print
The Print dialog displays information about the installed
printer and formats printer output according to the
criteria specified by the user.

Print Setup
This dialog displays the list of available printers
and provides controls for selecting a printer as well
as setting paper orientation, size, and source, and
other printer properties.  It can be displayed independently
or from a command in the Print dialog.  

Page Setup
Page Setup provides controls for specifying properties
about the page elements and layout.

About
The About dialog can be used to display an application's
name, version and copyright information.  

Font (Properties)
The Font dialog can be used to display the font properties
of a selection of text.

Color
The Color dialog provides controls for selecting the
color property of a particular object.  

Sound
The Sound dialog provides a list of the current sounds
installed in the system and provides controls for assigning
those sounds to particular events.

Spell checking
The Spell Check dialog provides an interface for displaying
a selected word that is not found in the currently active
dictionary.  It also displays suggested alternatives
to the work and controls for selecting an alternative
word or correcting the spelling of the existing word.

Sorting
The Sorting dialog displays categories by which a selected
list can be sorted.  The categories are defined by the
application.

Properties
This is a template for a standard property sheet and
provide controls for view and changing the properties
of an object.  

Insert/Import
This dialog provides an interface for inserting new
objects or importing existing objects into a document.


Window Management
MDI (Workspaces, Workbooks)
The Multiple Document Interface (MDI) provides a means
of managing multiple sets of objects that are logically
grouped together for a particular task.  Chicago extends
this interface to define two interface constructs: 
workspaces and workbooks.  

Workspaces
A workspace object is a natural evolution of the traditional
MDI design.  Like MDI, a workspace allows the association
and management of a set of task related windows within
a "parent" window which also provides a construction
for interface elements of objects opened within the
workspace.  The major difference between workspaces
and the Windows 3.1 MDI design is that workspaces are
intended to be generic containers whereas most current
MDI implementations restrict the objects that may be
contained.  In this sense, workspaces are really just
user, rather than application, configured work areas.

Workbooks
Not all object/task related grouping needs to be confined
to an overall parent window.  In a workbook design,
the windows associated with the contained elements are
restored to their previous state, but share the same
screen work area as windows of other objects.  In addition,
workbooks may have very specific semantics associated
with their ordering like pages within a book.  The interface
for Visual Basic is an example of a workbook style of
interface.  

A Comparison
Workspaces and workbooks are not mutually exclusive
concepts.  In fact, workbooks may be displayed in a
workspace (which would confine the related windows).
The following table summarizes the characteristics of
each.  

Workspace Workbook  -  is a container (of objects
and their windows) -  is a container (only of objects,
not windows)  -  remembers the state of windows open
from within it -  remembers the state of windows open
from within it  -  is a workspace; content windows
are confined (clipped) to its window -  is NOT a workspace;
content windows open in the workspace it is already
in (or optionally replace its view)  -  minimized
windows are retained within its workspace -  minimized
windows are retained within the workspace the workbook
is in  -  workspace window shares menu bar and status
bar area (possibly tool bar area) -  menu and status
areas are NOT shared (for open content windows)  
provides no ordering semantics (order does NOT matter) 
provides sequential ordering semantics (order does matter)  
provides navigation for moving between windows (via
menus) -  provides navigation for moving between objects
(button and/or tabs)  -  often zoomed to full screen 
NOT generally zoom to full screen  -  does NOT provide
for ordering (e.g., page numbering) across objects 
does provide for ordering across objects  -  does
not have an index view -  optionally may have an index
view  -  based on a desk metaphor -  based on a (note)book
metaphor  
Interacting with the "shell"
Interacting with the "Browser" (aka explorer)
Applications that maintain their own data respositories
or other non-ordered collections of objects are encouraged
to provide view definitions for use with the Windows
object browser.   
Scraps
The system provides for the creation of objects that
may be stored directly in the file system.  These objects
are referred to as "scraps".  The system automatically
provides icons for basic types of scraps (text, graphics,
generic).  
Using the Registration Database
Developers should make full and correct use of the system
registration database.  This means:
  To supply associations between their file types and
executable files.  If an application does not do this,
then the system will prompt the user requesting an appropriate
editor/application to use.  
  To register the icons they wish to have displayed
by the system in both large (32 x 32) and small (16
x 16) sizes.  Otherwise, the system will generate a
generic icon for it.  
  To include data specific commands for their document
types (e.g., "Play" for a sound object.)
  To add pages to the file property sheet for the objects
stored in the file system.  
  To support "print-to" to enable appropriate behavior
when user transfer objects to printers.
Support UNC pathnames
Developers should support UNC pathnames for identifying
the location of objects.  This enables the users to
browse the World directly and open up files without
having to make explicit network connections.    


Object Linking and Embedding
<information from current OLE document to be integrated
in here>
Help
QuickHelp
In addition to providing Help files that may be browsed
by the Window's Help application, applications are encourage
to support the QuickHelp facilities.  QuickHelp is accessed
via the Help menu command included in an object's pop
up menu.  

Selecting Help from an application's menu displays a
small window with brief contextual information about
the object or the object's context and options for the
user to see other information, including access to the
Help Book of demonstrations.  (See following section
for more details on the Help Book.) 
QuickHelp Inspector
QuickHelp Inspector is a special instance of the QuickHelp
interface that displays the QuickHelp window, but in
a browsable mode such that the user can point to different
objects have their QuickHelp information dynamically,
simply by pointing at the object.  It works similarly
to the way property sheets can be converted into property
inspectors.  The QuickHelp Inspector remains displayed
unless explicitly closed by the user.  

The QuickHelp Inspector's window always stays on top
of all other windows.  It can also be minimized so that
it can be kept in a compact form yet used to browse
for the names of certain objects.  
Help Book
The Help Book is a workbook object where the Help files
are installed for an application.   The Help Book replaces
the standard Help application in former releases.

Shortcuts
Alt+click  This combination displays the QuickHelp window
for whatever the user clicks on.  

F1  This key is the shortcut for accessing the QuickHelp
window for the object with the current focus.  

Shift+F1  This key invokes QuickHelp window in "Inspector"
mode.

Visual Design
Border Styles
Windows now includes a unified visual design for building
all system components. The application of color to the
border styles creates a 3D effect based on an upper
left-hand corner light source. See figure 1 & 2.
Layout 
Size, spacing and placement of controls is critical
in creating a visually consistent and predictable environment.
Figure 3 shows proposed default settings for size, spacing
and placement of system controls and text. Figures 4
6 show guidelines for button placement.
Icon Style
The icon style has been slightly modified to reflect
the same light source and the system controls. The black
outlines have also been eliminated to reduce visual
clutter. See figure 7.
All programs also need to provide icons for the application
as well as for documents created by the application.
See figure 8.
Fonts
Usage  
The proposed system font for Windows is Arial 8pt non
bold. Text is bold only in title bars, as default commands
on menus and on the default button in dialogs.
See figure 9.
Fonts and system controls also scale proportionally
in Windows. See figure 10. 
The Pen Interface
<Information about the Pen Interface to inserted here>


Appendix A  Mouse Interface Summary
The following tables summarize the basic mouse interface
including selection and direct manipulation (drag and
drop).

Effect On Press Click  (press-release) Drag (press
move-release) Double-Click  Unselected 
object existing selections clear clear clear clear   anchor
point reset at object reset at object reset at object reset
at object   operation select object under hotspot select
object under hotspot select object under hotspot and
show popup menu for selection set select object and
default transfer  select object and non-default transfer
(w/popup) select object and execute default operation
on selection set execute Properties on selection set  Selected
object existing selections no change no change no
change no change   anchor point no change no change no
change no change   operation optionally subselect optionally
subselect optionally subselect and
show popup menu for selection set default transfer* non
default* transfer (w/popup) optionally subset and execute
default operation on selection set execute Properties
on selection set  "White space" existing selections clear clear c
lear clear   anchor
point reset to button down point
(restore to last location if no selection are made) no
change (or reset to button down point; restore to original
on button up) reset to first object included  no change   operati
on none

none
(select whitespace)  show popup menu for whitespace

(Select All
Select None) select everything logically included by
marquee from anchor point to release point
select everything logically included by marquee from
anchor point to release point 
and show popup for selection set  execute default operation
for whitespace
(Select All) none
(whitespace does not have properties)  
Operations using the Shift key modifier:

With Shift Effect On Press Click  (press-release) Drag
(press-move-release) Double-Click  Unselected 
object existing selection clear current selection
no change to other selections clear current selection
no changes to other selections clear current selection
no changes to other selections clear current selection
no changes to other selections   anchor point no
change no change no change no change   operation extend
selection state 
to items logically included
from anchor point to current object 
(selection state is based on first object included) extend
selection state to items logically included from anchor
point to release point 
(selection state is based on first object included) extend
selection state to items logically included from anchor
point to release point 
(selection state is based on first object included)
and show popup menu for the selection set extend selection
state to items logically included from anchor point
to release point
(selection state is based on first object included) extend
selection state to items logically included from anchor
point to release point (selection state is based on
first object included) and show popup menu for selection extend
selection state to items logically included from anchor
point to release point (selection state is based on
first object included) and execute default action on
the selection set  extend selection state to items
logically included from anchor point to release point
(selection state is based on first object included)
and execute Properties on the selection set  Selected
object existing selection clear current selection
no changes to other selections clear current selection
no changes to other selections clear current selection
no changes to other selections clear current selection
no changes to other selections   anchor point no
change no change no change no change   operation extend
selection state 
to items logically included 
from anchor point to current object
(selection state is based on first object included) extend
selection state to items logically included from anchor
point to release point (selection state is based on
first object included) extend selection state to items
logically included from anchor point to release point
(selection state is based on first object included)
and show popup menu for  the selection set  extend
selection state to items logically included from anchor
point to release point
(selection state is based on first object included) extend
selection state to items logically included from anchor
point to release point
(selection state is based on first object included)
and show popup menu for selection set  extend selection
state to items logically included from anchor point
to release point (selection state is based on first
object included) and execute default action on the selection
set 
extend selection state to items logically included
from anchor point to release point (selection state
is based on first object included) and execute Properties
on the selection set  
 "White space" existing selection clear current
selection
no changes to other selections clear last selection
no changes to other selections clear last selection
no changes to other selections clear last selection
no changes to other selections   anchor point no
change no change no change no change   operation extend
selection state 
to items logically included 
from anchor point to current location
(selection state is based on first object included) extend
selection state 
to items logically included 
from anchor point to release point
(selection state is based on first object included) extend
selection state 
to items logically included 
from anchor point to release point
(selection state is based on first object included)
and show popup for selection set extend selection state
to items logically included from anchor point to release
point
(selection state is based on first object included) extend
selection state to items logically included from anchor
point to release point
(selection state is based on first object included)
and show popup menu for selection set extend selection
state to items logically included from anchor point
to release point (selection state is based on first
object included) and execute default action on the selection
set 
extend selection state to items logically included
from anchor point to release point (selection state
is based on first object included) and execute Properties
on the selection set 
 
Operations using the Ctrl key modifier:

With Ctrl Effect On Press Click  (press-release) Drag
(press-move-release) Double-Click  Unselected 
object existing selection no change
no change no change no change   anchor point reset
at object reset at object reset at object reset at
object   operation toggle the selection state 
of  the object (select) toggle selection state of object
(select) toggle selection state of the object
(select)
and show 
popup menu for the selection set
* toggle the selection state of the object (select)
and 
Copy transfer the selection set
** toggle the selection state of the object (select)
and 
Copy transfer the selection set
** toggle selection state of the object (select) 
and 
execute default action on the selection set * toggle
selection state of the object  (select)
and 
execute Properties for the selection set *  Selected
object existing selection no change no change no
change no change   anchor point reset at object reset
at object reset at object reset at object   operation not
defined  toggle selection state of the object
(unselect) toggle selection state of the object 
(unselect)
and show 
popup menu for the selection set**  Copy transfer
the selection set
** 
(unless the drag does not exceed transfer threshold,
in which case is intepreted same as Click) Copy transfer
the selection set
** 
(unless the drag does not exceed transfer threshold,
in which case is intepreted same as Click) toggle selection
state of the object (unselect) 
and 
execute default action on the selection set * toggle
selection state of the object 
(unselect)
and
execute Properties for the selection set*   "White
space" existing selection no change no change no
change no change   anchor point reset at button
down point no change no change no change   operation none

(however, this may show the visualization for marquee/range
select)
none show popup menu for the selection set** toggle
selection state of objects logically included from anchor
point to release point (based on the first object included)+ togg
le
selection state of objects logically included from anchor
point to release point (based on the first object included)
and show 
popup menu for selection * execute default action on
the selection set**  none 
(whitespace does not have properties)  *    If the
effect of toggling unselects the current object under
the pointer, the popup/action applies to the remaining
selected objects (if none, then the whitespace).
**  To extend a disjoint selection, use Shift+Click or
Shift+Drag.
***  A toggle range operation toggles the objects all
to the same state (based on the first included item).
The is the default setting.  The system allows the
user to switch the left/right mapping of the button
functionality.
While other mouse behaviors like chording or triple
clicking are possible, they are outside the scope of
the design guide.
This is consistent with today's use of the Paste command.
Paste appears in the Edit menu of applications even
if there is no data on the Clipboard to be "pasted".
However, it appears disabled to indicate this state.

This is not to exclude that there may be other means
of viewing the properties of an object.  For example,
folder views display certain properties of objects stored
in the file system.
 If the Ctrl key is released before the mouse button,
reverts to default drag transfer. 

 If the Ctrl key is released before the mouse button,
reverts to non-default drag transfer (i.e., with popup
on button up).




(c) 1993 Microsoft Corporation    MICROSOFT CONFIDENTIA