C2C Requirements Prioritization
 Share
The version of the browser you are using is no longer supported. Please upgrade to a supported browser.Dismiss

View only
 
ABCDEFGHIJKLMNOPQRSTUVWXYZAAAB
1
Priority
(Must/Should/Could)
#Requirement
2
#Label
3
1Must1.0Easy-to-use responsive interface, simple and flexible. Make it easy to include annotations: 2-3 clicks process, have a dropdown list of controlled vocabularies, allow tagging with an URL.
4
1Must2.0Keep a simple tool integratable (with a click of a button) with Zotero, Hypothes.is and other tools.
5
1Must3.1Annotations must be visible for non-users
6
1Must6.0Ability to highlight a target (text or image) by color-coding it, drawing a box around it.
7
1Must10.1There will be at least 3 levels of sharing annotations: privately, with a group (members must be identified), and publicly (everyone). (See table below) There may be a need for more levels (for example: “only shared to registered users”). In order to promote sharing open annotations, they should be public by default, but the system will allow the user to configure its account settings to make all new annotations private, public or shared with a group by default. There should also be an option to indicate that you may want the system to ask you each time you annotate whether annotations are shared publicly, privately or with a given group.
8
1Must11.0Modification of annotation target & body should be allowed
9
1Must12.0Keep a log of activities of the system.
10
1Must13.0When creating annotations, the target could be a text chunk, an image or another annotation. Allow adding a tag in a specific place (region) within an image.
11
1Must15.0All annotations are visible by default but can be filtered (e.g. by author, date, etc)
12
1Must16.0Annotations must be stored centrally but could also be cached locally.
13
1Must19.0The system should be multi-platform.
14
1Must20.0The system should allow to associate a licence with the annotation for any non-private use.
15
1Must21.0Content creators should alway be logged into the system
16
1Must22.0Only creators can modify (not delete) their own annotations, with the exception of administrators who can modify anyone else’s annotations. If we allow edition, then we will need to link annotations to the different versions of the target (e.g. Google docs “resolve” functionality hides the old comment but its still there, not deleted).
17
1Must25.0The system should be able to handle controlled vocabularies/checklists (thesauri; taxonomies like IPNI for all plant names, The Plant List, WORMS, Catalog of Life, and ITIS; gazetteers, etc.) and allow the creation of list of values, lists of people (authors like IPNI for all plant author names like VIAF, collectors, illustrators, VIAF, etc.), traits like morphological terms (Stearn's "Botanical Latin") and Marine Species Traits, habitats from marineregions.org, WWF Ecoregions and habitat ontologies; "Taxonomic Literature" (Stafleu and Cowan) for author names and journal title abbreviations, ontologies (OBO Foundry, Plant Phenology Ontology, FLOPO, PO, Gene Ontology) and systems like Atlas Living Australia, EOL, Index Herbarim and IPNI. This should be achieved by “registering” the controlled vocabulary (downloading locally or self building vocabularies) and make it available through the system. This should then allow an user to choose values from those lists, browsing or searching their labels (for example: habitats like mangrove, tropical montane rainforest, paramo), equivalent names (synonymy) and taking into account their hierarchy relations through time (species taxonomy, localities, etc.).
18
1Must26.0The system would allow the user to define topics (for example: using a hashtag sign #), create a reference to an entity, associate terms to an annotation, etc. This could be done using annotations of annotations (like GoogleDocs uses the comment “Resolved” and dissappears the whole conversation if the last comment is of type “Resolved” but reappears it (and “unresolves” it) if a new annotation is added to the thread afterwards). Linking by adding URLs, replying or highlighting are different ways in the interface to input a certain type of annotation.
not really, but you can flag it
19
1Must27.0Implement search functionality by keyword or type (comments/descriptions/customized tags/categories). Any references to entities within an annotation should be indexed and made searchable (for example: hashtag or @)
20
1Must33.0The system should allow an user to filter the annotations and show only those that came out in the current search result.
21
1Must37.0Different types of annotations should be allowed. For example: specimen reference, taxonomic name, habitat types, corrected text, geographic locations, authors (artist, collector,dates, determined by), notes, reviews, links (URL, URI, DOI, barcode), customized categorization, personalized vocabularies or (hash)tags (“#Interesting”, “#evolution”, “#new_method”, “#lacksDocumentation”, “#lacksanalysis”), bibliography (citation), ratings are just some of the different types that the system could support.
22
2Should3.2Filter annotations by: author, date, category, tags/terms and show only those.
23
2Should4.0Export different formats (text, image or Rich Text) compatible with existing products (Wikipedia, Flickr, Disqus, Wordpress, Pinterest, Zotero, Google Refine, Trove, Digital New Zealand, Smithsonian Transcription Center, Notes from Nature, VertNet, EOL, iNaturalist, AnnoSys, Tropicos, ADAM)
24
2Should5.0When displaying annotations in a search result, include context (i.e if text, surrounding words or, if image is chosen as target, then its the area surrounding the region)
25
2Should7.0Annotations could include also images and entity references in the text of the body, so the use of a Rich Text field is preferred when capturing the body of the annotation.
26
2Should9.0Ability to print target with annotations (layout TBD, but should include PDF (text) and comments).
27
2Should11.1Versions should be supported if the annotation target & body can be modified
28
2Should17.0Annotations need to be discoverable outside of the place where they were added (i.e. separate from the website or target)
29
2Should18.0The system should support assessment of and reply to annotations and notifying of any changes in related annotations
30
2Should23.0Annotations can be flagged (e.g. as inappropriate) or for admin review.
31
2Should24.0Any autocomplete functionality should be modifiable through the use account configuration, including writing URLs.
32
2Should28.0The system needs to allow for validation of a target if it changes (e.g. if the page or sentence on page changes, as in replaced or deleted, we need to account for that and build in functionality to address that
33
2Should30.0Allow annotations as frequently as required, creating efficiencies during the data input. (e.g. maintaining default values for each field configurable through the account setting).
34
2Should34.0The system should allow searching annotations across the repository displaying the body and the target. The context of the target should also be shown for contextualization.
35
2Should35.0Filtering annotations on a digital library level or a book search result level should allow to write a text contained in the annotation or an entity referred to in the annotation like Author, categories and range of dates. For the awareness part, when showing the dropdown list of categories, the values would be followed by the number of annotations in that category in the Digital Library or the book search result; alternative a balloon or status bar could indicate this when hover over or the field gets the focus when the user lands on it. Authors, for example, could be chosen from a list of referred authors in the annotations on this Digital Library or the current book search result. For dates, by default, the creation and modification dates could be filled with the earliest date and the latest date of the annotations in the Digital Library or this current book search result.
36
2Should36.0Filtering annotations on a book viewer level would show the categories used in the current page followed by the number on categories used in the current book; alternative a balloon or status bar could indicate this when hover over or the field gets the focus when the user lands on it. The same with authors of annotations, they could be chosen from a list of referred authors in the annotations on the current page followed by the number on categories used in the current book. For dates, by default, the creation and modification dates could be filled with the earliest date and the latest date of the annotations in the current book.
37
3Could3.0Tool is integratable (with a click of a button) with Zotero, Hypothes.is and other tools.
38
3Could8.0Annotations should be able to expand to more than one page if needed
39
3Could10.0The tool could also allow an user to read the annotations back from a PDF.
40
3Could14.0An user should be able to see the versions of their annotations and they should be able to update. When updating, the ID of the annotation will be kept the same but the last modification date will be updated and a new annotation related to the existing one would be created for the previous version (with the former body and date). This way, using the same ID, but having a different timestamp, the system can differentiate when any annotation that referred to this one may be outdated and require that the user be notified to ratify its validity with the new version of the annotation body..
41
3Could29.0We need the functionality to allow for overlapping text and overlapping regions (e.g. 2 different users highlight the same text or image but with slightly different boundaries)
42
3Could31.0The system should contribute to make the user aware of other existing annotations that might be related. For example, like by highlighting the number of annotations of the same category that the user is choosing for his annotation, allow to search free text or vocabulary terms, traverse annotations with context in a separate search results page and create a reference to existing annotations in the system (in the page/book/Digital Library/Repository) or follow Kindle’s example of marking the more highlighted parts of a book.
43
3Could32.0While typing, the system could suggest the characters to type ahead by looking similar values in an annotations referenced from existing indexed terms. Autofill functionality (suggests words based on what you typed before) could use indexed terms stored in the DB or the browser support this and cache the values to service the look ahead function.
44
3Could38.0Users should be able to duplicate an annotation or copy the body an annotation and paste it with a different target within the system or outside the system in other application (for example, like a citation in Zotero, or a comment in Google Docs, or a conversation in text or a table with targets (and context).
45
3Could39.0Setup a website to support the system. Allow for talk page.
46
3Could40.0Wiki’mize more by allowing users to add annotations while recording the history of changes (versioning) and relying on the power users (like groups’ admins) to help out monitoring that and making the necessary corrections/vetting of the content.
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
Loading...