Re: Delivery formats for big complicated information?

[technical -at- theverbalist -dot- com]

> This suggests you need to both add 
> the new information to your existing structure and find out what other 
> information is missing. Talk to the users, and while you're at it, ask 
> them what usability problems they encounter.

Ah, my user-buddy is the best. He's totally into identifying what the
document needs and roping other users into helping us out. Si I'm getting
good user input about what the doc needs and how our users us it out in
the wilds.
 
> One presentation approach that sometimes works very well indeed when 
> you have lots of data is what I call a "baseball card". 

Ah, great minds...for the last release we tablized all the info in the doc
which really showed where there was inconsistencies in what we provided,
and where info was missing. We now have a beautiful "baseball card" for
every transaction, with links to the objects that the transactions use and
return...got it, got it, need it, got it...
> 
> <<One of the users suggested putting the document into an Access 
> database, in order to accomplish being able to search for an element in
> a transaction, and then on other transactions that use that element.>>
> 

> That's potentially a really bad solution, for a variety of reasons. 
> First, someone has to develop the database application and troubleshoot
> it to ensure that the underlying logic is bulletproof. 

This would be one of my biggest concerns--unless we have a really good and
comprehensive plan for putting the info in there, we're going to have all
sorts of nonsence coming out.

> Second, you have 
> to ensure that every user has Access installed on their computer (not 
> likely); Third, you have to ensure that everyone knows how to use Access (even > more unlikely);

Those requirements are actually not too hard to meet--we have a fairly
small number of users (I'm working on an abstruse, big ticket software
app) most of whom are in our Professional Services Group. My user buddy (I
LURVE him) is a lead in PSG, so he can round people up and make sure they
have Access and know how to use it.

> Fourth, if you distribute a database, 
> how are you going to protect the integrity of its data? (It can be 
> done, but you have to plan for this.)

That's a good point that I hadn't considered--if a users messes up the
data in the database, how will they know it's messed. Hmmm...
> 
> There's nothing inherently wrong with this, provided that all the other
> developers agree. No point catering to the needs of a single user and 
> alienating all the others, right?

Yes,exactly. I'm into 'cause it sounds like fun, but since we'd still need
to produce PDFs for the Developers Guide and the other big transaction
doc, I want to make sure that a web format provides usability that a PDf
doesn't. I'm still in the gathering user requirements stage on that
project--it's all still very fuzzy right now...

Thanks for your ideas--I've got more to go on now,
Mandy

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

ROBOHELP X5: Featuring Word 2003 support, Content Management, Multi-Author
support, PDF and XML support and much more!
TRY IT TODAY at http://www.macromedia.com/go/techwrl

WEBWORKS FINALDRAFT: New! Document review system for Word and FrameMaker
authors. Automatic browser-based drafts with unlimited reviewers. Full
online discussions -- no Web server needed! http://www.webworks.com/techwr-l 

---
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- raycomm -dot- com
Send administrative questions to ejray -at- raycomm -dot- com -dot-  Visit
http://www.raycomm.com/techwhirl/ for more resources and info.