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
_______________________________________________________
fluid-work mailing list - [email protected]
To unsubscribe, change settings or access archives,
see http://lists.idrc.ocad.ca/mailman/listinfo/fluid-work
