[Sigia-l] Elements of Documentation

[Donna Marie Fritzsche]

Yep, it definitely points to the multi-disciplinarian aspect of the 
whole process.  In the previous days of the client-server world, this 
step probably would have been done by a computer programmer (at least 
in the trading world, which is my main experience with transactional 
systems.)

Which also brings another interesting question that I know has been 
mentioned here, but I am woefully behind on my list reading - which 
is the difference in requirements between transactional vs 
informational systems.

Having a dominant content strategy component in an informational 
system makes a great deal of sense, but in a transactional system, it 
seems that the user experience or business goals would come to the 
forefront. The content would almost become a subset of the business 
goals and/or database requirements.  Actually, the task-strategy 
might be the dominant design force.  (I have been rereading old 
postings, and I appreciate that one of the Peter's keeps bringing us 
back to the importance of "User Task".)  So for instance, in a mostly 
transactional system, I would suggest that we could say:

The User Task Specification says "we need a dynamic messaging catalog 
and page-level message component for all sorts of messages."  Of 
course, this is an idea that I just had based on my first cup of 
coffee.

Thanks for the detailed explanation, in  my experience, the type of 
steps you outlined are often neglected until very late in the 
process, yet it can shape the user's experience as much as any other 
component of the system.

   Donna





At 7:55 AM -0400 6/29/02, Patrick Hunt wrote:
>I think you are both right. Content Strategy says "we need a dynamic
>messaging catalog and page-level message component for all sorts of
>messages." Information Architecture says "in that case, we have 4 message
>categories (e.g., error, exception, instructional and informational), each
>of these has a certain number of sub-categories (field format error, field
>value error, required field, etc.)." Content Development says "you want all
>those messages when?" (But as in most cases, as Jesse suggests, there is
>much overlap between IA responsibilities and those of other participants.)
>
>So the IA deliverable in this scenario is not unlike a content
>inventory/matrix. The message catalog takes the form of a table, whether in
>simple format such as ThinkFree Calc or a more complex format like a MySQL
>data source (ultimately, it needs to be easily imported into the developer
>solution for integration purposes). Fields in a basic message catalog might
>include category, sub-category, description, message text, page ID
>(multiple), date and time stamps for creation/modification, author, etc.
>


--