User Namespace
Table of contents
- 1. Introduction
- 2. Status
- 3. Functional Specification
- 3.1. Current shortcomings
- 3.2. Use Cases
- 3.3. Non-goals
- 4. Technical Specification
- 4.1. Golden Rule for User Pages
- 4.2. Related Issues
- 4.3. Technical Use Cases
- 4.3.1. User page gets created
- 4.3.2. User page gets deleted
- 4.3.3. User is banned/disabled
- 4.3.4. Auto-repair user page creation
- 4.4. Outstanding questions
- 4.5. UI requirements
- 4.6. API requirements
Introduction
Currently, the user namespace's handling inside MindTouch is without purpose - while it has always served as a focal point for user-centric activity in MindTouch, it has lacked a way of exposing data in a consistent format, nor have logic rules been applied to make this area the real sense that users "own" this space.
The goal of these changes is to change the perception of the user namespace as simply a personal scratchpad to the central point to receive all user-centric information in MindTouch. By implementing subtle changes to the way users interact with this feature, we should aim to (1) discourage content creation in the user namespace (and thus encourage high-quality content creation in the main namespace) and (2) evolve the user namespace into a structured, personalized view of a user's activity in MindTouch.
High-level user stories for the user space
- For readers (visitors viewing a user's page), the user space is for discovering context about a user within MindTouch.
- For contributors (users on their own page), the user space is a personal area to work on documents in isolation, and to get their user-centric views of MindTouch activities to keep track of their activity.
For content curators, content from the user space should not inhibit the ability to monitor content generation in the main namespace.
Intended Audience
All users of MindTouch.
Status
Speccing by RoyK - parts of this work will be in Olympic.
Functional Specification
Current shortcomings
Using the high-level user stories:
- For readers (visitors viewing a user's page), the user space is for discovering context about a user within MindTouch.
- There is a lack of structured information about a user. User dashboards & user activity dashboard solves this problem.
- For contributors (users visiting their own user pages), the user space is a personal area to work on documents in isolation, and to get their user-centric views of MindTouch activities to keep track of their activity.
- On top of the structured information covered in 1.1 above, there is no default permissioning of a user's space to prevent others from taking over the namespace.
- For content curators, content from the user space should not inhibit the ability to monitor content generation in the main namespace.
- With the current implementation of user pages, users commonly put in work-in-progress notes on their user pages, which by default, show up in the recent changes as well as search results. This is unnecessary noise for content curators.
Use Cases
(I'm going to simplify all references to "user namespace" to simply "user:")
Readers get user-centric data and activity about a specific user
The User Dashboard framework allows applications to start pushing focused data to users with relevant information to them. The default view would contain information relevant to their activity on MindTouch is covered in the user activity dashboard spec.
User creates a personal scratchpad of free-form pages
Users can create free-form pages as they have been able to in the past. The equivalent of User:RoyK page ("root homepage") would be under the "Notes" tab of the user dashboard. Although the root homepage of notes would remain within the User Dashboard chrome, future pages would look like normal pages in MindTouch.
These pages would automatically be permissioned upon creation to be "Semi-Public" - users would be forced to lift the restrictions to allow others to contribute to these pages.
It should also be impossible to lock users out of their own namespaces with permissions - users should always be added to the grant list to prevent lockout.
User installs a mini-application
In the "notes" section, because the subpages operate as normal MindTouch pages, users will be able to use the page wizard to select mini-applications to install for themselves in their user namespace.
User searches site for content in User:
When a user searches for content through the API, the searches will, by default, return only results in the main namespace. In order to expand searches into the user namespace, they will have to select either the "search all namespaces" or "search user namespace." If a user wishes to search their own namespace, they will select "select my namespace."
Title searches (as used by the future navigation pane and the link dialogs) will search across all namespaces by default.
User views recent change filters for User: changes
When a user visits recent changes, to see all changes happening in user:*, they will have to select a filter that says "Show recent changes in the all namespaces."
Non-goals
Technical Specification
Golden Rule for User Pages
User pages must always exist.
Related Issues
Bug 7924 is a parent item which contains all relevant work items for Olympic. Bug 7991 contains work items for Pipestone.
Technical Use Cases
User page gets created
Currently, user pages are created at user log-in time. This poses a problem with the addition of user dashboards, as users who were created through the control panel (invited users) will not have user pages.
There are three ways for a user to be created in MindTouch:
- User self-registers an account. This also logs the user in.
- A (new) user logs in with an external authentication service. This login also creates the user account for the first time.
- Administrator creates (invites) a user to the system through the control panel. This creates the user, but the user may not log-in for some time.
Currently, only use cases #1 and #2 create user pages - the special case of #3 of local account creation should also create a user page. When a user page is created, it should be restricted (through a config key) to Semi-Public to that particular user.
Considerations: If a user does not have CREATE permissions, how can we reliably create this user page?
- Page gets created with impersonation by the admin user
Should users receive elevated permission rights in their own user space?
- Not critical for this release as it relies on changes to hierarchy and permissions for root-level pages like Template: and User:. Ship this release w/o elevated permissions and deal with it in Pipestone.
- Quick dump for hierarchy clean-up: If User: and Template: get cleaned up, how do we execute scripting in Template:?
How do we remove the ambiguity of "Joe Smith" and "Joe_Smith" accessing: "User:Joe_Smith"?
- Treat space and underscores as the same - API will throw a conflict error
User page gets deleted
Over time, content may appear on a user's page which they may want to delete. Given that the golden rule prevents pages from being fully deleted, the delete operation on the user page should be followed-up with a page creation to prevent breaking user dashboards. Standard permissions are enforced upon delete. (similar to the use case when deleting a parent page w/o deleting children)
User is banned/disabled
If a user is either banned or disabled, the administrator should be presented with an option to also wipe the user page's contents consistent with the "user page gets deleted" use case above.
(Note: If we actually end up supporting user deletion in MindTouch, it should do a full wipe on the page deletion w/o new page creation).
(The reverse use case of unbanning/re-enable should be supported as well)
Auto-repair user page creation
Non-issue. Handle with UI messages.
If we were to upgrade; site administrator can create a script to loop through and log-in with all users.
Outstanding questions
- Lossy conversion from username to user pages (underscores and spaces). Currently user dashboards look at spaces first, then underscores. Should new systems allow for user names to be created like that? (if so, rename should be executed)
- Encoded titles vs. usernames?
- Explicit linking between usernames/userpages (allows non-title/username linking)
UI requirements
- Add a config key to noindex,nofollow pages in the user namespace (default on new installs, must be set for older installs)
- Need to define RC and search experience for filtering
API requirements
- Tag page
- What links here
| Images 0 | ||
|---|---|---|
| No images to display in the gallery. |
Copyright © 2011 MindTouch, Inc. Powered by
"By implementing some subtle changes to the way users interact with this feature, we should aim to (1) discourage content creation in the user namespace (and thus encourage high-quality content creation in the main namespace)"
Our users like the My Page space because it allows them to do work that they want to keep hidden until they are ready to publish it. By forcing them to create it in the main body of the wiki you cannot guarantee that any will "high-quality content" because you have no control over what people write. I know that many of our users like to keep their work hidden until it is both finished and of a standard that is acceptable to them. The great thing about their My Page is that the content is easily hidden from most users, thus giving them a feeling of security they wouldn't have by having WIP written in a more public space. Cheers.