Documentation update

[Cheetham, Anastasia]

I've been working on updating and upgrading our Infusion Documentation in preparation for the 1.3 release. The documentation priorities for 1.3 are primarily updates based on code changes and beginning work on improved demos
    http://wiki.fluidproject.org/display/fluid/Infusion+1.3+-+1.5+Roadmap
but I've also been trying to lay the groundwork for 1.4, 1.5 and beyond.

So here's a status update of what's new in Documentation, followed by an overview of next steps:


Update
======

1) Release-specific updates to the docs

Everyone working on Progress and InlineEdit have been great in helping to update the API documentation for those components to reflect their changes. Changes will continue as more bugs are fixed. There are several specific Bug Parade JIRAs related to this:

FLUID-3715: Update keyboard a11y plugin API docs to reflect bug fixes
FLUID-3746: Update InlineEdit docs to reflect any Keyboard a11y bug fixes
FLUID-3747: Update Progress docs to reflect any Keyboard a11y bug fixes
FLUID-3748: Update Uploader docs to reflect any Keyboard a11y bug fixes
FLUID-3749: Update Reorderer docs to reflect any Keyboard a11y bug fixes

I'm also working on updates to framework documentation related to recent fixes:

FLUID-3717: Update Framework API docs to reflect additions, bug fixes
FLUID-3773: Document changes to the ChageApplier/Data Binding


2) New wiki space specifically for documentation

   http://wiki.fluidproject.org/display/docs/Infusion+Documentation

This space is now publicly available to all (no need to be logged in!). It uses a new Confluence layout that will be helpful in customizing and versioning our documentation, as well as with navigation. I encourage you to visit, poke around, and let me know what you think. It's a work in progress, so now's the time to help shape it.

The migration of all of our documentation over to this new space will probably happen over a few releases.


3) New look-and-feel for Framework documentation

(FLUID-3717: Update Framework API docs to reflect additions, bug fixes)
I'm in the process of migrating our Framework Functions documentation to a "one-function-per-page" style, facilitating more information about each function - in particular, more examples. Please have a look and let me know what you think. Some samples:
    http://wiki.fluidproject.org/display/docs/fluid.container
    http://wiki.fluidproject.org/display/docs/fluid.each
    http://wiki.fluidproject.org/display/docs/fluid.demands


4) IoC documentation

(FLUID-3716: Document the IoC API)
I have an overview of how the new IoC system works in the new space:
    http://wiki.fluidproject.org/display/docs/IoC and sub-pages

It's still a work in progress but is hopefully a bit useful. If you're working with the IoC system, please have a look at the docs and come to me with any unanswered questions - your questions will help me to complete the documentation.



Next Steps
==========

5) IoC Invokers and Expanders (plus restructuring)

(FLUID-3716: Document the IoC API)
I hope to restructure the IoC documentation as I add more information to it. The next additions will be information about Invokers and Expanders.


6) Renderer documentation

(FLUID-3719: Update Renderer docs to reflect updates, bug fixes)
Many changes have been made to the Infusion Renderer infrastructure, and I've been working toward updating the documentation to reflect these. This might happen in the new space, or might be applied to the old space.


7) New Keyboard-A11y plug-in demo/tutorial

(FLUID-1120: Finish Keyboard A11y tutorial)
Jon has posted a mock-up of his ideas for a new Keyboard-A11y plug-in demo. I encourage everyone to have a look and provide feedback, comments, etc. We will write this code as a demo and use that as the basis for a tutorial.


8) Develop a format for component-level documentation

I need to work out a way to structure the Component documentation in the new space. The one-page-per-function layout is great for the framework functions, but how can it be applied to the public API of a component, for example? Designers, I'll be pinging you for ideas.


-- 
Anastasia Cheetham     Inclusive Design Research Centre
acheetham at ocad.ca            Inclusive Design Institute
                                        OCAD University