Information Technology Reference
In-Depth Information
Deep Versions
4)
a thumbnail to be used in lists and
timelines
The repository should track all committed
changes to each document as the backbone of its
sub-content structures. It should attach all com-
ments, discussions etc. to a specific version of the
document to ensure consistency and further the
understanding of the maturation process.
Versioning should be clearly visible in the
document screen, with a current version number
prominently displayed. The user could expand this
version information to a time line of the events
around this and prior versions. The timeline should
show all activities, including sub-content, around
the document, versioning steps and leaps, and
the differences in the document. The user could
literally trace changes back in time by walking
down the time line.
The system should consider each document
“draft” until it receives a new version number by
peer review and agreement. The system could even
maintain several versions of a draft to facilitate
multiple proposals. In the end, only one of these
drafts should be “promoted” to a version.
Depending on other features discussed below
(see “Tres Facet Auditorium”), the number of
peers required to attach a version number to a
document might depend on the version itself.
Traditionally, version numbers consist of three
segments: “version.subversion.build”. An ex-
ample: version “2.1.231” identifies a document
in version “2”, subversion “1”, and build “231”.
Version changes indicate major changes, usually
departures from large parts of the document, from
the prior version. Subversions indicate smaller
changes, and builds usually contain error fixes
and clarifications. The repository might accept
build commits by one person, require a review of
2 peers for a new subversion, and a consensus of
the whole peer group for a version change.
All four should be available to the user directly
on one page, and she does not have to worry
about conversion: the system will handle that
in the background. It should retain the different
rendering versions even when the document is
versioned up to ensure that prior versions remain
easily accessible.
Joe was looking for a specific presentation the
team gave to executive management. He did not
remember the name, but he remembered the title
of one slide: “How to make it happen”. He types
this text into the repository's search engine, and
selects “Advanced Search”. This allows him to
specify more information about the search. He
selects “Headline” and “Exact Phrase” from
the menu. The system now looks for headlines in
documents that contain this phrase. The meaning
of “Headline” is defined specifically for each ap-
plication type: word documents have headlines
directly; in PowerPoint, it means titles in slides;
in Excel, headlines are the names of worksheets,
and so on.
The system now searches for those documents that
match the criteria. Surprisingly enough, several
documents match. Joe switches the view of the
results from simple list (a list of all the documents,
their author, creation and last-edit dates, matu-
rity level and status) to “Thumbnails”. Here, the
list also contains the visual presentation format
of the first page. Still not satisfied, Joe switches
to “Timeline View”, where he quickly finds the
presentation he remembers by glancing at those
thumbnail pictures.
Clicking on the thumbnail, Joe navigates to the
document itself, which opens right in front of him
immediately. If the document had been wrong,
it would have taken him only a few seconds to
navigate to the next one.
Mary was hesitant at first to post a document she
considered half-finished to the repository. When
she heard Brazzer laude this feature, she took
Search WWH ::




Custom Search