Difference between revisions of "Specifications"


(Specific pages that should be created)
(User contributions)
Line 162: Line 162:
*Grey text = Contributed by another user  
*Grey text = Contributed by another user  
*Black text with strikeout = Text contributed by user and deleted by another user  
*Black text with strikeout = Text contributed by user and deleted by another user  
*Grey text with strikeout = Texas contributed by another user and deleted by user
*Grey text with strikeout = Text contributed by another user and deleted by user
===Example ===
===Example ===

Revision as of 06:49, 21 April 2012

This page lists the proposed specifications for the development of the OPOSSEM wiki.

Wiki Objectives

OPOSSEM, the Online Portal of Social Science Education in Methodology, is an online portal to facilitate sharing of various resources for teaching social science research methods (particularly statistical methods) among educators in secondary, undergraduate, and postgraduate settings. Little educational material is freely available to serve the needs of basic research methods courses in the social sciences, particularly political science. The creation of problem sets and lecture notes is time-intensive, and methods courses requiring such preparation are becoming more widespread across all types of institutions. This project seeks to reduce these start-up costs and enhance methods instruction by providing an online space in which instructors can share materials and information. Community members are able to post to the discussion forum, share teaching materials (syllabi, lecture notes, assignments, or working papers on teaching research methods), suggest external resources (online data source, resources for students or instructors, or published research on teaching research methods), or rate community content.

The proposed wiki-based, online textbook project responds to two needs. First, as suggested above, the range of textbook options for instructors of undergraduate research methods is quite limited. Instructors must take most textbooks as all or nothing propositions, without having flexibility to adjust content to their particular course’s learning objectives. The poor fit between the available texts and the learning objectives creates situations where students struggle not only to learn new quantitative methods that are unfamiliar and intimidating to them but must do so with examples that are not clearly related to their own political science or backgrounds. Student learning would be enhanced were they to have access to content that more clearly linked the research methods to the theories and approaches they learn in other political science class and to their own experiences.

Second, research methods textbooks are quite expensive for students, even though the core content (i.e., the equations, methods) in the text changes little from edition to edition. Compared to other textbooks in political science, research methods texts, with the costs of typesetting equations and the sometimes extensive use of figures, are often at least 50% more expensive for students. This creates a burden for students with limited resources, who cannot easily afford such texts.

The wiki-based textbook project will address both of these needs by enabling instructors to design a custom textbook option from the wiki-based content that will suit their particular course and to provide that textbook to their students in either Adobe Acrobat (.pdf) format or as a hardcopy distributed through their university bookstore at significantly reduced cost. However, before this is possible, the MediaWiki site hosting the textbook content must be developed and customized.

Wiki Content

Wiki content will include textbook topics related to social science research methods. The content will be written only by members of the OPOSSEM community, which includes both faculty and graduate students. The content will include a number of topics, ideally organized in the smallest possible units, so that instructors can combine the topics they want to have included or covered in their version of a methods textbook.

Each topic should have associated with it the following content, which would "follow" the core text or content:

  • List of equations used in the topic
  • List of questions or problems related to the topic
  • List of keywords or glossary terms related to the topic (and linked to glossary entries)
  • References

Example of how topic content should be stored or available for editing

Error creating thumbnail: Unable to save thumbnail to destination

Example of how a registered user should be able to organize content into a new page, or chapter

Error creating thumbnail: Unable to save thumbnail to destination

Wiki Functional Requirements and Features

Hosting configuration

Currently, the site is hosted/configured at However, to conform with current recommended practice, the site should be hosted at

Optimization and security

The site must be optimized to minimize server calls and facilitate fast page loading. The site must be secure.

Single-sign-on (SSO)

The site must implement single-sign-on using cookies (not LDAP, not OpenID, not Shibboleth, etc.) with our existing Drupal site (, using Bakery or another similar tool. Users will sign-on only through the Drupal site (, master) and be redirected to the Wiki (, slave). Users will not be allowed to modify their user name or password from within the wiki, and this function should be disabled in the wiki. Any changes must be made on the Drupal site and then propagated to the Wiki site in a true "sync." That is, changes to the user name, email, or password on the Drupal site must be updated to the Wiki automatically without admin intervention nor the creation of duplicate accounts. Clicking "login" on the wiki site should redirect to the Drupal login page, and likewise, clicking logout on either site should logout the user.

User page and talk

The user page in the Wiki (for example, User:Michelle_Dion) should be pre-populated with a link to the user's profile page on the main site (, if possible. The user talk page will keep its default features.

Users should be able to customize the notification settings for their talk pages, but they should not be able to change the email address to which notifications are sent. These should always go to registered email address in the Drupal database, which is kept in sync with the user tables in the Wiki.

User roles & permissions

User roles will be defined in the Drupal site and should be synced to the user table of the Wiki site, where they will inherit Wiki permissions defined below (or in the sections on the different features).




Future updates

Whenever possible, customization to standard extensions should be minimized so that the site is easily maintained. Any customization or modification to existing extensions must be documented.

Download/Output options

Users should be able to download any page, or collection of pages (see books below), in each of the following formats:

  1. XML
  2. LaTeX
  3. Acrobat .pdf
  4. epub (cf:
  5. Kindle
  6. mobi?
  7. OTHERS?

User created books and User bookshelf

Users must be able to select a list of pages (including pages they have created in their user area, such as User:Michelle_Dion/POLS784courseoutline#Course_Policies) and easily (re)organize these pages in a customized order to form a book, which can then: be saved to the User's "bookshelf," a separate area to house their personalized collections of pages. All books on the bookshelf will be public, and any visitor can browse the books on user bookshelves.

QUESTION for TEAM: Should users be able to make their own books "private"? And, how to handle hosting books for students, but also potentially giving the option of restricting access on our site to registered users? Thoughts?

Registered users should be able to "save" someone else's book to their own bookshelf.

These books should also be available to be downloaded as XML, LaTex, .pdf, .mobi, .prc, and (OTHER FORMATS??) [By registered users only? Or anyone? Or user has option to choose?]

These features should be like those available in the Create Book tool, but with the added provision that books are automatically be saved as associated with a particular user, and then are stored in a standardized location, named the User's bookshelf. Users should also be able to easily save someone else's book to their own bookshelf, and then have the option to edit their own version of it.

There must also be the capacity to run a query that audits the created textbook to ensure all internal references work (e.g. that all pages referenced in included material are included) so people don't end up with incomplete books. The query would return a list of missing pages and provide the user with the option of adding those pages.

OPOSSEM library

Visitors must be able to browse the books that have been saved by users and the saved books should be listed (or sortable) by the following characteristics:

  • User name (the person on whose bookshelf the book resides)
  • Most viewed (or downloaded)
  • Most recently updated
  • Book Title

Functions that allow contributors to easily add and organize new content


Equations must have a separate namespace and must be protected so that only editors can change equations. All textbook pages must include hidden text (that is, that can be viewed only when editing) that advises those that edit pages on how to use existing equations in their page and where to look up the list of existing equations.


A separate namespace will be needed for keyword definitions or glossary terms. In the text, these keywords will be marked, and should automatically be transcluded to the bottom of any page on which the section of text appears (like the reference system).

We will provide an extensive list of keywords, and the most recent Wikipedia definition for these keywords should be imported to the OPOSSEM glossary to provide a starting point for our community to edit the definitions.


Problems and/or questions should also be associated with each section of text, and these, too, should automatically 'follow' the text and be transcluded (wc?) to the bottom of whatever new page they appear upon. Again, this would be similar to the reference system.


Examples should also be associated with each section of text, and these, too, should automatically 'follow' the text and be transcluded (wc?) to the bottom of whatever new page they appear upon. Again, this would be similar to the reference system.

Need to be able to tag examples by field and subfield (e.g. sociology, Canadian politics, etc.) and allow selection of examples to include by these criteria (e.g. to exclude US politics examples for a Canadian textbook).

Forking/Branching Pages

Need to have option for building a "forked" page that incorporates content from an existing page but changes/adapts it to a particular approach.

Need to preserve edit history for forked pages (e.g. if someone produces "my version of regression" based on "regression", the "regression" history should be carried forward to retain attribution etc.).

Specific pages that should be created

Main Page

What should this have on it?

How to get involved

This page will have text that invites OPOSSEM community members to get involved, with a number of suggestions.

This page must also include lists of the following pages:

All the pages in the OPOSSEM namespace

All the pages listed in the Maintenance reports section of Special:SpecialPages

All the pages listed in the List of pages section of Special:SpecialPages

Tools for Editors

This page should include the relevant links for editors to use. This includes all the links in the Quality Assurance section of Special:SpecialPages.

Anything an editor can do but that no other users can do should appear on this page to make it easier for editors to see what tools they have.

Official page versions

Each July 1 (or thereabouts), editors will review changes to the pages since the last official version of the page and "approve" changes to create the official/protected version of the page.

Visitors and members can view either the current version of the "official/protected" or 'flagged' version of pages.

There must be a page that lists all "flagged" or reviewed pages, with the date of their most recent review.

See Special:ReviewedPages. Question for Team: Need to figure out how to explain this because we'll want annual editions of the textbook to stay static.

User contributions

User contributions must be displayed in a way that is easy for external reviewers/department chairs to "see" and evaluate. The default page view for User contributions (e.g., Special:Contributions/Michelle Dion) does not meet this requirement.

In addition to the default contributions view, a custom view should be created for each user that will each page the user has edited. When the link to that page is clicked from this list, it will return a copy of the current page with the following characteristics:

Display current version of page with content contributed by user (black) and others (grey) plus:

  • Any text added by user that has been subsequently deleted by any other user (Black text with strikeout)
  • Any text that was added by another user that was deleted by user (Grey text with strikeout)
  • Any deleted text from other users should not be displayed.

Sample Color Key:

  • Black text = Contributed by user
  • Grey text = Contributed by another user
  • Black text with strikeout = Text contributed by user and deleted by another user
  • Grey text with strikeout = Text contributed by another user and deleted by user


Lorem ipsum dolor sit amet, consectetur adipiscing elit. Curabitur bibendum ullamcorper viverra. Donec malesuada nulla nec augue aliquam eget mattis justo lacinia. Nunc mattis tempor lorem nec scelerisque. Donec aliquam tincidunt arcu, a egestas ante ultrices eget. Curabitur neque orci, rhoncus vitae gravida eu, blandit in nisl. Aliquam dui nisi, tincidunt sit amet lobortis gravida, rutrum eu elit. Donec lacinia, ante dignissim auctor dapibus, nulla nunc accumsan enim, eget vestibulum nibh est at mi. Ut enim eros, iaculis et fringilla sit amet, ullamcorper non urna. Nunc id semper sapien.

Cras faucibus malesuada pellentesque. Phasellus vitae magna diam, non iaculis dui. Aliquam hendrerit pellentesque ipsum, quis accumsan risus adipiscing nec.In vel tellus orci. Donec libero nunc, tristique non bibendum viverra, fermentum ut leo. Cras porta pharetra justo. Nulla aliquam placerat leo, a eleifend ligula tincidunt in. Maecenas dapibus, urna quis varius tincidunt, diam magna hendrerit massa, eget eleifend sem ante et massa. In et lacus ut quam venenatis consequat sit amet vitae eros. Pellentesque habitant morbi tristique senectus et netus et malesuada fames ac turpis egestas. Proin vulputate imperdiet nulla vel varius. Sed porttitor suscipit venenatis. Aenean tortor velit, sodales porttitor dapibus non, rhoncus ac lacus. Quisque aliquam adipiscing nisl at adipiscing. Pellentesque sodales sem a quam consequat tincidunt. Etiam orci eros, placerat in rhoncus a, tempor ut sapien.

Morbi tempor libero vitae neque consequat tristique. Morbi nisi dui, egestas at faucibus sed, tempor eu risus. Quisque faucibus molestie lectus, quis feugiat metus lobortis sit amet. Aenean et fringilla est. Sed turpis est, tempus ut aliquam id, consequat sed enim. Suspendisse interdum arcu sit amet tellus fermentum nec egestas purus scelerisque. Praesent at molestie quam. Proin eget augue vitae justo porttitor sodales. Nunc et lectus vitae nulla fringilla interdum non sit amet ante. Sed nec nibh ligula, non venenatis mi. Curabitur ultrices, nisl id faucibus laoreet, purus mi tempor tellus, id iaculis ipsum eros sed turpis. Curabitur luctus erat fermentum augue mattis ac dapibus mi lacinia.

Question for team: Should dates be included?? How/where?


Wiki design

The MediaWiki skin or website design must incorporate design elements from the existing OPOSSEM Drupal site. In particular, the Wiki site must:

  1. Use visual elements, the logo, and colors already in use on the Drupal site
  2. Not use a theme that looks in any way like the default Wikipedia theme

The wiki need not look exactly like the Drupal site and indeed should look more like a book or wiki site than the main Drupal site. That is, the Wiki theme need not be fully integrated into the main Drupal site, but the two sites should share common design elements and a similar 'look'.