Friday, November 09, 2007

Online Registration: Life as a small fish in a big ocean

Last week Lauren Covington and Stephen Nold at Meeting Tech Online (MTO) published "Registration Tools: What’s New, What’s Next", describing the results of their research into the subject. The topic raised by meeting planners that was of most interest to me was their desire to integrate registration systems with their other back-office systems.

Background: Big ocean, small fish

I'm not sure how big the meetings industry is. Starcite's Web site refers to the $300 billion global events industry, while a January 2007 PhoCusWright study projects "groups and meetings revenue" at $175 billion by 2008. Either way, the market size is really big, but according to the PhoCusWright study travel (air, hotel, car, ground transportation, cruise, travel) accounts for about 54% of the total while non-travel (meeting rooms, catering, audio/visual) accounts for 46%. Starcite's research predicts a $1.5 billion market size by 2010 for meetings technology tools (which I assume includes event RFPs, meeting expense management, meeting planning, online community, and registration applications). If online registration tools accounts for 10% of that total, then $150 million is a nice market niche for a small software company like ours, but this size makes it tough for us to set the technology direction of companies that organize events and spend 1,000 times that amount holding them.

(Comment: Thanks to Michael Boult, Starcite's CEO, for his polite comments correcting my originally reported data and providing additional information.)

Living with multiple systems when you are the smallest of the lot

The result is that we enter systems integration projects from a position of weakness. Companies look at their CRM (Customer Relationship Management), Intranet, and HR employee databases as their primary applications that are critical to business operation. While event management software is crucial to a small number of meeting planners, the rest of the organization spends maybe 15 minutes each year registering for a handful of events. As a software company, we want to build interfaces that others connect to, give them the documentation, and have them go at it. More often, we receive a stack of documentation and are asked how we are going to fit our round peg into their square hole.

Love it or hate it, everybody has it

The first place we started was with Microsoft. By integrating with Internet Explorer (Certain Registration), Outlook (email and calendar appointments), Excel (reports and imports), and Word (labels, badges, and printable documents) - we connect to the tools that 90% of our customers regularly use. The open source movement and competition from Google, IBM, and others have forced Microsoft to expand their products' interoperability slowly but steadily. I expect that Certain Registration and similar products will continue to grow closer to these standard tools in the future.

The key to communication is to speak the same language

Two systems that speak the same language can communicate readily. Two systems using different languages must have an "interpreter" in order to communicate. In software, the cost of building the interpreter can be the difference between winning and losing the business. Because online registration is dependent upon larger systems, we have to learn the languages of the core systems.

When I wrote the second version of Certain Registration ( in 2001, I corrected the mistakes of the late 1990s, but I did not have a standard framework to build upon. Now, the software industry has both a standard communication method (Web Services) and language (XML). I've written previously about my efforts to help define a standard language for the events industry through the Convention Industry Council's APEX initiative. I have recently had the chance to review Security Assertion Markup Language (SAML), an established XML communication standard for "Single Sign On", which is the practice of logging in once and being authenticated into multiple applications. (I'll write more on that subject in a future post.)

Eating the elephant one bite at a time...

The reason I spend so much time on XML standards and Web Services is that, while we have integration interfaces now, the future for "minor" applications like registration will be to natively speak the common XML languages of the core applications. Then my clients' developers will be able to select Certain Registration as an off-the-shelf component of the much larger system that they are supporting, and they will be able to quickly exchange data within defined boundaries between our application and their other components.

As I see it now, this is going to be the only way for most organizations to have an "all-in-one" system that includes a professional meeting management component.

Monday, October 01, 2007

What to do when you can never have enough standard reports

One of the most common questions that I see on online registration RFPs is, "How many standard reports do you have?" It's a question that begs for a misleading answer, because there is no "standard" for reports in event registration and no two vendors' answers are comparable.

(Caveat: After thousands of industry discussions, the Accepted Practices Exchange (APEX) has published a few report "standards" for specific areas of meeting planning, but few people use these without making at least minor adjustments for their specific business needs.)

Early on, we stopped trying to give customers a dozen or a hundred standard reports in Certain Registration and focused on providing a minimal set of reports "out of the box", while allowing users to copy and customize those reports in order to define their own standard reports. But even this hasn't been enough to meet our goal of "one-click reporting" for all customers.

Reporting in Excel With Online Data

Last year, I described my experience on-site at the National FFA Organization's 79th Annual Convention. The 80th Convention just ended, so last month it was time to update their on-site reports for this years' event. This process reminded me of some unique reporting that I did for FFA using Excel Web Queries.

While most business users are familiar with Excel spreadsheets, not too many people use its more advanced features such as Web Queries, Macros, and Pivot Tables. Web Queries allow you to pull data from any Web site address into an Excel spreadsheet. Pivot Tables allow you to take tabular data in a spreadsheet and summarize it by any column or row. And macros allow you to record a series of actions within the spreadsheet and then automate them in the future.

The FFA requires on-site reports beyond the capability of Certain Registration. In addition to pixel-specific formatting requirements, they have several "special rules", such as single-day registrants should count as one-half of a person when calculating the total registration numbers. In order to meet their needs, I started with an Excel spreadsheet, where I used a Web Query on one worksheet to extract raw data from the FFA event in Certain Registration.

I next added a worksheet that used a Pivot Table to summarize this raw data into a simple table.

Then, I used Excel formulas to apply "special rules" and to transfer the desired data to a pre-formatted worksheet suitable for printing.

And finally, I recorded an Excel macro and associated it with the FFA icon.

In the resulting Excel spreadsheet, when an FFA user who is logged into Certain Registration clicks on their logo on the first worksheet, the macro automatically runs the Web Query, refreshes the Pivot Tables, and updates the printable worksheet via its formulas. The user then clicks the print button and pulls the report off the printer.

Learn more

I'll leave it to the reader to decide if they are interested enough in this process to learn how to apply Web Queries, Pivot Tables, and Macros to their Excel spreadsheets. If so then Microsoft's help files and online resources provide ample instruction.

Friday, September 07, 2007

Will technology replace face-to-face meetings?

Jeff Rasco of Attendee Management Inc. pulled me aside at the MPI World Education Congress in Montreal last month with an interesting problem. He had a client who needed fax delivery of their online confirmations, which Certain Registration offers only via e-mail or printable documents. The situation behind this need led me to some interesting discoveries about the application of technology in the meetings industry.

"Virtual" Road Shows - in Person

Jeff had a client who manages events for a major pharmaceutical company. Instead of the typical practice of using a sales rep to pitch a product, the company wanted to arrange a nice steak dinner for doctors to sit down and listen to a world-class expert in their field discuss topics of mutual interest (some of which happened to be the company's products). But the cost of flying such expensive talent around the country to each major city would be high, and no expert is willing to use that much time meeting with a large number of small groups.

So Jeff's client contracted with 50 or so Morton's steak houses to use their new Velocity Suites product. One evening, doctors across the country come to the Boardroom at their local Morton's, are greeted by local representatives from Morton's and the pharmaceutical company, sit down for a nice dinner, and then at a specified time a large screen rolls out and the keynote address is broadcast into each dining room from the headquarters in New Jersey. The Boardrooms are set up for interactive presentations, so attendees can "raise their hand" and ask questions, which are heard at the other locations also.

To me, this is a perfect example of one way technology and "virtual meetings" are changing and will change the meetings industry. Humans are social, and fine food coupled with face-to-face contact with a personable sales rep simply works for businesses. But add to that mix a top-tier speaker in a small group setting, and you have a winning combination. This technology makes it possible to hire a speaker for 50 Boardrooms of 40 people each, when you could never afford the time or cost of meeting each group one at a time. And, done correctly, each small group will feel like they are getting the same attention as if there weren't 2000 others seeing the same program.

Since my conversation with Jeff, I've read more about this concept in the August 2007 issue of Successful Meetings ("Steakhouse Chain Makes High-Tech Meetings" by Vincent Alonzo, p. 11) and at Meeting Focus. I expect to see more restaurants offer this format and more companies use it in the near future.

New Meeting Formats, Same Registration Challenges

So back to the point of Jeff's conversation. His challenge was to manage registration for 50 or so small meetings, which together acted like one big meeting with a couple thousand attendees. Many doctors continue to prefer fax over email for their registration confirmations, so with past small meetings, Jeff's team would handle this request once or twice by simply printing out the email confirmation and then sending it via their fax machine. But the volume of fax requests for the Morton's meeting series was making this process cumbersome. He asked me if we could offer this capability, or if any online registration company does.

I thought about this problem on the flight home and wondered if maybe I could devise a feature for our application where he would enter an e-mail address that contained the registrant's fax number, and then our service would receive the e-mail, convert it into a fax, and deliver it to the appropriate number. I realized this solution could have broader application outside of meetings and briefly thought about starting an offshoot business, until I searched Google and found a dozen existing services. The one I liked best was Faxaway, where you send an email to [fax_number] (e.g.,, it faxes the content to the number provided, and then charges $0.11/minute to your account (based on the "From" email address that you used).

I'm not sure if Jeff used the service, but it was an example to me of the growing breadth of web-based services available to meeting professionals. Application designers don't always have to fit every solution into one system; sometimes it is better to figure out what you want technology to do and then look for it in a stand-alone system that can integrate with your current process.

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 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 in 1998. Scott was moving to San Diego as Enteronline became a part of, 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 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 ( 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 - 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.
  • - 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 reports that "A few sites have already been sued under the ADA, including two major travel sites (Priceline and 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, "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 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 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:

    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)


    STRATEGY BACKGROUND (from the Ft. Lauderdale Spring meeting):


    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.


    • 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:

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

    • Meeting calendar available at:

    • 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...

    2007 SGMP National Education Conference

    On May 3rd I presented an educational seminar titled "Online Registration for Government Meetings: Compliance, Security, and APEX Standards for the Group Travel Industry" at the Society of Government Meeting Professionals (SGMP) 2007 National Education Conference in Atlantic City. You can wait to learn about the session in the next issue of Advantage magazine, or read about it below.

    Session Summary

    This session discussed the past, present, and future of online registration. Event registration in the past made meeting planners the bottleneck in a cumbersome process as paper, phone, and fax registrations came in and were typed into a computer, while attendees waited for their confirmation letters to arrive via mail. We demonstrated features of modern online registration tools that provide a cost-effective path to attractive web sites, custom registration forms, integrated credit card processing, and instant email communication. Online registration is governed by many regulations and best practices, including data encryption using Secure Sockets Layer (SSL), Payment Card Industry (PCI) compliance for credit card processing, American Disabilities Act (ADA) Section 508 compliance for equal opportunity, Fair and Accurate Credit Transactions Act (FACTA) regulations for privacy concerns, and the CAN-SPAM law for e-mail communication.

    Lastly, we discussed the APEX initiative to produce open standards for electronic data transfer of event RFPs, rooming lists, and Event Specification Guides between meeting professionals and hotel suppliers. During the Q&A period, we discussed an analogy for the future world of instant and easy data exchange between hotels and meeting planners; APEX will be the un-seen plumbing in your housing, while software tools will be the faucet handle in your sink – offering a simple and intuitive way to get water. I encourage participants who wish to remain informed about the topics discussed in this session to subscribe to the speaker’s blog at

    Friday, May 11, 2007

    Listen to Your Customers and You Might Learn Something

    Sclerochronology is the study of physical and chemical variations in the accretionary hard tissues of organisms, and the temporal context in which they formed. Familiar examples include annual bandings in reef coral skeletons or daily growth increments in mollusk shells.

    I learned this from our customer Beth Miller-Tipton of the University of Florida during a conversation at the Society of Government Meeting Professionals in Atlantic City last week. Beth also taught me that she is using our product to manage abstract submission for their upcoming Sclerochronology conference. This was news to me; I didn't know that we had an abstract management tool.

    Behind the Curtains at Scientific Conferences

    In my graduate school days at Berkeley I had the opportunity to help organize a few conferences for the California Catalysis Society. Scientific conferences typically have a higher ratio of speakers to attendees than other educational events. Let's say you're an expert in a particular area of science (such as Catalysis or Sclerochronology) and you find yourself appointed to be the host of a conference on the subject. When you begin to put the program schedule together, the first step is to issue a "Call for Papers", which you send to everyone in your field. Scientists, professors, and students who want to present their work at the event submit abstracts describing the content of their proposed presentation or poster. A conference usually has multiple sessions, each focussed on a particular topic. The session chair is an expert on that topic and has the job of selecting speakers, moving the presentations along (often only 15-20 minutes are allotted per speaker), and managing the discussion.

    Presenters submit these abstracts for many reasons - their budget might not allow them to travel to the conference unless they are speaking, they may have recent results that they are about to publish and want to generate additional attention for their research, or they may be rehashing previous research in order to get another line on their Curriculum Vitae (the scientist term for resume and list of publications). Success in science, like most fields, is a combination of quantity and quality. Quantity of research is demonstrated by the length of your list of publications and presentations, while quality often depends on the number of citations that your research has, i.e. the number of other people whose work references yours. (Where do you think those guys at Google got their "page rank" idea?) These two factors combine to help determine your funding levels from grant applications, your promotion to tenure, your movement up the academic ladder into the elite universities of highest prestige - you get the idea. So getting your abstract selected is a big deal at some conferences.

    Abstract Management Process

    As the meeting planner, you have to collect the abstracts from prospective presenters, force the session chairs to review the abstracts and select their posters and presentations, and keep the presenters informed of their status (since many presenters cannot register or make travel plans until they know that their abstract will be accepted). Fortunately software is available to facilitate this process, although dedicated "Abstract Management" solutions can be expensive and are over-kill for many conferences.

    Certain Registration Extended

    Enter our clever customer Beth Miller-Tipton. She devised a process with her IT department and Certain Registration to use her existing registration system to collect both abstracts and registration and housing reservations. They first upload the abstract file (usually as a Word document or PDF) onto their internal servers, then link to a registration form in Certain Registration, where they collect the presenter's contact information, abstract title, presentation preferences, and so on. They use data integration to pass the web address of the abstract file into the registration form, so that they can produce a single report from Certain Registration with the contact information for all submitters, with hyperlinks to their abstracts. Beth and the session chairs sit down one day, run through this list on a projection screen, and click on each link to view the abstract. The chair (or committee) quickly decides which abstracts to accept for presentations, or which for posters, or which to decline if space is limited.

    Without having to learn a new system or spend a bundle, Beth created an online abstract management process that works conveniently for everyone - the meeting planners, the session chairs, and the prospective presenters. I liked it so much that we decided to add a new custom question type ("File") into Certain Registration, so that she can manage even the file upload portion of the process within one system. Hopefully, many other customers and prospective customers will find this to be equally valuable.

    Monday, April 30, 2007

    Neat Technology

    I've spent a few hours recently with Maged Mohamed, CEO of TechNeat. They created an interesting twist on the barcode / mag stripe / RFID badge readers that are common in trade shows and larger events. TechNeat builds their products on top of the Blackberry wireless platform, so data captured on-site at an event is available online immediately. Compare that to the normal method of capturing data on a local network or hand-held device (or on paper, heaven forbid!) and you discover many advantages and some potential new applications.

    A Brief Background on Badge Readers

    If you've attended a trade show in the past 20 years, then you are familiar with badge readers. Attendees get a name badge printed with their name and a bar code, magnetic stripe, or (more recently) RFID chip. They walk around the show, look at exhibits, and if they find a product of interest then a sales rep scans their name badge with a hand-held or table-top device. Each scan tells the exhibiting company who you are, and after the show the exhibitors either print out your information or take a memory card to the services counter in order to download the data in an electronic format.

    Due to technology limitations, a name badge that is 3-4 inches wide can store about 20 characters with "1D" (one dimension) bar codes, about 225 characters (3 tracks with 76 characters each) with a magnetic stripe, 12 characters in an RFID chip, and practically any amount of data in a "2D" (two dimension) bar code (although the bar code will increase in size with the amount of data printed). Thus, except for with 2D bar codes, name badges usually only store a unique identifier for each person, and the full contact information is stored in a registration database with a link to that unique ID.

    1D Bar Code encoded in Code 128
    DataMatrix 2D barcode Name badge with embedded RFID chip

    TechNeat Products

    TechNeat supports all of these badge formats, but their products are scanners built upon the same wireless Blackberry devices that currently addict so many techies. When an exhibitor scans your badge at a show, your unique Id or contact information is immediately and securely transmitted via the Blackberry's wireless carrier to TechNeat's Internet servers. There, they record the details of the interaction (date-time, scanner id, etc.) and link the registrant's unique ID to their full contact information. Thus employees who are not at the show can sit at their browser anywhere (with an Internet connection) and watch the leads come in from their colleagues who are exhibiting. When the show ends, the exhibitors simply drop off their scanners and head home, which sure beats standing in line for an hour waiting to pick up a 3.5-inch floppy disk.

    Integration Opportunities

    While I'm a fan of Techneat, I don't get paid to sell their products, and so the chance to interact with their systems (and customers!) is most exciting to me. For example, registration workers at the front desk in a location without ethernet or Wifi Internet access could welcome attendees, scan their badge, and instantly transmit a signal to our registration database that the attendee has checked in for the show.

    Or, if you need to know who is going to each of your sessions at a large event, then you can put TechNeat's RFID scanners or floor-mounted bar code readers at the doors to your meeting rooms. As attendees walk through the door, the scanner reads their registration ID and transmits it and the scanner's ID to their online database. By connecting a scanner ID to a specific room and the registration ID to a person, we can record who went to each session and when they entered and left the session.

    Future Potential

    I love working with companies, like TechNeat, who find better ways to collect information at an event while we work on producing better ways to organize and manage that information before, during, and after the event.

    Friday, April 20, 2007

    3rd Annual Pharmaceutical Meeting Planners Forum

    I participated in a panel discussion on "The Future of Meetings Technology" at the Center for Business Intelligence (CBI) 3rd Annual Pharmaceutical Meeting Planners Forum on March 27, 2007 in Philadelphia. My co-panelists were Michael Boult (CEO of Starcite) and Rick Borovoy (CTO of nTag). Gaze with me into our crystal ball...

    Question 1. Why hasn’t the meetings industry adopted technology tools at the same rate as other industries?

    My perspective (since Internet tools became available in 1998) is that meeting professionals have adopted "public-facing" tools such as online registration, event web sites, email marketing, and web-based meetings (webinars) as quickly as other industries. They have not adopted "back-office" systems, however, at nearly the rate seen in other service departments such as Travel, Finance, Procurement.

    I think this adoption pattern has several causes:

    • The traditional event planner has been a "people-person" who loves to focus on the attendee experience rather than learn new technologies.

    • Available tools have not been both powerful enough and simple enough to meet most planners' needs.

    • Investment in and development of back-office tools for meetings has lagged that of Travel, Finance, and Procurement because there was not a critical mass of centralized corporate meeting departments and large meetings organizations willing to spend on IT at the same levels seen in the other areas. This situation is changing rapidly.

    Question 2. Is the current electronic RFP system working for hoteliers?

    Michael Boult took this question from the audience. His view is that current web-based RFP systems (such as Starcite's) are simply digitizing the existing RFP-based sales process. Some planners or companies may have abused this efficiency gain on their end by increasing the number of facilities who receive their RFPs (in hopes of driving costs down via competition), but most systems like Starcite have learned and now send an RFP to an average of 7-8 hotels (which are previously matched against the event criteria). This shouldn't create more burden on the hotels' sales offices than they had before the Internet.

    His question to the audience was why don't meeting planners move away from the RFP process and move to a "shop & transact" marketplace, for example, one similar to the manner with which you purchase plane tickets or shopping carts of books and electronics. None of the attendees had a good answer, but my perspective is that both sides of the industry are averse to such a marketplace being controlled by a single company, like Starcite, who would profit handsomely from transaction fees, while all of the suppliers would be forced into a cost-cutting mode that would commoditize the products (hotel services and meeting experiences) which the industry is determined to keep unique. I believe that such a marketplace built upon open standards such as APEX will have a niche in the future.

    Question 3. Why is integration so key to meeting management technology?

    Most meeting professionals realize that event management applications will not be primary data tools from the perspective of a large organization, relative to enterprise applications such as Customer Relationship Management (CRM), employee databases (HR), Finance, Procurement, and Corporate Travel. Thus meeting management applications will either have to work with these primary systems, or their users must continue to manually export/import and re-enter data from the primary systems.

    Question 4. How will Web 2.0, Second Life, etc. affect the way planners hold meetings (if at all)?

    Web 2.0 is vaguely defined as the "Internet of You" -personal web sites, Blogs, social networking, and online personas that in some cases are better known than your physical self.

    People often ask why video-conferencing isn't more widely used, after all, AT&T created the PicturePhone 40 years ago. Anyone who spends a few hours a day on webinars and conference calls knows that it isn't because the video quality is too low (it still is) but rather it's because we simply don't look as good as we think we do.

    Copyright The Economist - www.economist.comEnter Second Life - a virtual world where you create an online persona who interacts with others for you. I can see a future where you combine Internet telephony, instant messaging, webinars, and a realistic computer representation (at the quality of Pixar movies and video games) of yourself into a "Second Life" meeting room. This is being done on the fringes of technologists, but it could become mainstream. I would much rather have a moving representation of my best picture making a presentation in a webinar than to have an actual live video-conference picture of myself - and the technology is easier without the live feed anyway.

    Here is a great picture from the September 28, 2006 issue of The Economist, showing grandmother Donna Meyer and her Second Life avatar. Which would you rather watch presenting a seminar on punk rock music?

    Question 5. Do you any of you share the opinion that the use of technology in site selection and social networking (before and at meetings) affects the human interaction and will evolve or come full circle (driving more person-to-person interactions)?

    I think that the quality of the face-to-face meeting experience is going to increase. Otherwise, there is no point in spending the travel time and costs to leave your office, when you can have a basic meeting of minds via conference calls and webinars. As work teams become globally distributed and people have more choice about where they want to work, face-to-face meetings will be reserved for the most valuable personal interactions and experiences. I think the overall number of physical meetings will stay about the same, but the value (and cost) per person is going to grow in order to deliver this higher level of quality.

    Question 6. How do you see the APEX initiative entering planners’ everyday lives?

    I've spoken about APEX repeatedly, and I see it being the plumbing that makes the water flow. Meeting planners won't know what APEX really is until they see the technologies that come out of its implementation - the elimination of "Changes Reports" (because planners and hotels will keep their systems in synch electronically and automatically), an electronic marketplace of events and services (see Question 2), and event resumes stored as "e-books" on your PDA instead of 3-ring binders. When these things become commonplace, event planners will appreciate that the water is indeed flowing, even though most still won't care about the plumbing that got us there. And then, of course, after a few years they'll just expect that the water always flowed when you turned the faucet handle.

    Question 7. What are the "next big things" coming for meetings technology?

    • "One system for all meetings" - big conferences, small meetings, all different event types will be managed within a single system

    • Integration - behind the scenes your "single system", which works seamlessly for you, will be tightly integrated with many other systems both inside and outside of your organization

    • Simplicity - technology will just work, or you won't use it (we'll see...)

    • Migration from RFPs to "Shop & Transact" - at least for some products and services

    • "Web 2.0" - technology will customize your events to you

    • Social Networking - computers will aid person-to-person interactions and introductions, allowing you to collaborate locally and globally in an online community that is an extension of your physical one

    Thursday, April 19, 2007

    APEX TAC Monthly Meeting Minutes - April 2007

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

    APEX TAC Monthly Virtual Meeting

    Host: Rick Borry (Certain)
    Meeting number: 484 326 154
    Start Time: Thursday, April 19, 2007 07:56:04 PM(GMT 00:00)
    End Time: Thursday, April 19, 2007 08:43:47 PM(GMT 00:00)
    Meeting URL:

    Attendee List:
    Rick Borry (Certain)
    Sujal Shah (Starcite) - NEW
    Jeremy Keller (SiteVisit)
    Buck Downs (Columbia?) - NEW
    Jane Melville, Julie Graff & Marshalle King (Hilton) – NEW, replacing Bob Horn
    Scott Rudberg & Andrea Campbell (Passkey)
    David Collins (Syllogy Design) - NEW
    Kyle Bricker (Lenos) - NEW
    Rob Wilson (Meeting Sites Resources)
    Ali Tabatabai (Avectra) - NEW
    Rooji Sugathan (Ungerboeck)



      1. Meeting calendar available at:

      2. May 17th virtual 3rd Thursday at (4:00pm EST to 5:00pm)
        MEETING NUMBER: 484360851
        PASSWORD: APEX051707
        *** Please sign in with your name as “First Last (Company)” so that it’s easier to take attendance.

      3. The next face to face follows HITEC in Orlando. The TAC meeting will be held on June 27th and 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".

    2. STRATEGY REVIEW (from the Ft. Lauderdale meeting last month)

      1. See


    4. Take inventory of where the 4 groups are: ESG, FSO, Rooming List, RFP.

      1. OTA_HotelRFP_MeetingRQ.xsd

      2. Jeremy (LEADER) ~90% complete (need to merge Rob’s files and review)
        Rob, Junior
        Julie, Marshalle, Jane (Hilton)

      3. OTA_HotelRoomListRQ.xsd

      4. Michael (LEADER) - (Dave - Mike seems to be the best owner) ~70% complete?
        Dave, Scott, Andrea

      5. OTA_HotelEventRQ.xsd – ESG

      6. Rooji (LEADER) ~40% complete

      7. OTA_HotelEventRQ.xsd – FSO

      8. Jessica (LEADER)
        Chip, Bob (phasing out, to be replaced by new Hilton members after RFP is completed)

      9. Volunteers - David Collins (will join a group but wants to look at them first)


      1. The leader for each group should coordinate with EJ to schedule working meetings (~2h webex and conference call) with their team in order to complete the XSLTs before our next meeting (May 18th)

      2. Rich Mattes (Newmarket) can coordinate scheduling of working meetings if you need to use their Webex

      3. We need to drive these to completion by May so that we can try to get pilot implementation in someone’s database by the June meeting.

      4. Discuss common issues teams are facing and decide how to resolve them on the Forums at:

      5. Sujal (Starcite) said that they previously tried to implement APEX internally, but were not successful due to several reasons:

        • The sheer size of the XML message
        • They weren't sure where to map their database fields in the XML standard
        • The standard included a large number of fields that weren't useful to them
        • We hope to address these issues with our current project of producing validation and translation standards.

    6. NEXT MEETING (Virtual May 17th)

      1. Powershop beta demonstration (Chip Meyer)

      2. XSLT Demonstrations by working groups

      Tuesday, April 03, 2007

      APEX Implementation Pilot - Q1 2007 Update

      On March 21-22, an intrepid group of pioneers met in Ft. Lauderdale to figure out how the meetings and group travel industry will use this APEX stuff. Like all explorers, we discovered that the path before us will be easier than we thought it was before we started, but harder than we had hoped for.

      Time to Test the "Exchange" part of APEX

      As the name (Accepted Practices Exchange) says, APEX is about exchanging data between trading partners in the meetings and group travel industry. As described previously, last year we developed three XML specifications within the Open Travel Alliance to help event planners exchange data related to:
      • Request for Proposals (RFP) - meetings in search of a facility
      • Hotel Rooming Lists - attendees who need rooms in a group block
      • Event Specification Guide (ESG) - meeting information for the planner to share with the hotel

      This year, our goal is to implement pilot programs with specific industry partners who will use these XML standards to electronically transfer data from one proprietary system to another.

      The Plan

      First, our group (the APEX Technology Advisory Committee) reviewed our options and selected a strategy. We decided that each trading partner (meeting planners, CVBs, and hotels) would be responsible for creating their own "translator", or software routine that converts data from their proprietary database format into the standard APEX XML.

      Notice that the APEX standards do not specify the infrastructure surrounding the XML exchange. Eventually, we expect to provide guidelines about this infrastructure, which may consist of SOAP web services or https GET/POST methods. We expect the data exchange methods will require an authentication layer, in order to make sure the other application should have access to the requested data, and a version control layer, since the OTA standards are published twice a year and will undoubtedly undergo changes as the community learns from experience.

      Next, we agreed that we want to offer a human-readable version of the (machine-readable) XML documents. This will make the XML useful in situations where only one trading partner adheres to the APEX standards, and it should help developers validate their XML translators.

      For now, we decided to not tackle the Exhibitor versions of the Event Specification Guide (ESG) or Functional Setup Order (FSO), and we decided not to produce an XSLT standard for the "page layout" of the Rooming List standard, since this is legacy report format leftover from the days before Excel and e-mail.

      The Preparation

      Before starting a software development project, you should define how you will validate that the result meets your expectation. For APEX, we agreed upon a validation method for trading partners to test their translator routines that produce XML documents:
      • The XML must be well-formed. Any XML editor (or browsers like Internet Explorer) will tell you if the resulting XML document is formed correctly according to the W3C standards.
      • The XML must validate against the OTA XML schema (XSD). Good editors like XML Spy will compare XML documents to an XSD standard and instantly identify areas of non-compliance, e.g. if an email address is not in the correct format.
      • The XML must have data in the correct fields. Developers will be required to download the sample XML documents from OTA, enter the data into their application database, and then produce XML using their export translator. The resulting document should match the sample that you started with, otherwise, for example, you may be putting a person's first name into the last name field and not notice the error during the first two tests.
      The Path

      After discussing our past experiences with XML data transformation and exchange, the team selected the Altova MissionKit Enterprise Edition for the implementation process. (The enterprise edition is required because the OTA schemas are complex "nested" xml schemas, which aren't supported by the professional edition.)
      • XMLSpy - OTA uses this editor to produce the XML standards, and it offers simple validation of XML documents against XSD schemas.
      • StyleVision - We used this editor to produce XSLT files that map "machine-readable" XML documents into "human-readable" HTML or PDF formats.
      • MapForce - This tool will allow each trading partner to map their proprietary database fields to the XML Schema standard fields, which is the first step to building a "translator" for the APEX standards.

      The Journey

      Well, if only you could imagine how excited this bunch of computer geeks were after producing a Plan, Preparation, and Path on the first day. After dinner and a couple of drinks at the Irish pub that night, we actually thought we might knock this thing out on the second day. Unfortunately, reality set in after about 2 hours of struggling with Stylevision, but we created enough transformation tools to confirm that we are on the right path.

      The journey continues - contact us know if you want to join it.