[kepler-dev] Displaying repository results in component search pane
Sean Riddle
swriddle at gmail.com
Fri Mar 12 14:05:43 PST 2010
Now that a given KAR file can contain multiple items (like a workflow
and a report), I'm trying to rethink the way repository results are
displayed in the component search pane so that relation isn't lost.
For instance, consider the following: There are two items, a workflow
W and report R, in a KAR file. A user searches on the LSID of the KAR
file, so both results have to be displayed. The workflow and report
have semantic types S_W and S_R, respectively. At the moment, the
system would display this:
S_W
|
|
--W
S_R
|
|
--R
There's no hint that W and R are related. So here are a few ideas for
preserving that information.
Option 1, I was thinking, is to introduce an extra top level to show
containment in a KAR file, like so:
K
|
|
--S_W
|
|
--W
--S_R
|
|
--R
The downside to this approach is that S_W and S_R could appear
multiple times if other search results in other KAR files share those
semantic types. This could clutter up the search results.
Another option, rather than trying to overload a single tree with this
additional data, would be to introduce another mode for the search
result pane, where it just shows containment. In this case, the
semantic type mode would be what the system currently does, and the
containment mode would show the following:
K
|
|
--W
--R
Of course, this introduces the problem of the best way UI-wise to
switch between the two modes, etc. I think this would be good for some
point in the future, but not for 2.0.
My preferred option, at the moment, is similar to what the system does
now. It relies a bit on the fact that from what I've seen, reports
don't get semantic types (Let me know if I'm wrong about that). For
the purposes of display, I figured give them the same semantic type(s)
as the actor/workflow (this assumes there is one), and then
communicate the relationship between the two through the displayed
name of the report:
S_W
|
|
--W
--R (W report 1)
So those are just some ideas I've been kicking around. Please reply if
you have a preference or other ideas.
- Sean
More information about the Kepler-dev
mailing list