SCORE Project: MeetMe
Title: A Better Meeting Planner
Sponsor: Michal Young
Planning meetings with Doodle is tedious and difficult with more than a few people who each have many constraints. For this project you should create a better meeting planner, one that fills the same purpose as Doodle, but more efficiently (in terms of user time and elapsed time to find a meeting time). It should draw from Google Calendar and/or other widely used calendaring applications to help choose prospective meeting times. It should work (although perhaps not as conveniently) for users who do not use the same calendaring application, or who choose not to share that information. It should respect privacy and security preferences. In particularly, it should make it possible to find a meeting time in common with minimum disclosure of schedule information. An analysis of privacy and security should be an integral part of the project.
Project Description
Many people use Doodle and similar services to find times to meet. When the number of participants is more than three or four, this usually leads to one of two scenarios:
- A poll is distributed with a few proposed meeting times. Each prospective participant has conflicts with at least one of the proposed times. A flurry of email follows, then either a new poll is distributed with agreed candidate times, or else the meeting time is just settled by email.
- To avoid the first scenario, a poll is distributed with many time slots. It is tedious to fill out, but at least it is possible to find an acceptable meeting time in a single round.
To avoid both of these scenarios, we need a meeting time arranger that can start with plausible meeting times, based on the schedules of prospective participants. To find plausible meeting times, the meeting planner should draw from participants' calendars and possibly other sources of information.
Drawing data from a person's calendar or schedule entails dealing properly with issues of privacy, confidentiality, and security.
Project Scope
A minimal meeting planner will have at least the following features:
- It should draw from Google Calendar and/or other widely used calendaring applications to help choose prospective meeting times.
- It should work (although perhaps not as conveniently) for users who do not use the same calendaring application, or who choose not to share that information.
- It should respect privacy and security preferences. In particularly, it should make it possible to find a meeting time in common with minimum disclosure of schedule information. An analysis of privacy and security should be an integral part of the project.
Many enhancements and extensions are possible, including:
- Draw from multiple calendar and scheduling systems, e.g., Google Calendar and Microsoft Outlook, and include a well-documented protocol or interface for including additional calendar systems.
- Support both web-based and email-based responses from prospective meeting participants, on both desktop/laptop and mobile platforms.
- Support complex attendance requirements, e.g., “persons A,B, and C, are necessary; persons X,Y, and Z are invited but not necessary for the meeting; at least two of M,N, and O should be present.”
- Distinguish between preferred meeting times and possible meetings times, flexibly ranking proposed times both by which attendees can attend and by how convenient the time is.
- Handle time zones appropriately and robustly. For example, a teleconference at 3pm for the Seattle participants and midnight for participants in Lisbon and Milano would likely be less desirable than a meeting at 8am for the Seattle participants and 5pm for the Lisbon and Milano participants. Each prospective participant should have an opportunity to say which hours of the day are suitable for meetings.
Process Requirements
Teams may choose a process that they find appropriate, which may also depend on the requirements of a software project course. Whatever process is followed should be adequately described. The sponsor suggests a process that includes early evaluation of use scenarios with mockups or "wireframes".
Whatever process is selected should have robust provision for testing. A good test suite, including both unit and integration or system tests, is an essential part of the delivered system. This may be a challenge when using web components.
The process must also produce a suitable analysis of security and privacy considerations and how they have been addressed. This need not be a lengthy document, but it should be enough to allow a reviewer to convince him or herself that these issues have been addressed sufficiently. Note that it is very unlikely that this can be addressed satisfactorily after implementation. A successful project will address these concerns from the beginning, taking design and implementation approaches that make the analysis simple.
Usability studies are not required, but are highly desirable.
Project artifacts should be hosted on a public repository (such as Github or Bitbucket). The project should be suitable for adoption and extension by other developers by downloading or forking from the repository (which implies adequate developer documentation and lack of gratuitous dependence on the local development environment). Distinct "binary" distributions for users who wish to install the service or client applications may also be desirable.
Environmental Constraints
The sponsor is willing to offer comments on features and usability of client interfaces that run in web browsers on Mac OS or iOS devices, and possibly Android.
It is suggested, but not required, that at least the client interface of the meeting planner be implemented using a modern web framework such as node.js, django, jquery, etc.
Level of Sponsor Involvement
The sponsor will attempt to answer questions within a week throughout the contest period, but responses may be slower in July and August 2015 due to travel and other obligations. If email traffic becomes problematic, a web forum will be established for discussion among contestands and the sponsor.
Sponsor contact: Michal Young, University of Oregon
Project Restrictions
None.
Project FAQ
Answers to selected questions will appear here.