ShowCase is a user group for booth administrators, which aids in their training and helps coordinate periodic "events".  The first of these to be announced is the opening of the Trade Show site itself, which happens in three stages:

• 10/31 - we open it to MESDA's other SIGs, who get emailed UIDs
• 11/31 - we open it to the full MEMBER base, via a final page B.1
• 12/31 - we open it to the public, after each MEMBER gets a booth

1. MEETING listing page - cites description pages for all/USER's/rest
2. MEETING description page - with bi-modal [(DE)REGISTER] button
3. GROUP listing page - cites description pages for all/USER's/rest
4. GROUP description page - with bi-modal [(DE)REGISTER] button
5. PROJECT listing page - cites description pages for all/USER's/rest
6. PROJECT description page - with bi-modal [(DE)REGISTER] button
7. Registered USER page - secure (see below) extension of descriptions
8. Registrations page? - secure for each USER (see below) extending B.1
9. New B.4 promotions - offer to MEMBERS all the above (see below)

On C.7: Each SIG "description" page (for which USERS can REGISTER) needs an optional link to C.7, showing an associated Log of (de)registered USERs.  Both it and the link display only for USERS flagged (via B.3) as "viewer" of the depot. The LogAPI tag which handles Log listings is reused here (perhaps expanded so that any USER who is registered for the same SIG can also use it  to find other USERS who are registered.  This is a free option, data adjustable for individual SIGs.
 

We must design for a fast growing set of SIGS, as each option likely needs its own  GROUP and PROJECT.  In addition, we expect many private SIGs, built by and for specific MEMBERS.  To cope with all this growth, USERS will need special help.

On C.8: Each USER may get a new associated Log of "registrations" on his private page(s), which may include MEMBERS.  (These are not options, but design choices not yet resolved.)  Only the USER would see what he is signed up for, except for admin staff at MESDA.  Either may then [DEREGISTER] the USER for a SIG right on the page.   This logic interacts with that supporting the LogAPI tag.

On C.9: Everyone will want all reference pages on options to be well organized and semi-standard.  New sales pages by MESDA should tout all the above as working demos of tags and templates, which each MEMBER can "try, then buy" for his own booth.  The related SIG pages on each option should thus have a repeatable, well planned structure, easy to navigate as the number of options expands.

This will help buyers.of the options, users, and prospects.  The R&D teams busy creating new options will win, as well as the staff doing sales and training.  For each release, there is a lot of detail to communicate.  It needs to be planned.

The general rule will be a written option design as early as possible.  A pre-release to Q/A 15 days in advance of beta follows, with draft usage documents.  They and their code are then compared by Q/A, while final usage and sales doc is being prepared for public release.  Bugs may force changes to documents.  Training SIGs should not only help enforce this structure and workflow, but help us expand and refine it.

Optional services, depots and SIGs can be a huge money-maker for MESDA.  Even if a MEMBER might normally not add such dynamic features to his own website, he may sign up for them on a Boothnet site, as here they are cheap and easy, and SIGs aiding the USER-community of their purchasers will be readily apparent.   And since his own corporate web site stays untouched, the risks on "trying out" these options is really pretty low - just the admin time needed for training and set-up.

That option cost is typically far more than the sales price.  The efforts outlined above must try to minimize admin time, to help maximize their net benefit/cost ratios.