Browse Prior Art Database

User Interface Design to Hide Complexity in Dialogs

IP.com Disclosure Number: IPCOM000107340D
Original Publication Date: 1992-Feb-01
Included in the Prior Art Database: 2005-Mar-21
Document File: 3 page(s) / 127K

Publishing Venue

IBM

Related People

Fleming, SS: AUTHOR [+2]

Abstract

User interfaces need to offer many options for actions specified in dialogs to satisfy the requirements of some users. This invention avoids confusing basic users, by hiding these options.

This text was extracted from an ASCII text file.
This is the abbreviated version, containing approximately 48% of the total text.

User Interface Design to Hide Complexity in Dialogs

       User interfaces need to offer many options for actions
specified in dialogs to satisfy the requirements of some users.  This
invention avoids confusing basic users, by hiding these options.

      Current systems provide numerous options for actions specified
in dialogs.  For example, in sort dialogs, the user has an option to
sort by ascending or descending order. As another example, in a
some...  dialog, which allows the user to specify a subset of a list
to be displayed, the user has an option to create a subset of the
current subset or a new subset of the entire list.

      You can see from these examples the tradeoff found in current
user interface designs today.  There is no question of the utility of
the options for the actions for some users in some situations.
However, the extra options are confusing to basic users who do not
need them and present additional complexity to expert users who may
not wish to use the optional function for a given action.

      This user interface problem is pervasive today, in part because
of the competitive pressure for applications to offer more and more
advanced features, to compete in the "feature checklist" comparisons.
Almost every application today has many options in dialog boxes that
will never be used by a significant number of users.  In fact, some
options may never be understood by many users.

      What is required is a way to add features to dialogs for users
who understand the features and wish to use them. It is also desired
that the same user interface be provided for adding features to the
primary windows of applications, thus allowing the user to use the
same technique to customize any part of their product's user
interface.  This invention fulfills these goals.

      In primary windows, many current applications use pull-downs
from the menu bar to provide choices which control customization of
applications.  This is an inferior design for the following reasons:
      1.   Novice users always explore the pull-downs searching for
actions.  They encounter the customization actions and are confused.
They may mistake a customization choice as a way to perform a novice
task.  If customization accidentally results, this may result in
additional confusion and the novice may not know how to reverse the
change.
      2.   Pull-downs are "valuable real estate" for application user
interfaces, and should be reserved for frequently used actions.  Even
if a pull-down is sparsely populated, the real estate is valuable for
adding function in future product releases or adding frequently used
expert functions as a result of customization. Customization of a
given window may be considered an infrequent user task.
      3.   The presence of infrequently used choices on pull-downs
presents a cognitive burden to expert users, by forcing them to make
selections from a larger set of choices....