PostMortemOverview

Welcome to the end of the beginning. Here we will record our current thoughts about what's going on, and where we need to go for the future. Please add issues, and join in on discussions/topics that get you worked into a lather.

We'll start discussing these topics in our next telecon.

 When editing, please follow the standard convention of talk page
 (http://en.wikipedia.org/wiki/Wikipedia:Talk_page).  In particular, indent responses from 
 what they are responding to with colons (:) and make sure you sign your entries with four 
 tildes (~~~~)

Undo/Redo

Summary: Need flexible support for undo/redo.

Links: Undo Design

This capability is important to integrate from the start. It'll be an added 'tax', but well worth it to users!

--Hollywood 17:30, 22 Jan 2006 (EST)

Selection

Summary: Need flexible support for selection operations.

Links: Selection

This is one of the things that we have support well. People react visibly to linked view selections in our demos.

--Hollywood 17:30, 22 Jan 2006 (EST)

Plotting

Summary: Flexible support for parallel graph operations, as well as highly interactive client-side graphing.

Links: Plotting Parallel Data (PGraph)

Ken's PGraph work will address parallel concerns, but there is a huge component of client-side graphing in ParaQ. How do we manage mulitple client-side graphs? How does the user understand what's being graphed? How is that controlled? In our recent demos, one use case that came up was that of having client-side graphs appear on a tiled display. Not a high priority, but something to think about in the overall architecture. We seem to be spending a lot less time on the tile display requirements these days.

--Hollywood 17:30, 25 Jan 2006 (EST)

I think putting the plots in the multi-view with the other views will make it easier to expand the capability of the graphs. It will also simplify the graph/model coordination. If we put the plots in the multi-view, we can add them into the pipeline browser(s). This can greatly expand our options. We could use tool buttons and context menus to connect the plots to the appropriate model.

Mark Richardson 12:40, 26 Jan 2006 (EST)

Testing

Summary Test or die.

LinksTesting Requirements, Testing Design, Notes on ParaQ Testing, Testing Prototype, Early Testing Prototype, Hello World Testing

We're on our way with the dashboard, the testing framework, and the mentality of the group. Now, we have to commit to writing test plans, test cases, etc. Again, a balancing act with development.

--Hollywood 17:30, 22 Jan 2006 (EST)

Connection

Summary: Flexible support for connection to servers; wide range of users and use cases.

Links:

Tim, Lisa, John and I were talking about this at lunch today, and if we can make this aspect of using ParaQ simple (OK, as simple as possible ...), we're going to win big. This will be a lot of work, for something that the user blows by every time he/she uses ParaQ. I can also be a big user sticking point, if we ignore it.

--Hollywood 17:30, 22 Jan 2006 (EST)

Save/Restore

Summary: We can save a lot of information, but what operations (Save, Restore, etc.) make sense to the user?

Links:

Installation Management

Summary: Several platforms need installation scripts/packages soon, so that we can manage user testing, demos, etc.

Links:

Development Process

Summary: What is our development model for the coming releases?

Links:

We touched on this briefly in a recent meeting, but we'll need to formalize it in the next few weeks. I'm a big, big fan of frequent 'working releases', especially given that we want to exercise a lot of capability in the coming months. Testing (including user testing) will have to be an integral part of our development process, as UI design and useability issues are a major motivator of the entire ParaQ project.

In addition, we should reflect on how we're starting to work together as a team. If there are problems in communication, or if we need to re-structure our responsibilities, let's talk about that as we move forward.

--Hollywood 17:30, 22 Jan 2006 (EST)

Alternate views of the pipeline

Summary: What are our standard UI views of the pipeline?

Links:

Our current pipeline browser is fine for demos, but we'll quickly outgrow this. Will we always support several views of the pipeline? What designs - whether alone, or in concert - best allow the user to understand and operate on the pipeline?

--Hollywood 17:30, 22 Jan 2006 (EST)

I have a plan for the pipeline list view that will make it useful beyond the demo. I don't think we will outgrow it. I've been putting the pieces into place as I've prepared it for the demo. I can make some examples after the demo, but I think we can show any pipeline in the list view. I think we should still implement a graph view of the pipeline to give users another option.

Mark Richardson 12:34, 26 Jan 2006 (EST)

I can understand how we'd show 'fan-out' pipelines - one thing indented below anther - but how about 'fan-in' - things that have more than one input? At present, this case is rare, but it may become more common in the future. Of more pressing concern is a pipeline like that in Prism - where a pipeline branches like this, to several windows:

 A->B->C->D->E->(shown in window_a)
          |
           ->F->G->(shown in window_b)
          |
           ->H->I->(shown in window_c)

This seems like it'd be hard to represent in the current pipeline browser, but maybe if we just remove the windows from it, we're OK. Dunno.

Hollywood 17:30, 22 Jan 2006 (EST)

Architecture for Coordinated Views

Summary: How are Client-side views integrated into the overall ParaView/ParaQ architecture?

Links:

Lots of interesting uses of ParaQ are going to include multiple linked views. What is a good multiview architecture? A good linking architecture? How much of this functionality is available to the users - are there compound-filter-like things that we can use to set up multiview interfaces? This is an important part of UI customization.

--Hollywood 17:30, 22 Jan 2006 (EST)

Taming the Filter Zoo

Summary: How can we make it easy to use the different types of filters?

Links:

The Filter graph architecture, though powerful for programming, can be difficult for users to grasp. In fact, it's one thing that stands in the way of simplifying ParaQ. We've spoken briefly about having the user perform 'operations' (clip, threshold, etc.) rather than 'apply filters to anther filter', but is it possible to hide the filters from the user, or should we force the user to understand the paradigm? Maybe it's enough to have the 'expert' mode, in which the entire pipeline is exposed, and a 'novice' or 'compound filter mode' where everything is hidden. We may only determine this through user testing and prototyping.

Filters fall into several rough categories. A few that make sense to me are 'filters that operate on pure data' and 'filters that need a couple of inputs'. An example of the former is a Threshold filter, an example of the latter is the Glyph filter. The Glyph filter needs in input data set and in input glyph. Will it be up to the user to understand the input needs of a filter? Can the PV Server provide a client with enough information to auto-generate a useful UI (object inspector)? How does the user want to interact with various filters?

--Hollywood 16:15, 26 Jan 2006 (EST)