Calendars Calendaring

Document Sample
Calendars  Calendaring Powered By Docstoc
					Calendars & Calendaring

         Class 3
Setting up & accessing calendar
           Database
   Making connection to Access
// Set up database connection
try {
url ="jdbc:odbc:AddressBook";                 JDBC-ODBC bridge
Class.forName( "sun.jdbc.odbc.JdbcOdbcDriver" );
connect = DriverManager.getConnection( url );     output.append(
    "Connection successful\n" );                Bridge to name
    }
    catch ( ClassNotFoundException cnfex ) {
// process ClassNotFoundExceptions here
    cnfex.printStackTrace();
output.append( "Connection unsuccessful\n" +
    cnfex.toString() ); }
From Peter Wu
From Peter Wu
From Peter Wu
From Peter Wu
From Peter Wu
From Peter Wu
From Peter Wu
From Peter Wu
EXAMPLE
           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
    Summary                      Event Entry
              recurring_status            event type




  location

                                                    duration


                                        busy/free
Journal
Daily View
Weekly view (by slot)
Weekly View (journal)
Monthly view (journal)
Yahoo calendar
 Electronic Calendars in the
Office: An Assessment of User
Needs and Current Technology
     Kincaid C., Dupont P. and Kaye R.
                 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 user’s needs
• Make recommendations for features of electronic
  calendars that would make them substitutes for
  paper calendars
           Survey Methods
• 30 respondents
• Interviewed with 32 questions of three
  categories
  – General calendar usage
  – Electronic calendar usage
  – Automatic scheduler usage
    Questions: general calendar usage

•   Number, type of calendars currently used
•   Usages
•   Calendar accessibility to others
•   Average number of meetings
Questions: electronic calendar usage

• Frequency of usage
• Feature preferred in paper calendars
• Possible enhancements
  Questions: automatic scheduler usage

• Whether it is used, whether it is easy to use
• Suggested enhancements
                 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
   – One’s calendar is rarely accessed by others (usually ask
     directly rather than look at others’ calendar)
          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
      • Don’t lose information
   – Automatic scheduler is not frequently used
      • Unreliable methods
      • More difficult to confirm, cancel (compared to e-mail)
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
            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
How are shared calendars used?
 Information and Context:
Lessons from a study of two
shared information systems
 Dourish, P., Bellotti, V, Mackay W. & Ma, C.
                 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”
     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
                  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
                    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
            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
        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
        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
                    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
                 Context (2)
• Context Components (cont.)
  – Timeliness
  – Organizational status and relevance
     • Degree of relevancy of information to individuals
       and to the organization
      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
A Case Study of Calendar
 Use in an Organization

      Jonathan Grudin
                 +
All-in-one vs. PROFS (circa 1996)
 Defaults matter:
 Hi privacy (free vs. scheduled) All-in-one
 Lo privacy (all you’ve 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?)
Three users (from Palen’s thesis)

         (Sun in more detail)
               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
                       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
                    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
    Social, Individual&
  Technological Issues for
Groupware Calendar Systems
         Palen, L.
    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
           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
        GCS for Interpersonal
          Communication
• Artifacts of temporality: “time-as-artifact”
• Peer judgment: time allocations of
  colleagues
• Privacy managing
• Meeting arranging
• Organization learning: organization’s
  “memory”
     Socio-Technology aspect
• Usage environment impacts the technology
  design
  – Geographically expansions and time zone
    compatibility
  – Security/Privacy Policy
                    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
Augmenting Shared Personal Calendars

    Tullio, J., Goecks E., Mynatt, E. & Nguyen, D.
                     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
              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
      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
   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
 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
         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”
      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
  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
Interpersonal Communication (2)
• Interactions
  – When user moves mouse over a colleague’s
    icon, a menu will appear with colleague’s full
    name and small picture and a link to view
    his/her calendar
  – When a link to colleague’s calendar is clicked,
    his/her calendar will appear side by side with
    the user calendar so that schedules can be
    compared
    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
      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
Internet Calendaring and
 Scheduling Core Object
 Specification (iCalendar)
          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
Expedia iCalendar example
        iCalendar Structure
• Components
• Properties
• Parameters
Property
              Example
                     Component
BEGIN:VEVENT                   value
DTSTART:20030920T150000Z
DTEND:20030920T163000Z
SUMMARY:Project Group Meeting
ATTACH;FMTTYPE=image/jpeg:http://ex
 ample.com/images/meeting_place_map.
 jpg
END:VEVENT                    Parameters
                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)
                Properties
•   Attendees (ATTENDEE)
•   Start date/time (DTSTART)
•   End date/time (DTEND)
•   Attachments (ATTACH)
                   Attendees
• An attendee is someone who's been invited to an
  event (but may not actually attend)
   – ATTENDEE:mailto:foo@example.com
• The actual status of attending is specified using
  “PARTSTAT” (participation status) parameter
   – ATTENDEE;PARTSTAT=TENTATIVE;
      ROLE=REQ-PARTICIPANT:
      mailto:foo@example.com
           Dates and Times
• Date in format <YYYYMMDD>
  – e.g. “20030920” for 20th September 2003
• Local time in format <HHMMSS>
  – e.g. “190000” for 7pm
• Universal time in format <HHMMSS>Z
  – e.g. “190000Z” for 7pm (UTC)
• Date and time in format <date>T<time>
  – e.g. “20030920T190000Z”
                 Durations
• Durations in format P<hours>H<minutes>
  – e.g. “P3H10M” is the duration of 3 hours and
    10 minutes
                 Attachments
• Examples of attachments include an agenda or
  minutes of a meeting
• An attachment may be:
   – an URL
      • ATTACH:http://example.com/report.doc
   – encoded binary data
      • ATTACH;FMTTYPE=image/basic;
         ENCODING=BASE64;VALUE=BINARY:
         MIICajCCAdOgAwIBAgICBEUwDQYJKoZIhvc…
             Recurrence
BEGIN:VEVENT
DTSTART:20030927T133000 Rule of
DTEND: 20030927T153000  occurrences
SUMMARY:Friday meetings       Exception to
RRULE:FREQ=WEEKLY;BYDAY=FR the rule
EXRULE:FREQ=MONTHLY;BYDAY=FR;
  BYSETPOS=-1
END:VEVENT
        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
Rules of recurrence by frequency
• RRULE:FREQ=<freqvalue>
  – Possible frequency values are YEARLY,
    MONTHLY, WEEKLY, DAILY, HOURLY,
    MINUTELY and SECONDLY
       Frequency Constraints
• Further constraint may be defined using:
  – BYMONTH, BYWEEKNO, BYYEARDAY,
    BYMONTHDAY, BYDAY, BYHOUR,
    BYMINUTE, BYSECOND and BYSETPOS
     • “FREQ=WEEKLY;BYDAY=FR”
     • “FREQ=DAILY;BYHOUR=8,10,13,15”
     • “FREQ=WEEKLY;BYMONTH=6,12”
Frequency Constraints (cont.)
– INTERVAL
  • “FREQ=WEEKLY;INTERVAL=2” (every other
    week)
– COUNT
  • “FREQ=WEEKLY;COUNT=7” (this event will
    occur 7 times)
– UNTIL
  • “FREQ=MONTHLY;BYMONTHDAY=20;UNTIL
    =20031231Z” (occur until the specified date)
     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/
           Related Standards
• vCalendar – Predecessor standard of
  iCalendar
  – http://www.imc.org/pdi/
• xCal – XML syntax for iCalendar
  – http://xml.coverpages.org/iCal.html
        Software implementing
          iCalendar standard
•   iCal (MAC)
•   Outlook 2000
•   Lotus Notes
•   Mozilla Calendar
    (http://www.mozilla.org/projects/calendar/)
What to include in your database
     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
  creator VARCHAR(20) BINARY NOT NULL,                      # UWNetID
    /* N = no recurrence, M = master record for an expanded recurrence */
  recurring_status CHAR(1) BINARY NOT NULL DEFAULT 'N‘
        )
    Summary       Outlook iCal entry form                  To Add from CAP
                                                           Originator
    (shortdesc)   recurring_status     event type          Link




location(id)

                                                 Start &
                                                 stops

                                     busy/free
Description
(longdesc)
    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.
      2740 Calendar Description
• Implements subset of RFC 2445 & CAP
• Includes appointments, and “notes”
• Contains fields for
  –   originator
  –   location
  –   summary
  –   description
  –   link
  2470 Calendar Description (cont)
The 2470 calendar contains simplified 2445 records
 of type either VEVENT or VJOURNAL.
 VEVENTs have start times < end times while
 VJOURNALs have start times=end 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.
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)
                 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/