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

This is an interesting case, but I'm not sure that there aren't multiple conflated ideas here, including archiving, associating graphics with a portion of a web page, and associating graphic annotations with content and the web annotation model. I think the latter is quite interesting, though possibly  a complicated v.next topic.

On that item,  is another example what Apple demonstrated with the stylus for the iPad Pro? Has anyone looked at that in more detail?

The issue for such annotations is how do you find them and correlate them with content if they are just a graphic layer? (I think the answer is that the app that allows creating such graffiti annotations must also populate a more semantic layer linked to the graphics, i.e. fit the information into the model appropriately). This is why I think it is v.next/

see below for some comments/questions

regards, Frederick

Frederick Hirsch
Co-Chair, W3C Web Annotation WG

www.fjhirsch.com
@fjhirsch


> On Sep 21, 2015, at 4:35 PM, Doug Schepers <schepers@w3.org> wrote:
> 
> 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

why is this different from the current Web Annotation model of URLs + selectors? (I think from below you agree, that maybe additional selectors need definition)

> 2) should allow arbitrary archiving URLs, formats, and protocols (e.g. should not require Memento protocol)

URL enables retrieval without specifying how archived? Why is archiving a standards problem for this group?

> 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

app needs to map pointer events to content and make semantic mapping?

> 4) must provide graceful fallback for annotations in UAs that don't support drawing or archiving

sounds like trying to swallow a whale. Maybe we should start in v1 with simpler cases?

> 
> == 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.

can you  explain scroll and zoom, why would that change the association?

> 
> 
> == 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 Monday, 21 September 2015 21:18:58 UTC