CLIM mail archive
[Prev][Next][Index][Thread]

Re: Selecting Presentations (coneptual)

    Date: Tue, 19 May 1992 16:06 MEST
    From: Mark Nahabedian <naha%RIVERSIDE.SCRC.Symbolics.COM@fhg.de>

    This is in regard to your questions about a user interface for selected
    objects.

Thank you.

    Your program has some objects to be manipulated.  These objects are
    represented on the screen by presentations.  A given object may be
    represented by more than one presentation.  The user selects objects
    which are to be manipulated by some program operation by selecting a
    presentation of that object.

    What visual feedback should the user receive for his selection choices?
    Should only the presentation that was selected be highlighted or should
    all presentations of the selected presentation's object be highlighted.

    The answer to this question depends on the nature of the operation being
    performed.  For an operation on program objects, all presentations of
    the selected object should be highilghted.  For an operation which is
    intended to apply only to the selected presentation, only the
    presentation should be highlighted.

    [...]

    The only thing the user gets to manipulate directly is the presentation.
    The application needs a way to disambiguate between the case when the
    user intends to manipulate the presentation, or the object which it
    represents.  It's sort of a graphical version of the quoting problem in
    textual languages.

An interesting analogy, I've never seen it that way!  But I'd like to
describe it in another way:

An "object" may contain different aspects (or is it "made up" of these
aspects?) from the user's point of view. Presentations of an object are
to visualize these aspects, i.e. each presentation may visualize one or
more of these. In that terms, the location of a file's icon in a Mac
Finder window and it's position relative to other icons are such a
user's aspect of the *file object* -- it's name andlocation in the
directory hierarchy are other aspects.

It's a *modelling issue*, whether you represent different user aspects
(of one "user object" or better "user concept") as different program
objects (in some sort, presentations are just as well program objects)
or as one complex object with an "aspect operation". With your
differentiation between program objects and presentations you take the
first point, the notion as a (graphical) quoting problem takes the
second -- the lisp interpreter gets the object "symbol" and can treat it
as a symbol (quoted = symbol aspect) or as a variable (unquoted =
variable aspect).

All this doesn't make things easier.
What happens when a user "selects an object"? Suppose he wants to
perform an operation on the object. He will only be interested in those
aspects of the object which are relevant to the operation. Note the
plural of aspects -- there may be several. Accordingly, all
presentations viualizing some of these apspects should be highlighted.
That's what I called "selection context". Of course, this set of
"relevant" presentations depends of the user has in mind, as you pointed
out in the example of dragging a file's icon in the Mac Finder:

    In some cases contextual information can be used to resolve this
    ambiguity. [...]

    In some cases the application doesn't know what's being operated on
    until the user's interaction is complete.  On the Apple Macintosh, the
    Finder serves as a graphical interface to the file system.  It allows
    the user to rename files, move them to a different part of the file
    system hierarchy or delete them.  The contents of a directory are
    displayed in a window.  Each file and subdirectory in that directory
    appears as an icon in that window.  The user is free to rearrange these
    icons by dragging them around within the window.  The icon is the
    presentation of a file and dragging it within the window is a
    manipulation of that icon.  When an icon is dragged outside the window
    onto another window, the user is indicating that the file which the icon
    represents is to be moved from the directory represented by the window
    where the icon started to the directory represented by the window to
    which the user dragged the icon.

    Since any given file on the Macintosh is only represented by a single
    icon to be highlighted.  The finder thus has the luxury of not needing
    to resolve the ambiguity between object and presentation until the
    interaction is complete.  

Many other applications take all presentations in one *window* as one
selection context -- that's technically easy and a reasonable
"heuristic": with window-based applications, you have the concept of
an "active" or "selected" window which somehow represents the
"focus of interest" of the user. Switching windows then means switching
selection contexts.

However, CLIM supports windows subdivided into panes -- there is in
general not "selected pane". And in CLIM it is (technically) quite easy
to have more than one presentation of one object -- although CLIM does
not support the programmer to keep track of the relation object -->
presentation(s). I guess, these two facts are the root of all these
questions about the selection metaphor. However, the root of the arising
problems lie in modelling and representation issues of complex,
multifacetted objects, where the metaphor "select an object" may
sometimes be just inadequat!?

Stefan B.

Mail: Stefan Bernemann        ! Phone:  +49-231-9743-139
      c/o FhG IML Dortmund    ! Fax:    +49-231-9743-234
      Emil-Figge-Str. 75      ! Email:  berni@iml.fhg.de
      D-4600 Dortmund 50, FRG !
References:
Main Index | Thread Index