On Server site
Keying in the ‘ws’ command, as in Figure 9, in the application directory would launch the server_core program. A server message flow window then pops up and will stay when the server is on. The server message flow window (Figure 10) allows the server administrator to monitor the incoming messages.
Figure 9. Command needed to start a WhiteboardTalk server program
Figure 10. Server message flow window
On the Client site
Step 1: Under the application directory, key in the "wc" command to launch the client core program as shown in Figure 11. The client
core program will then start a registration window as shown in Figures 12 and 13 to ask the new user to register his name with the WhiteboardTalk server. The user name registered can be any name as long as there is no-one with the same name already registered. The registered name will be held for the user when he is online. When the user logs off, the name he registered with will be erased from the server. The user can register a different name when he logs on next time. After the user completes the registration process, the client core program will start a core window as shown in Figure 14. The core window will be on the user’s screen throughout the time when he is online.
Figure 11. Launching the client core program.
Figure 12. The WhiteboardTalk registration window.
Figure 13. Selecting a login ID for the session.
Figure 14. The WhiteboardTalk core window.
Step 2: From the client core window, the user can pull down the menu from the run selection and choose either New Connection or the Quit option as shown in Figure 15. When the Quit option is selected, the WhiteboardTalk program will terminate. All interfaces generated by it will also be closed. If the user chooses the New Connection option, a Connect window will pop up to ask the user the name of the remote user whom he would like to invite to communicate with(Figure 16).
Figure 15. The run selection menu.
Step 3: After the user fills in the name of the remote user he wants to talk with and clicks the Connect button, as shown in Figures 16 and 17, the request for connection message is sent to the server. The server will check its client name list to see if remote user is online. If the user is online, the server will pass on the message to the remote user. When the remote user’s core program receives the request message, it will pop up a calling card to tell the remote user who is calling him (Figure 18). If the remote client decides to accept the invitation, an "agree" message is sent back to the original caller
directly, without going through the WhiteboardTalk server. After the remote user accepts the invitation, Whiteboard interfaces pop up for both of them to talk. If the invitation is rejected, the "refuse" message will be sent to the original caller through the WhiteboardTalk server.
Doing it this way avoids the remote client being able to detect the user’s address. In the case that the target client is not online, the WhiteboardTalk server simply sends a ‘target not online’ message back to the caller.
Figure 16. The Connection window.
Figure 17. Entering the request.
Figure 18. Receiving the invitation.
Step 4: After the connection has been created, users are able to talk to each other by drawing on their Whiteboard interfaces (Figure 19). It is worth noting that the settings on the Whiteboard interface are defined by the local user. For example, the color chosen by one user in the meeting will not affect the color settings on a remote user’s Whiteboard interface. The remote user still uses their own original color settings in drawings. Each user can only change the color of the drawings presented on his own. As shown in Figure 19, we can see that user p3 uses black for this drawing while p1 uses red color for drawing.
The color used by the remote user is not affected when the local user changes his color setting. The mark ‘p1+p3’ on the top of the frame shows that two users, p1 and p3, are participating in the group discussion. This feature, which lists the names of the participants on the top of the Whiteboard, is especially useful in identifying who is participating in the meeting. This is especially useful for situations when the local user has more than one online meeting running at once.
Figure 19. Exchanging messages via WhiteboardTalk, as seen by user P1.
Figure 20. Drawing displayed on the Whiteboard of user p3.
Step 5: By clicking on the invite button on the Whiteboard interface (Figure 20), a user can invite other people to join the group meeting. The Whiteboard interface application will launch a Group Invitation frame (Figure 21) that is similar to the Connect frame shown earlier. After the remote user’s logon name is supplied, the user can select the invite button on the Whiteboard screen to continue the invitation process or the cancel button to stop the invitation. If the user chooses the cancel button, the invitation frame simply disappears and everything returns to the previous stage as if nothing had ever happened. If the user chooses to continue the invitation process, the invitation message will be sent to the server. The server will check its logon list to find the invited user’s location, assuming they are online at the time and the invitation message is then passed to the remote user.
The core application on the remote user site will launch a calling card to notify the remote user that there is a group invitation (Figure 22).
The remote user can choose to refuse to talk or accept the invitation.
The refuse message will be sent back to the original caller by the help of server. Once the remote user decides to accept the invitation, information including the remote user’s Whiteboard’s listening port number and internet address will be sent to everyone in the communication group to notify them that he is entering the group. All members in the meeting group then update their group list so they can exchange data with the new member. Figure 23 shows that the new user, p2, is added to the group. Figures 24 to 28 show that the newcomer can only read information posted after he joins the meeting, while other members can still read all the messages. Privacy for old group members can thus be protected. For example, the decision to invite a new member may be reached by old members in the course of discussion directly on their Whiteboards. It would not be good for group morale to let the new member know who disagreed with inviting
him into the discussion.
Figure 21. The group invitation screen.
Figure 22. The group invitation calling card presents on user p2's screen.
Figure 23. Adding new user p2 to the group.
Figure 24. Whiteboard display seen by p1 before p2 joining the group.
Figure 25. Whiteboard display seen by p3 before p2 joining the group.
Figure 26. Whiteboard display seen by p1 and p3 after p2 joining the group.
Figure 27. Whiteboard display seen by p2 at the same time as the previous Figure.
Figure 28. Leaving the meeting.
Step 6: To leave the group meeting, a user only has to click on the disconnect button as shown in Figure 28. The Whiteboard session in which the user decides to leave can be terminated while other Whiteboard processes belong to this user are still running. A message will be sent to the other participants in the group meeting. A notification card (Figure 29) will be shown on all participants’ screens to let them know that a specific user has left. Other participants can also identify which member has left by checking on the member names of those remaining in the meeting on the top of the Whiteboard, as shown in Figures 30 and 31.
Figure 29. Notifying the group that a member has left.
Figure 30. The Whiteboard screen seen by p1, showing p3 has left the meeting.
Figure 31. The Whiteboard screen seen by p2, showing p3 has left the meeting.