milestones

Note: This document discusses potential milestones for releases 0.2 and beyond of PCEnv. Unless otherwise stated, these milestones are potential milestones (i.e. items which could be considered for the upcoming releases), and not items which will definitely be in the release.

= Math editing = Status: Completed

A user should be able to edit mathematical equations in PCEnv, using the linear MathML editing mode.

== Benefits ==

Allows CellML models to be created ab initio in PCEnv, without having to edit any XML.

== Costs ==

Another week of development time, as well as more time to get feedback from users on the feature.

= Ability to pan and zoom the graph view with the mouse = Status: Completed

== Benefits ==

Allows the user to examine their data more easily.

== Costs ==

More actions for a user to learn (especially if we remove the existing context-menu zoom facilities).
Need to consider keyboard users as well.
Another week of development time, as well as more time to get feedback from users on the feature.

= Option to unfreeze models (and throw away the run) = Status: Completed

A user should be able to tweak an integration parameter without going through all the complexity of cloning the model. In order to achieve this, a third option, to discard data and unfreeze the model could be added to the 'model frozen' popup dialog.

== Benefits ==

Potentially more efficient user experience.

== Costs ==

Up to a day of development time, plus some time required to verify the fix, and to check that the fix didn't create any additional problems.

= Move New trace button elsewhere = Status: Completed

== Benefits ==

More space on the screen can be used for graphs.

== Costs ==

Loss of intuitiveness on the user interface. Peter notes that it is not clear what 'New' does anyway, although if we changed it to 'New trace' it would be much clearer than making an iconed button under colour on the tree column header for colour. A right click context menu might not be as bad, but it would still be harder for users to discover.
Up to a day of development time, plus some time required for user interface feedback, and to check that the fix didn't create any additional problems.

= Changing graph background colour / grid lines = Status: Pending work by Andre on publication graph metadata. Could be a 0.2 milestone if this is available in time.

== Benefits ==

Ability to edit a wider range of presentation metadata.

== Costs ==

Would take up screen space (unless it is in a context menu, in which case it would be hard to find).
Several days development time (including time to get the publication graph metadata => graph control, and vice versa). These times does not include the specification work that Andre has said he will do.

= Changing line type and thickness = Status: Pending work by Andre on publication graph metadata. Could be a 0.2 milestone if this is available in time.

== Benefits ==

Ability to edit a wider range of presentation metadata.

== Costs ==

Several days development time (including time to get the publication graph metadata => graph control, and vice versa). These times does not include the specification work that Andre has said he will do.

= Arbitrary number of graphs in tabs = Status: Discuss whether it should be in 0.2.

== Benefits ==

Could have more graphs open at the same time.

== Costs ==

Performance: Having many canvases around at the same time seems to make XUL reflows slower. The impact of this needs to be measured, and we need to determine if it is still an issue when using tabs.
Usability: A drop down list on the keys could be more usable, as it allows you to define sets of graphs and then compare any pair (while inter-tab comparisons would be impossible). Need to discuss this further.
Several days development time, plus time for any issues (usability of otherwise) caused by fixing this to be resolved.

= Finer granularity of UI updates = Status: Discuss

== Benefits ==

More similar to existing software.

== Costs ==

Performance hit, batching data means that we can complete the integration faster, and having smaller batches will harm performance (currently we send on the next point if it has been more than 1 second, and we also limit the total number of points batched to meet memory use / packet size considerations).
Insignificant development time, with relatively low risk of breakage (but we still need to allow time to test any implications this may have).

= Prevent user from resizing the key relative to the graphs = Status: Discuss

Please don't do this. Resizing all the window panes can be a little annoying at times but I definitely wouldn't want to lose the functionality of being able to resize the key. If this was controlled by the software and not able to be altered it could get frustrating - James Lawson

== Benefits ==

User is presented with less options so is less likely to become confused. The software would automatically resize the key for the user.

== Costs ==

The user has less flexibility, which would stop them from being able to, for example, make the graph take up the whole screen and hide the key, or hide the graph and work on the key. There could also be more items in the key then fit on the screen, and the user would have no control over how much of the screen would be used for each.
About half a day of development time. We would have to leave it in for a while before making a release (with people testing snapshots during this time) to ensure nothing else breaks as a result of this.

= Save more data into simulation metadata = Status: Complete

== Benefits ==

Don't lose data like algorithm and point density.
Can use data set in PCEnv in other tools which also understand the simulation metadata.

== Costs ==

We need to agree on simulation metadata which can store all this information. The algorithm has proven particularly difficult to specify correctly in the past.
A day or two of development time, plus stabilisation time.

= Save CellML models = Status: Complete

== Benefits ==

Means that edited models can be saved, allowing them to be put into the repository.

== Costs ==

A day or two of development time, plus stabilisation time.

= Save the complete state of PCEnv = Status: Discuss (proposed for 0.2)

== Benefits ==

Means that the complete list of open models can be saved. This could occur automatically when the program exited.

== Costs ==

Need a way of closing all models or similar as well, otherwise it could be difficult to work with.
A week of development time, plus stabilisation time.