Problem Description Meeting Scheduling across Heterogeneous Calendar Systems and Organizational Borders

Transcription

1 Problem Description Meeting Scheduling across Heterogeneous Calendar Systems and Organizational Borders Background Using electronic calendars has become the most prominent way of managing personal time. Such electronic calendars are increasingly accessed through various mobile devices and web sites. It is typical that the same user has calendar data stored in several places: on various devices and on the server. Consequently, synchronization between these calendar data sources sometimes creates additional hassle. What is also common is that people use the same calendar for work and private life. Sometimes people use different logical calendars to manage work and private life separately, and synchronize these logical calendars to the same device. Also, work life has changed. Employees nowadays manage their own time and calendars. Although secretaries are still used, most people want to feel being in control of their own time. Therefore, they want to affect where the meetings are booked in their calendar. Despite its importance, meeting scheduling is still a practical challenge. While there are data formats, such as icalendar, that allow sharing the details of an agreed meeting, the process of finding a suitable meeting time is still not solved fully. There are several reasons for this. Firstly, many employees have a very tight schedule and a huge number of meetings, hence making it difficult to find commonly available times. Secondly, many employees have to regularly agree meetings across organizational borders. Such meetings may be held with potential customers or vendors, with subsidiaries, or with collaborating companies. Thirdly, there are several prominent electronic calendar systems (Microsoft Exchange and Google Calendar in particular) that are not interoperable. Fourthly, many people are slow to read and respond to s and meeting requests. Hence, when participants work in different organizations, and/or utilize different calendar systems, scheduling a meeting is potentially an arduous and time-consuming task. The typical way to schedule meeting in such a situation is that the participants send meeting time suggestions back and forth via . To ease the meeting scheduling, several software tools enable sharing availability information between the participants. However, when scheduling meetings between heterogeneous organizations and calendar systems, all existing solutions have their specific shortcomings. For example, when using Doodle, the participants have to manually confirm their available times in a meeting request, thus slowing the response. As another example, Microsoft Exchange finds available times quickly without participant involvement, but requires that all participants use the

2 same calendar system and are from the same domain. Sharing calendar information between organizations in different domains requires extensive measures, such as establishing a federation trust with Microsoft Federation Gateway. Finally, Google Calendar similarly finds available times without participant involvement, but requires that the participant uses Google Calendar as well and has explicitly shared her calendar with the meeting organizer. The users of Exchange and Google calendars can also publish their free/busy times to the Internet, but with no editing possibility or scheduling functionality. Table below summarizes the strengths and weaknesses of the current major solutions. Effort needed from the meeting organizer to find available times during the scheduling Effort required from the participants during the scheduling Participant control over the available times and time visibility Effort required to take meeting scheduling service into use Cross-organizational scheduling Scheduling over heterogeneous calendars Doodle MS Exchange Google Calendar Set up a poll. Wait for Automatically and Automatically and the participants' immediately find the immediately find the response, possibly next commonly next commonly days or weeks. available time from the available time from the Results are confirmed participant calendars. participant calendars. availability. Results are only Results are only potential availability potential availability React to an , check one s calendar and manually mark times to the poll. Add the agreed event to the calendar. Full control over what to show as available and to whom. No effort (registration optional). Yes. Across all calendar types, even paper calendars. (=free time). Accept / reject a meeting invitation. Meeting event added automatically to the calendar. No control for the available times (all free times are shown as available); possibility to limit visibility to different persons. Assuming the organization is already using MS Exchange, no additional effort. Requires explicit sharing with limits on the number of shares. No. (=free time). Accept / reject a meeting invitation. Meeting event added automatically to the calendar. No control for the available times (all free times are shown as available); possibility to limit visibility to different persons. Assuming the organization is already using Google Calendar, no additional effort. Requires extensive organization-wide measures in configuring the calendar servers. No. Service vision Our company has decided to implement a meeting scheduling service that combines the best aspects of Doodle, MS Exchange, and Google Calendar (see comparison table). Most importantly, when the meeting organizer wants to set up a meeting, the service should be able to find potentially available times quickly and without any participant involvement. Such

3 potentially available times could be drawn, e.g., from mobile devices, calendar servers, or cloud calendars. Also, instead of having to manually enter availability to a poll, the participants should be able to just react to a meeting invitation. Despite being able to check available times automatically without participant involvement, the meeting scheduling service should allow the participants as much control over the available times as possible. Hence, the available times that are shown to the meeting organizer are not just free time in the calendar, but should be filtered in a way that is specific to the meeting request. Naturally, the meeting scheduling service should be easy to take into use, and should work seamlessly over heterogeneous organizations and different calendar systems. Planned meeting scheduling process Step 0 illustrates how users take our meeting scheduling service into use. Besides registering, the users integrate their calendar with our service. The integration should require as little effort as possible for the users. In addition, Step 0 illustrates how the users can control their availability. The users can define own private availability rules that customize which free times from their calendar are considered available for meetings in different social contexts. As an example, a user can specify that a work meeting can take place on weekdays between 9am and 5pm excluding the lunch hour, whereas a soccer game with friends can take place on Saturdays and Sundays. Also default availability rules can be defined. For example, default rules can restrict access so that only authorized groups and users see any available times. Step 1 starts the actual scheduling process: the organizer creates the meeting proposal by entering the meeting details and the list of the invited participants. The context of the meeting is also indicated to enable selecting correct availability rules.

4 After the organizer has created the meeting proposal, the available times are calculated by combining the free time in the participants calendar with the availability rules that are specific for this social context. The available times are combined to find those times that are available for all participants. Thereafter, the organizer can browse the available times, and make an educated decision about the meeting time slot (Step 3). After the time is decided, notifications about the meeting are sent to all participants. Means for such notification are, e.g., calendar requests or . The first point when the participants know about the upcoming meeting is when they receive the meeting request (Step 4). The invited participants can accept the meeting request, decline, or request that another time is scheduled for the meeting. This is because there are no guarantees that the available times are really available: the selected time may have been reserved or inconvenient but not marked in the calendar, or it may have been reserved between the creation of the meeting proposal and the meeting request. In addition, busy people are often slow to respond to meeting requests. Therefore, our service should mark the selected meeting time slot as tentative in all participants calendar, thus minimizing the possibility for double booking. Moreover, the organizer can see the status of whether and how the invited participants have responded, and resend notifications. The organizer can also decide to reschedule or cancel the meeting if many people have declined the invitation or requested rescheduling. After an invited participant has accepted the meeting request, the meeting is added as a new calendar event into the participant s calendar (Step 5). If rescheduling takes place later on, the corresponding calendar event is also updated. Some important goals for the scheduling service The discussions with the various stakeholders revealed several important goals for the meeting scheduling service. The scheduling service should allow the users to be in control of their own time as much as possible, while allowing automation. Firstly, the service should be guided by the principle of letting the organizer decide. The service does not try to find the best possible meeting time, but it is always the organizer who eventually selects the time for the meeting. The organizer has the best understanding of the tacit knowledge related to calendars and dates, for example, days near national holidays may not be good candidates for important meetings since people often take extra days off near the holiday. These unwritten rules and conventions make it difficult and error prone for the computer to find the best possible meeting time. Further, by letting the organizer decide, the organizer can also mitigate the situation in which no commonly available times are found for a meeting proposal. In that case, the organizer can decide whether it is better to schedule the meeting to take place later, or to select a meeting time that is not available to someone and take the risk that they will miss the meeting. If the latter, the organizer can view the available times of each participant individually, and select a time that is available to at least those persons that are absolutely needed in the meeting. But even those participants that were not available are sent a meeting request; the participants can then decide whether they want to rearrange their own schedules to be able to participate.

5 But also the participants should have control over the meeting scheduling. Although the service finds the available times automatically, it takes into account the user-customized availability rules. Further, the participant can have a say to a meeting request: if the proposed time of the meeting request is not suitable, and the participant still wants to attend the meeting, she can request for rescheduling of the meeting, potentially with a message to explain the reason for this. Therefore, many post-scheduling features are needed, such as rescheduling, canceling, and reacting to responses from participants. Especially rescheduling is important for a good user experience: the organizer should be able to run the scheduling process again without having to re-enter the meeting information and participants. Security and privacy should be ensured in several ways. Since calendar data is sensitive, most organizations would feel reluctant in letting their employees synchronize their full calendar data to a third-party service (that is, to our meeting scheduling service). Hence, it is of utmost priority that that the full calendar data never leaves the mobile device or the external calendar service: only free times are sent to our service. Consequently, the access, transfer, and storage of all calendar-related data must be carefully managed, and only the minimum amount of data should be stored and transferred. Further, since the organizer can browse the available time periods of the invited participants, the possibility to invite participants to a meeting should be regulated. For example, the users can deny showing their available times to strangers. Hence, the service must allow the users to indicate who is allowed to see their available times. Finally, the agreed meeting events and participants are sensitive information, since they may convey information about ongoing collaboration between companies. From the business point of view, support for as many different calendar sources as possible is crucial for the success of our service. (This affects the size of the potential customer base.) Examples of potential sources of calendar data include calendars in mobile devices, calendars in PCs, cloud calendar services, such as Google Calendar and Office365, local calendar applications running on the users devices, and Exchange servers hosted by the participants companies. Accessing calendar information in any of these sources requires careful design. Our technical specialists have warned that Exchange calendars are next to impossible to be accessed from the outside by a third-party service. But authorization to any calendar service or server is not straightforward, since we cannot rely on the participant usernames and passwords directly. Similarly, in order to make sure the use of our service can spread virally, the service must be easy to install and take into use. A single employee working in an organization should be able to take our service into use without the need to ask support from the IT staff. If taking into use requires company-wide installation, it becomes at least cumbersome and in some cases impossible for single users. (Some company IT admins would not trust a calendar-reading, third-party service enough to allow it to be installed into company premises.) Naturally, we should be able to sell our service to companies, and it should be easy to install the service to all employees in the company as a whole.

6 Some open questions The discussions with the various stakeholders revealed several open questions that need to be decided during the design. How to ensure that participants have control over the times that are shown as available to the meeting organizer? Which things should the availability rules take into account? o Meeting organizer or participants? o Meeting purpose (work/leisure/hobby)? o Meeting topic, agenda? o Meeting importance? o Meeting location (and travel time)? o Different levels of availability: available, available but not desired, busy? o Should be easy to define for the user, yet efficient in capturing tacit rules of deciding which times are OK o Should support different contexts, e.g., work and private scheduling How to ensure security and privacy? o What information is sensitive? o How to support collaboration with employees / companies that do not fully trust each other? o How to avoid phishing of sensitive information? How do the users access the service? o How does the functionality or the role of the user affect this? o Native GUI, browser,? How to notify the participants about the upcoming meeting? How do the participants respond? o Various notification options exist, must think about the convenience to the users. How to handle situations in which no commonly available meeting times are found? How to manage the meeting after the meeting time has been selected and participants have been notified? How to make sure that this service is easy to take into use by a single employee in a company? o But also top-down support for whole organizations must be possible What kinds of considerations company IT policies impose on this service? What is the business model of this service, and what implications it has on the architecture? o E.g., in freemium, must distinguish the added value to the paying customer / company How to integrate with various calendars? o How to access calendar data? Just-in-time, synchronization,? o Just-in-time: how to access a device or service, how to deal with unavailability.? o Synchronization: how to deal with synchronization problems, how to ensure data is up to date, how to avoid privacy issues? How to access calendar data on devices? How to support multiple devices from single user? How to access calendar services, e.g., Google Calendar, Exchange, and Office365? How to authorize the access to the calendar data? o Typically, calendar services assume that the calendar data is fetched by a client that is controlled by the calendar owner o We cannot assume the users (or their IT admins) are willing to give their username/password for these calendar services