Taking out scenario type for now, since the wireframes suggest that it's basically a timeline component composed of activities and decisions.

I created a timeline then populated it with an activity which had two subactivities. I double click the the activity and it opens in it's own window. It opens in canvas plus view, which makes no sense for an activity with sub-activities. Canvas plus should not be a view option. It should open by default into a timeline plus view. There is no timeline plus view option.

https://docs.google.com/a/nasa.gov/file/d/0B8yT2AXIcluCVlV1bzBnSVF4ZFE/edit?usp=sharing

When viewing a scenario with multiple timelines, scrolling with the scroll-wheel is very slow.

The "This" menu item should read "File", at least for the distribution used for scenario-building. For flexibility, should consider allowing plug-ins (or even components themselves) to specify the name used for the "This" menu

During a demo of Scenario component, dragging and dropping a Collection object from the Browse view onto a Timeline was observed to cause MCT to freeze. (Possible infinite loop on the GUI thread?)

Needs investigation, including a determination of correct drag-and-drop behavior

Invoking "Save All" after making center pane changes to Activities in a Timeline View does not actually save those changes, if those Activities have been included in the Timeline by way of a Collection.

Problem is likely that getAllModifiedObjects is not implemented for collections

When a user moves or changes the duration of an Activity in a Timeline or Scenario view, any Decisions immediately following or preceding the Activity should change their apparent duration appropriately. Put differently, a Decision should always fill all available space between two activities (or between timeline start or end, if the decision is not bounded on both sides by activities)

Decisions should have a diamond shape at the center when viewed in a timeline view. Text of the decision should disappear when it gets too narrow. (Text of decision should still be available as a tool tip)

From "UI NASA MCT various" document

Create an activity with a duration of 1 day ("1 00:00" or "24:00"). Any start time is valid.

Note that in its info view, as well as on the Timeline view (if placed within a timeline), its duration shows as "00:00"

This is incorrect; formatter should produce "1 00:00"

(Possible root cause: A ">" instead of a ">=" check to see if duration is a full day)

When a user changes the duration of a sub activity by dragging its edge (within the TimelineView), it is possible for that sub-activity to have a longer duration than its parent activity (see attached image)

Where 'sub1' is a sub-activity of 'Activity'

When activities are short relative to the length of the timeline, they end up becoming very narrow & look somewhat strange. Hovering shows a tool tip with full name and duration, so information is accessible, but appearance is generally less informative than desired.

Possible possible solutions to pick and choose from:

• Use some heuristic to zoom in a timeline on load so that short activities are readable
• Colorize activities by type, so even if you can't see the description some info is available
• Make activities on a timeline smaller vertically in general (this saves space and may make the short activities appear less strangely narrow)
• Include type in tool tip if set

Duration formats used for entering start/end/durations for activities is not entirely intuitive. Should either:

• Make it more flexible (accept different ways of expressing/omitting days, hours, etc)
• Add help information (tool tips?) where used explaining what formats are accepted, for the user's reference

Activities currently have a plain-text "Type" field; reusable Tags would be desirable.

Tags should be displayed as user objects in two top-level collections: "User Tags" and "Mission Tags"

Tags should additionally be settable through the info view, using a drop-down menu. Once added, they should appear underneath the drop-down in rounded rectangles with X's on them. Clicking the X removes the Tag from that activity.

See UI NASA MCT Various

Originally requested in VWoeltjen#12

Activity create wizard currently keeps whatever was previously input for start & duration. Since many real timelines occur in sequence, it would be expedient to adjust this start time based on the previous duration. (Noted by multiple developers, though not requested by users)

Clicking on an activity in a center-panel scenario or timeline view should select the activity, causing it to appear in the Inspector

Timeline views currently only display directly-nested activities - that is, activities/decisions reachable through other activity objects.

This, however, does not address the case where a bundle of related activities is desired to be identified as some specific unit (in a manner more general than as a Timeline or as sub-activities of a parent Activity). Desire here is to simply put these activities in a Collection, and subsequently drop this Collection into a timeline and have these activities appear.

Implementation concern here is the search depth / strategy for activities. Should collections within collections be searched for activities? Collections within activities? Simplest case is to look within only Collections that are directly referenced by the Timeline (in addition to directly-referenced activities, as is done now); this should probably be used as a starting point as it satisfies the obvious use case of simply bundling up related activities.

Open into its own window a timeline with multiple activities within it. Make some changes to the activities using the Timeline View drag interface.

Go to File. Note that Save All is available. Click Save All.

Make subsequent changes, again using the drag interface.

Go to File. Note that Save All is NOT enabled.

(Additionally, instead of click interface, Timeline Inspector can be used to initiate this category of changes.)

As a short-hand to the Create menu, drag-and-droppable components should appear in the left-hand Browse pane which serve as templates for common component type when editing a Scenario or Timeline. Dropping them into the view should instantiate new components of those types at appropriate places in the object hierarchy (with start times corresponding to location, where appropriate)

Note that some design is needed - should these only appear when a component which might contain them is open in its own window? Should these have their own pane to distinguish them from the normal object hierarchy?

Timeline and Scenario views should offer widgets to allow zooming in/out in terms of time scale; correspondingly, should also allow user to pan or scroll through timeline when zoomed in such that the entire timeline/scenario does not fit horizontally within the view.

In addition to Timeline view, would be desirable to have a top-to-bottom time-ordered list view of activities. This would provide extra space for notes and reflect better the "step by step" nature of certain timelines.

Certain design issues need to be addressed here. What information is included in the view? How should concurrent activities be displayed? (Use case seems oriented toward timelines without concurrency, but since overlapping activities are allowed in various situations the software will need to do something here.)

Give the user the option of saving their timeline with their current zoom settings and pan-location.

Currently, a user can resize the timeline with the pan-and-zoom bar, but MCT does not save the view.

If a sub-activity start time is earlier than the start time of the parent activity then the partent activity start time needs to reflect that. The same if a sub-activity end time is later than the parent activity. Total duration of the activity as shown at the parent level should be from the start of the earliest activity or sub-activity and end at the latest activity or sub-activity.

Creating a Cycle in a Timeline and then attempting to resize any member of the cycle results with a 'Fatal Startup Error null' dialog box. This bug completely crashes MCT

Steps to Reproduce:

1. Create an 'Activity Timeline' T
2. Create an Activity A_parent in T
3. Create an Activity in A_parent (lets call it A_child)
4. Drag A_parent into A_child (now we have a cycle)
5. In the timeline view for T, try to resize A_child or A_parent: each will result with a NULL exception, crashing MCT

Image showing an example cycle in the Activity Timeline

I created an activity with two sub activities, all with the same duration. The sub-activities overlap. See the screen grab.

https://docs.google.com/a/nasa.gov/file/d/0B8yT2AXIcluCYjhicGU4Y3h3YjQ/edit?usp=sharing

When adjusting the start or end of the top-level activity in a Timeline View, the Activity does not visibly change width. This is because the Timeline shrinks to fit the size of all Activities it contains.

Solution will require first that Activity objects can start at a time offset from the beginning of a Timeline, and that Timelines themselves have durations (to allow for space after the last Activity if user desires)

An activity component was previously created in another session in Eclipse where the scenario plugin was loaded. When launching MCT in the command line, the activity component becomes a "broken component".

In some cases it is desirable to mark a specific point in time on a timeline with some information - for instance, "Goal Satisfied." In some sense this could be considered a zero-duration activity, although "event" might be a more natural term (however, "event" is also a bit of an overloaded term in this context so maybe better naming is needed)

Graph View (showing data summations) should be separated out of Timeline into its own view, allowing it to be reused for higher-level components (scenario) as well as embedded into Scenario/Timeline views

Open a Timeline View which contains Activities with Sub-Activities

Move those Sub-Activities around. Note that constraints are enforced (sub-activities cannot overlap, etc). Then Save All.

Move Sub-Activities around yet again. Suddenly, constraints are not being enforced.

A timeline component type shall serve as the container of activities and decisions. The timeline view shall render each activities (including their sub-activities) and provide a summary of power and communication bandwidth consumption at the bottom of the timeline.

Sub-activities (and decisions) can be created, modified in an Info View, or drag-dropped into Activities without triggering the parent activity's constraint-handling mechanism. That is, using these approaches it is possible to create sub-activities which overlap, decisions with empty space at either end, activities with bounds outside of their parent, et cetera.

Ideally, constraints should be enforced in these situations. However, due to the flexible nature of MCT's object graph, it is possible to create situations where constraint enforcement is unsolvable (i.e. no solution exists). Particularly this can occur when one activity is a sub-activity to different parent activities (which may have contradictory rules for their children.)

It should also be considered that this may be confusing to the user, as (if this were implemented for solvable cases) situations can be created where unseen parent activities impose constraints on sub-activities, potentially resulting in some "spooky action at a distance" scenarios (where sub-activities are pushed or stopped for reasons that are not visible to the user, due to the presence of sibling sub-activities in other timelines)

Activities and Decisions should allow the user to add some plain text notes / descriptions to the object. Ideally this should be shown in the object's info view. May require some modifications to platform to allow multi-line text editing in Info View.

(From MOS Sys Eng Tagup 8/5/2013)

(Identified during 8/5/2013 meetings)

Scenario distribution should eventually include plug-in which integrates data prepared or served by xGDS.

Specifically, viewing exploration plans in MCT is desirable, especially in a manner compatible with Scenario views. Viewing of other features such as Notes and Maps is also likely desirable.

Note that further exploration is needed, including identification of use cases.

Activity components should express their data properties via a capability. Timelines should support a similar capability which acts as the sum of the capabilities of its children (similar to Scenario). This supports general-purpose Graph view being applied to any of the above.

Ideally, capability's interface should support continuous functions, but step-wise functions are fine for the time being

A Scenario Object serves as a container for multiple timelines.

A Scenario View presents multiple collapsible timelines with the same reference time.

The "power/comm" overlay feature should span all visible timelines.

A graph presenting power/comm (etc) summations from all Timelines should be present at the bottom of the Scenario, as well.

In the Timeline View, a user can resize an Activity to the point it disappears. Indeed, when switching to a different view and then coming back to the timeline view, the activity is back, but seeing activities disappear from timelines is quite disconcerting to the user.

While not a bug, I feel this issue is a feature request: to not allow shrink-to-zero activities.

Steps to reproduce:
In a timeline view, grab the edge of an activity and shrink it: eventually it will disappear.

In addition to Start and End time, Activity Info view should have a field for Duration. This field should be synchronized to any changes in the Start and End fields.

(From 8/5/2013 meetings)

Currently Activities are modeled as having some constant cost that goes away at the end of the activity. Realistically, costs (such as power and data usage) exhibit complexities which are not captured in this model, which are important to assessing timelines.

Notes from 8/5/2013:

• Constant costs are fine for assessing high-level feasibility (so OK in near-term)
• More realistically, costs such as power occur all at the start of an activity, or similar. General case should allow cost to be expressed as a function of time.
• Costs may also need to accumulate, and in some cases be negative (ie "benefits"). For instance, battery charging as opposed to power usage

Both design and implementation is needed to support this enhancement.

I create an activity timeline in the user environment. I open that timeline into it's own window. It is empty. I invoke Objects --> Create --> Activity. I name and create the activity. It shows up in the directory but not in the timeline. I'm in timeline plus view. I change the view to info plus then back to timeline plus and now I can see the activity in the timeline. This behavior is design for the telemetry canvas and it makes sense in that context. For the timeline plus view this behavior does not make sense - the timeline should show the contained activities by default.

Users should be able to designate the "type" of specific activities. This is to support future Scenario features such as charts and graphs, to allow easy assessment of the relative costs spent on activities by type.

Implement user object containment as specified here:

https://docs.google.com/a/nasa.gov/spreadsheet/ccc?key=0AsyT2AXIcluCdDQ1OHdySDVsWUc0OC1udGxpNWtweGc#gid=0

This relates back to nasa/mct#145

Add icons for component types introduced n scenario plug-in. These icons can follow MCT's current icon rules for now (quick fix); the dynamic behavior in nasa/mct#145 and corresponding UI specification can be left for later

Create an Activity object using the Create menu

In the dialog, enter garbage (text that is not a date - "Quack," for example) for the start time and/or duration.

Observe that the Create button is still Enabled

Click create. The new activity appears. In the info view, it can be observed that default values (00:00 start, 00:30 duration) have been applied.

Note that this happens even if one of the values entered in the create dialog is valid. (For instance, start of "1 20:00" and duration of "Quack" becomes an activity with 00:00 start, 00:30 duration)

Expected behavior: "Create" button should not be available unless start and durations are both valid (can be parsed to dates, are non-negative, and duration non-zero.)

Observed hackathon 8/16/2013

Attempting to open an older timeline ("Integrated Timeline (partial)" in the hackathon db) causes a NPE to be thrown and a grey screen to be displayed.

Cursory investigation suggests that the "type" field of the activity is null (as these activities were created before the addition of a "type" field), but this is not checked by ActivityView before drawing. Easiest fix is to modify getType() in the activity component such that it never returns null.

java.lang.NullPointerException
at gov.nasa.arc.mct.scenario.view.ActivityView.paintComponent(ActivityView.java:104)
at javax.swing.JComponent.paint(JComponent.java:1054)
at javax.swing.JComponent.paintChildren(JComponent.java:887)
at javax.swing.JComponent.paint(JComponent.java:1063)
at javax.swing.JComponent.paintChildren(JComponent.java:887)
at javax.swing.JComponent.paint(JComponent.java:1063)
at javax.swing.JComponent.paintChildren(JComponent.java:887)
at javax.swing.JComponent.paint(JComponent.java:1063)
at javax.swing.JComponent.paintChildren(JComponent.java:887)
at javax.swing.JComponent.paint(JComponent.java:1063)
at javax.swing.JComponent.paintChildren(JComponent.java:887)
at javax.swing.JComponent.paint(JComponent.java:1063)
at javax.swing.JComponent.paintChildren(JComponent.java:887)
at javax.swing.JComponent.paint(JComponent.java:1063)
at javax.swing.JComponent.paintChildren(JComponent.java:887)
at javax.swing.JComponent.paint(JComponent.java:1063)
at javax.swing.JComponent.paintChildren(JComponent.java:887)
at javax.swing.JComponent.paint(JComponent.java:1063)
at javax.swing.JViewport.paint(JViewport.java:731)
at javax.swing.JComponent.paintChildren(JComponent.java:887)
at javax.swing.JComponent.paint(JComponent.java:1063)
at javax.swing.JComponent.paintChildren(JComponent.java:887)
at javax.swing.JComponent.paint(JComponent.java:1063)
at javax.swing.JComponent.paintChildren(JComponent.java:887)
at javax.swing.JComponent.paint(JComponent.java:1063)
at javax.swing.JComponent.paintChildren(JComponent.java:887)
at javax.swing.JSplitPane.paintChildren(JSplitPane.java:1047)
at javax.swing.JComponent.paint(JComponent.java:1063)
at javax.swing.JComponent.paintChildren(JComponent.java:887)
at javax.swing.JSplitPane.paintChildren(JSplitPane.java:1047)
at javax.swing.JComponent.paint(JComponent.java:1063)
at javax.swing.JComponent.paintChildren(JComponent.java:887)
at javax.swing.JComponent.paint(JComponent.java:1063)
at javax.swing.JComponent.paintChildren(JComponent.java:887)
at javax.swing.JComponent.paint(JComponent.java:1063)
at javax.swing.JComponent.paintChildren(JComponent.java:887)
at javax.swing.JComponent.paint(JComponent.java:1063)
at javax.swing.JComponent.paintChildren(JComponent.java:887)
at javax.swing.JComponent.paint(JComponent.java:1063)
at javax.swing.JLayeredPane.paint(JLayeredPane.java:585)
at javax.swing.JComponent.paintChildren(JComponent.java:887)
at javax.swing.JComponent.paintToOffscreen(JComponent.java:5228)
at javax.swing.RepaintManager$PaintManager.paintDoubleBuffered(RepaintManager.java:1508)
at javax.swing.RepaintManager$PaintManager.paint(RepaintManager.java:1439)
at javax.swing.RepaintManager.paint(RepaintManager.java:1236)
at javax.swing.JComponent.paint(JComponent.java:1040)
at java.awt.GraphicsCallback$PaintCallback.run(GraphicsCallback.java:39)
at sun.awt.SunGraphicsCallback.runOneComponent(SunGraphicsCallback.java:78)
at sun.awt.SunGraphicsCallback.runComponents(SunGraphicsCallback.java:115)
at java.awt.Container.paint(Container.java:1967)
at java.awt.Window.paint(Window.java:3877)
at javax.swing.RepaintManager$3.run(RepaintManager.java:807)
at javax.swing.RepaintManager$3.run(RepaintManager.java:784)
at java.security.AccessController.doPrivileged(Native Method)
at java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDomain.java:76)
at javax.swing.RepaintManager.paintDirtyRegions(RepaintManager.java:784)
at javax.swing.RepaintManager.paintDirtyRegions(RepaintManager.java:757)
at javax.swing.RepaintManager.prePaintDirtyRegions(RepaintManager.java:706)
at javax.swing.RepaintManager.access$1000(RepaintManager.java:62)
at javax.swing.RepaintManager$ProcessingRunnable.run(RepaintManager.java:1647)
at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:251)
at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:733)
at java.awt.EventQueue.access$200(EventQueue.java:103)
at java.awt.EventQueue$3.run(EventQueue.java:694)
at java.awt.EventQueue$3.run(EventQueue.java:692)
at java.security.AccessController.doPrivileged(Native Method)
at java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDomain.java:76)
at java.awt.EventQueue.dispatchEvent(EventQueue.java:703)
at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:242)
at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:161)
at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:150)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:146)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:138)
at java.awt.EventDispatchThread.run(EventDispatchThread.java:91)

Timeline view needs to be decomposed into smaller views, down to individual View objects for each activity (current implementation represents these primarily in drawing code, not within the Swing object hierarchy.) This is necessary to support other features which expect full-fledged views, such as #8

In Timeline View, activities are allowed to overlap temporally. Normally, these will be presented on separate horizontal rows when the Timeline View is first instantiated. However, if two activities are on the same row, they can subsequently be dragged to overlap using the Timeline View's mouse interface.

It's unclear what precisely should happen in this situation (moving the activities to different rows during the gesture may be visually jarring/distracting/confusing for the user). One possibility is to allow them to overlap while the gesture is still ongoing, but to reorganize layout when the gesture completes (mouse up)

When creating an activity within an activity using the Objects --> Create Menu the selection should read Objects --> Create --> Sub-activity