Talk:Pipeline Browser Ideas

Re: Tree View Problems

What does a hierarchy mean?

When I look at Mark's diagram, it seems clear to me that we're asking the wrong question. Let's turn the problem around, and look at things from the user standpoint.

Take this simple test: Look at a Pipeline Browser representation, and without thinking about (code, etc.) implementation, draw the graph that it represents. Think as a user, not a programmer.

The Test

What does this Pipeline Browser representation show? To me, it logically represents this filter graph.

What does this Pipeline Browser representation show? To me, it shows this filter graph.

Conclusion

In other words, when I look at the Pipeline Browser hierarchy, I think it naturally leads to 'indentation means connection'. If we do it this way, I think we solve several problems - the thing makes sense, and I think it's easy to understand. Of course, this comes at the sacrifice of width - large chains of filters will be 'wide', because we always indent. Remember - we decided not to indent during our design discussion, because we didn't want these things becoming wide.

To me, the 'indent means connection' design makes sense, and it makes the whole widget easier to understand. Because of this, I like it for the first rev. We can, through user testing see how long a typical pipeline becomes (how wide they become), and address that problem.

--David 15:30, 28 March 2006 (EST)

Re: Berk's Design Proposals

This is pretty close to what I was drawing up. I have a few concerns about some of the ideas here.

First, changing the text color is a bad idea. For one, some people have a difficult time distinguishing color differences. Even the highlighting of related items can be problematic. The pipeline can be too large for the display window. This may cause some of the highlighted items to be hidden from the user's view. For straight and fan-out pipelines, the relationship should be evident from the item arangement. For fan-in pipelines, the highlighting may help, but the highlighted parts can still be hidden out of the view.

Second, showing the last member of a collapsed sub-pipeline is different from what the user might expect. If they have to learn how to use the new pipeline view, it should have a similar feel to other similar widgets. When a user collapses an item in a tree view, that item is still visible. I think we should maintain that concept in the new pipeline view. There is also a technical reason not to. Qt style can dictate where the elipse should be for an item's text. This is used when an item is too wide for a column. One of the style options is on the left. This would confuse the user with two meanings for the elipse.

To handle the problem of navigation for a fan-in item, I was planning on putting it in several locations. At the source level, it would have its own icon. In the pipelines it would have a special "link" icon. Double clicking or using a context menu, would allow the user to jump to the source location. At the source location, the context menu could list each of the inputs allowing the user to jump back.

--Mark Richardson 19:00, 29 Mar 2006 (EST)

I agree w/Mark's critique of naming of collapsed items. Still - we need to support collapsed items. Mark - you're planning on this, right?

--David 9:00, 31 Mar 2006 (EST)

Yes. I'm still planning on having collapsable items. The item would retain its own name, which is the way a tree view works.

--Mark Richardson 17:05, 31 Mar 2006 (EST)

A counter-opinion: I don't think we need collapsible items. I think the idea is confusing. In a normal tree view, when you collapse something, you are collapsing a branch of the tree. That makes sense because hierarchies naturally group things in branches. However, with our perturbed indentation, a collapse does not collapse a branch. It collapses an arbitrary section of the pipeline. It is confusing and probably should not be available any more than it should be available in a simple unordered list of filters.

If collapsing is supported, it really should be supported everywhere. Every single entry in the tree (except maybe leaves) should have that little "+", and when you click it, then everything from that filter to the end of the pipeline (or to some fan-in filter) is collapsed. It might not be clear, but at least it's consistent.

--Kmorel 10:57, 4 Apr 2006 (EDT)

I agree that highlighting is quite limited (some people are color blind, filters might be hidden etc etc.). However, I think it has a few advantages: 1. it is sex, 2. it brings forward associations for people (that are not color blind) and make it easier to focus on a local part of the pipeline, 3. it gives visual hints about associations such as linking. It doesn't have to be color necessarily. That was the first thing that came to my mind.

As for the last member of the pipeline being shown, it is matter of choice. Usually (but not always), the last filter is more representative of what a pipeline branch branch does. It's OK with me either way.

Oh, another thing, Charles suggested having the icons being more representative of the dataset. For example, we could have different datasets for polygonal data, unstructured grids, structured data etc. This could be in addition to source and filter icon. What do you guys think?

Berk 12:02, 30 Mar 2006 (EST)

We should not ignore color highlighting - it can be an aspect of the UI that shows differences, but having multiple channels for that type of information is necessary, as well, given color-blindedness.

--David 9:00, 31 Mar 2006 (EST)

I think custom source/filter icons is a great idea. We haven't designed a mechanism for it yet, but we've talked about it.

--Mark Richardson 17:05, 31 Mar 2006 (EST)

If we go with the 'icon zoo', we need to get a page up soon that describes our bestiary, so people can sound off about the graphics.

--David 17:19, 31 Mar 2006 (EST)