|FACADatabase Task Force Meeting Minutes for 05/09/07
1. Members Present.
The Task Force meeting began about 1:00 pm with the members identifying themselves on the phone and in the room. Georgia Abraham from DHS and Hope Grey from DOI were on the phone and Hope’s connection was poor. Vivian Drake From VA, Maggie Weber from GSA, Kathy Plowitz-Worden from NEA, Linda Anadale from DOC, Angel Saumure and Tonya James from TRES, Susanne Bolton NSF, David Cleary from NIH/HHS, and Ken Fussell as Task Force Chair were in the room.
2. Review and discuss thoughts regarding the stakeholders and constituencies identified as concerned with the structure, content, and reporting capabilities of the FACADatabase, ver. 3.
Ken began the discussion by asking if we were including everybody we should in our thinking. Ken listed the current constituencies of which he was aware and which include:
• The system was initially developed for Committee Management reporting purposes.
• The DFO role within agencies that have advisory committees was the first user identified since the DFO provides most of the system information.
• The GFO role was added since there are often agency sub-groups with responsibility for multiple committees.
• The CMO role for agencies and Committee Management roles were added. First, he CMOs had to validate the information at the end of the reporting periods, and then the CMOs and Committee Management tracked the consultation process and the committee life cycle within the system. This began from Committee Management’s perspective but has evolved with a greater inclusion of CMO needs and concerns.
• In the interest of openness and because FACA is focused on Public Participation in government we added the Public Access component.
• The White House was added as a user role when the WH Personnel Office expressed interest in 2001 and they continue to use the system.
• The Library of Congress refers inquiries to the database.
• The Congressional Research Service uses the system.
• The General Accountability Office is known to use the system as a starting point for some inquiries directed from Congress towards the activities of agencies.
• Congressional Staffers inquire and are directed to the database several times a year.
Georgia pointed out that the internal use by department officials within the agencies has increased significantly over the years, usually focused on committee membership and committee functions.
Angel reported that her agency uses the system for similar purposes and she directs people from the agency up to and including the secretary’s office to the system as a starting point when there are inquiries about creating new committees, urging the inquirers to determine if there are already committees established that are looking at similar concerns. If agency users can’t find what they need, then Angel’s office will do the research, but often still using the system as the basic tool and starting point.
Ken reported that DOI is using the current system for vacancy reports. Hope observed that the agency wants to use the system and is trying to use the system, but the leadership has no real confidence that their users at the DFO level keep the system up to date, so they ask people to produce a separate monthly report through other channels to compare to the information they have in the system. Generally they are unhappy with the result.
Linda and Georgia shared their methods for creating incentives to keep the records up to date.
Angel wondered aloud if was really appropriate that the Performance Measures should be visible to the public. This was batted around, with Angel pursuing the idea that perhaps it should be internal to the FACA community and others weighing in from various perspectives. Linda, Vivian, Georgia all commented. Ken noted that the discussion had moved away from constituencies and stakeholders but promised to return to Performances Measures and these issues in the Requirements review.
Susanne noted that we should not overlook universities and similar user groups from the public sector. At this point, since no other groups were being identified, Ken suggested that we wrap up the stakeholder discussion for now and return to it when anyone felt they had identified a new group that we had not already included.
3. Requirements Development:
Ken suggested that we continue the requirements development process by examining the current system page by page and role by role, identifying the requirements that had produced those pages and their current contents, keeping what was relevant, discarding what was not needed and adding whatever new requirements we identified.
We began with the Home page and Ken invited the task force to comment on their use of the Home Page and its links.
The group discussed briefly the contents of the Printed Reports 1972-1998 link, and noted that the link would be improved if it was more informative.
The same observation was made about the Case Digest Search.
The Up link and in truth the entire navigation system needs clarity. We need to experiment to find out what works for us as we set up the new system.
Some of the Task Force present felt that the Score 300 link was confusing in its purpose to anyone but the in crowd at the time of the ACR. Others thought the public had a right to know who was keeping the system up-to-date and current.
Logon will be changing in concept and location, since users may be able to logon from anywhere in the system when they have a need to edit data. We discussed the possibility of an automatic logon if the user hit the web site from their assigned workstation.
Ken mentioned the current aspects of the logon process that will be retained, i.e., the username/logon will be the user’s email address so that the user can be sent their password anytime they forget it, and the username/password combination is unique in the system and is linked to the user’s role and access rights.
Angel felt that when read-only data/results are presented to any users, it should be clear and obvious that it is read-only and not editable.
Kathy pointed out that the link names Search and Public Access can sort of mean the same thing to some people. The links are not clear.
Angel thought that it might help if Search was not on the Home page.
The group next discussed the Search link. Ken pointed out that in versions 1 and 2 the Search function was part of the public access concept and a user lost their rights when they selected Search, even if the committee found or selected was one that they owned. In version 3, on the other hand, the system will remember the logged in user’s rights, even when they invoked Search.
Vivian observed that simple, clean, un-cluttered pages were more visually pleasing.
Ken explained how clarifying information will be available to the users about each link and field via hidden tags on the page and how that process made the web page more use to blind users who were accessing the web pages using screen readers.
The group turned their attention to the Search Page and Ken explained the current functionality of the Search in Documents part of the page, i.e., it searches the text part of the committee documents stored online with the database. Ken differentiated the current search capability and the intended search capability in the revised system. With the current system the user searches for text, identifies the committee of interest from the text search, leaves the text search and then drills down to the agency and committee from the Explore Data link/button. With the planned system the user will search for text and will be presented with links to the relevant committees.
Kathy proposed a new search capability on the public’s behalf, a search of meetings by interest areas that would link to the committees. This could be provided either by a search with the appropriate parameters or by a set of reports about meetings that could be customized to get similar results. This generated a discussion by the group on how else the current and future database could be used if we collected data we do not currently collect, i.e., members by congressional district or political party. We will not be going that direction without a statutory requirement to do so. This also prompted discussions about how the system can be currently used to produce tables and schedules of proposed and planned meetings as well as a history of meetings held. Ken wrapped up this section by suggesting we would be coming back to Search with additional requirements as the system evolved.
The group moved on to a discussion of the Help feature, what we wanted Help to be, whether manuals were needed, how they should be named, etc., etc. Georgia thought that it would be more useful if the help displayed was controlled by rights of the logged in user and was context sensitive, so that an individual user was not overwhelmed by all the help possibilities for work they could not do and functionality they could not access. This discussion went on for quite a while.