Sakai 2.0 RWiki Functional Requirements and Specification

Contents

• I. Introduction
• II. Summary
• III. Functional Requirements
• IV. Roles and Groups
• V. Non-functional Requirements
• VI. Wireframes / Functional Specification
• VII. Functional Roadmap

I. Introduction

RWiki is an open-source Wiki tool for Sakai that gives worksite members the ability to create and update wiki pages within the worksite. RWiki is designed and developed at the Centre for Applied Research into Educational Technology (CARET) at Cambridge Univeristy. Plans for further development of RWiki are outlined in Section VII.

II. Summary

RWiki will allow worksite members to

1. View wiki pages
2. Update wiki pages
3. Create new wiki pages
4. Link to document resources in Sakai
5. Include images in pages
6. Link to external pages
7. Use UTF8 character sets
8. Use TeX mathematical notation

III. Functional Requirements

Viewing content

1. View Wiki pages within Sakai
2. Follow links to internal pages
3. Follow links to documents and resources within Sakai
4. Follow links to external content
5. Increase or decrease text size

Editing content

1. Edit existing content.
2. Add a variety of headings, bulleted lists, tables, and text formatting
3. Link to other RWiki pages, under page aliases if desired
4. Link to external pages
5. Incorporate images uploaded into Sakai Resources.
6. Incorporate maths notation using TeX
7. Use UTF8 character sets, allowing content in a number of different languages
8. Preview your changes
9. Cancel your changes
10. Save your changes
11. Receive notification if the page has been changed by someone else while you are editing it, allowing you to choose which version to save.

Alter document permissions

Allows the owner of a page (usually the page?s creator) to make it available for public viewing within Sakai.

1. Apparently this is going to change?
2. Edit the conten
3. At bottom of the page, a ?show document permissions? button appears.

Information on content

1. Lists all pages the page references
2. Lists all pages that reference the page
3. Gives the page owner (usually the person who created it)
4. Gives the global page name, to allow linking to it from outside the RWiki
5. Gives the page permission detail (the site you need to be a member of to see it)
6. Gives details of when the page was last edited

History of content

1. Gives a list of all previous versions of that page, with the name of the user who altered it, the date.
2. Allows you to view any previous version.
3. Compare the contents of any version with the current version
4. Compare the contents of any version with the version immediately previous.
5. Allows you to revert to any previous version.

Search

1. View list of titles of pages including search content
2. Use ?and? operator (but not ?not? or ?or?)

IV. Roles and Groups

A number of use cases that have been suggested for RWiki require page-level permissions to be set and represent behaviour that is atypical of a ?standard? wiki. These page-level permissions are hidden by default. Sakai Admin should have RWiki superadmin permission in order to reveal page permissions to sites that wish to experiment.
Standard Wiki

There are 5 permission within RWiki:

• RWiki read
• RWiki create
• RWiki update
• RWiki admin
• RWiki superadmin

At the time of writing, new worksites are created with the access and maintain roles only. When the RWiki tool is added to a site the site access and maintain roles receive the following permissions by default:

In !site.template and !group.template these are the standard permissions as deployed in 2.1

In !site.template.course and !group.template.course these are the standard permissions as deployed in 2.1

Note: the absence of superadmin permission for the Site/Maintain role is one of the reasons for encouraging Sakai Admin to setup superadmin permission for the Sakai Admin user.

The default permissions above are felt to be appropriate for typical use. Default permissions can be changed by editing components.xml and redeploying Sakai. After this has been done, the realm permissions of existing sites will not have changed, but new sites will have the new permission sets defined in components.xml as default settings on adding the RWiki tool to a site. If the tool is removed and then added back the permissions sets current in components.xml will be created and the previous realm/site permissions will be lost.

RWiki with page-level permissions

In order to activate page-level permissions, Sakai Admin should grant RWiki admin to the site ?Maintain? role. With the default settings recommended in this document, this will result in the permissions option becoming visible to site members with the ?Maintain? role. Maintain users will then be able to edit page permissions as required. A typical change may be to allow the Page Owner to control the page permissions, or simply to make the page visible to the Public (users with the .anon role)

RWiki page-level roles (permission sets)

In order to allow flexible use cases to be supported, some internal roles (permission sets) are defined in addition to the Sakai Site/Role permission sets above. The Page/Role permission sets implemented in RWiki are:

• Page Owner
• Sitewide
• Anonymous (Public)

When a RWiki is added to a site, 3 document/page is created by default (Help, Recent Changes, and Edit_right). The RWiki internal permissions for these pages are configured in components.xml. In addition, when the tool is first accessed, a page named ?Home? is created. The permissions for Home are set by the page creation code and are currently hard-coded, but a request has been made for them to be moved to components.xml. The initial permissions set by code for new pages and thus ?Home? are:

The default settings for RWiki internal page permissions in components.xml are:

Note: the logged-in user who adds the RWiki tool to the worksite will be the initial Page Owner for these pages.

What do RWiki page-level permissions do?

• The Page/Read permission allows the page to be viewed.
• The Page/Write permission allows the page to be edited
• The Page/Admin permission determines whether the page permissions can be changed. If a user does not have Page/Admin permission granted, the page permissions will not be visible to that user.

Note for Page/Write permission: While a link to a new page can be created in the page, a user who first follows that link will trigger a page creation (normal wiki behaviour). This will result in a ?permission denied? error if they do not have RWiki update permission in their site role (access, maintain). However, another user with RWiki update could follow the link to create the page and then the link would work for the first user because now only RWiki Read permission is required to view the page.

Who's on top?

• RWiki Page/Owner internal permissions override RWiki permissions granted in with the site role (access, maintain)
• RWiki Page/Sitewide internal permissions are overridden by the site role (access, maintain) permissions.
• RWiki Page/Public internal permissions override Sakai.anon RWiki permissions.

Thus, page-level permissions will usually behave in an intuitive fashion. With page-level permission activated, if you own the page or if the page has been set for Public read or write access, this will be allowed regardless of other permissions set elsewhere. But granting Page/Sitewide the ?Read? permission will allow only allow a member of the worksite to view the page if they have a role that has also been granted RWiki Read permission.

V. Non-functional requirements

• RWiki uses the Sakai 2.0 build mechanism
• RWiki can be deployed into Sakai 2.0.0 or 2.0.1
• RWiki typically serves pages in < 50ms on a low end PowerBook (eg 1.3GHz G4).
• The implemented markup is based on Radeox. All of the standard markup (linking and formatting) is present.
• Each RWiki space within the worksite should manage its own subfolder in sakai resources that contains attachments. RWiki should reuse the sakai resources functionality to enable a use to upload content on the page. It should provide a list of uploaded the contents, for that page, on the pages (e.g. there are 5 attachments to this page). Should investigate what happens when a resource is moved, and how be might handle it. Is there an event in Resources we can watch ?

VI. Wireframes/Functional Specification

Users with create / update permissions see the menu and search box displayed at the top of the page.

Users without create / update permissions see the full page and the navigation trail, but without the menu. Note that they also lose the search functionality.

Images uploaded as resources within Sakai can be shown within RWiki pages.

Links to external sites are marked with a ?world? icon.

Links to resources within Sakai are also marked with a ?world? icon.

Tables are shown with highlighted headers

Images can be incorporated within tables

The search page shows a list of all pages containing the separated by ::

The word searched for (here ?page?) is displayed at the top.

The search page shows only the ?home? button from the menu.

That search is added to the breadcrumb trail and can be returned to at any time.

When editing, help tips are displayed in a column to the right.

When editing pages, the changes can be previewed below the editing box.

The info page displays the relevant information for each page.

VII. Roadmap Features

Comments

To make RWiki useful in a educational environment, we will add the facility for users to add comments to pages. This will probably be a sequence of Wiki pages, probably with a different set of permissions, that are associated with the main page.
RSS feed

Feed of recent changes as RSS, but also other features. If these events are RWiki specific they should be RWiki standalone, otherwise they should integrate with Sakai Events.
Helpers

Expose the pages of the Wiki as undecorated content so that other tools can use the content.
Courier / Event Integration

Every transaction in RWiki should cause an event to register. This will allow users to be notified when another user starts to edit a page
Rename page

Add the functionality to rename pages
Spelling

A non intrusive spell checker that checks spelling as the user types (using Ajax).
Search

Improved search functionality, including ?or? and ?phrase? operators