Friday, August 31, 2007

History of Online Registration

MeetingTechOnline called to ask me questions for their upcoming "History of Online Registration" whitepaper. While I've told this story several times over the past 9 years, the framework of this interview made me think again about why certain technologies go from novel to standard practice in seemingly short bursts of time.

My History of Online Event Registration

Scott Curry, a friend from Clemson, started Enteronline.com in 1997 while I was in graduate school at Berkeley. His experience registering runners for marathons and 10Ks opened my eyes to the new technology of database-driven web sites and e-commerce, and led me to start Register123.com in 1998. Scott was moving to San Diego as Enteronline became a part of Active.com, and I wanted to apply the technology into a field that was more business-oriented than participatory sports. Offering online registration to professional event planners seemed like a good business model: a transaction-based fee structure, recurring revenue from the repeating nature of events, and substantial sums of money being spent in the existing industry.

In the end of 1998, Regweb had a working registration system, B-There was just starting up, Starcite was announced but not launched, Plansoft was selling mainly Windows applications, and SeeUThere was an eVite look-alike. Interestingly, all of these companies are now part of the new Starcite. At that time, most of us were competing against paper registration and in-house systems rather than each other. Cvent, Acteva, Regonline, and others were all right around the corner.

Right after we started, we tried to exhibit at the HSMAI Affordable Meetings show in San Jose. We couldn't get a booth, but we did land a demo with the show manager, George Little Management, who was looking for a vendor to replace their in-house system for the annual International Hotel, Motel & Restaurant Show. I'm proud to say that we've provided online registration to GLM and HSMAI ever since.

Why Then?

Advon asked why so many online registration companies started between 1997-1999. That time period was really a perfect storm for new technology development:
  • Microsoft's Active Server Pages (.asp) and Allaire's ColdFusion (now an Adobe product) changed the World Wide Web by allowing developers to (relatively) easily create web sites and forms that could interact with databases. Thus we could collect registration data online, store it in a database, and then deliver it to meeting planners as reports on demand.
  • More people began to use email and Netscape in their daily life. These attendees asked for event web sites, online registration, and instant email confirmations.
  • Cybercash (now a part of PayPal) and other processors made it easy for developers to integrate online credit card processing into registration forms, without investing in direct connections with the credit card payment network. Now payment for event fees could be collected and confirmed prior to delivering an email confirmation, thus greatly improving events' cash flow and collections.

The result was a situation where people wanted it, technology could deliver it, and the cost to deliver the service was less than the clear benefits. Throw in a few hundred million dollars' worth of venture capital money chasing anything ".com" and you had dozens of start-ups entering the market for online event registration.

Overcoming Early Hurdles

Of course it wasn't that easy, or we wouldn't have seen all of mergers and bankruptcies in this market since 2001. Trust was one of the biggest hurdles I experienced in the early days, as we tried to tell people that we would hold their data for them, but deliver it to them at any time when they needed it.

Back then, the mindset in IT was that security revolved around a physical location - your data was secure when it was stored on your computers, which were safely locked in your office. The idea that someone else should hold your data on their computers was like early banks trying to get people to take the money out of their safes and put it into an "account", which had only a small percentage of cash reserves behind it. Every time I thought we had moved past the trust issue, someone like Event411.com would close shop in the middle of their customers' events and strand both their money and data in bankruptcy court.

From 1997 to 2007 the trust issue has declined in importance because (1) customers have had ten years of experience with web-based services such as travel reservations, online banking, eBay, and Amazon to get comfortable with the web hosted model, and (2) suppliers like Certain Software have provided service to event planners for over 10 years without stranding their customers.

What have you done for me lately?

Before 2001, the emphasis for meeting technology seemed to be, "What can you do for the attendee?" Thus our business was geared toward providing event web sites with a custom look-and-feel, posting FAQs online instead of answering questions one call at a time, linking to online registration forms with integrated credit card processing, and delivering e-mail confirmations and invitations.

After 2003 the question from most event planners is, "What can you do for me?" They take for granted attendee-facing technology and now focus on back-office processes, security, reliability, and full-functionality (i.e., one system that fits all needs). Thus meeting technology is moving towards integrated registration, housing, travel, program management, budgeting, meetings approval, and RFPs.

What happened between 2001 and 2003 was that 9/11 crushed the travel industry and many event people were let go while budgets for new hires were frozen. Since the group travel business recovered in 2003, work loads have increased while human resources have stayed the same. Online registration products matured to the point that they are expected to take care of attendees, so meeting planners focus on back-office efficiency and productivity.

The effect on registration budgets and full-service vendors

The past decade of work has naturally effected service providers who were in the meetings industry before the Internet technology existed. In many companies, registration technology budgets are going down as organizations strive to replace multiple separate systems (membership management, on-site registration, call center technology, online registration, meeting planning software, etc.) with an integrated system. While they are willing to pay more for the integrated system than they did for any one older system, they expect its cost to be less than the sum of the legacy systems.

Also, full-service event registration companies continue to thrive. There will always be a market for whom a single contact is more important than a single system. These people will pay more to a full service provider who delivers an integrated service that hides the complexity of multiple systems and processes. Our business at Certain sees this in the relationship between some of our customers and resellers. We have customers with their own product license who do everything themselves, while other companies contract with a reseller who has a license with us and provides service on top of our application. But a third and growing group of customers follow a hybrid model, where they have a license with us and manage some events themselves, but also contract with a full-service provider/reseller for other events where the reseller uses their clients' license with us.

Wednesday, August 29, 2007

Developing a Section 508 Compliance Strategy for Web Site Accessibility

(This post is a continuation of my article on Section 508 compliance for Web accessibility.)

I've been working with a federal government agency to validate Section 508 compliance for their online registration form. Before this process began, had you asked me if our attendee-facing web pages were Section 508 compliant, I would have replied, "Absolutely, yes." But working with Angela Hooker (http://www.angelahooker.com/) on this project, I've learned a few things about web accessibility:
  1. You cannot rely on automated testing tools, like WebXact, to insure Section 508 compliance.
  2. You must validate compliance with multiple applications geared toward different audiences. For example, try JAWS for sight-impaired users, navigate without a mouse to simulate motor-skill deficient users, and view pages with a lower resolution for technologically-disadvantaged users.
  3. Complying with the spirit of the law (i.e., to provide universal accessibility to Web content) requires an expert who can show you the end users' experience, beyond strict compliance with the letter of the law.

I also learned that the World Wide Web Consortium (W3C) and International Organization for Standardization (ISO) are both following the United States' lead in web accessibility guidelines, and in the future Section 508 regulations will be rolled into the international standards embodied in the W3C Web Content Accessibility Guidelines 2.0 (WCAG). Adopting Section 508 compliance now gives you a head start on interoperability with the next generation of web browsers and platforms (such as iPhones and tablet PCs).


Specific Issues with Section 508 Compliance

Over the past month, I've identified and resolved a few issues with our Section 508 compliance of the online registration forms:

  • We disabled a client-side Javascript function, which hid payment fields that did not apply to your selected payment method. Although this area passed the WebXact screening, the script confused the JAWS screen reader and resulted in content being read out of order.
  • We added text and hyperlinks designed specifically for blind users. We inserted these instructions in a white font color (on a white background), so that they would be "invisible" and not detract from the experience of sighted users.
  • We replaced a web mail interface with a simple "mailto" link. The web mail interface had the same look and feel as the registration form, but opening an e-mail message in your client application (such as Outlook) made us 508-compliant.

Looking at the bigger picture, however, we don't want to have to deal with Section 508 issues one form at a time. So I've been working with our IT, Development, and QA groups in order to develop a systematic approach to build, maintain, and audit Section 508-compliant Web applications.


Developing a Company Policy for Section 508 Compliance

The goals of our Section 508 compliance policy are to:

  • Meet U.S. Federal regulations for our public sector clients (comply with the letter of the law)
  • Produce Web sites that are universally accessible (comply with the spirit of the law)
  • Educate our staff on Section 508 requirements
  • Adopt international standards for more consistent development of Web applications

Why be Section 508 compliant?

  • It is a law for U.S. federal government (and many state/local government) agencies, representing about 25% of both our current and potential customer base.
  • Section 508 compliance is spreading beyond the public sector, becoming an internal requirement for major corporations and non-profit organizations
  • Section 508 regulations are being merged into the W3C Web Content Accessibility Guidelines (WCAG 2.0) and ISO standards, so compliance with these HTML standards help us operate on future web browsers and platforms (PDAs, phones, etc.)
  • Section 508 is a design standard for universal accessibility, just as PCI Compliance is a design standard for financial data security. Following Section 508 guidelines can help multiple developers in a globally-distributed work environment produce consistent, quality HTML code.

Section 508 Compliance Policy

Our policy for Section 508 compliance is:

  1. 100% compliant on the registrant-facing side (i.e., Forms and Web Sites)
  2. Strive for compliance with documentation and Help files, or offer a 508-compliant option
  3. Strive for compliance on Admin side (intranet application), but not at the expense of harming the UI experience for sighted users.

"Strive for compliance" means that where possible on the Admin side and Help files, we should write HTML to the standards of the W3C WCAG and Section 508 guidelines. These standards are international best practices and insure maximum interoperability of HTML as the web moves to new browsers, mobile devices, kiosks, etc. So all images should have ALT tags, all form fields should have ID attributes with Label tags, all data tables should have header descriptors (as defined in the standards), all HTML should be checked for syntax errors such as end tags and tag nesting.

But for areas where meeting 508 compliance would result in an inferior UI for sighted users, we can make an exception in the admin side and Help files. An example here is the Help files "Table of Contents", which is not 508 compliant but has a much better UI for sighted readers through its dynamic interface.

In cases where compliance will not be achieved, then we should try to offer a 508-compliant alternative. For example, Robohelp allows us to save Help files in a separate 508 compliant format, which we can add to our Certain Support Center for vision-impaired users.

Section 508 Compliance Implementation

Many teams will work together to build, maintain, and certify our Section 508 compliance.

Developers and QA engineers:

QA Testing:

  • For as many releases as possible (i.e., if automated and feasible), we should validate Section 508 compliance on a "sample" form and web site with Watchfire WebXact (included in HP Mercury testing tool)
  • This automated tool is a good first pass for testing - it gives the specific line number of problems, along with a proposed solution for the developer

Note that the automated testing tools may return "508 Compliant" when a web site is not truly compatible with the advanced screen readers that disabled users actually employ. In order to comply with the spirit of the law, further User Acceptance Testing is needed.

User Acceptance Testing (UAT)

In order to comply with the spirit of accessibility, UAT should follow the guidelines outlined in Section 3 of Jim Thatcher's tutorial for checking the accessibility of our web pages.

  • With major releases, or once per quarter, UAT should run through a comprehensive "standard" form and web site with the JAWS screen reader (the 40 minute version is adequate for this) - this exemplifies how vision-disabled users experience the web site
  • UAT should navigate the sample form and web site without using a mouse (using Tab and keyboard only) - this exemplifies how motor-disabled users experience the web site

Compliance/Audit (IT)

One deliverable from the audit is for the consultant to produce a Section 508 compliance report for sales to be able to give to clients and prospects instead of having to conduct multiple internal audits one at a time.

Tuesday, June 19, 2007

Web Site Accessibility (Section 508 or ADA Compliance)

The day before my annual family reunion in Myrtle Beach, we received a call from a client stating that the payments page of their online registration form was not "Section 508 ADA compliant". This rang some alarm bells, since we have tried to support the Section 508 accessibility guidelines since signing our first federal government agency client in 2002. I started my research at the "Quick Reference Guide to Section 508 Resource Documents", but at 144 pages I realized that I was going to need a "Quicker Reference Guide" in order for our developers and QA engineers to understand the legal requirements and best practices surrounding Web site accessibility for visually impaired users.

Background Information: Laws and Recommendations

(If you don't have time for the background information, then skip to "The Short Version" at the end.)

Web accessibility is the practice of making web sites accessible by all people regardless of physical disabilitiy or lack of access to the latest technology (such as JavaScript). In the United States, web site design should follow the accessibility standards set by the American Disabilities Act, Section 508 of the Rehabilitation Act, and the World Wide Web Consortium.

The American Disabilities Act (ADA) is a 1990 civil rights law that affords protection against discrimination to Americans with disabilities. Title II of the ADA places non-discrimination requirements on the web sites of public agencies (state and local government).

Section 508 was a 1986 amendment to the Workforce Rehabilitation Act of 1973. It proved to be ineffective, and in 1998 the proposed Federal Electronic and Information Technology Accessibility and Compliance Act was enacted as the new Section 508. In particular, sub-part B, 1194.22 provides 16 rules for Web-based intranet and internet information and applications.

The standards of Section 508 web page design are complementary to the recommendations laid out in the Web Content Accessibility Guidelines (WCAG 1.0) of the Web Accessibility Initiative (WAI) of the World Wide Web Consortium (W3C), which is the international standards organization for the World Wide Web. A working draft of WCAG version 2.0 was published on May 17, 2007.

Additional sources of information about Section 508 standards include:

  • United States Access Board - The Access Board developed the accessibility standards used in the Federal government's procurement regulations for the various technologies covered by Section 508
  • Section 508.gov - GSA’s Office of Governmentwide Policy, Center for IT Accommodation (CITA) is charged with educating Federal employees and building the infrastructure to support section 508 implementation.
  • ADA.gov - Department of Justice's Civil Rights Division explains how to maintain ADA compliance for State and Local government web sites
  • Accessibility Forum - The GSA has created a "Buy Accessible" system to help decide when a federal government purchase must comply with Section 508
  • Information Technology Technical Assistance and Training Center - The ITTATC reached the end of its 5-year grant on May 16, 2006, so this information is for historical purposes only

  • Who Does It Apply To?

    While Section 508 attempts to follow the WCAG standards, and the WAI tries to accommodate international legal policy, it is important to recognize that the W3C publishes recommendations for users of the World Wide Web, while Section 508 and ADA are laws that apply to many web sites in the U.S.

    I'm not a lawyer, but my research indicates that ADA Title II applies to all state and local government web sites, while Section 508 applies to all public agencies that receive federal funding. In addition, vendors (like Certain Software) that provide web sites to federal agencies must comply with Section 508 as a requirement of the purchasing process. Compliance requirements may be expanding to private web sites, however, as USWeb.com reports that "A few sites have already been sued under the ADA, including two major travel sites (Priceline and Ramada.com) that must now meet web accessibility standards and reimburse the court for tens of thousands of dollars."

    Besides the legal requirements, following the W3C guidelines for web site development is simply good business - it ensures compatibility with future web browsers and reaches the widest possible audience. Again from USWeb.com, "According to the Civil Rights Division of the U.S. Department of Justice, there are 50 million people with disabilities in the United States with $175 billion in discretionary spending power." When you consider that Section 508 Compliance benefits not only blind people, but mature audiences and people with visual impairments, the need to serve these groups in our aging population is clear.

    Implementing Web Accessibility Guidelines

    The best place to start is to read the 16 rules for web site design in Section 508 Sub-part B 1194.22. The Access Board provides examples of implementing these 16 rules with greater detail. Also, Chapter 5 of the "ADA Best Practices Tool Kit for State and Local Governments" provides examples of designing web sites that comply with Title II of the ADA.

    For experienced Web designers, Jim Thatcher wrote a comprehensive 12-page Web Accessibility Tutorial on implementing Section 508 compliance and published it on his web site JimThatcher.com. This is the best resource for Web User Interface (UI) developers who want to learn how to implement Section 508 compliance.

    And for the truly zealous, the Web Content Accessibility Guidelines version 2.0 is the ultimate compilation of best practices for accessibile web design.

    Validating Compliance

    Jim Thatcher has an excellent 5-page tutorial on Testing for Accessibility. The most popular program, Bobby, was started as a free service by the Center for Applied Special Technology. It was rolled into the Watchfire WebXact testing tool, which unfortunately will no longer be available for free use after July 15, 2007. (Bobby offers a free 10-day evaluation with registration, or it is available for purchase for $299.) Watchfire also offers a comprehensive WebXM Application Scanner, which looks for security, spelling, and compliance errors in your web pages and can be integrated into QA processes via solutions such as the HP Mercury Quality Center, IBM Rational ClearQuest, and Microsoft Visual Studio Team System.

    I used the free testing tool at WebXact on a sample registration form created to test the payment page of our online registration process. It is an excellent product. You simply enter a web site URL, it scans that page, and then provides a concise report showing the errors and warnings your HTML has compared to either the Section 508 or W3C WCAG standards. You can click on any of the warnings to see the specific checkpoint line in the relevant standard that triggered the message, along with instructions for resolving the issue. Below are screenshots I took of this process.




    Going back to the reason for this article, readers who carefully inspect the WebXact results will notice that we did have a Section 508 non-compliance error on our payments page - the "Billing Address" form fields were not identified with labels. Our client's form, however, did not use these fields, and thus it was in compliance. The original issue that they raised regarded our use of JavaScript to show or hide form fields based on the payment method that the registrant selects. JavaScript (or "Dynamic HTML") in itself, however, is not in violation with Section 508 or W3C standards, because it was designed to "show all" fields if JavaScript is disabled in the user's browser, or if the user is visually impaired and using a screen reader tool to access the page. I was able to demonstrate this by disabling JavaScript on my browser (in IE 7, this is under Tools > Internet Options > Security > Custom Levels, scroll down to Scripting, under "Active Scripting" select "Disabled", then close and re-open the browser) and re-loading the payments page, which correctly showed the form fields for all payment methods.

    So, What Does It "Look" Like to Visually Impaired Users?

    The best way to experience your web site or application through the eyes of impaired users is to either use a test-only browser or screen reader software.

    The most popular text browser is "Lynx". You can see it in action by entering a URL from your Web site at the free Lynx Viewer available at http://www.delorie.com/web/lynxview.html. Below is a screenshot of the "Lynx" (text-only) view of the same payment page shown above.



    The most popular screen reader is JAWS. It's an interesting exercise to load it on your PC and have it read your web site to you. You can select from several electronic voices and adjust the speed to match your preferences. I once watched an accessibility expert at the Equal Employment Opportunity Commission (EEOC) use JAWS on our registration application at a blistering pace. She (and according to her, most blind people who use screen readers regularly) could navigate through a page using the electronic voice faster than I could read it.

    The Short Version

    If you want to be compliant with the ADA and Section 508 accessibility guidelines:

    1. Read the Section 508 Rules.
    2. Have your Web designer read Jim Thatcher's Web Accessibility Tutorial
    3. Validate compliance on your web site with Watchfire WebXact or one of the other tools listed in Jim Thatcher's Six Tools for Testing.

    Friday, June 01, 2007

    The Number One Feature Request from Meeting Planners

    Jerry Chandler from Business Travel Executive magazine asked me, "What is the #1 feature request that you hear from meeting planners?" I've heard this question before, and I know that editors expect an answer like "Travel Integration", "Meeting Expense Consolidation", or "Budgeting". But my answer was, "Tools that will simplify their working life".

    Deliver More. Do Less.

    In business, everyone is asked to deliver more product with less cost. Since the "product" of Meeting Planning is often pre-event data management, this demand translates into managing more information while using less human time. Meeting Planners are flooded with data, and they each want "The Feature" that will make their unique work flow simple. For some, the feature is roommate matching; for others, it is financial integration for month-end accounting reconciliation; for others, it is managing seating assignments.

    Developing "The Feature"


    Software developers try to create an application with a set of features that meets the needs of the largest group in the target audience. In the late 1990s, online registration was "The Feature" that all event planners and attendees wanted, and providing it was (in hindsight) straightforward. Some events collect payment from attendees, so integrated online credit card processing became "The Next Feature". Then room block management was the feature, but only for a smaller set of event planners since not all events manage their room blocks. Roommate matching was the feature for corporate meeting planners whose firms wanted to reduce housing costs by sharing rooms among their employees. Of course, this feature was useless for trade shows and conferences where attendees stay in individual rooms. Next, corporate travel managers who found themselves in charge of centralized meeting planning decided that travel integration was the must-have feature, for one stop group travel planning (event registration, housing, and travel arrangements). The focus on meeting expense consolidation led to feature demands for Budgeting, RFP management, Facility / Vendor databases, and so on.

    Along the way, each new feature made online event registration applications appeal to a broader audience, but somehow, more features made more people less satisfied. This contradiction is explained when you remember that each individual user did not specifically ask for all of these features, what they wanted were "Tools that will simplify their working life". With additional features, applications became more complex to master, and developers became focussed on expanding breadth in the application instead of tying existing features together to streamline individual workflow processes.

    When More Is Less

    The May 21, 2007 issue of Forbes reports that the Honda CRV, with 88 possible configurations, outsells by 250% the Chrysler Nitro, with 167,000 configurations. Since dealers sold only 36,687 Nitros last year, Chrylser and its suppliers were paying for an infrastructure that supported five times as many configurations as any customer wanted. (The 2008 Nitro will allow 680 option combinations.)

    When I apply this logic to our application, I find about 16,549,457,379,840 possible combinations in our custom reporting area alone.
    • 21 report types
    • 7 report output formats
    • 11 report display options
    • 4 report visibility options
    • 2 report data scope options
    • 8 "Changes Report" options
    • 10 "Role-based"options
    • 11 group options
    • 6 subtotal options
    • Approximately 1000 columns
    • 29 filter options, plus 2 date filter options with 9 date options and 34 date range options
    • 2 header/footer options with 63 dynamic fields
    • 3 export action options
    • 10 custom column options
    I've worked on this application since the first line of code, and there are few features or options that were added without solving a specific customer need. But after 8 years these features in aggregate have made life more difficult for some users than it should be. And it has created a "headwind" that slows down development; because each new feature can potentially affect more areas, QA must test more possible combinations in order to ensure backwards compatibility, and a wider audience demands more new periphery features that perpetuate the cycle.

    Paid to Provide Solutions, not Just Identify Problems


    While providing more features for the event planning industry, our design philosophy has to step back and create a User-centric (and Workflow-centric) focus on simplicity. I will continue this discussion in a future blog.

    Thursday, May 17, 2007

    APEX TAC Monthly Meeting Minutes - May 2007

    The APEX TAC held it's monthly Virtual Meeting on May 17, 2007. Here's what we did.

    APEX TAC Monthly Virtual Meeting

    Meeting Topic: APEX Virtual Meeting 5/17/07
    Host: Rick Borry (Certain Software)
    Meeting number: 484 360 851
    Start Time: Thursday, May 17, 2007 07:57:17 PM
    End Time: Thursday, May 17, 2007 09:09:26 PM
    Meeting URL: https://newmarketinc.webex.com/newmarketinc

    Attendee List:
    Rick Borry (Certain)
    EJ Siwek (CIC)
    Jeremy Keller (Meeting Matrix)
    Jane Melville, Julie Camp (Hilton)
    Scott Rudberg & Andrea Campbell (Passkey)
    Rob Wilson (Meeting Sites Resources)
    Rick Fahnestock (MPI)
    David Collins (Syllogy Design) - Joining the Rooming List Group
    Michael Lu, David Quattrone (Cvent)
    Charles Jeffers
    Chip Meyer (Data App)

    Agenda

    STRATEGY BACKGROUND (from the Ft. Lauderdale Spring meeting):
    See http://registrationdoctor.blogspot.com/2007/04/apex-implementation-pilot-q1-2006.html

    PROGRESS UPDATE:

    Jeremy Keller and Rob Wilson reviewed their progress on the RFP transformation tool. They are about 90% complete, but learned some lessons that we will adopt for the other groups:


    • Generally, it's better to use the Response XML (OTA_HotelRFP_MeetingRS3.xml) because the Request XML sample does not have as much data.

    • But even the Response XML document in the OTA standard is not complete - many fields don't have data or have duplicate data from other fields - this makes debugging very hard. We should modify the sample XML fiels so that all fields are complete and all data is unique (e.g. don't use the same name for Event Organizer and Key Contact)
    • Rick and Chip suggested a "best practice" that Response Messages should echo back the data from the Request Message in addition to adding response data. This way the sending application could validate that the data it sent was placed into the correct fields, e.g. the Last Name in the meeting planner's application was stored into the Last Name field of the hotel's application. Hilton pointed out that this could lead to a lot of extra work and is really only necesary during the initial validation phase. Once the translator routine has been validated in both partner's applications, there isn't as much of a need to echo data back-and forth every time. This will be a discussion point during the initial pilot implementations.
    • Jeremy added a CSS style tag to the XSLT so that he could color-code the font classes for "Labels" (from the APEX Template), "Data" (from the XML file), and "Comments" (his notes. We agreed to use this coloring standard during development.
    • Jeremy uses Visual Studio instead of Altova Stylevision, which produces a lot of "extra" code in the XSLT. He manually cleaned up the output from Rob's Stylevision copy in order to produce the final transform.
    • Rob noted that the data types used in the OTA standard are not always consistent, e.g. some dates are "Date-Time" type and others are "String". Chip noted that this may be intentional if the field can contain text such as "ASAP" or "3rd Quarter", but we need to review these issues and decide if they are mistakes or valid.
    • Hilton raised several issues about labels, e.g. "Key Contact" in Section 1 but "Primary Sales Contact" in Section 5. The labels and amount of information collected must be reviewed for clarity and completeness.
    • Hilton also asked about the location of the field definitions - since the RFP standard doesn't have an introduction (as the other standards do). For example, in Section 4, what is the difference between "RFP Published Date" and "RFP Distribution Date"?
    • After Jeremy and Rob finish their merge, everyone will be able to add comments (in Red) to the final output for review in the Orlando meeting in June.

    THIS MONTH’S TASKS:

    • We will focus on completing the RFP XSLT and resolving its issues before tackling the other two schemas

    • Jeremy, Rob, EJ, Chip will work on the RFP completion:

      • Complete merge

      • Update color scheme to match standard

      • Review merged document and add comments, errors, questions

      • Complete addition of data to all fields in RS.XML so that it is fully documented

    • Rest of team should review the completed RFP with Rob and Jeremy's comments and make recommendations for changes needed, especially from the Hotels' prespective of what data they need to receive from Planners and send in response to RFPs

    • Discuss common issues teams are facing and decide how to resolve them on the Forums at: http://apex.dataapp.com/Forums/tabid/226/ctl/Edit/mid/624/ItemID/6/itemindex/0/Default.aspx

    NEXT MEETING (Orlando, FL after HITEC, June 27-28)


    • Meeting calendar available at: http://apex.dataapp.com/Calendar/tabid/224/Default.aspx

    • The next face to face follows HITEC in Orlando. The TAC meeting will be held on June 27th and 28th, starting at 3pm on th 27th and ending at 3pm on the 28th.

    • We have a room block of 5 for $149.99 each at Embassy Suites Orlando - Lake Buena Vista, 8100 Lake Ave., Orlando, Florida 32836. Attendees can call the main number 407-239-1144 and ask for the Reservations Dept. (Mon-Fri, 8-4pm). Please have mention "CIC/APEX".

    • Tentative Agenda:

    1. Powershop beta demonstration (Chip Meyer)
    2. XSLT Demonstrations by RFP team and review of work completed and recommendations
    3. Close out RFP, focus on Rooming List and Event Specification Guide

    End Note

    Yes, even Pre-Kindergarten has graduation. Congratulations, Izabella!

    Even Pre-Kindergarten has graduation now...