Sonoma 2006 > Sonoma 2006 Planning

(Eugene 10/19): Some general thoughts on strategy can be found here.

(David 10/20): Eugene, thanks for your interest. There are (at least) two considerations that have gone into the technologies chosen for the ISSS site so far.

• (David 10/20): Relative low sophistication with computer technology – Although I personally spend 8 to 12 hours per day on my computer, this is far from the norm for most ISSS members. Within the past year, we've introduced interactivity to the web site, which has been a lot for members to swallow. Many of the questions that I get, in the role of webmaster, are at the level of e-mail and passwords. Although I understand the desire to have a plethora of tools, there's some questions as to whether some of these tools should be on the ISSS domain, or whether it's better to just link to them (in the ecology of the Internet).
• (David 10/20): Ongoing administration of membership and passwords – In the role of acting webmaster – and that's a role that I continue to look to give up! – I've been resisting designs that require administering passwords, or keeping a membership list online. Jennifer Wilby, in her role as VP of Administration, has traditionally been the central hub for the society, and we've gradually been unloading work from her. She still handles membership by hand, and has a PC database with all of the members on it. We have a Mailman list of “announce” with 900 names on it – everyone that is interested in anything about the ISSS including members, former members and non-members. (We actually don't have a membership mailing list, although I created a mailing list of Cancun 2005 registrants). I update the Mailman lists on requests from her. (I can actually run the full list onto the database, and duplicates fall out).

(David 10/20): With this background, in my role as a member of the Board of Directors, I would request that Debora put forth recommendations to the board on organizational issues, prior to implementing technical portions. This could include:

• (David 10/20): Appointment of a VP of Membership, with responsibility for online management of membership records. (I note that in the Bylaws, there's a role of VP of Membership and Conferences, but I'm sure that that's more than Gary Metcalf had signed up for. We should probably check with G.A. Swanson if there's a constitutional issue with splitting the role, but since we had conference co-chairs last year, I can't see why we shouldn't be able to split without issue).
• (David 10/20): Appointment of a Webmaster for the ISSS: I continue to want to relinquish this role, since I'm personally now VP of Communications and Systems Education, as well as chair of the SIG on Business Applications in Business and Industry. Since Sonoma 2006 is a California conference, maybe the probability of finding a qualified webmaster is better. This doesn't mean that I wouldn't still be on the web, but I could move more to content, and less on administration. In addition, I could continue to advise on architecture and technology issues. (The informal working group on this in 2003 and 2004 was Maurice Yolles, Jennifer Wilby and myself).

(David 10/20): With that long preamble, let me speak to Eugene's ideas.

(Eugene 10/19): We already have a Wiki and online forum set up for the conference. We should also have:

• (Eugene 10/19): Hallway for conference registration and social networking
  • (David 10/20): The process for conference registration needs to bring Jennifer Wilby on board. Prior methods have been prohibitively expensive. (The ISSS really does run on a shoestring, and volunteerism rather than sponsorship.) Jennifer has a legitimate concern about sustainability, and we need to ensure that the path we take forward is as robust as a single person manual process.
  • (David 10/20): Social networking online would be interesting innovation for the ISSS. In the Cancun discussion, someone (I think it was Len Troncale) mentioned that the ISSS is almost always the second professional society for its members, rather than the first. This means that social networking actually usually occurs in the primary professional society, and members have little energy for ongoing communications within the ISSS. Perhaps we should try a pilot on a “free” domain, and see how much interest we get. (Worse than not offering the function would be offering the function on the ISSS domain, and then not getting any activity).
• (Eugene 10/19): logged IRC channel for real-time chat throughout the conference
  • (David 10/20): My intuition tells me that this is probably a low priority for an ISSS sort of event. At ISSS meetings, I'm a standout as a person with a laptop computer. Most people come to the conference for face-to-face communications, and technology just gets in the way.
• (Eugene 10/19): a group blog, a blog aggregator (via PlanetPlanet?) or both
  • (David 10/20): I might be convinced on this, in the frame that blogs are slightly friendlier than wikis. The wiki is still pretty much an experiment for the ISSS. On the other hand, there's little that could be done on a blog that couldn't be done on a wiki. In addition, a wiki is a true collaborative environment, whereas a blog really is single person perspectives. Some of those functions are already handled using Phorum at ForumsISSS, which is currently under-used. I'm currently using Pivot on my family web site, and like that – but I'm the administrator for two active users!
• (Eugene 10/19): an online photo gallery. either Gallery or a commercial site, such as Flickr.
  • (David 10/20): I use Dalbum for personal photographs, and have been impressed by Qdig. (The former pre-indexes thumbnails, the latter does them on the fly). I'm mostly concerned with use of disk space, because people now shoot at 4 to 6 MegaPixels, which results in 1 MB to 2MB per photograph. Knowledgeable people would size these down to 72dpi photographs that take around 100 KB. Rather than just enabling large batches of photos, I would prefer to have them in context, i.e. embedding them in pages with captions and/or text around them. If people want to share personal photographs, perhaps linking to their sites is enough. (I actually don't want people linking to mine, because it's a personal server in my basement, and it's on dynamic DNS).

(Eugene 10/19): We should:

• (Eugene 10/19): Advertise the tools widely, both before and during the event
  • (David 10/20): Advertising isn't enough. We need people – I've called them web moderators – who will actually hand hold users through the tools. I had a 45 minute slot in the main tent at Cancun 2005 to introduce attendees to the ideas, and then two 90-minute “the doctor is in” sessions where individuals could walk up and ask questions one on one. We need some volunteers to do similar support, before, during and even after the event.
• (Eugene 10/19): Choose a tag for del.icio.us, Technorati, and Flickr tags. Most likely isss2006.
  • (David 10/20): The VP of Conferences and the Chair of the Local Organizing Committee need to come to an understanding about whether it's better to promote a single year event, or the ISSS conferences in general – in particular, the upcoming Tokyo 2006. We need to set an expectation either that (a) this is something that we could do in California that is leading edge, but not likely to be replicated in other conferences; or (b) that these are advances that we're making that attendees should expect to see at every ISSS event for the next five years!
• (Eugene 10/19): Aggressively encourage people to document the event proceedings on the Wiki. This is especially valuable in an OpenSpace? format, as the Wiki is a wonderful medium for report-backs, and it facilitates cross-fertilization.
  • (David 10/20): I support this, but again, we need web moderators for the less computer-literate.

(Eugene 10/19): One thing that really aids in the conference experience is SingleSignOn?. Done right, it not only enables you to use a single username and password across all of the different tools, it also enables you to interoperate with other tools easily, including those hosted on other sites. We can use IdentityCommons? technology to enable this.

• (David 10/20): I agree that Single Sign On is a good feature, but there have been two considerations on the multiple signons at this point:
  • (David 10/20): (a) most visitors to the ISSS site are readers only, so the number of passwords has been small. (Actually, it's only been two: one for ForumsISSS and one for ProjectsISSS. Implementing Single Sign On requires mucking around in PHP code in Phorum and in phpWebSite – something that I've resisted, due to effort required.
  • (David): (b) In system design, there's the bigger consideration of tight coupling versus loose coupling. In the current design, the sections of the web site are loosely coupled, so that if we get hacked in one place, the whole site isn't down. Single Sign On suggests a more tightly coupled design. Lookly deeply into the design, one would note that a full-function Content Management System – phpWebSite – has been reduced to use for only one function. This is not by accident, since the wiki and other features on that package are immature, at this point. I prefer loose coupling, at least for now.

(David 10/20): A side discussion that I've had with Maurice Yolles has been around whether we should replace phpWebSite with Open Journal System. (There's also a sister Open Conference System). We haven't actually discussed this deeply, because it requires some research, and it's a case of the devil you know versus the devil you don't.

(David 10/20): Another architectural standard that we've had, to date, is to use open source scripts written in PHP. Part of this is due to at least minimal support from the server's owner, Flemming Funch. Part of this is now the experience that I can customize the software without a large amount of training. (Remember this comment comes with someone working around computer systems since 1976!) We've been able to avoid alternative languages / scripts (e.g. Java, Python, Perl) so far.

Simon (11/12): We should use this forum to review available options to support online registration and/or electronic payment.

Current process: The current method is manual. Jennifer Wilby receives credit cards payments, and manually enters them onto Worldpay. One month later, she can somehow withdraw payments to the bank account. The cost of processing is about 10% of the amount (which includes an invoice fee, and presumably the usual credit card transaction fee of 3% to 5%). Jennifer gets this service through Pipex in the UK.
Simon (11/26): Many online payment options require setting up a merchant account, which would establish the ISSS as a credit card-accepting merchant. These come with a one-time setup fee, monthly/annual subscription fee, and per-transaction charges layered on top. The following providers, supported by aMember, don't require setup of a merchant account.
Potentially suitable payment options, supported by aMember:

**Paypal** - funds would accumulate in the Paypal account, for transfer to ISSS organizing committee bank account.
Email Payments

• Process: Create an invoice by entering your details on a simple online form on the Paypal website. Paypal automatically generates and emails your invoice to your customers. No advanced technical expertise is required. When your customers click the payment button in your email invoice, they are instantly transferred to secure payment pages on the Paypal website. Your customers make their payments on Paypal's secure website. They do not need a Paypal account to pay you. Paypal accepts, authorizes, and processes the payments instantaneously, allowing you to accept many payment types, including Visa, Mastercard, American Express, Discover, eCheck, and Paypal balance payments - all through one provider. Once the payment is successfully processed, the funds are deposited directly into your Paypal account and can be withdrawn or transferred to your bank account easily.
• Payment methods: Visa, Mastercard, American Express, Discover, Bank transfers, Paypal balance. No need for registrant to have Paypal account.
• Fees: No monthly fees, no setup fees, no cancellation fees. Transaction fees range from 1.9% to 2.9% + $0.30 USD.
• Comments:

Website Payments Standard

• Process: Your customers select items to purchase on your website. When they are ready to pay, they click a payment button. Customers are transferred to secure payment pages hosted by Paypal to make their payment. Next, your customers simply enter their payment information on the secure Paypal hosted pages that can be customized to match the look and feel of your website. Your customers do not need a Paypal account to pay you. When your customers pay, Paypal instantly routes the transaction through the major payment networks, allowing you to accept Visa, Mastercard, American Express, Discover, eCheck, and Paypal balance payments - all through one provider. Once the payment is successfully processed, the funds are deposited directly into your Paypal account and can be withdrawn or transferred to your bank account easily.
• Payment methods: Visa, Mastercard, American Express, Discover, Bank transfers, Paypal balance. No need for registrant to have Paypal account.
• Fees: Free use of Paypal's shopping cart (or use payment button instead of a cart - likely a fit for ISSS). No monthly fees, no setup fees, no cancellation fees. Transaction fees range from 1.9% to 2.9% + $0.30 USD.
• Comments:

**Beanstream**

• Process:
• Payment methods:
• Fees: $39 USD setup fee, $29 USD monthly fee, $0.55 transaction fee, 4.75% discount rate
• Comments:

**Moneybookers**

• Process:
• Payment methods:
• Fees: 2% (transfer must be covered by user balance or paid via offline bank transfer) Optional: 5% if transfer is debited from user's verified credit card or bank account (direct debit), or 8% if transfer is debited from user's unverified credit card or bank account (direct debit).
• Comments:

**NOCHEX**

• Process:
• Payment methods:
• Fees: 2.6% + 20p per transaction. No setup fee, no admin fee.
• Comments: Only accepts U.K. cards.

Standalone options:
**Acteva** - Acteva handles all credit card transactions and sends a check.

• Process: Appears to be driven through an Acteva-hosted but private-labellable webpage, linked to Acteva's payment processing and event management suites.
• Payment methods: VISA, Mastercard, American Express, Discover, checks (through Acteva Multipay), purchase orders (through Acteva Multipay).
• Fees: Not given on website.
• Comments: Acteva offers a wide set of event management tools (Active Pages for event registration, data collection and payment handling; Eventmail for mailings to attendee list; and tools for automatic discounting, waitlists, e-mail ticketing, and phone/fax registration. Upcoming live product demonstrations would be worthwhile to look at.