From MozillaWiki
Jump to: navigation, search

Basic annotation description

An annotation is a simple frame + text overlaid on a screenshot to make it easy to point out the area of focus in a screenshot.

Screenshot Annotator Requirements

An annotation will consist of:

  • A rectangular frame that will appear when the mouse is hovering over the image (not just the annotation itself)
    • Coordinates for the top left and bottom right corners of the rectangular frame
  • Text to show by default (DefaultText), when the mouse is not hovering over the annotation
  • Text to show when hovering over the annotation (HoverText). This text should replace DefaultText while the mouse is over the annotation.

Syntax requirements

  • DefaultText and HoverText should support full TikiWiki syntax, meaning Bold text, Italic text, new lines (%%%) and Links should be supported
(x1,y1),(x2,y2) [Zonelink] Static text with support for wiki syntax
- attrib1 = value1
- attrib2 = value2
Hover text which can span across multiple lines
with support for wiki syntax

Review requirements

  • An annotation will simply be a block of wiki code attached to the wiki body of an article containing an image. As such, it will be part of the article itself, subject to the same review process as a normal wiki edit, and fully localizable.
  • Saving an annotation edit should modify the staging copy of the article, not the live article

Style requirements

  • All CSS used for e.g. frame border and background, and text style, should be globally part of the theme used on SUMO
    • While testing the plugin, the CSS can be inline
  • The wireframe around an annotation should only be visible when the mouse is hovering over the image (which would show all annotation frames).
    • It should be possible to change this behavior with a setting of the plugin (for example, we might want to always show the frames if that proves to be better)

Annotation Editor Requirements

  • When logged in contributors are viewing a KB article, they should see a link for each image/screenshot of an article (either overlaid on the top-right corner of an image, or immediately under it)
    • Clicking on that image should open up a screenshot annotation editor, where the contributor can add/edit/remove annotations for that particular screenshot.
    • The annotations should be loaded from the staging copy of the article, not the live article.
      • Nelson says there is a php function in tikiwiki that can modify the contents of a specific tag of a wiki article, so saving this should be fairly straightforward
      • If the clicked screenshot doesn't exist in the staging copy, an error message should be displayed informing that the staging copy has changed. (It could also automatically direct the contributor to the staging copy when this happens.)
  • The annotation editor should show the image in full size, and include Add and Remove buttons.
  • Selecting an annotation should allow you to change the size and location with the mouse.
  • Selecting an annotation should allow you to enter both hover text and standard text in two text boxes. Again, bold/italic text, as well as links and new lines should be supported.
  • When saving the changes of the annotations, the staging copy should be modified, just like in a normal article edit. Approvers will then be able to review the changes.

Notes regarding possible way to localize annotations

Nelson Ko: We have a Google SoC student working on a screenshot annotation system for us: but I was wondering if annotations could become translatable.

LPH: depends on how they store the data. best would probably to have it stored as part of the wiki page, otherwise the annotations need to have objectids to work with the tiki_translated_objects table

Nelson Ko: as XML as per (haven't decided where exactly, i,e, in db or what)

LPH: but then you need additional tracking stuff

Nelson Ko: probably there will be a tiki_image_annotations table or something

LPH: the stuff I wrote is mostly specific to wiki pages because nothing else keeps a history, but if they keep revision history of their XML, the translation bit magic can be adapted

Nelson Ko: so history is necessary for translation system to work I suppose

LPH: otherwise you can't diff. However, with XML, it may be possible to add version data as attributes on the notes, but that could be a mess to manage depending on the type of content in there and the structure of the annotation XML, this could actually be a viable solution

Nelson Ko:

LPH: yep... if you add a version attribute on the content tag, there is something to do about this. Each region already has a unique identifier