Mobile devices (e.g., cell phones, personal digital assistants (PDAs), etc.) are being configured to support an increasing amount and variety of applications. For example, a mobile device may include telephone applications, organizers, email applications, instant messaging (IM) applications, games, cameras, image viewers, etc. Mobile devices may connect with other devices to obtain scheduling/calendar information of other people. The scheduling information may be used to schedule meetings/events for groups of proposed attendees. However, it is extremely difficult to display overlapping schedules of proposed attendees in a usable way to determine availability for a meeting/event.
The following detailed description refers to the accompanying drawings. The same reference numbers in different drawings may identify the same or similar elements. Also, the following detailed description does not limit the invention.
Systems and/or methods described herein may provide an event scheduling interface to enable a user to easily identify availability of potential attendees. An event object may be provided with attendee dependencies. User input, such as a touch on a touch-sensitive screen, may be applied to move the event object over a calendar or another time-based representation. Indicators (e.g., icons, images, etc.) of potential attendees may show the availability of each attendee during the time period within the calendar where the event object rests. Thus, availability of the potential attendees may be indicated in real-time by “dragging” the event object over different time periods on the calendar representation.
Event object 110 may represent a particular duration (e.g., one hour) that may be defined by the user. For example, set meeting duration icon 140 may provide a menu from which a user may select a particular duration (e.g., 30 minutes, 1 hour, half-day, etc.). In another implementation, the duration of event object 110 may be adjusted using incremental controls, such as incremental controls 145, or other user interface techniques. Event object 110 may be associated with schedules of the potential attendees indicated by representations 130. For example, a user may select add/remove attendee icon 150 which may provide a menu from which a user may select contacts to add to the group of potential attendees. Each potential attendee may have a separate representation 130. Event scheduling interface 100 may also optionally include a find next available icon 160. Find next available icon 160 may provide a user with a recommendation of the earliest time period (relative to a current time period) without conflicts available to all potential attendees. Schedule meeting icon 170 may also be optionally included to automatically initiate a meeting invitation for potential attendees at a time period selected by the user.
In the exemplary implementation of
Although
As illustrated in
Speaker 220 may provide audible information to a user of device 200. Speaker 220 may be located in an upper portion of device 200, and may function as an ear piece when a user is engaged in a communication session using device 200. Speaker 220 may also function as an output device for music and/or audio information associated with games and/or video images played on device 200.
Display 230 may provide visual information to the user. For example, display 230 may display text input into device 100, text, images, video, and/or graphics received from another device, and/or information regarding incoming or outgoing calls or text messages, emails, media, games, phone books, address books, the current time, etc. For example, display 230 may include a liquid crystal display (LCD), such as a thin film transistor (TFT) LCD, etc.
In one implementation, display 230 may include a touch screen display that may be configured to receive a user input when the user touches (or comes in close proximity to) display 230. For example, the user may provide an input to display 230 directly, such as via the user's finger, or via other devices, such as a stylus. User inputs received via display 230 may be processed by components and/or devices operating in device 200. The touch-screen-enabled display 230 may permit the user to interact with device 200 in order to cause device 200 to perform one or more operations. Exemplary technologies to implement a touch screen on display 230 may include, for example, a near-field-sensitive (e.g., capacitive) overlay, an acoustically-sensitive (e.g., surface acoustic wave) overlay, a photo-sensitive (e.g., infra-red) overlay, a pressure sensitive (e.g., resistive and/or capacitive) overlay, and/or any other type of touch panel overlay that allows display 230 to be used as an input device. The touch-screen-enabled display 230 may also include the ability to identify movement of a body part or a pointing device as it moves on or near the surface of the touch-screen-enabled display 230.
Control buttons 240 may permit the user to interact with device 200 to cause device 200 to perform one or more operations. For example, control buttons 240 may be used to cause device 200 to transmit information and/or to activate event scheduling interface 100 on display 230. Microphone 250 may receive audible information from the user. For example, microphone 250 may receive audio signals from the user and may output electrical signals corresponding to the received audio signals.
Although
Processor 300 may include one or more microprocessors, application specific integrated circuits (ASICs), field programmable gate arrays (FPGAs), or the like. Processor 300 may control operation of device 200 and its components. In one implementation, processor 300 may control operation of components of device 200 in a manner described herein.
Memory 310 may include a random access memory (RAM), a read-only memory (ROM), and/or another type of memory to store data and instructions that may be used by processor 300. In one implementation, memory 310 may store data used to display a graphical user interface, such as quick-access menu arrangement 100 on display 230.
User interface 320 may include mechanisms for inputting information to device 200 and/or for outputting information from device 200. Examples of input and output mechanisms might include buttons (e.g., control buttons 240, keys of a keypad, a joystick, etc.); a speaker (e.g., speaker 220) to receive electrical signals and output audio signals; a microphone (e.g., microphone 250) to receive audio signals and output electrical signals; a display (e.g., display 230) to receive touch input and/or to output visual information; a vibrator to cause device 200 to vibrate; and/or a camera to receive video and/or images.
Communication interface 330 may include, for example, a transmitter that may convert baseband signals from processor 300 to radio frequency (RF) signals and/or a receiver that may convert RF signals to baseband signals. Alternatively, communication interface 330 may include a transceiver to perform functions of both a transmitter and a receiver. Communication interface 330 may connect to antenna assembly 340 for transmission and/or reception of the RF signals.
Antenna assembly 340 may include one or more antennas to transmit and/or receive RF signals over the air. Antenna assembly 340 may, for example, receive RF signals from communication interface 330 and transmit them over the air, and receive RF signals over the air and provide them to communication interface 330. In one implementation, for example, communication interface 330 may communicate with a network and/or devices connected to a network.
As will be described in detail below, device 200 may perform certain operations described herein in response to processor 300 executing software instructions of an application contained in a computer-readable medium, such as memory 310. A computer-readable medium may be defined as a physical or logical memory device. A logical memory device may include a space within a single physical memory device or spread across multiple physical memory devices. The software instructions may be read into memory 310 from another computer-readable medium or from another device via communication interface 330. The software instructions contained in memory 310 may cause processor 300 to perform processes that will be described later. Alternatively, hardwired circuitry may be used in place of or in combination with software instructions to implement processes described herein. Thus, implementations described herein are not limited to any specific combination of hardware circuitry and software.
Although
Object controller 410 may generate and update an event object (e.g., event object 110) that links an event (e.g., a meeting) duration with scheduled availability for potential attendees. In one implementation, object controller 410 may receive user input to define an event duration and to define potential attendees for the event. Object controller 410 may retrieve (e.g., from data collector 420) schedule information for each of the potential attendees. Object controller 410 may receive user input to position the event object on a calendar display and may calculate the availability of each of the potential attendees in relation to the position of the event object on the calendar display.
Object controller 410 may identify basic information about each potential attendee (e.g., a graphic, such as an image, associated with the attendee that may be associated with one of peripheral applications 440) and create a contact-related graphic (e.g., representation 130) for each potential attendee based on the basic information. In one implementation, object controller 410 may assemble icons and/or graphics based on one or more templates retrieved from GUI data 430. Templates may include, for example, arrangements for calendars/timelines (e.g., calendar 120) upon which the event object may appear to exist, defined locations for contact-related graphics, and/or other user-input buttons (e.g., set meeting duration icon 140, add/remove attendee icon 150, find next available icon 160, schedule meeting icon 170, etc.). Object controller 410 may also provide signals to alter the display of contact-related graphics for potential attendees based on the availability of each the potential attendees at a time period associated with the current location of the event object.
Data collector 420 may receive user input that identifies potential attendees to associate with the event object (e.g., event object 110) and retrieve scheduling data for each potential attendee. In some implementations, user input may be received directly by data collector 420 or indirectly through object controller 410. In one implementation, data collector 420 may retrieve scheduling data for each potential attendee by requesting information from a service provider (using, e.g., communication interface 330, to contact a server of the service provider) that has access to scheduling data for each potential attendee. In another implementation, scheduling information may be retrieved using peer-to-peer sharing techniques with one or more other devices. Data collector 420 may retrieve the scheduling information for each of the potential attendees and store the information (e.g., in memory 310) for object controller 410 to use in calculating attendee availability. In one implementations, data collector 420 may retrieve schedule information for a particular time period (e.g., one week or one month from the current time) to conserve memory use in device 200.
GUI data 430 may include information that may be used by object controller 410 to compile graphics for event scheduling interface 100. GUI data 430 may include, for example, user preferences, images and/or templates. User preferences may include, for example, format preferences for the calendar/timeline arrangement, such as font/icon sizes, viewable time-spans (e.g., one day, multiple days, weeks, etc.), images, and/or display size. Images may include, for example, images representing potential attendee(s), background images for templates, skins (e.g., custom graphical appearances), etc. Templates may include formats for event scheduling interface 100 to which particular scheduling information may be supplied for presentation on a display (e.g., display 230).
Peripheral applications 440 may include applications that may receive, generate, or manipulate schedule information for one or more potential attendees. In some implementations, peripheral applications 430 may be stored within a memory (e.g., memory 310) of device 200 and/or stored on a remote device that can be accessed over a network. Peripheral applications 440 may include, for example, data conversion applications to translate scheduling information into a format useable by event scheduling interface 100. Peripheral applications 440 may also include any application from which scheduling information or potential attendee information may be obtained, such as a telephone application, a text-messaging application, an email application, an instant messaging (IM) application, a calendar application, a multimedia messaging service (MMS) application, a short message service (SMS) application, an image viewing application, a camera application, an organizer application, a video player, an audio application, a GPS application, etc.
Although
Because a 1.5 hour meeting is desired (for the present example), user input 500 may be applied to incremental control 145 to increase the duration of meeting object 110. In other implementations, the duration of meeting object 110 may be altered using set duration meeting icon 140, which may open another window to provide controls/settings for event object 110.
As shown in
As shown in
Referring to
Referring to
Referring to
As illustrated in
In another exemplary implementation where a touch-screen is not used, device 200 may identify a particular user input associated with the location of a cursor (guided, e.g., by the mouse, touch-panel, or other input device) on the event scheduling interface 100. In still another exemplary implementation, device 200 may identify user input for a particular icon/command associated with event duration or proposed attendees based on the direction from a keypad or control button, such as an arrow, trackball, or joystick.
Schedule information for the proposed attendees may be retrieved (block 630). For example, device 200 (e.g., data collector 420) may retrieve scheduling data for each potential attendee identified by activities in block 620. Data collector 420 may retrieve scheduling data for each potential attendee by requesting information from a service provider (using, e.g., communication interface 330 to contact a server of the service provider) or from one or more devices associated with the potential attendees. For example, a calendar program for a potential attendee may store information of previously scheduled events that may preclude availability of the potential attendee during particular time periods. Information from the calendar program may be retrieved directly (or indirectly) by device 200.
An event object may be generated (block 640). For example, device 200 (e.g., object controller 410) may create an event object (e.g., event object 110) for the selected event duration that is linked to the scheduling data for each potential attendee. In one implementation, the event object may be presented as a graphical object that can be moved in time along a calendar representation (e.g., calendar 120). The event object may include potential attendee dependencies that can register potential attendee availability (or unavailability) for the time-period defined by the location/duration of the event object.
User input to locate the event object may be detected (block 650). For example, as described above with respect to
Attendee availability associated with the location of the event object may be displayed (block 660). For example, device 200 (e.g., object controller 410) may provide a representation (e.g., representation 130) of each potential attendee to indicate availability/unavailability of each attendee for the time period defined by the location/duration of the event object. As described above with respect to
It may be determined if there is a change of location of the user input for the event object (block 670). For example, device 200 may identify a change in the touch location, the cursor location, or the control button direction that corresponds to a movement of event object 110. As another example, device 200 may identify user input to a find next available icon (e.g., find next available icon 160) that may cause device 200 to automatically identify the next available time period for which no conflicts exist and move the event object to the corresponding location. If a change of location of the user input for the event object is detected (block 670—YES), process 600 may return to block 660 to display attendee availability associated with the location of the event object.
If no change of location of the user input for the event object is detected (block 670 NO), deactivation of the event object may be detected. For example, device 200 may eventually detect removal of the user input from the event object. Removal of the user input may include, for example, removal of the touch from the touch sensitive display, release of a mouse-click associated with a cursor, or pressing of a dedicated control button. In response the detected deactivation, device 200 may continue to display the event object at its most recent location and the representation of each potential attendee to indicate availability/unavailability of each attendee for the time period defined by the location/duration of the event object.
A meeting invitation interface may be provided (block 690). For example, once a user identifies a particular time that is acceptable (e.g., has no attendee conflicts or has an acceptable quorum) for the planned event, user input may be provided to open a meeting invitation interface (e.g., schedule meeting icon 170). In one implementation, the meeting invitation interface may launch one or more peripheral applications (e.g., peripheral applications 440) that may be used to send meeting announcements to the potential attendees previously identified by the user. For example, device 200 may launch an email application and provide a draft email with the address of each potential attendee and/or the meeting time information.
Touch-sensitive display 720 may include a display screen integrated with a touch-sensitive overlay. In an exemplary implementation, touch-sensitive display 720 may include a capacitive touch overlay. An object having capacitance (e.g., a user's finger) may be placed on or near display 720 to form a capacitance between the object and one or more of the touch sensing points. The touch sensing points may be used to determine touch coordinates (e.g., location) of the touch. The touch coordinates may be associated with a portion of the display screen having corresponding coordinates, including coordinates for a multi-button menu icon. In other implementations, different touch screen technologies may be used.
Touch-sensitive display 720 may include the ability to identify movement of an object as the object moves on the surface of touch-sensitive display 720. As described above with respect to, for example,
Touch panel 820 may be operatively connected with display 830 to allow the combination of touch panel 820 and display 830 to be used as an input device. Touch panel 820 may include the ability to identify movement of an object as the object moves on the surface of touch panel 820. As described above with respect to, for example,
Systems and/or methods described herein may include receiving a user input to associate two or more contacts with an event object, retrieving scheduling information for each of the two or more contacts, and presenting, on a display, a calendar presentation and the event object located within the calendar presentation. Systems and/or methods described herein may further include receiving a user input to move the event object to multiple locations within the calendar presentation, where each of the locations of the event object within the calendar presentation is associated with a different time period, and presenting an indication of the availability of each of the two or more contacts for each time period associated with the position of the event object.
The foregoing description of implementations provides illustration and description, but is not intended to be exhaustive or to limit the invention to the precise form disclosed. Modifications and variations are possible in light of the above teachings or may be acquired from practice of the invention.
For example, while implementations have been described primarily in the context of a mobile device (such as a radiotelephone, a PCS terminal, or a PDA), in other implementations the systems and/or methods described herein may be implemented on other computing devices such as a laptop computer, a personal computer, a tablet computer, an ultra-mobile personal computer, or a home gaming system.
Also, while a series of blocks has been described with regard to
It will be apparent that aspects described herein may be implemented in many different forms of software, firmware, and hardware in the implementations illustrated in the figures. The actual software code or specialized control hardware used to implement these aspects is not limiting of the invention. Thus, the operation and behavior of these aspects were described without reference to the specific software code—it being understood that software and control hardware may be designed to implement these aspects based on the description herein.
Further, certain portions of the invention may be implemented as “logic” that performs one or more functions. This logic may include hardware, such as an application specific integrated circuit or a field programmable gate array, or a combination of hardware and software.
Even though particular combinations of features are recited in the claims and/or disclosed in the specification, these combinations are not intended to limit the disclosure of the invention. In fact, many of these features may be combined in ways not specifically recited in the claims and/or disclosed in the specification.
No element, act, or instruction used in the present application should be construed as critical or essential to the invention unless explicitly described as such. Also, as used herein, the article “a” is intended to include one or more items. Where only one item is intended, the term “one” or similar language is used. Further, the phrase “based on” is intended to mean “based, at least in part, on” unless explicitly stated otherwise.