dominoGuru.com
Your Development & Design Resource
Public Build: Event Calendar
12/29/2008 03:17 PM by Chris Toohey
In this post - the first in an ongoing series of Public Build projects - I plan to discuss the first steps when starting a project, followed by additional posts, screencasts, and other publishings specific to this particular build project.
About this Project
A customer of mine was in dire need of a simple events calendar to facilitate their corporate training endeavors. This simple events calendar, which we'll call Events Calendar (or EC for short), will consist of event coordination through the native Lotus Notes client, review and "reservations" via a web browser client (Internet Explorer 6+ in this particular case, but we'll write for everything), and simple integration with a shared mail database and calendar that will handle all of the actual Calendaring & Scheduling work.
This project - at least phase 1 - is due by 12/31/2008, and counts against my project champion's year-end reviews.
Getting Started
You went for the Domino Designer client didn't you?! Tsk tsk tsk -- we're not going to touch the Designer client until we're actually ready to code something. And with (... checking Calendar) less than 3 days until this application needs to go live, the last thing that we need to do is get stuck in the building phase before we've confirmed the functional requirements for our build project.
Those of you who have checked out YellowCast may be familiar with the term Napkin Development. Those of you who haven't (for shame!) or would like a recap, Napkin Development is the simple practice of blueprinting the application outside of the code, through a combination of workflow diagrams, ~pseudocoding, and - when the need arises - jotting something down on a napkin!
This may seem an inconvenience, but consider this:
- This allows you to easily confirm that you understand what the customer wants (and that they understand what they're asking of you) -- which greatly decreases scope creep.
- ... and since I hate to document things, you can use the majority of the blueprinting as a jumpstart to the documentation of the project!
So, let's start by talking a little bit more about the build project itself:
- 3 User Types: Event Admin : Attendee : Coordinator
- 2 Client Types: Lotus Notes : Web Browser
- An Event Admin will create an event entry in the EC via Lotus Notes, Attendees across the organization will create a reservation entry for a given event via their Web Browser, and the Coordinator will use the reservation data to create emails, and invite the Attendees to a scheduled Meeting through a pre-existing established Group Mail Database.
That's pretty much it for phase 1 on this project. The architecture-minded will immediately consider creating a simple Parent-Child data hierarchy with the Event and Reservation entries respectively, which is exactly what I plan on doing.
For those of you who are more visually-minded (like me), here is a simple architecture diagram of how we'll design EC:
Data
Now that we have a rough idea of what the application will do, as well as the "main players", we're going to deep dive into what each type of NotesDocument in our NotesDatabase will contain from a data perspective.
As we've established, there will be two types of NotesDocuments: Events and Reservations. Each of these NotesDocuments will contain both functional and data storage NotesItems, and we'll take a few moments to outline the ones that we know we'll need now:
Event|event
NotesItem | Usage |
title | Simple 1-line identifier for the event. |
description | Multi-line descriptive identifier for the event. |
date_start | Starting Date for the event. |
time_start | Starting Time for the event. |
date_end | Ending Date for the event. |
time_end | Ending Time for the event. |
location | Location/venue for the event. |
categories | Optional categorization option for the events. |
subject | Computed - special NotesItem name used for bookmark mouseover text. |
Reservation|reservation
NotesItem | Usage |
$ref | Created automatically, stores the Event NotesDocument UNID. |
username | Computed, using the user's runtime evaluation of @UserName |
And that's really - the Event Admin will create an event NotesDocument, entering in the Title, Description, date and times of the event, it's location, and any categorization they choose. Pretty simple. The reservation is simply a username-stamped Response NotesDocument to the event NotesDocument.
The real work is going to be the visual representation of the events on the web browser client, with the ability to click and create a reservation. That, we'll cover in the next post - where we should be finished with the blueprinting of the application and move onto planning which particular technologies we will employ to deliver our Events Calendar!