Patent Application
20110047484
Collaborating to create and share documents and other content is recognized as a great way to save time and improve the creation and use of content. Early word processing documents were often created by a single author and then printed or distributed in some other physical form as a final draft. Electronic collaboration allows many authors to contribute to a document and for many users to view the document. There are many types of collaboration. For example, architects collaborate on a building design, engineers collaborate on a car design, software developers collaborate on software source code, legal documents are created by lawyers and reviewed and amended by clients, and so forth.
With the rise of the Internet, sharing of content has become common, both to collaborate on the creation of content and to distribute content to consumers of the content. Sharing content can be performed using simple tools such as email (e.g., emailing a document between two users) or more complex tools such as a custom-designed intranet application for an organization. Content sharing often revolves around a pre-existing relationship between the authors and consumers of the content, such as a project team, family members, schoolmates, or other association. Content today can describe many types of information, including textual information, pictures, tables, mathematical formulas and calculations, architectural designs, schematics, computer source code, videos, audio files, calendars, and any other information content that may be represented in digital form.
Enterprise content management (ECM) refers to the technologies used to capture, store, preserve, and deliver content and documents and content related to organizational processes. ECM tools and strategies allow the management of an organization's unstructured information, wherever that information exists. A subset of ECM is a content management system (CMS), which is computer software used to create, edit, manage, and publish content in a consistently organized fashion. CMSs are frequently used for storing, controlling, versioning, and publishing industry-specific documentation such as news articles, operators' manuals, technical manuals, sales guides, and marketing brochures. The content managed may include computer files, image media, audio files, electronic documents, and Web content. Another type of ECM is a document management system (DMS), which is a computer system (or set of computer programs) used to track and store electronic documents and/or images of paper documents. The term has some overlap with the concepts of Content Management Systems and is often viewed as a component of Enterprise Content Management Systems and related to Digital Asset Management, Document imaging, Workflow systems, and Records Management systems.
Unfortunately, content sharing and collaboration are still too difficult to be used widely. Simple file sharing systems, such as Rapid Share, lack features to enable users to do anything other than transfer files. Because of this, many users still resort to sharing by email. On the other hand, more advanced ECM systems, such as Microsoft SharePoint, involve such a high level of setup and administration (often by a dedicated system administrator) that they are not approachable by many users. Users are forced to return to more traditional means of collaboration, such as videoconferencing, telephones, and face-to-face meetings. In addition, existing systems are often tied to proprietary storage solutions that involve complex management. For example, an ECM application often stores data in a database that a user or system administrator manages. For this and other reasons, these systems are often only used within a corporate intranet with a dedicated information technology (IT) staff.
A collaboration system is described herein that empowers non-technical users to create and manage custom collaboration portals, called hubs. Unlike previous systems, hubs are easy to manage, often providing a satisfactory default configuration after the user answers one or two questions through a wizard-like interface. In some embodiments, the collaboration system is provided as an Internet based service that can be accessed by users regardless of their affiliation with a company or other predetermined group. For example, users may create hubs for various purposes in their life, such as for sharing content related to a child's soccer team, sharing work-related documents, and sharing family photos or other content. In addition, the system shields users from the systems that provide storage for the content. For example, the system may be centrally managed by a service provider, and may store data using a database, cloud-based storage service, or other storage system.
Typically, a user starts by creating a profile with the system. After logging on with the profile, the user creates a hub. The system may present the user with one or more options, such as whether the hub is to be public (visible to other users) or private/secured (e.g., requiring an invitation or other permission to be visible to a user). The system may provide one or more hub widgets that provide specific functionality, such as a calendar widget for managing events, a file widget for sharing files, a comments widget for managing electronic discussions, and so forth. When creating a hub, the system may allow the user to select a template from a set of templates that define different default widgets to be associated with the new hub. After the system creates the hub, the system offers the user options for configuring the hub and for sharing the hub with other users. Thus, the collaboration system facilitates online collaboration for users without IT or other advanced software experience.
The hub creation component 110 manages the creation of new hubs. The component 110 receives information about the new hub, such as a name, description, Uniform Resource Locator (URL), color scheme, initial widgets, and so forth, and stores the hub using the data storage component 120. The hub creation component 110 communicates with the user interface component 130 to provide a user interface through which a user specifies information about the new hub. The hub creation component 110 may provide several ways of creating a hub, such as a short wizard for producing a “quick hub” and a more detailed wizard for producing a more complex hub. For each of these ways of creating a hub, the hub creation component 110 provides an easy interface that can be used by non-technical users to rapidly create intranets, extranets, and content sharing portals.
The data storage component 120 persistently stores hub data across user sessions with the system 100. The data storage component 120 may use a database, storage area network (SAN), cloud-based storage services (e.g., Amazon S3), or other storage system to persistently store hub data. Hub data includes configuration information, such as the name and description of the hub, as well as widget data, such as files stored by a files widget, events stored by a calendar widget, and so forth. The hub data may also include security information, such as a list of users that are allowed to access the hub and roles of each of the users that determines actions each user can perform.
The user interface component 130 provides a user interface for users to provide input and receive output from the system 100. In some embodiments, the system 100 is implemented as a hosted network-based service that can be accessed by multiple clients. The service may provide output as one or more Hypertext Markup Language (HTML) pages, and the clients may use a standard web browser to interact with the service. The user interface component 130 may also provide other interfaces, such as a programmatic interface that provides Extensible Markup Language (XML) or other output for consumption by other applications. Thus, at times the system 100 may interact directly with the user and at times the system may provide data to other applications used by the user (e.g., an Apple iPhone application or a Facebook plug-in).
The hub sharing component 140 manages which users can access a particular hub. Although the system 100 may act as a hosted service accessible to many clients, some hub creators may not want some hubs to be accessible to any Internet user. For example, a hub creator may create a hub related to a confidential project. The hub creator uses the hub sharing component 140 to both inform other users about the hub and to define which users can access the hub. A hub can be public (i.e., open to any user) or private with a specific list of users. The hub creator or another hub administrator can select users through a user interface of the hub sharing component 140, define roles for each selected user, and send an invitation to each selected user.
The component 140 may send invitations through the system 100 so that the user will see invitations when the user logs on. The component 140 may also send invitations to the user through other communication channels, such as via an electronic mail message or text message (e.g., using the Short Message Service (SMS) of a wireless provider). The hub creator may select users with which to share the hub initially during hub creation and may invite new users later throughout the lifetime of the hub. When the hub sends invitations, the hub sharing component 140 may generate a token that is included in a link that the invitation recipient can select to accept the invitation. The token is selected so that it is difficult to guess so that possession of the token is an indicator of the validity and identity of the person responding to the invitation.
The hub design component 150 provides an interface through which a hub administrator can modify the hub layout and select widgets to add to the hub. A hub contains one or more pages that may be displayed as web pages or tabs from a main screen of a hub. Each page has a layout that defines, for example, how many columns of widgets are displayed on the page. A hub administrator uses the hub design component 150 to modify the layout and add/remove widgets to each page. In some embodiments, the hub design component 150 provides a dynamic, editable web page version of the hub that allows the user to select (such as by clicking a mouse) and move widgets on each hub page to a desired location. The component 150 may also allow the user to modify textual elements, like a title, description, or other element. In some embodiments, the hub administrator invokes the hub design component 150 by selecting a hub design mode. In response, the component 150 provides the editable user interface to the hub administrator. When the hub administrator finishes making any changes, the component 150 saves the hub data to the data storage component 120.
The hub management component 160 provides an interface through which a hub administrator can modify settings of the hub. Unlike the hub design component, these settings may include non-visual elements, such as which users can access the hub, any expiration date of the hub, whether the hub is public or private, and so forth. The hub management component 160 allows the hub administrator to make ongoing changes to the hub as the needs of a group using the hub change. Managing a hub is a task that is easily performed by a non-technical user, such as through a familiar web interface. A hub creator is automatically an administrator of the hub and may select one or more additional administrators of the hub that the system 100 will permit to manage and modify the hub configuration. When the administrator finishes modifying the hub, the hub management component 160 stores the changes using the data storage component 120.
The system 100 includes one or more widgets 170 that provide specific functionality to hubs. A widget may perform a variety of functions, and typically includes a displayable interface that appears on at least one page of the hub. For example, a calendar widget may display a rendering of days in a month similar to a paper calendar or a list of scheduled events associated with a calendar. Widgets may also include administrative interfaces, such as for adding new events to a calendar or restricting which actions users of various roles are allowed to perform using the widget. Examples of widgets are the calendar widget previously described, a task widget for managing tasks, a files widget for storing and sharing files among users, a comments widget for managing online discussions, and so forth. The system 100 may be expanded over time by an operator of the system 100 with additional widgets that hub administrators can add to their hub pages.
The computing device on which the collaboration system is implemented may include a central processing unit, memory, input devices (e.g., keyboard and pointing devices), output devices (e.g., display devices), and storage devices (e.g., disk drives or other non-volatile storage media). The memory and storage devices are computer-readable storage media that may be encoded with computer-executable instructions (e.g., software) that implement or enable the system. In addition, the data structures and message structures may be stored or transmitted via a data transmission medium, such as a signal on a communication link. Various communication links may be used, such as the Internet, a local area network, a wide area network, a point-to-point dial-up connection, a cell phone network, and so on.
Embodiments of the system may be implemented in various operating environments that include personal computers, server computers, handheld or laptop devices, multiprocessor systems, microprocessor-based systems, programmable consumer electronics, digital cameras, network PCs, minicomputers, mainframe computers, distributed computing environments that include any of the above systems or devices, and so on. The computer systems may be cell phones, personal digital assistants, smart phones, personal computers, programmable consumer electronics, digital cameras, and so on.
The system may be described in the general context of computer-executable instructions, such as program modules, executed by one or more computers or other devices. Generally, program modules include routines, programs, objects, components, data structures, and so on that perform particular tasks or implement particular abstract data types. Typically, the functionality of the program modules may be combined or distributed as desired in various embodiments.
Continuing in block 240, the client selects a visual style for the new hub. For example, the hub creation interface may include one or more predefined styles and/or color schemes from which a user can choose. Continuing in block 250, the client sends the service a hub creation request that instructs the service to create the hub based on the provided information. When the service receives the request, the service creates the hub and persistently stores the hub settings, including the user that created the hub. Continuing in block 260, the client receives a user interface for viewing the created hub. For example, the service may provide a web page to the client that includes tabs that navigate to individual pages of the hub. Each page may include one or more widgets selected during hub creation. Note that in some embodiments, the collaboration system provides an option for creating a quick hub for sharing content that may omit some of the above steps. For example, when creating a quick hub the system may not ask the user to select widgets or a visual style. After block 260, these steps conclude.
Continuing in block 330, the component receives a design modification request. For example, the user may select one of the displayed controls for editing the hub design. The hub modification request may include many types of changes, including adding a page, modifying the layout of a page, adding widgets to a page, removing widgets from a page, changing information on a page (e.g., a title, logo, or theme), adding data to a specific widget (e.g., uploading a file to a file widget or adding a task to a task widget), and so forth. Continuing in block 340, the component saves modified hub data to a persistent data store. For example, the component may store information about the widgets and how they are arranged on each hub page in a database or other data store. After block 340, the component loops to block 320 to display the updated, editable hub user interface and receive any further modifications. In block 350, reached when the user selects the control for exiting the hub design mode, the component exits the hub design mode and displays the hub with a normal, non-editable user interface. After block 350, these steps conclude.
Continuing in block 430, the hub sharing component receives information about one or more invited users with which the sharing user wants to share the hub. The information may include a name, email address, and customized message from the sharing user to the one or more invited users. Continuing in block 440, the hub sharing component receives a role for each invited user. For example, the sharing user may select whether the invited user will have administrative or editing privileges over the hub. Continuing in block 450, the hub sharing component sends an invitation to each invited user. The component may send the invitation via email or other communication medium to the invited user. The invitation may include a link to a URL that the invited user can access to use the shared hub. After block 450, these steps conclude.
The quick hub widget 530 provides the user with controls for quickly creating hubs to send or receive files. Users may often want to share files through a hub without going through the additional steps typically associated with creating a hub, such as selecting widgets. The quick hub widget 530 allows the user to quickly create these types of hubs. The activity log area 540 displays a log of actions that the user has taken with respect to hubs associated with the user. In some embodiments, the user can set criteria to filter the information displayed in the activity log area 540, such as to filter by activity type. The activity log area 540 may include links in each entry that, when selected, navigate the user to a page related to the activity. For example, if the activity of an entry is uploading a file, a link associated with the entry may refer to a file viewing page. The list of hubs 550 displays a list of hubs associated with the user with links to the home page of each hub. The list of hubs 550 may include hubs that the user previously created as well as hubs to which the user belongs (potentially created by other users). Each entry in the list may include a link to a URL that represents a particular hub home page. Selecting a link takes the user to the home page for that hub, such as the home page of
The system may also allow the user to drag and drop widgets to new locations on the design page 900. In some embodiments, the design page 900 contains Asynchronous JavaScript and XML (AJAX) code that allows the design page 900 to receive dynamic layout information while limiting bandwidth to a hosting server. The design page 900 allows ordinary users (e.g., non-developers) to customize hubs without assistance from a familiar web-based or other interface. For example, a user can easily drag and drop widgets to various locations on a page or to other pages of a hub to specify the layout desired by the user.
In some embodiments, the collaboration system displays a running audit trail of at least some actions performed by one or more users related to a hub. For example, the main page of a hub may contain a widget in the right column that displays an activity log with entries for each action taken by a user. Entries may contain a record of when a user created a hub, when a user uploaded a file to the hub, and other significant events that may be of interest to other users of the hub. Users of the hub can browse the activity log to stay up to date about events that have occurred since each user last viewed the hub. Users may also elect to show or hide events that the activity log displays based on event criteria, such as type of event, user that initiated the event, and so on.
In some embodiments, the collaboration system associates a role with each user and hub that defines the actions the user can perform on the hub. For example, the system may include reader, contributor, author, and administrator roles. A reader has the ability to access a hub, view pages, view widgets, download files, and view details on file items. A contributor has all the rights of a reader plus the ability to upload documents, add items to lists, and add comments to file libraries. An author has all the rights of a contributor plus the ability to modify properties of widgets, add and remove pages in a hub, add and remove widgets, design a hub, and share the hub with other users. An administrator can manage all aspects of a hub. In addition to the rights of an author, an administrator can add and remove administrators, manage the settings for a hub, and deactivate a hub. In some embodiments, the system allows an administrator to allow public access (i.e., non-authenticated users) to a hub and to assign a default role (e.g., reader) to associate with unknown users. Alternatively or additionally, the system may allow the administrator to control granular restrictions, access to widgets, and information contained in widgets on a per-user basis, by role of user, or make access public.
In some embodiments, the collaboration system allows users to search hub data and/or to search data across hubs associated with a user and public hubs accessible by all users. For example, the system may provide a search box in the user interface into which a user can type one or more keywords or phrases that the system will identify in content stored in one or more hubs. The system may provide links to hub pages containing the identified content. Search provides an alternative way to find and navigate to content stored in hubs.
In some embodiments, the collaboration system expires hubs and information within hub widgets after a specified period. For example, the system may receive an expiration time from a hub creator when the hub is created or may use a default expiration time based on a hub type. For example, a hub created for the purpose of sharing files may expire after a short period, while a project-based hub may not expire or be set to expire after the expected completion date of the project. The system may also trigger expiration based on certain events, such as a period (e.g., one month) of no activity related to a hub. Expiring hubs allows the system to recover data storage space for use by other hubs. For example, a files widget may expire files after a particular configurable interval after a user creates the file, such as to satisfy company data retention policies.
In some embodiments, the collaboration system enforces user limits and storage quotas. For example, the system may provide each user with a set number of hubs that the user can create and/or a set amount of data storage space that hubs created by the user can consume. The system may set quotas based on a subscription level or price tier associated with the user or hub, so that users can pay the operator of the system for more hubs and/or data storage space.
In some embodiments, the collaboration system translates or transcodes information uploaded into a hub or widget in a hub for more convenient or appropriate display. For example, the system may transcodes a video of an initial bit rate into a video with a lower bit rate for easy download by client computers with slower network connections. The system may perform translations based on a subscription level or price tier associated with the user or hub, so that users can pay the operator of the system for particular encodings, higher fidelity renderings, or other types of processing.
In some embodiments, the collaboration system provides alternative interfaces to files widgets. When uploading files, the system may provide multiple interfaces for uploading files, including a Sun Java application, an Adobe Flash form, or an HTML POST. The system may also receive files for the files widget via File Transfer Protocol (FTP) or other file transfer specifications. The system may also receive files for the files widget as attachments to email sent to a designated email address for each file widget. When viewing files, the system may provide files through similar interfaces, as well as providing a separately accessible URL for each file. This allows hub users to share links to individual files that are hosted in a hub with other users. In some embodiments, the system provides versioning for files so that updates to files are tracked and users can access or identify specific file versions. For example, one user may upload a document, creating a first version of the document, and a second user may modify the document, creating a second version of the document.
In some embodiments, the collaboration system modifies the login process based on how a user invokes the system. For example, if a user visits a web site associated with the system with a hub-specific URL and the user is not logged in, then the system provides the user with a hub-specific login page. Upon supplying sufficient credentials, the system displays the home page of the hub associated with the hub-specific URL, such as that described with reference to
From the foregoing, it will be appreciated that specific embodiments of the collaboration system have been described herein for purposes of illustration, but that various modifications may be made without deviating from the spirit and scope of the invention. Accordingly, the invention is not limited except as by the appended claims.
