The disclosed technology pertains to multi-user collaboration environments, and more particularly to a unified editable inbox configured to provide multiple users with direct access to editable contents.
Various types of application tools have been introduced or developed for sequential collaboration purposes over the past several years. For example, copy-and-paste functionality, i.e., CTRL-C/CTRL-V (keyboard shortcuts typically used for copy and paste operations), and cut-and-past functionality, i.e., CTRL-X/CTRL-V (keyboard shortcuts typically used for cut and paste operations), have enabled users to temporarily place text on a clip board for subsequent placement in a different portion of the document or a different document altogether. Consider an example in which a first user Roslyn sends an instant message (IM) to a second user Allen, who then selects and copies some of the content from Roslyn's IM and pastes the copied content into a document he is in the process of co-authoring with Roslyn.
In the example, Allen can immediately see the newly added content within the document at his terminal. Until he sends the revised document to Roslyn or saves it on the server, however, Roslyn is unable to see the document in the most current state, i.e., with the newly added content. Thus, one having ordinary skill in the art will recognize that Allen is not really co-editing the document; rather, he is simply using existing tools to weave new content into static information.
The advent of e-mail has also been used in connection with sequential collaboration purposes. For example, when a user replies to an e-mail message, the e-mail editor will typically add quotations marks to the original [or added] content. The editor will often indent or otherwise preface the added text, too. Consider an example in which a first e-mail user Phil sends an e-mail message to a second e-mail user Karen, who wishes to add some comments to the message.
In the example, Karen can prepare a reply message that contains the original message text inline and then intersperse her comments therein. Current systems often use multiple colors, fonts, and visual effects in connection with the added comments to distinguish the added comments from the original content. However, one having ordinary skill in the art will recognize that Karen's actions do not constitute true co-editing; rather, Karen is simply commenting on, i.e., adding comments to, what is essentially static text.
Another problem with current systems is the lack of unity among multiple users that are in the process of co-editing a document. Consider an example in which a user Samantha sends out a document as an attachment to an e-mail, or posts the document on a shared server, and asks the other members of her team to comment on and edit the document. Each team member then makes a copy of the document, edits his or her own separate copy of the document, and then re-posts his or her copy of the document with his or her comments inserted therein. Unfortunately, Samantha quickly discovers that she is left with the task of merging and reconciling all of the individual edits into a single, unified and current version of the document.
Thus, there remains a need for a way to address these and other problems associated with the prior art.
Embodiments of the disclosed technology can include receiving and placing virtually any type of static content received from traditional communication tools such as e-mail, blogs, instant messaging (IM), chat, or text messaging, or retrieved from a file system, into a shared, co-editable environment. For example, a system can merge static content from legacy inboxes or messaging client interactions into shared, editable content. Such a system essentially merges the concepts of “share and then edit” into a single activity: “edit what is shared.”
In certain embodiments, an end user can determine whether certain information, e.g., messages or documents, should be allowed to become co-editable with other users. The user can make such a determination either before the information is to be shared with other users or after it has already been shared, e.g., widely distributed. For example, the user may wish to prevent any editing to a particular document until a certain team deadline, such as a release or launch date, has passed.
A unified editable inbox in accordance with the disclosed technology can create a link from the static, non-editable content to the new shared, co-editable content so that context is not lost. For example, the unified editable inbox can maintain the static, original content as reference material for the corresponding shared, co-editable content. By promoting the original, non-editable content into shared, co-editable content, the original content and intervening revisions would thus be preserved.
Certain implementations can include the integration of version control capability with shared, co-editable content. Such version control can be used to preserve information integrity and context, and can also enable the use of various types of tools pertaining to re-tracing and branching operations. For example, team members can access previous versions of a particular content, back to and including the original version of the content.
The foregoing and other features, objects, and advantages of the invention will become more readily apparent from the following detailed description, which proceeds with reference to the accompanying drawings.
Current e-mail systems and other workflow clients are static and separate from the typical authoring and editing environments that are frequently used for generating collaborative content. In contrast, embodiments of the disclosed technology include a system that is configured to promote non-editable items in a static inbox into shared content that is co-editable. Certain implementations of the disclosed technology include taking the non-editable content out of its original communication modality form and putting it into a web-viewable and co-editable server-based repository where the content can be modified via user interactions at a unified editable inbox.
Such arrangements can advantageously eliminate the need for a user to cut-and-paste or copy-and-paste information from non-editable content areas into co-editable content areas by acknowledging and enabling interactive collaboration. Thus, a unified editable inbox in accordance with the disclosed technology can also be used as a co-editing tool rather than a mere notification service.
The disclosed technology includes at least two different mechanisms for promoting static content in an inbox to shared, co-editable content. A first mechanism can include the promoting of static content before the content is to be shared, e.g., before the content is distributed to all team members. These implementations can provide an integrated application that would enable shared editing of the promoted content. Using these types of arrangements, information shared by a user, such as comments added to a document, can arrive at the other users' inboxes in a particular format such that the newly added content is already accessible to and shareable among the other users. One having ordinary skill in the art will also recognize that it is possible to directly create the content in a co-editable form, i.e., without first creating the static content and later promoting it to a shared content format.
Returning to the example of the e-mail exchange between Phil and Karen, when Phil sends his e-mail message, the message is dynamic in nature and subject to co-editing. Instead of sending a reply to the message, Karen can directly edit the message itself. When Phil later views the message as edited by Karen, he can see Karen's edits directly within the original message. Furthermore, if any other users were copied on the original message sent by Phil, these other users would see the e-mail including all of Phil's original text as well as Karen's edits.
A second mechanism can include the promoting of static content after the content has already been shared. Consider an example in which a user sends an e-mail message or posts a blog entry and then later decides that the sent and/or posted information should be used as the beginning of a shared document. Implementations in accordance with this second mechanism can enable the user to select the previously sent e-mail message or posted blog entry and then promote the selected content in order to make it shareable and co-editable among collaboration partners such as other team members. For example, the system can bring the content from its original state into a new shared content area, e.g., a unified editable inbox, where the co-editing can take place via each user's instance of the unified editable inbox.
Once the system promotes the content to the new shared content area, the system can place several referenced links from the shared content back to the original version of the content. Thus, the origin of the shared content can be preserved in addition to the original version of the shared content. The system can thus also help to show the context of the origin of the original content. The shared content area can include storage space at a shared content repository. A shared content repository in accordance with the disclosed technology can reside on a local or remote database, for example.
Certain embodiments of the disclosed technology can include the utilization of version control capability with respect to the modified content. The provision of versioning and revision control over the shared, co-editable content ensures that no information is lost because previous versions of the content can be recalled and reused. As changes are made to a document, for example, previous versions of the document can be retained. Thus, any individual or group member of a team can go back at any point and retrieve any previous version of the content. There are a number of version control options that can be implemented, such as tagging, titling, and minor/major version marking. For example, a user may tag a particular version with certain information or mark the version as being a minor version or a major version of the content.
Each revision of a particular content can be stored at a shared content repository along with information pertaining to the revision, such as a timestamp as well as the identity of the author of the changes in the corresponding revision. Whereas current systems make repeated copies of a content (which tend to get more convoluted with each change), a shared content repository in accordance with the disclosed technology can be configured to store only a single copy of the actual content. Rather than unnecessarily store each revision in its entirety, the system can store the actual changes as well as information indicating where the changes are located within the content. Thus, while a user comment added to a content can appear inline at the unified editable inbox, the information can be stored separate from the document itself.
In contrast,
One having ordinary skill in the art will appreciate that, while
In addition to the original version 302A, there are two revised versions of the editable content 302B and 302C. The unified editable inbox 300 displays all three versions 302A-302C as an indexed listing. The second version 302B can represent the original version 302A of the content with the additional information, e.g., Andy's comment 306, displayed therein. While the added content is displayed inline by the unified editable inbox 300, the added comment is generally stored separate from the content itself. Added content can be stored in a separate portion of the same shared content storage repository that stores the content itself or in an entirely separate database, for example.
An identifier 304 such as an icon, user photo, avatar, etc., can be used to identify the creator of the original version of the content 302A. The creator of the content in the illustrated example is a user named Jim. Because the original author Jim remains the originating author of the subsequent versions 302B and 302C, the same identifier 304 remains unchanged.
In the example, two other users named Andy and Ted have contributed to the collaboration by posting comments 306 and 308, respectively, to the original version 302A. Because the content is shared and co-editable, the users Jim, Andy, and Ted, and any other team members, are not bound by the limitations of traditional collaboration systems. For example, assuming the original version of the content 302A is an e-mail message from Jim to Andy, Andy and Ted can immediately post their comments 306 and 308, respectively, to the message even though they may be situated in separate, remote locations.
Each version of a shared, co-editable content can be stored in a shared content repository, for example. In certain embodiments, added content can be stored separate from the original content. The system can actively refresh the unified editable inbox of each collaboration participant in real-time by sending the added content as it is received by the system. Thus, a collaborating user can see another user's contribution to a particular version of a content as it happens without having to wait for the user to save the document to the server or distribute the edited document to the other team members.
Each version of the content 302A-302C displayed in the unified editable inbox 300 has a version selector 310A-310C, respectively, that can be used to shift the focus of the unified editable inbox 300 to the selected version of the content. Each version selector 310A-310C can be a simple checkbox, a button, or any other interface component suitable for receiving a directive from the user. Each version selector 310A-310C can have a version indicator 312A-312C, respectively, to provide information corresponding to the version, such as a date/timestamp indicating the specific date and time when the corresponding version was stored, for example. It should be noted that collaborative additions such as the posted comments 306 and 308 or other contributions, such as attachments to the content, can each have their own version selector and version indicator.
By shifting the focus of the unified editable inbox 300 to a different version of the content, it is possible to create a tree structure of content. For example, if a user were to edit the original version 302A rather than one of the revised versions 302B or 302C, the user would be editing a version of the content that does not include any additional content introduced into either of the revised versions 302B and 302C. This could spawn a whole new branch of content within the tree. It would also be possible, if considered appropriate, to merge this branch back into the primary branch of the content, so as to combine the two divergent streams of content.
In the example, each version of the content 302A-302C has a share enable selector 314A-314C, respectively, that the user can use to enable or disable sharing and co-editing capabilities for the corresponding version. Each share enable selector 314A-314C can be implemented as a checkbox, dropdown menu, or other suitable input component. For example, if a user wishes to lock down the original version of the content 302A in the example, the user can use the corresponding share enable selector 314A to disable sharing/co-editing capabilities for that version 302A. Other users would thus be barred from co-editing, e.g., contributing to, the original version 302A.
Share editing of any version can be toggled on or off at any time. Also, certain embodiments can provide a number of options with respect to share editing. For example, certain implementations can enable a user to select particular users from whom co-edit capability is to be prevented. Also, a user can indicate to what extent sharing and editing is to be restricted. For example, a user may wish to share a certain content among team members in a read-only manner. In such situations, the user may designate that sharing of the content is to be granted to all team members but co-edit capability is to be withheld from all team members.
In the example, each version of the content 302A-302C has a corresponding Options button 316A-316C, respectively, that can enable a user to take advantage of a number of different options with respect to the corresponding version. For example, a user can assert Reply or Reply All functionality with respect to the particular version of the content. The user can also forward, print, download, or delete the desired version, among other options. The Options buttons 316A-316C can also provide versioning and share control functionality in addition to or in place of the version selectors 310A-310C and share enable selectors 314A-314C, respectively.
In the example, a first user's desktop computer 404 can provide a unified editable inbox 300 for the first user and a second user's laptop computer 408 can provide a unified editable inbox 300 for the second user. In addition, a third user's PDA 412 can provide a unified editable inbox 300 for the third user. A central repository 418 such as a local or remote database can store shared content once the content has been promoted from the corresponding static content. The central repository 418 can also store content added to the shared content as part of the collaborative process. Alternatively, content added by users can be stored elsewhere, e.g., in a separate data repository.
Consider an example in which a fourth user uses the other laptop computer 410 to send a document to the other team members that are currently active. If the first and second user are currently logged in, they will receive the document, which has been promoted to a shared, co-editable state, at the corresponding instance of the unified editable inbox 300 at each of their respective machines, i.e., desktop computer 404 and laptop computer 408. The second user can then use his personal instance of the unified editable inbox 300 on his laptop computer 408 to contribute to the collaboration by inserting a comment into the document, for example. As the second user edits the document, the first user can see the changes in real-time via his personal instance of the unified editable inbox 300 on his desktop computer 404.
Once the system has received the static content, the system can promote the static content to a shared content format, as shown at 504. For example, the system can create and store a copy of the content in the same form as originally received and then create a new copy of the content in a shareable, co-editable format and store the new copy at a shared content repository. In certain embodiments, the system can promote every static content received from one or more users, e.g., collaboration team members, immediately. Alternatively, the system can promote a static content to a shared content format pursuant to a user directive. For example, a team lead may wish to prevent any co-editing of a certain content until he or she has had a chance to personally review the content.
After promoting the static content to a shared, co-editable content format, the system can then provide the shared content to certain users, such as currently active collaboration team members, as shown at 506. The users can now review and co-edit the content simultaneously. If a user decides to edit the content, the system can save the user's changes to the document and also present the user's changes to the other users in real-time, as shown at 508. Thus, collaboration team members can advantageously review and edit a particular content at the same time without needing to worry about saving a draft before sending it out, etc.
Consider an example in which two different remote users decide to add comments to a particular e-mail message sent to them by a local user. Regardless of whether the system receives the comments from each remote user at substantially the same time, the system can process each added comment in real-time.
In certain embodiments, whenever a remote user edits a shared content, for example, the system can refresh the display of the shared content at the terminal of the other remote users as each change is made, even if the changes are at the level of the individual character. That is, as one user inserts or deletes individual characters within the content, the other users can see these changes being made at the character level as they are being made. Alternatively, the system can perform the refresh after a number of characters or after each word or sentence, or simply after a certain period of time has passed.
The system can also store and present to other users certain annotation information for each edit of a shared content. As used herein, annotation information generally refer to attributes that can be conveyed regarding a corresponding edit, such as “bold” or “inside a table” characteristics as originally presented with respect to the corresponding edit.
Each user can review the shared content and decide whether to add to the collaboration by contributing to the shared content, as shown at 604. For example, each user can post comments and/or attachments to the shared content. As the shared content is edited, each version of the content is saved along with information specific to the corresponding version, as shown at 606. For example, the system can save a version of the content after each added character, word, paragraph, etc., to a shared content repository at a remote database. The system can also store annotation information, as discussed above. For example, the system can store for each edit annotation information corresponding to the edit.
Users can optionally re-visit previous versions of a shared content, as shown at 608. For example, a user can pull up the original version of the content or an early version of the shared content to return to a particular point in the collaboration before certain changes that the user wishes to avoid in a new revision. A user can also take advantage of a number of features offered by the system as part of or in connection with the version control functionality. For example, a first user can direct that the most current version of a content be shown but without the contributions from a certain other user or group.
Users can also optionally direct the system to enable or disable certain sharing and/or edit capability aspects of a particular content, as shown at 610. For example, a user can prevent other users from editing or further editing a particular content by disabling the co-edit capability for those users. The user can lock out individual users or direct the system to treat the content as read-only for all. Users can also control the accessibility of a content to other users for read-only purposes.
General Description of a Suitable Machine in which Embodiments of the Disclosed Technology can be Implemented
The following discussion is intended to provide a brief, general description of a suitable machine in which embodiments of the disclosed technology can be implemented. As used herein, the term “machine” is intended to broadly encompass a single machine or a system of communicatively coupled machines or devices operating together. Exemplary machines can include computing devices such as personal computers, workstations, servers, portable computers, handheld devices, tablet devices, and the like.
Typically, a machine includes a system bus to which processors, memory (e.g., random access memory (RAM), read-only memory (ROM), and other state-preserving medium), storage devices, a video interface, and input/output interface ports can be attached. The machine can also include embedded controllers such as programmable or non-programmable logic devices or arrays, Application Specific Integrated Circuits, embedded computers, smart cards, and the like. The machine can be controlled, at least in part, by input from conventional input devices (e.g., keyboards and mice), as well as by directives received from another machine, interaction with a virtual reality (VR) environment, biometric feedback, or other input signal.
The machine can utilize one or more connections to one or more remote machines, such as through a network interface, modem, or other communicative coupling. Machines can be interconnected by way of a physical and/or logical network, such as an intranet, the Internet, local area networks, wide area networks, etc. One having ordinary skill in the art will appreciate that network communication can utilize various wired and/or wireless short range or long range carriers and protocols, including radio frequency (RF), satellite, microwave, Institute of Electrical and Electronics Engineers (IEEE) 545.11, Bluetooth, optical, infrared, cable, laser, etc.
Embodiments of the disclosed technology can be described by reference to or in conjunction with associated data including functions, procedures, data structures, application programs, instructions, etc. that, when accessed by a machine, can result in the machine performing tasks or defining abstract data types or low-level hardware contexts. Associated data can be stored in, for example, volatile and/or non-volatile memory (e.g., RAM and ROM) or in other storage devices and their associated storage media, which can include hard-drives, floppy-disks, optical storage, tapes, flash memory, memory sticks, digital video disks, biological storage, and other tangible, physical storage media.
Associated data can be delivered over transmission environments, including the physical and/or logical network, in the form of packets, serial data, parallel data, propagated signals, etc., and can be used in a compressed or encrypted format. Associated data can be used in a distributed environment, and stored locally and/or remotely for machine access.
Having described and illustrated the principles of the invention with reference to illustrated embodiments, it will be recognized that the illustrated embodiments may be modified in arrangement and detail without departing from such principles, and may be combined in any desired manner. And although the foregoing discussion has focused on particular embodiments, other configurations are contemplated. In particular, even though expressions such as “according to an embodiment of the invention” or the like are used herein, these phrases are meant to generally reference embodiment possibilities, and are not intended to limit the invention to particular embodiment configurations. As used herein, these terms may reference the same or different embodiments that are combinable into other embodiments.
Consequently, in view of the wide variety of permutations to the embodiments described herein, this detailed description and accompanying material is intended to be illustrative only, and should not be taken as limiting the scope of the invention. What is claimed as the invention, therefore, is all such modifications as may come within the scope and spirit of the following claims and equivalents thereto.
This application claims the benefit of U.S. Provisional Patent Application Ser. No. 61/224,778, titled “COLLABORATION TOOLS” and filed on Jul. 10, 2009, and U.S. Provisional Patent Application Ser. No. 61/236,005, titled “PRESENCE-ENABLED INBOX” and filed on Aug. 21, 2009, both of which are hereby fully incorporated by reference herein. This application is related to U.S. patent application Ser. No. ______, titled “COLLABORATION SWARMING” and filed on Oct. ______, 2009, U.S. patent application Ser. No. ______, titled “INTELLIGENT CO-BROWSING AND CO-EDITING” and filed on Oct. ______, 2009, U.S. patent application Ser. No. ______, titled “AUTO GENERATED AND INFERRED GROUP CHAT PRESENCE” and filed on Oct. ______, 2009, U.S. patent application Ser. No. ______, titled “UNIFIED ADDRESSING, SENDING, AND RECEIVING COLLABORATION SERVICE” and filed on Oct. ______, 2009, and U.S. patent application Ser. No. ______, titled “PRESENCE-ENABLED INBOX” and filed on Oct. ______, 2009, all of which are commonly assigned with this application and are hereby fully incorporated by reference herein.
Number | Date | Country | |
---|---|---|---|
61224778 | Jul 2009 | US | |
61236005 | Aug 2009 | US |