Embed table or graph with ACP

Tall input or output nodes

If you want to embed an edit table, result table or result graph in a diagram in AWP, simply make its input node for an edit table or output node for result table or graph tall: AWP displays the table or graph using the outline of the input or output node as a frame (instead of just showing a button that opens a separate window), if the node height is more than 4 times its default height. The default height of an input or output node is initially 26 pixels, so it will embed the table or graph if the height is more than 104 pixels. (The default height is actually a function of the text size, so "tall" be larger than 104 pixels, if you choose a larger font size than the default 11 point.)

AWP uses the table or graph format last used in the last version of the model you saved in DTA. So, if you want AWP to show a graph (not result table), you should view it that way -- and set any graph style options you want -- before you save it. Similarly, for an Edit table, choose the pivot (which index is rows and which columns) before you save the model. Similarly, AWP will use the uncertainty view -- mid, mean, statistics, pdf, cdf, or sample - that you last viewed in DTA. (This information is stored in the valuestate attribute for the original node.)

If the edit table or result table is larger than the area provided in the node, it displays whatever fits, along with scroll bars to let the user access the rest. It automatically sizes the graph to fit the area, which generally works well as long as the area is large enough.

Example usage

Here's how the modeler creates the output node in DTA:

Here's the result displayed on the diagram in AWP:

Embed_location (formerly Results on right)

During the first round of work on the USGBC's LEED Credit Calculator, we used a text node with the special idenitifer 'Results_on_right' to select a rectangle (the outline of the text node) where to display the edit table, result table, or graph of any selected node. It also displays the title and description of the selected variable at the top of the frame, and highlights the displayed node, so you know what you are looking at. This scheme turns out to be very convenient, since the author needs specify a single area, and the end user can quickly see the table or result of any node selected in a diagram or form containing inputs and outputs. It is especially handy in AWP where the user is viewing the model via a Web browser, and cannot easily position multiple windows to view diagrams and results at the same time, as they can in DTA. It would also be a convenient UI option for DTA, letting end users easily view input and output tables and graphs, without having to rearrange windows all the time.

It would be useful to expand the scheme to allow display of more than one edit table, result table or graph in the same Diagram view. For example, you might want to see a table and corresponding graph at the same time. Or see multiple graphs for comparison. For some models it may work better to arrange the diagram nodes to be wide, with the results below, or above, hence the name 'Results_on_right' may become misleading. Accordingly, here is an expanded spec, based on Fred's suggestions with a few tweaks:

Spec for something better for non-specific embedded frames

If we want to display edit tables, or results in multiple frames, AWP needs to know which frame to use for which node.

A. One option is (as in Fred's scheme below), you can specify an AWP_attrib for each node, containing FrameNode:TextNode1 to specify that it use Textnode1 as the frame. If you want to show two frames say in a diagram for Module M, you could set one, say Textnode1 as the default by specifying

  Module M
  Awp_Attrib: FrameNode:TextNode1

By default any node in M will use Textnode1 as its frame. For selected nodes, you could add the attribute to those Objects:

  Awp_Attrib: FrameNode:TextNode2

and they will use a second TextNode2 as their frame. As Fred points out, it is tricky but possible for a user to specify an attribute for an alias, input or output node -- rather than its original node. Generally, for each module, you'd only want to specify a frame in that diagram, so inheriting a frame node from a parent diagram would probably not be that useful.

B. Another option would be to use cycle through any available frames -- the first node clicked would use the first frame. The second uses the second frame. If there are only two frames in the diagram, the third node will reuse the first frame. And so on. Normally, the author would lay out two or more frames of the same size.

Pros:

• The user can compare two or more input or output tables or graphs just by clicking on them.
• The user controls which node edit tables or results are shown at the same time (subject to

the number of frames available) -- i.e. the last n nodes clicked on display in the n frames.

• The author need only define one or more frames for a module -- no need to define frames

separately in the AWP_Attrib for any nodes.

Cons:

• The author can't control which input or output displays in which frame.
• For that reason, it would be usual to make all the frames the same size. There's no way for the author to control that a small edit table, say, go in a small frame, and large graph, say, in a large frame.

(For this multiple frame scenario, I think it would also be easy to add the functionality that a user could click on a node, and then drag the mouse over to the frame, and then display the table or graph for that node in that frame. Don't know if this functionality is really useful, but it is appealing IMHO. Fredbrunt)

Option C: If we combine Option B with the embedded tall input/output node scheme, the author can use the tall node scheme if they want to always show a particular node table or graph in its own (custom-sized and located frame). If there is not enough room for every node to have its own frame (the usual case), the rest can share common frames, as in Option B.

What is displayed?

Title and description: It displays the title of the variable is displayed in bold at the top, with description below it. If Description contains more text than will fit in the top 1/3 of the framenode, it shows only what will fit in the top 1/3, with a scroller to see more.

When Diagram window is opened, and no node has been selected, it shows the title and description of any Frame node, which is useful for initial explanation of the diagram/module and how to use it. (That's what we did in the USGBC model.)

Font size: It uses the font style and size specified for the frame node with the title in bold -- initially the title and description specified for the frame, and then the title and description for the selected variable. It should allow web links (as in other descriptions) to appear in the description text.

If users clicks twice on a variable node (not double-click) and there are at least two frames, it shows the default (graph or table) view in the first, and the other (table or graph) in the other. Alternatively, we can label a framenode, as "Graph_over_table" and it shows the graph and table in the same frame node, with only one title and description at the top. It's up to the author must make sure it is large enough.

FrameOptions:

• Show_title [on by default]
• Show_description:nn : Where nn is a number between 0 and 100, where it uses up to nn% of the vertical space available to show the description, showing vertical scroller if that isn't enough to show the entire description. if nn=0, it shows no description (and no scroller). Default if not mentioned, is "Show_description:30"
• Graph_or_table: Shows whichever form was last saved in the model [default]. Shows a button as in DTA, allowing user to toggle between graph and table.
• Graph: Shows graph
• Table: Shows table
• Graph_over_table: Graph above table.
• Table_over_graph: Table above graph.