From Functional Testing > Swim collected widget html as batch tests ran and presented them in compact and browsable swim-lane diagrams suitable for understanding long-running, multi-participant transactions, notably Eclipse new-committer elections. pdf
CUNNINGHAM, Ward, [no date]. The “Swim” System for User-Oriented Presentation of Test-Case Results. pdf > # Conclusion > […] we've focused on supporting conversations: conversations between developers, conversations between developers and sysadmins; conversations between developers and users; and even conversations between users and other users.
See Conversations
> Second, we've worked at, and visualized, the right level of abstraction. Our abstractions are simple enough to understand because we don't talk in computer terms such as "database updates", "ajax form posts", or "user1"; instead we use the user's vocabulary, show the user's interface panels, and use the names of real people and roles in our simulations. At the same time, our abstractions are detailed enough to be believed because we are running the real code in our simulations instead of bubbles and arrows diagrams. We respect the user's expertise without dumbing down our system or forcing them to use our terminology.