Mailing-List: contact general-help_at_simile.mit.edu; run by ezmlm
X-No-Archive: yes
Reply-To: <general_at_simile.mit.edu>
Date: Tue, 28 Sep 2004 20:37:44 -0400
From: Stefano Mazzocchi <stefanom_at_mit.edu>
X-LocalTest: Nonlocal Origin ([18.51.2.218]
X-Spam-Level:
X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham
version=2.63
X-SpamBouncer: 2.0 beta (9/23/04)
X-SBNote: Bulk Email (From_Daemon/Listserv/Resent/Precedence)
X-SBRule: Bogus HELO
X-SBRule: From domain matches first external Received domain
X-SBScore: 3 (Spam Threshold: 20) (Block Threshold: 5)
X-SBClass: Bulk
David F. Huynh wrote:
> 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.
David,
great to have you on board too.
> 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.
I feel kinda weird to discuss sorting at this level. For XSLT, for
example, sort was one huge problem for the server side implementations
because it stopped the ability to stream stuff.
For efficiency, sorting should normally be done closer to the data as
possible. For example, instead of doing an unsorted SQL query, generate
XML and sort it thru XSLT, it is always a lot more performant to make
the SQL output be already sorted and forget the transformation stage.
I tend to have the same feelings overhere, but I understand that the
situation of 'data aggregated from different sources' could be pushed
way higher in the stack than in "data in my database" scenarios.
cf my posting about different ways to do sorting.
> 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.
Aren't we dealing with content transformation at this point?
Yes, it would seem that what we want here is a view of "hierarchical"
data, where we have categories and want to view by category. The
expandable tree view is an example of this. It shouldn't be up to the
UI to create the grouping.
On the other hand, we probably need the UI to let the user _manage_
the grouping (ie, drag item from one group to another).
> 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.
This is definately transformation. I think we should not try to solve
all possible problems on the table. The presentation layer is
responsible to present, not to alter the data in any way.
agreed.
These are two different concerns and should be treated independently.
> 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).
Good point. Another trick is to use "semantic zooming", meaning that you
can consider nesting as a "entering the Z axis", for example, that once
you get deeper in the Z axis, the level of details of your lens might
get reduced, so you might have different lenses for different Z depths
(or depth ranges, say [3-inf[)
Nice.
although depth is a nice metaphor, at the end of the day we are
dealing with 2d. So rather than assigning lenses for different
depths, we should assign them for different amounts of screen real
estate.
I have a dream of a relatively complex scheme here, but not sure if we
want to pursue it right now. The idea is that any view specifies how
much space it "wants", along with some tolerance. It also specifies
which subviews should be embedded inside it. Now we have a problem of
assigning real estate from the view to each of the subviews. This is
a lot like the kind of line layout problems that word processors deal
with; they use various dynamic programs to decide the optimal
assignments based on the "happiness" of each subview with a given
amount of available space.
> 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.
Hmmm, wait. Let's not mix concerns again: the presentation ontology
should be concerned with the locales only if that meant to display it
differently.
The only think I can think of (but I'm sure I'm missing something) is
bi-di, but, again, CSS takes care of all that already.
bi di?
> 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?
Well, this is exactly the issue of styling: up to you to define the
locators and the styles that match them.
> 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.
Eh, good question, but I would like the group to focus on easy things first.
The easy answer is that for a read-only UI like longwell we don't need
to support such highlighting. On the other hand if we want a tool to
_manipulate_ the data we will have to say things about highlighting,
drag and drop, etc. Granted that the read only view vocabulary can be
developed without thinking about such things, I would love for the
energy being expended to _also_ produce some ideas for the read/write
vocabulary.
> 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?
Gosh, this is an interesting question. I honestly don't know where this
would fit. It is definately a usability concern and impacts
presentation, but I don't know if this is really something that we can
define at the ontology level without inventing an entire language for it.
> 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.
This is definately not a presentation concern.
If the user should not see the value, the right answer is not to
deliver the data to the viewer.
> User preference:
> ----------------
> Can the user change the view of a particular object and have that change
> persisted?
We do that in longwell, but I don't think that this behavior should be
driven by the presentation layer.
Not sure what you mean by "driven", but I think it is obvious we will
want to support such changes of view. In haystack these changes are
arranged by writing into the data model new assertions about what
should be viewed how; I don't see any way to support this in a "read
only" system.
> 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?
I feel this is another content issue: you can transform your model
before presentation, but you should not make the presentation layer do
the transformation for you.
I think there is a layer here _between_ the data and the presentation.
It is true that the presentation layer should not be resposible for
deciding which attribute of each object should be displayed on the
"title" column or "author". On the other hand, this is a very common
question that should have a simple (to program/describe) answer. The
approach that requires anybody presenting a collection to specify, for
each item in the collection, which attribute belongs in the title
column is a no go. One option is to record, for each _type_ of data,
appropriate (single or ranked list of) attributes that can be used for
the title, and then let the presentation layer go through a level of
indirection to get the value for the attribute. Another is to do it
on a per-display basis, saying "show view of C, listing properties X,
Y, or Z as available in column 1, and properties A or B as available
in column 2." The second does require more specification of the view,
but also lets the end user control their display at a fine grain, by
changing the list of properties to show in each column.
Like for XML, when you use XSLT to transform and then use CSS to style
it, so that you can keep the two concerns separate.
> 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.
CSS takes care of this.
Not entirely---mightn't we want to use different views because of the
different resolution of the final output?
> 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).
Right.
> 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?
I'm sorry, but I have to disagree.
The whole point of separating content and style is to achieve
orthogonality. This orthogonality is, as you point out, probably
impossible at a theoretical level, but if we solve 99% of the problems,
we cover a lot of ground.
> 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).
Here I agree: the pipeline concept is one of my favorite design patterns
and have proven tremendously successful in enforcing separation and
foster reuse thru simple contracts.
I would strongly be in favor of such an architecture for RDF
presentation, but right now we are dealing with the defining the last
stage and I think we should focus on this first.
I don't follow your qualification. Isn't what's being propsed exactly
the recursion at the end of david's comment?
> 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.)
I know you and David probably think that this discussion (and probably
the Longwell project) is reinventing the wheel that Haystack has been
using for a long time and, I have to say, I'm confident that you are
completely right and that you guys thought about these things a lot more
than we did.
On the contrary---I believe that for haystack we developed square
wheels, and it is about someone came along and made round ones.
At the same time, we have completely different needs and goals: if we
ever want to come up with a software that makes any impact on the world
out there, we need to make it *easy* for people to understand it, that
is: make it solid, easy to use and easy to grasp, then move
incrementally from there.
Haystack, on the other hand, is more focused on doing the think in the
most elegant way possible, with different priority and different metrics
on rating technological complexity and radicality of ideas.
I would say that the more elegant it is the easier it will be for
people to understand and use it.
That said, I think what david might be getting at is a kind of
circular dependency. We know that you may need to know the data in
order to determine the right view. But in certain situations it is
not possible to know what data you need to present until _after_ you
have determined what view will be used to present it. The lens is a
simple example---you don't know what properties you will need to query
until you find out what lens will be used, and you don't know what
lens to use to display the value of that property until after you have
queried the property to find out the type of object that is its value.
So, we can't just bundle up the data and ship it off to the
presentation layer. The presentation layer needs to go back and forth
with the data management layer in order to construct the presentation.
We want to stay in the middle, "applying" (and it's a shame this term
has so much negative meaning in some communities) some of that research
into something that users can really use.
The point is not to reinvent the wheel, but to get there incrementally
and in a solid fashion.
This is why we need to start small, but also we need to listen to those
that have more experience on the subject like you people.
> 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.
As I said, this does not be specified at the view level and there might
be client-specific configurations for this when we start.
Some of it does have to be specified---eg, how much screen real estate
is needed for a given view.
Anyway, thanks for the input, it's greatly appreciated!
--
Stefano Mazzocchi
Research Scientist Digital Libraries Research Group
Massachusetts Institute of Technology location: E25-131C
77 Massachusetts Ave telephone: +1 (617) 253-1096
Cambridge, MA 02139-4307 email: stefanom at mit . edu
-------------------------------------------------------------------
Received on Tue Oct 05 2004 - 21:28:05 EDT
This archive was generated by hypermail 2.3.0
: Thu Aug 09 2012 - 16:39:17 EDT