[sugar] Annotation (was Re: Viewing PDFs from Browse)

[Samuel Klein]

Annotation is different from editing and original creation.

A user can in fact annotate a file or document they do not have
locally.  I find that use case more likely than the alternative; I
have never succeeded in pushing a book report upstream into a
publisher's next edition.

Annotation, commentary, and review should be cleanly separated from
[ownership of] the original document or media file.

A set of annotations is in general much smaller on disk, much more
frequently versioned, and more likely to need sharing (rather than
independent discovery of copies of the same work) than originals.

A set of annotations made to one version of a document are also
relevant to other versions, so it can limit reuse and collaboration to
imply too strong a connection with a specific original document.
Conversely defining annotations such that they exist separately from a
document helps make different sets of annotations overlay with one
another.

To use your image-drawing example, if there is an original image that
I can expect others to have seen, and I am drawing on top of it, I
would indeed hope that the drawing is stored in such a way that the
original can be deciphered -- so that if you and I draw different
things, I can tell that it was on the same image, or add our two
drawings together, or switch from mine to yours simply by exchanging
"drawing layers" rather than exchanging the entire image.  If you
store my mona lisa mustache by modifying the mona lisa in place on my
machine, this is hard to separate out in the future.

After passing through a world with millions of works and terabytes of
data, the small part of this that I hope to preserve as my own gloss
and memory of it, the part I might keep in a real journal, is
effectively my set of annotations, assessments, margin notes : these
should be built deeply into [Sugar], and the usability and sharability
of them refined.

See also [[annotation]] on the wiki, for the above and for discussion
of how to link annotations to words, pages, collections, collaboration
sessions, and projects; similarities b/t comments, discussions,
annotation and review; &c.

SJ

PS - While I do not see annotations being tied tightly to original
works, I can see annotations of different works being closely
associated with one another.

On Sat, Oct 11, 2008 at 10:11 AM, Eben Eliason <eben.eliason at gmail.com> wrote:
> The user couldn't annotate a file they don't "have".  Obviously we
> have to download the bits to a temporary location to view them, but in
> the normal paradigm of the web, nothing is permanently kept unless you
> explicitly download it.  Perhaps an attempt to navigate away from the
> page could ask if you wanted to keep it around or not, but I'd just as
> soon expose the keep button and have kids learn to keep only what they
> actually want.  Everything on the web is transient unless you grab
> something while you can.
>
> It doesn't really make sense to me to add annotation tools and such to
> the pdf viewer in Browse for this reason.  It should remain limited to
> handy viewing controls, saving the annotation tools for Read once the
> document is local, I feel. (As an analogy, you wouldn't expect to be
> able draw on top of or otherwise edit an image within Browse, right?
> You'd be able to zoom, pan, *maybe* rotate; but you'd download it and
> edit it in an activity designed for that purpose.)
>
> - Eben
>
>
> On Sat, Oct 11, 2008 at 6:21 AM, Tomeu Vizoso <tomeu at tomeuvizoso.net> wrote:
>> On Wed, Oct 8, 2008 at 5:01 PM, Eben Eliason <eben.eliason at gmail.com> wrote:
>>> On Wed, Oct 8, 2008 at 10:53 AM, Tomeu Vizoso <tomeu at tomeuvizoso.net> wrote:
>>>> On Wed, Oct 8, 2008 at 4:46 PM, Eben Eliason <eben.eliason at gmail.com> wrote:
>>>>> On Wed, Oct 8, 2008 at 4:24 AM, Tomeu Vizoso <tomeu at tomeuvizoso.net> wrote:
>>>>>> On Wed, Oct 8, 2008 at 1:40 AM, Eben Eliason <eben.eliason at gmail.com> wrote:
>>>>>>> Hey, this looks pretty cool, actually.  One powerful addition which I
>>>>>>> think is necessary in order to adopt this is the addition of a Keep
>>>>>>> button in that toolbar, by which one *could* download the pdf for
>>>>>>> offline reading later if wanted.
>>>>>>>
>>>>>>> In a similar vein, would it be possible to create a supplemental
>>>>>>> toolbar like this for other media types which browse specifically
>>>>>>> supports?  I could see having a similar UI for images, and a perhaps
>>>>>>> for audio and video, too.  The ability to view various formats
>>>>>>> directly, yet also have a one-click means to download the file, sounds
>>>>>>> promising.
>>>>>>
>>>>>> Hmm, shouldn't the act of viewing a PDF create an entry in the journal
>>>>>> that allows you to resume this act? If so, shouldn't the viewer plugin
>>>>>> create an entry in the journal by itself and that entry would contain
>>>>>> the PDF?
>>>>>
>>>>> Well, in this new model, I'd think not, actually.  I can view an image
>>>>> directly within Browse without creating a new Journal entry.
>>>>> Basically, anything Browse handles natively remains a part of my
>>>>> Browse session.  Anything which it cannot, or which I explicitly wish
>>>>> to keep for myself, becomes a new downloaded object.
>>>>
>>>> So Browse would create some kind of entry that would allow resuming
>>>> the reading of that book?
>>>
>>> Of course.  Basically, the following would happen:
>>>
>>> 1. Child clicks on a link to a pdf (or "natively supported media type")
>>> 2. Browse displays the pdf directly, with the contextual toolbar
>>> 3. Browse does not yet interact with the DS; this is just part of what it does
>>>
>>> (Stopping here would result in no Journal entry, apart from the Browse one)
>>
>> Not sure about it, if the user spent some good time reading (and
>> perhaps annotating) the PDF, shouldn't the journal record this in the
>> same way it tries to record all worthy interaction with the machine?
>>
>> Regards,
>>
>> Tomeu
>>
> _______________________________________________
> Sugar mailing list
> Sugar at lists.laptop.org
> http://lists.laptop.org/listinfo/sugar
>