Browse Prior Art Database

Naming Objects with Relationships in a Graphical User Interface

IP.com Disclosure Number: IPCOM000117887D
Original Publication Date: 1996-Jul-01
Included in the Prior Art Database: 2005-Mar-31
Document File: 4 page(s) / 148K

Publishing Venue

IBM

Related People

Larner, IP: AUTHOR [+2]

Abstract

Today's Graphical User Interfaces (GUI) make use of 'folder' to represent containment relationships between objects. A folder object can be opened into a window view of its contents. The contents of a folder have a relationship to the folder - that is they are 'members of'. Normally, it is not necessary to describe this type of relationship as the interface assumes the user understands this is the default.

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

Naming Objects with Relationships in a Graphical User Interface

      Today's Graphical User Interfaces (GUI) make use of 'folder' to
represent containment relationships between objects.  A folder object
can be opened into a window view of its contents.  The contents of a
folder have a relationship to the folder - that is they are 'members
of'.  Normally, it is not necessary to describe this type of
relationship as the interface assumes the user understands this is
the default.

      However, in more complex situations it may be necessary to show
various relationships between sets of objects.  The situation can be
made more complex by the fact that both 1-1 and 1-Many relationships
may exist and these do need to be indicated to the user.

      It may also be necessary to indicate to the user that a
relation between two objects exists and that this is other than the
simple 'members' relationship.  Consider, for example, the case in
which 'Ann', 'Bill' and 'Chris' are members of a 'Rowing' club,
whilst 'Ann', 'Dave' and 'Ed' are members of a 'Sailing' club.
'Bill' is also a member of the 'Tennis' club.

      One method of showing this would be to have a container object,
'Clubs' which contains three objects 'Rowing', 'Sailing' and
'Tennis'.  On opening the 'Rowing' object, the new window appears
showing some container objects such as 'Members' and some single
instance objects such as 'Address'.  Opening the 'Members' object
would show their respective members - that is one object for each
member.  A user wishing to know more about the object labelled 'Ann'
would open it and see a container object, perhaps labelled 'Clubs',
'Banks', 'Children' and some single instance objects labelled
'Address' or 'Father' (a person can only have one address and father,
so there is no need for a folder for such items).  If the user wishes
to know which clubs 'Ann' is 'a member of' he would open the 'Clubs'
object and would see two objects, 'Rowing' and 'Sailing'.

      The above scenario, while seemingly intuitively obvious at
first, can give rise to some problems for the user.  For example,
there are two container objects labelled 'Clubs', which if opened
produce different views.  One object is really 'All Clubs' while the
other is subset of this object and should be called 'Clubs of which
Ann is a member'.  The 'Rowing' club object is contained in both 'All
Clubs' and 'Clubs of which Ann is a member'.  Similarly there could
be many objects labelled 'Members' - they are 'Members of Rowing
Club', 'Members of Sailing Club' ... containers.  The object 'Ann'
could appear in many such containers.  The way this is normally
handled is to create duplicate or shadow icons which can be placed
wherever they are needed (see for example, OS/2*).

      Another problem occurs when the contained objects are shadows
of real objects.  In OS/2 the name of the object is used as a title
for the shadow icon (albeit in a different text de...