dw_dev | Calendar functionality (GSOC 2010)

Hello!

I'll very shortly introduce myself here, just not to be out of the blue :P :
I'm Ania, a Computer Science student from Gdynia, Poland who would like to participate in this year's Google Summer of Code (GSOC).

And - yes!- the point:
I'd be pleased to create a tool that would be useful for DreamWidth Members: a calendar - on-line time organizer. ( http://wiki.dwscoalition.org/notes/Summer_of_code#Calendar_Functionality )

I would do as much as I can to create a practical, intuitive and configurable tool that could meet Your expectations, therefore I'd be very thankful for any requests, suggestions, advice.

Below I attach an outline of the calendar functionality. It bases on the requirements from Dreamwidth GSOC ideas page and the research I conducted among my family and friends about the functionality that they look for in this kind of utilities or they think this tools lack of:

I TECHNICAL FEATURES

1. Synchronization handling (proposition below is a open list of possible options):

a. iCalendar format (RFC2445) - used e.g. in Google calendar
b. CSV format

2. Exporting calendar to printable format

II USER FEATURES

3. Multiple calendars

- Calendars may share information with each other

4. Events

a. Relating events to categories
b. Support for recurring events

- Choice of recur period

c. Possibility to set a note
d. Possibility to assign file, etc
e. Possibility to assign to persons, groups...

5. Group events

a. Group events - possibility to create events shown in group members calendars
b. Event invitations

6. Notifications (highlighting on calendar, pop-ups, email)

a. Reminder of incoming events
b. Reminding of past - not done events

7. Reconfigurability and personalization

a. User's ability to control calendar's visibility (public, private, among group)
b. Calendar features personalization
c. Configurable time zone
d. Configurable calendars days (e.g. Mon-Fri), hours, …
e. Configurable design

8. Design

a. Skin personalization
b. Coloring events depending on it's category, priority
c. Highlighting events that are of a high priority, are already delayed, etc...
d. Pinning images in the background of an event/day/… view

9. Searching

a. Pick a data/month/year and search through the portal for specified by User data, events
b. Displaying history concerning specific category, person meet, etc

10. Others

a. Todo notes -> events to place in time in the future
b. Events -> todo notes -possibility to "unschedule" an event

III WORTH CONSIDERATION

11. Interesting fields to look at

a. Weather calendar

- Displaying background views for e.g. future week weather

- Retrieving data from web service

b. Sms notification about important events

- Possible only for particular phone operators

c. Integration with MS Outlook

Once again - I'd be very thankful for any comment, suggestion or criticism and for your attitude to this subject. I'm looking very forward to this.

Thanks!

Flat | Top-Level Comments Only

This is the feature my friend and I would very like to use: we would be able to synchronize our timetables, organize time spent together. Therefore there would be ability to add a person's profile to the list of people who can see/edit the personal calendar.

Moreover, if there would be an incoming event that would be interesting for the group or community (like e.g. GSOC for dw_dev community:P ), this would not only notify about deadlines, but also help to organize the tasks, and be brief, clear and easy way to spread information.

So - more precisely - for every calendar there would be assigned a list of persons with defined rights. They could be added individually or within a group. (Of course, they could resign from being on that list). People with particular rights would be able to manage the calendar.

(Is this a satisfying answer? :P)

So you'd be able to invite everyone in a comm to an event, or invite an on-fly-list, or a custom access group that you have set up? Or would each community have a calendar, and members would see community events on their calendar?

If every calendar has a list of people with defined rights, would this be updated automatically if you give someone new permissions in the community (e.g. posting access) or would it be separate? Would "editing the calendar" be a new level between posting access and moderator?

Would it be easy to allow all your access list to see your calendar but no-one else, or all of a custom access group but no-one else, and have it update automatically when that access group changes?

So you'd be able to invite everyone in a comm to an event
interesting idea, I haven't thought about this particular feature - inviting to an event - but it seems to be a valuable feature
or invite an on-fly-list, or a custom access group that you have set up? Or would each community have a calendar, and members would see community events on their calendar?
Every calendar would have an administrator, by default the person who created it. She/he would have a possibility to choose if the whole calendar would be private, seen by particular people, seen by particular group(s).

In parallel, a single user would have an ability to display single calendars, but also combine chosen calendars event in a new view - so that she/he could have a more complex vision of upcoming events as well as better chances not to miss the event.
Nonetheless, as I've mentioned, the possibility to invite people for not only a calendar, but also single event seems very interesting and I'd really like to add it to calendar features requirements.

If every calendar has a list of people with defined rights, would this be updated automatically if you give someone new permissions in the community (e.g. posting access) or would it be separate?
I think the following proposition could be discussed:
Situation 1:
If it would be a calendar with dw_dev events, I suppose there would be no need to performing special actions for adding calendar readers in other way than when a person becomes a dw_dev member (however, before adding the dw_dev calendar to the person's calendars view, this person should be asked if she/he is willing to). The rights set to the group would concern the whole group as well. When a person would resign from dw_dev membership, the dw_dev events shouldn't appear in the person's calendar, I suppose; etc.

Situation 2:
If, lets say, I want to share my calendar with my best friend and show (and not let to edit) my plan to my school mate, I'd send personal invitation to those people, defining their rights one by one.

Situation 3:
However, there may probably happen situations, when we would not like only particular people from the group to see the calendar (just as hes Denise mentioned - e.g. when we prepare a secret birthday party. This may be solved by adding people individually by the calendar creator (or by people who would have rights to do so).
[ Therefore implementation, in order to determine user's rights to calendar, should primary consider if a person is added as a single account, and if not - as a group member. ]

Summing this point up:

The calendar's creator (who automatically becomes it's administrator) while creating a calendar will have a possibility to:
- set the calendar's visibility - choose people, groups who would be invited to have an access to the calendar
- define the access level (the rights) for chosen people (one by one) and groups (group members have by default the same rights).

The whole process could perform in the following way:

I think that if a group would be given an access to the calendar, becoming a member of the group automatically gives the particular (defined by calendar's administrator) rights to the calendar.

I, naturally, welcome every suggestion that would lead to better solution. I think, this case may evolve depending on Users (this means ours:P) demands.
And one more remark: I personally think, that there should be possibility of choice in the security field, however too many options may lead to verbosity and make choice not intelligible. This, in turn, may cause mistakes in the security area, which - as I've learned - is highly undesirable in Dreamwidth. This means that I'd need to ask for help when defining a final configuration panel: there may be important issues that I may not notice or instead of brevity, I'd achieve too much complexity.

Generally, when working on project, I'd like to create a suggestions thread, where I would ask Dreamwidth members about Their opinion and would be very glad to read about their own ideas or needs.

Would "editing the calendar" be a new level between posting access and moderator?
The privileges is the another important issue (as it concerns security). This again would have to be discussed among Dw community. As for now I propose the following levels:
- calendar administrator (who by deault would be the calendar's creator) - deciding about the calendar's access
- managing (creating & editing & deleting) events
- viewing events

Above all - this questions You made are just what I would appreciate when working on project (thanks). They show me aspects that I may not identify on my own.

No problem, and thanks for clarifying :) This sounds good.

This looks very well thought out -- I'm really impressed by the effort you've put into this so far! Taking the time to draw pictures is always appreciated. :)

I think that the best way to handle these security questions would be an option at the time of creating the calendar -- I like what Google Docs does, where you can have a public document or an invite-only document. Maybe we could make it so that calendars were public (and listed, linked off the profile, like right next to tags and memories), access-locked (listed linked off the profile, visible to all people on your access list), custom group locked (listed linked off the profile, visible to all people in a custom group), or invite-only (not listed linked off the profile, viewable only through the invite link until you become a 'member' of that calendar) -- making invites essentially an access group without having to form an actual access group.

I particularly like your attitude on options. There's a careful balance between making something have enough options to be useful, and making something have too many options and be confusing!

And yes, we would absolutely post an entry asking people what they would want to see in a system like this. Our users are very, very good at giving their opinions. :)

I just want to say that I'm very pleased for every response and in such a short time! It's very valuable for me and I will try to embody every thought and suggestion.

I would present my a bit more concrete vision of project in thursday/friday. I have some crucial time at my university now and I'm sorry for loosing the pace:P

May I just say how impressed I am by this project plan so far? Because I am :)

:P thanks, it really encouraging!

Count me as another one who's impressed and excited by what I've seen so far!

Calendar functionality (GSOC 2010)

Group calendar events

Re: Group calendar events

Re: Group calendar events

Re: Group calendar events

Re: Group calendar events

Re: Group calendar events

Re: Group calendar events

Re: Group calendar events

Re: Group calendar events