RiverWare Output Canvas: Tea Cup and Flow Animations / Questions
Phil Weinstein, CADSWES -- edit: 8-05-2014 -- See Project Index

Responses to David's Review e-mail of 8-5-2015

This is in response to the version of the document set aside here (first item). Subsequent changes are being made to the second item. (Refer to the "Document Status" sections in these documents):

I'm going to adopt some of David's suggestions in the current design document. But there are some philosophical issues which I think we need to get others' opinions on. I am a little concerned about how complicated things are getting in order to accommodate most of the things we are seeing in the two provided examples. (I don't think the initial design should try to do that). I will provide an updated document which will need broader review before pursuing more complexity. (BTW, I think that we may want to reverse the decision to go beyond a single marker line in the CDWR example, for the initial design -- i.e. perhaps we could start with just a single marker entity).

After revising the document, I think it would be helpful to look at actual configuration dialog mockups. The bulleted lists of configuration features are just too abstract to evaluate.

Here are David's last review comments, and my responses.

(1) [David]: We need to think about how they create and edit these tea cups. I think it should be a wizard approach to create them, but then they could edit each one individually once they are created.  I don't think they should have a fixed configuration across the canvas. What if I want to show reservoir storage in one teacup and groundwater storage in another.  Or Top of Conservation pool markers on one teacup, Guide Curve on another.  You should be able to quickly create a set of teacups with common config and slots, but then add/edit/delete teacups as necessary.

[Phil]: I'm generally concerned about support for uniformity among the items on the Output Canvas. There should be some Tea Cup properties which are common to all Tea Cups on the canvas -- or at least to sets of Tea Cups on the canvas. If every aspect of a Tea Cup is completely independently specifiable, it would be hard to even know, and confirm that Tea Cups are displaying the same sort of data. David has suggested that the canvas itself should not be such a place -- that it should be "agnostic" in terms of the items it contains -- e.g. it shouldn't have any general configuration for Tea Cups, as such. A particular limitation of the current design being reviewed (as David points out above -- SEE section 3.1 in the document) shows up in the "Long Labels" for Tea Cup entities not being able to accommodate specific different uses, e.g. for Reservoirs vs. Ground Water Objects. (That really is in the hands of the user -- how specific the text is that they enter for those entities). But I could imagine coming up with an intermediate Tea Cup "Template" definition, of which the Output Canvas would support several, and each Tea Cup would base its customization on one particular Tea Cup Template. This feels like its getting awfully complicated. I'd prefer to err on the simplicity side -- with all Tea Cups in a particular Output Canvas conforming to a single set of common Tea Cup properties (i.e. along the lines of section 3.1). A more complicated configuration system could be devised later, if requested.

(2) [David]: The labels need to be more general.  Any auto label we create is going to be the wrong number or in the wrong place. Let's figure out how to give them an easy way to show any number or text they want to see anywhere on the canvas. Maybe this could be a "Numeric Value" component like on the Snake Basin plot. Could we get this with the Text item or Flow Line? Or do we need another component?

[Phil]: The first part of David's comment is in relation to some provisions we're seeing in the BOR example and the two numeric values (zero or one or two) which I'm specifying as being "built-in" to the Tea Cup configuration (based on the CDWR example) ... the percentages shown here:

I like the idea of providing an optional convention like this. (See how I present that as item #7 in section 3.1). But we could ALSO provide a more free-form dynamic text capability with something along these lines:

... This accommodates only a single value. But such text items could be positioned anywhere, so several could be placed together (near each other), e.g. to show both an absolute value and a percent. (See some examples of this sort of thing in the sample BOR diagram). I'm not sure though that our initial design needs to get this fancy. (I don't think we need to try to accommodate everything shown in the CDWR and BOR examples in the initial design).

(3) [David]: I don't think we need an Edit/View approach as it seems too complicated. Locking the location of items on the canvas is sufficient.

[Phil]: We could go with just a "Lock" checkbox. I don't see that having a pair of radio buttons as being that much more complicated, and would help simplify the presentation of context menu operations. (These seem like very different work flows). (I was imagining displaying those two radio buttons on a row of widgets including also the timestep / animation controls, which will otherwise be pretty empty).

(4) [David]: The doc needs more info on export to image, export to animation, and inclusion in model reports.

[Phil]: I will add these to the design. The "export to animation" is going to be tricky! (But we can still identify that as a requirement of the initial design). Qt doesn't directly support generation of MPEG or AVI files (and not even GIFs, which can be animated). I've posted the following question on the Qt Interest list and the Qt Project Forum:

So far, I've gotten this response:

FFmpeg is a general library (not Qt as such) ... https://www.ffmpeg.org/ ... and there is some sketchy stuff about someone having created a Qt wrapper for this. In any case, at the present time, we need to go beyond Qt do accomplish this (generation of AVI or MPEG movie files, or something like that).

For the current design, including in model reports will just be specified as "still" snapshots (not animated movie files) -- like our current support for Pie Charts in model reports.

(5) [David]: You mention callouts, how are those supported? Are they just another Line component? Are they a Flow line with no associated slot?

[Phil]: My intention was to say that callouts are not part of the initial design. I guess we could allow Flow Lines to be configured without an associated slot for this purpose.

(6) [David]: Hiding is not necessary at this point. Snapping could be optional.

[Phil]: That seems OK. I'll remove hiding. Should I also remove "snapping" -- i.e. should Flow Lines all just be freely placed, without actual connections to each other or to Tea Cups?

- Phil