Browse Prior Art Database

Design and Implementation of Read-Only Radiobuttons and Checkboxes

IP.com Disclosure Number: IPCOM000114275D
Original Publication Date: 1994-Dec-01
Included in the Prior Art Database: 2005-Mar-28
Document File: 4 page(s) / 166K

Publishing Venue

IBM

Related People

Eldred, TE: AUTHOR [+5]

Abstract

The Common User Access* (CUA) standards do not address how read-only radiobuttons and checkboxes should look, how the user should be allowed to interact with them, or how the control should react to user input. Disclosed is the design and implementation of read-only radiobuttons and checkboxes.

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

Design and Implementation of Read-Only Radiobuttons and Checkboxes

      The Common User Access* (CUA) standards do not address how
read-only radiobuttons and checkboxes should look, how the user
should be allowed to interact with them, or how the control should
react to user input.  Disclosed is the design and implementation of
read-only radiobuttons and checkboxes.

      The concept of read-only controls is not new in an OS/2*
Presentation Manager* (PM) environment.  Read-only entry fields, for
example, allow the user to cursor to and scroll through the text of
an
entry field, but do not allow the user to change the text.  Read-only
spinbuttons, containers, and sliders are also available in PM.

      However, situations exist in some applications that would make
it very desirable for other controls to be read-only.  One example is
the setting of attributes for an object.  Some attributes can only be
set when the object is created and cannot be changed later by the
user.  When the attribute values are viewed by the user after the
object is created, the controls originally used to set the attribute
should be used to display the attribute value in read-only mode.
Radiobuttons and checkboxes are often used to set attributes, and
need to be displayed as read-only controls.

      PM does not provide support for these controls being read-only.
The only options are fully enabled or disabled.  Displaying the
attributes as fully enabled, which lets the user change them but does
not honor those changes, would be very confusing to the user.
Displaying the attributes as disabled presents the control in
half-tone.  Usability studies have shown that users tend to ignore
disabled controls altogether, because they do not seem to be
applicable to the current situation.  Disabled controls also cannot
get the focus, another important usability consideration.  Neither of
the available presentation styles is appropriate for this situation
where an application wants to display these controls so that the user
is made aware of their importance, while not allowing the user to
change the selections.

      The appearance of read-only controls should be unique, so that
users can recognize the control to be read-only when they see it.
The
appearance should also convey the functionality of the control to
users.

      Radiobuttons and checkboxes each consist of two parts:  the
text and a bitmap showing the selection state.  For a disabled
control, both parts are shown in half-tone.  Since a read-only
control does not allow its state to change, the bitmap showing the
state should be displayed in half-tone as though it were disabled.
The user seeing a disabled bitmap will intuitively understand that
the state will not change.  Since the control is not disabled,
however, its text should be displayed as normal, nondisabled text.
The user seeing nondisabled text will realize that the control is not
disabled and therefore presents rel...