Day Planner

The Day Planner vision

Note: This is the original vision, you may also view the current vision document

The vision of Day Planner is to create a Day Planner that:
- Is easy to use
- Is simple to learn
- Is consistent
- works offline, does not require an internet connection
- goes out of its way to make sure the user knows about an appointment
- follows the GNOME HIG
- has the features people need, but not more. No bloat, no excessive features
- has a clean, well documented and extendible codebase
- does one thing, and does that well

User interface
The user interface is going to be simple. It should not be bloated like many other planning applications (such as the Mozilla sunbird and Evolution planners). It should follow the GNOME human interface guidelines. Using the GTK GUI libraries. It should also have the ability to use the GNOME GUI libraries if they are available thus providing easier to use widgets (however no functionality should depend upon the GNOME libs).

Read-only web interface
Day Planner should be able to export to html (read-only). This should be possible to do by the commandline with no X (DISPLAY var) running. This so that the user can access her or his Day Planner tasks from a web interface. Further on perhaps it could be an idea to have an actual web client utilizing mod_perl/cgi. This is however not a priority and should not be expected to be considered before around version 2.0.

Underlying daemon ("the reminder")
The daemon should be hidden from view most of the time. The user shouldn't know about it. The daemon takes care of access control (making sure only one client is running at any one time) and running the notification program to notify the user about events. Day Planner shouldn't be running without it. When speaking about the daemon to the user it should be referred to as the "Day Planner reminder".

Underlying notification software
The notification software takes care of making sure the user knows about an event. It displays a GUI pop-up dialog and takes care of the "postpone" button in those dialogs. It should also be able to notify the user in other ways so that even if X isn't running the user knows. This can be achieved by for instance:
Mailing the user
Using wall to notify (not optimal, security risk on multi-user systems)
Using write on all terminals of the user that ran the notifier. Would be hacky.

Innovative notification - aka. in a perfect world...
SMS notification is a very interesting option. Sending the user an SMS or MMS with the summary of the event. This is not currently possible, SMS costs money and there is no good web interface to send it from. This could be solved by using online websites to send free SMS messages, but it would be a very hacky, ugly and time-consuming thing to write and wouldn't really be reliable. Still, this is a vision document, and in a perfect world this would be possible. Perhaps if mobile phones one day get a permanent internet connection we can have a mobile phone client. I doubt it though...

Networking and calendar sharing
Having a remote server where you can also save your dayplanner data would ofcourse be a useful feature. However, due to the design of Day Planner, that the program should always be able to run offline we don't want calendar sharing in the sense that it will get your calendar data from a central server. It will be more along the lines of that the Day Planner daemon at regular intervals uploads the data to a central server. A user can then authenticate with that server to view a calendar and even edit it if the proper permissions are in place.

This will allow the user to access and edit their own calendar while not having an internet connection, and then merely uploading the new calendar data when an internet connection/network is available. This way you can share your calendar data with other people, while still retaining the access to the calendar at all times.

On the technical side. An xinetd solution would probably be easiest, where we have SSL and authentication done in the server/client itself. The dayplanner daemon can fork off a process that uploads the data. The interval could be around 10-15 minutes for a server on the local network and 30-60 minutes for an internet server. Only uploading when the data has been saved.

The networking system is however far off into the future, and should not be expected before around Day Planner 2.0 or 3.0 (unless someone is prepared to pay for its development, of which I highly doubt).

For now calendar sharing can be partially emulated with nfs shares and the --confdir commandline option. A readonly mode for Day Planner might be introduced later to further simplify this.