| Following are minutes, notes, minutiae, and esoterica from the Matt Roch/Art
Little era(s) of the Desktop Migration Task Force. Rather than pick and place
the minutes separately, I think the following, provided by Art, provides a good
chronology of the group to the present.
I'll place minutes of future meetings here as well.
Bill
From: TNPUBS::ROCH "10-Feb-1993 1648" 10-FEB-1993 16:57:05.15
To: @DESKTOP.LIS;
CC: ROCH
Subj: Next Desktop Migration Task Force meeting/Minutes from last meeting
The next Desktop Migration meeting will be held:
Thursday, 18-Feb
1:30 - 3:00
Mark Twain conference room (LKG1-2/J16)
Action item from Mondays meeting:
Write down your view of the TNPUBS work environment in 1995.
Include: What tools (applications, hardware, networks) will be used?
What TNPUBS' deliverables will these tools help produce?
Send this information to Matt by Monday, 15-Feb. This information will be
combined, forwarded to the group before the meeting on the 18th, and
will form the basis for a brainstorming session at the next meeting.
A formal agenda for the 18-Feb meeting will be distributed next week.
Minutes from this past Monday's meeting follow.
Minutes from the 08-Feb meeting of the Desktop Migration Task Force
(thanks to Janice for notetaking).
Attendance:
Bill Dubie Elena Aschkenasi
Dave Sciuto Art Little
Janice Sahagian Charlie Terrasi
Denny Dixon Mick Schonhut
Paul Boccelli Mike Wasiejko
Betty Lew Matt Roch
This was a "getting started" meeting for the task force. We accomplished
the following:
1. Developed a "snap shot" of the tools currently used by TNPUBS.
2. Identified categories of current tools issues/problems.
3. Discussed current tools support and some possible assumptions about
future tools.
4. Defined some high-level TNPUBS' goals, goals which should affect
what tools will be needed in the future.
1. CURRENT TOOLS IN USE AT TNPUBS
In the interest of forming a common starting point for all task force
members, the group created a list of all tools/applications/network devices
currently in use at TNPUBS. The intent was to define where we are now before
addressing where we want to be in the future.
Workstation Applications:
o Interleaf (~ 40 users)
o Document (~ 40 users)
o DECwrite (2-3 users)
PC applications:
o MS Word for Windows
o Grammatik
o Visual Basic
o Excel
o PowerPoint
o Aldus PageMaker
o PC Project
o Harvard Graphics
MAC applications:
o Aldus Freehand
o Adobe Illustrator
o Aldus PageMaker
o Quark X-Press
o PowerPoint
Converters:
o Interleaf to Bookreader
o DDIF converter
o Cloverleaf
Tools:
o VMS Cluster
o VMS Workstations
o X-Windows Terminals
o RISC ULTRIX Server
o PCs (10?)
o MACs (2-3)
o CD-Roms (2-3)
o Scanner (1)
Printers:
o LPS20s
o LPS40s
o Kodak
o LN03s
o LA75
o Color Printer
o LA50s
2. CURRENT TOOLS ISSUES
In order to identify potential problems when implementing future systems,
the group identified major categories of current tools-related problems.
o Converting between file formats (Internal and External)
o Training
o Availability of hardware
o Unscalable results from testings
o Application support
3. CURRENT TOOLS SUPPORT STRATEGY/POTENTIAL FUTURE ASSUMPTIONS
Mick showed the following graphical representation of the current TNPUBS'
tools support strategy.
|-----------------|--|--
| Initial | | ^
| System | | ^
| Load (ISL) | | |
| | | |
|-----------------| |>>NaCTS Managed |
| | | |
| T&N Pubs | | |
| Custom | | |
| Load | | |
| | | |
|-----------------|--|-- |
| | | |
| T&N Pubs | | |
| Specialized | |>>On Common Server and Managed |
| Common Area | | |
| | | |
|-----------------|--|-- |
| | | | Applications can
| One-of-a-kind | | | move from unmanaged
| Applications | |>>Minimal support and not managed | to managed
| | | (Virus scans)
|-----------------|--|--
Mick and the team also identified some potential tools-related assumptions
for 1995:
o 75% of department with PCs
o Applications available via Network File Service
o Alpha hardware and software available
o Windows NT as main operating system
o Tools required dependent on client/customer requirements.
4. TNPUBS GOALS
The tools TNPUBS uses in the future will depend on TNPUBS' deliverables (in
turn based on customer needs). The group tried to capture some basic
assumptions as to what those deliverables are now and may be in 1995.
Current/Future Goals:
o Minimal documentation
o Decide on delivery of documentation:
o Increase use of Hypertext and Multimedia
o Remain committed to New Business.
o Online viewing
o CD-ROM distribution
o Continued hardcopy distribution
o Online submission (for improved Time-to-Market)
o Use a PC network of some sort -- for instance PATHWORKS.
o Limit the number of applications to reduce cost of cross-training.
o Address systems security issues.
From: TNPUBS::ROCH "15-Feb-1993 1213" 15-FEB-1993 12:08:09.86
To: @DESKTOP.LIS;
CC: ROCH
Subj: Reminder - Desktop Task force action item
A reminder of the action item due by the end of the day today; so far I
have received only 4 responses from the 14 members of our task force. Thanks
to those who have already responded.
Write down your view of the TNPUBS work environment in 1995.
Include: What tools (applications, hardware, networks) will be used?
What TNPUBS' deliverables will these tools help produce?
Send this information to Matt by Monday, 15-Feb. This information will be
combined, forwarded to the group before the meeting on the 18th, and
will form the basis for a brainstorming session at the next meeting.
From: TNPUBS::ROCH "18-Feb-1993 1043" 19-FEB-1993 10:08:14.66
To: @DESKTOP.LIS;
CC: ROCH
Subj: Reminder: Desktop Migration meeting this afternoon; please read attached "futures" descriptions if you have a chance
A reminder that the Desktop Migration Task Force will meet this afternoon:
1:30 - 3:00, Mark Twain Conference Room, LKG1-2/J16
Agenda: "Brainstorm" regarding future tools and systems, based on action items.
Discuss action plan for task force, revisit deliverables.
Determine regular meeting time/intervals.
Attached are views of the TNPUBS work environment in 1995 as submitted by
several members of the task force. We will base our brainstorming session
on this information, so please try to review these descriptions prior to
today's meeting (don't worry if you cannot, we will summarize at the meeting.)
You may want to extract and print this file for easier reading.
Thanks, Matt
The strategy for 1995 appears to be migrating toward a primarily
MS-DOS environment. This not only aligns our productivity tools
with the rest of the industry, but it also provides a more
efficient way of transferring files with third-party partners.
Working in such as standardized environment could help improve
contributors' productivity, given the wealth of applications and
tools readily available.
I suspect that graphics tools for the DOS world will also compete
aggressively with Macintosh tools; witness the recent release of
Quark Express for the PC, a variation of a well-established
desktop-publishing tool for the Mac.
As processors improve, the distinction between workstations and
desktop systems steadily blurs. The promise of Alpha and even the
Pentium processor from Intel demonstrates that low-end systems
are gaining on workstations in processing power and capability.
The probable set up will include a high-end PC for each
contributor who needs to produce and edit documentation. Software
should consist of customized versions of commercial software,
such as MS-Word for Windows, Grammatik, and PageMaker. Graphics
packages should also figure heavily in these
applications--Harvard Graphics comes quickly to mind. Networking
strategies like PATHWORKS will ensure the efficient transfer of
files and documents from one system to another.
Vision of 1995
Information as food.
Standards.
The Accordian.
I14y
Business:
Information in the food chain. That which we build (in our case,
information products) will be used, consume, and integrated with other
products.
Other Vendors and Platforms<--------+
^ |
/ |
/ |
v |
+------------------+ |
v | v
Customer_Request-->Industry->Digital->NaC->Manufacturing->Customer+
^ |
| |
+--------------------------------------------------------------+
As a result we must deliver our products in industry standard formats.
Further, by recognizing that we are participants in the definition of
industry standards, we will move agressively to ensure that our
technical advances fit well into the present and evolution of the
industry (as we have done with Alpha, attempting to redefine the next
level of chip design). We can expect new video and animation standards,
new models for licensing, and (he dreams) ISDN to the doorstep.
The accordian will continue to work. There will be continuing efforts
to consolidate, via servers and resource managers, and to disperse, by
desktop horsepower, distributed, heterogenous systems, and
telecommuting.
s/w mgmt -------> Data Center/IS <---- data
choices <-----------------+----------------> displays
Interoperability. We want the ability to buy what we want, obtain the
benefits of having our unique solution, and have it work as though we
all running the same configurations.
Workplace:
The procedures and products of technical documentation will become even
more closely integrated with those of software engineering. The
principles and tools used to design software will have direct
applicability to the design of the information suite. Help-level
documentation will be generated from the software compiler or design
database. Whether this is done with Object-Oriented Programming Systems
depends on how well the market embraces that acronym for their
money-making ventures.
Alpha and Pentium will still be establishing themselves in the
commercial markets. (DOS outsold Dos/Windows 4:1 in the early 1990s.)
Mac will be a player. So will portable systems. The interoperability
will be handled by systems integrators pulling in big money and by
systems designs like Athena and Pilgrim.
I wish for, but do not expect, a file management/library management
system that can be distributed across the enterprise and integrated
with the authoring systems. No seems to want one badly enough yet.
I see the future organization using PCs that run MS-DOS, OSF/1, and
OpenVMS. Our environment will have a departmental standard ISL that contains:
o Interleaf
o MS-Word
o MS-PowerPoint
o MS-Excel
o Windows/NT operating system, too
o Writer's Toolkit: grammar checker, online references, indexing sfw
o Graphical Interface sfw
Our machines will be high powered PC desktops systems, within a LAN/WAN
environment.
Much of our future will depend on what needs our clients face, and what
tools we can effectively support. We'll need to draw a line at some point to
avoid becoming an "all-things-to-all-people" shop. However, flexibility within
the subgroups of our organization will help to keep us in line with our
specificclients' needs.
I also think that multimedia will be possible through our PCs. As I
spoke to you about a few weeks ago, the current multimedia task force would
do well to build a useful demo that we could show to potential clients in order
to win multimedia requests. In the future, these requests will be more
active as more and more clients and their customers get PCs.
Here is a quick snapshot of my view of the TNPUBS work environment in 1995.
I think it will be a PC-based network with applications (preferably
WYSIWYG or with an online viewing capability) that are widely used in
the industry. My reasoning is based on the fact that Digital is
likely to have more partnerships with other companies in the future.
We will not necessarily be doing all the documentation in-house and
we will have to deal with a lot of different tools that might produce
varying forms of printed output. However, I would think that everyone
would try to use the most prevalent tools and these apparently are on
the PC. This approach should cover small, as well as large, companies.
Depending on the size of the third-party companies that we will be
dealing with, they might not have the ability or resources to produce
multimedia and online information. If we continue to produce this
form of information, that will be an area where we can add value.
However, I think that the one of the most important things for us to
learn from our current situation (with the proliferation of tools) is
that it should be able to work together or be easily converted from
one form to another. Otherwise, our selection criteria will not be
worthwhile because the same situation will result.
TNPUBS Tools and Deliverables in 1995
I feel that the hybrid tools and applications available in 1995 will
result in a powerful combination of options for desktop publishing
houses. I see the PC world migrating toward, and merging with, the
workstation environment. This will create a publishing tool box
comprising current hardware, current and new software, and innovative
conversion applications, usable from both worlds.
Coupled with Digital's path toward Open Systems, these new hybrid
wares will evolve to fill the needs of publishing consumers ranging
from individuals to corporations. Digital will likely continue to
strive to initiate and improve online delivery of documentation.
Online warehouses containing PC, workstation, and third-party
applications will become available to network users. Writers will mix
and match them, using built-in, or external "application bridges," to
suit specific writing and delivery needs.
Among the current tools that Digital will be in using in 1995 are:
Interleaf (fine-tuned for high-efficiency)
VAXdocument (with Tag Suppression to verify format before printing)
Bookreader (with auto indexing and selective hot-spot listing)
Hyperhelp
Also available to Digital writers will be:
Converters that really work
Online, realtime EDMS proofing applications
Universal hot-spot applications to quickly tag any source
material for online delivery
Platform-independent writing aids to help with:
Grammar (any of the PC or WS applications)
Spelling
Style
Format
Word choice (online thesauras)
Search tools to find and list the location of material in
notes or VTX that is relative to specific products or
applications
Most of these writing aids will have on-the-fly capability for
efficient, instant-response, verification and correction during
document creation.
Work Environment
Homogeneous environment where there is optimum compatibility among writer
tools.
Writers, editors, illustrators, and production share common platforms.
Art department has the capability to deliver graphics directly to an
individual writer's desktop in a format readily usable by the writer.
Documents can be migrated directly between desktops.
Conversion tools are minimal if not nonexistent.
Bookreader or its equivalent accepts writer output directly with no inter-
mediate build step required.
Writers can output directly to online Help facilities.
Ultimate goal is to take input data in any form (hardcopy, online, voice(?))
and make it accessible from any writer's desktop.
Hardware Environment
Desktop machine should be Alpha- or Pentium-based workstation operating
at 100 MHz with 32 Mbyte RAM.
All T&N Pubs machines should be connected to a client-server Enet or token
ring network (preferably high speed - ~100 mbs).
Print servers, network servers, file servers should all exist as either
separate stand-alone devices or be installed on low-use machines to minimize
congestion problems.
Network storage should be RAID-based to minimize cost and maximize storage
potential.
One or more multimedia development workstations should be located within
the group. These workstations should include sound cards and CD-ROM drives
in order to benchmark competitor multimedia products, as well as develop
our own multimedia packages.
The art department should be using the same workstations used by writers.
Illustration tools should be compatible with writing tools.
Software Environment
Operating system should be Windows-NT in order to have access to the
widest possible array of development tools.
A strict screening program should exist to ensure that any tools brought
into the group can coexist and cooperate with existing software.
Basic DTP or WP package should be the tool of choice for all writers
to minimize or eliminate cross-desktop incompatibilities.
The selected writing tool should have hyper-help and online documentation
support built into it.
Grammar and spell checkers should be integrated into the basic writing
tool engine. These facilities should be customizable by the group.
A standard prototyping tool such as Visual Basic should be on everyone's
desktop.
Multimedia software should include sound and motion packages which would
allow us to develop animated presentations.
Ultimate Goal
The future of our group should rest on the ability to meet the diverse
documentation needs of any department in Digital. We should be capable of
delivering anything from online hypermedia, to animated multimedia
presentations, to traditional hardcopy documentation. Doing this requires
stat-of-the-art equipment and a complete rethinking of the way we
currently do business.
By 1995, writers at Digital will use Nwindows and PCs, and some of the other
desktop publishing tools that small software companies are now using.
If the user information that we produce is not project-driven, as was the
response during our meeting, then my guess is that we will produce more online
documentation than hardcopy, perhaps reversing the present percentage
(my estimate) of what users actually use 80% hardcopy, 20% online.
Digital is now in closer partnership with Apple, so we should also watch in
what directions Apple is moving. They are now using radio network
technology with Appletalk, an application that supports mobile clients who
want to connect to large internetworks. We may need to consider "voice"
documentation.
PLATFORMS
10% of us will be using Windows NT on an AXP-based DECpc
15% of us will be using Windows NT on an Intel-based PC
10% of us will be running MS Windows V4.x on an Intel-based PC
The above PCs will be on our Ethernet and they will be running
PATHWORKS for Windows NT and PATHWORKS for DOS.
10% of us will be using Windows NT terminals via an AXP-based Windows NT server.
35% of us will be using DECwindows/Motif on VXT workstations.
5% of us will be using X Windows terminals via our OpenVMS VAX cluster
5% of us will be using DECwindows/Motif on standalone (non-VXT) workstations.
5% of us will be using MACs connected to our network via PATHWORKS
5% of us will be using IBM OS/2 and other platforms connected to our
network via PATHOWORKS.
APPLICATIONS...
15% VAX DOCUMENT
40% DECwrite
30% Interleaf on OpenVMS
10% Interleaf on Windows NT
5% others (Powerpoint, Microsoft Word...)
From: TNPUBS::ROCH "10-Mar-1993 1436" 10-MAR-1993 15:18:26.77
To: @DESKTOP.LIS;
CC: ROCH
Subj: Desktop task force -- tomorrow's meeting postponed
Due to unforeseen changes in TaN Publications, it would seem best to postpone
tomorrow's task force meeting until next week (when things have settled
around here). Therefore:
Tomorrow's meeting at 1:00 is cancelled.
Next task force meeting: 18-Mar, Thursday
1:00 - 2:30
Room TBA
Thanks to all who submitted a requirements list, this information will be
combined for next week's meeting.
Matt
From: TNPUBS::ROCH "12-Mar-1993 1554" 12-MAR-1993 15:55:01.95
To: @DESKTOP.LIS;
CC: ROCH
Subj: Next Desktop Task Force meeting
Due to Microsoft training on the 18th, the next Desktop Migration task force
meeting will be held:
19-Mar, Friday
1:30 - 3:00
Nantucket CR (LKG2-1/T9)
An agenda will be distributed next week.
Note that after this meeting we will resume meeting at our regular time of
1:30 every other Thursday afternoon.
Thanks,
Matt
From: TNPUBS::ROCH "19-Mar-1993 1057" 19-MAR-1993 11:01:12.23
To: @DESKTOP.LIS;
CC: ROCH
Subj: Desktop task force - meeting reminder, today at 1:30 in Nantucket
A reminder that the Destop task force will meet this afternoon:
1:30 - 3:00
Nantucket CR, LKG2-1/T9
Agenda:
Review/finalize weighted General Requirements list
Define next steps for task force
From: KOALA::LITTLE "Art Little 19-Mar-1993 1104" 19-MAR-1993 11:16:54.16
To: TNPUBS::ROCH
CC: LITTLE
Subj: RE: Desktop task force - meeting reminder, today at 1:30 in Nantucket
Matt,
I've got to get a major deliverable to my Postmaster client today & I'm
playing catch-up from being out yesterday, so--as much as I want to be
there--I really can't break loose this afternoon. Sorry.
Once Jim Mac starts up here (a week from Monday), I'll only be supporting
one docset, so it should be normal-crazy rather than twisted-crazy & I'll
have more time for the important things in life. (Oh, I have to introduce
Jim to the group this afternoon also.)
BCNU,
-A-
From: TNPUBS::ROCH "26-Mar-1993 1413" 26-MAR-1993 14:37:48.03
To: @DESKTOP.LIS;
CC: ROCH
Subj: Next Desktop Migration Task Force meeting
Please mark your calendars for the next Desktop Task force meeting:
Thursday, 01-Apr
1:30 - 3:00
Fiedler CR (LKG1-3/G9)
Agenda for this meeting:
Elect a new chairperson
Define action plan/schedule
Minutes from the 18-Mar meeting will be distributed next week, prior to
Thursday's meeting.
Also note that the Fielder room will be the meeting site for the Desktop Task force
through the end of June (every other week). Please plan on attending meetings
from 1:30 - 3:00 in the Fiedler room on the following dates (all Thursdays).
April 01
April 15
April 29
May 13
May 27
June 10
June 24
From: TNPUBS::PBOCCELLI "There is absolutely no substitute for a genuine lack of preparation. 31-Mar-1993 1530" 31-MAR-1993 15:27:50.48
To: @DTMIG
CC: PBOCCELLI
Subj: Agenda Item for Tomorrow's Task Force Meeting
Hello,
With Matt Roch leaving T&N Pubs, we must elect a new chairperson for
our task force. Because I am the IPA team monitor as well as a task
force member, it is my responsibility to notify the core team when
the new chair is named. A key item on tomorrow's agenda should be the
naming of the new chairperson for this task force. This message is an
open request for team members willing to serve as the task force
chair. If you have the desire and time to lead this task force, please
consider volunteering for this position at tomorrow's meeting.
Our task force has as its primary goal the development of a migration
plan to provide T&N Pubs with industry leading technology by 1995.
Because of this ambitious goal, we have become a fairly visible task
force. As a result, the new chairperson must be willing to devote the
time and sweat necessary to making us successful. Matt did an
outstanding job and will be missed, but his leaving should not be a
show stopper for us. We have the talent within the task force to
successfully complete our mission with a minimum of disruption.
Please come to the meeting prepared to discuss this issue.
See you all tomorrow,
Paul
From: TNPUBS::PBOCCELLI "There is absolutely no substitute for a genuine lack of preparation. 01-Apr-1993 1105" 1-APR-1993 11:03:37.65
To: @DTMIG
CC:
Subj: Task Force Reminder
From: TNPUBS::ROCH 26-MAR-1993 14:41:46.74
To: @DESKTOP.LIS;
CC: ROCH
Subj: Next Desktop Migration Task Force meeting
Please mark your calendars for the next Desktop Task force meeting:
Thursday, 01-Apr
1:30 - 3:00
Fiedler CR (LKG1-3/G9)
Agenda for this meeting:
Elect a new chairperson
Define action plan/schedule
Minutes from the 18-Mar meeting will be distributed next week, prior to
Thursday's meeting.
Also note that the Fielder room will be the meeting site for the Desktop Task force
through the end of June (every other week). Please plan on attending meetings
from 1:30 - 3:00 in the Fiedler room on the following dates (all Thursdays).
April 01
April 15
April 29
May 13
May 27
June 10
June 24
From: TNPUBS::ROCH "01-Apr-1993 1210" 1-APR-1993 12:12:39.00
To: @DESKTOP.LIS;
CC: ROCH
Subj: Desktop task force - meeting reminder, updated General Requirements
A reminder that the Desktop Task force will meet this afternoon from 1:30-3:00
in the Fiedler conference room.
The following (after the form feed) is an updated list/definition of
General Requirements. This list reflects both the initial contributions of
task force members and a task force review meeting on 18-Mar.
Notes to General Requirements list:
- EDMS Postscript was removed as a general requirement, but was
added as an example of an Industry Standard.
- "Price/Cost Analysis" was changed to "Cost/Benefit."
"Network License" was changed to "Licensing."
"Ease-of-Use" was changed to "Performance/Usability."
"Reusable Format" was changed to "Information/Data Portability."
Open issues:
- Need input from Art department.
- Need to verify planned TaN deliverables with management team,
specifically the "Services Offered" brochure being coordinated
by Don Skarzenski.
- Where does "application (product) performance" (especially speed)
belong? The group agrees that it is an important general requirement,
but there are differing opinions on whether this should be a
requirement of its own, or part of another requirement (Usability,
Interoperability?).
As of this date, this requirement is noted under the definition for
Performance/Usability.
01-Apr-1993
WEIGHTED GENERAL REQUIREMENTS
------------ ------------------------------
Requirement/ Average Weighted Score (1-10)
Definition (7 respondents)
------------ ------------------------------
Interoperability 9.2
How well does the application work with the existing or planned
environment? Consider immediate workgroup and overall organization
(TaN Pubs). Does the planned configuration support all of the
required platforms/protocols?
Performance/Usability 8.2
The application/process is easy to learn, intuitive, minimum
ramp-up, acceptable system performance (speed, resources).
Consider documentation and online help/tutorials.
Support/Training 7.0
Support: Is there a clearly defined and worthwhile support channel?
Consider availability of product support 800 numbers, user groups,
and internal/external templates/tools. Training: Is there an
identifiable training resource (internal/external)? Consider
product training such as tutorials.
Industry Standard 6.8
An industry standard is software, hardware or an architecture
to which vendors adhere because of its widespread customer base
or because of its real or perceived quality. Specific standards
may include Alpha, Motif, EDMS Postscript, Motif, or MS Windows.
Cost/Benefit 6.3
The relative cost of acquiring and implementing an
application and the potential benefits to the TaN Pubs
organization (including ROI and maximum user productivity).
Information/Data Reusability 5.3
Does the application offer/allow reuse of information from a
variety of inputs to a variety of outputs as determined by
business requirements?
Distributed Processing 5.0
Does the application fit into a distributed processing model?
(Defined here as: The ability to spread the processing load
over multiple systems to ensure wide/efficient use of resources.)
Licensing 4.2
What type of license(s) does the application provide (single-user,
concurrent, network, site)? What is the cost per license?
Is the licensing scheme adaptable to business needs?
From: TNPUBS::ROCH 2-APR-1993 10:56:54.28
To: KOALA::LITTLE
CC: ROCH
Subj: Desktop task force - proposal
From: TNPUBS::ROCH 4-FEB-1993 11:45:23.48
To: @DESKTOP.LIS;
CC: ROCH
Subj: Desktop Migration Task Force: Proposal and next meeting
Attached is our task force proposal as submitted to the IPA.
Our next meeting will be:
2:00 - 3:30
Monday, 08-Feb
Frost conference room (LKG1-2/G9)
If you were not at the last meeting, the following proposal may indicate a
change in focus. The majority of those in attendance at the last meeting agreed
on this direction for the task force. However, there is still interest in an
IPA task force that addresses current tools and training, especially Interleaf.
If you are interested in forming a second, separate task force that addresses
current tools, please contact Charlie Terrasi (TNPUBS::TERRASI).
Thanks,
Matt
IPA TASK FORCE PROPOSAL
04-Feb-1993
Submitted by:
Matt Roch
Task Force Topic:
Desktop Migration Strategy
Task Force Purpose:
Develop a strategy for efficiently and successfully migrating TNPUBS
personnel to desktop systems (including networked applications and PCs).
This strategy would be created in conjunction with the Tools
(Production) department.
Potential benefits to TNPUBS include reduced implementation time,
problems, and costs; increased worker productivity; and a wider range
of services offered to customers (through use of industry-standard
applications). An added benefit is increased participation of
individual contributors in organizational strategies.
Proposed approach:
Develop a Desktop Migration Specification that includes:
- Work systems model
- Recommended work systems, inclu
|
| Here's a draft of the Summary paper....
Task Force Summary
This paper summarizes the research undertaken by the IPA's
Desktop Migration Task Force. Original task force members
included:
Elena Aschkenaski
Paul Boccelli
Denny Dixon
Bill Dubie
Karl Hakkarainen
Mark Kimball
Betty Lew
Art Little
Owen O'Neil
Matt Roch (Chair)
Janice Sahagian
Mick Schonhut
Dave Sciuto
Mike Woizeiko
Because of several organizational and personnel changes, the
composition of the task force changed noticeably over the past
year. The task force chair itself went from Matt Roch to Art
Little to Bill Dubie.
The following task-force members contributed to this paper:
Paul Boccelli
Bill Dubie
Karl Hakkarainen
Betty Lew
Dave Sciuto
All task-force members contributed to Appendix A, "Personal
Visions," and Appendix B, "General Weighted Requirements."
I. Problem Statement (Why We Were)
The original objectives of the Desktop Migration Task Force were,
as Matt Roch stated in his proposal, to "(d)evelop a strategy for
efficiently and successfully migrating T&N Pubs personnel to
desktop systems (including networked applications and PCs)." We
envisioned the benefits, as Matt noted, to include "reduced
implementation time, problems, and costs; increased worker
productivity; and a wider range of services offered to customers
(through the use of industry-standard applications)." Another
benefit was increased participation of individual contributors in
organizational strategies.
These goals illustrated the tend toward the desktop in
documentation circles, along with the popularity of PC-based
applications in the marketplace. The market and industry
themselves had seemed to embrace these technologies, so we saw
the formation of this task force as a vehicle to familiarize T&N
Publications with these predominant market tools.
Typifying the trend towards these new technologies, the
publications department acquired, over the past six months, these
desktop systems and applications that, eventually, appeared to
embody the strategy that this task force was developing; however,
the rapid acquisition and adaptation of this new technology
nearly negated the need for the task force itself. The realities
were outpacing the goals and visions that task-force members had
originated, though a pilot implementation and a demo had been
planned.
Clearly, the hardware configurations in our publications group
symbolized the quick growth of the desktop strategy, as well as
Digital's own stake in the market. Because of this, the task
force decided to modify its goals and to produce this summary
report as an exercise in the vision of T&N Pubs writers, editors,
and artists, and to document the rapid progress of these systems
in our publications group.
What We Did
Note 12.x in the IPA_REGISTRY VAX Notes conference contains
detailed descriptions and minutes of the activities of this task
force; essentially, the role each member had was to help generate
a common strategy of migration to desktop systems for all members
of T&N Pubs. We did this by, first, discussing and developing a
Weighted General Requirements list (see Appendix B), then creating a
second list of potential applications, including operating
environments. We then matched what deliverables might be created
using these implementations, as shown in Table 1.
In creating Table 1 (abstracted from the minutes), we considered
our current tools situation and positioned our potential
applications against what T&N Pubs was using. We developed core
requirements to coincide with these potential applications.
Table 1. Potential Applications
Include apps. here.
Action Item
With these lists in guides, each task-force member devised a
personal vision of what the future desktop environment might
resemble in 1995; those remarks appear in Appendix A.
List of Requirements
Rules
There were two fundamental rules in the planning process:
1.
The software solutions must meet the customers' needs.
2.
The resulting configuration must be manageable.
Historically, planning in the technical publications world at
Digital has been hardware driven. ("We have a VAX. Now, what
software can we use on it?") With the loosening of purchasing
rules for both hardware and software, we have seen a dramatic
shift in the types of computing solutions available in the
publications business.
First of all, there's been a recognition that there are multiple
businesses. We have technical documentation as the mainstay of
the business. In addition, however, are marketing materials
(information sheets, press releases, slide presentations, and the
like), course materials, multimedia presentations, and other
promotional materials. Each is similar, but all have unique
requirements for software and hardware features. VAX Document did
not meet the requirements of all of the businesses. Neither,
however, would Aldus Pagemaker.
So, we concluded that a common core of tools, available to all,
would be the basis of the tool selection criteria. Then, each
business would define (and continue to define) its unique
additional requirements. Aldus Pagemaker would become a standard
part of the marketing writers' toolkit, while Interleaf and
related tools would be the basis for technical documentation
writers.
The maintainability and support requirements would be met mostly
through planning. Applications, wherever appropriate, would be
installed on servers or installed via Initial System Load (ISL)
to ensure that each system was consistent and secure.
Interoperability of tools (what version of Pagemaker works with
which version of Powerpoint) would be ensured by small-scale
testing prior to major upgrades.
During the term of the task force, we learned of a fundamental
change in the production requirements for our business. Support
for Bookreader was discontinued by Engineering. The selection of
WorldView as the preferred online information delivery tool. led
to new agreement between Interleaf and Digital regarding the use
of Interleaf 5/6, WorldView Press, and WorldView viewer.
Suddenly, MS Word became a practical option for high-volume,
online information delivery on Digital platforms.
How We Adapted--Open
The task force declared victory and closed up.
B. Results of the Adaptation--Open
2. Matching Resources to Needs--Client Needs--Open
Software Research Checklist
Identifying the need
Is there a sufficient need within the organization for the software?
Will the software help to improve productivity in the organization?
Will the software be accessible to the people in the organization
who need it?
Doing the Research
Literature Searches
Library searches: limit searches to 18 months back.
Product information cards: send them in
Create a product function matrix
Word of Mouth
Which product in its class is used most often?
What functions are most important to the users of this class
of software?
What functions are most important for users of this class
of software?
On the Market
What's currently available in this class of software?
What do salespeople say about the software in this class?
What sells? What doesn't sell? Are updates free, low-cost?
What do the reviews say?
Testing the Software
Test Drives
Check stores that are running the software
Find out who sells the software and ask for a test drive
Getting Demos and Evaluation Copies
Call companies, ask for evaluation copies or demos
Be prepared to send back evaluations
Use standard tests for all products
Weighing the Results
Function Matrixes
Build a list of function criteria for selection process
Include both technical and business considerations
Technical Considerations
Portability of product and output
Technical Support
Business Considerations
Cost vs productivity gains
License or individual copies
Introducing New Technologies and Software Products to the Organization
Identifying the Business Need
At a time when the company was downsizing its workforce due to
slumping sales and a poor economy, the Telecommunications and
Networks Publications (T&N Pubs) organization began looking at
ways that it could continue to provide high quality documentation
with fewer resources. We had been asked by our new CEO and
president to "work smarter" and "do more with less." Being an
organization of high achievers, we were poised to look beyond our
current technology to tools in the industry that would help to
maintain our high level of productivity.
III. Change in the Milieu
With the advent of Don Skarzenski's Marketing Communications group, our
task force began to feel increasing pressure as to just what our
deliverables would be. The MarCom group was introducing new software and
hardware into the pubs group at a frantic pace. Here we were planning
a migration strategy for the 94-95 timeframe, and the MarCom group was
already integrating PCs and sophisticated software into the pubs group.
They were stealing our thunder without our even being aware of it.
At this time, we began to rethink our deliverables. As weeks went by,
it became increasingly apparent that we were slowly being pushed into
irrelevancy. With this new group defining de facto standards based on
its real world needs, we no longer had an agenda.
A. How We Adapted
With the impetus from MarCom, task force members began to question
our reason to be. Several meetings were held to discuss our future.
Out of these meetings came the decision to rethink our goals and
reevaluate the task force, with the idea that our usefulness had come
to an end. With these issues in mind, the team decided that anything we
had to say would be rendered moot by actions occurring within the
publications group. Actions that were way beyond our control, and on
which we could have very little impact.
After much churning, we decided to dissolve the team. There did not
seem to be much point in generating a migration strategy that would be
DOA. The team, however, did not want to discard months of meetings,
research, and writing without having something to show for our efforts.
B. Results of the Adaptation
Realizing that we probably would not have much impact on the decisions
being made within the group, we decided to take the sum total of our
efforts and turn it into a final report. This document would be a record
of our efforts to develop a useable migration strategy. We put this
document together in the hopes that there may be some relevant
information to be gleaned by members of the pubs group who have a vested
interested in developing a coherent and logical scheme for migrating
the publications group to the desktop environment of the future.
IV. The Evolving Standards
As a result of the rapid changes that occurred in our tools
environment, our standards had to adapt to meet these new
challenges. This section of the paper provides details about our
current tools environment and the different configurations that
are provided to meet our business needs. It describes the
standards that were used to create our current environment and
how those standards might be used in determining future
environments.
List of Tools--Configurations
We have no standard PC configuration. Rather, we have a mix of
software and hardware platforms with a variety of different
applications. This list does not provide a complete accounting of
all software available to T&N Pubs users; the list changes daily.
Rather, it provides a description of the base configurations for
the types of PCs currently in use.
The two major platforms we support currently are as follows:
DECpc 433 (Tower and Workstation variety)
Hardware characteristics
w
Intel 486 33Mhz CPU
w
24+MB Memory
w
80MB IDE hard disk (Workstations)
w
170-450MB IDE hard disk (Towers)
w
14-16" VGA Color Monitor
w
1.44MB Floppy disk drive
Operating system and networking software
w
MS-DOS V5.0
w
MS-Windows V3.1
w
PATHWORKS for DOS V4.1
Base Application Set
w
Microsoft Office (V4)
-
Excel
-
PowerPoint
-
Word
w
PageMaker V5.0 and misc. applications on some machines
DECpc 466
Hardware characteristics
w
Intel 486 66Mhz CPU
w
24MB memory
w
245MB IDE hard disk
w
14-19" VGA color monitor
w
1.44MB floppy disk drive
w
Integral CD-ROM drive (2 mini towers)
Operating system and networking software
w
MS-DOS V6.0
w
MS-Windows V3.1
w
PATHWORKS for DOS V4.1
Base Application Set
w
Microsoft Office (V4)
-
Excel
-
PowerPoint
-
Word
w
PageMaker V5.0 and misc applications on some machines
DEC 320p Laptops
Hardware characteristics
w
Tandy 20Mhz CPU
w
8 MB memory
w
60- or 80-MB hard disk.
w
LCD monitor with VGA color output optional
w
1.44-MB floppy disk drive
Operating system and networking software
w
MS-DOS V5.0
w
MS Windows 3.0 or 3.1
w
One or two of the MS Office Products (typically Word and Excel).
w
Kermit
w
PATHWORKS for DOS V4.1
Appendix A Personal Visions
The strategy for 1995 appears to be migrating toward a primarily
MS-DOS environment. This not only aligns our productivity tools
with the rest of the industry, but it also provides a more
efficient way of transferring files with third-party partners.
Working in such as standardized environment could help improve
contributors' productivity, given the wealth of applications and
tools readily available.
I suspect that graphics tools for the DOS world will also compete
aggressively with Macintosh tools; witness the recent release of
Quark Express for the PC, a variation of a well-established
desktop-publishing tool for the Mac.
As processors improve, the distinction between workstations and
desktop systems steadily blurs. The promise of Alpha and even the
Pentium processor from Intel demonstrates that low-end systems
are gaining on workstations in processing power and capability.
The probable set up will include a high-end PC for each
contributor who needs to produce and edit documentation. Software
should consist of customized versions of commercial software,
such as MS-Word for Windows, Grammatik, and PageMaker. Graphics
packages should also figure heavily in these
applications--Harvard Graphics comes quickly to mind. Networking
strategies like PATHWORKS will ensure the efficient transfer of
files and documents from one system to another.
Vision of 1995
Information as food.
Standards.
The Accordian.
I14y
Business:
Information in the food chain. That which we build (in our case,
information products) will be used, consume, and integrated with other
products.
Other Vendors and Platforms<--------+
^ |
/ |
/ |
v |
+------------------+ |
v | v
Customer_Request-->Industry->Digital->NaC->Manufacturing->Customer+
^ |
| |
+--------------------------------------------------------------+
As a result we must deliver our products in industry standard formats.
Further, by recognizing that we are participants in the definition of
industry standards, we will move agressively to ensure that our
technical advances fit well into the present and evolution of the
industry (as we have done with Alpha, attempting to redefine the next
level of chip design). We can expect new video and animation standards,
new models for licensing, and (he dreams) ISDN to the doorstep.
The accordian will continue to work. There will be continuing efforts
to consolidate, via servers and resource managers, and to disperse, by
desktop horsepower, distributed, heterogenous systems, and
telecommuting.
s/w mgmt -------> Data Center/IS <---- data
choices <-----------------+----------------> displays
Interoperability. We want the ability to buy what we want, obtain the
benefits of having our unique solution, and have it work as though we
all running the same configurations.
Workplace:
The procedures and products of technical documentation will become even
more closely integrated with those of software engineering. The
principles and tools used to design software will have direct
applicability to the design of the information suite. Help-level
documentation will be generated from the software compiler or design
database. Whether this is done with Object-Oriented Programming Systems
depends on how well the market embraces that acronym for their
money-making ventures.
Alpha and Pentium will still be establishing themselves in the
commercial markets. (DOS outsold Dos/Windows 4:1 in the early 1990s.)
Mac will be a player. So will portable systems. The interoperability
will be handled by systems integrators pulling in big money and by
systems designs like Athena and Pilgrim.
I wish for, but do not expect, a file management/library management
system that can be distributed across the enterprise and integrated
with the authoring systems. No seems to want one badly enough yet.
I see the future organization using PCs that run MS-DOS, OSF/1, and
OpenVMS. Our environment will have a departmental standard ISL that contains:
o Interleaf
o MS-Word
o MS-PowerPoint
o MS-Excel
o Windows/NT operating system, too
o Writer's Toolkit: grammar checker, online references, indexing sfw
o Graphical Interface sfw
Our machines will be high powered PC desktops systems, within a LAN/WAN
environment.
Much of our future will depend on what needs our clients face,
and what tools we can effectively support. We'll need to draw a
line at some point to avoid becoming an
"all-things-to-all-people" shop. However, flexibility within the
subgroups of our organization will help to keep us in line with
our specificclients' needs.
I also think that multimedia will be possible through our PCs. As
I spoke to you about a few weeks ago, the current multimedia task
force would do well to build a useful demo that we could show to
potential clients in order to win multimedia requests. In the
future, these requests will be more active as more and more
clients and their customers get PCs.
Here is a quick snapshot of my view of the TNPUBS work
environment in 1995.
I think it will be a PC-based network with applications
(preferably WYSIWYG or with an online viewing capability) that
are widely used in the industry. My reasoning is based on the
fact that Digital is likely to have more partnerships with other
companies in the future.
We will not necessarily be doing all the documentation in-house
and we will have to deal with a lot of different tools that might
produce varying forms of printed output. However, I would think
that everyone would try to use the most prevalent tools and these
apparently are on the PC. This approach should cover small, as
well as large, companies.
Depending on the size of the third-party companies that we will
be dealing with, they might not have the ability or resources to
produce multimedia and online information. If we continue to
produce this form of information, that will be an area where we
can add value.
However, I think that the one of the most important things for us
to learn from our current situation (with the proliferation of
tools) is that it should be able to work together or be easily
converted from one form to another. Otherwise, our selection
criteria will not be worthwhile because the same situation will
result.
TNPUBS Tools and Deliverables in 1995
I feel that the hybrid tools and applications available in 1995
will result in a powerful combination of options for desktop
publishing houses. I see the PC world migrating toward, and
merging with, the workstation environment. This will create a
publishing tool box comprising current hardware, current and new
software, and innovative conversion applications, usable from
both worlds.
Coupled with Digital's path toward Open Systems, these new hybrid
wares will evolve to fill the needs of publishing consumers
ranging from individuals to corporations. Digital will likely
continue to strive to initiate and improve online delivery of
documentation.
Online warehouses containing PC, workstation, and third-party
applications will become available to network users. Writers
will mix and match them, using built-in, or external "application
bridges," to suit specific writing and delivery needs.
Among the current tools that Digital will be in using in 1995
are:
Interleaf (fine-tuned for high-efficiency)
VAXdocument (with Tag Suppression to verify format before printing)
Bookreader (with auto indexing and selective hot-spot listing)
Hyperhelp
Also available to Digital writers will be:
Converters that really work
Online, realtime EDMS proofing applications
Universal hot-spot applications to quickly tag any source
material for online delivery
Platform-independent writing aids to help with:
Grammar (any of the PC or WS applications)
Spelling
Style
Format
Word choice (online thesauras)
Search tools to find and list the location of material in
notes or VTX that is relative to specific products or
applications
Most of these writing aids will have on-the-fly capability for
efficient, instant-response, verification and correction during
document creation.
Work Environment
Homogeneous environment where there is optimum compatibility among writer
tools.
Writers, editors, illustrators, and production share common platforms.
Art department has the capability to deliver graphics directly to an
individual writer's desktop in a format readily usable by the writer.
Documents can be migrated directly between desktops.
Conversion tools are minimal if not nonexistent.
Bookreader or its equivalent accepts writer output directly with no inter-
mediate build step required.
Writers can output directly to online Help facilities.
Ultimate goal is to take input data in any form (hardcopy, online, voice(?))
and make it accessible from any writer's desktop.
Hardware Environment
Desktop machine should be Alpha- or Pentium-based workstation operating
at 100 MHz with 32 Mbyte RAM.
All T&N Pubs machines should be connected to a client-server Enet or token
ring network (preferably high speed - ~100 mbs).
Print servers, network servers, file servers should all exist as either
separate stand-alone devices or be installed on low-use machines to minimize
congestion problems.
Network storage should be RAID-based to minimize cost and maximize storage
potential.
One or more multimedia development workstations should be located within
the group. These workstations should include sound cards and CD-ROM drives
in order to benchmark competitor multimedia products, as well as develop
our own multimedia packages.
The art department should be using the same workstations used by writers.
Illustration tools should be compatible with writing tools.
Software Environment
Operating system should be Windows-NT in order to have access to the
widest possible array of development tools.
A strict screening program should exist to ensure that any tools brought
into the group can coexist and cooperate with existing software.
Basic DTP or WP package should be the tool of choice for all writers
to minimize or eliminate cross-desktop incompatibilities.
The selected writing tool should have hyper-help and online documentation
support built into it.
Grammar and spell checkers should be integrated into the basic writing
tool engine. These facilities should be customizable by the group.
A standard prototyping tool such as Visual Basic should be on everyone's
desktop.
Multimedia software should include sound and motion packages which would
allow us to develop animated presentations.
Ultimate Goal
The future of our group should rest on the ability to meet the diverse
documentation needs of any department in Digital. We should be capable of
delivering anything from online hypermedia, to animated multimedia
presentations, to traditional hardcopy documentation. Doing this requires
stat-of-the-art equipment and a complete rethinking of the way we
currently do business.
By 1995, writers at Digital will use Nwindows and PCs, and some
of the other desktop publishing tools that small software
companies are now using.
If the user information that we produce is not project-driven, as
was the response during our meeting, then my guess is that we
will produce more online documentation than hardcopy, perhaps
reversing the present percentage (my estimate) of what users
actually use 80% hardcopy, 20% online.
Digital is now in closer partnership with Apple, so we should
also watch in what directions Apple is moving. They are now using
radio network technology with Appletalk, an application that
supports mobile clients who want to connect to large
internetworks. We may need to consider "voice" documentation.
PLATFORMS
10% of us will be using Windows NT on an AXP-based DECpc
15% of us will be using Windows NT on an Intel-based PC
10% of us will be running MS Windows V4.x on an Intel-based PC
The above PCs will be on our Ethernet and they will be running
PATHWORKS for Windows NT and PATHWORKS for DOS.
10% of us will be using Windows NT terminals via an AXP-based Windows NT server.
35% of us will be using DECwindows/Motif on VXT workstations.
5% of us will be using X Windows terminals via our OpenVMS VAX cluster
5% of us will be using DECwindows/Motif on standalone (non-VXT) workstations.
5% of us will be using MACs connected to our network via PATHWORKS
5% of us will be using IBM OS/2 and other platforms connected to our
network via PATHWORKS.
APPLICATIONS...
15% VAX DOCUMENT
40% DECwrite
30% Interleaf on OpenVMS
10% Interleaf on Windows NT
5% others (PowerPoint, Microsoft Word...)
Appendix B Weighted General Requirements
01-Apr-1993
WEIGHTED GENERAL REQUIREMENTS
------------ ------------------------------
Requirement/ Average Weighted Score (1-10)
Definition (7 respondents)
------------ ------------------------------
Interoperability 9.2
How well does the application work with the existing or planned
environment? Consider immediate workgroup and overall organization
(TaN Pubs). Does the planned configuration support all of the
required platforms/protocols?
Performance/Usability 8.2
The application/process is easy to learn, intuitive, minimum
ramp-up, acceptable system performance (speed, resources).
Consider documentation and online help/tutorials.
Support/Training 7.0
Support: Is there a clearly defined and worthwhile support channel?
Consider availability of product support 800 numbers, user groups,
and internal/external templates/tools. Training: Is there an
identifiable training resource (internal/external)? Consider
product training such as tutorials.
Industry Standard 6.8
An industry standard is software, hardware or an architecture
to which vendors adhere because of its widespread customer base
or because of its real or perceived quality. Specific standards
may include Alpha, Motif, EDMS Postscript, Motif, or MS Windows.
Cost/Benefit 6.3
The relative cost of acquiring and implementing an
application and the potential benefits to the TaN Pubs
organization (including ROI and maximum user productivity).
Information/Data Reusability 5.3
Does the application offer/allow reuse of information from a
variety of inputs to a variety of outputs as determined by
business requirements?
Distributed Processing 5.0
Does the application fit into a distributed processing model?
(Defined here as: The ability to spread the processing load
over multiple systems to ensure wide/efficient use of resources.)
Licensing 4.2
What type of license(s) does the application provide (single-user,
concurrent, network, site)? What is the cost per license?
Is the licensing scheme adaptable to business needs?
Appendix C Grammatik Research
GRAMMATIK RESEARCH
Summary
This paper describes the customization of the grammar checker
Grammatik V for Windows 3.1 for use with documents produced using
VAX DOCUMENT, a text-editing/formatting application from Digital
Equipment Corporation.
Introduction
The migration of desktop systems to office and academic
environments brings with it attendant questions and problems. One
of these problems has been how to allow personal-computer
applications to reside and work with documents produced on a
workstation platform. In the Telecommunications and Networks
Publications Group of Digital Equipment Corporation in Littleton,
Mass. (U.S.A.), we faced such a challenge, namely, how to
customize and use over-the-counter grammar-checking software with
documents that had embedded formatting codes.
We chose as our grammar-checking software Grammatik V from
Reference Software: It was cost-effective, easily learned, and
the company provided a review copy for our testing purposes. Our
main intention was to verify whether, if at all, Grammatik would
be a useful tool to check grammar and usage on documents produced
using VAX DOCUMENT, a text-editing/formatting application from
Digital Equipment Corporation.
VAX DOCUMENT has long been used in our organization; therefore,
we sought an easy transition from workstation systems using the
VMS Operating System to desktop personal computers using a
combination of MS-DOS (Windows) applications with PATHWORKS and
other networking utilities. The code produced by VAX DOCUMENT is
Standard Digital Markup Language (SDML), not unlike Standard
General Markup Language (SGML), which is rapidly gaining
popularity.
The document, then, is by no means WYSIWIG, and is difficult to
read in its raw form. Using templates, the writer formats the
coded document to produce a readable, finished product. The
advantages are that the writer does not worry about formatting,
as long as the document is correctly coded. The text then becomes
a technical manual, information sheet, catalog, or cover letter,
according to the template. Also, as this is a
technical-publications group, VAX DOCUMENT affords a consistency
across product lines, ensuring a recognizable documentation set.
The disadvantages are that the writer has much difficulty
proofing the coded copy before formatting. If the writer spots an
error, he or she must go back to the source document, incorporate
the change, then format the document again, mostly at a cost of
time and effort. The document must pass through an editor's hand
as well, after formatting. Listing 1 provides a sample of a coded
technical document:
Listing 1: Sample SDML Coded Document
<COMMENT>(Use CLETTER doctype to process thru DOCUMENT)
<DEC_LOGO>
<head>(HUBwatch<footnote>(TM\HUBwatch is a trademark of Digital Equipment
Corporation.)
for ULTRIX<footnote>(TM\ULTRIX is a trademark of Digital
Equipment Corporation.) Software Version 1.1)
<ordernum>(AV-PXYXA-TE)
<p>
Dear Customer,
<p>
The HUBwatch for ULTRIX, Version 1.1, software product
is a network management application used to manage Digital hubs on
extended local area networks. The product features
a graphic user interface (GUI) based on Motif<footnote>(R\Motif
is a registered trademark of the Open Software Foundation, Inc.) windows.
<p>
The HUBwatch GUI has the following features:
<list>(unnumbered)
<le>Two views of the Hub front panel, physical view and logical view, that
show the modules installed and their operating status
<le>Management windows that display real-time information
about each module installed in the Hub and enable modification,
or management, of module operating characteristics
<le>Online, Motif windows help that describes each management window
and the associated management tasks
<endlist>
<p>
Refer to the HUBwatch for ULTRIX, Version 1.1, Software Product
Description (SPD 40.64.00.A) for a more description of this product.
<subhead1>(HUBwatch Release Notes)
<p>
After performing the installation,
read the release notes located in /usr/kits/HUBwatch/hubwatch.release_notes.
<p>
The release notes include important information about the HUBwatch software
that was not included in the <emphasis>(HUBwatch Installation and Use) manual
or online help.
<subhead1>(HUBwatch Installation Procedure)
<note>
If you are installing HUBwatch software to manage DECagent 90 and
DECbridge 90 modules that you purchased before the release of
HUBwatch software Version 1.1, ensure that these
modules are upgraded to the latest firmware levels.
You cannot use HUBwatch software Version 1.1 to manage the
DECagent 90 and DECbridge 90 modules unless they have the latest
firmware. If you need firmware kits for these modules, contact
your Digital sales office.
<endnote>
<p>
To install the HUBwatch software,
follow the instructions in the
<emphasis>(HUBwatch Installation and Use) manual. This manual
is included with the media in the software distribution kit.
<COPYRIGHT_STATEMENT>(March 1993)
Personal Computers and the Workstation Environment
In April 1992, when we saw that personal computers were becoming
more prevalent in our industry and organization, we also saw the
potential dilemma between old and new technologies. Commercial
software like Grammatik offered another documentation-production
tool, but could it work with an SDML document produced on the VMS
operating system? To its advantage, DOCUMENT produced ASCII text,
albeit nearly unreadable in its coded form, and Grammatik used
ASCII as one of the word-processing formats. We knew that
Grammatik could be customized to overlook certain verbal
configurations--much like the coded tags VAX DOCUMENT produced.
We then began to formulate a group within the organization to
investigate whether Grammatik would be a useful application for
our mixed environment.
Another question was the statistical data Grammatik supplied as
part of its output. We suspected that the various readability
levels Grammatik provided would be skewed by the tags that
appeared in text, if we somehow neglected to have Grammatik
overlook them. Usability studies aside, we looked to Grammatik
not to be an arbiter of readability, in this case, but to provide
another text-editing utility that would help us produce our
documentation more efficiently.
This was a notable concern for writers and editors, who believed
that Grammatik would be the measuring tool of competence and
would provide the data that would appear in performance reviews.
In our subsequent training sessions, we stressed that this would
not be the case, as this Grammatik project was designed only to
help writers and editors produce cleaner documents. They would
use Grammatik as they would any other utility. (Spelling
checkers, we gathered, faced the same opposition when they were
first used.)
Customizing Libraries
To begin this task, we established a schedule to ensure that we
met regularly. We experimented with various coding techniques in
Grammatik, and used feedback from writers and editors who
volunteered their time to help us modify Grammatik's library. We
should stress here that it was the collaborative nature of the
volunteers in our department that enabled us to produce this
tool. Through trial and error we incorporated the many tags and
codes of VAX DOCUMENT; clearly, this text-editing program was not
intended to be used with a grammar-checking utility. However, we
managed to produce a workable, beta library that allowed us to
further test SDML documents.
Following this phase, our next objective was to bring this tool
to the attention of the various writing groups within our
organization; typically, these groups were devoted to specific
projects, which enabled writers and editors to work on singular
documents and documentation sets. We arranged to present our
customized Grammatik library to these groups' individual staff
meetings, where we were met with many questions--and a few
misgivings--about this tool.
We developed presentations with tutorials to demonstrate the
method (and obstacles) of checking the grammar and style of a
specific document produced using SDML. Editors could customize a
Grammatik library for their projects, incorporating style guides
and word lists that contained unique or unusual spellings of
projects. Writers could run their documents through Grammatik
before delivering them to editing, allowing editors to review
other areas; this way, the deliverable would be made in time for
first revenue ship.
We stressed that using Grammatik was purely voluntary, both
because the availability of personal computers at the time
(autumn 1992) was very limited, and because the learning curve
associated with it, especially for writers accustomed to using
workstations and networked operating systems, could inhibit a
document's delivery date. At the time, a writer or editor had to
download an SDML document to diskette, bring it to an available
personal computer, then run Grammatik on the document. This was
an unwieldy method that left many questions concerning hardware
distribution, especially if the only available personal computer
were in another writer's office.
With the distribution of personal computers, however, this
problem has lessened; also, the growing use of other
word-processing software, especially Microsoft Word for Windows
2.0, has provided other avenues for grammar-checking utilities,
like the one built into Word. We have made Grammatik available
for those users who have personal computers and who still use VAX
DOCUMENT to produce their technical documentation.
Introducing New Technologies and Software Products to the
Organization
Identifying the Business Need
At a time when the company was downsizing its workforce due to
slumping sales and a poor economy, the Telecommunications and
Networks Publications (T&N Pubs) organization began looking at
ways that it could continue to provide high quality documentation
with fewer resources. We had been asked by our new CEO and
president to "work smarter" and "do more with less." Being an
organization of high achievers, we were poised to look beyond our
current technology to tools in the industry that would help to
maintain our high level of productivity.
T&N Pubs, like most of Digital, used tools that ran on
host-terminal technology. This configuration limited the
organization to a few complex and expensive electronic publishing
tools. Among the applications of which the organization boasted
was Interleaf. In terms of electronic publishing on a large LAN,
and in response to meeting our clients demands for large, complex
documentation sets, Interleaf was the publication tool of choice.
However, even with its sophistication, Interleaf had its
drawback. For the majority of clients, accessibility to the
source document was not a concern; however, as the organization
began to grow and develop new client relationships, demands for
a variety of client-accessible publishing tools grew, too.
Additionally, as T&N Pubs expanded its business to nontechnical
communications, such as business and marketing communications,
Interleaf did not provide the flexibility and functionality to
successfully do the job. If we were to succeed as an
entrepreneurial business, we needed the tools of one.
Given conditions, such as a dwindling workforce and diversifying
client-base, we began looking to PCs for their easy-of-use, and
wide portability and flexibility. Both OpenVMS and Interleaf
ported to OpenVMS had very much locked us into propriety
applications and formats. The organization had spent much time
and money on developing conversion tools to increase the
flexibility of the tools, but development was slow and the
outcome was inconsistent and technically complex for the writer.
On the other hand, PCs offered a wide-range of compatibility
among various formats and several tools and applications designed
to tackle a wide-variety of demands from a diverse client-base.
Additionally, since many of our clients, and some our the
writers in the organization, had PCs either in their offices, or
at their homes, source files could be read and edited literally
anywhere.
Doing the Research
Given management's approval to bring in software products that
would help maintain and even increase productivity, we proceeded.
Since the downsizing had caused the organization to experience
widening gaps in the ratio of editors to writers, we targeted
productivity gains in the area of editing. Our goal, it must be
stated, was not to replace our editors with software, but to
augment their skills with tools that would accomplish the
rudimentary issues of grammar, spelling, and word choice. Thus,
we hoped to enable the writer to "edit" their own documentation
before handing the draft to the editor. In turn, the editor
would be able to concentrate on more high-level editorial issues,
such as documentation uniformity across documentation sets.
The outcome of this targeting exercise led us to investigate
grammar checkers for the PC. We began the research with some
understanding of the popular packages available. Prior to the
research, we had attended a technical communications conference
where the topic of grammar checkers as productivity tools for the
writer was presented. We gathered up the hand-outs, reviewed
them, got in touch with the presenter of the seminar, and invited
her to attend a management meeting with T&N Pubs. She was asked
to speak on her finding of grammar checkers as productivity
tools. Based on her research, which remained somewhat
inconclusive due to large gaps in functionality needed in these
programs, we started our research in the Digital library, doing
literature searches of technical journals and magazines, as well
as PC trade magazines. The literature search, although limited
to the last 18 months, produced about 100 articles on several
grammar checkers. After reviewing a good deal of the articles,
we chose five grammar checker applications based on DOS-base
compatibility and positive reviews in the magazines.
The next step required that we organize the information into a
matrix of product name and functionality. The functionality was
based in part on T&N Pubs' requirements for grammar checkers and
on standard functionality used as a criteria for product
evaluations by several reviewers. Among the important
functionality was number of flags to false hits (how often the
checker flags an problem, and how many of those flagged problems
are inaccurate hits) and compatibility to various word processing
formats. Since VMS and Interleaf were highly proprietary
products, we needed to identify grammar checkers that could work
on ASCII files.
Whenever a magazine or journal contained ads for grammar
checkers, we pursued the company's information by sending out the
attached "bingo cards" for more information. The literature sent
to us proved valuable not only for its more complete descriptions
of the products' functionality, but also for its listings of
direct contacts, such as retailers and the company itself.
Testing the Software
Our research took us out of the library and into stores that sold
the selected products. We had called several stores that
primarily or exclusively sold computer products, introduced
ourselves, and asked if they would set up demos of grammar
checkers for us. Most were unable to comply to our request,
since many companies do not supply the retailers with demo
copies. However, those who happened to have products running on
PCs in the stores were happy to help us.
What proved much more valuable was contacting the companies
themselves, stating our purpose, and asking for evaluation copies
for testing. In calling the five major producers of grammar
checker software, three sent us full evaluation copies, and did
not require that we either return or pay for the copies. One
company sent us a demo of the product, showing its functionality.
One was unable to send us an evaluation copy and did not have a
demo to distribute.
All evaluation copies were installed on a PC notebook since the
organization had a few standalone PCs within writers' offices.
We determined that the notebook would be easily setup in an
office, conference room, or home where testing and usage
observations could be done. We used a standard technical
document to ensure conformity across product evaluations.
Additionally, we ran the grammar checker on documentation that
had already been released or was in progress. A formal pilot was
organized and members of the organization from apprentice writer
to consultant writer were chosen to participate. The
writer-volunteers were invited to use the grammar checkers on
their own documentation in their offices. We observed both the
results of the grammar checking through the document, as well as
the users' interactions with the product and its results.
Weighing the Results
At the conclusion of the pilot, which ran for about two to three
weeks, we made a presentation to T&N Pubs management. The
presentation focused on the chronology of the research method,
the outcome of the research and pilot, and recommendations. The
recommendations took into consideration our physical environment
(lack of PCs currently in the organization), licensing issues for
networking the application, the cost of buying the product and
maintaining it, and its accuracy in identifying problems and
offering corrective information. We anticipated some resistance
from the writer and editor population, due mostly to their lack
of experience with PCs or their products. Some saw the
encroachment of PCs on their business as an insult to the
complexity of their tasks; others regarded the introduction of an
automated process to perform a human task as a threat to their
position in the organization. Still others thought that the
statistical information generated by the checker would be a basis
for future performance reviews. Management saw the tools as
productivity boosters for the organization and foresaw a time
when PCs and client/sever technology would replace the current
host-initiated technology common in Digital at the time.
Grammatik by Reference Software was recommended for its ability
to provide the best in all our criteria mentioned throughout this
paper. Implementation proved to be difficult, however, because
of a lack of PCs. We chose to set up "PC Suites" throughout the
organization. These were offices that were set up with a PC or
two on which Grammatik was loaded. Users were asked to either
pull their ASCII formatted text over the network using PATHWORKS,
or to bring a diskette containing their ASCII file to the PC.
Research and further development, such as customizing the grammar
checker to look for specific T&N Pubs conventions, continued to
ensure that we had chosen the best product for our needs and that
we could maintain and improve its usefulness in our organization.
|