- From: Georgi Kobilarov <gkob@gmx.de>
- Date: Wed, 20 Aug 2008 03:31:58 +0200
- 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, 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. 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 results? 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 prototype. > 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. 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. > [...] > 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. 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 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", ... 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 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. 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... Cheers, Georgi [1] http://www.georgikobilarov.com/presentations/2008/03/Humboldt.ppt -- Georgi Kobilarov Freie Universität Berlin www.georgikobilarov.com
Received on Wednesday, 20 August 2008 01:33:47 UTC