Business to Business (B2B) Dashboard
Table of contents
The Problem
^ top
Sun's existing Business to Business application message tracking did not have a way to visualize messages. Additionally, most of our customers had expressed a desire to mine the message for business and Trading Partner data.From customers we learned that they needed a dashboard that they could easily extend with their own screens. The customers expected that the application would ship with some dashboards for their typical users.
The Users
^ top
- Business users
-
- Dollars and cents — cut waste and increase profits.
- Who is costing us more/less and why?
Uses computers a lot, but is not expected to be an expert user or programmer. Wants to get results quickly.
- Operations users
-
- Make sure the end-to-end system is up and running correctly.
- View alerts about something that was expected to happen but did not. For example, "Purchase order 99587 has not finished processing"
A more expert user who also trouble shoots why the problems occurred. Needs to be able to drill-down to see causes of errors in the system.
- Business-to-business centric users
-
- Track transaction status for standard messages.
- Drill down to lowest level of a message and show:
- The Message Hierarchy.
- Errors and Warnings in messages.
- The actual data sent.
- Resubmit messages back to the system after correcting errors.
Expected to have a deep knowledge of B2B messages and be comfortable with the raw message format. These customers are used to using computers but may not be computer experts.
Example Mock-ups
^ top
Operations View
User can drill down from a graph to the messages that generated that graph.
User clicks on errors portion of bar to see list of errors processed at 1:00 am. Because the user was on the Operations View tab the user also sees a list of tasks.
Transaction View
Displays a message as sent / received by a Trading Partner.The example used in the mock-up was of an AS2 message that contains an X12 message. This example was selected because it represents the most complex case that the application was expected to deal with.
Here the user has selected an 850 Purchase Order where the data was semantically wrong but the record was able to be processed. The messages and Acknowledgements (Acks) that flow through the system are clearly shown. Tool tips (not shown here) make sure that color is not the only distinction between normal messages and Acks.
Users could select portions of a message to view a "dialog". The dialog shows the records that flow from one Trading Partner to another as a result of a record being sent / received. In the below example, an 850 was sent to Trading Partner 2. Trading Partner 2 sent back both a 997 (Ack) and an 855. When Trading Partner 1 received the 855, Trading Partner 1 sent back its own 997 (Ack).
Here the user has selected an ISA record.
The Paginated Tree (© 2009 All rights reserved) for complex messages
One of the most interesting problems that had to be solved was to design a way to show a complex message where each section of the message could have thousands of children.The system had to stay responsive to the user so showing all the nodes at once would not be practical.
After doing research and not finding a paginated tree I came up with the following design.
- Nodes show which repetition of the node is being shown.
- Users can expand / collapse a node and use a paginated control to see children.
- Users can switch to a view where each of the repetitions are also shown.
Showing all repetitions of the GS segment.
Note: If you are interested in implementing the paginated tree please contact me at Andrea.Kendall.job@gmail.com.
More Information
^ top
See my Journeys in Design blog.<Back