Abstract
This
article details the preparation of a software package tailored specifically
for use in a university school counselor education program.
The current implementation includes capability for text-based chat
enhanced with video for use with clients, advisees, and off-campus
supervisors. Examples and links
to freeware programs and tutorials are included, along with specific
suggestions for installation and customization.
Concept
Into Practice: A Case Study In Software Design
When
the 2000-2001 academic year began, the four full-time faculty members assigned
to the school counseling program at the University of Nevada, Las Vegas, met
to establish goals and objectives for the year.
A new, shared research agenda with focus on exploration of service
delivery through the Internet/WWW was a consensus objective.
Reasons
for the selection were several. The
potential for delivering various counseling and/or counseling supervision
services via on-line modalities is receiving increasing attention both in
counselor education programs and in related fields (Baltimore & Jencius,
1999; Fowler, 2000).
One of the four faculty members, newly assigned to the school
counseling program, had some history in work with programming and design of
on-line programs for a special education population (Jones,
2000) and agreed to coordinate the activity.
There
was also recognition that the advantages of Internet/WWW service delivery for
persons in rural areas (Hackerman & Greer, 2000)
were not limited to populations in such areas.
Metropolitan Las Vegas is one of the fastest growing urban areas in the
United States. While all of our interns are placed in schools within the
metropolitan area, the inevitable traffic congestion associated with this
growth has created a growing problem in setting up face-to-face sessions with
students and off-site supervisors.
Supplementing our traditional activities with services delivered via
the Internet/WWW appeared to be an opportunity well worth exploring.
Our
intent in this paper is to share both frustrations and success related to the
specific design and implementation of the service delivery system.
We have no financial interest in the software packages to be described,
in fact the majority are freeware packages available to all.
While
we have found it advantageous to customize the software for our specific needs
and will suggest tools for such customization, many programs require little,
if any, adaptation. Some
experience in Perl and/or Java programming is needed for customization.
Our identities, however, are as counselor-educators, not as computer
programmers. Self-instruction
using on-line tutorials was sufficient to tailor the programs for our specific
needs.
There
is also no intent to claim that the current package is the “best”
available. It is our belief,
though, that the problems we have addressed with the software design are not
unique, and that some of our “hits” and “misses” will be of interest
and value to others in the counseling community who are confronting comparable
concerns.
Phase
1 - The Perl Script
The
first step was to identify which areas of possible delivery would be our
initial focus. Three were
selected: a trial using limited on-line supervision to supplement traditional
supervision sessions, a trial using pre-service counselors to provide on-line
interpretation of vocational interest inventory scores, and a trial of
“virtual meetings” of program faculty to supplement our scheduled
face-to-face sessions. The
latter, although not often noted in discussions of the advantages of
Internet/WWW applications was identified as having particular potential to
enhance communication capabilities among faculty with heavy advisee loads and
other time commitments.
Sussman
(2000) identified e-mail, text-based chat, and
video-conferencing as the primary alternatives available to exchange
information between counselors and consumers, noting that e-mail exchange was
by far the most widely used. Casey,
Bloom, and Moan (1994) describe the use of e-mail and
related technology in an effective supervision application.
Because we each were already making extensive use of e-mail with our
students, we decided to focus our project instead on applications of the
text-chat and video-conferencing alternatives.
Text-based
Chat
Chat
programs have, of course, become a common feature on the web landscape.
Users exchange information with known and unknown communication
partners, down the hallway and across the planet.
Delmonico, et al. (2000) investigated delivery of
an on-line support group using a chat site and found both strengths and some
concerns.
The
majority of text-based chat programs use the Common Gateway Interface (CGI).
CGI is not a language; it is instead a simple protocol used to
communicate between web forms and a host program.
In essence, the CGI allows a web site visitor to “run” a program
located on the host computer.
A
CGI program can be written in almost any programming language supported by the
host system. Perl scripts are,
however, easily the most popular tools, probably because they do not have to
be compiled as executable programs. Instead,
the Perl (Practical Extraction and Reporting Language) script simply
communicates information to the Perl program housed on the host computer which
relays the output back to the web. In
addition to text-chat applications, Perl scripts are frequently used to
display input from html forms, to create guestbooks, and in web-based e-mail
programs.
Implementing
a text-based chat system is relatively simple, and there are a number of
excellent, free Perl scripts from which to choose.
Examples include Jim Melanson’s Simple
Chat and the Chat-N-Time
program available through the Scripts for Educators site.
The ChatPro
2.5 program from Command-o.com, although not free, is a particularly
powerful program with a variety of easily configurable options, including
password-protected rooms, and a free trial download is provided.
The
common feature in these programs is that they are local-site based.
That is, all software is uploaded to the local site; the user is not
asked to join a broad web-based community.
Hosting this text chat software requires only minimal system resources. The host, in our case the school counseling program, needs
only a web site to which files can be uploaded and permission to execute CGI
programs on the web server.
Because
CGI programs are the equivalent of letting the world run programs on a host
computer, there are security precautions.
CGI programs are always housed in a special directory on the host
computer so the web server knows to execute the program, rather than display
it to the browser. The directory
will be under direct control of the host webmaster, and special permission is
typically required to upload files to this directory.
In most instances, including our own, the webmaster will create a
special cgi-bin directory for the user.
In
theory, and typically in practice, a prospective user then needs only the
address supplied by the host and a web browser to access the chat.
Most of the text-based chat programs do require a web browser with
capability to display frames.
To
illustrate the simplicity, the Simple
Chat download is comprised of just two small
files: the actual chat script and a configuration file with instructions.
One line of code in the configuration file is changed to reflect where
the chat data will be stored, accomplished by simply loading the configuration
file into any text processor, identifying the location of a data directory,
and saving the text.
To
install this software, the first step is to create a data directory on the
host web site and create a user subdirectory within it. The chat script and
chat configuration file are then uploaded to the special cgi-bin.
The
last installation step is to set permissions for reading, writing, and
executing of the related files. For the chat script and configuration file, the appropriate
permission allows you and the users to read and execute the files, but only
you are allowed to write to them. Full
permission for reading, writing, and executing is allowed for the data
directory and subdirectory. The
FTP program used to upload the files usually includes the UNIX chmod commands
to set these permissions. The
chat program is then ready to run.
The
Simple
Chat software is, by far, one of the easiest programs to install and use,
but ease of installation is typical for other Perl scripts as well.
All of the scripts include some configurable options.
In Simple
Chat, for example, font size/style, the number of users allowed at any one
time, and the displayed name of the program are modified by changing single
lines in the configuration script. Options
to add private rooms, select text colors, and so forth are also available in
some of the free scripts.
The
extent of further customization will be contingent on level of comfort with
programming and on the desired application(s).
We chose, for example, to write and add a Perl script for password
protection for access to the chat. Our
script reads a file of approved code numbers and then either directs the
browser to the chat or to an error page for resubmission.
Free, “off the shelf”, Perl password
protection
scripts are
available at a number of sites.
We
also chose to make a few other cosmetic changes to the basic script display.
Perl is a user-friendly programming language, and we found this
tutorial
an especially useful resource.
The more personal “feel” of the customized chat script easily justified the time required in preparation of it.
Visual
Cues
It is typical in discussions about technology
and counseling (Coursol & Lewis, 2000; Sampson, 2000) to note the significance of visual cues in
Internet/WWW communication. Video
conferencing is, in fact, one of the frequently mentioned modalities for
on-line supervision and/or service delivery (McFadden, 2000.
A growing number of free or inexpensive video
conferencing programs are available, requiring only some readily available
software and the addition of a small camera.
For example, Microsoft’s NetMeeting
is a free download, and many camera packages now include access to sites for
combined video/text chat.
There may, however, be a significant hidden
cost in use of such packages for delivery of counseling services, an
incremental loss of privacy. Concern
about confidentiality is clearly evident in ACA’s 1999 ethical
standards for
on-line service delivery.
A consumer
guide for use of online services
prepared by the American Psychological Association even suggests a service
which hides the identity of the web surfer.
Concerns about confidentiality were raised in the Delmonico, et al. (2000) study of a text-chat application.
After trials of several video-conferencing
packages, we were not comfortable with the loss of information control
implicit in the packages, particularly since some information to be
transmitted would likely be sensitive. Software
that provides such control is, of course, available but is designed and priced
for applications well beyond the scope of our need and budget.
We elected instead to separate the underlying
video and text chat programs, using one piece of software to transmit the
video and another to transmit the text chat.
The two distinct programs are then combined on the user screen in
simple html frames. This
decision, while adding a modicum of complexity in the design, did enable us to
have more direct control over where and how the text and video images were
projected.
Free and low cost webcam software comes in
basically two “flavors”. Most
packages are limited to simply capturing an image at user specified intervals,
followed by an FTP upload to a predetermined site.
These applications, though, provide no semblance of “natural”
movement. A streaming effect is obtained with software that includes a
built-in http server.
The InetCam
package from iVista provides
remarkable quality using some proprietary code which divides the image into
three parts and then refreshes only the part of the image which has changed.
Following free registration and software download, the user is
“assigned” a URL for the image that can then be accessed through any
browser. This package also
includes an auditory component (which can be disabled).
We chose, however, an alternative to enable
more control at the local site level, Paul Chinn’s WebCam2000.
This image server is a small (approximately 111KB) program which
continuously uploads still images to a configurable socket on the local
computer’s URL (e.g. mycomputer.com:8080).
It is a free download with no ads and no limitations on approved use.
Several features can be configured, including size of image and image
quality. The software works with
essentially any camera which uses standard "Video For Windows"
drivers.
A
stream-like effect is obtained using an html file directed to the URL.
The simplest procedure is setting an interval for autorefresh in the
HTML heading. A more natural
effect is accomplished by adding Javascript so that only the image itself is
refreshed.
Code samples for both techniques and a general
tutorial in use of webcams are available at WebCam World. Use of the
WebCam2000 package does require a static IP
address for the computer(s) serving the video images.
In situations where the Internet Service Provider dynamically assigns
the IP’s, a work-around is available using one of the free naming services,
for example Deerfield.com’s DNS2Go.
With the chat script prepared and the visual
input enabled, the last step then was to combine the two in a hopefully
user-friendly web environment. HTML
frames programming is not complex, and the HTML
Goodies site by Joe Burns has a very helpful on-line tutorial for
both frames and other HTML applications.
Our final Phase 1 software package used three frames: the video image, some program links to our school
counseling program,
and the modified text-chat program.
Phase
2: The Java Venture
We used the software described above through
most of the Fall 2000 semester. Student
feedback was quite positive, and a great deal of data were generated for
empirical analysis of the outcomes in several applications.
Feeling empowered by the overall success with our first customizing
venture, our next step addressed two concerns in that software package: the
awkwardness in communication from the ‘wait time’ in the chat script and
our desire to further insure confidentiality in the information being
transmitted.
Although the available CGI text chat programs
have some differences in the interface, there is a common feature.
Essentially all such programs are based on code that creates a
“virtual” script at the host URL. Users
submit data to that script with form input, and the script is in a frame that
is refreshed at a predetermined rate.
We found it difficult to maintain a
“natural” mode of communication because of the inevitable delay between
the time the input was submitted and the time it actually appeared on the
screen. Although certainly
not as problematic as is evident when trying to use e-mail for immediate
communication, there were frequent message “cross-overs”, especially when
more than two were using the script. User A asks a question.
User B answers the question. User
C asks for clarification of the question.
User B’s response may or may not have appeared on User C’s screen
before the request for clarification. Who
answers next?
A related problem with the standard
implementation evident even when only two are in the chat is that after User A
asks a question and receives no immediate response, (s)he has no way to know
whether User B is preparing a lengthy response, ignoring the question, has
lost access to the script, etc. This
is a common problem with chat text programs, and there is even a
“netiquette” suggestion to send a short abbreviation message, MTF, to let
others know that there is “more to follow”.To reduce the wait-time between
messages, we briefly considered use of one of the Internet Relay Chat/Instant
Messaging services but did not pursue this option.
While transmission speed is remarkable in contrast to a shared script,
we felt that the lack of confidentiality eliminated these as possible
alternatives for our applications.
A viable alternative, however, was found in
the JavaTalk program developed by Frank
Stefano, a research scientist at AT&T Laboratories Cambridge, UK.
It is distributed as free software, including source code, with no
limitations on use and an open invitation to modify the source as the basis
for other applets.
Rather than writing to a script, JavaTalk is a socket-based chat system.
The server component is run on the host computer and “listens” on a
predetermined socket (port) number. The
user simply connects to a page on the host that is running the server.
A socket is a mechanism that allows programs
to communicate, either on the same machine or across a network.
Apart from the IP address that specifies a computer on a network, each
computer also has a number of ports available for handling specific tasks.
The user specifies the IP address and the port number of the host. The
two programs establish a communication through the network using their
sockets, and then may exchange information, each by writing to and reading
from the socket which was created.
Some socket or port numbers are usually
“reserved”. For example, by
default you send e-mail through port 25 and receive e-mail through port 110. The higher numbered ports are typically available for other
applications. As described
earlier, we configured our webcam package to use port 8080.
To access JavaTalk,
the user must have a Java-enabled browser, but that capability is present in
most, if not all, current browers. The
difference in speed of transmission between the script and socket modalities
is startling. Near
real-time transmission and display of messages is evident even with a laptop
using a 28k modem.
The most common Java programs are applications
and “applets”. Applets are
designed for use with browsers on the Internet/WWW.
Access to an applet is provided with code inside a standard html file.
Applications, by contrast, are stand-alone executable programs and
cannot be directly accessed via the Internet/WWW.
Before Sun Microsystems introduced Java, essentially
all interactivity on the Internet/WWW used CGI scripting.
A user submitted information with the browser to a host server. The
host server passed the information to an external program running on the host.
Output from the external program went back to the browser. CGI scripts thus require at least one “round trip” from
the browser to the server and back. When, in contrast, an applet is included
on an html page, the applet is temporarily copied to the browser's machine and
is executed there, rather than on the host server, reducing the time and the
bandwidth demand.
Although sometimes confused because of the
similarity in names, Java and JavaScript have almost nothing in common except
for the name. Java is a
programming language developed at Sun Microsystems.
JavaScript, developed by Netscape, is a scripting language, an
extension to html.
The JavaTalk,
package has two components. One
is an applet which will run, as described above, on the local computer.
The chat server component, typical for socket programs, is an
application, as opposed to an applet, and must be executed on the host.
Setting up the server component of the package required some additional
steps. Special permission
to run applications on the primary host webserver is required, and such
permission is seldom granted.
We found, however, an easy workaround by
installing personal webserver software on a computer in the first author’s
faculty office. Several software
programs are available to enable this capability.
We chose the vqServer
package available as a free dowload from vqSoft.com.
This package runs on Windows, Linux, Macintosh, Solaris and any system
that supports Java. It also
includes options for password protection and CGI scripts.
Java programs are compiled as “classes”.
The JavaTalk download, in
addition to the source code, includes all of the compiled classes necessary to
run the program. With the
personal webserver installed, implementing the server component is a simple
single line command.
After the server is “listening”, a user
enters the chat with an html file on the host computer.
The user is initially identified by the local URL, but the standard
package includes instructions to change this to initials, first name, etc., if
desired.
Confidentiality
With the source code for both the server and
client components of JavaTalk included, we were next able to
give attention to enhancing the extent of confidentiality in the data
transmissions. In our Phase 1
script chat, we used password protection to access the script, stored the
files in areas of the website that could not be easily identified or accessed,
and removed the files from the web after their use. But there was always a period of time when the actual content
of the communication was moving between servers and stored in a site which
could not be completely secure. Concern
about the former was significantly increased when we first began experimenting
with the personal webserver software and could see first hand how easy it was
for web communications to be observed at the server level.
Java programming may not be an especially
pleasant venture for the “faint-hearted”, but one of the authors had
experience with the language, and the Internet/WWW is replete with tutorials
and sample applets. Software
required to prepare and compile java applets and applications is a free download
from Sun Microsystems. On-line
tutorials are also available at the site.
Armed with confidence that trial and error is a powerful tool in this
process, we set out to add encryption to the JavaTalk
package.
Conceptually, the task is relatively simple. A user types a message in an area of the applet identified as
a TextField. When the user
presses the <enter> key, the message is sent to the server which
broadcasts the message to the Internet/WWW through the specified socket
number. The server is
concurrently listening on that socket, and all messages which come to that
socket number are sent to a display area on the applet identified as a
TextArea.
In effect, the message being typed in the
TextField is private to the user until the <enter> key is pressed.
To enhance confidentiality, we simply added two steps to the process.
Step one was to encrypt the message after the
<enter> key is pressed to send the message but before the message goes
to the server for broadcast. Thus,
only the encrypted message would be “heard” by the server and then sent
back to the applet for display in the TextArea.
After the message is received by the applet from the server, step two
was to insert code to decrypt the message before display in the TextArea.
Both steps occur at the level of the local applet; only the encryptions
are broadcast through the host server.
There
are several options to provide encryption.
The most widely used encryption technique on the Internet/WWW is the ROT13
method which rotates the alphabet by half its length.
For more serious encryption, JulianCode is a free download from the JavaBoutique.
And, since the primary intent is to hide the task from a casual reader,
it is also possible to use a simple letter substitution technique for
encryption.
Enhancing
the Application
While
the socket-based chat program provided near real-time transmission after the
message was submitted, there was still the problem of wondering what was
happening during the periods when no messages were being transmitted.
We addressed that problem by adding a “monitorField” to the JavaTalk
applet and integrating some elements of a Perl script into the applet.
Java
applets have the capability to read files from a host computer, but for
security reasons, applets cannot create or write to a file on the host
computer. Perl scripts can both
read and write to host files, but socket programming in Perl is quite complex
and not particularly robust.
Scott
Clark’s tutorial
on file input/output capabilities in Java was an especially helpful guide
through which we added an additional communication capability to the JavaTalk
applet, a message to a monitorField that a user was in the process of
preparing a message.
This
presented an interesting programming challenge, but the outcome has more than
justified the effort. In this
enhancement, code was added to the Java applet to check, at 5-second
intervals, the length of the text in the TextArea used to prepare and send a
message. When the length is
greater than zero (user is typing something in the TextArea), the applet
submits to a Perl script the text “(initials) is preparing a message.”
The Perl script writes this message to a file on the host computer.
When the <enter> key is pressed to send the message to the chat
server, a blank message is sent to the Perl script and written to the host
file. In the meantime, the
applet, also at 5-second intervals, is reading the file from the host
computer, and displaying the results in the TextArea at the top of the applet.
While
not a perfect solution since occasionally more than one user will be
attempting to write to the file at the same time, in practice this has
essentially resolved the “what is going on” question.
When there are apparent periods of inactivity in the chat, the user has
a visual signal if a message is being prepared.
Current
Applications
Using
the enhanced JavaTalk
system as described above, we have three current areas of application.
In simplest form, the system provides an essentially real-time chat
capability for communicating with students, with off-site supervisors, and for
“virtual meetings” of the school counseling program faculty.
Combining
JavaTalk with html
frames, another application allows supervisor and supervisee concurrently to
view a supervisor’s case notes while “talking” about those notes.
In this application, the notes can be encrypted before uploading to the
website. One html frame holds the
chat component and another is used to display the case notes.
Our
most ambitious implementation involves administration and interpretation of a
test via the Internet/WWW. In the
illustration identified in the graphic as labclient.htm, the student's left
frame holds the chat component. The
top of the right frame on the student screen is a test prepared in the Java
language. The bottom of the right
frame on the student screen is a stream-type video image of the faculty
member, using the WebCam2000
program described above.
In
this implementation, the process begins with the faculty member providing
explanation and directions for the test through the chat frame and answering
any questions prior to the test administration. When the orientation is completed, the faculty member
instructs the student to “click” in the frame on the right and begin the
test. A Perl script writes a
one-line file on the host computer indicating that the test has been accessed
and writes to that same file when the test is completed and the report is
ready..
On
the faculty member’s screen, identified as labhost.htm in the graphic, the
left frame is the chat. A Java
program in the upper right on the faculty member’s computer checks the
access file at 5-second intervals to identify when the testing has begun and
when it is completed. When
the test is completed, the student’s program writes the test results to a
different file on the host. When the faculty member receives the message that
the test is completed, that file is then loaded into a display area.
The student and faculty member then return to the chat frame to discuss
the test results.
In
this implementation, the student will always be able to “see” the faculty
member. If the student is
completing the test in a webcam-enabled setting, the lower right corner of the
faculty member’s screen is an image of the student.
Otherwise, that section is blank.
Summary
and Discussion
The
oft-quoted “journey and not a destination” clearly describes our present
status. We are using the current
software package through the Spring 2001 semester, and it appears to have
successfully resolved our concerns about speed of transmission, enhanced
privacy, and additional communication cues.
It would be less than accurate, however, for us to suggest that all is
now smooth sailing.
There
continue to be occasional problems with proprietary browsers.
Both for us and for others, the intent of Java to provide a “write
once, run anywhere” environment remains an only partially fulfilled goal.
For reasons that are not completely clear, for example, the Netscape
(4.7) browser will at times hang in the middle of a test administration. This phenomenon is not evident, however, with the current and
recent versions of Microsoft’s Internet Explorer, and we have not yet had
opportunity to test the package with the new Netscape browser.
Unlike
many of the CGI-based text-chat programs, JavaTalk does not allow for creation
of private rooms. Thus, anyone
who reaches the html file that points to an active socket can enter into an
active conversation. We have
minimized that possibility through use of password protected files and
directories, and the page cannot be bookmarked to avoid the password.
Some
such risk, however, is inevitable. A
feature in the JavaTalk software does provide additional security so long as
the appropriate users remain alert. When
one enters this chat, the only things which will appear on the screen are the
messages transmitted after entry, and there is a signal when the page is
accessed. Not unlike the real
life scenario if an unwanted observer intrudes, the intended participants can
simply exit, leaving the lurker with a blank screen.
Although,
as noted above, JavaTalk does not provide private rooms, more than one socket
can be active at the same time. Thus,
a faculty member could be conversing with an advisee through one socket while
another faculty member was conferring with an off-site supervisor through
another socket, and there would be no cross-over of the transmissions.
We currently are keeping three sockets active at all times without
apparent overload of the computer resources.
To
all who might be considering comparable applications, persistence and
flexibility appear to be the primary ingredients. Persistence because the best intended software will sometimes
crash, and there were certainly times when such crashes caused us to
re-consider just using commercial packages, and even whether the online road
was really worth traveling. Persistence
also because no matter what unusual application you are considering, there is
a good chance that someone else has already tried it.
Online searches provide a plethora of examples of code which can guide
the new development.
In
all such applications, flexibility is also a critical feature; there should
always be a “plan b” for those instances in which a software application
that had been working perfectly, suddenly malfunctions in the middle of an
important conversation. A
sharp-eyed reader may have caught one such instance in the image used to
illustrate the student in the combined chat and test administration format. In this program, instructions, test interpretation, and test
administration are all designed to occur in the software.
In the illustration, though, the student also has a telephone in hand
and is, in fact, receiving instructions about what to do when the program
appeared to have stalled. An argument, in fact, could be made that the optimal use of
current technology would combine use of the telephone with the software.
We, for example, have had instances of using the phone to talk to a
supervisee while simultaneously viewing the supervision notes on the computer.
Through
sharing of our experiences, it was our intent with this paper to both point
out some potential pitfalls and also to encourage others to consider
comparable activities. Designing
and/or customizing software is a time-consuming venture, but there are
rewards. On occasion it was also
helpful to be reminded that commercial software also sometimes crashes (and
usually at the worst possible moment). We
also attempted to remain constantly vigilant to the fact that the software is
only a medium. What we say and do
with our clients and supervisees is important.
How we do it is only a tool.
References
Baltimore, M.L., and Jencius, M. (1999). A new professional publishing paradigm: Cyberpublication and the Journal of Technology in Counseling, Journal of Technology in Counseling, 1.1. Retrieved March 27, 2001, from the World Wide Web: http://jtc.colstate.edu/vol1_1/cyberpublication.htm
Casey,
J., Bloom, J. B., and Moan, E. (1994). Use of technology in counselor supervision.
ERIC Digest ED372357 Apr 94. ERIC Clearinghouse on Counseling and Student
Services, Greensboro, NC. Retrieved March 27, 2001, from the World Wide Web: http://www.ed.gov/databases/ERIC_Digests/ed372357.html
Coursol,
D.H., and Lewis, J. (2000). Cybersupervision: Close encounters in the new
millenium.
Retrieved March 27, 2001, from the World Wide Web:
http://cybercounsel.uncg.edu/manuscripts/cybersupervision.htm
Delmonico,
D.L., Daninhirsch, C., Page, B., Walsh, J., L’Amoreaux, N.A., and Thompson,
R.S. (2000). The palace: Participant responses to a virtual support group, Journal of Technology in Counseling, 1.2 Retrieved
March 27, 2001, from the World Wide Web: http://jtc.colstate.edu/vol1_2/palace.htm
Fowler, R.D. (2000). The internet: Changing the work we do, Monitor on
Psychology, 31,
Retrieved March 27, 2001, from the World Wide Web: http://www.apa.org/monitor/apr00/rc.html
Hackerman, A.E., & Greer, B.G. (2000). Counseling psychology and the
internet: A further inquiry. Journal of Technology in Counseling, 1.2 Retrieved
March 27, 2001, from the World Wide Web: http://jtc.colstate.edu/vol1_2/cyberpsych.htm
Jones, W.P. (2000). Neuropsychological assessment on the Internet/WWW:
The next step. Proceeedings of the Fifteenth Annual Conference on Technology and Persons with Disabilities.
Retrieved March 27, 2001, from the World Wide Web:
http://www.csun.edu/cod/conf2000/proceedings/0217Jones.html
McFadden, J. (2000). Computer-mediated technology and transcultural
counselor education. Journal of Technology in Counseling, 1.2. Retrieved
March 27, 2001, from the World Wide Web: http://jtc.colstate.edu/vol1_2/transcult.html
Sampson, J.P. (2000). Using the internet to enhance testing in counseling. Journal of Counseling and Development, 78,
348-356.
Sussman, R. J. (2000). Counseling over the internet: Benefits and challenges in the use of new technologies.
Alexandria, VA: American Counseling Association/ERIC/CASS. Retrieved March 27,
2001, from the World Wide Web: http://cybercounsel.uncg.edu/manuscripts/internetcounseling.htm
