"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 Monday, 21 September 2015 20:35:29 UTC