"Easy to use" versus Intuitive

When people first inquire about our online registration system, they ask two things: "How much does it cost?" and "Is it easy to use?" At that stage, I have to answer "such and such $$$ per registration" and "yes", because if I took the time to explain why these are the wrong questions to ask, then the prospect would think that I'm waffling. I might as well say, "I'm going to take more money from you than the IRS and in return give you something that is slightly more complicated than your Tax Return in a year when you got married, sold a house, bought another house, closed an S Corporation, and merged 3 kids into a Brady Bunch family (welcome to my tax year). But if only I had time to tell them this...

"Easy to Use" and "Flexible"

What prospects are saying is, "Is this software easy for me to use for my current job tasks, with my specific event planning experience and level of comfort with web-based software." Well, the truth is that some users are so uncomfortable with Internet applications, or even the computer in general, that they will never think an application is "easy". For these people we show what our application can do for them and their customers, and then we offer our "full service" option, where our in-house experts build the client's registration forms, web sites, and reports for them. Presto! - it's easy to use because you don't have to use it at all!

But most of our prospects want to "do it themselves", either to save money or because that is part of their job description, and, well, they like getting a paycheck every month. The challenge for a software designer (like me) is to create software that is both "easy to use" and that can actually do what you need it to. On top of that, it must meet these criteria for a wide audience of paying customers, otherwise the cost of the software would be more than most individuals or companies could bear.

It would be easy to build an application that has a step-by-step wizard that guides a person through the exact process that they follow with their events. This would be "easy to use", that is, until another person tried to use it, and then "whoa! what about discount codes for multiple attendees from the same company - how do I do that?". Then the manager needs to oversee all of her staff and allocate resources appropriately and monitor budgets - but without getting in the way of the employees doing the work. Next the executives take the business in a new direction or merge with another company, and suddenly the processes that have worked for six years need to be changed to meet this new reality.

Okay, so what the prospect really wants is "easy to use" and "flexible". So we design a wizard that asks questions about what you need for this event - Fees or Free? Breakout Sessions? CEUs? Guests? Hotel Rooms? Air Travel? - but this can go on and on until the user becomes annoyed having to constantly tell the system what they do and don't do with each event. So we give you templates, so you don't have to answer these questions with each repeat event; you only answer them with the new events. This struggle between easy and flexible goes on and on, and is in the forefront of our software design.

"Easy to Use" and "Intuitive"

"Intuitive" is a better goal to keep in mind when designing software. Can the user approach the application (without training or assumption of skill levels) and intuitively know how to approach the application, and where to start in order to get their immediate task accomplished? People don't actually expect software to do their job for them, they just want it to help them do their job that much faster. Don't make me answer questions about what I want to do - I know what I want to do, just help me do it.

Concepts in Practice

The concept of "Intuitive" has been in the front of my mind lately because we are currently re-designing the Register123 user interface. We are working with Bruce Browne, a software design expert who previously worked with Apple and Intuit on the Quicken application.

First, I have a week off to spend the Holidays with my family in the Colorado snow, but starting next year I'm going to discuss the design process that we've used in order to improve our software, and hopefully achieve the elusive goal of "easy to use".

Merry Christmas and Happy Holidays to you and your family.

Early adoptors aim to implement APEX standards

This week marks my one-year anniversary of joining the APEX Technology Advisory Committee (TAC). During this period, my company donated close to $50,000 in time and travel expenses towards the meeting industry's efforts to create XML standards for electronic data exchange. This investment was made on faith in the APEX goals, but I'll need to show a return on this investment by the time I reach my second-year anniversary. Here's how I plan to do that...

APEX Strategy

As I've described in many posts this year, APEX focussed its efforts in 2006 on creating XML standards through the Open Travel Alliance. We produced 3 schemas:

• Single Facility Event RFP
• Housing Rooming List
• Event Specification Guide

Now that we have completed the XML framework, we decided to focus efforts in 2007 on implementation of the APEX XML standards in real-world applications. Our intention is to show the industry how they can use these standards to make their lives easier. Once we have proven this, we expect to get a flood of new "converts" to the APEX religion.

If development goes as planned, the MPI World Education Congress in Montreal on July 28-31, 2007 will be our big "coming-out" party. EJ Siwek (the APEX TAC chair) plans to host at least five 90-minute sessions in order to educate meeting professionals in attendance about the implementation of APEX standards within Certain Registration and other meeting planning software applications.

Implementation Plans

The current implementation phase is when the hard-core developers come out and do their stuff. While companies are free to implement APEX XML standards any way they please, I expect most organizations will build a "translator" interface between their proprietary database and the APEX standards. The process will look something like this:

The beauty of XML is that each company will only have to build the translator between their database application and the APEX/OTA standard. Data exchnage will use existing standards (e.g., SOAP / HTTP) that all web-based applications can readily accommodate, and standard processes (e.g., XSLT) exist for converting XML into document-based reports.

How to get involved

If you want to get involved in the implementation phase, then you (or someone who can read XML) need to do the following:

• Join the APEX TAC at our web site (http://apex.dataapp.com). Here you can download our calendar of meetings and add yourself to the notification email list.
• Download the current XML standards (OTA 2006B) from the OpenTravel Alliance. This download contains hundreds of files, of which only a few apply to the APEX initiative for group travel / meeting planners:
• OTA_MessageUsersGuide2006BV1.0.pdf - The "Message Users Guide" contains a high-level description of each OTA Message with sample use cases and XML instance documents.
• \_OTA_CodeTable\OTA_CodeTable20061211.xls - The code table contains the text descriptors for OTA standard codes used in the XML messages. For example, the "Event Type" code 11 means "Sales Meeting"
• \_OTA2006B_XML\OTA_HotelEventRQ.xsd - The XML schema for the Event Specification Guide (RQ is used for "Request" and RS is "Response")
• \_OTA2006B_XML\OTA_HotelRFP_MeetingRQ.xsd - The XML schema for the Event RFP
• \_OTA2006B_XML\OTA_HotelRoomListRQ.xsd - The XML schema for the Housing Rooming List
• Download the latest version of the APEX standard reports in document format. These are available in the APEX Toolkit, or online at the APEX web site.
• Get a copy of the APEX workbook from the TAC web site. The workbook is produced by APEX's "doc tool", and contains a translation from each field in the Word-document versions of the APEX reports and their corresponding elements in the APEX/OTA XML schemas.

In addition, I recommend getting a good XML editor - I used the Altova XMLSpy 2006 Professional Edition to help write the standards.

Behind the Scenes: Setting Up and Managing a Blog

Well, I've been practicing this Blog thing for a few months now and I've decided to roll it out to the public. It was easier than I thought it would be to set up a Blog, but harder than I thought to manage an email subscription list.

Setting up a Blog

This part was easy. I choose Blogger (a Google subsidiary), because I had heard of it before and it only took me five minutes to get started. I wasn't frustrated enough to try anything else, but I've heard that Yahoo! has a pretty good blog engine now. I spent a half-day customizing the template so that I could set up the side bar you see on this page, but besides that the only time I spend on this Blog is the time it takes me to write the posts.

Managing a Subscriber Base

I thought that I could use Blogger to manage a subscriber database, but that turned out not to work. I want people to be able to subscribe or unsubscribe to my Blog so that I can notify them via email each time I make a new post.

After a little research, I found a free web-based subscription database management tool called Mach5 Subscriber. It's limited to 5,000 contacts, but when I have more readers than that then I'll be willing to upgrade to the paid version. In a few minutes I set up an account, selected the data that I want to collect from my audience, and Subscriber instantly created both a subscription signup page and a subscription management page. I then added these hyperlinks to my Blog so that readers can subscribe and unsubscribe from my email list.

Sending Notification Emails

The next step was to find a tool to let me send bulk email to my subscriber list. Mach5 has another product for this purpose, Mach5 Mailer, which is also free up to 50 emails at a time. This is a Windows-based application that integrates with Subscriber in order to allow users to send personal, customized emails to your subscription list. It sends both HTML and text versions, and can contain hyperlinks to your Mach5 Subscriber pages for your audience to manage their subscription.

The last hurdle was to find an email server that I could use to send the notification emails. Outgoing email requires a SMTP (Simple Mail Transfer Protocol) server. Fortunately, Greg Paik, the Director of Network Engineering at Certain, allowed me to use our Exchange server for the small scale of my current subscription database. Our SMTP Server requires me to connect to our VPN first in order to prevent unauthorized users from relaying spam through our network, but this isn't a big deal from my laptop, even when I'm on the road. When I outgrow the scale of Mach5's free tools, then I'll need to find another option for mail delivery. (Mach5 is working on a product called Mailer Express that will hopefully do this.)

Putting It All Together

Now I have the Blog, subscription database, bulk mail merge application, and outgoing email server. Each time I post to the blog, I'll send an email to the current subscriber list with the first paragraph and a hyperlink to the full posting. If you want to add or remove yourself from the subscription list, it's as easy as clicking on the hyperlinks in the email or on the left column of this page. And I hope that readers will send me topics that they would like me to discuss, and forward the subscription emails to their friends and colleagues.

Let the experiment begin!

On-Site Registration at the 79th Annual National FFA Convention

Bob Osborn, Brett Weigl, and I were on-site with the FFA at their National Convention from October 23-26 in Indianapolis. With over 50,000 attendees, this was the largest convention to date that used Register123 for on-site registration.

Pre-Registration
FFA closed pre-registration on October 11, two weeks prior to the event. After that, attendees had to register on-site. For an event of this size, these two weeks allowed the FFA staff to complete on-site preparations without a constant flux of registrations and cancellations.

On-Site
We flew into Indianapolis on Monday so that we could set up the Internet connections and confirm the system configuration. For the on-site event, we created special registration forms that focussed on rapid data entry rather than custom branding.

On-site registrants started at the information desk. This area helped attendees determine if they needed to enter the registration line, if they needed to walk to the "Issues Desk", or if they simply needed to have name badges printed for exhibitors.






Attendees who entered the Registration queue saw the event agenda twice. Sessions that had sold out were posted clearly so that people wouldn't try to buy tickets for unavailable sessions at the counter.






Notice that only 1 row of the 5 set up in the queue was full. Lines and wait times were reduced by about 75% compared to 2005, mainly because so many more attendees participated in the new online registration process. People who did want to register on-site completed a paper form while in the registration line, so that they would be ready to purchase tickets when their turn came up.





FFA set up 6 registration stations with 2 workers per station. Around the corner to the left is the "Issues Desk", which served people who lost tickets or needed to change their pre-registration order. Because of the higher proportion of pre-registrations this year, the "Issues Desk" line was longer than in past years.





Behind the counter, registration desk workers used the new "Admin-side Forms" in Register123 to quickly process on-site registrations, collect payment, and print out confirmations and receipts. FFA receives a large number of P.O., check, and cash payments on-site, although the percentage of credit card payments increased this year.





After the front line workers entered the registration data, the system sent a "Pick Plan" to the back office workers. These employees selected the purchased tickets, bundled them with the registration materials, and met the attendee at the end of the registration desk. All transactions were monitored by FFA's registration manager (Sheridan Gilchrist) from a second-row PC station.





Meanwhile, I sat in the back-office at another monitoring station. Here I looked for issues and created special reports for FFA. This year was something of a learning experience for us, and these reports will become part of the standard features in Register123 for next years' events.






Overall, the on-site registration process went very smoothly. We lost Internet access on the first day for a few minutes, which was quickly addressed by the convention services. Now that Internet access is approaching the reliability of electricity in modern convention centers, the major problem with using an online registration system on-site is being eliminated.

Lessons Learned
In 2007, we plan to reduce the number of manned registration stations from 6 to 4, and to add 2 "Self-serve registration kiosks". These kiosks will allow people to register themselves on-site via Register123, as long as they are paying by credit card. One FFA worker will "float" between the two self-serve kiosks, in order to help attendees who have trouble. This process should work much like the self-service check-in stations at airports.

Also, we will likely add a second "Issues Counter", in order to handle the increased number of pre-registrants who need to make changes to their registrations on-site.

Lastly, we will modify the on-site name badge printing form in order to reduce the number of steps required to print a name badge. Thanks to Register123's flexibility, these process changes can be configured without any software development.

On the front lines at the 79th Annual National FFA Convention in Indianapolis

Nearly two years ago, Certain won the contract to handle online registration for all events sponsored by the National FFA Organization.

Background

The FFA (formerly called the "Future Farmers of America") is a national association of state FFA chapters. They hired Jeff Rasco and Rod Marymor of Tech3 Partners to mangage their selection of an Online Convention Registration (OCR) application. Tech3 worked with FFA to determine their key needs and to deliver a detailed RFP to all major online event registration vendors. Certain was one of four finalists selected to present to the FFA operations committee at their headquarters, and in March 2005 we signed a multi-year contract.

Time to Deliver

Now, 18 months later, the 79th National FFA Convention begins today at the RCA Dome and convention center in Indianapolis. After a pilot test at last year's convention in Louisville, the implementation team from Certain (Bob Osborn, Sr. Account Manager, Brett Weigl, Director of Client Services, and I) was ready to handle FFA's somewhat unique online registration requirements. These include:

Registration

• The National FFA Convention will have around 50,000 attendees, separated into about 50 groups such such as exhibitors, members, alumni, advisors, parents, staff, press, speakers, judges, etc. FFA used Register123's unlimited registration categories to manage these groups.
• With 50,000 attendees, the FFA had to schedule three Opening Sessions of ~15,000 - 18,000 each in the RCA Dome. They wanted to limit the total number of tickets selected for any of the three Opening Sessions to be equal to or less than the total number of registrations purchased. (Apparently, in past years some advisors took advantage of an older registration system by splitting their groups into multiple Opening Sessions and getting more "free" opening session tickets than the number of registrations they purchased.) FFA used Register123 Packages and Form Logic in order to enforce this complex business requirement.
• FFA has an existing Web Site with state chapter login, which is integrated with their PeopleSoft CRM database. They used Register123 Form Integration features to seamlessly pass state chapter information from their web site intranet to the registration form when each registrant clicked on the "Register" hyperlink.

Ticket Management

• State chapter advisors register multiple student attendees at once, and FFA only collects the contact information for the advisors. FFA used Register123's unlimited Program Module in order to enter more than 175 sessions, tours, concerts, parking passes, etc., where advisors purchased 1-100 tickets at a time for each item.
• FFA delivers paper tickets and purchased items to all pre-registered attendees. They used Register123 Personal Documents to create a custom "Pick Plan", which their warehouse technicians used to prepare indivudal packets and ship via UPS.
• FFA also used Register123 Web Integration Links to integrate with the UPS Worldship application, so that employees or attendees could use their Registration Code to track their package shipment on the UPS web site with a single click.

Financials

• The National FFA Convention must cover its expenses through registration fees and additional fees for tours and concerts. FFA processed over a million dollars via Register123's Financial Module using integrated credit card processing and check/P.O. payments.
• FFA uses Peoplesoft Financials and CRM application as their association management solution. Their IT team used Register123's Budget Module to store the PeopleSoft General Ledger Account Numbers with each fee, and Register123 Custom Reports to create batch files with payment and fee information. The reports were customized with the column headers and tab-delimited text format required by FFA's automatic nightly import into Peoplesoft.

Housing

• The FFA worked with the Indianapolis Convention & Visitors Association (ICVA) to contract rooms with nearly every hotel in Indianapolis (162 hotels with 12,000 peak room nights and over 30,000 total room nights). The ICVA used Passkey to manage the city-wide housing reservations for FFA. Register123 integrates with Passkey to provide a seamless registration system for attendees.
• In order to meet their hotel commitments, the FFA offered discounted registration ($30 vs. $40 per person) for attendees who book inside their room block. Because students often stay four or five per room, the FFA wanted to allow only up to 5 discounted registrations per room reservation processed within the block. FFA used Register123's "Packages" feature of the Program Module and "Form Logic" feature in order to enforce these business requirements on their attendees.

On-Site Registration

• About 10,000 attendees and advisors register on-site, and many pay with cash or pre-printed checks drawn on purchase orders. FFA used Register123's on-site registration features to create simple "Admin-side forms" that registration desk temp workers were able to learn and use after less than 10 minutes of training.
• FFA used Register123's "split payments" and "cash payments" features in order to process multiple payments against a single order, to accept cash on-site, and to calculate change. Register123 payments reports tracked cash receipts per registration desk worker (with an audit trail based on user name and date-time posted) in order to maintain cash security on-site. (The six foot - six inch off-duty police officer helped this situation, I think.)

I'll post more information (and pictures) tomorrow showing all of this in action from behind the on-site registration desk.