Calendars

1
Calendars Calendaring

• Class 3

2
Setting up accessing calendar Database
3
Making connection to Access

• // Set up database connection
• try
• url "jdbcodbcAddressBook" 
• Class.forName( "sun.jdbc.odbc.JdbcOdbcDriver" )
  
• connect DriverManager.getConnection( url )
  output.append( "Connection successful\n" )
  
• catch ( ClassNotFoundException cnfex )
  
• // process ClassNotFoundExceptions here
  cnfex.printStackTrace()
• output.append( "Connection unsuccessful\n"
  cnfex.toString() )

JDBC-ODBC bridge
Bridge to name
4
From Peter Wu
5
From Peter Wu
6
From Peter Wu
7
From Peter Wu
8
From Peter Wu
9
From Peter Wu
10
From Peter Wu
11
From Peter Wu
12
EXAMPLE
13
Design Decisions

• Content vs. Context
• The more text the narrower the view
• Slot vs. Journal
• Slot offers spatial context
• Journal preserves space for text
• Free/Busy vs. Event Id
• Iconic/in context
• text

14
Event Entry
Summary
event type
recurring_status
location
duration
busy/free
Journal
15
Daily View
16
Weekly view (by slot)
17
Weekly View (journal)
18
Monthly view (journal)
19
Yahoo calendar
20
Electronic Calendars in the Office An Assessment
of User Needs and Current Technology
Kincaid C., Dupont P. and Kaye R.
21
Objectives

• Examine how office workers use calendars in
  general
• Examine their feedbacks to using electronic
  calendars
• Review the degree which the electronic calendars
  meets the users needs
• Make recommendations for features of electronic
  calendars that would make them substitutes for
  paper calendars

22
Survey Methods

• 30 respondents
• Interviewed with 32 questions of three categories
• General calendar usage
• Electronic calendar usage
• Automatic scheduler usage

23
Questions general calendar usage

• Number, type of calendars currently used
• Usages
• Calendar accessibility to others
• Average number of meetings

24
Questions electronic calendar usage

• Frequency of usage
• Feature preferred in paper calendars
• Possible enhancements

25
Questions automatic scheduler usage

• Whether it is used, whether it is easy to use
• Suggested enhancements

26
Survey Results

• Paper calendars
• By average, a person uses 2 calendars
• Most popular format are day at a glance and
  week at a glance
• Most common usages
• Record of appointments, meetings, events, etc.
• Reminders and notes
• As to do lists
• Ones calendar is rarely accessed by others
  (usually ask directly rather than look at others
  calendar)

27
Survey Results (cont.)

• Electronic Calendars
• Less uses of the electronic calendar as primary
  calendar
• Difficult to use, difficult to enter information,
  not portable, duplications of paper calendar
• Few prefer electronic calendar to paper calendar
• Easy to modify
• Dont lose information
• Automatic scheduler is not frequently used
• Unreliable methods
• More difficult to confirm, cancel (compared to
  e-mail)

28
Survey Results suggested enhancements

• Alarm/reminder facility
• Ability to enter repetitive/standard meetings
  over a time period
• Ability to attach minutes/agendas to calendar
  entries
• Automatic Scheduler
• Automatic attendance confirmation
• Automatic cancellation notification

29
Recommendations

• Calendars
• Flexible in entering data
• Optional alarm/reminder
• Easy to navigate from day to day
• Automatic Schedulers
• Allow user to specify who to attend, time range
• All possible meeting times should be presented
  and user should be allowed to select the best one
• Warning of conflicts, allow confirmation, cancel
  of meetings
• Allow booking resources along with meetings

30
How are shared calendars used?
31
Information and Context Lessons from a study of
two shared information systems

• Dourish, P., Bellotti, V, Mackay W. Ma, C.

32
Objectives

• Study of Two Information Systems at EuroPARC (a
  Rank Xerox research lab in Cambridge, UK)
• The Calendar
• Khronika
• The two systems provide access to similar
  information bases
• The focus of the study is on the uses of the same
  information in different context

33
Two Information Systems

• The Calendar
• Document lists details of whereabouts of lab
  members during the week, information about
  visitors, upcoming events, seminars
• Distributed weekly both by e-mail and in paper
  form
• Khronika
• Electronic event server which allow
  browsing/updating a database of events
• No facilities for automatic event scheduling

34
The Calendar

• One human editor/administrator
• Collecting data
• Automatic weekly e-mails request the information
  from all staff in the lab
• Reminder is sent if information is not received
• If still no information is received, the default
  entry will be used for that individual
• Distributing data
• 3-5 pages long, distributed to staff in papers
  and e-mails

35
Khronika

• Collecting data
• Individuals may contribute information anytime
  from any workstation
• Multiple interfaces for data entry
• Information entered available immediately
• Retrieving data
• Browsing
• Searching
• Automatic Reminders

36
Usage Comparisons

• Entering information
• The Calendar
• Users are required to provide the information
  (official records)
• Khronika
• Less formal in contributing the information
• Change/delete more easily
• Importance of the information, timeliness of
  distribution, perceived audiences are among the
  factors in choosing which system to put the
  information into

37
Usage Comparisons (2)

• Retrieving information
• Timeliness and the nature of medium are among the
  critical factors to choose which system to refer
  to for some particular information
• Information in Khronika is more up-to-date but
  less official
• Information in Khronika provides information
  about who-enter/when-it-is-entered which help in
  the assessment of information

38
Usage Comparisons (3)

• Presentation Issues
• The Calendar
• Separate information by events (as opposed to
  times)
• The conflict of times between two events is
  invisible
• Provides a section on summary of upcoming events
  over the next few months
• Khronika
• Conflict of times is easy to identify
• To see all the upcoming events over the next few
  months, forwarding multiple pages required, which
  makes the information less accessible

39
Context

• Context impacts how the users interpret the
  information
• Context Components
• Ownership/responsibility over the correctness
• Medium/mutability
• Storage and Distribution Medium
• Convenience and ease-of-use
• More mutable medium, more likely to carry
  tentative information

40
Context (2)

• Context Components (cont.)
• Timeliness
• Organizational status and relevance
• Degree of relevancy of information to individuals
  and to the organization

41
Design for interpretation

• Design implications
• Contextual cues to assist users to interpret the
  information
• Shared information (human interprets information)
  vs. Shared action (automatic scheduling)
• Contextual information collecting for later
  presentation
• Contextual information to assist browsing

42
A Case Study of Calendar Use in an Organization

• Jonathan Grudin

43
All-in-one vs. PROFS (circa 1996)

• Defaults matter
• Hi privacy (free vs. scheduled) All-in-one
• Lo privacy (all youve entered) PROFS
• Benefits of open calendars
• Finding people
• Predicting whether a meeting might be movable
• Finding where a meeting is
• Discovering meetings
• Learning about the company (e.g. what is your
  manager doing?)

44
Three users (from Palens thesis)

• (Sun in more detail)

45
The Salesman

• 30 on the road
• Uses
• Month-at-a-glance notebook for sales
  appointments, notes, etc.
• Writes in pencil makes lots of changes
• Electronic calendar to find out when manager is
  in town

46
VP

• Depends on EC for everything (all day in
  meetings)
• admin assistant has write access changes
  schedule as needed
• Alarms linked to a pager
• Prints out a copy (daily calendar) to take home
  so she can turn the pager off

47
SWE

• 3 Calendars
• Day-at-a-glance for to-do list
• EC for appointments info primarily for others
• Large month-view for deadlines tracking
  traveling roommate

48
Social, Individual Technological Issues for
Groupware Calendar Systems
Palen, L.
49
Groupware Calendar Systems (GCS) Perspectives

• Technology-centered perspective
• Individual-centered perspective
• Human-computer interaction (HCI)
• User-centered design
• Organization-centered perspective
• Computer Supported Cooperative Work (CSCW)
• Groupware

50
Single-user calendar

• Diversity of forms
• Granularity daily, monthly, weekly, 15 minute
  units
• Location of access hallway planner, desktop
  organizer
• Diversity of functions
• Temporal orientation determine day, month, year,
  events, duration
• Scheduling
• Tracking records
• Reminding of future events
• Note recording/archiving
• Retrieval Recall

51
GCS for Interpersonal Communication

• Artifacts of temporality time-as-artifact
• Peer judgment time allocations of colleagues
• Privacy managing
• Meeting arranging
• Organization learning organizations memory

52
Socio-Technology aspect

• Usage environment impacts the technology design
• Geographically expansions and time zone
  compatibility
• Security/Privacy Policy

53
Summary

• Calendar Manager
• Temporal Coordination
• Information Sharing
• Users of general calendars may need to modify
  their practices to suit the electronic medium
• Behavioral and technical mechanisms are required
  to manage privacy of calendars in social
  environment

54
Augmenting Shared Personal Calendars
Tullio, J., Goecks E., Mynatt, E. Nguyen, D.
55
Outline

• The design of the Aurgur system in three
  perspectives
• Single-user Calendar
• Temporal orientation, tracking, reminding,
  editing
• Interpersonal Communication
• Finding open times to schedule meetings
• Socio-technical Evolution
• Privacy management

56
System Design

• Retrieving user calendars from PalmOS devices
• Database is designed to match with the vCalendar
  specification
• Provide prediction about the likelihood of
  attendance for future events using a Bayesian
  network model
• Event-matching which will identify events from
  several calendars if they are the same events
• Web-based visualization

57
System Implementations

• All components written in Java
• Visualizations use JSP and DHTML
• Database is provided by the MM implementation of
  MySQL
• Norsys Corp.s Netica software is used for
  probabilistic modeling and inference
• SVMLight support vector machine is used to
  classify calendar events

58
Predicting Event Attendance

• A Bayesian network is used
• A user model of event attendance is created based
  on
• User role
• Location of user
• Location of events
• Time/duration of events
• Type of event
• Other event priority
• Availability of reminder

59
Event Classification using SVM

• Attributes such as event location and event type
  are not fields in PalmOS calendar so they must be
  extracted from text
• The support vector machine (SVM), a machine
  learning algorithm, is used to identify events
  from words in documents
• SVM models are created and trained to classify
  events by location and type
• Locations 3 campus buildings and other
• Types courses, seminars, individual meetings,
  group meetings, office hours, and other

60
Co-scheduled events

• Co-scheduled event identification
• an ability to show a user that colleagues are
  also planning to attend the scheduled event
• system identifies calendar entries across user
  calendars that represent the same event
• however, users often have different coding
  styles, e.g. brownbag seminar, brown bag, bb
  seminar

61
Co-scheduled Events (2)

• The Term Frequency-Inverse Document Frequency
  (TF-IDF) algorithm is used for matching events
• Matching by textual similarity
• Similarity threshold is defined
• Results showed that matching recurring events is
  more accurate than one-time events due to more
  common words used

62
Interpersonal Communication

• Augmented View of Daily Calendar
• Event in the calendar is displayed along with the
  icons of colleagues who scheduled the same event
• Likelihood of attending the event by a colleague
  is indicated by three techniques
• Icons are arranged from left-to-right according
  to attendance likelihood
• Opacity of icons
• Icons are grouped by attendance likelihood

63
Interpersonal Communication (2)

• Interactions
• When user moves mouse over a colleagues icon, a
  menu will appear with colleagues full name and
  small picture and a link to view his/her calendar
• When a link to colleagues calendar is clicked,
  his/her calendar will appear side by side with
  the user calendar so that schedules can be
  compared

64
Socio-Technical Evolution

• Social history
• Log and visualize the accesses to calendars
• Private /public event
• User may set an event on the calendar to be
  viewable by owner or viewable by all

65
IS 2470 Calendar Projects

• GUI calendar- write a GUI connect it to a
  database
• Start incorporating iCal standards
• Web-based calendar- write a typical web front-end
  to a database
• Phone-based calendar interface- extend web
  calendar to limited display/interaction
• Speech-based calendar interface- work with speech
• Web Services calendar- expose your calendar as a
  web service

66
Internet Calendaring and Scheduling Core Object
Specification (iCalendar)
67
iCalendar Standards

• RFC 2445 - Internet Calendaring and Scheduling
  Core Object Specification
• Structure and syntax of iCalendar data
• RFC 2446 - iCalendar Transport-Independent
  Interoperability Protocol (iTIP)
• Methods of exchanging and publishing iCalendar
  data
• RFC 2447 - iCalendar Message-Based
  Interoperability Protocol
• Methods of exchanging iCalendar data via e-mail

68
Expedia iCalendar example
69
iCalendar Structure

• Components
• Properties
• Parameters

70
Example
Property
Component

• BEGINVEVENT
• DTSTART20030920T150000Z
• DTEND20030920T163000Z
• SUMMARYProject Group Meeting
• ATTACHFMTTYPEimage/jpeghttp//example.com/image
  s/meeting_place_map.jpg
• ENDVEVENT

value
Parameters
71
Components

• Events (VEVENT)
• has a start and end time (e.g. a meeting)
• Journals (VJOURNAL)
• has a start time with no specific end time (e.g.
  an occurrence of an event)
• Todos (VTODO)
• has a due date (e.g. a task that must be
  completed by a certain date)

72
Properties

• Attendees (ATTENDEE)
• Start date/time (DTSTART)
• End date/time (DTEND)
• Attachments (ATTACH)

73
Attendees

• An attendee is someone who's been invited to an
  event (but may not actually attend)
• ATTENDEEmailtofoo_at_example.com
• The actual status of attending is specified using
  PARTSTAT (participation status) parameter
• ATTENDEEPARTSTATTENTATIVE
• ROLEREQ-PARTICIPANT
• mailtofoo_at_example.com

74
Dates and Times

• Date in format ltYYYYMMDDgt
• e.g. 20030920 for 20th September 2003
• Local time in format ltHHMMSSgt
• e.g. 190000 for 7pm
• Universal time in format ltHHMMSSgtZ
• e.g. 190000Z for 7pm (UTC)
• Date and time in format ltdategtTlttimegt
• e.g. 20030920T190000Z

75
Durations

• Durations in format PlthoursgtHltminutesgt
• e.g. P3H10M is the duration of 3 hours and 10
  minutes

76
Attachments

• Examples of attachments include an agenda or
  minutes of a meeting
• An attachment may be
• an URL
• ATTACHhttp//example.com/report.doc
• encoded binary data
• ATTACHFMTTYPEimage/basic
• ENCODINGBASE64VALUEBINARY
• MIICajCCAdOgAwIBAgICBEUwDQYJKoZIhvc

77
Recurrence

• BEGINVEVENT
• DTSTART20030927T133000
• DTEND 20030927T153000
• SUMMARYFriday meetings
• RRULEFREQWEEKLYBYDAYFR
• EXRULEFREQMONTHLYBYDAYFR
• BYSETPOS-1
• ENDVEVENT

Rule of occurrences
Exception to the rule
78
Specifying Recurrence

• RRULE
• Specifying rule for recurrence
• RDATE
• Specifying dates/times of recurrence
• EXRULE
• Specifying rule for exception to the recurrence
• EXDATE
• Specifying dates/times for exceptions to the
  recurrence

79
Rules of recurrence by frequency

• RRULEFREQltfreqvaluegt
• Possible frequency values are YEARLY, MONTHLY,
  WEEKLY, DAILY, HOURLY, MINUTELY and SECONDLY

80
Frequency Constraints

• Further constraint may be defined using
• BYMONTH, BYWEEKNO, BYYEARDAY, BYMONTHDAY, BYDAY,
  BYHOUR, BYMINUTE, BYSECOND and BYSETPOS
• FREQWEEKLYBYDAYFR
• FREQDAILYBYHOUR8,10,13,15
• FREQWEEKLYBYMONTH6,12

81
Frequency Constraints (cont.)

• INTERVAL
• FREQWEEKLYINTERVAL2 (every other week)
• COUNT
• FREQWEEKLYCOUNT7 (this event will occur 7
  times)
• UNTIL
• FREQMONTHLYBYMONTHDAY20UNTIL20031231Z
  (occur until the specified date)

82
iCalendar software library

• Reefknot project - iCal Perl toolkit
• http//sourceforge.net/projects/reefknot/
• PHP iCalendar
• http//phpicalendar.sourceforge.net/nuke/
• iCalendar C Library libical
• http//sourceforge.net/projects/freeassociation/

83
Related Standards

• vCalendar Predecessor standard of iCalendar
• http//www.imc.org/pdi/
• xCal XML syntax for iCalendar
• http//xml.coverpages.org/iCal.html

84
Software implementing iCalendar standard

• iCal (MAC)
• Outlook 2000
• Lotus Notes
• Mozilla Calendar (http//www.mozilla.org/projects/
  calendar/)

85
What to include in your database
86
U. Washington event schema

• events (
• eventid INTEGER NOT NULL AUTO_INCREMENT PRIMARY
  KEY, key for most tables
• lastmod TIMESTAMP NOT NULL, updated
  automatically on update
• seq INTEGER NOT NULL, number of changes to
  this record
• publicf CHAR(1) NOT NULL, T or F
• created DATETIME NOT NULL,
• startdate DATE NOT NULL,
• starttime TIME,
• enddate DATE NOT NULL,
• endtime TIME,
• shortdesc VARCHAR(255) BINARY NOT NULL,
• longdesc BLOB,
• longdesc1 BLOB,
• longdesc2 BLOB,
• link VARCHAR(255) BINARY, URL
• / T tentative, F confirmed, C
  Cancelled, P postponed /
• status CHAR(1) BINARY NOT NULL DEFAULT 'F',
• locationid INTEGER NOT NULL, key in
  location table
• sponsorid INTEGER NOT NULL, key in sponsor
  table

87
Outlook iCal entry form
To Add from CAP Originator Link
Summary (shortdesc)
event type
recurring_status
location(id)
Start stops
busy/free
Description (longdesc)
88
Things to be dropped from CAP

• Time zone component related entries
• Alarm related entries
• recurrence
• Roles (other than originator)
• Contact
• Related-to
• Geographic position
• etc.

89
2740 Calendar Description

• Implements subset of RFC 2445 CAP
• Includes appointments, and notes
• Contains fields for
• originator
• location
• summary
• description
• link

90
2470 Calendar Description (cont)

• The 2470 calendar contains simplified 2445
  records of type either VEVENT or VJOURNAL.
  VEVENTs have start times lt end times while
  VJOURNALs have start timesend times. VJOURNAL
  entries provide a way to attach text or links to
  the calendar and cover both icalendar VTODO and
  VJOURNAL entry types. VFREEBUSY values are not
  explicitly stored but can be generated from
  VEVENT records if requested.

91
2470 calendar fields (adapted from UW)

• eventid INTEGER NOT NULL,
• event_type CHAR(1) / E VEVENT, J VJOURNAL
  /
• startdate DATE NOT NULL,
• starttime TIME,
• enddate DATE NOT NULL,
• endtime TIME,
• summary CHAR(255),
• description VARCHAR(1023),
• link CHAR(255) URL
• location CHAR(255),
• originator CHAR(255)

92
References

• RFC 2445
• http//www.ietf.org/rfc/rfc2445.txt
• Reefknot/iCalendar Bootstrap Guide
• http//reefknot.sourceforge.net/bootstrap-guide/t1
  .html
• Recurrence Tutorial
• http//tipi.sourceforge.net/doc/recur/