Workspaces Use Cases
Description
User stories
Roles: Normal user, Workspace administrator, Workspace creator
Userstory #1 |
---|
As a normal user I want to to create a public or private workspace and become administrator for that workspace.
|
Userstory #2 |
---|
At creation time I want to be able to choose the applications that will be available in the workspace. |
Userstory #3 |
---|
At creation time I want to be able to specify the members. |
Userstory #4 |
---|
As a workspace administrator, I want to add additional applications to or remove existing ones from the workspace. |
Userstory #5 |
---|
As a workspace administrator, I want to change the visibility of a workspace. |
Userstory #6 |
---|
As a workspace administrator (or just creator?), I want to remove the workspace. |
Userstory #7 |
---|
As a workspace administrator, I want to add other administrators for the workspace. They will receive a direct notification. |
Userstory #8 |
---|
As a workspace administrator, I want to add or remove members. They will receive a direct notification. |
Userstory #9 |
---|
As a private workspace administrator, I want to validate the requests to join the workspace. |
Userstory #10 |
---|
As a normal user, I want to join a public or private workspace. |
Userstory #11 |
---|
As a normal user, I want to invite other users to join a workspace. |
Userstory #12 |
---|
As a normal user, I want to see available applications in a workspace. |
Userstory #13 |
---|
As a normal user, I want to see an index/a list of workspaces, each with:
|
Userstory #14 |
---|
When a workspace is accessed, a dashboard is presented to the user. This dashboard contains:
|
Userstory #15 |
---|
As a normal user, I want to see the list of members of a workspace in the workspace's User Directory. |
Userstory #16 |
---|
As a member of a workspace, I want to broadcast (status?) messages to the members of the workspace. |
Userstory #17 |
---|
As a member of a workspace, I want to see the list of (work) groups I am a member of inside that workspace. (XWiki)Groups can be used to organize people belonging to the same workspace (e.g. a workspace about project X can have a group for each module, each one containing people working on that module) |
Userstory #18 |
---|
As a member of a workspace, I want to view all members of a group inside that workspace together with their activity in that workspace. |
Userstory #19 |
---|
As a member of a group inside a workspace, I want to broadcast messages to that group. |
Userstory #20 |
---|
As a member of a workspace, I want to be able to leave a workspace. |
Design
The social extension of XWiki will be based on the notion of {\em workspace}. A workspace is a space where users can collaborate and exchange information.
A workspace is defined by the following elements:
- A wiki for enabling collaboration.
- A set of users that are allowed to participate and collaborate in the context of a workspace.
- A set of applications that are available in the workspace and that facilitates the tasks users commonly do in the context of a workspace.
Workspace can be created by users who have the rights to do so, and can be public or private. The user who created the workspace becomes its administrator and have all the management rights on the workspace itself. It can then give these rights to also other users if he wishes.
A public workspace is meant to be joined by any user while a private workspace, on the other hand, can be joined only after being accepted by the user who is the administrator.
In order to join a private workspace either a user receive an invitation from a member of the workspace, or she requests to the adminstrator(s) the right to join.
Workspaces and XEM (XWiki Enterprise Manager)
XWiki Enterprise Manager (XEM) is XWiki's global administration solution. It offers the ability to create new wikis on-demand and provides the infrastructure tools (i.e., global user management, detailed statistics) required to manage many wikis at the same time.
XWiki Enterprise Manager is typically used to manage public or private wiki farms. It can be used to offer either open or closed wiki-creation capabilities.
In Wiki3.0 we will use XEM as the primary mean to implement workspaces. In this way workspaces will be implemented as fully-fledged wikis with all the functionalities:
- Each workspace will consist of a subwiki in a XEM setup
- A special subwiki will be used as a container for users: each user registered in the system will be a user of this wiki. User profiles will be available here and user-oriented components will provide information about users by looking at this wiki.
By having this setup we can give the workspace the full power of a standalone wiki that is used, configured and administered in isolation with respect to other workspaces. This allows also the installation and management of a different set of applications on each workspace.
Moreover, in each workspace, all the administration tools such as group and rights management is available to organise users in different sets and to give them different rights with respect to the information available in each workspace.
Workspace creation
The "create wiki" UI of XEM will be extended to support specifying:
- A list of applications to be deployed in the new wiki;
- A list of users to be added as workspace members.
- The visibility of the new workspace (public/private).
Upon creating a new wiki:
- The Application Manager Application (or Extension Manager, or both) will be deployed in the new wiki (using a wiki template?);
- The Application Manager will be remotely controlled to install the user selected applications;
- The functionality to register new users in the new wiki will be disabled.
Membership
Have a top-level group for each workspace.
This would imply that, for each workspace, a global group is also created. This group is to be managed by the administrators of the corresponding workspace to add or remove workspace members. The association between a group and workspace is kept as an object stored in the group's page.
At workspace creation time, each administrator of a workspace will have edit rights on the global group's XWiki document. This way he can use the existing group UI to add/remove members and to add/remove administrators.
Any groups inside a workspace are viewed as "Work Groups" and are created by workspace administrators. The XWiki group sheet will display the activity stream filtered to group members and current workspace (wiki). This also applies to the global group page, where the current workspace is the workspace associated to it, and not the main wiki.
Tasks
1 Workspace creation/removal
1.1) Remove WikiManager java rights checking for the current user.
1.2) Basic workspace template used to instantiate new workspaces.
1.2.1) Workspace home page (Main.WebHome of subwiki)
1.2.1.1) Activity stream for the workspace (this allows also to publish user statuses directly from the home page)
1.2.1.2) Quick access links to workspace applications
1.2.1.3) Top 5 active members
1.2.1.4) Join/leave buttons (where applicable)
1.2.2) Group page (for both main and sub wikis)
1.2.3) Links to group edit pages accessible from outside the wiki preferences (for group managers)
1.2.4) Default management applications (ApplicationManager + ExtensionManager?). Make sure WikiManager does not allow deeper creation of subWikis so that if it is installed by a workspace admin, it must not be able to function.
1.3) Workspace management dashboard (where to put it? in user profiles? top menus?)
1.4) "Wiki" to "Workspace" translations rebranding.
1.5) Disable workspace user registration. Keep it just in the main wiki.
1.6) Workspace properties management (public/private) and user list dashboard (members)
1.6.1) Create a global group corresponding to the new workspace to handle workspace membership.
1.7) Workspace directory for users willing to discover available workspaces
1.8) Workspace creation "dialog" with initial settings like the workspace title/description, initial user list, administrators, and applications to be installed
2 Workspace management (this should be done as an extension of the wiki preferences with possibly a shortcut from the homepage or top menus)
2.1) Adding users
2.2) Inviting users
2.3) User joining request validation (for private workspaces)
2.3.1) Store user join requests/invitations in global group page as objects?
2.4) User can join workspaces using the workspace directory mentioned in 1.7
2.5) Application management once the workspace is already created (handled by the ApplicationManager Application)
3 User statuses
3.1) User status should be contextualized in order to provide more effective filtering
3.1.1) User statuses sent from the user profile should be broadcasted and shown in activity streams of the personal social network
3.1.2) User statuses sent from the workspace home page should be shown only on activity streams related to the workspace
3.1.3) In general a "context" attribute for the user status should provide information for performing contextual filtering. The context field could be multivalued (specially for things like "external, facebook" or "external, twitter").
4 User profiles
4.1) Extended user profiles with additional fields (like "interests", "skills", etc.)
4.2) Dashboard aggregating events coming from different contexts (personal social network, workspaces, etc.), prefferably with context separation (a column/activity stream for each context)
4.3) User's social network management
4.3.1) Follow/Unfollow other users (controls for this could be placed in the public user profile)
4.3.1.1) List of followed users
4.3.3) Block/Unblock users (don`t allow them to follow or message you)? Does this make sense in an enterprise environment?
4.3.3.1) List of blocked users
5 Messaging
5.1) Inbox, Sent, Trash sections in the Messaging private section of the user profile.
5.2) A message may have as destination users or groups. Multiple values accepted.
5.3) Messages stored as objects in user's profile or trough custom mapping? Custom mapping might be more effective but can not be ex/imported.
5.3.1) If stored as objects, we need a plugin to overcome privileges needed by the sender to write in other user's profile pages.
6 Search (Extend the existing search by adding new "tabs")
6.1) Dashboard for searching for workspaces (see 1.7) using different criteria (i.e., workspace description, title, and attributes)
6.2) Dashboard for searching for users using different criteria (i.e., user interests, skills, etc. this will be based on extended attributes of the user profile)
6.3) Dashboard for searching for events using diferent criteria (workspace, space, page, user, application, etc.) respecting the visibility of events. Practically, use activity stream for this.