All,
The capabilities described in "OHS Comparison Categories"
<http://www.bootstrap.org/lists/ohs-talk/0005.html> are hierarchical, but all
of the indenting of the original posting was lost in the the translation to
hypermail, so it's going to be hard for anyone to sort out that document until
it gets fixed. For now, I've added my own unique on-the-fly outline labeling
below (at the front of each item) but you'll still need to refer to the
original posting for the "full" explanation of each capability.
The purpose of this posting is to try and map these categories (capabilities)
against those called for in the "OHS Framework" document, just to see what sort
of coverage the latter provides. (NB These categories were used to compare
file systems, document architectures, hypertext systems, and general
knowledge-work systems, so not all capabilities mentioned here necessarily
apply at the level of the environment described in "OHS Framework".)
I Information Organization
I.A Filing:
I.A.1 Items Filed Multiple Places w/out Copying - satisfied by having a
document consisting of links pointing to the "filed" documents.
<http://www.bootstrap.org/alliance/alliance-980.htm#2B2A1>
[Link objects should appear in the list of Elementary Objects
<http://www.bootstrap.org/alliance/alliance-980.htm#2A1A1>. Also, since links
are so pervasive, it's hard to keep them confined to 2B2, they contribute to
2A2 Structure, and 2B3 Portrayal (I'm thinking of seeing a link's extent (like
with underlining in html), vs. human-readable link/object addresses, vs.
pulling in what the link is pointing to instead of seeing the link i.e.
transclusion). All of these need to be distinct ways of viewing (using) a
link.]
I.A.2 Folders Filed Within Folders - satisfied by documents containing links
which point to other such documents containing links, etc...
I.B Linking
I.B.1 Fine-Grained Location (Src/Dst) -
<http://www.bootstrap.org/alliance/alliance-980.htm#2B2A1> allows for the
source of a link to be at any given spot within a document, but to only point
to a whole-object destination. I.e. fine-grained source location, but only
whole-object destinations.
Fine-grained locations allow linking from a specific character location in a
document/object to a specific character location in the destination (target)
document/object. (Or from one spot in a graphic image, to a specific spot in a
target graphic image, e.g.)
I.B.2 Fine-Grained Extent (Src/Dst) -
<http://www.bootstrap.org/alliance/alliance-980.htm#2B2A1> doesn't specify
source extent but implies no-extent i.e. a point source. (On web pages, source
extent is shown by the underlined segment of text, for example.) Destination
extent is not specified, but whole-object is implied. This can be confusing
when pointing into the middle of a string or cluster of objects (like
paragraphs) that run together. Exactly what is being referred to isn't clear.
[My litmus test for linking is to link a specified region in a graphic/image to
a specified region in another graphic/image (or to a swept segment of text).
E.g. the user uses the mouse to sweep a rectangle (or whatever) to define the
source and then destination regions. Analogously for text, selecting an
arbitrary contiguous span of text for the source, and any other arbitrary
contiguous span of text (or one of the above graphic rectangles...) for the
destination, e.g.]
I.B.3 Semantic Direction -
<http://www.bootstrap.org/alliance/alliance-980.htm#2B2B1> says we've got
backlinks. But it needs to be specified that links require an explicit
direction from-to. Assuming that links are "typed", tools can then analyze
networks of links and sort out link relations (semantic relationships) like
"caused". Imagine if it weren't apparent which of two linked events "caused"
the other - lawyers would have to get involved which would reduce productivity
no end :-) All Web links, for example, are basically outgoing "reference"
links (i.e. going to some referenced material) which isn't very powerful by
comparison...
I.B.4 Can Follow a Link From Either End
You have to be able to see where a backlink is pointing to in your (target)
document, *and* be able to follow the backlink to the spot in the source
document where it was defined... This is left fuzzy in most backlink
discussions, and <http://www.bootstrap.org/alliance/alliance-980.htm#2B2B1>
should be beefed up if true bidirectional links are desired.
I.B.5 Link Storage - unspecified in "OHS Framework", and it shouldn't be in a
requirements spec. This is a design issue (but a valid down-stream comparison
criteria).
So as a summary example for comparison, html Web links support a fine-grained
source location (to the character) and destination location (to the line?).
The extent of the source is also fine-grained (the underlined text), but the
destination extent is invisible to the user (at best, the intended destination
is scrolled to the top of the browser window, but nothing indicates to the
reader exactly what the link was pointing to). They are untyped unidirectional
links that, from the target end, can't be seen or followed back from. And they
are embedded in the source document itself by it's author (only).
[Actually, there's a missing comparison category as to whether links from
within a document/object can only be created by the document's/object's author.
There are different capabilities + usage-styles which can work. Allowing
anyone to link *from* a document they don't own *to* a document they don't own
is most general (and is provided for in systems like Brown University's
Intermedia, and in Ted Nelson's Xanadu design). The sacrosanctity of the
authored from-document can be maintained by view filters that show only the
author's outgoing links as desired... (And note that links aren't necessarily
embedded/stored/archived inside of the document, as per I.B.5 above.)]
I.C Tagging - not in the spec. Only special case system-maintained tags like
author and time-stamp attributes.
I.D Metainformation - not in the spec. Journal has potential.
II Document Management
II.A Document Architecture
Object-based structure provided for by
<http://www.bootstrap.org/alliance/alliance-980.htm#2A1B1>. Live embedding of
the objects is implied by stretching
<http://www.bootstrap.org/alliance/alliance-980.htm#2C1A2> to say that the
appropriate vocabulary for manipulating a selected object is automatically made
available when the object is selected. I.e. the tool for manipulating the
object (imagine an embedded graphic) is brought to the fore when the object is
selected. Another passing reference exists in the last sentence of
<http://www.bootstrap.org/alliance/alliance-980.htm#2B3A2> [Make this explicit
if that's what's desired.]
II.B Annotations - available via specified linking facilities. Mentioned in
passing in micro-scenario
<http://www.bootstrap.org/alliance/alliance-980.htm#2D2A>. Needs access
controls for specifying visibility by only the intended user or group.
II.C Highlights - not specified. These are seen by the user as e.g.
underlined, italicized, or colored/shaded text (or text-background) or
(shaded/colored?) rectangles in a specific graphic/image, in order to emphasize
an area of interest. (The same visual look would be used to show the extent of
a link source or destination (and can be turned off). In some designs, a link
is an object which connects a source highlight to a destination highlight).
Underlying machinery allows: finding a specific highlight (by its
attributes/tags, including name (like Augment bookmarks)), going to the
next/previous highlight in a document, etc., etc. In effect, highlighting
turns the user-selected region into an object, to which all the powerful object
manipulation/viewing operations can apply... Important for CODIAK.
II.D Linear Versioning - hmmm, only mentioned in passing in the section 2D
micro-scenarios.
II.E Parallel Versioning - *nobody* has this (needs human-side exploration to
determine usefulness)
II.F Access Control
II.F.1 Granularity of Users - i.e. to what granularity can one allow/disallow a
protection. Access control list is most fine-grained. Owner / Group / Others
is more middle of the road. Unspecified by "OHS Framework".
There's another use of "access control" information, namely a user asking the
system to please show (or filter) objects from specific group(s) / user(s) for
decluttering purposes (narrowing the infoverse). Maybe something in or around
<http://www.bootstrap.org/alliance/alliance-980.htm#2B3A2> (view control)? For
looking at large collections of objects/documents... (Hmmmm, this is more
properly discussed under the 1C Tags section of this posting?)
II.F.2 Granularity of Information - protections apply to: whole document,
specific object in a document, arbitrary region of a document, etc.
<http://www.bootstrap.org/alliance/alliance-980.htm#2A1C1> says protection is
at the object level.
III Change-Detection / Notification - not specified. (Rudimentary glimmerings
in: versioning, Journal notifications). Mentioned in passing in micro scenario
<http://www.bootstrap.org/alliance/alliance-980.htm#2D2A>
IV Information Visualization - not specified. This is basically a higher-level
tool set that operates over large collections of objects, as long as there's
some level of machinery available in the objects (like tags)... Might be
captured in a micro scenario like "Study"
<http://www.bootstrap.org/alliance/alliance-980.htm#2D3A>, or "Information
Exploration" or "Data Mining", or some such.
IV.A Filtering - Addressed in
<http://www.bootstrap.org/alliance/alliance-980.htm#2B3A2> (which should say
"filtering by content *or attribute*") (Attribute = tag)
IV.B Info Organization Structure Display - not specified other than for outline
structuring of a document. There should be analogous link and (more generally)
object-collection displays. (Where an "object collection" refers to the
objects in a document, or to an arbitrary collection of documents/objects
(including collections of link objects...))
IV.C Graphs / Plots of Tagged Info - not specified. As an example,
<http://www.spotfire.com/market/demos.html> and
<http://www.spotfire.com/products/spotfire/spotfire3/> give some examples of a
tool that (basically) plots tagged objects...
V Collaboration
V.A Concurrent Editing - covered in
<http://www.bootstrap.org/alliance/alliance-980.htm#2A1C1> where shared objects
are "simultaneously viewable, manipulable, and changeable"
V.B Bulletin Boards - not mentioned. Could probably be created by usage
conventions of spec'd capabilities.
V.C Screen Sharing - covered in
<http://www.bootstrap.org/alliance/alliance-980.htm#2C2A1>
V.D Role Support - not covered. Needs a micro-scenario and references to
access control.
V.E Electronic Signatures - covered in
<http://www.bootstrap.org/alliance/alliance-980.htm#2A1E1>. Needs a tie-in
with Role Support above.
VI Extensibility
VI.A User Written Scripts - basically covered under
<http://www.bootstrap.org/alliance/alliance-980.htm#2C4>
VI.B In-house Programming - no mention of available API.
VII Data Interoperability
VII.A Within Environment - this is extremely important but hard to specify.
You want to say something like "all documents/objects in the environment can be
operated on by all tools in the environment whose operations "make sense" in
the given context" (which is a bit fuzzy). Another try from the "re: OHS
Comparison Categories" posting:
"As a designer, you'd like all capabilities to be orthogonal and play naturally
with each other without special cases or dependencies. And in some sense, you
want a minimal set of constructs (nouns as well as verbs) that are general, and
can be applied in a wide variety of situations. This yields high conceptual
integrity."
This is the holy grail of user-level design... Needs a scenario.
VII.B With External Environment - this is touched on by
<http://www.bootstrap.org/alliance/alliance-980.htm#2C3A2> but for interlinking
only, vs. operating external applications or pulling data from or pushing data
to them (like the Augment Reach system?). (Unless you feel that's covered by
basic link push/pull/execute operations, but then this should be made explicit
if so.)
Well that's it... As I said in the original e-mail (a long time ago) this was
to be a jumping-off point for capturing the desired capabilities of
knowledge-work systems. I still don't consider this list complete or
especially well-factored, so there's certainly room for improvement. At any
rate, as it is, it seems to say that the "OHS Framework" document holds up
fairly well. This specified OHS system would have come up head-and-shoulders
above any other system that was compared with these categories back when they
were developed.
Cheerio,
John
This archive was generated by hypermail 2b29 : Thu Jan 06 2000 - 11:01:17 PST