Patent Application
20100088143
Many computer users have adopted electronic calendar applications during the last couple of decades. Even with these electronic calendar applications, most calendar events are scheduled in a manual and time consuming manner. For instance, if a user wants to schedule a meeting with two colleagues, he/she tries to find a suitable date and time for the three participants. The user often sends an email to the colleagues asking if a selected time will work. The colleagues have to review their own calendars and respond to the user. Often several rounds of emails are exchanged before the date and time are agreed upon. The user may also have to find a suitable location, such as an available conference room. Further, if one of the attendees has to cancel the meeting for some reason, the process has to be started anew. The present inventive concepts offer an alternative paradigm for calendar event scheduling that can offer significant time and/or convenience factors to the participants.
The described implementations relate to calendar event scheduling. One system includes a storage component configured to store scheduling constraints relating to at least one user. The system also includes a declarative calendar/calendaring component configured to automatically schedule declarative calendar events for the at least one user based upon the scheduling constraints.
Another implementation is manifested as a technique that presents a declaratively scheduled calendar event to a proposed attendee. The technique also allows the proposed attendee to either accept the declaratively scheduled calendar event or specify constraints that cause rescheduling of the declaratively scheduled calendar event. The above listed examples are intended to provide a quick reference to aid the reader and are not intended to define the scope of the concepts described herein.
The accompanying drawings illustrate implementations of the concepts conveyed in the present application. Features of the illustrated implementations can be more readily understood by reference to the following description taken in conjunction with the accompanying drawings. Like reference numbers in the various drawings are used wherever feasible to indicate like elements. Further, the left-most numeral of each reference number conveys the Figure and associated discussion where the reference number is first introduced.
This patent application pertains to declarative scheduling of calendar events. A calendar event can be a date and time that are reserved, or can be reserved, for one or more users for a given reason(s). A calendar event may exist in a singular instance, multiple parts, and/or be recurring. Traditionally, a user manually or explicitly schedules calendar events by trying to find a time that is clear on his/her calendar and is also clear on the calendar of other desired attendees. This may take a considerable amount of time and communications between the user and the attendees that can basically be considered as lost or unproductive time. In contrast, among other attributes, the present concepts can offer a substantial time saving advantage to the user.
Manually created calendar events 210(1)-210(3) can be presented in a manner that allows them to be distinguished by the user from declaratively scheduled calendar events 212(1)-212(12). In this case, manually created calendar events have a diagonally lined background (indicated at 214), whereas declaratively scheduled calendar events have a cross-hatch pattern (indicated at 216). Other implementations can distinguish between manually created calendar events and declaratively scheduled calendar events utilizing other mechanisms, such as color. Distinguishing manually scheduled calendar events can offer several potential advantages to users of the calendar application as will described in more detail below. Briefly, one potential advantage is that the user, or another user, such as the user's manager can readily identify which calendar events on graphical window 200 are declaratively scheduled.
Accordingly, in some manifestations, the user and/or the manager may be allowed to manually schedule a calendar event over (in conflict with) an existing declaratively scheduled calendar event. In such a case, the calendar application can reschedule the declarative event at another date and time that satisfies the associated constraints. Further, this configuration may provide useful information relating to the ramifications of scheduling calendar events.
The present implementations offer system users flexibility in how many constraints are selected for a specific declaratively scheduled event. (An example of an interface for selecting constraints is described below in relation to
For discussion purposes, assume that the user's manager views graphical window 200 Thursday night at 5:00 P.M. and wants to assign the user a calendar event in the form of a task (hereinafter, “manager's task” specifically designated in
The suggested common constraints region 604 can be offered as a potential time saver to the user and can include a predefined list and/or a list that reflects the user's constraint selections in previous declarative scheduling scenarios (i.e., automatically offer the user his/her previous selections). The add constraints region 606 offers the user the option of manually entering constraints in an instance where the suggested constraints do not apply and/or do not include some or all of the constraints that the user wants to define for the calendar event. Constraints selected by the user from either or both of the suggested common constraints region 604 and the add constraints region 606 can be populated into a selected constraints region 608.
In the illustrated configuration, suggested common constraints region 604 shows two common constraints in the form of attendee(s) 610 and completion 612. The attendee(s) constraint is populated with two options. First, the user can select specific individuals at 614 or by department at 616. For instance, consistent with the earlier discussion, the user may select him/herself, Jen, and Auriana for a calendar event at 614, such as from a drop down menu (not specifically shown). Alternatively, the user may have a new project and specify a representative from the sales department, a representative from the marketing department, and a representative from the creative department under the departments option 616. In the latter scenario, the system that generates the graphical window can access organizational structure information to select the attendees. Usually, the user knows the attendees that he/she desires for a calendar event, but such not need be the case. For instance, the user may simply enter a constraint that someone needs to go to the receptionist's desk everyday between 10:00 and 10:15 so that the receptionist can go on break. The user does not necessarily need to know who is available or what attendee is most appropriate. Though not specifically shown, a dropdown menu of other means for selecting individual and/or department representatives may be provided for the user.
Several options are supplied under the completion constraint 612. For instance, the user can select a complete by date 618 for the calendar event and/or a schedule before some other event(s) 620 and/or schedule after some other event(s) 622. For instance, the user may specify that the calendar event has to be scheduled by the end of the week and after the management meeting.
The add constraints region 606 allows the user the option of manually entering constraints that may not be available in the suggested common constraints section. For instance, the user may specify that they need a certain percent of the specified attendees to be able to attend the calendar event. Such a constraint may be useful in a scenario where the user needs a quorum for voting purposes at the calendar event.
As mentioned above, the user's selected constraints can be auto-populated into the selected constraints region 608 for further consideration. Selected constraints region 608 can allow the user an option of ranking or prioritizing individual selected constraints at 624 and deleting individual selected constraints at 626. Ranking can allow the user to specify the relative importance of individual constraints. Such a feature can be especially useful for scheduling calendar events for lots of attendees and/or for attendees that have very crowded calendars. For instance, the user may specify that the complete by date 618 has highest priority so that at least some type of meeting occurs before a given deadline.
When the user is satisfied with the defined (i.e., selected) constraint(s) the user can click to schedule the calendar event at 628. The calendar event can then be declaratively scheduled for the user based on the selected constraints with reduced, or no, further actions on the part of the user.
In another implementation, the user may define constraints for a proposed calendar event and send the constraints to proposed attendees for review. The proposed attendees can accept or redefine the constraints. Once the constraints are agreed upon, the event can be declaratively scheduled based on the agreed upon constraints.
In some implementations, the user may predefine how he/she wants declaratively scheduled calendar events to be presented. For instance, the user could select from the configuration presented in relation to
In this manifestation, server computer 902 includes a declarative calendar component 914, a constraint satisfaction component 916, and a storage component in the form of a declarative calendar database 918. The declarative calendar component 914, constraint satisfaction component 916, and declarative calendar database 918 can operate cooperatively to create declarative calendar user interfaces such as those described above in relation to
Declarative calendar component 914 can generate user interfaces related to declarative event calendars and/or calendaring. The declarative calendar component can obtain constraints from a user and/or declarative calendar database 918 and send the constraints to constraint satisfaction component 916. The constraint satisfaction component can operate on these constraints to declaratively schedule calendar events. This information is returned to the declarative calendar component 914 which can cause appropriate interfaces to be generated on computers 904-908 for the respective users 912(1)-912(3).
The configuration of system 900 can be termed a distributed or centralized configuration in the declarative calendar component 914, constraint satisfaction component 916 and declarative calendar database 918 that contribute to accomplishing declarative calendar event scheduling are located on the server computer 902. In other configurations, some or all of these components 914-918 may alternatively or additionally be manifest on one or more of computing devices 904-908.
In the present discussion, smart phone 908 can be representative of any number of ever evolving classes of computing devices that can offer one or more of the following: cellular service, internet service, and some processing capabilities combined with a human interface such as a graphical interface. Other current examples of this class can include personal digital assistants and cell phones, among others. Similarly, PCs 904-906 can alternatively be manifest as Apple brand computers, Linux based computers, thin clients, and set-top boxes, among others.
Block 1002 enables a user to request declarative scheduling of a calendar event. In some configurations, declarative scheduling may be the sole option provided to the user. In other configurations, the user may be able to select between traditional scheduling (i.e., the user selects the date and time) and declarative scheduling. A non-limiting example of a user interface for accomplishing block 1002 is described above in relation to
Block 1004 allows the user to define constraints associated with the calendar event. Non-limiting examples of constraints that may be defined in relation to block 1004 are described in the discussion above relating to
Block 1102 presents a declaratively scheduled calendar event to a proposed attendee. Two non-limiting examples of user interfaces for accomplishing block 1102 are described above in relation to
Block 1104 allows the proposed attendee to either accept the declaratively scheduled calendar event or specify constraints that cause rescheduling of the declaratively scheduled calendar event. Causing the proposed attendee to specify additional scheduling constraints if he/she does not want to accept can provide a basis for rescheduling the proposed declaratively scheduled calendar event. Other configurations can allow a proposed attendee to decline an invitation without specifying additional constraints. However, such a configuration may have a higher likelihood that the subsequent invitation will also be declined since the system lacks constraint information (i.e., why was the proposed event declined) from which to reschedule.
Block 1202 detects a change in a declaratively scheduled calendar event. For instance, a user may want to manually, or via declarative scheduling, change the calendar event. For example, an attendee may not be able to attend a declaratively scheduled meeting or a manager may want to assign another task to a user that has a higher priority than the declaratively scheduled calendar event.
Block 1204 recognizes an impact on a declarative constraint associated with the declaratively scheduled calendar event. For instance, say the declarative constraint is that all managers have to be present and unanimously give final approval of a product before a ship date. If at block 1202 one of the managers cancels attendance to the manager's meeting, then at block 1204 the technique may recognize that the constraint of getting the product shipped on the ship date may be affected by the cancellation.
The technique can initiate user-notification relating to the impact at block 1206. The notification may be made at the time of the proposed cancellation (i.e., before the user selects to either approve or cancel a proposed change). So for instance, when a user selects that he/she wants to cancel the meeting (or his/her attendance) a notice may appear of the impact so that the user can select to go ahead and make the change or cancel the change. For example, this notice may be manifest as a user-interface that specifies the proposed change (e.g., cancelling the meeting) and lists the impacts of the change. The user-interface can include buttons from which the user can either expressly make the change or cancel the change. In either case information regarding the impact is provided so that user can make an informed decision.
The user-notification may be provided to one or more of, the user attempting to make the change and users tied to the constraint, among others. So, for instance, the user-notification may be provided to all managers who are responsible for meeting the ship date and/or a director who established the ship date as a declarative constraint. This feature can allow relevant participants and/or users to see the impact of any changes made to the declarative calendar system.
The user-notification may be manifested differently for different involved (i.e., tied) users. For instance, as mentioned above, a user-interface generated for the user actually initiating the change may have a different appearance than the user-notification provided to other involved users.
The present concepts can allow users to more easily schedule calendar events. For instance, the user simply defines one or more constraints relating to the calendar event and it can be automatically declaratively scheduled on the user's behalf without further effort. The concepts can also offer information to users about potential ramifications of scheduling calendar events. For instance, scheduling a new project with a high priority may cause another project to be delayed. The user can then decide whether to go ahead and schedule the new calendar event, change its constraints, or cancel it based upon this information.
Many of the examples described above relate to a business context. Other business examples may allow some or all of the complex manual scheduling now performed by an operation manager to be automatically completed via declarative scheduling. Further, declarative scheduling could improve employee morale. For instance, when dealing with multiple employees, operation managers often become frustrated with employee scheduling requests and as a result disregard them all. With declarative scheduling, the operation manger can enter that “employee A prefers not to work Fridays” and “employee B prefers to work afternoons” as constraints. These constraints may be assigned a low priority, but the declarative event scheduling system will automatically satisfy them if possible.
The present concepts also lend themselves to social settings. For instance, say a user wants to keep in touch with friends. The declarative scheduling system might offer a constraint such as “keep in touch by having lunch” with my friends at least one time per quarter. Then these lunches automatically get scheduled via declarative scheduling.
Although techniques, methods, devices, systems, etc., pertaining to declarative scheduling scenarios are described in language specific to structural features and/or methodological acts, it is to be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or acts described. Rather, the specific features and acts are disclosed as exemplary forms of implementing the claimed methods, devices, systems, etc.
