Summary of UIOptions Architecture meeting this afternoon

[Antranig Basman]

I'm cross-posting this summary to the GPII architecture list, since the work underway on improving the 
UIOptions architecture will be of direct relevance to integrators working on the PCP/PMT once it is 
delivered. Making the UIOptions component easier for integrators and other providers of preferences settings 
is one of the core aims of this work..

Present were Justin, Michelle, Yura, Cindy and Antranig of the Fluid team at OCAD.

Currently there are a few branches of work underway, targetted at different sides of the architecture. The 
last roadmap we had written down is at http://wiki.fluidproject.org/display/fluid/FLOE+2013+Q1+Roadmap but 
has not been updated since January.

The most straightforward branch is Cindy's. This is at https://github.com/cindyli/infusion/commit/FLUID-4908 
and is aimed at the "enaction" side of the architecture - that is, the part which honours the user's 
preferences by applying them to the environment (in this case, the browser). To recap our early 
architectural plans, these view the task of handling preferences as consisting of three "axes" or "ants". I 
don't see that this treatment has yet reached the wiki, but one of our recent UIOptions presentations can be 
seen in PPT here:

http://wiki.fluidproject.org/download/attachments/1707985/User+Interface+Options+Cloud4all.ppt?version=1&modificationDate=1349456047832

On slide 23 and 24, these are represented as sides of a cube in different colours, 1+2 representing 
"presentation and persistence" and side 3 representing "adaptation". These have informally been named "ants" 
following an architecture meeting in 2011. During today's meeting we refreshed our memory on whether it was 
the entirety of a cube handling a single preference that had been called an "ant" or just one side of the 
cube. We decided to standardise on referring to just one cube side as an "ant".

Cindy's branch deals with the red sides (ants) previously held within a component named UIEnhancer. She has 
refactored the code dealing with this away from a hard-coded model held within the UIEnhancer to a 
collection of free functions and simple, self-contained components using the new Infusion framework features 
delivered last month (the "ginger world" - docs forthcoming).

We have a few similar branches underway - Yura has one dealing with persistence (green side) at 
https://github.com/yzen/infusion/tree/FLUID-4686 and Justin is dealing with presentation (yellow side) at 
https://github.com/jobara/infusion/tree/FLUID-4927 .

I emphasised that an important principle in this large-scale refactoring work is to ensure that each branch 
is as far as possible issued against a complete configuration of UIOptions which is kept working. Any other 
working model greatly increases the risks of failed integration when collecting together separated branch 
work. However, it is possible to make limited compromises by allowing some "degraded functionality" in an 
integration branch, as long as the core component is kept functioning - that is, it is possible for the user 
to run it without major issues on at least one platform.

*A*: Given this aim, we agreed with Cindy a short-term work package that consists of re-integrating her 
"action ants" into a thin shell component broadly replicating the architectural role and behaviour of the 
old "UIEnhancer" component, whilst continuing to make limited use of new framework features to simplify the 
implementation. The new "UIEnhancer.js" would be a mostly empty file which defined an abstract "empty grade" 
defining no ants by default, and a "concrete grade" replicating the functionality of the old UIEnhancer by 
reintegrating the new ants. It would be ok if this implementation were API-deficient (that is, led to extra 
work by the integrator) with respect to the old one, as long as it led to a working component.

Given we require to deliver a working demonstration of the system showing some new features by April 2, we 
decided that a "hard core" of deliverable features consists of the new panels for which high fidelity 
wireframes are at 
http://wiki.fluidproject.org/display/fluid/User+Interface+Options+design+high+fidelity%2C+C.1 - we would 
then opportunistically deliver some new features/panels/ants chosen from the set on the Q1 roadmap page 
depending on the remaining time available. It seems most likely that these might consist of some form of UI 
simplification demonstration, some text-to-speech (simple "self-voicing") or both.

*B*: The other teams (yellow and green) face bigger integration issues in the short-term, since the new 
overall architecture for UIO (which I expect to start working on next week) is not yet ready. A good 
short-term goal seems to be parallel to Cindy's - to work on producing an "empty UIOptions" which has no 
ants, and bundles all the panel components in separate files - but with a largely unchanged architecture. It 
would be ok, as with Cindy's work, to sacrifice some API gracefulness in the short term as long as the 
component was kept working. For the demo we would then deliver the core "shell architecture files" plus two 
"integration files" consisting of panel definitions for the old and new UI panels respectively.

So far no HTML matching the high fidelity designs has been produced, but this seems to be one of the highest 
priorities. We plan to talk with the design team on Monday about what schedule we could deal with this for, 
but it seems that a further useful and immediate work package would be for the yellow/green team (Yura and 
Justin) to work on creating some "terrible markup" which at least provides the skeleton for controls and 
panels in the new designs, so that they could get working on writing panel components in the right file and 
in the right arrangements as soon as possible. The good markup when it arrives could be slotted in 
relatively easily (hopefully some time around the end of next week).

*C*: We will for the time being abandon the "ad hoc" options transformation system delivered with the old 
UIOptions ("mapOptions" system) and I will deliver, expectedly next week, a streamlined system that delivers 
equivalent capabilities using the new framework features ("IoCSS" from 
http://issues.fluidproject.org/browse/FLUID-4873). Until then the teams will work on the basis that any user 
configuration targetted at individual ants will be delivered via "pointy configuration", guessing the exact 
component name and path of the target ant deep in the hierarchy.

Other important work packages were agreed to be pushed off beyond the April 2 milestone:

*D*: Support for automatically selecting and integrating panels for UIOptions/UIEnhancer using a model 
transformations-like approach driven from a declarative schema (JIRA forthcoming)
*E*: Improving the template loading and rendering system for the overall component (requires new framework 
support)

We'll have further meetings on Monday including Colin and the design team to further refine and clarify 
these plans, but they should cover enough work to fill up the next few days. A further crucial part of this 
work is to draw up *detailed* JIRAs (preferably showing actual code sketches and API usage sketches) 
covering this work, together with a schedule and work dependency map, as well as to update our roadmap wiki 
pages.

More later,

Antranig