This invention relates generally to computer workspaces in cloud-based software applications and, more specifically, to a system and method for syncing content across the pages of the workspace.
The traditional computer workspace includes document editors, where a page is the fundamental unit. Information added to a page is stored in files and folders and locked within such a construct. For a similar piece of information to exist at a different location, it must be retyped at the new location or copied and pasted there, so that the same information is stored in two locations. Any changes to the original piece of information would have to be manually entered into the new location or manually copied and pasted to update the information. While such a model has been accepted for decades, it is also functionally limiting and inefficient within the interconnected world we live in. While some progress has been made related to the use of containers of content that can exist at different locations and be synced together, setting up such containers in a conventional system is not intuitive and requires time and many steps to accomplish. Therefore, there is a need to change the model such that information on a workspace page would be dynamic and able to stand on its own, for example, within a hierarchy of blocks, and for instances of the information to be able to exist in multiple locations and be cross-referenced bi-directionally.
The present disclosure describes a system, method, and computer program for syncing content across workspace pages. The method is performed by a computer system that includes servers, storage systems, networks, operating systems, and databases.
The present invention provides a completely different paradigm for computer workspaces. It is based on a hierarchical block data model, where each piece of information in a workspace page is stored as separate objects in a database. This is different from how most text editors store information. Each block has a list of attributes including: a unique identifier, a type, a list of properties, a format, a list of child blocks, and a pointer to its parent block. One benefit of the block data model is that if a user has a piece of information that he or she wishes to present on a plurality of workspace pages (e.g., public webpages, private workspaces, etc.), the user can place instances of a block having that piece of information on the plurality of workspace pages. The plurality of workspace pages on which the user places instances of the block may be within the same workspace or in different workspaces. The present invention describes various methods for syncing the instances of the block such that a change to the piece of information on one block results in an update to the piece of information on all the synced blocks.
In one embodiment, a method for syncing content across workspace pages comprises the following steps:
The present disclosure describes a system, method, and computer program for syncing content across workspace pages. The method is performed by a computer system that includes servers, storage systems, networks, operating systems, and databases (“the system”).
1. Block Data Model
A block data model is comprised of one or more blocks, which are content containers. All blocks in the block data model are content blocks. The content of a block can take many forms. For example, the content can comprise text, images, lists, a row in a database, pages, or one or more child blocks. Some blocks may have one type of content, e.g., a block containing text or a block containing one or more child blocks. Some blocks may have more than one type of content, e.g., a block containing both text and one or more child blocks. Content on workspace pages (e.g., wiki pages) rendered by the system is stored in blocks and each of the workspace pages has a hierarchy of blocks (with each workspace page as the block at the top of the hierarchy).
Every block on a workspace page has attributes that describe the block itself and attributes that define the block's relationships with other blocks. For example, attributes that describe the block itself include: a unique identifier, a list of properties (e.g., a “title” property which stores the text content of blocks), and a type attribute that determines how a block is displayed. The attributes that define the block's relationships with other blocks include: an array (or ordered set) of child blocks and a pointer to its parent block.
One example of a block type is a synced block having a sync attribute. The synced block does not contain text (i.e., the text field value is empty), but rather is a container for one or more child blocks that each have their own type attribute and where a plurality of synced blocks are multiple instances of the same block at different locations. The multiple instances include an original synced block, which includes pointers to its child block(s), and one or more reference synced blocks, where the one or more reference synced blocks each has a pointer to the original synced block (or, in other words, points to the same data in the database as the original synced block), and the content of a synced block is synchronized across all references of the synced block. Other examples of block types include text, image, page, heading, callout, list (e.g., a to-do list, a numbered list, a bulleted list, etc.), toggle, a row in a database, etc. Each block is stored as a row in a database.
A user can combine blocks, move blocks between locations, and change a block's type attribute from one block type to another block type. When a user changes a block's type attribute, the block's properties and content do not change, but the type attribute changes, which, in turn, affects whether and how the properties are rendered. For example, when a block has the type “to-do list,” the “checked” property of the block is rendered, but when the block is changed to a “heading” type or a “callout” type, the “checked” property of the block is not rendered.
The block's relationships with other blocks also define how the block is rendered. For example, the hierarchical relationships between a block, its array of child blocks, its parent block, and any sibling blocks form a “render tree” that renders each of the blocks in a hierarchical tree based on each block's type attribute. For example, for “list” blocks such as a “bulleted list” block and a “to-do list” block, the text content of the child block(s) is indented below the text content of the block itself. For a “toggle list” block, the text content of the child block(s) is also indented below the text content of the block itself, but the child block(s) is only rendered when the toggle property is expanded; otherwise, only the text content of the block itself is rendered. For a “page” block, the content of the block is displayed in a new page rather than indented on the current page.
Editing the hierarchical tree is also based on the relationships between the blocks. For example, unlike a conventional workspace, indenting a block does not just change the style properties of the blocks, but it also changes the hierarchical structure of the tree such that the indented block is added as a child block to the nearest preceding sibling block.
The hierarchical relationships between the blocks also determine which users have permission to view or edit which blocks. A block inherits the permissions of its parent block. Hence, the attribute of a block that is a pointer to its parent block determines the permissions of the block. In other words, as the permissions are traced through the hierarchy, the workspace page block as the block at the top of the hierarchy ultimately determines the permissions for the entire workspace page.
Example implementations of the methods are described in more detail with respect to
2. Method for Syncing Content Across Workspace Pages
In certain embodiments, the first workspace page and the second workspace page are within the same workspace. In certain embodiments, the first workspace page and the second workspace page are in different workspaces.
In certain embodiments, in response to receiving user input to insert the synced content in one or more additional workspace pages, the system creates an additional reference synced block for each of the additional workspace pages and adds a pointer that points to the original synced block to each of the additional reference synced blocks.
3. Method for Creating an Original Synced Block by Creating an Empty Block of a Synced Block Type
4. Method for Creating a Reference Synced Block from Another Synced Block Via “Copy and Sync”
In certain embodiments, if the user selects the “copy and sync” option from a first reference synced block, then when the user pastes the block on another workspace page, the user is creating a second reference synced block that points to the same original synced block as pointed to by the first reference synced block.
5. Method for Creating Both an Original Synced Block and a Reference Synced Block Via “Paste and Sync”
6. Method for Identifying Permission Mismatches
If the viewing permissions are the same, the system determines that the permissions match for the synced block and the reference synced block (step 530) and renders the reference synced block on the second workspace page. If the viewing permissions are not the same (i.e., determining that at least one user having permission to view the second workspace page does not have permission to view the first workspace page), the system determines that the permissions do not match for the synced block and the reference synced block (step 540), renders the reference synced block in the second workspace page only for users having viewing permission, and displays an indicator of the permission mismatch on the first and second workspace pages to users that have edit permissions for both of the workspace pages (step 550). In certain embodiments, the indicator of the permission mismatch is only displayed on the first workspace page, or only on the second workspace page.
7. Method for Rendering a Workspace Page with a Reference Synced Block
In certain embodiments, the original synced block and each reference synced block are each associated with a display that lists all the workspace pages on which the synced content appears. In certain embodiments, in response to a user selecting a workspace page on a list, the system navigates the user to the selected workspace page.
8. Method for Editing Content Inside a Reference Synced Block
9. Method for Unsyncing a Single Reference Synced Block
10. Method for Unsyncing all Synced Blocks
11. Example System Architecture
In
The server includes a server application programming interface (API) 1035, a block transactions processing module 1040, a notification subscription service module 1045, a block database 1050, and a database interface 1055. The server API 1035 sends block data to and receives block data from the client application 1005. When a client application 1005 requests a workspace page, the server API 1035 receives the request, the database interface 1055 retrieves block data for the requested page from the block database 1050, and the block data is sent to the client application 1005 via the server API 1035. Transactions from the client application 1005 are received at the server API 1035 and sent to the block transaction processing module 1040. The block transaction processing module 1040 processes transactions from client application 1005 and saves valid block changes to the block database 1050 via the database interface 1055. The notification subscription service module 1045 notifies client application 1005 of changes to blocks to which they subscribe. Client application 1005 subscribes to notifications for blocks currently rendered in the client application 1005.
12. Example Screenshots of User Interface Visualization
In the user interface visualization of
13. General
The methods described with respect to
As will be understood by those familiar with the art, the invention may be embodied in other specific forms without departing from the spirit or essential characteristics thereof. Accordingly, the above disclosure is intended to be illustrative, but not limiting, of the scope of the invention, which is set forth in the following claims.
| Number | Name | Date | Kind |
|---|---|---|---|
| 5787175 | Carter | Jul 1998 | A |
| 6558431 | Lynch et al. | May 2003 | B1 |
| 7249314 | Walker | Jul 2007 | B2 |
| 8434134 | Khosrowshahi | Apr 2013 | B2 |
| 9076128 | Horvitz | Jul 2015 | B2 |
| 9286271 | Khosrowshahi | Mar 2016 | B2 |
| 9449182 | Dang | Sep 2016 | B1 |
| 10127944 | Land | Nov 2018 | B2 |
| 10164783 | Alexander | Dec 2018 | B2 |
| 10171255 | Alexander | Jan 2019 | B2 |
| 10257196 | Dang | Apr 2019 | B2 |
| 10437923 | Silk | Oct 2019 | B2 |
| 10466867 | Boucher | Nov 2019 | B2 |
| 10466868 | Boucher | Nov 2019 | B2 |
| 10521402 | Nicholls | Dec 2019 | B2 |
| 10567382 | Dang | Feb 2020 | B2 |
| 10623193 | Alexander | Apr 2020 | B2 |
| 10970457 | Prakash | Apr 2021 | B2 |
| 11048666 | Nicholls | Jun 2021 | B2 |
| 11138021 | Rosenstein | Oct 2021 | B1 |
| 11153328 | Bond | Oct 2021 | B2 |
| 11243824 | Meersma | Feb 2022 | B1 |
| 11423357 | Didrickson | Aug 2022 | B2 |
| 20020065848 | Walker | May 2002 | A1 |
| 20030229607 | Zellweger et al. | Dec 2003 | A1 |
| 20060129933 | Land | Jun 2006 | A1 |
| 20070186157 | Walker | Aug 2007 | A1 |
| 20110296507 | Khosrowshahi | Dec 2011 | A1 |
| 20110314555 | Horvitz | Dec 2011 | A1 |
| 20120198389 | Audet | Aug 2012 | A1 |
| 20130246346 | Khosrowshahi | Sep 2013 | A1 |
| 20150244538 | Alexander | Aug 2015 | A1 |
| 20150244748 | Alexander | Aug 2015 | A1 |
| 20150363478 | Haynes | Dec 2015 | A1 |
| 20160315941 | Dang | Oct 2016 | A1 |
| 20170012984 | Dang | Jan 2017 | A1 |
| 20170315683 | Boucher | Nov 2017 | A1 |
| 20170315979 | Boucher | Nov 2017 | A1 |
| 20180113862 | Glover | Apr 2018 | A1 |
| 20190028286 | Alexander | Jan 2019 | A1 |
| 20190065615 | Room | Feb 2019 | A1 |
| 20190138587 | Silk | May 2019 | A1 |
| 20190213243 | Silk | Jul 2019 | A1 |
| 20200053176 | Jimenez Salgado | Feb 2020 | A1 |
| 20200089657 | Nicholls | Mar 2020 | A1 |
| 20200142936 | Kaplan | May 2020 | A1 |
| 20200193054 | Bond | Jun 2020 | A1 |
| 20200265040 | Jung | Aug 2020 | A1 |
| 20210224464 | Prakash | Jul 2021 | A1 |
| 20210303773 | Rodgers | Sep 2021 | A1 |
| 20210357861 | Haramati | Nov 2021 | A1 |
| 20210357863 | Cohen | Nov 2021 | A1 |
| 20210382734 | Rosenstein | Dec 2021 | A1 |
| 20220036311 | Didrickson | Feb 2022 | A1 |
| 20220197238 | Kagawa | Jun 2022 | A1 |
| 20220300562 | Jain | Sep 2022 | A1 |
| Number | Date | Country |
|---|---|---|
| WO-2022184004 | Sep 2022 | WO |