Re: Display requirements

From: David R. Karger <karger_at_mit.edu>
Date: Fri, 24 Sep 2004 14:33:13 -0400

Lots of good stuff here. I'm going to pick one thing, the issue of a
sortable collection display, to think about the how/what
differentiation.

This may be irrelevant for display to a web browser, where such active
widgets might not be under consideration. But I hope we can get a
vocabulary that extends well to a richer client like Haystack.

So consider the problem of displaying a collection, in typical "one
item per row, with certain attributes in columns" form. As David
mentions, one of the things we want to support is clicking on a column
to sort according to that column. The question is, where do various
reponsibilities get delegated?

First, there's the issue of which columns (properties) to display.
This is itself a collection that is used to configure the view. In
haystack we want the user to be able to control which columns get
displayed, so we represent the collection of properties in RDF as
data.

Then there's the question of how to sort. There seem to be at least 3
plausible stories:



1. The view knows how to sort certain basic types (strings, ints).
    When the column is clicked it applies that sort to all items whose
    attributes in that column has one of the known basic types, and
    sticks all the items whose value on that attribute is unsortable
    at that end.

2. The view doesn't understand sorting. The view receives a list of
    items in a given order and displays in that order. When a column
    header is clicked the view delegates the sorting task to the
    underlying data model, and redisplays according to whatever new
    order comes back. So the collection view is actually an
    ordered-list view, but the creation of the ordered list is left to
    the underlying data model.

3. Clicking on a column is actually a manipulation of the underlying
    data, declaring that the underlying collection is actually a list,
    and that the list should be reordered according to the sorting
    column. As in (2), the view just presents the list in its
    existing order.

Option 3 is the most "elegant" in that there is a clear
differentiation of what (and ordered list in the data model) and how
(display the list in that order). But it probably isn't what people
want---I can certainly imagine wanting to look at the same data in two
different orders at the same time, which is impossible in option 3.

Option 1 may be the most convenient, but does make some very heavy
assumptions. It will run into serious trouble if, for example, I am
displaying a list of documents with authors, where the authors are
richly-represneted "people type" objects, and I want to sort by
author. We could try to get around this passing in some method for
extracting a key, but I don't think this is noticeable different from
leaving it to the data model to sort.

So I am inclined to option 2. In particular, to setting up our
collection views to receive an already sorted list, and not have them
worry themselves about the order. For example, we could arrange to
pass in a (newly created) RDF list pointing at the elements of the
collection.
Received on Fri Sep 24 2004 - 18:33:14 EDT