W3C home > Mailing lists > Public > public-lod@w3.org > August 2008

RE: freebase parallax: user interface for browsing graphs of data

From: Georgi Kobilarov <gkob@gmx.de>
Date: Wed, 20 Aug 2008 03:31:58 +0200
Message-ID: <180C011CD4FF654AB4B73A9A5AD7472C0A48D5@aristoteles.zuhause.lan>
To: "David Huynh" <dfhuynh@alum.mit.edu>
Cc: <public-lod@w3.org>, <semantic-web@w3c.org>

Hi David,

> That distinction between facets and connections was made by listening
> to
> users (inside Metaweb). They were already used to faceted browsing,
> they were trying to grasp the "pivoting" feature. Separating the two
> features visually seemed to make the UI easier to learn.
> I can also explain that distinction in a different way. Parallax is
> intended to be a browser, not a query builder. Personally, to me a
> query
> builder implies a closed-world database where there are few types and
> how these types are connected is understood by the user. For example,
> the database might contain data about publications, authors, and
> conferences. The user is assumed to be aware of how those types are
> connected. The query builder can then let the user specify patterns to
> match this closed graph by presenting the query graph in some visual
> way. Now, if we're dealing with an open world instead, then I don't
> think a query graph, and hence, a query builder, is suitable
> conceptually. Parallax embodies a browsing paradigm instead of a query
> building paradigm. In Parallax, you just keep going forward, much like
> you would on the Web. In normal web browsing, you don't expect a web
> page later in the history to somehow influence a web page earlier in
> the history.

Good point about the perception of browsing as only going forward.
When I started my work on UIs for graph data at HP Labs, the paradigm I
wanted to apply was zooming and panning. I've never really solved that,
but I still think there is an analogy there to pivoting. 

As you said correctly, I'm trying to build more of a query builder than
a browser. Zooming is an increase in the level of detail, and I think
pivoting (in my bi-directional query building style of interface) can be
seen as exactly that: Increasing the level of detail in a particular
dimension for a set of resources. However, one could also interpret
pivoting as panning because each set of resources (after several pivot
operations) has the same level of detail. I'm unable to make a clear
distinction here.

In order to not confuse the user when applying the query builder
paradigm, it is key to represent the query path accordingly. Where am I
coming from and how do my previous choices influence the current set of

Please have a look at [1] to see what I was thinking of to achieve that
(in particular slide 18 ff.). Please note that this presentation shows a
more advanced design of Humboldt, while my paper described an earlier

> This is actually a very subtle point

It is, but it's a good one. However, in my opinion, it is the result of
a certain UI design where there are no transitions between two sets of
resources. Animations could help?!

> I should also point out that there was a very conscious effort to not
> stretch the new browsing paradigm so much from the existing (web)
> browsing paradigm, so that people can understand and use it. As
> researchers, we all love to run 10 years ahead in the future, but I
> purposely lag behind so not to lose sight of the current user base.
> screencast together with the live working prototype also seem to get
> the
> point across effectively, even to non-SW enthusiasts. I wish more
> research can be experienced this way.
> [...]
> I think there's a bit more to say about the "lagging" point that I
> above. Building graph-based data UIs is extremely difficult. If we
> to cram all the power that can be afforded by, say, SPARQL into the
> then we face with the problem of making huge complexity appear simple
> enough. That's a tall order. And I tend to shy away from huge
> challenges. Instead, I just want to improve the current experience a
> little bit. In this case, it's the ability to go from set to set, as
> compared to going from one to one. This new capability won't let the
> user do everything possible with SPARQL, but it lets the user do more
> than possible before. And maybe that's good enough for now.

Yes, there are always two ways to approach UI design: Building the most
expressive interface and then trying to simplify it, or building a
simple interface with a simple interaction paradigm, and then increasing
expressivity as far as possible without giving up simplicity. I'm more
of a fan of the later too...

> > the label showing the particular related resources in a set of
> connected
> > resources, e.g. browsing from people to locations and displaying the
> > related people for each location, although I'm somehow missing an
> > interaction feature there.
> >
> You're right--that part of the UI was added in a later stage and needs
> some re-thinking. For one thing, I'm still struggling how to name
> links. Specifically, if you're starting with the presidents, and then
> pivoting to their children, then what should the link "Ronald Reagan"
> on
> top of "Michael Reagan" be called? There have been a few suggestions,
> such as "contributory links", "tributary links", "lineage links", ...

I like "tributary links". Actually, what those links represent are
inverse facet values. I very much liked your way of highlighting all
connected resources per facet value in NFB. Maybe that's the kind of
interaction I was thinking of for the tributary links.

> > I haven't highlighted that enough in my first message (mainly
> I
> > knew your former prototype of a "nested faceted browser", which has
> > already demonstrated such an interaction model), but I'd like people
> to
> > recognize how important that aspect is for the future of graph-based
> > data UIs!
> >
> I second that. I think that once we can refrain from the default
> to present a data graph as a visual graph, then we really open up to
> many possibilities. With Parallax, I hope to show just one
> and it's exciting to see what others might come up with.

It's great to see your work as UI expert in the area of graph data /
Semantic Web data. I hope that these two research areas will work even
closer together in the future, because there is still enough work to do.

Maybe there's a chance to collaborate here, what do you think? 

I'm also not aware of any upcoming semweb UI workshops. WWW2009 might be
a good place...


[1] http://www.georgikobilarov.com/presentations/2008/03/Humboldt.ppt

Georgi Kobilarov
Freie Universitšt Berlin
Received on Wednesday, 20 August 2008 01:33:47 UTC

This archive was generated by hypermail 2.3.1 : Sunday, 31 March 2013 14:24:17 UTC