TechWhirl (TECHWR-L) is a resource for technical writing and technical communications professionals of all experience levels and in all industries to share their experiences and acquire information.
For two decades, technical communicators have turned to TechWhirl to ask and answer questions about the always-changing world of technical communications, such as tools, skills, career paths, methodologies, and emerging industries. The TechWhirl Archives and magazine, created for, by and about technical writers, offer a wealth of knowledge to everyone with an interest in any aspect of technical communications.
Has anyone here encountered a situation like this one? I haven't, and I
can't find anything directly comparable in the archives. War stories,
comments, opinions, all appreciated. If you prefer to respond directly to
me I'll summarise for the list.
***************
We're currently involved in setting up a mid-sized intranet site in support
of a very large IT project for a government department. The site will
consist of the usual project bumpf (status reports, schedules, meeting
minutes, etc.) and a large number of project deliverables (reports,
analyses, and the like) that need to be published for the various project
stakeholders to read and/or comment upon. The vast majority, if not all, of
the information to be published is static. For example, once created and
approved, the project charter will never change. Drafts of project
deliverables will be published (in their original document formats such as
Word and then either downloaded or viewed through the browser) and, when new
drafts appear, they'll simply replace the previous versions. At this point I
can see no need for dynamic content, meaning content that appears as the
result of the user selecting options and getting customized information as a
result. There is a need to publish most or all of the content in a second
language.
Most pages will be written, coded, and never touched again. The biggest
changes, on an ongoing basis, will be to things like the page listing
available project status reports. As a new status report is produced, a link
to the status report will be added to the top of the list of status reports.
Ditto on things like meeting minutes. Pages referring to project
deliverables may need to be maintained in order to change the link(s) to the
most current version(s) of the deliverables plus changes to the document
abstract. Aside from this, there should be no need for heavy-duty
maintenance. Concurrent users might number, at most, 30 people, with average
use being perhaps a dozen or so.
There is a difference of opinion between myself and the other person doing
the requirements definition about how best to publish this information. As a
minimalist, I believe the easiest approach is to manually code the Web pages
using something like, say, Dreamweaver. The "technology" is well known and,
given the chronic shortfall of personnel support within such projects, a
decent techwriter can serve dual duty by maintaining the Web pages using
Dreamweaver as well as generating/editing content. Moreover, under this
approach, the translators would simply get a copy of the HTML pages needing
translation. They would bring them into an HTML authoring tool of their
choice and produce the translated pages by, essentially, overtyping the
English, thus maintaining tags and formatting.
The other person--a programmer by trade--is adamant that the best solution
is to go with a database publishing approach. A page would be produced in
Dreamweaver, cut 'n pasted into a Microsoft Access (ugh!) database, and then
served dynamically out of the database when it was needed. The project
deliverables would be treated similarly. This person is also touting the
"advantages" of being able to give the Access DB to the translation company,
who would create another "column" and do two-up translation. In his view,
this is simplest for the translation company and this would also enable him
to use a simple language selector key somewhere and pull whichever language
is needed out of the same DB.
I see problems with this:
-- Performance hits. Multi-user and Access are generally not terms used in
the same sentence.
-- Added steps and complexity. Another technology layer (Access) and extra
steps (cut 'n paste into the Access DB)
-- Translation. Translation companies that I've dealt with will get an
Access DB file and likely go "What the *%&^ is THIS?!"
-- Maintenance. If the Access DB works as advertised and there's never a
problem, then there's never a maintenance issue. OTOH, if ever an Access
problem does appear, then a programmer may likely need to be called in to
perform the remedial stuff. Similarly, I suspect--but don't know--that there
will be some level of DB maintenance needed to keep the thing running at its
peak.
Despite these issues, I'm open to being convinced that this approach is
better than my minimalist approach. So...anyone care to weigh in with their
experience and comments?
Thanks!
Sandra Charker
+++++++++++++
"There are only two ways to live your life. One is as though nothing is a
miracle. The other is as though everything is a miracle." - Albert Einstein
.... and you can live both ways at once. - Sandra Charker
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Check out the new release of RoboDemo, our easy-to-use tutorial software.
Plus, buy RoboHelp Office in August and save $100 with our mail-in rebate.
Get details and download free trial versions at http://www.ehelp.com/techwr-l
---
You are currently subscribed to techwr-l as:
archive -at- raycomm -dot- com
To unsubscribe send a blank email to leave-techwr-l-obscured -at- lists -dot- raycomm -dot- com
Send administrative questions to ejray -at- raycomm -dot- com -dot- Visit http://www.raycomm.com/techwhirl/ for more resources and info.
