Changes for page Calendar Application
Last modified by Ecaterina Valica on 2014/01/15 13:50
From version 14.1
edited by Vlad Merticariu
on 2011/06/22 13:28
on 2011/06/22 13:28
Change comment:
There is no comment for this version
To version 18.1
edited by Vlad Merticariu
on 2011/06/22 15:37
on 2011/06/22 15:37
Change comment:
There is no comment for this version
Summary
-
Page properties (1 modified, 0 added, 0 removed)
-
Attachments (0 modified, 6 added, 0 removed)
-
Objects (0 modified, 2 added, 0 removed)
Details
- Page properties
-
- Content
-
... ... @@ -32,6 +32,20 @@ 32 32 * Each event must be stored in its own document 33 33 * Each calendar is stored in its own space (only 1 calendar/space) 34 34 35 += Alternatives = 36 + 37 +**Calendar aggregator** 38 + 39 +The WebHome of the application is an aggregated calendar which displays the events from all the calendars of a user. 40 +The user creates several calendars (e.g. Personal, Work) which can be visualized both individually and together, on the main page of the application. 41 +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). 42 + 43 + 44 +**Individual calendars with categories** 45 + 46 +The users creates calendars which are individual entities and each event is assigned a category when added. 47 +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. 48 + 35 35 = Detailed Functionality = 36 36 37 37 == Adding events == ... ... @@ -47,7 +47,7 @@ 47 47 * **Date**: User should be able to mark an event as **recurring**. 48 48 * **Location**: Link to Google Maps 49 49 * **Description** 50 -* **Category** 64 +* **Category** : //? Do we need this once a user can have multiple calendars? // 51 51 * **Color**: The event will have a default color and event creators may select a different color for the new event from a given list 52 52 * **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) 53 53 * **Privacy options**: Default, Private, Public ... ... @@ -99,7 +99,7 @@ 99 99 100 100 * **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. 101 101 102 -**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) 116 +**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? // 103 103 104 104 == Settings == 105 105
- actions.jpg
-
- Author
-
... ... @@ -1,0 +1,1 @@ 1 +XWiki.evalica - Size
-
... ... @@ -1,0 +1,1 @@ 1 +70.2 KB - Content
- addMenu.jpg
-
- Author
-
... ... @@ -1,0 +1,1 @@ 1 +XWiki.evalica - Size
-
... ... @@ -1,0 +1,1 @@ 1 +18.1 KB - Content
- eventFields.jpg
-
- Author
-
... ... @@ -1,0 +1,1 @@ 1 +XWiki.evalica - Size
-
... ... @@ -1,0 +1,1 @@ 1 +73.9 KB - Content
- monthView.jpg
-
- Author
-
... ... @@ -1,0 +1,1 @@ 1 +XWiki.evalica - Size
-
... ... @@ -1,0 +1,1 @@ 1 +87.5 KB - Content
- weekView.jpg
-
- Author
-
... ... @@ -1,0 +1,1 @@ 1 +XWiki.evalica - Size
-
... ... @@ -1,0 +1,1 @@ 1 +62.2 KB - Content
- yearView.jpg
-
- Author
-
... ... @@ -1,0 +1,1 @@ 1 +XWiki.evalica - Size
-
... ... @@ -1,0 +1,1 @@ 1 +75.8 KB - Content
- XWiki.XWikiComments[0]
-
- Author
-
... ... @@ -1,0 +1,1 @@ 1 +XWiki.evalica - Comment
-
... ... @@ -1,0 +1,3 @@ 1 +I don't think we will need a livetable to list all the events since you can see/delete/edit all events in the year/month/week views. The calendar events are much powerful when they are in a timeline than seeing them in a list. 2 + 3 +Also I don't think is necessary the concept of categories when you can have multiple calendars. Right now in Google Calendar you can create multiple calendars and attribute each calendar a goal (have a personal one, a xwiki one, a birthday, etc). In this use case the concept of categories is replaced by multiple calendars. - Date
-
... ... @@ -1,0 +1,1 @@ 1 +2011-06-22 11:59:17.0
- XWiki.XWikiComments[1]
-
- Author
-
... ... @@ -1,0 +1,1 @@ 1 +xwiki:XWiki.Enygma - Comment
-
... ... @@ -1,0 +1,7 @@ 1 +I agree with this. 2 + 3 +We should have a 2 views: 4 +1. Individual calendar view, that should be available on each calendar's space WebHome 5 +2. Aggregated calendar view for all the calendars and events that are visible to the current user. This could be a new tab in the user's profile (harder for an application to extend right now) or, alternatively, in the Calendar application's space WebHome (easier and makes the Calendar application space useful). 6 + 7 +The event livetable might be useful for an 'advanced search' functionality, allowing to filter events nicely. - Date
-
... ... @@ -1,0 +1,1 @@ 1 +2011-06-22 12:35:20.0 - Reply To
-
... ... @@ -1,0 +1,1 @@ 1 +0