Meeting Scheduling Across Heterogeneous Calendars and Organizations Utilizing Mobile Devices and Cloud Services Varvana Myllärniemi
Olli Korjus
Aalto University, Finland,
[email protected]
Mikko Raatikainen
Aalto University, Finland
Steeri, Finland,
[email protected]
Terho Norja
Steeri, Finland
ABSTRACT
aries. The research questions are set as follows: RQ1: How to enable the e↵ortlessness of meeting scheduling over the boundaries of organizations and calendar systems? RQ2: How to ensure that the users have control over the decided meeting times? RQ3: How to avoid exposing user’s private information while allowing the system to function e↵ectively? We applied the design science approach [5]. The resulting artifact consists of an overall solution, architecture design and a prototype implementation. To ensure the utility against the business needs [5], the artifact was constructed and evaluated with our industrial partner Steeri. The artifact fetches calendar data from heterogeneous calendar sources for each meeting request, instead of utilizing proprietary calendar data sources. By utilizing calendar data both on mobile devices and cloud calendars, we aim at a sufficient variety of prominent calendar systems. To ensure privacy and participant control, the full calendar events are not transferred and even the free/busy times are filtered with user preferences to take into account the meeting context. Finally, due to the inherent complexity of time management, we do not aim at automatically finding an optimal meeting time that is guaranteed to be available for all participants, but aim at supporting the organizer in deciding the time and managing the meeting.
Finding a suitable time for a meeting is a common practical problem. The existing software solutions either cannot be used across heterogeneous calendar systems and organizations, or require manual e↵ort and waiting. We employ design science to study how meetings can be scheduled over organizational and calendar system boundaries; the scheduling should be e↵ortless while ensuring the user control and privacy of the calendar data. The resulting artifact utilizes heterogeneous calendar data from the mobile devices and the cloud calendars; the aim is to aid the organizer in making better decisions regarding the meeting times.1 Categories and Subject Descriptors: H.4.1 [Information Systems Applications]: Office automation Keywords: Meeting scheduling; Mobile device; Cloud calendar;
1.
INTRODUCTION
The mobile device, always connected and carried along, is nowadays one of the primary means of accessing calendars. Mobile devices often synchronize their calendar data from cloud services, such as Google Calendar. While there are data formats, such as iCalendar, that allow sharing the details of an agreed meeting, finding a suitable meeting time is still a common practical problem. Especially when participants work in di↵erent organizations, or utilize di↵erent calendar systems, meeting scheduling often involves sending time suggestions back and forth via e-mail. Although several solutions enable sharing availability, these solutions have shortcomings when scheduling meetings between heterogeneous organizations and calendar systems. With Doodle, the participants typically manually enter their available times to a poll, thus slowing the response. Microsoft Exchange shows available times automatically, but requires that all participants use Exchange and are within the same domain. We investigate the research problem of how to schedule meetings across organizational and calendar system bound1
Tomi Männistö
University of Helsinki, Finland
2.
PREVIOUS WORK
There is research on electronic meeting scheduling [9], also utilizing mobile devices [1], where the aim is to automatically find a common meeting time. This may take into account the invited people, the topic and the system load [10, 4]; be assisted by software agents that learn user preferences [2, 8]; or reschedule conflicting meetings [7]. The studies often assume the participants use the same calendar system; additionally cross-organizational scheduling has been studied [3]. However, many studies aim at minimizing, or completely removing, user involvement through a fully automatic meeting scheduling. This may have an adverse e↵ect on the user experience: the users were more satisfied with the time found through face-to-face discussions although the automatic scheduler resulted in fewer conflicts and compromises; face-to-face scheduling was also perceived to be more efficient and satisfying than e-mail [6]. Thus, people enjoy being in control of their decisions: a completely automatic scheduler takes this control away. In electronic meeting scheduling, the ease of use is the top priority followed by privacy [1]. More than half of the users would be willing to share their free/busy time with the
Carried out in Digile N4S Program funded by Tekes.
Permission to make digital or hard copies of part or all of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. Copyrights for thirdparty components of this work must be honored. For all other uses, contact the Owner/Author. Copyright is held by the owner/author(s). MUM ’14 Nov 25-28 2014, Melbourne, VIC, Australia ACM 978-1-4503-3304-7/14/11 http://dx.doi.org/10.1145/2677972.2678002
224
0. Users form groups to indicate the social context. Users can define personal availability rules for each group. User User
Organizer Organizer
1. Organizer creates a meeting proposal by entering the meeting topic, location, duration, and date range; by selecting a group; and by selecting the invited users. 3. Organizer browses and selects a time slot. Meeting requests are sent via e-mail to all invited users. 5. Organizer can see the participant status and reschedule if necessary.
Device Device // cloud cloud calendar calendar of of the the invited invited user user
2. Free times are queried from calendars; availability rules applied to calculate available times; and commonly available times calculated. Invited Invited user user 4. Invited users respond to the meeting request. An accepted meeting request is added into the calendar.
Device Device // cloud cloud calendar calendar of of the the invited invited user user
Figure 1: The meeting scheduling process embodied in the MSS solution. other meeting participants, while none of them would share all calendar details [1]. This highlights that the full calendar data should never be distributed and even the free/busy times should be regulated and filtered.
3.
tacit knowledge related to calendars, dates and conventions, for example, days near public holidays are not good candidates for important meetings because people often take extra days o↵ or leave early. Further, the organizer can also mitigate the situation in which no commonly available times are found by scheduling the meeting to take place later or selecting a time that is not available to someone. If the latter, the organizer can separately browse the available times for participants that must be present in the meeting. Also the participants have control: the available times are customized by the availability rules; and the participants can ask the organizer to reschedule an important but unsuitable meeting request. Finally, privacy (RQ3) is preserved by making sure the raw calendar data never leaves user’s calendar. Only free times are sent to the MSS; and even the free times are fetched just-in-time for each meeting proposal (Step 2) instead of synchronizing continuously and storing persistently. This is because organizations may be reluctant in letting their employees synchronize the full calendar data to the MSS. The drawback is that the calendars, and in particular the mobile device calendars, may be unreachable. In case some devices cannot be reached, the organizer can try again, abort the scheduling or continue without knowing all available times. Also secondary calendar sources, such as laptops, can be used. Further, since the MSS shows the available times of the invited users, the organizer can only organize meetings with groups that they belong to or with no specific group at all. For scheduling without a group, the users can specify default availability rules that are strict enough to show, or hide altogether, the available times. Finally, because the groups and their members are potentially sensitive information, their visibility and access are regulated: for example, groups can be invitation-only.
RESULTS
The artifact, the Meeting Scheduling Service (the MSS), consists of a solution, an architecture design and a prototype implementation.
3.1
Solution
The meeting scheduling solution is illustrated in Figure 1. Before the meeting scheduling takes place, the users can regulate the way their calendar information is used and shown (Step 0 in Figure 1). Besides free time, the participant availability is determined by the social context as indicated by groups and availability rules. Users can form groups with other users and define private availability rules that customize which times are considered available for different groups. For example, a meeting for group Project can take place on weekdays during office hours whereas an event with group Friends can take place on weekends. Also default availability rules can be defined. Step 1 (Figure 1) starts the actual scheduling process: the organizer enters the meeting details, the invited participants, and the social context as a group. The calendars of the invited users are queried immediately to find the available times (Step 2). The available times are calculated by combining user’s free times in the calendar with the availability rules for the group; this is repeated for all participants to find commonly available times. The organizer can browse the available times and make an educated decision about the meeting time (Step 3). After the time is decided, meeting requests are sent to all invited users via e-mail. The first time the invited users know about the upcoming meeting is when they receive the meeting request (Step 4). The invited users can accept, decline or request the rescheduling of the meeting. This is because there are no guarantees of availability: the selected time may be inconvenient, reserved but not in the calendar, or booked between Step 2 and Step 4. Moreover, the organizer can see the status of responses; resend notifications; reschedule; or cancel due to too few attending (Step 5). The solution enables e↵ortlessness (RQ1) across organizations and calendars: no participant involvement is required for the organizer to see the available times and the available times are shown immediately. The participants only need to respond to a meeting request. To ensure user control (RQ2), the solution is guided by the principle of letting the humans decide. Instead of completely automatic scheduling, the organizer is supported in selecting the time. The organizer has understanding of the
3.2
Architecture Design and Prototype Tool
To realize the overall solution described in Section 3.1, we designed an architecture for the MSS (Figure 2). To calculate the available times for a meeting proposal, the Central service needs to access both the Mobile service and the Cloud calendar service. To access the Mobile service, the design utilizes server push, and in particular, vendor independent long polling; this allows the simulation of pushing information from the server to the clients using standard HTTP. However, any other push technology can be utilized. To access the Cloud calendar service, the design utilizes existing calendar API. In Google Calendar API, the free times can be fetched through freeBusy REST resource; however, the requests from the Central service must be authorized in advance by the users. We also implemented a functioning prototype of the MSS architecture. The prototype contains all interfaces and in-
225
ternal elements of the MSS architecture, and it is possible to perform a complete scheduling process with the prototype (Figure 1). The prototype focused on studying the feasibility of the mobile client and integration with the mobile calendar; thus the integration with the cloud calendar services was not implemented. The Central service and the Web user interface are implemented using the Django web framework. The Mobile service for the Linux-based mobile device is implemented as a Python script file. The utility of the artifact was evaluated by comparing it with existing tools and in expert and user evaluation sessions.
faces. In contrast, Exchange and Google Calendar are able to schedule only across the same calendar system. To summarize the comparison, the MSS is relatively close to Doodle in its cross-organization, cross-calendar support and gives rule-based control over the available times. At the same time, the MSS is similar to Exchange and Google Calendar in the participant e↵ort and quickness of finding the available times. Therefore, it seems that the MSS strikes a compromise of the strengths and weaknesses of the existing tools when scheduling meetings across heterogeneous calendar systems and organizations. The drawback of the MSS is the additional e↵ort required in setting up the service as well as maintaining the availability rules and groups over time.
4.1
4.2
4.
EVALUATION
Comparison to Existing Scheduling Tools
We compare the e↵ortlessness (RQ1) and the user control (RQ2) of the MSS against popular scheduling applications: Doodle, Microsoft Exchange and Google Calendar. Firstly, Doodle is the slowest in finding the available times: the meeting organizer tries to guess good meeting times and then has to wait for the participants to answer. A benefit is that the available times are confirmed by the participant herself, which increases the probability that she can truly attend the meeting. In contrast, the MSS, MS Exchange and Google return available times immediately and automatically (Step 2 in Figure 1) but the available times are only potentially available. Secondly, Doodle requires the most e↵ort from the participants during the scheduling: the participants must manually check their calendars and mark the poll options. (Additionally, Doodle Calendar Connect allows the participants to see how the poll options fit into their Exchange or Google calendars.) After the Doodle poll has been closed, the participants typically have to manually add the meeting event to their calendars. In contrast, the MSS, Exchange and Google only require that the participants confirm a proposed meeting time. Thirdly, the control over availability is the best in Doodle: the participant can freely select from the poll options. The MSS gives less control, but still enables the participants to customize their available times with groups and availability rules. Microsoft Exchange and Google Calendar o↵er little control over the availability. Fourthly, the set-up e↵ort of starting to use Doodle is minimal. Assuming Exchange or Google Calendar is already used within the organization, no additional set-up e↵ort is needed. The MSS requires either mobile application installation or calendar authorization; however, this set-up process does not require any organization-wide measures, but can be performed by a single employee. Fifthly, cross-organizational scheduling is possible as such in Doodle and the MSS. Google Calendar requires explicit sharing between the calendars, with restrictions on the number of sharing. Even more strictly, Exchange typically works only within the same domain: sharing between organizations in di↵erent domains requires extensive measures, such as establishing a federation trust with Microsoft Federation Gateway. Exchange and Google can also publish user’s free/busy times to the Internet, but without scheduling functionality. Finally, Doodle supports scheduling between any calendars types, even paper calendars. The MSS supports all electronic calendars that are either synchronized into supported mobile devices or authorizable through web inter-
Expert and User Evaluations
Two group interviews at Steeri were conducted to evaluate the contribution: one interview with four technical experts and one interview with three end users. With the exception of one expert, the participants had no previous knowledge on the MSS. Both interviews were recorded and transcribed. To evaluate the e↵ortlessness (RQ1), everybody agreed the proposed solution was more e↵ortless than the other available scheduling means between di↵erent organizations. The users thought that these cross-organizational meetings posed unresolved challenges to their daily work and the MSS was an improvement to this practice. The experts were pleased with how much the MSS automates the scheduling process compared to Doodle. In contrast, the users and experts did not consider the MSS to be an improvement to the internal meeting scheduling. To evaluate the user control (RQ2), the users considered the free times and availability rules as a sufficient estimation of the available times. However, the rules do not necessarily guarantee availability: it is common for people to forget to put some appointments into their calendar. Because of this, the experts acknowledged the importance of the rescheduling and status management in the proposed solution. Additionally, the users mentioned that Steeri has established practices on meeting agreement and calendar use, for example, marking travelling time to the calendar events; these practices support the MSS in calculating the available times. The users also identified several future improvements to the user control. For example, meetings could have several organizers, one for each company, that are responsible for managing the status of the meeting on their side. Further, participants could be invited to a meeting, not only by name, but by skills or position. Finally, the availability rules could be made much more complex, e.g., to take into account the agenda of the meeting, or travelling time. To evaluate privacy (RQ3), the experts thought it is acceptable to share available times but only to a limited group of people that the user has voluntarily joined. Thus, it makes sense to restrict those who can be invited to a meeting and whose availability can be shared. The experts observed that the privacy and trust are crucial for the success of the MSS. The experts liked the possibility of companies accessing the MSS from their own trusted mobile clients in case they do not trust a third-party client enough to allow installing it.
5.
DISCUSSION
The MSS solution fetches calendar data both from mobile devices and cloud calendars: neither one of them alone would provide a sufficiently good solution. The benefit of
226
Meeting Scheduling Service (MSS) Create meeting, Select time slot, Organizer Organizer Manage meeting
Edit availability rules Edit user and group data
User User
Calendar in a mobile device
Web user interface Organizer UI User and group management UI
Central service Create meeting; Manage meeting; Edit users and groups; Edit availability rules;
Calendar manager
Mobile service
Submit request response;
E-mail client
Respond to request
Invited Invited user user
Meeting scheduler
Calendar and availability UI
Get events; Modify events;
Send meeting request;
User manager Request free times Update meeting events
Availability rule manager Administrator UI
Send free times;
Request long-term authorization; Get free/busy times; Modify events;
Legend Internal element
External element
Cloud calendar service (e.g. Google Calendar)
Logical operation in interface;
Figure 2: The MSS architecture design. the cloud calendar strategy is greater coverage with one implementation, compared with implementing a proprietary client for each mobile platform. However, the drawback of the cloud calendar approach is that it is still mostly incompatible with Microsoft Exchange. Typically, Exchange servers either assume that the request can be authenticated with the user’s password, or that the requests originate from the same Exchange domain. Thus, our design supports the heterogeneity of calendars with complementary device-based and cloud-based approaches. The ability to utilize mobile devices and cloud calendars makes our approach easier to take into use and less dependent of company policies and IT administration. The owner of the calendar data can fully control whether the MSS is taken into use: she can by herself install the mobile application or authorize the access to her cloud calendar. This enables viral spreading across organizations: the users of the MSS can recommend coworkers from di↵erent organizations to start using the MSS to ease the scheduling of their joint meetings. If the use of the MSS required company-wide solutions, such as installing new proxies or services to Exchange servers, the market potential would be smaller: some company policies may altogether prevent the installation of third-party services within their intranet. Fetching calendar data from mobile devices may a↵ect performance. To reach the mobile devices, we use push technology, and as an example instantiation, long polling. On the server side, this means a potentially large number of parallel open connections although most connections are not usually transferring any traffic. Therefore, a real production server may need to handle up to tens of thousands connections; in such a case, the Central service could be implemented with Tornado web framework. However, even with the current prototype implementation, the response time for gathering the available times from mobile devices (Step 2 in Figure 1) has been quick enough from a user’s perspective, and the devices seem to be able to cope with the battery usage over time. Additionally, all popular mobile phone ecosystems nowadays provide centralized push services: examples include Microsoft Push Notification Service, Apple Push Notification Service and Google Cloud Messaging.
6.
tion and an architecture design, along with a prototype implementation. The utility of the artifact was evaluated in an expert and user evaluation with our industrial partner, Steeri, and by comparing with the existing meeting scheduling tools. Most importantly, the artifact was found to be more e↵ortless in cross-organizational scheduling than current solutions. The user control and privacy are also sufficiently taken into account; the evaluation brought additional ideas for enhancing the user control. As future work, we are piloting the system in real use together with Steeri.
7.
CONCLUSIONS
We studied meeting scheduling across organizational boundaries and between heterogeneous calendar systems, and in particular, the e↵ortlessness, the user control, and the privacy of the user data. To this aim, we proposed a solu-
227
REFERENCES
[1] I. Bilogrevic, M. Jadliwala, P. Kumar, S. S. Walia, J.-P. Hubaux, I. Aad, and V. Niemi. Meetings through the cloud: Privacy-preserving scheduling on mobile devices. Journal of Systems and Software, 84(11):1910–1927, 2011. [2] L. Dent, J. Boticario, J. McDermott, T. Mitchell, and D. Zabowski. A personal learning apprentice. In Conference on Artificial Intelligence, AAAI, 1992. [3] C. Glezer. A conceptual model of an interorganizational intelligent meeting-scheduler (IIMS). The Journal of Strategic Information Systems, 12(1):47–70, 2003. [4] T. Haynes, S. Sen, N. Arora, and R. Nadella. An automated meeting scheduling system that utilizes user preferences. In Conference on Autonomous agents, AGENTS, 1997. [5] A. R. Hevner, S. T. March, J. Park, and S. Ram. Design science in information systems research. MIS Quarterly, 28(1):pp. 75–105, 2004. [6] K. Higa, B. Shin, and V. Sivakumar. Meeting scheduling: An experimental investigation. In International Conference on Systems, Man, and Cybernetics, volume 3, 1996. [7] W. S. Jeong, J. S. Yun, and G. S. Jo. Cooperation in multi-agent system for meeting scheduling. In IEEE Region 10 Conference (TENCON), volume 2, 1999. [8] R. Kozierok and P. Maes. A learning interface agent for scheduling meetings. In Conference on Intelligent User Interfaces (IUI). ACM, 1993. [9] J. Mosier and S. Tammaro. When are group scheduling tools useful? Computer Supported Cooperative Work (CSCW), 6(1):53–70, 1997. [10] S. Sen and E. Durfee. On the design of an adaptive meeting scheduler. In Conference on Artificial Intelligence for Applications, 1994.
