Creating an Appointment Calendar - Part 03 - Appointment Calendar package blog

By Michael J. Fuhrman

enetarch.net

<email contact>

10. Designing the Appointments Presentation


Welcome back to the third part of "Creating an Appointment Calendar". The previous post covered the extension of Ladder's Item and Folder data classes to create an Appointment and Appointments objects. This post will continue the Interface Design discuss that started in the first blog.

Several considerations that were covered are:
- Display a simple calendar for the week, and allow options to navigate between Previous / Next week, month and year, as well as return to the current date.
- Provide a consistent set of navigation links for the calendar
- Provide a consistent view for displaying the calendar entries in the list, new, edit and view pages.
- Moving an appointment to a different date should seem obvious
- Components of the presentation should be reusable and follow a consistent design format.

Further details will be uncovered and discussed.

When designing a Presentation, there are several things to consider:
- Which pages are needed?
- What components are needed on each page?
- Which components can be reused?
- How will CSS be accommodated?
- How will JavaScript be used?
- Will HTML HyperLinks be used or JavaScript Links?
- How will the Name Space be maintained?

This post will review the first three questions. The second post will review the re st of the questions.

-----------
a) Identifying the Pages

To identify pages, it&#146;s easiest to start with the 4 basic operations that data can have applied to it. Data can be created, updated , sought after, and deleted. These operations match the basic operations used by SQL Servers : INSERT, UPDATE , SELECT, and DELETE respectively. For now these pages will be called New, Edit, List / View and Delete.

Note: When SELECT is used, it can be used to List a series of matching entries in a database or it can be used to return a single entry. Thus why two pages have been identified for SELECT &#150; List and View.

At this point 5 pages have been identified: New, Edit, List, View and Delete. Our specifications call for an additional page to allow appointments to be moved from one date to another. This page will be called: Move.

Depending on the design of the page, the form and SQL operation can be placed in the same file. For the purposes of this application though, they will be kept separate. This adds an additional design requirement in how the components are designed, which will be covered later posts. For now the additional pages needed must match up with New and Edit, they will be called Add and Update respectively.

At this point, the pages identified are:
- New.php
- Add.php
- Edit.php
- Update.php
- List.php
- View.php
- Delete.php

List.php - displays a list of appointments that have been stored in the Appointments folder.

New.php - allows the user to enter data in for a new appointment.
Add .php - works with New.php to capture the data from the form in New.php and store it via Ladder into the data store.

Edit.php - allows users to edit data for an existing appointment.
Update .php - captures the changes made on the edit form and stores those changes into the data store.

View.php - allows the end user to see the data for this particular appointment.

Delete.php - deletes an appointment from the Appointments folder.

Now that the pages have been identified we can move on to breaking them down.

-----------
b) Breaking Down the Pages

This section will break down the pages identified in the earlier section. The component parts will be designed for reuse in future posts.

The component panels that can be readily identified are:

- A Navigation bar
- A Date Selector
- A List
- An Editable Appointment Item
- A Static Appointment Item

In reviewing the design of the Appointment Item Class, please remember that the START TIME and LENGTH are stored using INTEGER values. This suggests that two additional components may be needed to make the user&#146;s experience easier. They are:

- A Start Time selector
- An Appointment Length selector

With these basic components identified, this process can move into the design phase.

-----------
c) Design the Components

The previous section identified a Date Selector, List, Editable and Static Appointment Item, and a Start Time and Appointment Length selector. This section will describe how these components will work / interact with each other and the page they are associated with.

A design consideration raised earlier that now needs to be addressed is whether or not to designing generic components with static URLs or refer all HyperLinks TAGS '<A href=""></a>' to JavaScript functions. There are three choices here: Mixed, All HyperLinks Links, or all JavaScript Links.

As benign as this question may seem, the policy chosen will apply to all future components based on the requirement for reuse. A flexible decision will allow reuse of the components without having to change the code per application. While a mixed solution would seem to solve this problem, HyperLinks reference specific pages and as such HyperLinks appear to have ruled themselves out. JavaScript Links seem to have the same problem, unless NameSpaces are used.

JavaScript NameSpaces are created when objects include objects. As such , JavaScripts can follow a path of objects to a function of interest. With this technique the components can use unique paths to functions, like the following example: Corporate.Package.Package.Function. For the purposes of this post will use: ENetArch.Appointments.____() or ENetArch.Calendar. ___().

--- The Date Selector ---

There are many different kinds of calendars, and different ways that the calendar can be called into being on the page. Design questions to consider are:
Should the calendar be ever present or popup when needed?
How many weeks of the calendar should be present when the calendar is displayed?

There are two types of appointment calendars that can be used.
- One will present a week's worth of dates, and
- Another will provide 6 weeks&#146; worth of dates.

The one used for this post is the week&#146;s version.

--- The Start Time Selector ---

This component can take many different forms depending on how intricate a presentation is required. For the purposes of this example, a simple drop down list box will do. As such the only thing that is required then is the ability to populate the list box and select the appropriate time based on either a default value or a value from the appointment object.

--- The Appointment Length Selector ---

As with the Start Time Selector, this component can also be presented in many different forms. For the purposes of this example, a simple drop down list box will do. As such the only thing that is required then is the ability to populate the list box and select the appropriate time based on either a default value or a value from the appointment object.

--- An Editable Appointment ---

Several things to consider for the Editable Appointment are:

- The Editable Appointment will need to display a date selector, time and length selectors as well as the memo field.

- How much room should be given to the memo field?

- Where should the Start Time and Length Time selectors be positioned?

- Should the calendar be a part of the view, or implied and allow the user to move the appointment via other means?

Several programs: Outlook, Yahoo, and Google provide standard formats to edit an appointment. However their formats resemble email messages. An email format will not fit for this example.

For this example the Start Time and Length selectors will be displayed to the left of the memo field to allow the user to see them first.

+========+=========================+
+ StartTime + ......... Memo Field
+========+
+ Length ... +
+========+=========================+

--- A Static Appointment ---

The Static Appointment panel will look similar to the Editable Appointment panel, except that the fields will only display text, instead of editable information.

The design of this component allows for reuse in the List view, and also places new requirements on the Start Time and Length components. They will need to display non-editable data.

--- The List ---

There are several list formats and ways to create a List component. For the purposes of this discussion the focus will be on a vertical listing of appointments. And in the spirit of reuse, the design conflicts between the List component and the Appointment component will be discussed .

- The List component works with rows and columns
- The Appointment component works with 2 rows and 2 columns

These constraints lead to three possible scenarios being used: The first scenario draws the appointment view in a cell of the List component .. ie. the Appointment view doesn&#146;t change. The second scenario creates a new component specifically to List Appointments. The third scenario draws individual cells of the List component and requests the Appointment component to draw the contents of that cell.

If the Static Appointment component is used without change, the List will display each Appointment component wrapped in a cell. Depending on the amount of data in either column the columns of the individual appointments will not align. Using fixed width columns is an option, and may be necessary, but it also implies that more variables are needed to control those widths.

If a specific List view is created, the demonstration of reuse fails. Simply put, the work invested in building an Appointment component would be lost, since it would not be reused by the list component. However, building a specific List view for Appointments may shed light on how to design a robust solution.

To build a specific List view the list would know how many rows and columns it needs to display the appointment information properly. As the List drew out each row and column, it would place the information from the Appointment in the appropriate cell.

If this method were abstracted, call back functions could retrieve and format data per cell. Therefore a series of call backs could be used for the Header, each cell, and to determine the number of rows and columns needed.

If this method were taken one step further, the List and Appointment components could be separated. All the call back functions could be placed in the Appointment component. The list component would be given a reference to the Appointment component and then would ask the Appointment component the questions.

- How many rows and columns do you need?
- Do you have a header row?
- What goes in the cell at this row and column?

While this abstraction forces the extensions on Appointment Component, it allows the List and Appointment component to be reused in other capacities in future designs.

--- Common Features of these Components ---

With the components defined their common characteristics can be summarized into one or more abstract classes.

When building components for reuse an issue that must be resolved is how multiple copies of the same component will be distinguish ed when drawn to a web page. The answer lies in naming the component, not how PHP classes are named, but what name is used when the component draws itself in HTML and who names the component.

With this in mind, the common features are:

- How will the component be named?
- How will the name be used for HTML IDs, Names, and JavaScript Names?
- How will FORM variables be named, and passed and retrieved by the web server?
- How will component variables be saved and retrieved using sessions and cookies?
- How will the components receive and update Ladder objects?

For components that work with Lists the features identified can be abstracted as follows:

- Does the component have headers?
- How many rows and columns does the component need?
- What should be drawn in the header column?
- What should be drawn in a specific cell?

With the components identified, their common features could be identified. And with these features identified, the process of implementing the design can now commence.

Wrap Up
=======

At this point the process for discovering the Appointment components design guides is complete. A review of the Appointment User Presentation was conducted, pages were identified, and components were identified. A review of each component &#146;s requirements was conducted which lead to a discussion of how some components would need to interact with other components, and how that discussion would be facilitated.

Next Post
=========

The next post will begin implementing the Appointment Calendar&#146;s User Presentation.


Copyright 1998 - 2010 - E Net Arch
This program is distributed under the terms of the GNU
General Public License (or the Lesser GPL).