commercial+developer+comments

=Some suggestions from commercial developers and ex-Toolbox developers=
 * 1) Develop a content management approach to Toolbox development.
 * 2) Create a presentation layer and back end, publish content through presentation layer.
 * 3) This would require content to be edited out of the context of the screen design
 * 4) **BENEFIT:** changes to SCORM could be applied in the presentation layer and be context independent..
 * 5) **BENEFIT:** Make ID and SME independent of screen design. However, there would need to be a development of preview templates, enabling users to see how content will look prior to publication.
 * 6) **BENEFIT:** Media assets can be version controlled simplifying maintenance.
 * 7) Develop a database model for maintenance: input content into a database, this could be done remotely, however, synch and version control would have to be considered. Creating a remote model of development would be more expensive. + remote access version +Problems include synch and version control... More expensive.
 * 8) A web based model however, would require an online presence for development - what would be the drawbacks?
 * 9) Implications- developers in new model build templates, each screen element has corresponding database field..... Developers 'hooking' content to a presentation element.
 * 10) Build templates for interaction template types. html or flash. Body of work would include identifying best practice templates, and cutting edge templates which lend themselves to customisation. This would require external xml. Developers would work in patterns rather than developing individual interactions. Possible **BENEFITS:** Change the focus from individual effort to the development of a body of core interactions (value/roi ++). THis library could be reviewed annually with new interactions being added to the body each year using Toolbox funding. Over time a creative library would be established. Over time, templates become more sophisticated. **REQUIRED** body of work in template sequencing.
 * 11) To avoid suggestions of creating 'sameness' each year there would be one to two templates allowing embedding of individual work which would then have SCORM applied to it.
 * 12) Annually a reference group with a high representation of developers and IDs could Identify gaps and commission new ones.
 * 13) Avoid such a reliance on Flash for content, and perhaps explore tools such as AJAX.
 * 14) Separate content from presentation layer using xslt and xml.

What would be required?
Development of a platform independent easily updateable CMS. api for developers to communicate with databse A document database. Publication skins to allow outputs such as CD-ROM, iphone, SCORM etc. **BENEFITS**: As technology and output devices change, new skins can be developed sourcing output from the core Toolbox model. Simplified bug fixing - fix it and version control managed by Equella - roll backs possible. Tracks edits and changes -
 * Definintion of 'hooks' which name and describe fields.
 * -Ability for developers to be able to develop new fields for the databse

Web 2.0 Content requirements
Deveop a pilot for the new model in the form of learning objects. Embed - links to files on intranet (sharepoint??) build embed blocks - :embed code If Web 2.0 content was used, the web based nature of Web 2.0 content would require a core content/message to be displayed in the offline state.

=Tracking requirements= Is it important to register 'state' How do you reflect 'escalation' - i.e. you must not fail, you need to fid out this answer before moving on. Avoid feedback loops.