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

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

Received on Sunday, 17 August 2008 08:04:04 UTC