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