Trading Manager

Table of contents
  1. The Problem 
  2. The Users 
  3. Example Mock-ups 
  4. Example Screen Flow

The Problem 

RedSeal Solutions needed to provide a rich Web based interface to allow users to maintain their Business to Business Trading Management data. This included the need to maintain an arbitrarily large number of Trading Partners and associated agreements, Communities and Protocols.  Additionally, the Trading Manager needed to provide access to administrative task such as defining users and access roles.

The first version of the Trading Manager would be geared towards an Administrative user who had no access restrictions.  Future versions would include views of the data to support a 'self serve' model.  In the self serve model a user would only be able to update information for the Trading Partner that they where associated with.  Additionally a user in 'self serve' mode would only be able to view the  Trading Partners / Communities that they had an agreement with. 

The look and feel needed to be able to be consistent with widgets that would be able to be implemented using GWT-Ext.  

The most difficult part of designing a Trading Manager is providing support for complex Protocols such as AS2,  X12, ebXML and HIPAA.  The screens had to allow a user to quickly define the flow of information from one Trading Partner to another.  The same screen needed to support concepts such as batching messages for delivery and selecting an associated protocol  used to deliver the data (example: delivering an X12 message using AS2).

Actors where defined. Mock-ups where created as well as screen flows.  All deliverables where both reviewed by domain experts in Business to Business and customers.

 ^ top

The Users 

This is a summary of the actors we identified.  The real actors had names and much more detailed descriptions.
Responsible for a portion of the Trading Manager. This user maintains the portion of the Trading Manager for which they are responsible including associated runtime task. 

Administrator users include:

  • Suite Administrator
    Responsible for the entire Trading Manager. Maintains everything.

  • Trading Partner Administrator
    Responsible for a specific Trading Partner and that Trading Partner's agreements.  Also maintains protocols used by the Trading Partner. 

  • Community Administrator
    Maintains the communities, companies and departments by defining the users associated with them.

EDI Administrator
Responsible for a portion of the Trading Manager. This user maintains a portion of the Trading Manager but does not configure any information associated with runtime task.

EDI Administrator users include:
  • EDI Administrator
  • Trading Partner EDI Administrator
  • Community EDI Administrator
  • Protocol EDI Administrator

Looks at the bottom line of a business.  Needs to examine Trading Manager entities but does not want to maintain them. 

Executive users include:
  • Executive
  • Trading Partner Executive
  • Community Executive

Suite Tuner
Cares about making the system performant.  Configures runtime information such as Protocols, Databases and Plug-ins.

Trading Partner
A specific entity that participates in an agreement.   Trading Partners send and receive Business to Business messages using specific Protocols.

 ^ top

Example Mock-ups 

Note: The following are taken from the RedSeal Solutions Walkthrough .   I would like to thank RedSeal Solutions for permission to show the screens as a part of my portfolio.  RedSeal Solutions maintains all rights to these designs as indicated by the copywriter statement on the images of the slides.

The Trading Partners shown are the user's favorite Trading Partners.  This allows a user to select from a large list of Trading Partners and easily find the information they are looking for.

Coming up with a screen for the Agreements was the most interesting design problem.  For the most part it was expected that users would work from templates.  However, the GUI needed to be able to support creating complex Transactions from the GUI.  To easy the set up needed users can copy a properties from a section of the properties.  This allows a user to copy common settings like FTP settings for each Transaction.  

Another way to create an Agreement is to use a Wizard.  The following shows steps 3 and 4 of the Wizard.

Notice that the help text was also included to show the style and wording of the help for each step.

Stop 4 of 4 of the Create Agreement Wizard.  Reuse makes the configuration easy.

 ^ top

Example Screen Flow

The following show part of the Screen Flow diagrams created as part of the deliverable.  Icons from the mock-ups where used to indicate the functions selected by the user.

 ^ top