Ausschreibung/WikiPraise/Spec

Aus Wikimedia Deutschland
Wechseln zu: Navigation, Suche

The WikiPraise project aims to make information about authorship of individual parts of a wiki page more accessible to readers. It uses data gathered by the WikiTrust project to acquire the authorship information. The WikiPraise project consists of three components, which can be implemented independently:

  1. Praise: For any part of a given wiki page, make it easy to see who contributed it and when, and provide a link to the respective edit's diff view.
  2. Authorship: Show a ranked list of the main authors of a given revision. Users should be able to interactively highlight the portions of the text contributed by each author.
  3. Cite: Make it easy to get a citation-ready excerpt from an article, listing the 5 main authors along with the relevant links and license info.

All three parts shall be implemented in JavaScript, calling the web APIs for WikiTrust and Wikipedia/MediaWiki to retrieve the relevant information. The implementation should work in recent versions of FireFox, Internet Explorer and Chrome (Opera and Safari would be nice). In case an unsupported browser is detected, WikiPraise should try to avoid causing errors or disrupting page display.

Praise

  • The praise view shall be accessible via an extra "tab", placed just after the "history" tab (in the Vector skin, it may be hidden by default, like the "watch" tab is).
    • The tab could be named "WikiPraise", or simply "authors", if it's combined with the "Authorship" view. Make sure the distinction to the history tab is clear, though. It should be easy for admins to change and localize the label later.
    • the praise tab should work for the current as well as older revisions of a page.
  • hovering over a part of the text triggers:
    • a "bubble" showing the author and the date/time of the edit that contributed that part of the text
      • the date/time is linked to the edit's diff view
      • the author name is linked to the user page, links to user contribs and user talk are also provided (like on the history page).
    • all text contributed in the same edit is highlighted
  • Interaction between the bubble and the mouse is important (but tricky). A suggestion:
    • initially, the bubble "runs away" from the mouse, so the user can point freely at any part of the text and get the information associated with it. The mouse is never inside the bubble.
    • when the user clicks, the bubble freezes and becomes "stronger" (thicker border, stronger color). The mouse can then move into the bubble and click the links contained there.
    • the "click to focus" behavior needs to be discoverable. Perhaps simply by writing "click to focus" inside the bubble.
    • the bubble can be "unfrozen" by clicking anywhere outside the bubble, or clicking an [x] button in the bubble.
  • Bonus: Make navigation possible without using the mouse. Keyboard mode is triggered by a hot-key. Then:
    • one word is the "current focus".
    • the bubble and highlighting behave as if the mouse was hovering over the focused word.
    • the focus is moved in the text using the cursor keys.
    • hitting enter takes the user to the diff view
    • appropriate hot keys for the respective user page, user talk and user contribs shall be available.
    • clicking the mouse in the text ends keyboard mode.

Authorship

  • A authorship overview is added to the "Praise" view.
  • The list of authors is shown to the right of the text, sorted by the number of words the respective author contributed to the currently visible revision of the page. Word count should be provided by wikitrust. If not, ask for it to be added and use a simple regular expression for counting as a stop gap.
    • using copy & paste on the author list shall yield a well formatted list of authors that can conveniently be pasted into a word document, etc.
    • Bonus: optionally ignore minor edits in the count. If the relevant marker is missing in the WikiTrust output, ask for it to be added.
  • per default, at most 20 authors are shown. It shall be possible to expand the list, perhaps by clicking a "more" link at the bottom.
  • it should be able to collapse/expand the author list (vertically). a small placeholder is shown when the list is collapsed (e.g. a small vertical tab o n the right of the page). the expansion state of the list should be remembered between pages (perhaps in a cookie).
  • In the author list, anonymous authors should be combined into a single pseudo-author per default. There shall be an "expand" link to see the actual list of anonymous authors.
    • Note: Users with ID=0 are not necessarily anonymous. If there is no "anon" flag in the output from WikiTrust, ask for it to be added. As a stop-gap, use pattern matching to detect IP-like user names. Remember to provide for IPv6 addresses too
  • Similarly, bot authors shall be combined into a single pseudo-user
    • Can be postponed if this is not possible efficiently. Ask the WikiTrust team to include the relevant information in their output
  • The user names are linked to the respective user page.
  • Bonus: the author list shall stay in place when scrolling the page text. However, it must somehow be possible to scroll in the author list, too, if it's to long to fit the browser window.
  • when hovering over an author name, show details about the author:
    • number of words contributed, as well as the number of distinct edits from which these words come (other edits to the page are not counted). Something like "x words from y edits".
    • date/time of first and last edit ("between yyyyy and yyyyy").
    • Links to user talk and user contrib pages
    • contribution highlighting (see below) should be discoverable, perhaps by simply adding a text to the detail bubble: "click on author to highlight contributions in the text".
  • when an author's name is clicked:
    • the author is focused (highlighted/outlined more strongly)
    • this author's contributions are highlighted in the the page text, until another user is selected.
    • Bonus: make highlighting strong for recent, pale for old edits.
    • Note: when an author is focused, and the user moved the mouse over the page text, the contrib highlighting competes with the "highlight text from the same edit" feature from the "praise" module. Make sure the distinction remains clear, perhaps by using different colors. When in conflict, the praise highlighting should always override the author highlighting (because it reacts to hovering the mouse, and is thus more immediate).
    • details about the author (see above) become permanently visible. perhaps an "akkordeon" view could be used: show details below the currently selected used, pushing all other users down. use animation to make this more intuitive.
  • Bonus: provide keyboard-based access to all functions. THe list of authors should be navigated with the cursor keys.

Cite

  • when the user selects some text in the normal article view (of a current or old revision), a bubble with a button for "copy text" (de: "Text kopieren") shall be shown.
    • should work for selections done by mouse and by keyboard (using "show cursor" option in firefox, etc).
    • bubble shall also contain an explanatory text like "create a citation with all necessary information, ready for copy&paste to your blog or web site".
    • Bonus: make the bubble "slide" in when a selection is first created, move it smoothly into place when the selection changes.
  • (Edited 2011-07-13) when the button is pressed, the bubble shall expand and show a preview of the citation
    • there are three modes for showing the citation text for copy&paste:
      • A rendered preview, which can be copied as rich text to Word, etc
      • HTML, shows a non-editable (but selectable) text field containing the citation as HTML
      • Wiki, shows a non-editable (but selectable) text field containing the citation as wiki text
    • there are buttons for switchign between the modes
    • there is a "cancel" button that closes the bubble
    • Bonus: a "copy" button copies the current view of the text to the system clip board (using an appropriate media type) and shows a message like "text copied to your clip board" (may need flash)
    • the bubble should grow as big as needed to accommodate the copy&paste text, if that is not too big (80% width and 80% height of the page should roughly be the limit).
  • the text generated in the text box shall contain:
    • the previously selected text, with link and image URLs expanded to absolute URLs.
    • A paragraph saying "From the page XXXX (link) (hostory link) on Wikipedia, the Free Encyclopedia. Written by (up to 5 main authors, with links to their user page) and x others (if appropriate), yyyy - yyyy (year of first and last edit). Licensed CC-BY-SA 2.5 (link). "
  • bubble should be clearly visible but unobtrusive, e.g. show hovering over the navigation menu on the left, at the same vertical position as the text selection.
    • the bubble must not interfere with the user's normal activity, i.e. selecting more text, changing the selection, etc
    • Bonus: bubble should move appropriately when selection changes (with some delay - e.g. only update location after selection didn't change for half a second).
    • bubble should vanish when the selection is cleared (e.g. by clicking somewhere)
    • the bubble shall contain a [x] button for closing it.

Implementation Notes

  • "bubble" in the above text refers to any block "hovering" over the regular text content. A speech-bubble like form or other non-rectangular shape would be nice and fancy, but is not required, as long as it is clear which part of the regular page content the "bubble" refers to.
  • use jQuery for fancy drawing, animation, and abstraction of JSONp queries, etc.
  • The JS code needs to be easily internationalizable. All interface text should be contained in an array that is loaded from a separate page in the MediaWiki-namespace, and loaded as a system message, so the user interface language takes effect. Each module may have its own message array/page.
  • The source code must be structured and commented in a way that will allow others to quickly understand the code and modify it as needed.
  • if any functionality could be improved by better support from the WikiTrust API or from MediaWiki, this should be duely noted. Where possible, a workaround shall be found as a stop gap, if not, the feature is postponed.
  • The three components should be contained in separate JS files (resp. JS pages). "athouthors" may depends on "praise", "cite" should be independant of the wirst two. Any functionality shared by all three components shall be factored out to a separate file (resp. JS page), e.g. "wikipraise-common.js" or some such.
    • note that gadgets can be assembled from several js files, so the files do not need to import each other directly.
  • implementation on the live sites will happen in three stages:
    1. as "personal JS" on subpages of the author's user page
    2. as gadgets which can be enabled by wiki users in their preferences, and are maintained by wiki admins. IN this stage, WikIPraise will be widely advertized for testing.
    3. as part of the defaulkt site wide JS code. This requires cooperation of the WikiTrust team, since their current setup can probably not maintain the load caused by wide use of their servers. If the gadget is well received, WMDE and WMF will consider options for supporting the WikiTrust team in hosting their service.