"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!