Projects - Working Goals for June

The unifying technical element is shared data-storage mechanisms. They are kept limited by policy and design to encourage separate work (not yet staffed) on a non-EJB tier 2 (data transport) layer, which is planned so far only to this extent:

Help from other working groups and/or XML gurus may be sought on this final phase of work. Meanwhile, here are deliverables from initial efforts, which will simply use output-page templates cast in standard HTML.

This task - previously unstaffed - will be done jointly and ASAP by the Web Apps and JugSite WGs, aided be anyone else who wants to chime in. It shows how a simple log of immutable comments ("news") can advance high-level goals, and takes only two new web pages. The first is under /projects; the second under /jug:

1. Form-based News entry - Captures an ID of the USER entering data, a brief textual comment, and the ID of a GROUP most connected to its topic(s). The USER must also supply a password for that GROUP, or an error occurs when the form posts. Otherwise, its data is saved with a timestamp, and the second page is displayed.
2. Recent News Reporting - This shows an ordered list of prior comments, most recent first, filtered by GROUP and "age" limits (if any are passed). A small local form lets the end user (here unrestriced) add or adjust these limits and redisplay, to explore JugNews for any or all GROUPs.

This web app helps keep MaineJug informed on working GROUPS, especially news on Projects or Tasks too localized and frequent to be broadcast in MaineJUG emails. It lets GROUP leaders report WG progress in batches, exposes WG decisions to a wider audience, and in general makes our web site more interesting and lively. If JugNews text holds links to new or changed pages, it also adds new ways to find them.

Technically, the simple logging aids used for this application are adequate because JugNews postings never need later editing. In design pattern lingo, like many other textual declarations posted on the web and equally easy to support, they are immutable.

To aid similar web apps, the generic "Log" Java Bean supporting JugNews will be posted with June deliverables. It implements a simple but general read/write API to a backend text file. The Bean itself is insensitive to the specific Strings being logged, so it can be reused in many related "registration" tasks, which all let a USER sign up on-line for some meeting, project, task, event, etc.

For example, as a browsing USER discovers what MEETINGs and GROUPs (or projects, or events) are available, a [SIGN ME UP] button on related pages lets him or her register. If the USER ID is part of the session, due to an earlier login, this can happen with a single click. A sexy feature I'd like to see is that if a USER is already signed up, the button says [YOU'RE REGISTERED].

Additional "backend" pages also must let some administrator(s) - Joe and/or a related GROUP's leader - review the associated logs of registrations for recent changes, and/or migrate any new information they hold into some desired independent data store(s).

Each of these "mini-applications" roughly repeats the JugNews pattern. Each will therefore be implemented partly by reusing its machinery. However, many details need designing first, and before that can be done, conceptual plans and page architectures must exist. Overall, several unknown things cry out for design attention:

• Use Cases - Who benefits from on-line registrations? Do forms beat emails? What would be done with the info gathered? By whom? When? How?
• Scalability - What changes as USERS grow past 100? Or 1,000? Can we handle 500 distinct GROUPS? 5,000? Could it grow 10:1 more? 100:1?
• Attributes - Besides log-based associations, what fields do we want for each USER, GROUP, or MEETING. Whhy? Which fields can mutate?
• Subclasses - Some record types have them - e.g., is a SIG the parent of user GROUP and working GROUP? How do these differ and relate?

Overall, such formal modeling efforts seem needed soon to clarify the type of on-line communities envisioned, the specific web utilities that will help them grow, and the specific attributes that would support them. Unless we want to learn these AFTER we've built the wrong designs, now seems a good time to take these key steps, then solicit feedback on them from MESDA's board and member firms.

• GROUPs for Web Site, Web Apps and EJB WGs, plus JUG management
• PROJECTs for JugSite, Registry, Surveys, and JugNews.

Each GROUP or PROJECT leader initially gets a USER record citing an ID, plus email address and names as noted in Yahoo. This is Dave, Dan, Donna, Jason, Craig (as mgr-admins), and I added Joe as a key client. Later, we'll add an open page to self-register new USERS, so everyone can get involved.

Mgr-admins each also get (from me) training and a password letting them temporarily add/edit new USERS, GROUPS, MEETINGS and PROJECTS as desired. All mgr-admins have the same access (if they ever choose to look). Security is pretty lax.

They will also be able to (re)define a password needed to post GROUP or PROJECT JugNews, then pass it along verbally to other USERS in their teams. (These are mostly to keep random site visitors from posting nasty messages.)

Example MEETINGs are being built for the 3 Wed. night lectures we've had so far. An HTML template to present them at need should be straightforward to build. They'd might let us replace the static "Last" and "Next" meeting pages with a Bean that "shifts" next to last automatically during each JUG meeting (just to prove we can automate JugSite maintenance).

Example PROJECTS are mostly for the Web Apps team, to explore uses in project management and aid early planning/demos on Showcase. As I see it, people who register for a PROJECT do so to request emails on its JugNews. To request work, make suggestions, or get a password to add JugNews, they email its project leader.

As these record sets fall into place, all code and ideas above can be tested, and both adjusted as feedback dictates. If you have suggestions or questions on anything in advance of such testing, RSVP. Thanks.