[Sigia-l] Elements of Documentation

[Patrick Hunt]

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.

I've used message catalogs in previous instances, but the real value came in
a recent web application development project. We were able to significantly
streamline the experience and development using this approach. A simple
transaction process required the input form, field format validation,
business validation, user verification and confirmation. Originally, these
were modeled by the development team as four different screens (field format
validation was the only instance that didn't render a different page).

As an alternative, we created one form page that included a message
component with field format validation pre-cached. User enters data and
clicks submit, and javascript validation displays any field format errors in
the message component while highlighting which fields contain the errors.
User corrects errors and clicks submit, field formats pass validation, hits
the database and returns business errors. The same page is displayed with a
different error message from the catalog and the appropriate fields
highlighted. User corrects data, clicks submit, passes field and business
validation. Same page is rendered again, this time with a message in the
message component asking user to verify that they really want to take this
action and giving them the opportunity to change it. User clicks verify,
message component displays confirmation message in one of several page
options (same page with same data, giving user ability to change if needed;
same page with empty field values; same page with values of next item in
series; or another page). In all of these instances, the message component
would display both the confirmation message and an instructional or
informational message ("Congrats! You successfully submitted that data.
Here's the next one you need to deal with.")

In our case, IA collaborated with design to determine the presentation
characteristics of the messages as well.

 
>> . In addition to typical error messaging, such a system can be
>>> tied to personalization, upsell/cross-sell, etc. The IA would
>> conceivably be
>>>  involved, at a minimum, in determining message types and identifying pages
>>>  that require messages.
>> 
>> Sounds to me like you need content experts, not an IA. That's not to say
>> that someone couldn't be both, of course, but what you're describing is
>> really a matter of content strategy and content requirements, not
>> architecture.
>> 
> 
> Actually if you read the last line on his description, I think it is totally
> in keeping with what IAs who involve themselves in user interaction
> and experience should be addressing. I also think its a great step
> towards something many of us talk a bit about which is creating
> tailored/personalized messaging and experiences. I would be curious
> to see an example of what he is talking about. Patrick, please
> elaborate, I like your suggestion.