= WebLearn/CopyUI/Proposal =

This summarizes what was proposed for a way forward after discussing the salient issues on 3^rd^ November 2006.

== Additions / Changes ==

 * enable "CopyUI" for copying ''all'' resources.
 * enable "CopyUI" for ''bring'' too.
  * ''bring'' would be a ''push'', i.e. select the ''source'' first and then browse to the ''destination'' whilst in ''move / bring'' mode.
 * discard pop-up window (this is achievable in other ways, i.e. right-click + 'Open in new window').
 * discard the notion of a ''best practice area''.
 * discard the distinction of ''peer-to-peer'' and ''adopter'' copying (effectively just have the latter).

== Lower priority / Not to be tackled ==

 * any of the refactoring suggestions concerning moving of copy functionality to types such as `Resource` and `BuildingSession`.

== Pros ==
 * should make copying easier, especially for novices, by creating a more intuitive workflow:
  * go to source first, capture this as the implicit copy ''source'' by invoking copy and then browse to the intended ''destination''. All valid target destinations are annotated with a radio button.
  * copying will essentially be graphical / visual as opposed to textual, i.e. '''not''' needing to copy the source URL to the system clipboard first.
  * certain errors captured immediately, e.g. recursive copy `> 100` resources, rather than "on copy".
  * the number of types of other errors will potentially reduced, e.g. copying to a destination that's inside the source, as the interface will not offer this as a possibility in the first place.

== Cons ==
 * involves reversing the current workflow.
 * user documentation and training materials will need to be altered to reflect the changes.
 * users may get confused if they inadvertently enter copy mode, i.e. slightly different view and need to know to press 'Cancel' to exit.
 * further diverging codebases between !WebLearn and bodington and its knock-on effects with other bodington community partners. In a worst-case scenario, others may not wish this code to be added to the common repository (meaning Oxford has to maintain the code just locally). Even in a best-case scenario (where the additions are generally agreed to be "good") this creates further work with regard to merging with localized partner codebases.