Hi all,
David Karger asked me to join this discussion as I was involved with the
development of Haystack's UI framework a while ago. I took a quick look
over the discussion and tried to throw in some ideas here. My apology if
I'm repeating somebody else's previous comments. Consider this as a
brainstorming braindump.
Requirements
============
In no particular order.
Sorting:
--------
This extends beyond sorting a list of items from a dataset coming back
from a search query. It also applies to the presentation of multi-valued
properties (e.g., authors of a paper). Say, if we are displaying a set
of papers in a table, we should allow the user to sort the list of
authors in each individual cell under the Authors column either by the
authors' last names or by the order that the authors are specified on
the paper. And then, the whole Authors column itself can be sorted
ascending or descending. This is the tricky part. The sorting of the
Authors column can only be done after each individual Authors field has
been serialized to a string.
Grouping:
---------
Users can be allowed to group items, in which case, the property values
by which the items are grouped should be pulled out of individual views
of the items and placed in separate header rows.
Summarization:
--------------
In conjunction with grouping, we can provide summary data, such as the
count of items in each group. Other summary functions include average,
sum, mean, median, min, max, etc. If grouping is done by the browser,
then summarization has to be done by the browser.
Nesting:
--------
In Haystack, the use of nested views can lead to indefinite expansion of
inner views, even in circles. For example, the view of an email embeds
the view of an author, which embeds the views of emails that s/he sent
recently, which of course includes the view of the original email, etc.
Some limit of this nesting should be enforced before the user gets lost
diving down into the nested views (yes, we did observe such a behavior).
Internationalization:
---------------------
Big, scary topic... Well, if we want to truly aggregate different
sources of data, our UIs should be able to mix UI elements for contents
from different locales.
Highlighting/brushing:
----------------------
Can we allow users to highlight only items with a certain
characteristics? How would the highlighted items appear? How would the
items not highlighted appear?
Synchronization:
----------------
How do we specify the synchronization between different views? For
example, the action of selecting something inside a listview of items
navigates a preview pane to a more detailed view of that item.
Caching/on-demand:
------------------
How do we specify the loading options for a view? Can we indicate that a
view is currently loading its content using some animation? What if the
definition of the view is remote and unavailable at the current time?
Security:
---------
The user might not be allowed to see the value of a particular field.
How do we provide an explanation for this security permission? It would
be nice if in the place of the view of that field, an explanation is
provided as well as a method for obtaining permission.
User preference:
----------------
Can the user change the view of a particular object and have that change
persisted?
Attribute aliasing:
-------------------
How do you display a set of items that do not share the same set of
attributes? If several attributes are semantically similar to the user
(e.g., mail:subject and document:title), can they be collapsed into a
common virtual attribute?
Printing:
---------
Going beyond the browser and the computer screen, what do we need in
this ontology to support printing? We might need absolute dimensions,
pagination, color management, etc.
Presentation language
=====================
In building a framework for presenting RDF data, one might be inclined
to separate the presentation process into 2 sub processes: the selection
of an information subset (what to present) and the laying out of that
information on a visual display (how to present). But this separation is
usually very hard to make in practice, and maybe it shouldn't be made in
theory either. If in presenting a person object, I choose his/her
portrait photo, then the presentation is pretty much fixed. How
something is presented also influences what is presented: showing an
image file as an image on screen communicates its visual content, which
cannot be presented in any other way. Can I quote McLuhan's "the medium
is the message" here?
Perhaps skirting the issue but I try to think of the process of
presenting information as a series of transformations, converting a body
of abstract information ultimately to pixels on the screen or inkdots on
a page. Each transform takes in a body of "what/how to present" and
yields *a set* of bodies of "what/how to present" (e.g., property values
to present and how much space to present them in).
Following this transformation model, it makes sense to specify each
transformation as a unit, which requires the mixing of specifications
for what to present and specifications of how to present. This is
precisely the Haystack's approach: Adenine supports both the selection
of information through its imperative syntax as well as the layout of
views through its declarative syntax. (Adenine needs some improvements
but the main idea is the same.)
Perhaps the biggest headache in specifying a view ontology is coming up
with a way to specify which contexts a particular view should be use.
Such specifications can be complicated. For example, a view should only
be used when the user has such and such security permissions, is using a
display of so and so size, before a certain transaction has been made, etc.
David
Received on Thu Sep 23 2004 - 21:50:00 EDT
This archive was generated by hypermail 2.3.0
: Thu Aug 09 2012 - 16:39:17 EDT