Re: "Graffiti" and "Web-Clipper" Annotations

Hi, Tzviya, Bill–

Thanks for the feedback. I've added the Instructor's Manual scenario [1] 
to the use case; please edit it to correct any mistakes I made.

I agree that this is a good addition for a formal publication 
perspective. I do think that the "production workflow" scenarios are 
also valid and useful, especially considering how much the Web has 
become a medium for collaboration. It's good to get a variety of 
perspectives to make sure that the requirements fit a general use case.

[1] 
https://www.w3.org/annotation/wiki/Use_Cases/Graffiti_%28Web_Clipper%29#Scenario_5:_Instructor.27s_Manuals

Regards–
–Doug


On 9/21/15 5:16 PM, Bill Kasdorf wrote:
> Really great use case, Tzviya!! Whereas the "Art Director"
> annotations are typically used as part of a production process, but
> are not typically part of a published document (other than
> "published" within the workflow, prior to formal publication), this
> is an excellent example of formally published content with these
> kinds of annotations. The same use case applies to other types of
> instructional/training/technical manual publications, outside of
> K-12, as well, though the K-12 use case is the best example.--Bill K
>
> -----Original Message----- From: Siegman, Tzviya - Hoboken
> [mailto:tsiegman@wiley.com] Sent: Monday, September 21, 2015 4:46 PM
> To: Doug Schepers; W3C Public Annotation List Subject: RE: "Graffiti"
> and "Web-Clipper" Annotations
>
> Hi Doug,
>
> The "graffiti" style perfectly describes the way that many
> Instructor's Manuals for K-12 (grammar and high school) books are
> created. There is a snapshot of a page of a book, and arrows and
> overlays with additional information for the teacher.  Publishing
> would love to be able to create this as annotations layer. Ideally,
> the "snapshot" layer is functional (and accessible) as well.
>
> Tzviya
>
> Tzviya Siegman Digital Book Standards & Capabilities Lead Wiley
> 201-748-6884 tsiegman@wiley.com
>
>
> -----Original Message----- From: Doug Schepers
> [mailto:schepers@w3.org] Sent: Monday, September 21, 2015 4:35 PM To:
> W3C Public Annotation List Subject: "Graffiti" and "Web-Clipper"
> Annotations
>
> Hey, folks–
>
> There's a class of annotation client that's been troubling me for a
> while. They're pretty common, and they don't seem to fit well into
> our model.
>
> They don't just neatly select text or portions of images like our
> data model suggests, and they usually don't display annotations in a
> sidebar.
>
> I'll call this the "graffiti" annotator. It normally treats the web
> page like an image, rather than like text (even the text portions),
> and it lets you scribble on top of the page.
>
> I've noticed two main types of graffiti annotator:
>
> 1) The Art Director: this uses the site as a canvas to comment on the
> visual appearance of the site… circles and arrows highlighting
> colors, layout, images, fonts, and so on, and less commonly the text
> content itself. For an example, see Marqueed [1] and others.
>
> 2) The Archiver (or "web clipper"): this saves a snapshot of the
> page, either as HTML or as a screencap, or both, and archives it
> locally or somewhere in the cloud. The highlights and handwritten
> comments may or may not be done in a "responsive" way regarding
> layout changes (depending on the app's sophistication); if it's a
> screencap image overlay, it probably won't be responsive. If it's a
> pen-tablet copy-edit workflow, it will likely store (or convert)
> selected text to text, in addition to saving a raster snapshot. For
> examples, see MS Edge browser, Diigo [2], Evernote Web Clipper, and
> so on.
>
> The Data Model spec does talk a bit about archiving in the Time State
> Specifier [3], but it's mostly a passive property that relies on
> there being an active Memento server involved somehow, and it doesn't
> describe normative requirements in detail. The "snapshot" archive use
> case is a bit different than the Memento use case, because it's not
> intended to provide a canonical system of dated versions and
> alternative equivalents, like Memento.
>
>
> I recently had a notion for how to model a graffiti annotator; I'd
> welcome help in fleshing out details, either for the use cases and
> requirements, or for the solutions. If we can find a way to map this
> neatly into the Data Model, then it might have wider appeal,
> specifically to graffiti annotator implementers, and we can serve
> users by better interop and by providing clearer ways to point to
> their archived sites.
>
> Obviously, we can't satisfy every use case in Data Model v1. I'm
> inclined to propose this for v1, though, because it addresses key
> features of existing applications and services.
>
> I think we can satisfy major variations on this use case with a
> couple of new motives (motivations/roles), and a new selector type.
> I'll outline some requirements and suggested solutions here, and also
> on the wiki [4].
>
>
> == Requirements ==
>
> 1) must be able to indicate the location of a user-archived version
> of a webpage 2) should allow arbitrary archiving URLs, formats, and
> protocols (e.g. should not require Memento protocol) 3) must provide
> a mechanism for representing and reproducing symbols or drawings on
> the rendered area of a document, with considerations for relative
> positioning of the drawings to the content of the page, to x-y scroll
> position, to zoom level, to rendered dimensions, to viewport, and to
> other relative rendering factors 4) must provide graceful fallback
> for annotations in UAs that don't support drawing or archiving
>
> == Proposals == === Area selector ===
>
> This should be somewhat similar to area selectors for images, but
> perhaps with added characteristics for viewport, dimensions, scroll,
> and zoom of a document. It should indicate that it's a Web page, and
> not necessarily a traditional image, that it's pointing at.
>
>
> == Motives: Archiving and Drawing ==
>
> These (possible) motives would capture the different aspects of this
> use case (1+2 and 3); they are orthogonal, and could be used
> independently, together, or with other motives.
>
> `archiving` would satisfy requirements 1 and 2. It's most likely to
> be used on a `target`. The corresponding property value would be the
> URL of the archived version of the document/resource. I think the
> date of the archiving action could be derived from the annotation
> timestamp, so it wouldn't necessarily need its own timestamp, though
> could be an optional addition.
>
> `drawing` would satisfy requirement 3. I don't know whether it makes
> the most sense as a `target` or a `body`; as a `target` it makes
> sense because it's highlighting specific sections of a document; as a
> `body` it makes sense because it could be additional new content,
> like handwritten notes or symbols. Opinions welcome.
>
>
> There's probably quite a lot else to think about here, but I hope
> this is enough to help frame the use case for more discussion.
>
>
> Note: This class of annotation client has some history of being
> unpopular with site owners, because it "defaces" their page, or
> because it doesn't make a clear separation between the publisher's
> content and the annotator's content. (See the protests against Third
> Voice from the late 1990s–early 2000s [5].)
>
> [1] https://www.marqueed.com [2]
> https://www.youtube.com/watch?v=VHWapAF1Txw&t=96 [3]
> http://www.w3.org/TR/annotation-model/#time-state [4]
> https://www.w3.org/annotation/wiki/Use_Cases/Graffiti_%28Web_Clipper%29
>
>
[5]
> https://web.archive.org/web/20000129090035/http://www.telegraph.co.uk/et?ac=000647321007942&rtmo=qu9qXex9&atmo=lllllllx&pg=/et/99/9/30/ecfstik30.html
>
>  Regards– –Doug
>

Received on Wednesday, 23 September 2015 01:23:28 UTC