IT Council - George Mason University

Meeting Notes
7/17/03

1. Review of Web Standards document in response to state guidelines

a. Thanks to Paras, Mel, Lara, and Dee for the draft.
b. Key point: definition of what constitutes a University web site
c. Kristine Neuber addressed web accessibility

i. Use 508 standard instead of WAI?

1. less complex
2. more things addressed
3. training already in place
4. Kristine provided comparison chart

ii. Comments-this document is designed to show minimum compliance with state standards

d. Discussion about deciding to limit standards to first two levels

i. Better to choose 508 as standard for first two levels
ii. Modify first sentence in P.3: George Mason applies these standards to its web site as so defined.
iii. George Mason utilizing 508 instead of WAI as permitted in the state guidelines.

e. Noted that we own licenses for tools that will rewrite code for non-508 compliant pages.

f. The group approved the response as amended

2. Functionality Sub-Group report (Mel, Creston, John, Ann Clare, Paras, Andrew, Lara)

a. What is a web architecture?
b. General requirements

i. Single source data capture
ii. Appropriate decentralization of input and editing of data
iii. Incorporation of data entry into business processes
iv. Availability of data for output in multiple areas
v. Data easy to access by web interface
vi. External data sources incorporated as needed
vii. System for archiving and tracking version control

c. Functional requirements

i. Ability to retrieve operational data from central repository to provide content for web sites and provide services via the web (possibly data warehouse).
ii. Ability to access data for web development through central content management system.
iii. Ability to store and retrieve data used in web apps in an ITU-hosted database system.
iv. Ability to run web apps on ITU hosted web app servers.

d. What about people who choose to use non-standard apps?
e. What about units that maintain own servers? Provide for dynamic interface with data.
f. Make sure architecture has enough breadth to accommodate most common apps.
g. Noted: plan to communicate draft functionality doc with many groups on campus to see if we are addressing their needs
h. Incentives for participation?
i. Object to create a system that allows people to use central data, not force people to use. Re-evaluate proprietary system.
j. Prioritizing data to be included.
k. Start with one program-like catalog data.
l. Business requirements

i. Increased efficiency
ii. Better process-orientation
iii. Collaboration
iv. Access to more information

m. Note: hire cultural anthropologist to help with cultural change!
n. Hope for build up of successful process
o. Be mindful about length of time to implement this
p. Avoid simplest solution that doesn't really solve anyone's problem
q. Concern with reliability and ongoing accessibility

i. Sufficient capacity to support greatly extended use of web
ii. Use pilot initiatives to help determine infrastructure needs
iii. More formal capacity planning

r. Role of Internet 2?
s. Allow for use of multiple types of data-images, video, as well as text, numbers.
t. Storage place for aggregated data.

3. Next steps

a. Functionality group to revise document
b. Draft proposal presented to other groups on campus
c. Create groups to start looking at technical solutions and implementation issues (What is it and how can we do it).

4. Communication plan

a. Meet with MESA project leaders; plan joint communication with MESA
b. Road shows on MESA, web standards, web architecture

i. Get input and feedback
ii. Which groups?

1. Deans and directors
2. executive council
3. auxiliary enterprises
4. faculty senate/staff senate
5. OSP
6. OCPE
7. Support Services
8. Technology Coordination Team
9. alumni/development
10. Telecom and tech coordinators
11. Library

iii. Other means

1. DoIT Dialog
2. ITU Open House
3. Web site
4. Town Hall

iv. Communication Team

1. Anne
2. Dee
3. John

v. Technical Team

1. looking for members

vi. Implementation Team

1. looking for members

vii. Timeline

1. Sept: draft doc on functionality
2. Sept-Oct: meetings w/ campus groups
3. Nov: adopt requirements
4. Dec: technical possibilities subgroup
5. Spring 2004: technical proposals
6. Spring 2004: Discuss possible pilots
7. Summer 2004: proposal to VPIT
8. Summer-Fall: implement pilots
9. Spring 2005: evaluate pilots, make final recommendation

Attending:
Dee Holisky
Anne Agee
Mike Behrmann
Lara Bushallow
Ann Clare
John Creuziger
Andrew Flagel
Andres Fortino
Jim Finkelstein
Creston Jamison
Paras Kaul
Ruth Kifer
Mel Nichols
Roy Rosenzweig
Sean Watkins
MeiHua Zhai
Guest:
Kristine Neuber

Not Attending:
Farrokh Alemi
Cathy Hubbs
Deborah Keene
Scott Martin
Mike Wood
Stan Zoltek

-top-




Home Members Projects Meeting Notes Information Technology Unit	Meeting Notes 7/17/03 1. Review of Web Standards document in response to state guidelines a. Thanks to Paras, Mel, Lara, and Dee for the draft. b. Key point: definition of what constitutes a University web site c. Kristine Neuber addressed web accessibility i. Use 508 standard instead of WAI? 1. less complex 2. more things addressed 3. training already in place 4. Kristine provided comparison chart ii. Comments-this document is designed to show minimum compliance with state standards d. Discussion about deciding to limit standards to first two levels i. Better to choose 508 as standard for first two levels ii. Modify first sentence in P.3: George Mason applies these standards to its web site as so defined. iii. George Mason utilizing 508 instead of WAI as permitted in the state guidelines. e. Noted that we own licenses for tools that will rewrite code for non-508 compliant pages. f. The group approved the response as amended 2. Functionality Sub-Group report (Mel, Creston, John, Ann Clare, Paras, Andrew, Lara) a. What is a web architecture? b. General requirements i. Single source data capture ii. Appropriate decentralization of input and editing of data iii. Incorporation of data entry into business processes iv. Availability of data for output in multiple areas v. Data easy to access by web interface vi. External data sources incorporated as needed vii. System for archiving and tracking version control c. Functional requirements i. Ability to retrieve operational data from central repository to provide content for web sites and provide services via the web (possibly data warehouse). ii. Ability to access data for web development through central content management system. iii. Ability to store and retrieve data used in web apps in an ITU-hosted database system. iv. Ability to run web apps on ITU hosted web app servers. d. What about people who choose to use non-standard apps? e. What about units that maintain own servers? Provide for dynamic interface with data. f. Make sure architecture has enough breadth to accommodate most common apps. g. Noted: plan to communicate draft functionality doc with many groups on campus to see if we are addressing their needs h. Incentives for participation? i. Object to create a system that allows people to use central data, not force people to use. Re-evaluate proprietary system. j. Prioritizing data to be included. k. Start with one program-like catalog data. l. Business requirements i. Increased efficiency ii. Better process-orientation iii. Collaboration iv. Access to more information m. Note: hire cultural anthropologist to help with cultural change! n. Hope for build up of successful process o. Be mindful about length of time to implement this p. Avoid simplest solution that doesn't really solve anyone's problem q. Concern with reliability and ongoing accessibility i. Sufficient capacity to support greatly extended use of web ii. Use pilot initiatives to help determine infrastructure needs iii. More formal capacity planning r. Role of Internet 2? s. Allow for use of multiple types of data-images, video, as well as text, numbers. t. Storage place for aggregated data. 3. Next steps a. Functionality group to revise document b. Draft proposal presented to other groups on campus c. Create groups to start looking at technical solutions and implementation issues (What is it and how can we do it). 4. Communication plan a. Meet with MESA project leaders; plan joint communication with MESA b. Road shows on MESA, web standards, web architecture i. Get input and feedback ii. Which groups? 1. Deans and directors 2. executive council 3. auxiliary enterprises 4. faculty senate/staff senate 5. OSP 6. OCPE 7. Support Services 8. Technology Coordination Team 9. alumni/development 10. Telecom and tech coordinators 11. Library iii. Other means 1. DoIT Dialog 2. ITU Open House 3. Web site 4. Town Hall iv. Communication Team 1. Anne 2. Dee 3. John v. Technical Team 1. looking for members vi. Implementation Team 1. looking for members vii. Timeline 1. Sept: draft doc on functionality 2. Sept-Oct: meetings w/ campus groups 3. Nov: adopt requirements 4. Dec: technical possibilities subgroup 5. Spring 2004: technical proposals 6. Spring 2004: Discuss possible pilots 7. Summer 2004: proposal to VPIT 8. Summer-Fall: implement pilots 9. Spring 2005: evaluate pilots, make final recommendation Attending: Dee Holisky Anne Agee Mike Behrmann Lara Bushallow Ann Clare John Creuziger Andrew Flagel Andres Fortino Jim Finkelstein Creston Jamison Paras Kaul Ruth Kifer Mel Nichols Roy Rosenzweig Sean Watkins MeiHua Zhai Guest: Kristine Neuber Not Attending: Farrokh Alemi Cathy Hubbs Deborah Keene Scott Martin Mike Wood Stan Zoltek -top-
Contact: Anne Agee \| Updated June 7, 2004