[annotator-dev] colored notes

[Robert Sanderson]

Dear all,

Is it the case that the colors, once selected, should persist throughout
the lifespan of the annotation?  Thus when the user selects the pinkish
color in the screenshots, all other users should also see that same pinkish
color.

Is this an important, must-have feature, or only something that could be
useful in some situations?

Many thanks!

Rob



On Tue, Jan 7, 2014 at 9:48 AM, Steph Skardal <steph at endpoint.com> wrote:

>  Hi,
>
> For my project, I heavily modified the viewer and editor and the addField
> API did not have enough capabilities. I was able to completely override the
> viewer addField method (
> https://github.com/berkmancenter/h2o/blob/annotator/public/javascripts/h2o-annotator.js#L23-32)
> in my plugin to control the order of annotator fields, but I didn't want to
> override the editor addField because it's a lot more code that I would be
> copying over and having to maintain, so I edited the core there. My core
> edits there were to allow for special DOM elements that do special things
> (e.g. a button to add a new "colored" layer, a div to that displays data
> from the database for which the user can select a result to tie the
> annotation to). The code that handles the onclick event for the special
> button lives in my plugin.
>
> Attached are a few screenshots of the UI.
>
> Personally, I don't think more direct presentation management is needed
> but the option would be nice. I like the idea of continuing to use an API,
> I just think that it needs to be built out a bit to allow for more advanced
> DOM elements and events tied to them, as well as to allow more control over
> the order of the fields. I accomplished the reordering by directly
> manipulating annotator.editor.fields in my plugin. I see a need for
> breaking down the editor addField method into smaller components so that it
> is more easily overridden. For example, instead of using a switch / case
> block in the editor addField method, would it be more advantageous to
> "register" field types and then have methods that correspond to each field
> type (or simply have an object with the various methods per field type)?
>
> With any open source project, I think it's just a matter of seeing how a
> tool is used and overridden to understand what methods might be valuable in
> the core. In summary, my shortlist of API needs for the viewer & editor
> addField methods:
> - ability to control order of fields when adding or when adding a new field
> - ability to remove fields
> - ability to add more advanced DOM elements / divs with multiple elements
> in addition to those already included
>
> Steph
>
>
>
> On 01/07/2014 04:10 AM, Randall Leeds wrote:
>
> I am curious whether the viewer and editor, with its .addField API, is
> serving needs or if people would rather manage presentation more directly
> and work more with the raw annotation data.
> On Jan 7, 2014 12:39 AM, "Riccardo Tasso" <riccardo.tasso at gmail.com>
> wrote:
>
>> To be quick I had to use one of the solutions provided in this thread,
>> but it seems to me that each one provides a slightly modified version of
>> the core. Maybe Ewald', Albert', Georgios' and Steph' work could be merged
>> to a new version of Annotator which supports multi-colored highlights with
>> or without a plugin?
>>
>>  This would be great,
>>    Riccardo
>>
>>
>> 2014/1/6 Randall Leeds <tilgovi at hypothes.is>
>>
>>>   On Thu, Dec 5, 2013 at 1:29 PM, Riccardo Tasso <
>>> riccardo.tasso at gmail.com> wrote:
>>>
>>>> It seems there is no way to accomplish this task without touching the
>>>> core!
>>>>
>>>>
>>>  Please elaborate on deficiencies and let's fix them!
>>>
>>
>>
>
> _______________________________________________
> annotator-dev mailing list
> annotator-dev at lists.okfn.org
> https://lists.okfn.org/mailman/listinfo/annotator-dev
> Unsubscribe: https://lists.okfn.org/mailman/options/annotator-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.okfn.org/pipermail/annotator-dev/attachments/20140114/f427407a/attachment-0004.html>