Summary of Wednesday's UIOptions/PGA architecture/roadmap community meeting

[Antranig Basman]

The early part of the meeting presented the roadmap and surrounding 
community and design structure for the group of interfaces that will be 
managed by the core UIOptions code as part of the overall PGA ecosystem 
- this includes deployments such as UIOptions as part of work for FLOE 
as well as tools such as the PCP and PMT for the GPII. I've uploaded a 
whiteboard snapshot which sketches the relationship between various 
tools at the different levels of the "user sophistication/intrusiveness" 
spectrum:

http://wiki.fluidproject.org/download/attachments/34575412/PGA+Tool+Ecosystem+Whiteboard.jpg

The level of technical complexity (which could be inversely correlated 
with "invitingness" to a user who needs an interface with minimal 
intrusion into their workflow) scales towards the right of the diagram, 
as illustrated by the buckets with increasing numbers of chili peppers.

At the left is the "Discovery Tool", positioned as the overall entry 
point to the ecosystem, with the maximum level of "invitingness" and 
ability to get the user as far as possible into the world of desirable 
customisations with the absolute minimum of interaction. Scaling towards 
the right we have the personal control panel (PCP) and then the 
preferences management tool (PMT). We discussed the relationship between 
these UIs and our plans to deliver them on the same core skeleton of UI 
and implementation architecture - the Fluid Infusion UIOptions tool. The 
current refactoring work underway by Cindy, Justin, Yura and others in 
Infusion's trunk is directly aimed at achieving the configuration 
flexibility required to adapt to these and numerous other use cases.

An overall explanation of the PGA architecture and ecosystem is at 
http://wiki.fluidproject.org/display/fluid/Preferences+for+Global+Access+Architecture

with individual pages for two of the discussed profiles (PCP and PMT) at 
the GPII at

http://wiki.gpii.net/index.php/Personal_Control_Panel and
http://wiki.gpii.net/index.php/Profile_Management

The discussion then turned to some technical aspects related to recent 
discussion on overall UIO API architecture - a page under design by 
Anastasia at 
http://wiki.fluidproject.org/display/fluid/Designing+a+new+UIO+API

We clarified some of my recent feedback relating to "nth parties" - in 
such a large and open ecosystem, we need to think carefully about the 
roles and the appearance of the ecosystem to each successive level of 
integrators and their users. This original feedback was at 
http://lists.idrc.ocad.ca/pipermail/fluid-work/2013-May/009059.html

In general, traditional software engineering techniques fall down 
through a complete lack of attention to the requirements of such an 
ecosystem - with usually only the requirements of what could be called 
"1st parties" (primary developers) and "2nd parties" (immediate users or 
immediate integrators) in mind. The main failure of the techniques 
comprised under the label "Object Orientation" could be considered the 
dreadful experience, through neglect, that they offer to 4th parties and 
above - and other techniques, past and current, are little better.

The exact numbering applied to the various groups into the ecosystem 
isn't so crucial, as long as it is appreciated that this forms an 
essentially "open graph" comprised of both people typically conceived of 
as "users" and "developers". An example of a "3rd party" could be 
considered a "primary integrator" as part of the GPII project who is 
using the UIO architecture to produce a specific (yet still open-ended 
tool) such as the PCP or PMT. A "4th or 5th party" could be considered a 
secondary or tertiary integrator in the GPII community such as a vendor 
producing a bundling of the PCP for use in a particular environment, or 
a user of such a tool. It's worth emphasising that we see the world of 
integrators blending seamlessly into the worlds of users as the "party 
numbers" increase, since many configurations of UIO have the function of 
allowing users to effectively author their own configuration management 
tools (such as with the PMT).

Justin asked the important question of whether we expect to see "the 
same" API across all party numbers. This is unachievable given the very 
different natures of these communities, but our overall aim is to enable 
"stable landmarks" so that there is no one "party barrier" in the 
community where the difficulty of working with the architecture sharply 
increases. This common abstraction is largely positioned as the use of 
GRADE NAMES and the JSON documents which are associated with them - 
where there are places where these are not the primary abstraction to 
the relevant party (for example - PMT users will work with an "open 
schema" defined by the GPII registry which defines preferences and their 
activity in terms of one or more ontologies - and - end users will work 
in terms of a UI in which none of these abstractions are directly 
visible) there will nonetheless be a straightforward and stable 
translation of the particular "party language" in terms of its 
embodiment in terms of grade names and their structure.

We returned to the UIO API page and talked over some ways in which the 
naming of grades was a crucial part of enabling this stability, and 
discussed some conventions for organising them - for example the de 
facto convention embodied in such choices as 
"fluid.uiOptions.enactors.textSizer". Where we arrive at conventions of 
this kind, we should highlight this advice in our "API" guidelines (in 
fact, increasingly, there will fail to be a conventional "API" to the 
UIO ecosystem consisting of function calls, but in fact primarily only 
this structure of named grades and their related configuration) - we 
expect further organising principles of this kind to emerge from the 
GPII Registry work.

Finally we turned to a specific naming issue of this kind, relating to 
the name given to the configuration of UIOptions familiarly named "out 
of the box" - the tool which can be used by default through a checkout 
of the image of Fluid Infusion. A vote on the choices for this name is 
currently coming to a close in fluid-work.

Cheers,
Antranig.