|
|
SharedShell:
A shared terminal for collaborative system administration
Network Communities Report
June 1999
John C. Tang, Nicole Yankelovich, and James "Bo" Begole
Introduction
SharedShell is a terminal program that enables multiple users to
interact together even though they may be separated by geographic
distance and network firewalls. It is designed in response to
observing how customer support engineers or system administrators
engage in diagnosing and resolving software problems on remote
computers. In the context of Sun's Customer Care Centers (CCCs),
SharedShell can be used to provide support engineers shared access to
a customer's computer so that they can work together while talking
over the telephone to resolve problems on the customer's computer. We
will use this context of enabling a support engineer to access a
customer's computer to describe how SharedShell works.
SharedShell replicates a terminal window of one computer onto other
computers which may be in another company (and thus on the other side
of one or more network firewalls). For example, if a Sun support
engineer is trying to resolve a software problem on a customer's
computer over the telephone, they can start a SharedShell conference
between them. SharedShell enables the support engineer to see what is
happening on the customer's computer, point to items in the terminal
window, draw in the window, and even enter commands if the customer
permits. 
Two areas of concern had a strong influence on the design of the
SharedShell interface:
- access security -- giving the customer confidence and control over the kind
of access that
can be made to the user's computer through the company's firewall.
- ease of use -- making the interface easy to use, even for the first time
user.
We will work through this support engineer scenario in more detail to
explain the main features of SharedShell, and show how we addressed
these issues.
Starting a SharedShell Conference
Typically, a customer calls the technical support telephone number and
starts describing the problem he's experiencing to a support engineer.
Resolving the problem frequently involves having the support engineer
dictate arcane UNIX commands to the customer, and having the customer
read back output from those commands. Sometimes the user is in a
noisy server room, or language accents may be involved that add
confusion to the communication. SharedShell is designed as a tool
that can be quickly started in the context of a support call to help
the support engineer and customer collaborate on solving a problem on
the customer's computer.
Even if a customer has never run SharedShell before, he can quickly
and easily start a SharedShell conference. The support engineer is
able to direct the customer to a web page that downloads and starts
the SharedShell application. Upon starting SharedShell, the following
window and dialog appear on the customer's screen:
Since the customer is allowing access to his computer, he must
initiate a SharedShell conference by inviting other people to share
his terminal window. When the SharedShell application starts, a
Conference dialog appears with the "Invite" tabbed pane selected. The
customer may make any desired changes to the Name field (the
SharedShell application tries to automatically detect the user's first
name). Then he must select the appropriate access permission setting,
choosing among the following three options:
- View -- allow remote users to see terminal contents
- Type -- allow remote users to enter, but not execute
commands (the customer must press carriage return to execute the command)
- Execute -- allow remote users to enter and execute commands
Once the customer has made his selections and clicks on "Invite", the
Conference dialog is replaced with the Conference ID dialog:
The customer must now read the Conference ID displayed in the dialog
aloud to everyone else on the phone. This ID, which helps to ensure
that the SharedShell connection remains secure and private, is only
valid while this dialog box is open (if accidentally left open, the
Conference ID times out after several minutes). In this scenario,
when the support engineer on the phone enters the conference ID into
the interface, the Conference ID window is updated to indicate the
users that have joined the conference:
Once the customer detects that support engineer has joined and that
there are no unauthorized intruders, he clicks on the "OK" button.
All participants in the conference now see a SharedShell terminal
window (described later).
Working through the scenario on the support engineer's side, she
launches a SharedShell or uses an existing SharedShell to bring up a
Conference dialog. To connect to the terminal window on the
customer's computer, the support engineer clicks on the "Join" tab in
the Conference dialog:
The support engineer can select what color she wants to use for her
telepointer and drawing. At this point, she waits for the customer to
read aloud the Conference ID. She enters this number into the
"Conference ID" field and clicks on "Join". The Conference dialog
disappears and once the customer confirms that the support engineer is
the right person to join the conference, he starts the conference.
One alternative that SharedShell offers for starting a conference is
if the customer wants to work in the terminal before inviting anyone
to join a conference. For example, if he is experiencing an
intermittent problem, he might want to first get the problem to occur
and then call Sun technical support. To do this, after starting
SharedShell, the customer would cancel the Conference dialog. At this
point, SharedShell becomes active and able to execute UNIX commands,
but is not connected with any other remote users. In this active but
unconnected mode, SharedShell behaves like an ordinary, single-user
terminal window..
Once the customer can re-create the problem, he can call the support
engineer and invite her to join a SharedShell conference. When the
support engineer joins, she can see the history of commands that the
customer executed when he was working on the problem in single-user
mode. This allows them to collaboratively review the commands that
were executed before the conference was started.
Collaborating in a SharedShell Conference
Once connected to other users, the SharedShell window looks like this:
A few changes indicate to the participants that the terminal is now
shared. In the terminal window itself, a message appears that
indicates the time of the connection, the list of participants (in
their appropriate colors), and the access permission setting for the
conference. Throughout the conference, messages like this one will be
printed in the terminal window when:
- A new participant joins the conference.
- A participant leaves the conference.
- Access permissions are changed.
- A user changes his or her color.
- A shell is cloned (explained below).
In the toolbar area of the SharedShell window, the status
indicator changes to show that SharedShell is connected to at least
one other user.
Furthermore, a yellow "share banner" is diplayed to act as a
conspicuous visual reminder that the terminal is being shared.
This banner contains all the functions related to sharing a terminal
window. On the left side is a legend with the names of each
participant. The arrow by each name indicates the user's color for
the current conference. To the right of the legend is an "Access"
menu that reflects the current access permissions setting. The menu
can be used during a conference to change the current access
permissions.
Further right in the yellow share banner is a button to send a note to
one or more conference participants. Pressing the "Send Note" button
will bring up a small note window:
Sending a note is useful when the user wants to send a text message to another
participant, but
doesn't want it executed as a command in the terminal (e.g., sending a Web URL).
By default,
notes are sent to all participants in a conference, but the pull-down menu in
the "To:" field
can be used to select a single user from the list to send a private note (when
there are more
than two conference participants). When a note is received, an alert bell rings
and the note
pops up on the recipients' computer screen, as shown below:
Any URLs included in notes are live; clicking on a URL will open the
user's default web browser to the specified web page. In addition,
the recipient of a note may send a reply, either to the sender or to
all conference participants.
The last item in the share banner is an "Alert" button. This is used
to get the attention of remote participants (typically by playing a
sound on everyone's computer).
Using the Terminal
In most respects, the SharedShell terminal acts like any standard UNIX
terminal window. The user types commands at the prompt and output is
printed in the window. One unique feature about SharedShell is that
more than one user may type commands if access permissions are set to
either "Type" or "Execute". Under these circumstances, the typing
appears in the color associated with the person typing, as indicated
in the legend. The system prompt always appears in black, and the
default color for the conference initiator (the customer, in our
scenario) is also black (although this color can be changed in the
"User Preferences" dialog). The output of any command appears in the
color of the person who typed the carriage return that executed the
command.
If SharedShell is in "Type" mode, only the user who initiated the
conference, who is on the computer on which any commands would be
executed, can execute a command by pressing the "Return" key at the
end of the command line. In our scenario, this means that only the
customer can execute commands by pressing "Return". If the support
engineer types a command and presses "Return," a blinking
"<RETURN>" appears, indicating that executing the command is
pending confirmation by the customer, who must press "Return."
As soon as the customer presses "Return," the blinking pending
<RETURN> indicator disappears and the command is executed. Any
user can cancel the command by pressing Ctrl-C, or edit it using the
"Backspace" key.
In "Execute" mode, any participant may press "Return" to execute
commands. In our scenario, this would allow the support engineer to
execute commands without having to wait for the customer to confirm
them. The color of the output of each command will be determined by
who pressed "Return" to execute that command.
The access permission setting can be changed in the midst of a
conference, so in our scenario, as the customer gains more of a sense
of trust in the support engineer, he can change the access permission
to "Execute", using the drop-down menu in the share banner.
A message documenting the change is printed in SharedShell, and the
support engineer can now type commands directly into the terminal on
her own.
Drawing
Another unique aspect of the SharedShell terminal is that it doubles
as a shared drawing surface. Regardless of access mode, any user in a
SharedShell conference may gesture or draw at any time using the
drawing tools. The drawing tools are available from the toolbar, the
tools menu, or the draw tools palette:
When the pointer tool is selected (the default selection), the user's
cursor is in the shape of the arrow. It appears in the user's color,
as indicated in the legend. Since all conference participants always
see each others' cursors, they can be used as telepointers to convey
mouse movements for pointing and gesturing. Typing at the keyboard
will enter the text at the command-line prompt, and selecting and
dragging with the left mouse button down will select text in the
terminal.
When the marker tool is selected, the user's cursor changes shape to
that of the marker and the user draws in the terminal window in his or
her selected color when the left mouse button is pressed. The drawing
layer is translucent so that terminal text may still be read if a user
draws over it or if new commands produce output that is printed in a
place where a drawing already exists. Typing at the keyboard will
still enter text at the command-line prompt.
When the terminal window scrolls, the drawing stays synchronized with the text
and scrolls off the screen along with the text.
Selecting the eraser tool allows any user to erase a portion of
the drawing and changes the user's cursor to the shape of an eraser.
The user may erase both their own drawings and those of anyone else in
the conference. Typing at the keyboard will still enter text at the
command-line prompt.
Adding Members and Leaving a SharedShell Conference
While troubleshooting a problem using a SharedShell conference, it may
be necessary to add users to the conference or some users may wish to
drop out. In our scenario, as they work through the problem, the
support engineer decides to add a colleague who is known to be an
expert on this particular problem. First, they add the expert to the
telephone conference call. Then, the support engineer instructs the
customer to go through the invitation process again to invite the
expert to join the SharedShell conference. Inviting new members to
the conference is controlled by the person who initiated the
conference (since any commands executed in SharedShell will be
executed on that person's machine). The customer reviews the access
permissions and decides to change it to "Type" mode before pressing
"Invite". The Conference ID dialog reappears and the process
continues in the same way as initially starting the conference (e.g.,
reading the new Conference ID out loud, confirming the new participant
that is joining). Once the expert is connected to the existing
conference, they may all point, draw, scroll back to see previous
contents of the window, or type commands.
When troubleshooting in a UNIX environment, it is often handy to have
more than one terminal window open at a time. At any time during a
SharedShell conference, any participant may select "Clone Shell" from
the Conference menu. This opens an additional SharedShell terminal
window connected to the same computer with all the same access
permissions and the same participants. A message saying that the
shell was cloned is printed in the transcript.
To drop out of a conference, any user may click on the "Leave..."
button, select "Leave..." from the Conference menu, or click the
close box from the window manager. In our scenario, once the support
engineer helps brief the expert on the problem, she realizes that she
could leave the conference and move on to her next customer. When she
clicks on "Leave...", she is prompted with a confirmation of whether
she wants to leave or wants to leave and quit SharedShell. She
chooses only to leave, and a message is printed in the terminal
documenting the time when the support engineer leaves the conference.
The SharedShell window on her computer now turns into an inactive,
unconnected terminal, as reflected in the status indicator.
The transcript from the conference still appears in the window and may
be viewed, scrolled, copied, and saved, but there is no longer an
active UNIX prompt (i.e., no UNIX commands can be entered because
SharedShell is no longer logged in to any computer) and the yellow
share banner disappears.
When the support engineer leaves, her name disappears from the
legend in the SharedShell windows on the customer's computer and on
the expert's computer, both of whom are still in the SharedShell
conference.
After working through the problem for a while, the expert resolves the
issue and instructs the customer to leave the SharedShell conference.
When the customer selects the "Leave..." command, the behavior is
slightly different than when the support engineer left. A dialog
warns that when the person who initiated the conference leaves, it
will be ended for everyone. If the customer confirms that he wants to
leave, he is left with an active but disconnected SharedShell window.
The share bar disappears, and the status indicator shows that the
shell is no longer connected to anyone else.
The shell still contains the history of interaction from the
just-completed conference. The customer may continue to work in this
terminal and can even connect to other users at some later time.
Saving and Viewing the Transcript
At any time during a SharedShell conference, a user may decide to save
a copy of the transcript. This saves both the text and any drawing in
an HTML file. Selecting the "Save Transcript..." command from the
Conference menu will bring up a dialog prompting the user to enter a
file name. The user is also given the option to save any notes that
have been sent or received as part of the SharedShell conference.
Including the notes captures all the interactions that occurred during
the conference.
A web browser must be used to view the transcript. When seen in the
browser, the user has the option of seeing the text and drawings
together, or seeing a text-only version.
Implementation Architecture of SharedShell
SharedShell works by creating a secure connection through firewalls.
To create this type of connection, it is necessary for each user's
client to connect to a SharedShell server in "neutral" territory
outside of any firewall. Proxies are needed to get through the user's
firewall, and all of these networking properties need to be specified.
SharedShell tries to automatically detect and set these properties, so
that users do not have to worry about configuring their SharedShell to
run. The address of the SharedShell server is preset in the
SharedShell software (initially there will be only one, but the
interface allows for specifying others in the future). Proxy and
SOCKS host information is the same as that used by a web browser. The
SharedShell application tries to automatically configure these
properties by examining the settings established for the user's
default web browser. If this information is not readily available,
the user will be prompted to manually enter it. Since each user's
site is different, this information will have to be provided by the
user's network administrator or internet service provider.
Providing a Secure, Easy-to-Use SharedShell
The design of SharedShell is intended to give users a sense of
confidence about the security of the connection it is making and make
it easy for users to use it, even on their first try. Since a
SharedShell connection typically requires penetrating corporate
firewalls to connect to a customer's computer, it must do so in a way
that respects policies about providing access to computers inside the
company firewall. SharedShell accomplishes this security using
well-established web proxies, and an interface that ensures that only
the desired users are being connected into a SharedShell conference.
Furthermore, since SharedShell enables others to see and potentially
execute commands on a user's computer, the user must have appropriate
control of what can be done on his or her computer. The access
permissions enable the users to control what remote users can do,
appropriate for the level of trust and understanding among the
participants. Some customers may want to globally disallow execute
and or type access for their entire company. This sort of preference
setting will be supported by the SharedShell server.
Since SharedShell will be used as problems arise on customers'
computers, it must be easy and lightweight to install, along the lines
of a web-based download. This impromptu context of using SharedShell
also means that the users probably would not have the benefit of any
prior training on using it. Thus, it must be self-evident how to use
the SharedShell interface. We plan to deploy SharedShell and study
how people use it to see if these design goals have been achieved.
|