Georgi Kobilarov wrote:
> I don't think that the web page metaphor applies very well, but I'm not
> sure. I think of an explorative query builder, and that's more related
> to multidimensional databases. I hesitate to use these terms because
> they introduce an huge amount of complexity. But that is the
> expressivity I would like to fit into an useable interface. Crazy?
>
Perhaps we have different objectives: you want to explore big graphs
while I want anybody to be able to build a browseable UI for a small graph.
> The group-by feature is neat, but it will break as soon as the user's path
> becomes as graph. Then the group-by would need a "refocus" feature as well to
> enable the user to explore /what/ he could group-by.
> And then the distinction between these two ways of filtering is more
> confusing than helpful.
>
> Maybe my idea of lifting the path to a graph doesn't work at all...
>
You're right that if the path is a tree or graph (with operations like
set union and intersection), then link sliding and group-by would break.
I'm still thinking of a solution for that :-)
>> Well, if you think "if I put 'papers' in, I should get 'papers' out"
>> then you're still thinking in terms of tables, rather than of graphs.
>> With graphs, you can put in "the Kennedys" and get out "the people who
>> hired the guys who shot the assassins of the Kennedys". Or if you put
>> in
>> "publications" you might want to get out "the funders who fund the
>> professors at the schools where the graduate students work on topics
>> related to the topics of those publications." :-)
>>
>
> Well, I was thinking of the sequence of filters as a kind of pipeline (I
> steal that metaphor from my colleague Richard here).
> If you think of it as a pipeline, you put in stuff and get a subset of
> that same stuff out. Navigating the graph is only done to select
> filters, i.e. as you wrote above, the user only temporarily switches
> focus.
>
I did think of query graphs and other designs, e.g., in early 2005
http://people.csail.mit.edu/dfhuynh/research/ideas/zoomable-faceted-browsing/query-graph-2.pdf
http://people.csail.mit.edu/dfhuynh/research/ideas/nested-queries-in-faceted-browsing/page-06.png
but I'm not convinced that a pipeline UI is the best.
>> There is another reason why the influence goes from left to right
>>
> only:
>
>> it's easier to understand when the effect is in one direction. If the
>> influence goes both way (i.e., the whole solution is a fixed point),
>> then it would be (even more) confusing.
>>
>
> I'm not convinced ;) Seems like a good place for a little user study...
>
You're right on this one, too :-) You don't know how good it is to hear
a SW guy say "user study" :-)
>> Obviously this prototype will need many more iterations until it makes
>> any sense to most users. Please let me know if you have more thoughts
>> on
>> the prototypes or on the topic in general!
>>
>
> Well, let's imagine a dataset like DBpedia where the user doesn't know
> the graph and doesn't know which filters could be applied. A task where
> the user has to explore the dataset first. That exploration is much
> easier while looking at actual data. And again, the group-by breaks ;)
The group-by feature *as it is implemented* would break... But yes,
DBpedia is a good data set to experiment on.
David
_______________________________________________
General mailing list
[email protected]
http://simile.mit.edu/mailman/listinfo/general
