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.
> 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?
> 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.
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.
> 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.
> 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.
> 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.
> 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.
> 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.
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.
> 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.
> 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.
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.
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.
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 Wed Sep 29 2004 - 00:37:22 EDT