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.
Before you go too far, I would suggest considering a different
database than Access. There are a number of free ones that have much
cleaner facilities for moving to other database engines should you
need to do so later.
In addition, if your database becomes very large, you may run into
capacity and performance issues with Access.
All of which said, I would also suggest considering a CMS (content
management system) with a database at its heart. Since these are
designed as textual storage and retrieval engines, you may find them
much friendlier for your users to deal with.
Using a relational database for document storage and retrieval can get
fairly ugly...with a CMS running on top of it, the whole thing becomes
much more manageable.
David
On Mon, 17 Jan 2005 10:44:41 -0500, Stevenson, Rebecca
<Rebecca -dot- Stevenson -at- workscape -dot- com> wrote:
>
> I mentioned a while back that I was reading Practical Software
> Requirements. It's turned out to be very helpful to my current project,
> so I thought public props were in order.
>
> It all started when the team on my project decided that the document I
> was working on would be more useful as a database. Pending any funding
> to get people who know what they're doing to build this, I've been
> drafted to implement something in Access (which I'd never used before,
> and my Visual Basic has gone untouched for five years). At a meeting
> last week in which "requirements" appeared fast and furiously, none of
> them things people had thought to ask for back when this was going to be
> a text document and most of them conflations of behavior and UI design,
> I decided that if I'm going to do this I will at least try to have
> proper requirements (and a spec!), to forestall any "but we wanted it to
> do something else" discussions later on.
>
> I'm about one third of the way into my problem domain description and
> already uncovering things I hadn't thought about. This is a new kind of
> document for me, and it's proving rather fun.
>
> Rebecca Stevenson
> Technical Publications | Document Development
> Workscape, Inc.
> PH: x3059 AIM: RJSWriter
WEBWORKS FINALDRAFT - EDIT AND REVIEW, REDEFINED
Accelerate the document lifecycle with full online discussions and unique feedback-management capabilities. Unlimited, efficient reviews for Word
and FrameMaker authors. Live, online demo: http://www.webworks.com/techwr-l
Technical Communication Certificate online - Malaspina-University College, Canada. Online training in technical writing, software (FrameMaker, RoboHelp, Dreamweaver, Acrobat), document & web design, writing manuals, job search. www.pr.mala.bc.ca/tech_comm.htm for details.
---
You are currently subscribed to techwr-l as:
archiver -at- techwr-l -dot- com
To unsubscribe send a blank email to leave-techwr-l-obscured -at- lists -dot- techwr-l -dot- com
Send administrative questions to lisa -at- techwr-l -dot- com -dot- Visit http://www.techwr-l.com/techwhirl/ for more resources and info.
