WAI WEB SITE DESIGN

"The good can be the enemy of the best." — Bill W

Overview

Worcester Area Intergroup's (WAI's) web site consists of:

Templates are used to format HTML web pages built by ASP.NET and C# functionality. Responsee (cascading stylesheets + JavaScript libraries, from M.I.T.) provides responsive layouts for desktop, tablet and mobile devices. JavaScript is also used for other browser (client-side) functions. Canned ASP.NET pages & content can be updated or supplemented with user content or pages.

Site elements, page content, and configuration setings are stored in SQL databases, and in user files:

The website runs under Microsoft Windows, uses SQL databases and user files for site content, and relies on 3rd party software for payment processing, SMTP & SMS messaging, online forms, an events calendar and maps/GPS navigation. Meeting Guide App connectivity is via a JSON text file of extracted WAI meeting data.

The website is designed for (and is itself the result of) cloning, using root database entries, .NET pages, and canned content. Cloning entails copying root objects and default site settings which, when combined with .NET pages and site-specific settings, content, and a registered domain, results in a website. (Note: domain registration, hosting, SMTP setup may also be needed; for co-hosted clones, see also: Cloning Design).

Design Goals

Design goals for this web site include:

Site Access | Menus | Pages

Website access is at three levels, for three groups:

A site can have unlimited public users, 1+ admins and 0+ members, as defined by group conscience.

Navigation menus and pages are level-specific:

When a member or admin logs out, site access, menus, and content revert to PUBLIC.

For any cloned site, member accounts can only be created by admins, i.e., the webmaster, Web Chair, or a trusted servant. New admin accounts can only be created by an existing admin user.

Members can access public and member pages, and admins can access "admin" pages. Each AA group chooses which pages to have on its site. Public pages, when accessed by a member, may have added capabilities or content; e.g., a calendar may permit members to make updates or see member-only content. Providing members with choices, access, and information, while protecting them and the site, is a primary design feature.

Examples of Public pages:

Examples of Public+Member Pages:

Examples of Member-Only pages:

Examples of Admin pages:

Member accounts require no personal information, even an email address is optional. A shared login ("gsr", "dcm", "advisor") may be used for groups, or a login can be for one person.

Site Elements

Virtually all site elements — logo, splash image, menus, pages -- are database-driven. Page or content changes are made by updating the database or a user-supplied file (via an admin page of the site itself).

Resources — documents, images, links, site content - can be uploaded by any member, if so desired. Or, a site can allow uploads but require a trusted servant (admin) to review and "activate" it. Or, a site can have only admins update site content.

Groups & Roles (committees, secretary, GSR, etc) — can be defined and assigned/reassigned to member(s). Content (PDFs, images, etc) may be uploaded and publically shared or restricted to a group or role. Groups and roles support AA principles (service rotation, delegated authority, autonomy, anonymity, group conscience). Members control their personal data and visibility via a member profile. Members (will) control email from the site by opting in/out of emails or SMS "alerts" (alerts are intended mainly for admin notification).

Admins — trusted servants who maintain the web site — have complete access to all site content except private member data; private member data is encrypted and accessible (in encrypted form) to admins and web hosting tech support only. Note: admins may not have access to the ISP hosting account items (account files, databases, email & FTP setup) in a shared hosting setup.

Site Types

A design goal is to create (or clone) web sites that reflect each groups' primary purpose and group conscience. AA entity types (districts, areas, intergroup, committees, etc) each have distinct needs. The software design ideally supports AA service entities with a web site (or clone) to suit those needs as determined by its group conscience.

Design Constraints

Language translation (e.g. Spanish, French, Portuguese) relies on the client/browser funtionality, no server-side (or package) support is provided.

As noted above, ASP.NET relies on a Microsoft Windows runtime enviroment, and this design relies on Microsoft SQL Server for database functions, both of which >could< be replaced by other runtime enviroments (Linux/Apache), databases (MySQL, Oracle, etc). This .NET design uses C#, but other programming languages (PHP, Python, JAVA, etc) could be used.

This implementation also relies on SMTP (Simple Mail Transfer Protocol) for basic email services such as error reporting and system or user notifications.


Web Servant & Fellowship Friend

###