*Attendees*
Tom Barton, U. Chicago (chair)
Shelley Henderson, USC
Brenden Bellina, USC
Blair Christensen, U. Chicago
Gary Brown, U. Bristol
Mark McLaren. U. Bristol
Andy Cohen, Stanford U.
Lynn McRae, Stanford U.
Jennifer Vine, Stanford U.
Minh Nguyen, Stanford U.
Scott Cantor, Ohio State U.
Chad La Joie, Georgetown U.
Walter Hoehn, U. Memphis
Steven Carmody, Brown U.
Peter DiCamillo, Brown U.
Ann West, EDUCAUSE/Internet2
Jessica Bibbee, Internet2 (scribe)

*Action Items*
[AI] {Minh} will email the <grouper-dev> list with a list of tiles that share similarities found in both Grouper and Signet.

[AI] {Gary} will circulate a description of a proposed generic tile controller.

[AI] {Gary} will draft conventions for directory layout of and build procedures for I2MI source code packages.

[AI] {Tom} will organize a separate mailing list to handle all the I2MI-UI discussions; items should be temporarily cross-posted with the <grouper-dev> mailing list to capture the appropriate audience.

*Discussion*
As Internet2 middleware software is being developed, particular attention is paid to the similarities found amongst individual strategies or elements that might be used for common purposes. This
call was designated in order to cultivate recent ideas regarding the potential uses of adapterClasses, presentationClasses, tag libraries, and other widgetry within User Interface methodology. It is the intent to explore how to integrate UIs with external information sources for
multiple types of "subjects." Also discussed was the support of site-specific customization of display elements. This discussion reflects a continuation of efforts in support of emails sent to the
signet mailing list by {Lynn} and {Gary}. A document was recently posted to the signet mailing list about adapterClasses and presentationClasses,
<https://mail.internet2.edu/wws/arc/signet/2005-01/msg00000.html>.
For ore information on the Grouper UI architecture, see <http://www.bris.ac.uk/ips-rojects/portal/groupsmanager/projectdoc/architecture/ui_architecture>.

We should give thought to proposed techniques and technology for the integration of UIs with various external information classes, and how might we implement these within a system. How do we go about assembling these technologies with the UI, as we consider Grouper and Signet? One item brewing in the initial presentation class is looking at how to build on the technique of the adapter class – do a render through a generic servlet, look at tiles –find a better implementation. Basically, the switch has been made from using adaptation classes to using tiles to create dynamic widgets; in the future, we need to look at using Java space to do so. The idea of
using HTML in Java classes might offer flexibility initially, but might create challenges in the long-term, when trying to do something specific. The ideal route would be to use Java Server Faces. This approach will leave the door open to a wider range of people using the UI. Java Server Faces do not provide a mechanism lay out a page – instead, you have an IDE where you drag and drop your widget; you copy within the IDE for more efficient development of page design.  It
becomes more like a Java beans approach.

There might be the flexibility for us to create our own tile, but it is dependent on the type of that context and how you would render that object – you can define the code, or overwrite it as a sort of default implementation. Another possibility is to have a controller generate the HTML, and this offers flexibility to have a view of viewtypes – a JSF or tile. There is an absence of present technology that allows a site override function. We would need to be able to operate with a
default behavior that can be overridden by a site. A challenge is presented, in that assumptions must be made, as a site may not know ahead of time what they will want to override. Is this generic controller something that a site would create independently, such that Grouper would utilize it, as would Signet, for example? Yes, it would be a sort of default system in how you would look for a specific key based on a key – look for it, then come back to the default key before
trying the next, and ultimately ending up with a default key. This is a low-cost, straightforward approach. We should work towards an agreement, regarding the naming of algorithms that we use to find a system type name.

What is this set of tiles, the override-able presentations or operations, that are peculiar to the projects, and what problems do they pose? Those built-in components within any subsystem like the UI; Picking Scope has a tree, browse, browser, picker – someone might want to override with something preferred in a given tile, which is site specific. An example might be some default conditions, or the search result. Another question leads to differentiating between the
descriptions of the architecture as a whole with the known pieces - for example, the left-hand navigation bar is a part of the application. One site might have a single-choice or multiple-choice
behavior, while another site may wish to override such behaviors. There is also a need to limit or define something new – perhaps a whole new widget; declare in the metadata, realtime.

Grouper is similar here; for example, it is difficult to know what the custom group attributes are ahead of time. The entity, in this case, is a group field object, which would have a specific name that might not be known ahead of time. However, a key could include the name, and is put into a tile of the JSP. If nothing is entered, a default will be used. You could then chose to build that key up, based on known groups – for example, groupfield, groupname, or whatever it is that you are trying to render. This provides a way of working with virtually any group field, as it is the name of the field that determines which templates get pulled in. It is the intent for Grouper to use these custom attributes, where attributes can be entered in text boxes, and can then be updated, adding to the functionality.

If Signet at a site, for example, has the word developer, administrator, owner of Signet itself – and if you wanted to make Signet customized overall to your site, it would be a resource that would support Signet as a site. This would mean contributed maintenance or management of a subsystem; in a sense, some of the widgets are contributed to Signet, regarding the layout of the
components within the applications; for example, libraries that are overlaid by new installations, or not overlaid, in cases referring to site-specific libraries.

There are two possible ways of doing this. You could 1) plan right and impose the structure in a way that you know, or 2) specify the sub project, where you would bring in and call your own institution-specific changes. With any directory structure, working with tiles and what they want to build – do this locally, make a target, but it would be effectively billed from the UI. You must have these two targets in the original bill target, and agree to copy things as necessary.

The initial version of Grouper 0.5x would have the clean default behaviors, and allow you to apply the specialization. This would be straightforward, while providing an uncomplicated hook to add something in. As for the 3rd party libraries that we are relying on for the tiles, Struts <http://struts.apache.org> is the current framework that we are using. There are no plans to add additional dependencies, and it is important that everyone communicates on using the same 3rd party libraries, for cohesiveness.  Tiles do have a specific configuration, an established standard in the UI.  However, there is more flexibility with how we at Internet2 use the tiles. This stands, with the exception of {Gary's} idea of using a generic controller, which would have its own configuration. [AI] {Gary} will circulate a description of a proposed generic tile controller.

{Minh} expressed interest in coming up with a list of reusable tiles that are used across both applications - standard headers and footers, tree tile, a tile to search and find a person, common images, or even java script tiles, etc. These would fall under the I2MI directory. It may not be possible to have separate tiles that include common definitions combined with Signet tiles to provide a complete picture. There will be some tiles that are shared – subjects in common, subject information.  {Tom} agreed that it would be useful to have an I2MI-UI directory, with a common UI. These sets of common tiles would be sources for inclusion, standards for navigation, the subject interface – all of these are found to be in common with Grouper and Signet. [AI] {Minh} will email the <grouper-dev> list with a list of tiles that share similarities found in both Grouper and Signet.  What other areas might we envision these applications using portions of the other? It will be necessary to have the ability to look up and find groups in order to assign privileges. This would come through the subject interface, where the group is a type of object. If Grouper already has tiles for searching and displaying groups, there is no need to reinvent the wheel.

This discussion will be continued over email, where it will reach a larger audience. New topics might be generated, and it was agreed that all would benefit from a separate mailing list devoted especially to User Interface discussion. [AI] {Tom} will organize a separate mailing list to handle all the I2MI-UI discussions; items should be temporarily cross-posted with the <grouper-dev> mailing list to capture the appropriate audience. You can locate subscription information about the new Internet2 Middleware Initiative SW User Interface Development <I2MI-UI> mailing list at either the Grouper <http://middleware.internet2.edu/dir/groups/grouper/#List> or the Signet websites <http://middleware.internet2.edu/signet/>. As with other Internet 2 collaborative projects, participation is open to all interested parties, subject to the Internet2 Intellectual Property Framework: <http://members.internet2.edu/intellectualproperty.html>.

How much of the total Grouper UI personalities would, in fact, be loaded in a set of tiles? Probably only a small part - for example, when you find and search for a group, then display the results so someone could directly select a group that is a target. This may not be necessary, but it might be useful to view the membership. Though it might be somewhat complicated, it is one of the ways that you could confirm the group.

Are there any requirements to manage groups or characteristics? The group that you want does not exist – so you have to create it. Rather than go through Signet, a second application might open – this will keep things clean, so that you do not have to add or modify information. You might be able to jump into using the class system to find groups manager, for example. You would need some navigation, a sort of umbrella around these applications – administrative navigation, which would allow you to jump between 4+ applications. This assumes that the UI is customizable; there would be a seamless transfer of information. How do we bundle this into a super-tool for full user ability?  We may not have the experience as of now to understand what the functional requirements are. The discussion is a good start for looking at consistency and how things might look – how to plug things together.

Building conventions will go back to the UI, not just the API. [AI] {Gary} will draft conventions for directory layout of and build procedures for I2MI source code packages.

A related topic for future discussion might be if we want to explore HTML and how to implement dynamic content. There is an assumption that learning Java script is a single round trip.

In the parking lot for future I2MI-UI discussions:
1. Report findings from continued exploration of tile capabilities;
2. Clarify the relationship between tiles and Java Server Faces,
    and how each should be used in I2MI UI designs;
3. Enumerate the 3rd party libraries (and their versions) required
    for Grouper and also for Signet.

The next I2MI-UI conference call is yet to be established. Watch the <grouper-dev> and <I2MI-UI> mailing lists for further information.