Georgi Kobilarov wrote:
Hi David,
thanks for your message :)
Hi Georgi,
Apologies for the late response.
In the meantime, I took a closer look at parallax. There are many nifty
little UI features I like, such as the "what did just happen?" message,
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 those
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", ...
And I'd like to say that in my opinion parallax's core interaction model
of browsing connected *sets* of resources is a incredible important
contribution to the area of graph-based UIs!
Thank you, I really appreciate that! But don't be modest yourself! :-)
We both have been going in similar directions if not the same. For the
benefit of others, here's the conversation Georgi and I had last December:
http://simile.mit.edu/mail/BrowseList?listName=General&by=thread&from=16039
In your Humboldt paper, you also explained the concept as browsing from
a set of resources to a set of related resources. And of course, as
Daniel Schwabe pointed out, he did very related work more than a decade
ago. I'm glad there's convergence here. This convergence indicates the
importance and timeliness of the problem to be solved.
I haven't highlighted that enough in my first message (mainly because 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 reflex
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 possibility,
and it's exciting to see what others might come up with.
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. The
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.
Indeed, initially, the facets and the connections were not
separated. Then, from user feedback, I split them apart, making those
two conceptually different features independent and visually separate.
I've been thinking about your point of facets and connections being
conceptually different features.
In my opinion, they are not conceptually different. I see that it makes
sense (or is even necessary) to make them independent and separate in an
interface with uni-directional filtering, but *conceptually* (including
a possible bidirectional filtering) they are not different. They both
present connected (via a particular property or via a "complex"
function) values/objects, grouped by different dimensions, for a given
set of resources. On top of that, there are interactions with the facets
such as using them as filters or browsing their values. I think, the
need to separate filtering and browsing is a result of limiting to
uni-directional filtering along the graph.
It might make sense to handle value properties (numbers, geolocations,
...) differently than object properties (resources/instances), but as
far as I can see, that wasn't your point. And in your NFB prototype, you
haven't made that distinction.
Actually, in the NFB prototype, you can't pivot to value properties. For
example, in
http://people.csail.mit.edu/dfhuynh/projects/nfb/browser.html?data/publications.js&data/publications.css
you can't pivot to the tracks as they are modeled as values, not
objects. But in any case, you're right that value properties should be
handled differently from object properties. Parallax actually uses only
object properties in facets and connections, because there's some
challenge in computing a facet based on a value property using
Freebase's query language.
So, could you elaborate why you're now making that distinction?
That distinction between facets and connections was made by listening to
users (inside Metaweb). They were already used to faceted browsing, and
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. Same thing in Parallax.
This is actually a very subtle point and a point that pained me for a
long time while I was prototyping NFB on paper. I solved it (I hope!) by
enforcing uni-directional influence, and introducing the "group by"
feature. The "group by" feature was discussed in our previous
conversation on the Simile mailing list. However, "group by" is not in
Parallax yet because I was too eager to release it.
I think there's a bit more to say about the "lagging" point that I made
above. Building graph-based data UIs is extremely difficult. If we want
to cram all the power that can be afforded by, say, SPARQL into the UI,
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.
So if I had it my way, they would be together; but by listening to other
people, they are now separate.
I would love to have a look at that earlier version ;)
Trust me, you don't want to look :) It's just like NFB, except a whole
lot more confusing and buggy.
David
