• Main objective
• Description
• Functionality
• Alternatives
• Detailed Functionality
  • Adding events
  • Viewing events
  • Settings
    • General
    • Privacy
    • Notifications
  • Search
  • Suggestions
  • Further work
• Technicalities

Main objective

This application aims to allow end users to create calendars for which they can define and manage events.

Description

The functionality of the application is similar to Google Calendar.
The user defines event objects for a specific calendar and the events are visible in different views (day/week/month/year?).

Functionality

• Add events:  1. Button which opens a modal window, allowing the user to insert details and save || 2. Complete form on the page. The users enters all the details and, after submission, he is redirected back to the calendar in view mode
• View event list:  A page (modal window) with the list of all the events in the calendar is displayed, using LiveTable, were the user can filter and edit/delete events (if he has the right to do it, additional view to administrate events)
• Import/export:  tbd - ical feeds 
• Microformats support:  tbd
• JS drag & drop on the calendar table for changing the dates/hours of the events ?:  an event can be dragged from one slot of the calendar table to another slot
• RSS notifications:  a document to generate RSS feed will be created
• Email notifications:  emails with information about the event are sent to the calendar creator and to the selected users (when?)
• Privacy settings on events:  events can be public or private, public events are visible to everyone, private events are visible only to the calendar creator
• Privacy settings on calendar  
• Display events on categories:  the viewer can select a category and only events from that category will be displayed in the calendar event
• Event details on hover:  when the user moves the mouse over an event in the calendar table details about the event (startin&ending time, location, description) are displayed
• Comment on events:  users have the ability to comment on events
• Yearly view of the calendar, where days with events in them are highlighted
• Monthly view of the calendar, with links to the previous and next months
• Weekly view of the calendar, with  links to the previous and next weeks
• Daily view of the calendar, listing all the events in that day
• Have an API for accessing events
• Each event must be stored in its own document
• Each calendar is stored in its own space (only 1 calendar/space)

Alternatives

Calendar aggregator

The WebHome of the application is an aggregated calendar which displays the events from all the calendars of a user.
The user creates several calendars (e.g. Personal, Work) which can be visualized both individually and together, on the main page of the application.
This is very similar to Google Calendar, following the same approach. The main advantage of this is the ease of interaction between users' calendars (e.g. sharing a calendar with another user means displaying the specific calendar among his own calendars, inside the WebHome). 

Individual calendars with categories

The users creates calendars which are individual entities and each event is assigned a category when added.
When the user is invited to other events he can choose to view those events in one or more of his calendars while when another user shares a calendar with him he can only view that calendar, on a separate page.
The current technicalities are meant for this alternative.

Unique calendar/user

Every user has only one calendar. Events can be categorized just as above.
For sharing the user has 2 options: share the entire calendar or share a category, which, as functionality, makes it similar to the Calendar aggregator alternative. 

Detailed Functionality

Adding events

You may add an event by:

1. Clicking a button which opens a modal window, allowing the user to insert details and save
2. Filling in a form on the event page. The user enters all the details and, after submission, he is redirected back to the calendar in view mode

Each calendar will be stored in a space. A space can only contain one calendar. Each event must be stored in its own document and should have:

• Name 
• Date: User should be able to mark an event as recurring. 
• Location: Link to Google Maps
• Description
• Category (e.g. Personal, Work)
• Color: The event will have a default color and event creators may select a different color for the new event from a given list
• Notifications: Email notifications may be sent to the event creator and the users he selects (10 minutes, 30 minutes, 1 hour, 1 day, 1 week)  
• Privacy options: Default, Private, Public
• The possibility to add guests. Guests can appear in the form of wiki users or email addresses. Suggestions should be available if the event creator starts typing in a user's name. Guests will be notified by email they have been invited to the event and they should be able to RSVP (confirm their presence) via email
• Set rights for guests. The event creator can grant users one, some or all of the following rights: modify the event, invite other guests to the event, see the guest list
• Attachments: Documents can be attached to an event. An icon will indicate in the daily and weekly view modes that the event has attachments
• Comments: Users have the ability to comment on an event. An icon will indicate in daily and weekly view modes that the event has comments

More actions:

• Change owner
• RSVP for guests: Users who are not event owners, but see an event to which they are invited in a calendar, should be able to click the "RSVP" link and confirm their presence
• Delete event
• Duplicate event: Copy an event inside the calendar
• Copy event to a different calendar: Copy an event from the current calendar to a different calendar

Viewing events

View calendar:

• Tabbed day, week, month, yearly view
• Year view:
  • There should be 12 cells representing the 12 different months
  • When users click on a month (e.g. June 2011) they should be directed to that specific month in the "Month" tab
  • When users click on a day (e.g. 1) they should be directed to that specific day in the "Day" tab
  • Days that have events associated should be marked with bold
  • The current day should be highlighted with a distinct color or frame
  • Arrows will be available to go to the previous/next year
• Month view:
  • Table view; each column represents a day of the week (Monday, Tuesday...); each cell represents a specific date (1, 2...)
  • When users click on a day (e.g. 1 in the cell header) they should be directed to that specific day in the "Day" tab
  • Events should be displayed chronologically inside each cell. The starting hour of the event should be displayed, the name of the event and an icon indicating if notifications have been set. Clicking or hovering (TBD) on the event will bring up a pop-up with more details and links to edit and delete the event
  • The current day should be highlighted with a distinct color (same as the one used for the "Year" view)
  • Arrows will be available to go to the previous/next month
• Week view
  • Table view; each column represents a day of the week (Monday, Tuesday...); each row represents an hour of the day
  • When users click on a day (e.g. Fri 6/17 in the table header) they should be directed to that specific day in the "Day" tab
  • Events should be displayed chronologically in each column and occupy the number of cells corresponding to the number of hours the event is scheduled to last. An alert icon should be displayed when a notification is set, an attachment icon when an attachment is present, a comment icon when comments have been added. Clicking or hovering (TBD) on the event will bring up a pop-up with more details and links to edit and delete the event
  • The current day should be highlighted with a distinct color (same as the one used for the other views)
  • Arrows will be available to go to the previous/next week
• Day view
  • Table view; one column representing one day; each row represents an hour of the day
  • Events should be displayed chronologically and occupy the number of cells corresponding to the number of hours the event is scheduled to last. An alert icon should be displayed when a notification is set, an attachment icon when an attachment is present, a comment icon when comments have been added. Clicking or hovering (TBD) on the event will bring up a pop-up with more details and links to edit and delete the event
  • The current day should be highlighted with a distinct color (same as the one used for the other views)
  • Arrows will be available to go to the previous/next day

• Display events by category: users can select a category and only events from that category will be displayed in the calendar
• Jump to a specific date

• Viewing events you are invited to in your calendar: Calendar owners will have view right by default for their own calendar (space). View rights should also be granted for events he is invited to. This means having view rights on event pages that are located in other calendars (spaces). Other rights, such as edit and comment can also be granted, depending on the settings established by the the owner when creating the event. 

View event list: A page (modal window) with the list of all the events in the calendar is displayed, using LiveTable, were the user can filter and edit/delete events (if he has the right to do it, additional view to administrate events)  ? Do we need this once the events can be viewed in calendar table? 

Settings

General

• Calendar name
• Owner
• Description
• Location

• Week starts on Sunday/Monday/Saturday ? should this be done automatically depending on the user's location?
• Show events you have declined: Yes/No
• Automatically add invitations to my calendar: Yes/No

Privacy

Privacy settings for calendar
The calendar can be:

• Public
• Visible for specific wiki users -> Share calendar
• Private

Privacy settings for the categories
Each category can be:

• Public
• Visible for specific wiki users -> Share category
• Private

Default privacy settings for events
Events can be

• Public: visible to everyone specified in the calendar settings
• Private: visible only to the event creator

Notifications

A calendar owner may choose to receive notifications for:

In addition, reminders can be sent by default to the calendar owner via email: 10 minutes, 30 minutes, 1 hour, 1 day, 1 week

Search

The "View event list" livetable can be used to filter events by date, location, and even to do searches within the event descriptions.

Suggestions

• Ability to print calendar
• Keyboard shortcuts
• Tips or link to documentation
• Notifications by SMS could be interesting
• Gadget integration

Further work

• Select language?
• Select from different time zones?
• Select date format?
• Select time format? 
• Similarly to Google Calendar, event recurrence should be customizable

Technicalities

The event-calendar part of the application will be implemented in the following way:

• 2 classes will be used: EventClass and CalendarClass
• an event represents a document with an object of EventClass attached
• a calendar represents a document with an object of CalendarClass attached. When a calendar is added, a space is also created. This space will contain the calendar document and the event documents associated with the calendar.

Event class properties:

• name (Name: text):  the title of the event
• startDate (Start date: date(dd/MM/yyy)):  the date when the event starts
• startTime (Start time: static list):  the hour when the event starts
• endDate (End date: date(dd/MM/yyyy)):  the date when the event ends
• endTime (End time: static list): the hour when the event ends
• allDay (All day: bool): checkbox which indicates that startTime is 00:00 of the startDate and endTime is 00:00 of the day after endDate
• repeats (Repeats: static list (daily, weekly, monthly, yearly)):  how often the event repeats 
• repeatsUntil (Until: date(dd/MM/yyyy)):  the date when the recursion of the event ends
• description (Description: text):  a short description of the event
• location (Location: text):  the location where the event will take place
• category (Category: database list):  the category of the event
• color (Color: static list):  the color of the event
• privacy(Privacy: static list):  set the event to be default, public (visible to everyone) or private (visible only to the user)
• emailNotifications (Email Notifications: static list):  indicates when the reminders for the event should be sent to the creator and to the guest list
• guestViewList (Guest View List: database list):  the list of users invited to the event, having view rights, waiting for confirmation
• guestEditList (Guest Edit List: database list):  the list of users invited to the event, having edit rights, waiting for confirmation
• attendingGuests (Attending guests: database list):  the list of users who have confirmed their attendance to the event
• nonattendingGuests (Non-attending guests: database list):  the list of users who have declined their attendance to the event
• notifiedGuests (Notified Guests: database list):  the list of guests who have received notifications about their event invitation 

XWikiRights objects will be added to event documents in the following way:

• default events: edit object for guestEditList and owner, delete object for owner
• public events: view object for XWikiAll group, edit object for guestEditList and owner, delete object for owner
• private events: view object for guestEditList, guestViewList and owner, edit object for guestEditList and owner, delete object for owner

Calendar class properties:

• name (Name: text):  the name of the calendar
• description(Description: text):  a short description of the calendar
• privacy(Privacy: static list):  set the calendar to be public(visible to everyone), visible to specific users or private(visisble only to the user)
• shareList(Share calendar: user list):  if privacy is set to visible for specific users, this list will contain the users who can view it
• owner(Owner: user):  the user who owns the calendar
• weekStart(Week starts on: static list):  The day when the week starts (Sunday, Monday or Saturday) ? should this be done automatically depending on the user's location?
• showDeclinedEvents(Show Events you have declined: bool):  Indicates if events which have been declined should be added to the calendar
• addInvitations(Automatically add invitations to the calendar: bool):  Indicates if the events to which the user has been invited should be added to the calendar 

Calendar class sheets:

• CalendarViewDaySheet:  contains the display of the calendar table in "day" view
• CalendarViewWeekSheet:  contains the display of the calendar table in "week" view
• CalendarViewMonthSheet:  contains the display of the calendar table in "month" view
• CalendarViewYearSheet:  contains the display of the calendar table in "year" view
• CreateCalendarEvent:  contains the form for adding new events
• CalendarEventListSheet:  contains the list of events for the specific calendar, with edit and delete links if the user has editing rights

Category class properties:

• title(Title: text):  the title of the category
• description(Description: text):  a short description of the category