Annotation is a central topic for shared spaces, but unfortunately it is still a stepchild and suffering from many small silly technical problems.
D. Grey sees artefacts and their annotations in the center of shared spaces:
“At the heart of collaboration and learning lies social interaction around artifacts, annotation…”
and I picture them quite literally in the middle of the axis of M. Böttger’s distance concept referred to in my #73. (I am not yet able to draw a diagram, which would perhaps resemble the one of my #81 post, showing interactions on artefacts differently.)
I think what he calls “situatedness” is quite akin to what M. Böttger describes with the medium communication distance. (And Denham’s “continual revisiting and revising” hits my pet idea since #70).
But, as Denham observes:
“Annotation … is emerging as the forgotten stepchild of eLearning and knowledge creation.”
Despite some ideas like those of J. Farmer and others who he quotes, it is still an unresolved problem even from the technical angle, and this has bothered me since a long time.
- When e-mail was new I was very enthusiastic about the quotations indicated by “> ” at the start of the line. Eleven years ago, I wrote a (paper) letter to a dozen of history subject librarians, evangelizing about listserv lists, and describing this feature: “Participants may write their comments right between the individual text passages or previous comments, which may remind you of the ancient communication technique in the monastery libraries using margin notes.”
But the potential was not leveraged. One stupid reason is that many modern emails texts just don’t have a start of line to indent if quoted, and this, in turn is probably due to the fact that the newline character is different on PCs and on Unix, and since it does not matter in HTML, it is a widely ignored (another stepchild!).
- Commenting to individual passages within a text in a web page using a link from one’s own page, should not be a severe problem since, after all, we have the named anchor tag directing the browser’s upper edge to the targeted spot. Always? Except when it is near the end of the page in which case the bottom edge is docked. While the semantic web is promoting the revolutionary focus shift from files to Semantic content within files, such a tiny practical problem within a page remains a major obstacle.
- On wikis, there are nearly unbounded possibilities to change someone else’s content, and to view the differences, but not both at the same time, as we are used to from paper revisions using red pens and margin scribbles, or from word processors’ revision functionality.
If you don’t have the chance to see the text changes in their context and the major context with change indicators, you will end up with two extreme attitudes towards wiki shared editing: some will so extensively refactor other’s pages that these may see it close to vandalism, while others will almost completely refrain from changes.
Still aggravating the problem, most “diff” functions exhibit their provenience from programmer versioning systems, where lines (code commands) are the entity in question which are analysed for alterations, while text paragraphs do not fit.
- Regarding the markup of the commented text spot, someone even came up with the idea to sent his users to the google cache with the search words being the commented text passage. There must be some way to markup the changed text in a less obtrusive way than word processor revision mode does it. I still have some hope that some best practice will emerge regarding how to best indicate that there is something hidden behind the marked-up words other than a proper weblink.
- mouse hovering will show additional information (explanations, context help, other title quickinfo, or comments or deleted text),
- but it’s not a link (or not a normal link leading to further information but only to a glossary, citation, or text revision).
In the context of accessability requirements like abbreviation or acronym tags, I have sometimes seen broken underlines or/and non-intrusively colored or backgrounded text. This is a pattern that lends itself readily to many sorts of markup saying:
But it may be a long way until <abbr> and <acronym> both work in all browsers, and because of their subtle difference they may eventually share the fate of the newline character mentioned above: become stepchild and neglected. Or there may be another silly technical obstacle to prohibit such a desirable emergence.
Don’t these technical problems look like a great niche or challenge for opensource projects forging personal information management tools?